CONFERÊNCIA IADIS IBERO-AMERICANA

Computação Aplicada 2013

i
ii
ATAS DA CONFERÊNCIA IADIS IBERO-AMERICANA

Computação Aplicada 2013

SÃO LEOPOLDO, RS, BRASIL

21 – 23 NOVEMBRO, 2013

Organizada por
IADIS
International Association for Development of the Information Society

Co-organizada pela

iii
 Copyright 2013
IADIS Press
Todos os direitos reservados
Este trabalho está sujeito a direitos de autor. Todos os direitos são reservados, no todo ou em parte,
mais especificamente os direitos de tradução, reimpressão, reutilização de ilustrações, re-citação,
emissão, reprodução em microfilme ou de qualquer outra forma, e armazenamento em bases de
dados. A permissão para utilização deverá ser sempre obtida da IADIS Press. Por favor contactar
secretariat@iadis.org.

Editado por Cristiano Costa e Pedro Isaías

Editor Associado: Luís Rodrigues

ISBN: 978-972-8939-96-0

iv
 ÍNDICE

PREFÁCIO ix
COMITÉ DO PROGRAMA xi
PALESTRAS CONVIDADAS xv

ARTIGOS PALESTRAS CONVIDADAS

SEGURANÇA CIBERNÉTICA: DESAFIOS E OPORTUNIDADES NA ERA 3

DE CIBERESPIONAGEM
Mehran Misaghi
TENDÊNCIAS NA COMPUTAÇÃO MÓVEL E UBÍQUA 11
Cristiano André da Costa

ARTIGOS LONGOS

ECG COM COMUNICAÇÃO SEM FIO BASEADO NO PROTOCOLO ZIGBEE 21

E WWW
Ari Magagnin Junior, João Hamilton Cecato Simas e Miguel Antonio Sovierzoski
PROCESO DE DESARROLLO DE COMPONENTES SOFTWARE REUTILIZABLES 29
ENFOCADO AL DESARROLLO DE APLICACIONES EMPRESARIALES
Fredy Humberto Vera Rivera, Fernando Antonio Rojas Morales y Enrique Torres López
UMA REVISÃO SISTEMÁTICA DA LITERATURA SOBRE MÉTRICAS 38
DE SOFTWARE
Darlan Florêncio de Arruda, José Gilson de A. T. Filho e Ricardo de Lima Chen
HERRAMIENTA DE MEDICION DE LA SATISFACCION DE LAS NECESIDADES 47
DE LOS USUARIOS DE SISTEMAS INFORMATICOS. EXPERIENCIAS
CON USUARIOS
Marisa Panizzi, Diego Arenas, Damián Gimenez, Elisa Licata Caruso y Mayra Carabajal
REDES NEURAIS APLICADAS NO RECONHECIMENTO DE CARACTERES 55
EM IMAGENS DE PLACAS VEICULARES
Célio Hoepers e Max Pereira
DESENVOLVIMENTO DE UM SISTEMA DINÂMICO DE MAPEAMENTO 63
DE LINHAS DE ÔNIBUS PARA UM MODELO DE TRANSPORTE INTELIGENTE
Williams M. de Araújo e Moisés P. Bastos

v
UTILIZANDO TÉCNICAS DE ALGORITMO GENÉTICO PARA RESOLUÇÃO 71
DO PROBLEMA DE GERAÇÃO DE GRADE HORÁRIA PARA ENFERMARIAS
Ricardo Soares Bôaventura, Bruno Queiroz Pinto e Keiji Yamanaka
APLICAÇÃO DE RACIOCÍNIO BASEADO EM CASOS A SISTEMAS DE SUPORTE 79
DE TI – HELP DESK
Aldair Hoepers, Max Pereira e Ademar Schmitz
SCHISTOSYSTEM – INTELIGÊNCIA ARTIFICAL PARA DIAGNÓSTICO 87
AUTOMÁTICO POR IMAGENS
André Caetano Alves Firmo, Allison Dantas de Oliveira, Julyana Viegas Campos,
Jones Albuquerque e Constança Barbosa
EXTRAÇÃO E SELEÇÃO DE CARACTERÍSTICAS PARA DIAGNÓSTICO 95
AUTOMÁTICO DE DEFEITOS EM MÁQUINAS ROTATÓRIAS
Francisco de Assis Boldt, Thomas Walter Rauber e Flávio Miguel Varejão
AGRUPAMENTO FUZZY E REGRESSÃO LOGÍSTICA APLICADOS NA ANÁLISE 103
DE TRAUMATISMO CRANIOENCEFÁLICO GRAVE
Merisandra Côrtes de Mattos Garcia, Evandro Tostes Martins e Fernando Mendes de Azevedo
MODELO DE SISTEMA DE MONITORAMENTO PARA ESTRUTURAS DE AÇO 111
UTILIZADOS EM CONSTRUÇÃO CIVIL
Diogo Lucena Gomes de Melo, Eneias Bezerra da Silva Junior, Gilmar Gonçalves de Brito,
Paulo Sérgio Brandão do Nascimento, Mêuser Jorge Silva Valença e Sérgio Murilo Maciel
Fernandes
MIF-RC: UMA METODOLOGIA INTEGRADA PARA APLICAÇÃO DE FORENSE 119
COMPUTACIONAL EM LOGS DE E-MAIL
Toni Escobar, Cristiane Ellwanger, Cristina Paludo Santos, Alessandro Freitas de Oliveira
e Paulo Ricardo Baptista Betencourt
SEGURANÇA DA INFORMAÇÃO: UMA INVESTIGAÇÃO NA PERSPECTIVA 127
DO USUÁRIO DE SISTEMAS DE INFORMAÇÃO CORPORATIVOS EM UMA
ORGANIZAÇÃO DE SAÚDE
Luciana Emirena dos Santos Carneiro e Maurício Barcellos Almeida
BUSCA EXPLORATÓRIA: UM ESTUDO DE CASO SOBRE DESENVOLVIMENTO 135
E AVALIAÇÃO DE UM SISTEMA
Deyvid Heric de Moraes, Luciano Tadeu Esteves Pansanato, Douglas Felipe Pereira e
Diogo Arenhart Marinho
RFDroid: SOLUÇÃO PARA AUXÍLIO À MOBILIDADE DE PESSOAS COM 143
DEFICIÊNCIA VISUAL EM AMBIENTES INDOOR
Cristina Paludo Santos, Cristiane Ellwanger, Denilson Rodrigues da Silva e Thomaz Colpo de Lima
FERRAMENTA DE APOIO AO ENSINO DE PROGRAMAÇÃO COM INTRODUÇÃO 151
A ORIENTAÇÃO A OBJETOS
Eduardo Guedes Carvalho, Gabriel Viana Guedes e Luiz Alfredo Soares Garcindo
AVALIAÇÃO HEURÍSTICA PARA GROUPWARES MÓVEIS: UM ESTUDO DE 158
CASO UTILIZANDO UM AUDIENCE RESPONSE SYSTEM
Márcio J. Mantau, Luciana P. Araújo, Jucilane R. Citadin e Carla D.M. Berkenbrock

vi
UM SERVIÇO DE GERENCIAMENTO DE QUALIDADE DE CONTEXTO EM REDES 166
DE SENSORES SEM FIO
Joéver Silva Hoffman, Isaac S. A. Pereira, Sérgio Teixeira, Janaína Scal Duia Castello,
José Gonçalves Pereira Filho e Patricia Dockhorn Costa
VALIDAÇÃO DE DEPENDÊNCIAS FUNCIONAIS CONDICIONAIS EM DADOS 175
XML: UMA ABORDAGEM BASEADA EM GRAMÁTICA DE ATRIBUTOS
Aryadne Guardieiro Pereira Rezende e Maria Adriana Vidigal de Lima
ESCALONAMENTO DE TAREFAS EM FERRAMENTA DE SEQUENCIAMENTO 183
GENÉTICO
Jéfer Benedett Dörr, Guilherme Galante e Luis Carlos E. de Bona

ARTIGOS CURTOS

APLICABILIDADE DE TÉCNICAS DE ALGORITMOS GENÉTICOS VIA WEB 193

UTILIZADA EM APLICAÇÕES DE GERENCIAMENTO DA CARTEIRA DE
CLIENTES E DO SCHEDULE DIÁRIO DA FORÇA DE VENDAS BANCÁRIA
Ricardo Soares Bôaventura, Bruno Queiroz Pinto, Miriellen Augusta da Assunção, Keiji Yamanaka
e Christina Testa Marques
CONTROLE FUZZY DO ARMAZENAMENTO DE GRÃOS DE ARROZ 198
Marcos Rodrigo Sauki, Maicon Bastos Palhano, Gabriel Felippe, Ruano Marques Pereira,
Priscyla W. T. de Azevedo Simões e Merisandra Côrtes de Mattos Garcia
ARBIO: SISTEMA DE GESTÃO DA ARBORIZAÇÃO 203
Denis Bruno Viríssimo, Marcelo Cristiano Russo, Sergio Brazolin e
Raquel Dias Aguiar Moraes Amaral
AVALIAÇÃO DE SISTEMAS DE BUSCA EXPLORATÓRIA: UM ESTUDO DE CASO 209
COM O MÉTODO AVALIAÇÃO HEURÍSTICA
Dferson do Prado Pereira e Luciano Tadeu Esteves Pansanato
DISEÑO Y DESARROLO DE UNA APLICACION DISTRIBUIDA 213
PARA LA ASIGNACION AUTOMATICA DE HORARIOS DE CLASES
Juan Fajardo Barrero
DETECÇÃO AUTOMÁTICA DE CÉLULAS SANGUÍNEAS 218
Jaqueline Cristina Sgarbi e Patricia Bellin Ribeiro
O TEOREMA DE PROBABILIDADE PELO ALGORITMO NAIVE BAYES 223
PARA A CLASSIFICAÇÃO DE DADOS: UM ESTUDO EM FERRAMENTAS DE
DATA MINING
Marcio Novaski, Merisandra C. de Mattos Garcia, Maicon Bastos Palhano, Gabriel Felippe,
Ruano Marques Pereira e Fernando Mendes de Azevedo
SISTEMA DE ANÁLISE DE VÍDEO EM TEMPO REAL NA DETECÇÃO DE 228
PADRÕES DE MOVIMENTO
Davi Alberto Sala, Adriane Parraga e Letícia Vieira Guimarães
MODBUS SECURE: INCORPORANDO MECANISMOS DE SEGURANÇA NO 233
PROTOCOLO MODBUS
Édson Fick , Rodrigo Marques de Figueiredo e Janaína Conceição Sutil Lemos

vii
SISTEMA RECONFIGURÁVEL PARA AQUISIÇÃO DE SINAIS DE 237
ELETROCARDIOGRAMA
Marcel Seiji Kay e Fábio Iaione

ARTIGO DE REFLEXÃO

UMA PROPOSTA DE SOFTWARE PARA PUBLICAÇÃO DE PROCEDIMENTOS DE 245

SUPORTE À INFORMÁTICA NOS PADRÕES DA WEB SEMÂNTICA
Matheus Dimas de Morais e Diego da Silva Sales

POSTERS

ESTUDO SOBRE MINERAÇÃO DE DADOS PARA DETECÇÃO DE SPAMS EM

REDES DE COMPUTADORES UTILIZANDO TÉCNICAS INTELIGENTES 251
Patricia Bellin Ribeiro, Kelton Augusto Pontara da Costa, Henrique Pachioni Martins,
Miguel José das Neves, Atair Alves Camargo Junior e Victor Vavalle Rossi
APLICAÇÃO DE REDES NEUROFUZZY NA AVALIAÇÃO DO COMPORTAMENTO
DO MERCADO IMOBILIÁRIO LOCAL
Níria Borges Ferreira, Maicon Bastos Palhano, Gabriel Felippe, Ruano Marques Pereira, 253
Priscyla Waleska T. de Azevedo Simões, Evelise Chemale Zancan e Merisandra C. de Mattos
Garcia
APRENDIZAGEM DA DISCIPLINA DE LINGUAGENS FORMAIS E AUTÔMATOS
FUNDAMENTADA NO DESENVOLVIMENTO DE UM SIMULADOR PARA
MÁQUINAS DE ESTADOS FINITOS 256
Andre Henrique Silva, Celso Olivete Júnior, Rogério Eduardo Garcia e Ronaldo Celso Messias
Correia
SISTEMA AGENDA DE COMPROMISSOS DOS OBJETIVOS DE
DESENVOLVIMENTO DO MILÊNIO 259
Débora Lima, Sérgio Rodrigues, Rodrigo Santos, Jano Souza, Miriam Chaves, Paula Losada e
Irene Cunha
ROTEAMENTO EM REDES DE COMPUTADORES UTILIZANDO ALGORITMOS
GENÉTICOS 262
Matheus Dimas de Morais, Wesley Folly Volotão de Souza, Anderson de Souza Lima e Ítalo de
Oliveira Matias
ANÁLISE DE DISPONIBILIDADE NA COMPUTAÇÃO EM NUVEM: WINDOWS
AZURE 265
Diego von Söhsten e Sérgio Murilo
DESENVOLVIMENTO DO MÉTODO ICS PARA O ENSINO DO TDAH ATRAVÉS
DE FERRAMENTAS COMPUTACIONAIS 268
Eduardo Seige Ianaguivara, Alex Candiago e Alessandro Pereira da Silva

AUTHOR INDEX

viii
 PREFÁCIO

Estas atas contêm os artigos e posters da Conferência IADIS Ibero-Americana Computação

Aplicada 2013, organizada pela International Association for Development of the
Information Society e co-organizada pela Universidade do Vale do Rio dos Sinos -
UNISINOS, São Leopoldo, RS, Brasil, de 21 a 23 de novembro 2013.
A conferência Ibero-Americana Computação Aplicada 2013 tem como objetivo abordar os
principais temas de interesse dentro da área de computação aplicada e tópicos relacionados.
Esta conferência aborda aspetos essencialmente técnicos.
Todas as áreas relacionadas à Computação Aplicada são de interesse, incluindo, mas não
limitado, às seguintes áreas:

- Sistemas de Agentes e Aplicações - Orientação a Objetos

- Algoritmos - Sistemas Paralelos e Distribuídos
- Sistemas de Informação Aplicados - Sistemas de Pagamento
- Bioinformática - Linguagens de Programação
- Estudos de Caso e Aplicações - Protocolos e Padrões
- Comunicações - Segurança
- Mineração de Dados (Data Mining) - Web Semântica
- Sistema de Bancos de Dados - Engenharia de Software
- Teoria e Prática do Comércio Eletrónico - Armazenamento
- Sistemas Embebidos - Tecnologias para a e-Learning
- Avaliação e Análise - Aplicações sem Fio
- Tendências Globais - Aplicações da WWW
- Computação em Grid - Tecnologias da WWW
- Recuperação de Informação - Computação Ubíqua
- Sistemas Inteligentes - Problemas de Usabilidade
- Redes Móveis e Sistemas - Realidade Virtual
- Multimídia - Visualização
- Redes - XML e Outras Linguagens Extensíveis

A conferência IADIS Ibero-Americana Computação Aplicada teve 117 submissões. Cada

submissão foi avaliada por uma média de quatro revisores independentes para assegurar o
elevado nível final das submissões aceites. O resultado final foi a publicação de 21 artigos
longos (correspondentes a uma taxa de aceitação de 18%), sendo publicados também artigo
de reflexão, artigos curtos e posters.

ix
Como sabemos, a organização de uma conferência requer o esforço de muitas pessoas.
Gostaríamos de agradecer a todos os membros do Comité de Programa pelo trabalho
realizado na revisão e seleção dos artigos que constam destas atas.

Estas atas resultam da contribuição de um variado número de autores. Estamos gratos a

todos os autores que submeteram os seus artigos. Agradecemos igualmente ao Professor
Mehran Misaghi, Sociedade Educacional de Santa Catarina (SOCIESC), Brasil e ao
Professor Cristiano Costa, Universidade do Vale do Rio dos Sinos (UNISINOS), Brasil por
terem aceitado dar uma palestra. Também gostaríamos de agradecer a todos os membros do
comité de organização, delegados e convidados cuja contribuição e envolvimento são
cruciais para o sucesso desta conferência.
Por fim, desejamos que todos os participantes tenham uma excelente estadia em São
Leopoldo, RS, Brasil. Convidamos todos os participantes para a edição do próximo ano da
conferência IADIS Ibero-Americana Computação Aplicada, que se realizará no Porto, em
Portugal.

Cristiano Costa, Universidade do Vale do Rio dos Sinos (UNISINOS), Brasil

Pedro Isaías, Universidade Aberta, Portugal
Co-Chairs

São Leopoldo, RS, Brasil

21 de novembro 2013

x
 COMITÉ DO PROGRAMA

CO-CHAIRS
Cristiano Costa, Universidade do Vale do Rio dos Sinos (UNISINOS), Brasil
Pedro Isaías, Universidade Aberta, Portugal

MEMBROS DO COMITÉ
Alejandra Garrido, Universidad Nacional de La Plata, Argentina
Alejandro Oliveros, Universidad Nacional De Tres De Febrero, Argentina
Alex Sandro Roschildt Pinto, Unesp De Rio Preto, Brasil
Alvaro De La Ossa, Colaboratorio Nacional De Computacion Avanzada, Costa Rica
Alvaro Luis Bustamante, Universidad Carlos III de Madrid, Espanha
Amaury Antonio De Castro Jr, Universidade Federal de Mato Grosso do Sul, Brasil
Ana Barbosa, Universidade Do Extremo Sul Catarinense, Brasil
Ana Winck, Universidade Federal de Santa Maria, Brasil
Ana Carolina Bertoletti De Marchi, Universidade de Passo Fundo, Brasil
Ana Paula Ferreira, Unipampa, Brasil
Anderson Luiz Fernandes Perez, Universidade Federal De Santa Catarina, Brasil
Angel Perles Ivars, Universitat Politecnica De Valencia, Espanha
Anibal Zaldivar Colado, Universidad Autonoma De Sinaloa, Mexico
Antonio Marti Campoy, Universitat Politecnica De Valencia, Espanha
Antonio Rito-Silva, Universidade Tecnica De Lisboa, Portugal
Arturo Camacho, Universidad De Costa Rica, Costa Rica
Asier Perallos, Universidad De Deusto, Espanha
Autran Macedo, Universidade Federal de Uberlandia, Brasil
Begoña C. Arrue Ulles, Universidad De Sevilla, Espanha
Bernardo Rocha, Universidade Federal De Juiz De Fora, Brasil
Carla Osthoff, Laboratorio Nacional de Computação Cientifica, Brasil
Carlos Holbig, Universidade de Passo Fundo, Brasil
Carlos Travieso, Universidad De Las Palmas De Gran Canaria, Espanha
Carlos Montez, Universidade Federal De Santa Catarina, Brasil
Carlos Valencio, Universidade Estadual Paulista Julio De Mesquita F, Brasil
Carolina Tripp Barba, Universidad Politecnica De Cataluna, Espanha
Celso Costa, Pontificia Universidade Catolica do Rio Grande do, Brasil
Claudio Toledo, Universidade De Sã£o Paulo, Brasil
Clayton Reginaldo Pereira, Universidade Federal de São Carlos, Brasil
Cristian Cechinel, Ufpel, Brasil
Cristian Garcia Bauza, Universidad Nacional Del Centro De La Provincia De, Argentina
Daniel Mesquita, Universidade Federal De Uberlandia, Brasil
Diego Carvalho, Centro Federal de Educação Tecnológica Celso Suckow da Fonseca,
Brasil

xi
 Diego Cazorla, Universidad De Castilla-la Mancha, Espanha
Eduardo Alchieri, Universidade De Brasilia, Brasil
Edward Moreno, Ufs, Brasil
Elder Cirilo, Pontificia Universidade Catolica Do Rio De Janeiro, Brasil
Eliane Pozzebon, Universidade Federal De Santa Catarina, Brasil
Elisangela Silva Da Cunha Rodrigues, Universidade Federal de Mato Grosso do Sul, Brasil
Esteban Robles Luna, Lifia - Unlp, Argentina
Eugenio Tamura, Pontificia Universidad Javeriana, Colombia
Fabiano Baldo, Universidade Do Estado De Santa Catarina, Brasil
Fabio Iaione, Facom/ufms, Brasil
Fabricio Augusto Rodrigues, Universidade Federal de Mato Grosso do Sul, Brasil
Fernando Jose Braz, Instituto Federal De Catarinense, Brasil
Fernando Osorio, Universidade De São Paulo, Brasil
Francisco Jose Seron, Universidad De Zaragoza, Espanha
Francisco Rodriguez Ballester, Universidad Politecnica De Valencia, Espanha
Geraldo Zafalon, Unesp, Brasil
Giliane Bernardi, Universidade Federal De Santa Maria, Brasil
Giovanni Cordeiro Barroso, Universidade Federal do Ceara, Brasil
Gustavo Boroni, Conicet-uncpba-pladema, Argentina
Gustavo Pessin, Usp/icmc, Brasil
Heitor S. Ramos, Universidade Federal de Alagoas, Brasil
Henrique Freitas, Pontificia Universidade Catolica de Minas Gerais, Brasil
Herbert Hoeger, Universidad Los Andes, Venezuela
Ignacio Larrabide, Upf, Espanha
Javier Muguerza, Universidad Del Pais Vasco, Espanha
Jesus Maria Perez, Universidad Del Pais Vasco, Espanha
João Paulo Papa, Universidade Estadual Paulista Julio de Mesquita F, Brasil
Joice Seleme Mota, Instituto Federal Catarinense, Brasil
Jorge Jesus Gomez Sanz, Universidad Complutense De Madrid, Espanha
Jose Alfonso Aguilar, Universidad Tecnologica De Mazatlan, Mexico
Jose Antonio Mateo, Universidad Castilla-la-mancha, Espanha
Jose Alfredo Cobian Campos, Universidad Nacional Autonoma De Mexico, Mexico
Jose Angel Banares Banares, Universidad De Zaragoza, Espanha
Jose L. Sanchez, Universidad De Castilla-la Mancha, Espanha
Jose Luis Castillo Sequera, Universidad De Alcala, Espanha
Jose Luis Vazquez-poletti, Universidad Complutense De Madrid, Espanha
Jose Manuel Colom, Universidad De Zaragoza, Espanha
Jose Amazonas, LCS/PTC/EPUSP, Brasil
Jose Machado, UNESP/SJRP, Bouvet Island
Juan Corchado, Universidad De Salamanca, Espanha
Juan Pablo D Amato, Univ. Nacional Del Centro De La Provincia De Bueno, Argentina
Juan Vicente Capella Hernandez, Universidad Politecnica De Valencia, Espanha
Juliana Souza, Fmrp - Usp, Brasil
Kalinka Branco, Universidade De São Paulo, Brasil
Karina Dos Santos Machado, Universidade Federal do Rio Grande, Brasil

xii
 Kelton Augusto Pontara Da Costa, Fatec-campus Bauru, Brasil
Kike Marti, Universidad Carlos Iii Madrid, Espanha
Kleinner Farias, Universidade do Vale do Rio dos Sinos, Brasil
Lasaro Camargos, Universidade Federal De Uberlândia, Brasil
Leandro Alves Neves, Unesp De Rio Preto, Brasil
Leandro Tortosa, Universidad De Alicante, Espanha
Lilia Munoz, Universidad Tecnologica De Panama, Panama
Lisandra Manzoni Fontoura, Ufsm, Brasil
Luciana Foss, Universidade Federal De Pelotas, Brasil
Luciana Frigo, Universidade Federal De Santa Catarina, Brasil
Luciano Gonda, Facom/ufms, Brasil
Luciano Jose Senger, Universidade Estadual De Ponta Grossa, Brasil
Luis Enrique Zarate, Pontificia Universidade Catolica de Minas Gerais, Brasil
Manuel E. Acacio Sanchez, Universidad De Murcia, Espanha
Marcelo Da Silva Hounsell, Universidade do Estado de Santa Catarina, Brasil
Marcio Castro, Lig, Ensimag - Montbonnot, Inria, France
Marco Spohn, Uffs, Brasil
Marco Aurelio Wehrmeister, Universidade Tecnologica Federal Do Parana, Brasil
Marcos Fagundes Caetano, Univerisidade De Brasilia, Brasil
Margrit Krug, Unisinos, Brasil
Maria Eugenia Cabello Espinosa, Universidad De Colima, Mexico
Maria Jose Gil, Universidad De Deusto, Espanha
Maria Teresa Alonso Martinez, Universidad De Castilla-la Mancha, Espanha
Mark Alan Junho Song, Pontificia Universidade Catolica de Minas Gerais, Brasil
Marta Arias, Universidad Politecnica De Catalunya, Espanha
Merisandra Garcia, Universidade Do Extremo Sul Catarinense, Brasil
Miguel Serrano Mateos, Universidad Carlos III de Madrid, Espanha
Milton Heinen, Unipampa, Brasil
Milton Romero, Ccet/ufms, Brasil
Nestor Calvo, Universidad Nacional Del Litoral, Argentina
Olatz Arbelaitz, Universidad Del Pais Vasco, Espanha
Pablo Rabanal, Universidad Complutense De Madrid, Espanha
Pablo Rinaldi, Instituto Pladema, Argentina
Patricia Maldonado, Universidad De Magallanes, Chile
Pedro Velho, Ufrgs - Campus Do Vale, Brasil
Rafael Avila, Unisinos, Brasil
Rafael Mayo Garcia, Ciemat, Espanha
Rafael Pasquini, Universidade Federal De Uberlândia, Brasil
Rafael Rieder, Universidade De Passo Fundo, Brasil
Rafael Sachetto, Universidade Federal De São João De Rei, Brasil
Rafael Stubs Parpinelli, Universidade Do Estado De Santa Catarina, Brasil
Rafael Tolosana Calasanz, Universidad De Zaragoza, Espanha
Raimundo Correa De Oliveira, Uea, Brasil
Remo Suppi, Universitad Autonoma De Barcelona, Espanha
Ricardo Ribeiro Dos Santos, Universidade Federal De Mato Grosso Do Sul, Brasil

xiii
 Rivalino Matias Jr, Universidade Federal Da Uberlândia, Brasil
Roberto Willrich, Universidade Federal De Santa Catarina, Brasil
Rodrigo Da Rosa Righi, Universidade Do Vale Do Rio Dos Sinos, Brasil
Rogelio Estrada, Universidad Autónoma De Sinaloa, México
Rogeria De Souza, UNESP/SJRP, Brasil
Rogerio Casagrande, Universidade Do Extremo Sul Catarinense, Brasil
Roseclea Duarte Medina, Universidade Federal De Santa Maria, Brasil
Rosita Wachenchauzer, UBA, Argentina
Sandro Da Silva Camargo, Universidade Federal Do Pampa, Brasil
Silas Evandro Nachif Fernandes, Universidade Estadual Paulista Julio De Mesquita, Brasil
Silvia Nassar, Universidade Federal De Santa Catarina, Brasil
Simone Costa, Universidade Federal De Pelotas, Brasil
Tales Bogoni, Universidade Do Estado De Mato Grosso, Brasil
Valeria Quadros, Universidade Federal De Mato Grosso Do Sul, Brasil
Vicente A. Gonzalez, Universidad Catolica "Nuestra Senora de la Asuncio, Paraguay

xiv
 PALESTRAS CONVIDADAS

SEGURANÇA CIBERNÉTICA: DESAFIOS E OPORTUNIDADES NA

ERA DE CIBERESPIONAGEM

Pelo Professor Mehran Misaghi,

Sociedade Educacional de Santa Catarina (SOCIESC), Brasil

RESUMO

Devido ao grande aumento do uso da Internet, a escassez da informação já não é mais uma
preocupação, como em algumas décadas atrás. Atualmente, o excesso da informação
tornou-se um dos problemas da maior rede mundial. A grande quantidade de informações
permite coletar, classificar e separar essas informações em diversas formas, de acordo com
o interesse de cada camada da sociedade, desde a mais bem intencionada até a mais
maléfica, onde se encontram os cibercriminosos. Uma das formas de combater os
cibercriminosos é por meio do monitoramento minucioso das atividades de qualquer
cidadão que possa ser considerada como suspeito. Diversas agências de inteligência, em
especial NSA, a Agência Nacional de Segurança dos Estados Unidos, têm feito coletas
excessivas de dados para este fim. Este trabalho apresenta algumas formas de coleta,
utilizadas pela NSA, bem como os desafios e oportunidades existentes.

xv
 TENDÊNCIAS NA ÁREA DE COMPUTAÇÃO MÓVEL E UBÍQUA

Pelo Professor Cristiano Costa,

Universidade do Vale do Rio dos Sinos (UNISINOS), Brasil

RESUMO

A área de computação ubíqua (ubicomp) pressupõe uma forte integração com o mundo real,
com foco no usuário e em manter alta transparência. Para o desenvolvimento de aplicações
nesse cenário, são necessárias pesquisas em diversos temas, abrangendo aspectos de
hardware e de software. Nesse âmbito, os tablets e smartphones são os principais
dispositivos empregados hoje em dia e que permitem uma transição para esse cenário.
Através do uso de diversos sensores e da exploração de conceitos como a ciência de
contexto, a adaptação e a interação transparente, os dispositivos móveis têm aproximado as
pessoas da ubicomp. O trabalho proposto, consequentemente, apresenta uma visão atual do
uso da computação móvel e das tendências envolvendo a computação ubíqua.

xvi
 Artigos
Palestras Convidadas
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

SEGURANÇA CIBERNÉTICA:
DESAFIOS E OPORTUNIDADES NA ERA DE
CIBERESPIONAGEM

Mehran Misaghi
Centro Universitário UNISOCIESC – Joinville – SC – Brazil.

RESUMO
Devido ao grande aumento do uso da Internet, a escassez da informação já não é mais uma preocupação, como em
algumas décadas atrás. Atualmente, o excesso da informação tornou-se um dos problemas da maior rede mundial. A
grande quantidade de informações permite coletar, classificar e separar essas informações em diversas formas, de acordo
com o interesse de cada camada da sociedade, desde a mais bem intencionada até a mais maléfica, onde se encontram os
cibercriminosos. Uma das formas de combater os cibercriminosos é por meio do monitoramento minucioso das
atividades de qualquer cidadão que possa ser considerada como suspeito. Diversas agências de inteligência, em especial
NSA, a Agência Nacional de Segurança dos Estados Unidos, têm feito coletas excessivas de dados para este fim. Este
trabalho apresenta algumas formas de coleta, utilizadas pela NSA, bem como os desafios e oportunidades existentes.

PALAVRAS-CHAVE
Crime cibernético, Espionagem, NSA,Segurança cibernética.

1. INTRODUÇÃO
O advento da Internet revolucionou o cotidiano de tal modo que atualmente não se faz nada independente.
Consequentemente, todas as ações são registradas na maior rede mundial, quer seja onde o indivíduo esteja,
com que ferramenta esteja se comunicando, o que esteja falando e com quem esteja conversando. Diversos
aplicativos traçam os perfis de usuários através de coleta de informações preferenciais para, de forma
legítima, direcionar e potencializar o comércio, via Internet.
No entanto, existem outros interesses nem sempre legítimos. A coleta de informação pode ser bastante
útil para qualquer tipo de atacante em potencial no espaço cibernético e servir para fins de cibercrime e
ciberespionagem . O projeto da norma NBR ISO/IEC 27032:2013, define o espaço cibernético como sendo
um ambiente complexo, no qual, há interação entre pessoas, serviços e aplicativos na Internet por diversos
meios. Tais interações inexistem em qualquer forma física . O mesmo projeto da norma, também define o
crime cibernético (ou cibercrime) como “atividade criminal em que serviços ou aplicativos no espaço
cibernético são usados para ou são alvo de um crime, ou em que o espaço cibernético é a fonte, ferramenta,
alvo, ou local de um crime ” (ABNT, 2013).
Conforme Berghel (2013), no mês de junho de 2013, veio a tona o dilema sobre as atividades de
espionagem via diversas agências de inteligência, em especial NSA. As revelações do delator Edward
Snowden levam as diversas questões, como por exemplo, o que está de fato sendo vigiado? Como as
empresas e as nações devem reagir? Este artigo apresenta um breve histórico sobre diversas tentativas
realizadas pela NSA, bem como os desafios e oportunidades existentes.

3
ISBN: 978-972-8939-96-0 © 2013 IADIS

2. A ESPIONAGEM NA INTERNET

2.1 A Espionagem Industrial

A atividade da espionagem é considerada a segunda profissão mais antiga do mundo, conforme Benny
(2014), que define a espionagem industrial como sendo roubo de segredos comerciais pela remoção, cópia ou
gravação de vigilância técnica das informações confidenciais, protegidas por uma empresa para uso por um
concorrente ou uma nação estrangeira. Presidente Reagan, na sua fala de 30 de novembro de 1985, se
referencia a espionagem como uma luta que deve-se ganhar, se quiser proteger a liberdade e o modo de vida.
A espionagem industrial não é somente a perda de informações protegidas que pode ser utilizada por
outra organização ou por uma outra nação. Se trata de tempo investido na criação de documentos, o valor que
alguém pode pagar por tais informações ou documentos, ou a perda de receita que uma organização poderá
sofrer, se uma organização concorrente for capaz de trazer um novo produto para mercado por causa de tal
atividade . Existem cinco condições para espionagem industrial: Causa, Habilidade, Racionalização, Gatilho
e Oportunidade (BENNY, 2014).
2.1.1 Causa
Para contrariar a espionagem industrial é importante compreender as razões de indivíduos que fazem parte de
tal atividade criminosa. Existe uma variedade de causas, como por exemplo, monetária, vingança, uma visão
religiosa, social ou política. A causa mais comum é dinheiro.
2.1.2 Habilidade
A pessoa que faz parte desta atividade deve ter comportamento criminoso de tal forma, que possa ser capaz
de superar alguns inibidores naturais. Esta pessoa deve deixar de lado os valores morais, lealdade para nação
ou empregador, e a maioria dos medos a ser descoberta.
2.1.3 Racionalização
Consiste em habilidade dos autores de espionagem justificarem para eles mesmo, a razão pela qual, a
espionagem industrial de fato não é errada. A justificativa pode concluir que a espionagem era por uma boa
causa, porque sustenta suas visões ideológicas ou políticas. Se a espionagem é feita por causa de dinheiro, a
racionalização pode ser a empresa possa arcar com a perda.
2.1.4 Gatilho
Muitas coisas podem desencadear a traição que causa um indivíduo fazer parte de espionagem industrial. Em
alguns casos ele participa de espionagem para obter mais fundos para ter um estilo de vida extravagante, ou
consumo elevado de drogas e bebidas alcoólicas. Em outros casos, a pressão pode ser relacionada com à
adesão a grupos criminosos, terroristas e ideológicas que procuram por informações protegidas que o
indivíduo tem acesso.
Tais situações fornecem a base para recrutamento de indivíduos incluindo funcionários orientadas por
concorrentes ou governos estrangeiros.
2.1.5 Oportunidade
É circunstância, na qual, o indivíduo tem acesso as informações protegidas e sente que pode utilizar e roubar
a informação sem ter consequências. Atualmente qualquer brecha de segurança da informação, como por
exemplo, uma lacuna nos controles internos, supervisão, treinamento, e auditoria cria atmosfera ideal, onde
as pessoas têm acesso às informações protegidas. A ocorrência de brecha de segurança, falta de uma
investigação adequada e falta uma medida disciplinar para o causador encoraja as pessoas que querem fazer
parte da espionagem industrial.

4
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

A figura 1 apresenta as condições, nas quais a espionagem industrial ocorre.

Figura 1. Condições para Espionagem Industrial

Os governos costumam utilizar o temo de “Agência de Inteligência” no lugar de “espionagem” e
justificam a existência das diversas agências de inteligência para monitorar possíveis ameaças à soberania
das nações.

2.2 Agência de Segurança Nacional dos EUA – NSA

Conforme Burns (1990), logo após a Segunda Guerra Mundial, diversas estruturas militares de inteligência
americana tais como, Central Intelligence Agency (CIA), Defense Intelligence Agency (DIA), National
Foreign Intelligence Board (NFIB), Federal Bureau of Investigation (FBI), serviços militares, diversos
departamento como Departamento de Tesouro, Departamento de Estado, Departamento de Energia e
Departamento de Comércio, todos envolvidos em atividades de inteligência trabalham desde início de 1930
para estabelecer uma central única de inteligência. Desta forma, a NSA se estabeleceu em 1952.
A proposta da criação de NSA foi desenvolver sistemas criptográficos para governo americano além do
intuito de espionagem de comunicações entre outros países. Diversas fontes confirmam que a amplitude e a
profundidade de vigilância do governo americano tem aumentado e diversificado em muitas décadas. O
gráfico 1 apresenta diversos artefatos utilizados pelo NSA para fins de espionagem (BERGHEL, 2013).

5
ISBN: 978-972-8939-96-0 © 2013 IADIS

Gráfico 1. Artefatos utilizados pela NSA

2.2.1 NSA em Números

Depois de rumores de espionagem, conforme Jarfis (2013), a NSA comentou que apenas “toca” em 1,6% de
tráfego diário de Internet. Se, como dizem, a rede transporta 1.826 petabytes de informação por dia, então a
NSA “toca” aproximadamente 29 petabytes por dia, sem dizer o que significa o “toque” nos dados. Analisar?
Armazenar?
Jarfis (2013), faz comparativo com Google, que em 2010 tinha indexado somente 0,004% de dados da
Internet. Desta forma, pode se concluir que NSA seria 400 Googles? Na mesma analogia, sete petabytes de
dados são mensalmente adicionados ao Facebook. Assim, NSA seria 126 Facebook.

2.3 PRISM
James Clapper, diretor de Inteligência Nacional dos EUA explica que, PRISM não é uma coleção de
informações reservadas ou programa de mineração de dados. Consiste em um sistema interno do governo
para facilitar a coleta das informações legalmente autorizadas de inteligência estrangeira, a partir de
prestadores de serviços de comunicações eletrônicas, sob supervisão judicial, conforme autorizado pelo
artigo 702 da Lei de Vigilância de Inteligência Estrangeira (FISA). Esta autoridade foi criada pelo Congresso
americano e tem sido amplamente conhecido e discutido publicamente desde a sua criação em 2008
(CLAPPER, 2013).

6
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Por outro lado, após vazamento de informações sobre espionagem americana e em especial, o PRISM,
surgiram diversas fontes que de forma detalhada apresentam programa de coleta de dados de PRISM, como
por exemplo, Poulsein (2013), Gellman (2013), Eaton (2013), Risen e Poitras (2013), Berghel (2013), entre
outras fontes. A figura 2, baseada em diversas fontes, apresenta de forma simples o que PRISM coleta e as
respectivas datas de adesão de diversos prestadores de serviços.

Figura 2. Início de coleta de dados em diversos prestadores de serviços via PRISM

Conforme a figura 2, o maior interesse de coleta de dados via PRISM consiste em mineração de dados de
emails, chats, vídeos, fotos, vídeo conferência e o comportamento do indivíduo nas redes sociais.

7
ISBN: 978-972-8939-96-0 © 2013 IADIS

2.4 Para Onde Vamos?

Com a recente exposição de PRISM, conservadores fiscais e neoliberais falam de "big governo", não
somente no sentido de abrangência e tamanho do orçamento, mas também no que se refere a grau de controle
que o governo exerce sobre os seus cidadãos. A partir disso, Berghel (2013), faz algumas previsões para
futuro:
1. Em 2014, Datacenter de UTAH estará completa, com capacidade planejada de 5 exabytes (10 18
bytes). Desta forma, NSA terá mais poder para mineração de dados e não ficaria mais limitada.
2. O governo americano continuará a terceirizar a vigilância e as atividades de coleta de informações,
especialmente para algumas empresas que são ainda menos sujeitas à supervisão parlamentar e
judicial como por exemplo, HBGary Federal / ManTech, Gamma Group, STRATFOR, e assim por
diante.
3. O Congresso americano continuará a manipular diversos estatutos para assegurar a ilusão da
transparência da informação.
4. Os políticos vão aproveitar a oportunidade da cobertura da mídia, para prevalecer as suas opiniões.
5. O governo vai continuar a sua perseguição agressiva de delatores, vazadores e jornalistas para
causar medo em pessoas contraditórias de qualquer faixa etária.
6. Jornalismo continuará a ser distraído de diversas questões importantes.

3. A ESPIONAGEM NO BRASIL
Estima-se que uma grande quantidade de brasileiros sejam alvos de espionagem de NSA nos últimos anos.
Segundo as revelações de Snowden, uma das estações de espionagem da NSA através da CIA funcionou em
Brasília até 2002. Logo após, veio na tona o assunto da espionagem da presidente Dilma Roussef no início de
setembro de 2013. A reportagem do Fantástico no dia 08/09/2013, apresentou documentos que confirmam,
que a maior empresa brasileira, a Petrobras, também foi alvo de espionagem do NSA (FANTÁSTICO,
2013a).
A Petrobras, a empresa com faturamento anual de aproximadamente 280 bilhões , maior do que a
arrecadação de muitos países. Não se sabe o que exatamente foi espionado neste caso. Mas, a Petrobras
possui conhecimento estratégico associado a negócios que envolvem bilhões de reais, comenta a reportagem
do Fantástico (2013a). Por exemplo, detalhes de leilão do Campo de Libra, sendo o maior leilão da história
do petróleo, detalhes de cada lote marcado para mês de outubro de 2013, para exploração do Campo de
Libra, parte do pré-sal. A pergunta crucial é: Será que os espiões tiveram acesso a esses dados?
Outros documentos disponibilizados pelo Snowdwn e apresentados na reportagem do dia 06/10/2013 no
programa de Fantástico afirmam que o Ministério de Minas e Energia foi alvo de espionagem canadense.
Através de um aplicativo chamado Olympia, que faz um mapeamento das comunicações telefônicas e de
computador do ministério, incluindo e-mails, é possível descobrir os contatos realizados para outros órgãos,
dentro e fora do Brasil, além de empresas como a Petrobras e a Eletrobrás. Desta forma, é fácil notar o
registro de ligações telefônicas feitas do Ministério para outros países, como o Equador, com chamadas
frequentes para a Organização Latino-Americana de Energia. Esta ferramenta consegue também identificar
números de celulares, marcas e modelos dos aparelhos utilizado (FANTÁSTICO, 2013b).

3.1 Segurança Cibernética no Brasil

Brasil ainda não possui regras específicas para tratamento da espionagem e segurança cibernética. Contudo,
estão sendo feitos uma série de esforços para esta finalidade. As regras a serem propostas incluem uma
versão complementar da Lei da Carolina Dieckmann que abordará os crimes na Internet. Além disso, um
projeto da Lei que aborda o Marco Civil na Internet com a participação popular, para definir direitos e
deveres na Internet. Tais projetos estão na fase de tramitação e votação.

8
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Conforme Freitas (2011), a consolidação do setor cibernético na defesa brasileira ocorre através de
Conselho De Defesa Nacional (CDN), Câmera de Relações Exteriores e Defesa Nacional(Creden), Casa
Civil da Presidência da República, Gabinete de Segurança Institucional da Presidência da República (GSI-
PR), Departamento de Segurança da Informação e Comunicações (DSIC) e Agência Brasileira de
Inteligência (Abin).

3.2 Desafios do Setor Cibernético no Âmbito da Defesa

Conforme Freitas (2011), A realização das ações estratégicas previstos para a segunda fase na Diretriz
Ministerial no 014/2009, constitui o grande desafio à Consolidação do Setor Cibernético na Defesa. Alguns

 Assegurar o uso efetivo do espaço cibernético pelas Forças Armadas e

desafios do setor cibernéticos são:

 Capacitar e gerir talentos humanos para a condução das atividades do setor cibernético na defesa;
impedir ou dificultar sua utilização contra interesses da defesa nacional;

 Desenvolver e manter atualizada a doutrina de emprego do setor cibernético;

 Adequar as estruturas das Forças Armadas e implementar atividades de pesquisa e desenvolvimento

 Cooperar com o esforço de mobilização militar e nacional para assegurar as capacidades operacional
para o setor cibernético;

e dissuasória do setor cibernético

4. BOAS PRÁTICAS DE SEGURANÇA

A NSA pode até ter quebrado esquemas criptográficos e incluído diversos mecanismos de acessos ocultos,
mas os negócios devem sempre enfatizar e focar as práticas de segurança da informação. Uma das iniciativas
do governo brasileiro é o decreto que vai obrigar uso de novo e-mail desenvolvido pelo Serviço Federal de
Processamento de Dados (Serpro) em todo o governo, e desta forma dificultar ao máximo as atividades de
espionagem nas correspondências eletrônicas do governo (AMATO, 2013).
Como recomendações gerais seguem algumas ideias:
1. Rever toda a política de informação com foco em atividades internas, registro de atividades e
auditorias periódicas para verificar a existência de brechas de segurança, conforme novos projetos
de normas NBR ISO/IEC 27001, 27002, 27032 e 27037.
2. A criptografia continua sendo a melhor solução. É indispensável que os dados sensíveis e
confidenciais sejam cifrados com algum sistema criptográfico forte. No ponto de visto de segurança,
sempre existe possibilidade de interceptação. Caso isto ocorra, o invasor ficará frustrado, se o dado
interceptado já é cifrado com algum esquema de criptografia forte.
3. Rever todos os protocolos utilizados na sua rede. Somente utilize protocolos seguros que permitem
encapsulamento e navegação mais segura do que os protocolos tradicionais.
4. Utilize e implemente as premissas de segurança lógica através de sistemas criptográficos na sua
rede: confidencialidade, autenticidade, irretratabilidade e integridade,
5. Não utilize programas comerciais de terceiros para comunicação de informações sensíveis.
Desenvolva a seu programa personalizado de comunicação, a partir de programa de fonte aberta
para incrementar o que é necessário e saber o que de fato, se passa pelo programa.

5. CONCLUSÃO
O presente artigo, de forma sucinta, apresentou os conceitos, condições e motivações de espionagem que
atualmente atormenta diversas nações. Foram também apresentados alguns detalhes de ferramentas de
espionagem de NSA. A preocupação com a segurança da informação não se deve somente à possibilidade de
coleta indevida de dados. É um momento oportuno para que as nações e as organizações verifiquem as suas
ações e políticas de segurança da informação atualmente em vigência. A atualização da política de segurança
da informação não é modismo e sim algo vital.

9
ISBN: 978-972-8939-96-0 © 2013 IADIS

REFERÊNCIAS
ABNT. Projeto da NBR ISO/IEC 27001:2013. Tecnologia da Informação – Técnicas de Segurança – Sistemas de gestão
da segurança da informação - Requisitos. Associação Brasileira de Normas Técnicas, 28/08/2013.
ABNT. Projeto da NBR ISO/IEC 27002:2013. Tecnologia da Informação-Técnicas de Segurança – Código de Prática
para controles de segurança da informação. Associação Brasileira de Normas Técnicas, 28/08/2013.
ABNT. Projeto da NBR ISO/IEC 27032:2013. Tecnologia da Informação – Técnicas de segurança – Diretrizes para
segurança cibernética. Associação Brasileira de Normas Técnicas, 28/08/2013.
ABNT. Projeto da NBR ISO/IEC 27037:2013. Tecnologia da Informação – Técnicas de Segurança – Diretrizes para
identificação, coleta, aquisição e preservação de evidência digital. Associação Brasileira de Normas Técnicas,
28/08/2013.
AMATO, Fabio, 2013. Decreto vai obrigar uso de novo e-mail em todo o governo, diz ministro. Disponível em
<http://g1.globo.com/politica/noticia/2013/10/decreto-vai-obrigar-uso-de-novo-e-mail-em-todo-o-governo-diz-
ministro.html>, 14/10/2013.
BENNY, Daniel J., 2014. Industrial Espionage: Developing a Counterespionage Program. CRC Press, Taylor & Francis
Group, NY, 2014.
BERGHEL, Hal, 2013. Through the PRISM Darkly. Computer: v. 46, issue 7, p.86-90. IEEE Computer Society. ISSN :
0018-9162
BURNS, Thomas L., 1990. The Origins of the National Security Agency. Centre for Cryptologic History, 1990.
CARVALHO, Jailton, 2013. Dilma determina ao Serpro reforço na segurança do sistema de e-mails do governo.
Dsisponível m http://oglobo.globo.com/pais/dilma-determina-ao-serpro-reforco-na-seguranca-do-sistema-de-do-
governo-10353980.htm>, 13/10/2013.
CLAPPER, James, 2013. Facts on the Collection of Intelligence Pursuant to Section 702 of the Foreign Intelligence
Surveillance Act. Disponível em <http://www.wired.com/images_blogs/threatlevel/2013/06/PRISM-FAQ.pdf>,
08/06/2013.
EATON, Joshua, 2013. Timeline of Edward Snowden's revelations. Disponível em
<http://america.aljazeera.com/articles/multimedia/timeline-edward-snowden-revelations.html>, 29/06/2013.
FANTÁSTICO, 2013a. Petrobras foi espionada pelos EUA, apontam documentos da NSA. Edição do Programa exibido
no dia 08/09/13 .Disponível em <http://g1.globo.com/fantastico/noticia/2013/09/petrobras-foi-espionada-pelos-eua-
apontam-documentos-da-nsa.html>
FANTÁSTICO, 2013b. Ministério de Minas e Energia foi alvo de espionagem do Canadá. Edição do programa exibio no
dia 06/10/2013. Disponível em <http://g1.globo.com/politica/noticia/2013/10/ministerio-de-minas-e-energia-foi-alvo-
de-espionagem-do-canada.html>
FREITAS, W. L., 2011. Desafios estratégicos para segurança e defesa cibernética
. Secretaria de Assuntos Estratégicos da Presidência da República, 2011
GELLMAN, Barton, 2013. NSA slides explain the PRISM data-collection program. Disponível em
<http://www.washingtonpost.com/wp-srv/special/politics/prism-collection-documents/>, 10/07/2013.
JARFIS, Jeff. NSA by numbers, 2013. Dipsonível em <http://buzzmachine.com/2013/08/10/nsa-by-the-numbers/>.
Acesso em 02/10/2013.
POULSEIN, Kevin, 2013. What’s in the Rest of the Top-Secret NSA PowerPoint Deck? Disponível em
<http://www.wired.com/threatlevel/2013/06/snowden-powerpoint/?viewall=true>, 10/06/2013.
RISEN, J.; POITRAS, L., 2013. N.S.A. Gathers Data on Social Connections of U.S. Citizens. Disponível em
<http://www.nytimes.com/2013/09/29/us/nsa-examines-social-networks-of-us-citizens.html?pagewanted=all&_r=3&
>, 28/09/2013.

10
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

TENDÊNCIAS NA COMPUTAÇÃO MÓVEL E UBÍQUA

Cristiano André da Costa

Programa de Pós-Graduação em Computação Aplicada – PIPCA - Universidade do Vale do Rio dos Sinos – UNISINOS,
São Leopoldo, Brasil

RESUMO
A área de computação ubíqua (ubicomp) pressupõe uma forte integração com o mundo real, com foco no usuário e em
manter alta transparência. Para o desenvolvimento de aplicações nesse cenário, são necessárias pesquisas em diversos
temas, abrangendo aspectos de hardware e de software. Nesse âmbito, os tablets e smartphones são os principais
dispositivos empregados hoje em dia e que permitem uma transição para esse cenário. Através do uso de diversos
sensores e da exploração de conceitos como a ciência de contexto, a adaptação e a interação transparente, os dispositivos
móveis têm aproximado as pessoas da ubicomp. O trabalho proposto, consequentemente, apresenta uma visão atual do
uso da computação móvel e das tendências envolvendo a computação ubíqua.

PALAVRAS-CHAVE
Computação Ubíqua, Computação Móvel, Ciência de Contexto, Dispositivos Móveis, Sistemas Distribuídos.

1. INTRODUÇÃO
A computação ubíqua (ubicomp) é um paradigma que já está completando cerca de 15 anos de existência. A
proposta, introduzida por Weiser (1991), consiste na ideia de que o computador se integre ao nosso dia a dia,
de tal forma que a sensação das pessoas é que ele desaparece. Para atingir tal visão, é necessária uma alta
integração da tecnologia com o ambiente, aliado a um alto grau de automatização e pró-atividade nos
softwares desenvolvidos (COSTA, 2008). Apesar dos vários anos de existência do conceito de ubicomp e dos
diversos trabalhos científicos na área, apenas mais recentemente surgiram dispositivos móveis com
capacidade de suportar aplicações que englobem essas ideias. Esses dispositivos, que hoje são
majoritariamente representados por tablets e smartphones, se caracterizam por possuírem uma autonomia de
bateria que permite um período mínimo de uso e também um alto grau de conectividade, seja através das
redes sem fio ou da rede de telefonia celular.
Apesar da evolução da área de computação móvel, muitos recursos ainda são limitados, tais como largura
de banda da rede sem fio, tempo de vida da bateria, tamanho da tela, dentre outros. Além disso, muitas vezes,
o software que carregamos no dispositivos móvel não é muito diferente daquele que usamos nos
computadores tradicionais. Geralmente ocorrem mudanças na interface e redução nas funcionalidades
disponibilizadas. De acordo com SATYANARAYANAN (1996) computação móvel é caracterizada por

 Elementos móveis são pobres em recursos se comparados a elementos estáticos:

quatro restrições principais:

considerações como peso, energia, tamanho e ergonomia penalizam os recursos

disponibilizados pelo dispositivo móvel, tais como velocidade de processamento, quantidade de
memória e capacidade de armazenamento. Apesar da constante evolução nos dispositivos
móveis, eles sempre serão piores em termos de recursos do que os dispositivos computacionais


estáticos;
Mobilidade é inerentemente mais perigosa: é muito mais fácil o furto ou roubo de um
dispositivo móvel do que o de um computador pessoal. Pelo fato de usarmos os dispositivos
móveis em todos os lugares, ficamos sujeitos aos riscos inerentes dessa ação. Além das

 Conectividade sem fio é altamente variável em desempenho e confiabilidade: Alguns

preocupações com segurança, dispositivos móveis são mais vulneráveis a perda ou dano;

espaços podem suportar redes sem fio de alta velocidade com um certo grau de confiabilidade,

11
ISBN: 978-972-8939-96-0 © 2013 IADIS

porém isso não é ainda universal. A variabilidade na qualidade de serviço oferecida pelas redes
sem fio é muito grande, principalmente nos ambientes externos. Nesse caso, é comum o uso de

 Elementos móveis se baseiam em uma fonte finita de energia: enquanto a tecnologia de

redes de baixa velocidade e locais sem cobertura nenhuma;

bateria irá evoluir no decorrer do tempo, a necessidade de ser sensível ao consumo de energia
não vai diminuir. A preocupação com economia de energia deve estar em muitos níveis do
projeto, tanto do software quanto do hardware.
Recentemente, o mesmo autor (SATYANARAYANAN, 2011), revisitou as restrições propostas em 1996
e concluiu que as mesmas são validas nos dias atuais. Satyanarayanan (2011) acrescenta que os desafios da
computação móvel levam a uma filosofia de projeto denominada “canivete suíço”: tentar espremer o máximo
de funcionalidade possível em um projeto compacto que é alto-contido e tão frugal quanto possível no
consumo de recursos. Infelizmente, essa característica geralmente compromete usabilidade, assim como as
ferramentas em um canivete suíço real (como faca, garfo, abridor de latas, saca-rolhas) são substitutos pobres
as implementações de tamanho real (SATYANARAYANAN, 2011). Telas minúsculas e teclados são
especialmente desafiadores para usuários móveis. Além disso, a um incentive do Mercado atual a valorizar a
quantidade de funcionalidade disponibilizada ao invés das inovações para atributos mais difusos como a
usabilidade.
Outo ponto a considerar que é diretamente ligada a usabilidade é a interface. Ela deve considerar a forma
mais natural de interação para os dispositivos específicos, e também informação contextual (como a
localização) e comportamento dos usuários (preferencias, necessidades, história, etc.) (COSTA, 2009). Por
exemplo, reconhecimento de voz é uma das melhores interfaces para telefones celulares porque eles tem telas
pequenas, botões diminutos e são otimizados para comunicação por voz (CANNY, 2006).
Apesar dos limites da computação móvel, e considerando os avanços recentes, torna-se mais factível o
desenvolvimento da área de ubicomp. Nesse cenário, o presente artigo tenta explorar as tendências atuais
relacionadas com a área e com os principais conceitos envolvidos. A principal contribuição científica do
artigo é delinear os limites atuais, bem como as tecnologias e modelos disponíveis para o crescimento da
ubicomp. No trabalho são detalhados os principais conceitos da área, bem como as principais soluções para
endereçar tais questões.
O artigo está organizado em 4 seções. A seção 2 define os principais conceitos da área, incluindo os
principais desafios para serem endereçados. Na seção 3 é feito um destaque de diversas tecnologias
disponíveis hoje em dia que se alinham as necessidades da ubicomp, bem como tendências futuras na área.
Por fim, a seção 4, traça as conclusões do trabalho.

2. PRINCIPAIS CONCEITOS DA ÁREA DE UBICOMP

Essa seção apresenta os principais conceitos da área de computação ubíqua. Inicialmente é detalhada a
computação móvel, principal evolução que permitiu o desenvolvimento da ubicomp. O conceito de
ubiquidade é introduzido na próxima subseção. Por fim, a última subseção apresenta os principais desafios da
área.

2.1 Computação Móvel

Computação móvel pode ser resumida como “Informação nas pontas dos dedos a qualquer momento e de
qualquer lugar” (SATYANARAYANAN, 2011). Grandes inovações em áreas como tecnologias de rede sem
fio, eficiência de energia e software cada vez mais adaptado aos dispositivos móveis tem tornado esse
paradigma uma realidade.
A computação móvel surge do avanço em duas grandes áreas: redes sem fio e dispositivos portáteis. Com
esses dispositivos o usuário pode acessar a informação de qualquer lugar, independentemente da localização
física ou do seu deslocamento (JING et al., 1999). A diferença em relação à computação tradicional é que os
serviços disponibilizados pelos sistemas de informática acompanham as pessoas e tornam-se mais presentes,
fornecendo capacidades expandidas. Essas capacidades disponibilizadas através de serviços, e combinadas
com o acesso a rede, transformam a computação em uma atividade que pode ser carregada (COSTA, 2009).

12
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

As possibilidades geradas pelo desenvolvimento da computação móvel, definem o cenário para que a
computação ubíqua se desenvolva. Esse conceito é detalhado na próxima subseção.

2.2 Computação Ubíqua

No clássico e visionário artigo sobre computação para o século 21, Mark Weiser (WEISER, 1991) resume o
que é esperado da computação ubíqua (também chamada de ubicomp): acesso do usuário ao ambiente
computacional, de todo lugar e a todo momento, por meio de qualquer dispositivo. A dificuldade reside em
como desenvolver aplicativos que irão continuamente se adaptar ao ambiente e continuar funcionando, a
medida que as pessoas se movem ou trocam de dispositivos (GRIMM et al., 2004).
Mark Weiser criou o termo computação ubíqua (também chamada de ubicomp) e é considerado um dos
fundadores da área. Ele apresentou a ubiquidade computacional como a ideia de integrar computadores de
forma transparente, aprimorando o mundo real. Weiser (WEISER, 1991) formula uma "nova forma de pensar
em computadores no mundo, uma que considera o ambiente natural do ser humano e permite que os
computadores desapareçam no entorno" (p. 94). Computadores irão desaparecer como uma consequência da
psicologia humana: quando as pessoas usam objetos sem a efetiva consciência do ato, elas focam além. Esse
é um fenômeno definido por alguns filósofos e psicólogos (WEISER, 1991): pessoas deixam de estar ciente
de algo quando elas usam um objeto suficientemente bem e frequentemente. O filosofo Heidegger designa
esse fenômeno Manualidade (Vorhandenheit no original) e Edmund Husserl denomina Horizonte (Horizont
no original).
Heidegger faz uma análise fenomenológica da forma como as pessoas lidam com o mundo. De acordo
com ele, nosso primeiro comportamento com entidades tais como ferramentas, dispositivos e sistemas no
mundo é a de uso. Essas entidades, vistas do aspecto do uso, estão disponíveis e fazem parte de um modo de
ser descrito por Heidegger como Manualidade (HEIDEGGER, 1996).
Edmund Husserl foi o primeiro a propor o conceito de Horizonte (KEEN, 1975). Husserl era um filósofo,
um dos fundadores da fenomenologia, e um matemático. O conceito refere à experiência humana como pano
de fundo para tornar as experiências possíveis. Horizonte aponta para uma rede de mecanismos conhecidos
focando não tanto nos objetos físicos, mas em um padrão ordenado que nós formulamos implicitamente no
nosso ato de ser (KEEN, 1975).
Para obter a integração física dos computadores no mundo, como pano de fundo, é necessário aplicar
algumas mudanças conceituais. Nessa perspectiva, Weiser também define um termo denominado virtualidade
personificada (embodied virtuality) em oposição a idéia de realidade virtual, uma vez que computadores não
podem ficar limitados aos dispositivos e softwares instalados. Além disso, é inadequado considerar a Internet
ou acesso a sistemas de arquivos distribuídos como exemplos de integração transparente. Weiser aponta
ainda que o poder da computação ubíqua não advém da capacidade de dispositivos específicos, mas sim da
interação entre diversos dispositivos.
Analisando a visão de Weiser, em (SAHA e MUKHERJEE, 2003) os autores afirmam que, apesar dos
significantes desenvolvimentos no hardware, computadores ainda são máquinas que executam programas em
ambientes virtuais e não são um portal para um espaço de aplicações e dados. Os autores de (WANT et. al,
2002) concordam que muitos componentes de hardware estão prontos para a computação ubíqua, como
consequência de diversas melhorias desde o artigo seminal do Weiser, incluindo redes sem fio, processadores
com alto desempenho e baixo consumo de energia, melhorias nas telas, alta capacidade e dispositivos de
armazenamento com pouca necessidade de energia.
Para a computação ubíqua seja uma realidade, é necessário avanços na integração física e na
interoperação espontânea, como definido por (KINDBERG e FOX, 2002). Integração entre dispositivos e o
mundo físico é crucial. A medida que os componentes se movem entre dispositivos e ambientes, eles devem
alterar tanto a identidade quanto a funcionalidade se adaptando de forma a melhor interoperar.
É necessário entender e suportar as práticas das pessoas no dia-a-dia para atingir a visão proposta por
Weiser, oferecendo diferentes formas de experiências interativas através de dispositivos heterogêneos
conectados via rede. Entretanto, muitos desafios se mantém hoje em dia. Eles são discutidos na próxima
subseção.

13
ISBN: 978-972-8939-96-0 © 2013 IADIS

2.3 Principais Desafios da Computação Ubíqua

Alguns desafios devem ser endereçados para atingir a computação ubíqua, como proposta por Weiser. A
Tabela 1 resume os principais desafios, apresenta as áreas em que eles ganham foco e os motivos principais
no escopo da ubicomp (COSTA, 2008).
Tabela 1. Resumo dos principais desafios da computação ubíqua.

Característica Área Foco Motivo

Diferentes tipos de dispositivos,
Heterogeneidade Sistemas Distribuídos
redes, sistemas,...
Larga escala, aumento no número
Escalabilidade Sistemas Distribuídos
de dispositivos.
Sistemas Distribuídos e de Evitar defeitos mais freqüentes ou
Dependability e Segurança
Missão Crítica severos do que o aceitável.
Internet e Proteger dados pessoais. Garantir
Privacidade e Confiança
Computação Móvel a confiança dos componentes.
Permitir a associação e a
Interoperação Espontânea Computação Móvel
interação.
Acesso de qualquer lugar, em
Mobilidade Computação Móvel
qualquer tempo.
Perceber contexto, inferir intençã
Sensibilidade ao Contexto Computação Móvel
e detectar mudanças.
Ajustar ambiente em resposta a
Gerência de Contexto Computação Móvel
informação percebida.
Fundir interface do usuário com
Interação Transparente com o Usuário Computação Ubíqua
mundo real. Focar na interação.
Permitir que computadores
Invisibilidade Computação Ubíqua
desapareçam no entorno.

Heterogeneidade é um desafio derivado de sistemas distribuídos. Aplicativos devem ser capaz de executar
em diferentes tipos de dispositivos, com vários sistemas operacionais e interfaces com o usuário. Software
deve mascarar as diferenças de infraestrutura para o usuário e gerenciar as necessárias conversões de um
ambiente para o outro. Como resultado, é necessário tratar diferenças de protocolos. Nesse cenário, não é
possível recriar software específico para cada dispositivo. Consequentemente, a lógica dos aplicativos deve
ser criada apenas uma vez com uma abordagem independente de dispositivo.
Outro desafio relacionado, herdado de sistemas distribuídos, é escalabilidade. Na ubicomp, um grande
número de usuários, dispositivos, aplicações e comunicações são esperados em uma escala sem precedentes.
Além disso, seria impraticável distribuir e instalar aplicativos explicitamente. É necessário evitar soluções
centralizadas para obter uma melhor escalabilidade e prevenir gargalos. Por fim, interações mais distantes
devem ser reduzidas ao mínimo necessário.
Algumas vezes, o sistema não consegue executar de acordo com a especificação funcional.
Adicionalmente, podem ocorrer problemas relacionados com erros de especificação e de implementação.
Essas situações levam a falhas. Uma falha é definida como a transição de um serviço correto para um serviço
incorreto (AVIZIENIS, 2004). Um serviço correto é obtido quando o sistema implementa a função desejada.
Serviço incorreto deve ser detectado e a execução restaurada para o estado correto. Evitar falhas que são mais
frequentes e mais severas do que o aceitável leva a dependability, um conceito que integra os atributos de
disponibilidade, confiabilidade, segurança crítica (safety), integridade e facilidade de manutenção. O termo
pervasive dependability tem sido usado para referir a essas necessidades no escopo da ubicomp (FETZER e
HÖGSTEDT, 2002).
Segurança é um conceito estritamente relacionado com a dependability de um sistema. Um sistema é
considerado seguro se existem medidas que garantem disponibilidade, integridade e confidencialidade.
Existem muitos mecanismos para fornecer segurança em sistemas distribuídos que podem também ser
usados na ubicomp. Entretanto, essas ações devem ser leves, preservando tanto a espontaneidade da interação
quanto as limitações de alguns dispositivos, no provimento de segurança para recursos e dados do usuário
(COULOURIS, 2012).

14
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

A privacidade dos dados desse usuário é uma questão a tratar. A medida que a ubicomp tornar-se parte da
vida cotidiana, dispositivos praticamente invisíveis vão coletar informações do usuário, incluindo dados
pessoais, sem nem mesmo serem notados. Garantir formas pelas quais essa informação possam ser usadas ou
transferidas de maneira privada será extremamente difícil.
Outro conceito associado é confiabilidade (trust). Em um cenário altamente heterogêneo e dinâmico, a
confiança em componentes para interação deve ser medida. Uma vez que não existe uma infraestrutura fixa e
nem um domínio específico, é necessário usar um sistema gerenciador de confiança para medir o que deve
ser exposto aos demais componentes (ROBINSON, 2005).
Integrar componentes variados disponíveis em vários dispositivos, bem como fazer a comunicação e o
entendimento entre eles possível, é um desafio identificado como interoperação espontânea. Um componente
interopera espontaneamente se ele "interage com um conjunto de componentes de comunicação que podem
alterar tanto a identidade quanto a funcionalidade ao longo do tempo, a medida que as circunstâncias
mudam" (KINDBERG e FOX, 2002). Essa espontaneidade é necessária por causa da natureza volátil da
ubicomp. Os componentes estão em movimento e interagindo com um conjunto de serviços que mudam
constantemente.
Outro desafio, denominado mobilidade, possibilita o acesso às aplicações e aos dados onde quer que o
usuário esteja independentemente do deslocamento. Isso porque em dispositivos portáteis, tais como
smartphones e notebooks, o ambiente computacional costuma acompanhar o usuário. Entretanto, mobilidade
física (de equipamentos ou de usuários) não é a única opção. Mover componentes como aplicações, dados e
serviços (mobilidade lógica) também é desejável. Hoje em dia, muitos desses componentes estão vinculados
a dispositivos específicos, dificultando que o usuário carregue esses componentes. Aplicações devem mover-
se de um dispositivo para outro, e o acesso aos dados deve ser mantido (aplicações estilo siga-me) (COSTA,
2008).
A computação móvel também introduziu a ideia de sensibilidade ao contexto, isto é, detectar informações
que caracterizam a situação de entidades nas aplicações. Essas entidades são pessoas, lugares ou objetos que
são consideradas relevantes em determinada circunstância (DEY, 2001). Para obter as informações de
contexto geralmente são usados sensores ou outros dispositivos que usam computação embarcada. O
emprego dessas informações relativas às entidades nas aplicações gera o que é denominado de software
sensível ao contexto, algo que se torna cada dia mais comum nos smartphones.
O ato de uma aplicação responder as informações obtidas pelos sensores é denominado de gerência de
contexto. Uma vez que é possível perceber o contexto, é necessário usar esta informação e agir
proativamente. Baseado nos dados obtidos dos sensores, o sistema toma decisões, tais como a configuração
de serviços de acordo com a mudança ambiental ou a manutenção do histórico de eventos passados para
reiniciar serviços quando o usuário reentra nesses ambientes (LYYTINEN e YOO, 2002). O gerenciamento
também pode expandir a capacidade dos dispositivos pelo uso de recursos disponíveis no contexto atual.
O projeto da Interação Humano-Computador (IHC) também é um assunto significativo. Como a ubicomp,
irão existir muitas formas de interação com o usuário. Além disso, a medida que os computadores tornam-se
mais "inteligentes", a intensidade e a qualidade da interação humano-computador tende a aumentar (SAHA e
MUKHERJEE, 2003). O foco na interface com o usuário, no projeto de software, tem adquirido um novo
significado desde o surgimento da computação móvel e dos novos modos de interação. A fusão de dados do
usuário com o ambiente real é outra razão para o desenvolvimento da área de IHC na ubicomp. Isso faz com
que a atenção seja direcionada para o conceito de interação transparente com o usuário. A ideia é preservar a
atenção do usuário, evitando saturação de informações (SIEWIOREK, 2002). Usuários devem ser capazes de
focar na tarefa que desejam realizar sem distração do sistema.
O último desafio é diretamente relacionado com a própria ubicomp. Invisibilidade está relacionada com a
manutenção do foco do usuário na tarefa, não na ferramenta (WEISER, 1994). Para atingir essa visão, o
software deve satisfazer a intenção do usuário, ajudando-o e não gerando obstruções. As aplicações devem
aprender com os usuários e, em alguns casos, deixar esses alterarem suas preferências, interagindo de
maneira quase subconsciente com o sistema (SATYANARAYANAN, 2001).
Na próxima seção vamos explorar algumas tendências e visão de futuro para minimizar o impacto desses
desafios.

15
ISBN: 978-972-8939-96-0 © 2013 IADIS

3. TENDÊNCIAS E VISÃO DE FUTURO

Para atingir a integração da computação com a vida cotidiana das pessoas, endereçando os vários desafios da
ubicomp, são necessárias a utilização de diferentes modelos, tecnologias e conceitos. A tendência da
disseminação dos dispositivos móveis, aliado ao seu barateamento, tem aproximado das pessoas a tecnologia
em qualquer lugar e a qualquer momento. Além disso, o barateamento de sensores e a conexão onipresente,
através das redes sem fio ou de telefonia, tem possibilitado a utilização de informações do contexto do
usuário, não mais limitada a localização ou velocidade de deslocamento. O problema reside em como
processar toda essa quantidade de dados coletados, de forma eficiente e inteligente.
Uma das técnicas bastante empregada é a do uso de conceitos de web semântica e ontologias (HENSON
et al., 2012). Nessa abordagem, os dados são organizados em uma base de conhecimento, através da qual
inferências podem ser realizadas, descobrindo relações e características importantes, e regras também podem
ser definidas. Com o uso das ontologias, pode-se criar múltiplas relações entre os diferentes dados coletados,
gerando informações não tão diretas e importantes para adaptação da aplicação às necessidades dos usuários.
Outra área que tem evoluído e que contribui para a visão de ubicomp, é a de interação com o usuário. A
interação tangível, que permite que as pessoas utilizem seu próprio corpo como interface, permite que formas
bastante natural de interação sejam empregadas. Bastante populares em aplicações de entretenimento, como
jogos, essas interfaces tem sido utilizadas em áreas como robótica e automação. Entretanto, devem a cada dia
serem mais utilizadas para auxiliar as pessoas nas suas tarefas do dia a dia e em realizarem atividades.
Outro ponto a destacar é o grande número de aplicações ditas ubíquas ou pervasivas (termo que é
sinônimo). Essas aplicações são desenvolvidas para as mais diversas áreas, destacando-se: saúde ubíqua –
ubiquitous health (SANTOS et al., 2013), onde aplicações são desenvolvidas com foco em monitoramento de
pacientes e apoio as tarefas da área utilizando contexto, dispositivos móveis e alto grau de integração;
pagamento ubíquo – ubiquitous payment (COSTA et al., 2013), integrando meios de pagamento com os
dispositivos móveis, bem como o desenvolvimento de uma carteira digital em que o dinheiro deixa de ser
físico e passa a ser virtual; educação ubíqua – ubiquitous learning (ABECH et al., 2012): trazer o
aprendizado para o mundo real integrado as atividades que o aluno vem realizando, bem como adaptado ao
perfil de aprendizado e demais informações de contexto; turismo ubíquo – ubiquitous tourism (COSTA et al.,
2012): aplicar os conceitos da ubiquidade na área do turismo, auxiliando as pessoas a conhecerem novos
lugares e melhorando suas experiências.
Para finalizar, existem diversas tecnologias hoje em dia que podem ser empregadas em uma visão de

 Tecnologias de comunicação baseadas em Radio Frequência ou Bluetooth: tecnologias com

futuro da computação ubíqua. A seguir, são destacadas algumas delas:

RFID, NFC e Bluetooth de baixa energia permitem interação entre diferentes usuários e
dispositivos bastante próximas da atividade das pessoas. Essas tecnologias podem ser
empregadas para serviços diversos de comunicação, localização, identificação e

 Redes de Sensores sem Fio: permitem a comunicação ad hoc para monitorar determinados
pagamento;

fenômenos e compartilhar as informações. Podem ser empregadas em diversas aplicações

da computação ubíqua incluindo o monitoramento de diversas condições em cidades

 Realidade aumentada: possibilita a adição de informações avançadas que melhora a

inteligentes;

experiência das pessoas no mundo real. Ao sobrepor informações na realidade do usuário,

 Computação vestível: consiste no desenvolvimento de dispositivos que são vestíveis ou

pode auxiliar na busca de informações e soluções, apoiando na realização de tarefas;

carregados pelas pessoas em seu corpo. Por causa disso, esses dispositivos permitem uma

 Inteligência ambiental: dispositivos e aplicativos colaboram e cooperam para conhecer o

constante interação com o usuário e utilização durante uma atividade específica;

perfil das pessoas e personalizar a experiência. Com essa tecnologia é possível antecipar
necessidades e adaptar o ambiente em resposta.

16
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

4. CONCLUSÃO
O desenvolvimento de software ubíquo ainda é limitado pela falta de infraestrutura de software cobrindo
todas as necessidades da ubicomp. A principal razão por essa ausência, é a complexidade de considerar
tópicos de pesquisa em aberto tão diferentes em um único projeto. Entretanto, muitos projetos hoje em dia
tem fornecido soluções isoladas para questões específicas.
Nesse artigo foram apresentados as principais questões relacionadas com tendências na computação
móvel, particularmente considerações relacionadas com a computação ubíqua. Primeiro, os principais
conceitos da área foram apresentados, focando nos desafios encontrados. Segundo, foram destacadas as
dificuldades em construir software ubíquo.
Hoje presenciamos o início da era da computação ubíqua. Apesar de existir uma grande evolução em
linguagens e ferramentas para o desenvolvimento de software desde o advento do PC, quando o foco são os
requisitos da ubicomp, ainda se observa os primeiros passos. São necessários middleware e framework para
acelerar o processo de desenvolvimento de software nesse cenário.
Um problema adicional do cenário da ubicomp é como a infraestrutura pode permitir que o usuário acesse
se ambiente computacional onde estiver e independentemente do deslocamento. A promessa do "todo tempo,
de todo o lugar" que seguidamente é apresentada junto com a ubicomp ainda é difícil de ser obtida. Outro
problema relacionado é como usar dados e aplicativos fortemente integrados com o mundo real. Essas
questões envolvem o endereçamento conjunto de diversos desafios aqui apresentados.
Esperamos que esse artigo possa contribuir para o avança do desenvolvimento da computação ubíqua.
Além disso, consideramos que para que se obtenha a visão seminal do Weiser de ubicomp, futuros sistemas
devem integrar-se transparentemente com o ambiente, tratando várias questões relacionadas com os desafios
discutidos nesse trabalho.

AGRADECIMENTOS
Agradecemos a IADIS e a pessoa do Pedro Isaias pelo convite para desenvolver esse artigo, além de
participar como orador e organizador da edição 2013 das conferências Ibero-Americanas WWW/INTERNET
e Applied Computing. Agradeço também ao CNPq que financia parte da minha pesquisa através da concessão
de Bolsa de Produtividade.

REFERÊNCIAS
Abech, M. et al., 2012. Um Modelo de Adaptação de Objetos de Aprendizagem com foco em Dispositivos Móveis.
Anais do Simpósio Brasileiro de Informática na Educação. pp. 1-5.
Avizienis, A. et al., 2004. Basic concepts and taxonomy of dependable and secure computing, Dependable and Secure
Computing, IEEE Transactions on , 1(1), pp. 11- 33.
Canny, J. 2006. The Future of Human-Computer Interaction. ACM Queue, 4(6), pp.24-32.
Costa, C. da, 2009. Software Infrastructure for Ubiquitous Computing, VDM Verlag, 2009. 174 p.
Costa, C. da, Yamin, A. & Geyer, C., 2008. Toward a General Software Infrastructure for Ubiquitous Computing.
Pervasive Computing, IEEE, 7(1), pp.64–73.
Costa, C. et al., 2013. 4iPay: A Payment System Model For U-Commerce. Proceedings of IADIS International
Conference WWW/Internet, pp. 43-50.
Costa, H. et al., 2012. A Ubiquitous Electronic Tourist Guide for the Caminhos de. Pedra Itinerary. Proceedings of IADIS
International Conference WWW/Internet, pp. 109-116.
Coulouris, G. et al., 2012. Mobile and Ubiquitous Computing, Distributed Systems: Concepts and Design, 5th ed.,
Addison-Wesley, pp. 817-880.
Dey, A.K., 2001. Understanding and Using Context. Personal and Ubiquitous Computing, 5(1).
Fetzer, C., Högstedt, K., 2002. Challenges in Making Pervasive Systems Dependable, Future Directions in Distributed
Computing, A. Schiper et al., eds., Springer, pp.186−190.
Grimm, R. et al., 2004. System support for pervasive applications. Transactions on Computer Systems - TOCS, 22(4).
Heidegger, M., 1996. Being and time: a translation of Sein and Zeit, State University of New York, New York.

17
ISBN: 978-972-8939-96-0 © 2013 IADIS

Henson, C., Sheth, A. & Thirunarayan, K., 2012. Semantic Perception: Converting Sensory Observations to Abstractions.
Internet Computing, IEEE, 16(2), pp.26–34.
Jing, J., Helal, A., Elmagarmid, A., 1999. Client-server Computing in Mobile Environments. ACM Computing Surveys,
31(2), pp. 117-157.
Keen, E., 1975. A primer in phenomenological psychology, Holt, Rinehart and Winston, New York.
Kindberg, T., Fox, A., 2002. System software for ubiquitous computing. Pervasive Computing, IEEE , 1(1), pp. 70- 81.
Lyytinen, K., Yoo, Y., 2002. Issues and Challenges in Ubiquitous Computing, Communications of the ACM, 45(12), pp.
63-65.
Robinson, P. et al., 2005. Some Research Challenges in Pervasive Computing, Privacy, Security and Trust within the
Context of Pervasive Computing, P. Robinson et al., eds., Springer, pp. 1−16.
Saha, D., Mukherjee, A., 2003. Pervasive computing: a paradigm for the 21st century. Computer , 36(3) , pp. 25- 31.
Santos, F., Costa, C., 2013. UBIHEALTH: A Ubiquitous Collaborative System to Support Telemedicine. Proceedings of
IADIS International Conference WWW/Internet, pp. 172-179.
Satyanarayanan, M., 1996. Fundamental Challenges in Mobile Computing. Proceedings of the ACM Symposium on
Principles of Distributed Computing (1996).
Satyanarayanan, M., 2011. Mobile computing: the next decade. SIGMOBILE Mobile Computing and Communications
Review, 15(2).
Siewiorek, D., 2002. New frontiers of application design, Pervasive Computing, IEEE, 1(1), pp. 79-82.
Want, R. et al., 2002. Disappearing hardware [ubiquitous computing], Pervasive Computing, IEEE , 1(1), pp. 36- 47.
Weiser, M., 1991. The computer for the 21st century. Scientific American, 265(3), pp.94–104.
Weiser, M., 2994. The world is not a desktop, ACM Interactions, 1(1), pp. 7-8.

18
Artigos Longos
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

ECG COM COMUNICAÇÃO SEM FIO BASEADO NO

PROTOCOLO ZIGBEE E WWW

Ari Magagnin Junior1,2,3, João Hamilton Cecato Simas1,2 e Miguel Antonio Sovierzoski2,3
1
Departamento Acadêmico de Informática
2
Departamento Acadêmico de Eletrônica
3
Programa de Pós-Graduação em Engenharia Biomédica (PPGEB)
Universidade Tecnológica Federal do Paraná (UTFPR)
Avenida Sete de Setembro, 3165, Curitiba, Paraná

RESUMO
Este trabalho apresenta uma solução tecnológica para a aquisição do sinal de eletrocardiografia através de comunicação
sem fio e visualização do sinal através de WWW em computação normal ou em dispositivos móveis, integrando diversas
tecnologias. O sinal de eletrocardiografia é adquirido e condicionado por circuitos eletrônicos, digitalizado e transmitido
para um computador através de padrão de comunicação sem fio ZigBee. A aplicação no computador recebe o sinal
transmitido em tempo real e o envia em pequenos pacotes de dados pela internet para um servidor web para
armazenamento e acesso. Os usuários cadastrados no servidor web podem receber e visualizar o sinal de
eletrocardiografia em tempo real no seu computador de mesa, laptop, tablet ou aparelho smartphone. O trabalho apresenta
a fundamentação teórica, as principais tecnologias utilizadas, detalhes de implementação, resultados obtidos discutindo-
se limitações e potenciais de melhoria.

PALAVRAS-CHAVE
Comunicação sem fio, dispositivos móveis, protocolo de comunicação, WebSocket, WWW, ECG.

1. INTRODUÇÃO
A WWW é composta de um emaranhado de protocolos e padrões de comunicação interconectados entre si.
Apesar de ser utilizada no início para facilitar a troca de informações entre pesquisadores, hoje a sua
utilização está crescendo devido aos avanços tecnológicos dos últimos anos, fato esse relacionado
principalmente pela grande demanda de utilização da rede provocada por um aumento significativo nas
vendas de smartphones e tablets. Em 2011, por exemplo, foram vendidos cerca de 472 milhões de aparelhos
smartphones no mundo, um aumento de 58% em relação ao ano anterior segundo Flipsen (2012). Existem
pesquisas para fornecer o acesso a internet até em zonas rurais através de redes mesh, como descrito no
trabalho de Kretschmer (2011). Dado o mundo globalizado em que estamos inseridos, é praticamente
impossível pensar nos afazeres diários sem a presença da rede mundial de computadores. A integração da
web com outras tecnologias permitiu o desenvolvimento de novas modalidades de negócios, serviços e
equipamentos, indo desde um meio para usuários comuns terem acesso a informações, até aplicações mais
sofisticadas em Home Care, como apresenta Nambu (2002). Todos estes avanços revertem para a sociedade
como novos serviços e facilidades.
Este trabalho apresenta um eletrocardiógrafo portátil com comunicação sem fio para um computador, que
pode estar em um hospital, clínica, consultório médico, em trânsito ou em uso domiciliar (e-health). O sinal
de eletrocardiografia adquirido é transmitido em tempo real para o computador próximo. Este computador
conectado a um servidor web através da internet transmite os dados de eletrocardiografia (ECG) em tempo
real para o servidor. O servidor web recebe os dados, armazena e permite o acesso em tempo real aos dados
por diversos usuários cadastrados. Os usuários cadastrados e conectados ao servidor web podem utilizar
diversas plataformas de computação fixa ou móvel. Na sequência do trabalho é apresentada a fundamentação
teórica da eletrocardiografia, as tecnologias envolvidas e o detalhamento de como foram utilizadas. São
apresentados alguns resultados do projeto e finalizando o trabalho com discussões e comentários.

21
ISBN: 978-972-8939-96-0 © 2013 IADIS

O Monitoramento Remoto de Pacientes tem sido amplamente utilizado a fim de melhorar a qualidade de
vida das pessoas e sob esse contexto o Colégio Americano de Cardiologia em parceria com a Associação
Americana do Coração descreveu diretrizes para eletrocardiografia ambulatorial. (Crawford, 1999). O grande
aumento de projetos desenvolvido para esse fim pode ser facilmente comprovado devido ao aumento do
número de publicações de artigos relacionado ao tema. Existem vários projetos que foram divulgados na
literatura que utilizam o conceito de e-Health em ECG. Watanabe (2012) utiliza o smartphone integrado com
um sistema desenvolvido chamado “Dentan” para fazer a monitoração do sinal de ECG. Paraschiv (2011)
desenvolveu um equipamento remoto para monitorar os sinais de ECG, porém com um foco voltado para
equipamentos de baixo custo com o intermédio de aparelhos celulares para a aquisição. Existem outros
trabalhos que fazem uso de tecnologias sem fio para transmissão de dados de ECG. Em Fensli (2005) foi
desenvolvido um dispositivo similar a esse projeto, entretanto o equipamento não foi desenvolvido para
operar em tempo real.
A grande diferença desse projeto para os demais relatados é o monitoramento remoto em tempo real, além
de fazer a gravação dos dados de ECG adquiridos. A possibilidade de visualizar o sinal em tablets e
smartphones também é um diferencial. As tecnologias utilizadas também são diferentes das apresentadas,
como no caso do padrão Zigbee escolhido para a transmissão sem fio.

2. FUNDAMENTAÇÃO TEÓRICA
Os trabalhos de Einthoven, Goldberger e Wilson no século passado determinaram as derivações e a
nomenclatura empregada no sinal de eletrocardiografia. A morfologia típica do sinal de ECG de uma pessoa
por uma das derivações de Einthoven pode ser observada na Figura 1, destacando-se a onda P e T, e o
complexo QRS com alguns valores típicos de intervalos e amplitudes. (Guyton, 2006).

Figura 1. Morfologia típica do sinal de ECG. Fonte: Guyton (2006)

A faixa de frequências do sinal de ECG na etapa de aquisição do sinal depende da aplicação para a qual
destinam-se os dados. Tompkins (1993) definiu que o sinal de ECG clínico padrão possui banda passante de
0,05 até 100 Hz. Para aplicações de monitoramento do sinal de ECG a banda passante é de 0,5 até 50 Hz. Já
para aplicações de batimento cardíaco é uma banda passante estreita centrada em 17 Hz.

3. MATERIAIS E MÉTODOS
A visão geral do projeto é apresentada pela Figura 2, com diferentes tecnologias e dispositivos envolvidos.
Observa-se que o paciente está conectado a um eletrocardiógrafo via eletrodos, colocados na superfície da
pele. O eletrocardiógrafo efetua a aquisição do sinal de ECG, faz as conformações do sinal, as adequações de
níveis de tensão, faz a amostragem e envia o sinal digitalizado para um computador através de comunicação
sem fio.

22
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Esse computador recebe os dados em tempo real, verifica erros nos pacotes de dados, trata os erros e
envia os dados para um servidor web em tempo real.

Figura 2: Visão geral do projeto de ECG sem fio e acesso via web.
Por outro lado e podendo estar em um ambiente distante daquele onde se encontra o paciente, um médico,
ou profissional da saúde habilitado, a partir de um host (computador, tablet ou aparelho smartphone) com
conexão a internet, pode acessar o servidor e visualizar em tempo real o sinal de ECG do paciente, ou um
sinal já gravado no banco de dados.

3.1 Eletrocardiógrafo

3.1.1 Aquisição do Sinal Eletrocardiográfico

O eletrocardiógrafo portátil realiza diversas conformações no sinal bioelétrico do coração captado na
superfície da pele. A Figura 3 apresenta o diagrama em blocos das etapas de condicionamento e conformação

 O Amplificador de instrumentação é utilizado para adquirir o sinal através dos eletrodos

do sinal de ECG, sendo detalhadas na sequência:

colocados na superfície da pele do paciente. Ele amplifica a diferença de potencial entre os eletrodos
colocados nos braços ou no tórax do paciente. O sinal na saída do amplificador de instrumentação
está sujeito a interferência em modo comum, devido ao circuito em malha fechada realizado pelos
condutores dos eletrodos e pelo paciente, sendo susceptível a interferência da rede elétrica.

 O Circuito da perna direita é responsável por causar uma interferência subtrativa, minimizando a
(Webster, 2010)

interferência provocada pelo ruído em modo comum. O circuito injeta uma corrente na perna direita

 Os Filtros passa-altas e passa-baixas atuando em conjunto formam um filtro passa-faixa para

do paciente em fase oposta ao ruído interferente da rede elétrica. (Webster, 2010)

restringir a banda passante do sinal de ECG (Webster, 2010). O filtro passa-altas é necessário para
atenuar a interferência causada pelo potencial de meia célula gerado pelos eletrodos e atenuar
também a interferência do músculo diafragma responsável pela respiração. O filtro passa-baixas é

 O Filtro Notch de 60 Hz é utilizado para atenuar os ruídos provenientes da rede elétrica, que não
necessário como filtro anti-aliasing e para limitar a faixa de frequências do sinal adquirido.

foram suficientemente atenuados pela interferência destrutiva provocada pelo circuito da perna

 O Ganho inicial, ajuste de ganho e ajuste de offset são utilizados para ajustar a faixa do sinal
direita. (Webster, 2010)

entre os níveis de tensão de 0 e 3,3 volts, que são os limites dos níveis de tensão do conversor

 O microcontrolador ARM Cortex-M3 digitaliza o sinal através do seu periférico conversor

analógico-digital do microcontrolador.

analógico-digital (ADC) com resolução de 10 bits e envia serialmente o sinal digitalizado para o

 O Módulo de comunicação com padrão ZigBee no eletrocardiógrafo é responsável por enviar os

módulo de comunicação.

dados para o outro módulo ZigBee conectado na porta USB do computador receptor.

23
ISBN: 978-972-8939-96-0 © 2013 IADIS

Figura 3: Diagrama em blocos da aquisição e transmissão dos sinais de ECG para o computador.

3.1.2 Eletrocardiógrafo – Firmware

A máquina de estados do firmware que está no microcontrolador do eletrocardiógrafo é representada pela
Figura 4. Tem-se sete estados, sendo que os três primeiros são responsáveis pela etapa de configuração dos

 Config_Timer – O firmware inicia nesse estado e configura o periférico Timer para realizar 300
periféricos, e os demais pela etapa de aquisição de envio do sinal de ECG. Segue a descrição dos estados:


interrupções por segundo. Após essa configuração passa para o estado Config_ADC.
Config_ADC – Nesse estado o firmware configura o periférico ADC para amostrar o sinal no modo

 Config_UART – Nesse estado o firmware configura a UART para poder enviar os pacotes de
burst (controle por hardware). Após essa configuração passa para o estado Config_UART.

 Waiting – O firmware permanece nesse estado até receber uma chamada de interrupção do Timer
mensagem para o módulo de comunicação sem fio e então passa para o estado Waiting.

TIMER_Handler, passando para o estado FinishedCounting, ou até receber uma chamada de

 FinishedCounting – Nesse estado o firmware da início a conversão de uma amostra do ADC no

interrupção do ADC ADC_Handler passando para o estado ADCFinishedConverting.

modo burst, passando o controle para o hardware, e volta para o estado Waiting para aguardar uma

 ADCFinichedConverting – O firmware prepara o pacote de mensagem no formato apresentado pela

chamada de interrupção do ADC chamando o método ADCBurst, indicando o término da conversão.

Figura 6, e em seguida passar para o estado SendDataToModule ao chamar o método

 SendDataToModule - Nesse estado o firmware envia os dados para o módulo de comunicação sem
Send_Pkt_Uart.

fio serialmente através da UART e então retornar para o estado Waiting aguardando novamente uma
interrupção do timer.

Figura 4. Máquina de estados do firmware do eletrocardiógrafo.

O firmware basicamente faz o processo de amostragem periódica do sinal de ECG a 300 amostras por
segundo e digitaliza o sinal com resolução de 10 bits, através do periférico conversor analógico-digital do
microcontrolador. Em seguida ocorre a montagem do pacote de mensagens com os dados digitalizados, que
será enviado ao módulo de comunicação sem fio através da interface serial.

24
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

3.2 Protocolos de Comunicação e Elementos Envolvidos

A Figura 5 apresenta o diagrama completo do sistema em termos de protocolos de comunicação, com os
elementos envolvidos. Nos itens seguintes são detalhados cada um dos processos de comunicação entre os
elementos envolvidos.
3.2.1 Comunicação entre o Eletrocardiógrafo e o Computador Receptor
A comunicação entre o eletrocardiógrafo e o computador receptor é uma comunicação unidirecional, que
parte do eletrocardiógrafo para o computador e é realizada pelos módulos de comunicação sem fio Xbee que
implementa o padrão Zigbee. A estrutura do pacote de dados trocado nessa comunicação é representada pela
Figura 6.

Figura 5. Estrutura em camadas das soluções de comunicação sem fio e via web utilizadas no projeto.

 1º byte: Delimitador de início de pacote, valor 0xFF. É o indicador de início do pacote.

O tamanho da mensagem é fixo de 15 bytes:

 2º byte: Identificador de pacote com valor variando se 0 a 0xFE. É utilizado para a reconstrução do

 3º ao 14º byte: Valores da conversão dos canais do ADC. Dois bytes são necessários para cada canal
sinal e indicativo de quais amostras chegaram ao computador receptor.

já que o ADC tem resolução de 10 bits, e cada byte possui os 5 bits mais significativos ou menos

 15º byte: Checksum do pacote. São os 8 bits menos significativos da soma do 2º ao 14º byte do
significativos de cada canal do ADC.

frame da mensagem. Utilizado para verificação de erros no receptor.

Figura 6. Estrutura do pacote de mensagem trocada pelo eletrocardiógrafo e o programa receptor.

Nessa comunicação não há retransmissão de pacotes perdidos, ou seja, a preocupação é com os pacotes
correntes para a análise em tempo real. O padrão Zigbee é definido por uma aliança de empresas denominada
ZigBee Alliance. Nesse padrão as camadas MAC (Medium Access Control) e PHY (Physical Layer) são

25
ISBN: 978-972-8939-96-0 © 2013 IADIS

implementadas pela definição IEEE 802.15.4 na faixa de frequência de 2,4 GHz. Utiliza-se do sistema de
segurança padrão da indústria AES-128. As vantagens da utilização desse padrão são: baixo consumo de
energia, segurança, baixo custo, confiabilidade, e a comunicação em rede sem fio baseada em uma norma
aberta global (ZigBee Specifications, 2013). Entretanto a taxa de transmissão é inferior a algumas normas
como Bluetooth e WiFi, porém atende os requisitos desse projeto.
3.2.2 Computador Receptor - Programa Receptor
O programa receptor que é executado no computador receptor foi desenvolvido em Java e é responsável por
receber os dados do eletrocardiógrafo, tratar os erros, montar o pacote de mensagens e enviá-lo ao servidor

 Verificar o número de amostras recebidas e transmitidas.

web via protocolo WebSocket. Nessa aplicação é possível:

 Verificar o número de amostras perdidas.

 Verificar o tempo em que a conexão está em aberto com o eletrocardiógrafo.
 Escolher a porta COM no computador onde está o módulo de comunicação.
 Conectar e desconectar do eletrocardiógrafo.
3.2.3 Comunicação entre o Computador Receptor, o Servidor e a Aplicação Cliente
A comunicação entre o computador receptor e o servidor, e a comunicação entre o servidor e a aplicação
cliente é feita sobre o protocolo WebSocket. Esse protocolo permite uma comunicação full-duplex através do
protocolo TCP, que por sua vez disponibiliza um tratamento de erros na troca de mensagens. A estrutura do
corpo da mensagem do protocolo WebSocket é apresentada pela Figura 7, sendo uma sequência de
informações alfanuméricas separadas em campos delimitados.

Figura 7. Estrutura do corpo da mensagem do protocolo WebSocket.

A máquina de estados do programa que é executado no computador receptor é mostrada pela Figura 8.

Figura 8. Máquina de estados do programa receptor utilizada no recebimento nos pacotes de mensagem.

26
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

 Waiting_Delimiter – Estado inicial onde o programa fica aguardando o recebimento do byte

Essa máquina possui seis estados:

 Waiting_ID – Estado onde o programa fica aguardando o recebimento do byte de identificação do

delimitador. Quando recebe o byte delimitador passa para o estado Waiting_ID.

 Waiting_MSP – Estado onde o programa aguarda o recebimento do byte mais significativo dos dois
pacote. Quando recebe este byte o programa passa para o estado Waiting_MSP.

bytes que formam o valor digitalizado do sinal de ECG. Quando ele recebe este byte passa para o

 Waiting_LSP – Estado onde o programa aguarda o recebimento do byte menos significativo do

estado Waiting_LSP.

sinal digitalizado de ECG. Após o recebimento deste byte o programa passa para o estado
Calculate_CheckSum. Caso o byte recebido seja o último byte do quinto canal de ECG, o programa

 Calculate_CheckSum – Neste estado o programa calcula o checksum do pacote que recebeu e

passa para o estado Calculate_CheckSum, caso contrário volta para o estado Waiting_MSP.

verifica se é igual ao valor de checksum que veio no pacote, caso seja igual o programa salva o
pacote e volta para o estado Waiting_Delimiter, aguardando um novo pacote, caso seja diferente

 Error – Estado onde o programa detectou algum erro durante o recebimento dos bytes que
passa para o estado Error.

completam o pacote, descarta-se os dados do último pacote recebido que estava com erro e volta-se
para o estado Waiting_Delimiter.
Para o funcionamento do protocolo descrito é necessário que o navegador web do host, onde é executado
a aplicação cliente tenha compatibilidade com o protocolo WebSocket, caso contrário essa troca de
mensagem não funciona.

3.3 Aplicação Cliente

A aplicação cliente foi desenvolvida em PHP (Hypertext Preprocessor), HTML (HyperText Markup
Language) e Javascript, sendo executada dentro do navegador web. Para desenvolver os gráficos do sinal de
ECG foi utilizada a biblioteca Smoothie Charts em JavaScript. A partir dessa aplicação é possível fazer as

 Visualizar o sinal de ECG em tempo real.

seguintes ações:

 Visualizar o batimento cardíaco em tempo real.

 Visualizar um sinal armazenado no banco de dados do servidor web.
 Visualizar as amostras de ECG em ordem cronológica pela data e horário.

4. RESULTADOS E DISCUSSÕES
Para apresentar resultados de testes com o sistema para este trabalho, foi adquirido o sinal de ECG de um
equipamento simulador de ECG Lionheart Bio-Tek Multiparameter Simulator. A Figura 9 apresenta o sinal
que foi visualizado em tempo real pelo usuário final na aplicação cliente. No canto inferior da Figura 9 pode
ser visto o tempo em que a aplicação está conectada no servidor e o batimento cardíaco instantâneo. Sob
condições normais o sistema como um todo funcionou corretamente sem problemas observados. Todavia o
sistema é dependente de uma boa conexão com a internet, caso essa conexão seja muito ruim, pode ocorrer
atrasos na transmissão dos pacotes se o sinal estiver sendo observado em tempo real, entretanto isso não
ocorre se for observado na aplicação cliente um sinal já gravado no servidor. Até uma distância de 40 m em
ambientes abertos a comunicação sem fio é eficiente, entretanto para distâncias maiores ocorre o aumento do
número de erros chegando a tornar inviável em alguns ambientes fechados e de alto ruído.

27
ISBN: 978-972-8939-96-0 © 2013 IADIS

Figura 9: Sinal de ECG Sinal gerado por um equipamento simulador de sinais de ECG (Lionheart Bio-Tek
Multiparameter Simulator), sendo observado em tempo real na aplicação cliente. (a) Menu da aplicação cliente. (b) Sinal
sendo observado simultaneamente em um aparelho smartphone e em um computador.

5. COMENTÁRIOS
Foi possível verificar em tempo real o sinal de ECG sendo adquirido pelo eletrocardiógrafo em um host com
acesso a internet e distante de onde o paciente está se submetendo a aquisição. Os protocolos de comunicação
sem fio desenvolvido e o protocolo WebSocket funcionaram de forma robusta e precisa, eliminando as
amostras com erros. A utilização da internet como meio de transporte de dados para um outro local distante
de onde o paciente se encontra, deu uma dinâmica diferente no modo como esse exame de eletrocardiograma
é realizado atualmente. Um médico, por exemplo, pode observar um exame sendo feito em tempo real do seu
paciente através de um aparelho smartphone ou tablet com internet 3G em qualquer lugar em que se encontra
ou então pode fazer o exame em uma clínica e buscar esse mesmo exame no banco de dados do servidor em
outra clínica sem nenhuma burocracia de transferência.

REFERÊNCIAS
Crawford, M. H. 1999. ACC/AHA Guidelines for ambulatory electrocardiography. Journal of the American College of
Cardiology, vol. 34, pp 912-48.
Fensli, R. et al. 2015. A Wearable ECG-recording System for Continuous Arrhythmia Monitoring in a Wireless Tele-
Home-Care Situation. IEEE Symposium on Computer-Based Medical Systems, Dublin, pp. 1063-7125.
Flipsen B. et al. 2012. Environmental sizing of smartphone batteries. Electronics Goes Green, Berlin Alemanha, pp. 1-9.
Guyton, A. C.; Hall, John E, 2006. Textbook of medical physiology. Elsevier Saunders, Pennsylvania, USA.
Kretschmer M. et al. 2011. Providing Mobile Phone Access in Rural Areas via Heterogeneous Meshed Wireless Back-
haul Networks. IEEE International Conference on Communications Workshops, Kyoto, Japão, pp. 1-6.
Malmivuo, J.; Plonsey, R. 1995. Bioelectromagnetism - Principles and Applications of Bioelectric and Biomagnetic
Fields. Oxford University Press, New York.
Nambu M. et al. 2002. WWW Based ECG Transfer for Home Care using JAVA Script. Proceedings of the 2002 IEEE
Engineering in Medicine and Biology 24th Annual Conference and the 2002 Fall Meeting of the Biomedical
Engineering Society (BMES/EMBS '02), vol. 3, pp. 1891 - 1892.
Paraschiv, A.-M. et al. 2011. Remote Monitoring ECG Signals System. 7th International Symposium on Advanced Topics
in Electrical Engineering (ATEE), Bucharest, pp. 1 – 6.
Tompkins, Willis J. 1993. Biomedical digital signal processing: C-language examples and laboratory experiments for
the IBM PC. Prentice-Hall.
Watanabe , H.; Kawarasaki, M.; Sato, A.; Yoshida, K. 2012. Development of Wearable Heart Disease Monitoring and
Alerting System associated with Smartphone, Healthcom, pp. 292 – 297.
WebSocket, 2012. Disponível em: < http://www.websocket.org/> Acesso em: 09 de maio de 2013.
Webster, John G. 2010. Medical instrumentation: application and design. John Wiley.
ZigBee Specifications, 2013. Disponível em: < http://www.zigbee.org/> Acesso em: 10 de maio de 2013.

28
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

PROCESO DE DESARROLLO DE COMPONENTES

SOFTWARE REUTILIZABLES ENFOCADO AL
DESARROLLO DE APLICACIONES EMPRESARIALES

M.Sc. Fredy Humberto Vera Rivera1, M.Sc. Fernando Antonio Rojas Morales2
y Esp. Enrique Torres López3
Universidad Francisco de Paula Santander - Cúcuta – Colombia - Departamento de Ingeniería de Sistemas
1
2
Universidad Industrial de Santander – Bucaramanga – Colombia - Escuela de Ingeniería de Sistemas e Informática
3
Universidad Industrial de Santander - Bucaramanga – Colombia - División de Servicios de Información

RESUMEN
El presente artículo corresponde a la investigación tecnológica realizada en conjunto por la Escuela de Ingeniería de
Sistemas y la División de Servicios de Información (DSI) de la Universidad Industrial de Santander (UIS) de
Bucaramanga - Colombia, en la cual se plantea un proceso de desarrollo de componentes software reutilizables, donde se
establecen y detallan los pasos necesarios para crear una biblioteca de componentes Java (versión JEE5). Como
resultado, el proceso se utiliza en la creación de componentes software para el desarrollo de software empresarial de la
DSI, en el marco del proyecto de desarrollo de nuevas versiones de los sistemas que dan soporte a las actividades
misionales de la UIS: Académico, Financiero y de Recursos Humanos. El artículo explica las fases del proceso de
desarrollo y su aplicación.

PALABRAS CLAVE
Ingeniería del Software Basada en Componentes, Componentes Software Reutilizables, Enterprise Java Bean,
Persistencia Java – JPA.

1. INTRODUCCION
Según (Pressman, 2002), “La ingeniería del software basada en componentes (ISBC) es un proceso que se
centra en el diseño y construcción de sistemas basados en computadora que utilizan componentes de software
reutilizables”. Con base en esta premisa, en el contexto de una investigación realizada en conjunto por la
Escuela de Ingeniería de Sistemas y la División de Servicios de Información (DSI) de la Universidad
Industrial de Santander (UIS), se propuso un proceso de desarrollo de componentes software reutilizables
como estrategia para el desarrollo del software empresarial, y se establecieron actividades para crear una
biblioteca de componentes reutilizables, que resuelve un problema de investigación planteado así: ¿Cómo
elaborar componentes reutilizables que sirvan de apoyo al proceso de desarrollo software? También se
resuelven las siguientes preguntas que ayudan a clarificar la solución del problema de investigación
propuesto: (1) ¿Cómo identificar los componentes candidatos a implementar y cuáles son los criterios de
selección de estos componentes? (2) ¿Qué alternativas de arquitectura se pueden utilizar para el desarrollo de
los componentes reutilizables? (3) ¿Cómo se deben implementar y especificar los componentes software, de
tal forma que se pueda hacer fácil su reutilización? La estructura del componente software reutilizable
estudiado se puede apreciar en la figura 1.

29
ISBN: 978-972-8939-96-0 © 2013 IADIS

Figura 1. Componente Software Reutilizable

El componente es un conjunto de subcomponentes que consta de Entidades, Controladores (Enterprise
Java Beans o EJBs), componentes personalizados para la interfaz de usuario (Componentes UI) y Servicios
Web. Con la implementación de este tipo de componentes, el ingeniero desarrollador dispone de un conjunto
de subcomponentes encapsulados en el propio componente, que pueden ser utilizados a conveniencia: como
EJBs, como controles personalizados o invocando servicios Web del componente; así el componente se
puede utilizar en el desarrollo de aplicaciones Web, aplicaciones cliente y aplicaciones móviles inclusive.

2. EL PROCESO DE DESARROLLO DE COMPONENTES

REUTILIZABLES
El proceso de desarrollo de componentes software reutilizables, tiene su fundamento en (Pressman, 2002),
(Iribarnes Martinez, 2003), (Weitzenfeld, 2002), (Bruegge & Dutoit, 2004). Las fases propuestas para el
proceso de desarrollo se pueden apreciar en la figura 2, un diagrama de actividades UML del proceso donde
se destacan los resultados principales de cada actividad. A continuación se detalla cada una de las fases del
proceso de desarrollo planteado, mostrando su utilización en la implementación de un componente software.

2.1 Análisis de Requisitos del Dominio de Aplicación

En esta fase se establece el dominio de la aplicación y el modelo de requisitos para la biblioteca de
componentes. En la DSI se pueden identificar las siguientes áreas de aplicación: Financiera, de Recursos
Humanos, Académica. Estas áreas tienen infraestructuras muy grandes, por lo que es necesario
desagregarlas, para reducir su complejidad. Por ejemplo, el sistema de Recursos Humanos se puede dividir en
las siguientes áreas: Actividad académica administrativa, general (servicios genéricos usados por otros
sistemas), hoja de vida del personal, pagos del personal, administración de personal y programas de
desarrollo. Después de seleccionar las áreas de aplicación se definen criterios de evaluación, para decidir el
dominio de aplicación para el que se construirá la biblioteca de componentes. Estos criterios se pueden
apreciar en la tabla 1.

30
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Figura 2. Propuesta del proceso de desarrollo de componentes software reutilizables.

Tabla 1. Criterios de evaluación de las áreas de aplicación

CRITERIOS DE EVALUACIÓN DE LAS ÁREAS DE APLICACIÓN

Criterio Descripción Evaluación
1. Grado de Utilización. Define el nivel de reutilización posible de los componentes 1: Muy bajo, 2: Bajo, 3:
del dominio de aplicación. Medio, 4: Alto, 5: Muy alto.
2. Dificultad de implementación Define la posible dificultad para el desarrollo e 5: Muy baja, 4: Baja, 3:
implementación de los componentes. Media, 2: Alta, 1: Muy alta.
3. Complejidad Define la complejidad del componente del área de 5: Muy baja, 4: Baja, 3:
aplicación de los componentes. Media, 2: Alta, 1: Muy alta.
4. Grado de cambio. Define la posibilidad de cambio de los requisitos para los 5: Muy bajo, 4: Bajo, 3:
cuales se implementan los componentes. Medio, 2: Alto, 1: Muy alto.
5. Nivel de Abstracción Define el nivel de abstracción y de las funcionalidades que 1: Muy bajo, 2: Bajo, 3:
van a manejar los componentes. Medio, 4: Alto, 5: Muy alto.
6. Necesidad de Define el grado de necesidad para implementar el 1: Muy bajo, 2: Bajo, 3:
Implementación. componente en la empresa de desarrollo software. Medio, 4: Alto, 5: Muy alto.
7. Posibilidad de componentes Define la posibilidad de encontrar componentes ya 5: Muy baja, 4: Baja,
ya desarrollados desarrollados que se adapten a la mayoría de 3: Media, 2: Alta, 1: Muy
funcionalidades que va a manejar el área de aplicación. alta.

La evaluación de las áreas de aplicación, en el sistema de Recursos Humanos, se obtuvieron los siguientes
resultados: Administración de personal 25 puntos, tramite Solicitudes 22 puntos, administración de roles,
usuarios, menús 23 puntos, generador de Listados 23 puntos, consultas generales de recursos humanos 28
puntos, administración ordenes de trabajo 19 puntos. Esta evaluación la realiza un experto del dominio y/o
líder del desarrollo. Se selecciona el área con mayor puntaje. Después de identificar y seleccionar el área de
aplicación se describe el dominio de aplicación seleccionado, resaltando las funcionalidades que se quieren
cubrir con la biblioteca de componentes por medio de un modelo de requisitos. Los resultados del modelo de
requisitos son la descripción detallada del dominio de aplicación y diagramas de casos de uso.

2.2 Modelo de Selección de Componentes

Con el modelo de selección de componentes se pretende elegir los componentes a implementar para el
dominio de aplicación establecido, teniendo en cuenta los casos de uso definidos en la fase anterior. El
modelo de selección de componentes se definió con base en técnicas de Ingeniería de software,
específicamente el proceso de desarrollo de software orientado a objetos propuesto por Weitzenfeld [2],
haciéndole adaptaciones. En la figura 3 se presenta el diagrama de actividades del modelo.

31
ISBN: 978-972-8939-96-0 © 2013 IADIS

Figura 3. Modelo de selección de componentes

Modelo del dominio del problema: Según (Weitzenfeld, 2002), el modelo del dominio del problema
define un modelo de clases común para todos los involucrados. Los resultados de este modelo son: las
entidades del dominio de aplicación y un diagrama de entidades. El diagrama de Entidades se presenta en la
figura 4 - a.
Modelo de análisis: En este modelo se establece un conjunto controladores del dominio de aplicación de
tipo Enterprise Java Beans (EJBs) -. Se identifican tres clases de control: ConsultarUnidadesEJB,
ConsultarCargosEJB, ConsultarGeneralesEJB. Los resultados de este modelo son los EJBs y el diagrama de
clases donde se relacionan los EJBs y las entidades que manejan; en este diagrama se puede apreciar la
dependencia estructural de cada EJB, en la figura 4 - b. Para el modelo de análisis es importante tener en
cuenta qué: (1) Se debe definir por lo menos un EJB por caso de uso. (2) Dependiendo de la complejidad del
caso de uso se pueden utilizar varios EJBs. (3) Dependiendo de los requerimientos funcionales y no
funcionales del caso de uso se decide el tipo de EJB a utilizar. (4) Se pueden manejar varios tipos de EJB
para un mismo caso de uso. (5) Se deben encapsular los servicios del caso de uso. (6) Se debe adicionar o
eliminar las entidades que se estime conveniente.

Figura 4 a. Diagrama de Clases de Entidad de las consultas generales – b. Diagrama de clases o Modelo de Análisis
Modelo de componentes: Se utiliza para definir los componentes software candidatos a implementar. El
objetivo principal del modelo de componentes es agrupar las entidades y los EJBs en componentes
independientes, de tal forma que se puedan reutilizar en los proyectos de desarrollo de manera independiente.
En la figura 5 – a, se muestra el diagrama inicial de componentes para la aplicación realizada en la DSI.
Hasta el momento, los componentes identificados constan sólo de entidades y EJBs, quedando por definir los
servicios Web y los componentes personalizados para la interfaz de usuario. El diagrama de componentes
mostrado en la figura 5- a cambia al agregar los servicios web y los componentes UI, dando origen al
diagrama que se muestra en figura 5 - b, El resultado de esta fase son los tres componentes mostrados en la
figura 5 - b.

32
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Figura 5 a. Diagrama inicial de componentes – b. Diagrama de Componentes del área de aplicación

Análisis de reutilización: En esta actividad se pretende asegurar que los componentes resultantes sean
reutilizables, para esto es necesario definir algunos criterios de selección de componentes. Los objetivos de
diseño en el proceso de desarrollo software, definidos en Bruegge y Dutoit [4], se pueden adaptar para definir
los criterios de reutilización y de selección de componentes. También Bertoa y Vallecillo [5] hacen una
adaptación del modelo de calidad ISO 9126 aplicado a los componentes, del cual se toman algunos criterios
para utilizarlos como criterios de selección, como se aprecian en la tabla 3. Para cada criterio se especifica
una escala de evaluación asociada que se evalúa sobre los componentes. Se considera que un componente es
reutilizable si obtiene una calificación entre 30 y 45 puntos que corresponden al 66% del puntaje, se
constituye en candidato a implementar.
Tabla 2. Criterios de selección de componentes

CRITERIOS DE SELECCIÓN DE COMPONENTES

1. Dependencia estructural.
Debe tener un alto grado de cohesión y un bajo acoplamiento para que la reutilización se 1- Muy alta. 2- Alta 3- Media 4
más fácil de obtener. Baja 5- Muy baja
2. Facilidad Mantenimiento
El mantenimiento del componente debe ser transparente, debe afectar lo menos posible a lo 1- Muy Difícil 2- Difícil. 3- Media.
clientes que lo utilizan. Se mide el grado de dificultad del mantenimiento. 4- Fácil. 5- Muy fácil.
3. Grado de Adaptabilidad.
Determina la capacidad que tiene el componente para adaptar las funcionalidades o servicio 1-Muy Bajo. 2- Bajo. 3- Medio. 4
que presta a situaciones imprevistas o no manejadas. El grado de adaptabilidad debe ser alto. Alto. 5- Muy alto
4. Grado extensibilidad.
Determina el grado de dificultad y el impacto de añadir nuevas funcionalidades a 1- Muy Alto. 2- Alto. 3- Medio. 4
componente. Para obtener la reutilización este grado de dificultad debe ser bajo. Bajo. 5- Muy bajo
5. Grado de Utilización.
Determina el número de posibles clientes o usuarios del componente. 1-Muy Bajo. 2- Bajo. 3- Medio. 4
Alto. 5- Muy alto
6. Portabilidad.
Determina la capacidad que tiene el componente de utilizarse en diferentes ambientes al qu 1-Muy Baja. 2- Baja. 3- Media. 4
fue implementado. Si se quiere que el componente tenga alta reutilización se debe pode Alta. 5- Muy alta.
utilizar en diferentes lenguajes, plataformas y sistemas operativos.
7. Complejidad.
Determina el grado de complejidad de la lógica que maneja el componente. Entre má 1- Muy Alta. 2- Alta. 3- Media. 4
complejo sea, más difícil será su implementación. Baja. 5- Muy baja
8. Grado de Cambio.
Define la posibilidad de cambio de los requisitos para los cuales fue implementado e 1- Muy Alto. 2- Alto. 3- Medio. 4
componente. Bajo. 5- Muy bajo
9. Posibilidad de componente ya desarrollado.
Define la posibilidad de encontrar un componente ya desarrollado que se adapte a la mayoría1- Muy Alta. 2- Alta.
de las funcionalidades que va a manejar el componente a implementar. 3- Media. 4- Baja. 5- Muy baja

33
ISBN: 978-972-8939-96-0 © 2013 IADIS

Al realizar la evaluación de los criterios de selección sobre los componentes candidatos a implementar se
obtuvieron los siguientes resultados: (1) Generales 35 puntos, (2) Unidades 34 puntos, (3) Cargos 32 puntos.
Los tres componentes candidatos superan los 30 puntos, cumpliendo con los requisitos planteados. Se
determina entonces en esta fase que se construirán 3 componentes software reutilizables para el área de
aplicación seleccionada.

2.3 Definición de la Arquitectura

Una vez definidos y seleccionados los componentes, se define el estilo arquitectónico que deben seguir para
implementarlos correctamente. Las alternativas de arquitectura para los componentes software reutilizables
son: (1) Arquitectura Modelo – Vista – Controlador (MVC). (2) Arquitectura por capas. (3) Arquitectura
Orientada a Servicios (SOA). Los estilos arquitectónicos, planteados en (Vera Rivera & Rojas Morales,
2008), detallan la forma de aplicar cada estilo a los componentes software reutilizables. La arquitectura
seleccionada para la implementación de los componentes del caso de estudio es la arquitectura por capas. Se
definieron tres capas para los componentes: (1) Capa de Datos: Contiene las clases de entidad del área de
aplicación que se encargan de la persistencia de los datos. (2) Capa de Servicios: En la cual se encuentran los
EJBs definidos para el componente. (3) Capa de Presentación: son componentes personalizados para la
interfaz de usuario y los servicios web.

2.4 Procedimiento de Desarrollo, Pruebas y Especificación

Con el procedimiento de desarrollo, pruebas y especificación se pretende definir los pasos necesarios para
implementar los componentes software reutilizables garantizando su calidad, así como también describir las
funcionalidades, propiedades y elementos del componente por medio de su especificación. En la figura 6 se
puede apreciar el procedimiento propuesto. A continuación se detalla cada actividad.

Figura 6. Procedimiento de desarrollo, pruebas y especificación de los componentes reutilizables.

Implementación de Entidades (EJB de Entidad – Java Persistence Aplication): El objetivo de esta
fase es convertir el modelo de entidades o modelo del dominio del problema en clases de entidad
implementadas y mapeadas a una base de datos relacional. El mapeo se realiza en Java versión empresarial 5,
utilizando el API de persistencia de Java, el JBoss Seam y el framework EJB 3.0, según se específica en
(Debu, et al., 2007). El resultado de esta actividad es un archivo *.jar que contiene clases de entidad
implementadas y mapeadas.
Pruebas unitarias del mapeo de entidades: Teniendo implementadas y mapeadas las entidades, es
necesario realizar las siguientes pruebas a cada entidad para garantizar que el mapeo quedó realizado
correctamente: (1) Probar mapeo de la entidad con la tabla asociada, (2) Probar las relaciones de la entidad
con otras entidades, (3) Probar la inserción de un registro en la tabla de persistencia asociada, (4) Probar la

34
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

eliminación de un registro de la tabla de persistencia, (5) Probar la actualización de un registro de la tabla de

persistencia.
Implementación de Servicios: En esta fase se crean los servicios que va prestar el componente a sus
clientes. Según (Guijun & Casey K, 2004) “un servicio es una unidad software que encapsula
funcionalidades del negocio y provee las funcionalidades a sus clientes a través de interfaces bien definidas y
publicadas”. La forma de implementar los servicios en Java EE 5 es utilizando el framework EJB 3.0 y
JBoss Seam. Estos frameworks contienen un conjunto de clases que facilitan la tarea de implementación,
distribución y utilización de EJBs. En (Debu, et al., 2007) se encuentra una guía detallada. Los resultados de
esta fase son: (1) Archivo *.jar con las clases implementadas, (2) Archivo *.ear con los EJBs y archivos de
configuración necesarios para utilizar los EJBs, (3) Archivo ds.xml, datasource que define la cadena de
conexión con la base de datos.
Pruebas funcionales de los servicios: Esta fase busca garantizar que los servicios fueron implementados
correctamente y que cumplen con la totalidad de los requisitos funcionales planteados. Las pruebas se
pueden realizar por medio de una aplicación de prueba donde se implementen y ejecuten los métodos
necesarios a ser probados o usando JUnit.
Implementación de los servicios web: Esta fase expone los servicios creados por medio de los EJBs en
la fase anterior como servicios Web. Se exportan como servicio Web aquellos métodos que no manejen una
transacción que necesite interacción permanente con el usuario y no requieran mantener su estado o el estado
de los procesos que esté manejando el cliente o el usuario. La implementación en java de los servicios Web
se hace por medio de la API JAX-WS (Java API para XML Web Services). En el JEE Tutorial (Oracle - Sun
Microsystem, 2008) se encuentra un capítulo dedicado a la creación de servicios web usando este API.
Pruebas funcionales de los servicios web: Para probar los servicios Web es necesario crear un cliente
que consuma los servicios Web y verificar que los resultados obtenidos son los esperados. Se deben realizar
pruebas remotas y con clientes implementados en otras plataformas.
Implementación de los componentes personalizados para la interfaz de usuario (Componentes UI):
La idea fundamental de desarrollar componentes UI, es implementar como componentes JSF o Richfaces, la
lógica del negocio que se pueda reutilizar en muchas aplicaciones de una forma sencilla y transparente para
el desarrollador. Con este tipo de componentes, se ahorran muchas líneas de código y esfuerzos, pues no se
repite el mismo código de una aplicación a otra. La implementación se realizó usando los planteamientos
realizados por SERGEY en (Sergey, 2008).

Figura 7. Utilización del componente UI.

En (1) se incluye la referencia al repositorio de componentes UI de la DSI.
En (2) se incluye la etiqueta richfaces del componente desarrollado.
En la DSI se implementó el componente UI de consulta de Unidades Académico Administrativas que
permite seleccionar una unidad de un listado y realizar la consulta por cualquiera de los siguientes criterios:
Tipo de Unidad, Clase de Unidad, Fondo Presupuestal, Unidad Superior, Código de Unidad, Parte del
nombre de la Unidad. Al seleccionar cualquiera de los criterios propuestos se realiza la consulta y
automáticamente se muestran los resultados para que el usuario seleccione la unidad que desea. La forma de
utilizar el componente implementado se puede apreciar en la siguiente figura 7. Al ejecutarse la aplicación se
muestra, un cuadro de texto donde se relaciona la unidad seleccionada y un icono para abrir la ventana de
búsqueda. Al pulsar sobre el icono se muestran los criterios de consulta, al seleccionar cualquier criterio, se
consulta la base de datos y se trae le información correspondiente como se puede apreciar en la figura 8.

35
 ISBN: 978-972-8939-96-0 © 2013 IADIS

Figura 8. Componente UI de consulta de unidades al ejecutar la consulta.

Se puede resaltar que el ingeniero desarrollador no tiene que realizar la consulta para llenar los combos o
las listas desplegables mostradas en la figura anterior, como tampoco tiene que implementar la consulta por
los criterios seleccionados, esa implementación viene encapsulada en el componente.
Pruebas de los componentes UI: Las pruebas de los componentes personalizados para la interfaz de
usuario se enfocan en verificar que la implementación del componente quedó bien realizada y cumple con los
requisitos planteados y así garantizar que el componente UI se puede utilizar en diversos proyectos de
desarrollo de software y que funciona correctamente.
Especificación del componente software reutilizable: La especificación del componente software
reutilizable se divide en las siguientes partes: (1) Documentación: Se realiza utilizando etiquetas para el
manejador JavaDoc, que describen las funcionalidades implementadas en las clases java que hacen parte del
componente. (2) Ficha de especificación: En la cual se describe la especificación de implementación, de
recursos, de factores internos al componente y la especificación no funcional del componente. Se basa
principalmente en los estudios hechos por (Geisterfer & Ghosh, 2006). Ver tabla 3. (3) Modelos UML: Se
adjuntan los modelos UML realizados en la creación del componente. Se incluye: Diagrama de casos de uso,
modelo del dominio del problema, diagramas de clases y el diagrama de componentes del área de aplicación.
Tabla 3. Ficha de especificación.

FICHA DE ESPECIFICACIÓN DEL COMPONENTE

NOMBRE: Nombre del componente. FECHA: Fecha de creación VERSIÓN: 1.0
DESCRIPCIÓN: Descripción breve del componente, que hace, las funcionalidades que maneja, domino de aplicación al
cual pertenece.
PALABRAS CLAVE: Palabras que identifiquen al componente.
ESPECIFICACIÓN DE IMPLEMENTACIÓN
TECNOLOGIA: Tecnología en la cual fue implementado el componente, junto con sus versiones.
INTERFAZ: Nombre de la interfaz que define los servicios del componente.
SERVICIOS: Define la signatura de los servicios que presta el componente.
PRECONDICIONES: Definen los requisitos que se deben cumplir antes de entrar a utilizar el componente.
POSTCONDICIONES: Definen los requisitos que se deben cumplir después de utilizar el componente.
DEPENDENCIAS: Hace referencia a los elementos de los cuales el componente depende para su correcto funcionamiento.
ESPECIFICACIÓN NO FUNCIONAL
RECURSOS: Define los recursos necesarios para que el componente funcione correctamente.
RESTRICCIONES: Define los alcances del componente, qué hace, hasta donde lo hace y qué no hace.
NIVEL DE SEGURIDAD: Define el grado de seguridad manejada por el componente, también define las recomendaciones de
seguridad que se deben tener en cuenta al utilizar el componente.
RENDIMIENTO: Se especifican las recomendaciones de configuración o de cualquier tipo para que el rendimiento del
componente sea el mejor. Se especifica también si tiene limitaciones de concurrencia que puedan afectar
el rendimiento.
PORTABILIDAD: Define las plataformas en las cuales funciona correctamente el componente.
GRADO DE Es el puntaje obtenido por el componente en el análisis de reutilización realizado en el modelo de
REUTILIZACIÓN: selección de componentes.
DISTRIBUCIÓN: Define la forma como se debe instalar y utilizar el componente en las plataformas soportadas.

36
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Esquema de Distribución del componente: Terminada la implementación del componente se realiza su

distribución para hacerlo disponible a los desarrolladores de software. Primero se crea un archivo build.xml
con la herramienta ANT que permite instalar el componente en un servidor de aplicaciones de forma
automática, y finalmente, empaquetar los archivos en un archivo *.tar o *.zip para ser colocado en el servidor
de versiones de la empresa de desarrollo.

3. CONCLUSIONES
Esta investigación especifica de forma detallada el proceso de desarrollo de componentes software
reutilizables que ha sido adoptada en los desarrollos de la DSI, probando así su impacto y relevancia. Se pudo
evidenciar que la utilización del proceso de desarrollo de componentes software reutilizables la
competitividad de la DSI mejora en aspectos como: (1) La producción de aplicaciones de software se hace
con mayor rapidez, teniendo en cuenta que los componentes reutilizables ya creados, se usan en muchos
proyectos de desarrollo sin necesidad de volver a implementarlos para cada sistema. (2) Los sistemas
informáticos ofrecidos a la comunidad universitaria que se basan en componentes creados, probados y
estandarizados, realizados con las mejores prácticas de desarrollo, logran una mejor calidad en el producto.
Como resultado se planteó un procedimiento para el desarrollo, prueba y especificación de componentes
basados en el estándar Java EE 5; se detalló la forma de implementar el mapeo de entidades, la elaboración
de servicios del área de aplicación utilizando EJBs 3.0, se hizo una exposición de esos servicios como
servicios Web y componentes personalizados para la interfaz de usuario, permitiendo aplicar los conceptos
en un entorno de desarrollo y puesta en marcha de aplicaciones de software en una organización de tamaño
considerable como la UIS. Además, como valores agregados, resultado de la investigación se hicieron
aportes fundamentales a la DSI. Entre los que se cuentan: la definición de estándares y buenas prácticas para
los nuevos desarrollos utilizando la especificación Java EE 5.

REFERENCIAS
Bruegge, B. & Dutoit, A. 2004. Object-Oriented Software Engineering Using UML, pattern and Java. 2 ed. Prentice
Hall.
Debu, P., Reza, R. & Lane, D, 2007. EJB in action. Manning Publications Co..
Geisterfer, C. M. & Ghosh, S., 2006. Software component specification: A study in perspective of component selection
and reuse. Proceedings of the fifth international conference on comercia-off-the-shelf COTS - based software
systems.
Guijun, W. & Casey K, F., 2004. Architecture, paradigms ans their influences and impacts on component-based software
systems. Hawaii , Proceedings of 37th International Conference on System Sciences.
Iribarnes Martinez, L. F., 2003. Un modelo de mediación para el desarrollo de software basado en componentes. España:
Tesis Doctoral - Universidad de Malaga.
Oracle - Sun Microsystem, 2008. The jave EE 5 tutorial.
Pressman, R. S., 2002. Ingeniería del Software un enfoque práctico. 5 ed. Mc. Graw Hill.
Sergey, S., 2008. CDK developer guide. Jboss comunity.
Vera Rivera, F. . H. & Rojas Morales, F. A., 2008. Propuesta de un proceso de desarrollo de componentes software
reutilizables. Revista Gerencia Tecnológica Informática - GTI, 7(19).
Weitzenfeld, A., 2002. Ingeniería del software orientada a objetos, teoría y práctica con UML y Java. Mexico: Itam.

37
ISBN: 978-972-8939-96-0 © 2013 IADIS

UMA REVISÃO SISTEMÁTICA DA LITERATURA SOBRE

MÉTRICAS DE SOFTWARE

Darlan Florêncio de Arruda, José Gilson de A. T. Filho e Ricardo de Lima Chen*

Escola Politécnica da Universidade de Pernambuco – UPE/POLI
*Faculdade dos Guararapes - FG

RESUMO
Métricas de software é um assunto que vem sendo estudado há anos e ainda hoje desperta interesses de pesquisadores.
Talvez pelo fato de ainda não ter atingido sua maturidade. Para esse trabalho foi aplicado o processo de revisão
sistemática da literatura sobre métricas de software com o intuito de responder à algumas questões de pesquisa com o
objetivo de contextualizar acerca do estado da arte do assunto estudado. Na fase inicial da revisão sistemática a string de
busca aplicada retornou 559 trabalhos totalizando as cinco bases científicas selecionadas para a pesquisa. Após aplicação
dos critérios de seleção nas fases da condução da revisão, apenas 22 trabalhos foram selecionados. Através da revisão
sistemática da literatura foi possível identificar e analisar conceitos, características, dentre outras informações que
contribuíram para aprimorar os estudos na área e enriquecer o seu conteúdo teórico.

PALAVRAS-CHAVE
Métricas de Software; Engenharia de Software; Estimativas; Revisão Sistemática da Literatura.

1. INTRODUÇÃO
Métricas de software é um assunto estudado há mais de 30 anos. No entanto, mal conseguiu se estabelecer
em sua amplitude na engenharia de software. A principal razão para isto, é que a maioria das atividades de
métricas de software não têm apresentado o requisito mais importante: fornecer informações para apoiar a
tomada de decisão gerencial quantitativa, durante o ciclo de vida do software. [FENTON e NEIL, 2000].
De acordo com [Singh et al 2012], métricas de software, medem diferentes aspectos da complexidade do
software e, portanto, desempenham um papel importante na análise e melhoria da qualidade do software. Tais
aspectos, abrangem área de qualidade, estimativa, custos, processos e assim por diante. Para [Yu e Zhou,
2012] métricas de software é a medida - geralmente usando classificações numéricas - para quantificar
algumas características ou atributos de uma entidade de software. Medições típicas incluem a qualidade dos
códigos de fonte, o processo de desenvolvimento e as aplicações realizadas.
Já Goodman [1993] define métricas de software como sendo, a contínua aplicação de técnicas baseadas
na medição para o processo de desenvolvimento de software e para os seus produtos fornecendo informação
de gestão relevante e, juntamente com a utilização dessas técnicas visando melhorar o processo e os seus
produtos. Sendo assim, o uso de métricas se mostra importante e relevante para os gestores e analista de
projetos de software. Entretanto realizar estimativas e prover métricas de software tem se tornado um grande
desafio na área de TI [MOLØKKEN, 2003]. A incapacidade da indústria em estimar software com precisão,
resulta em derrapagens orçamentais e atrasos nas entregas que minam em confiança e desgaste. Estimar
tamanho de um software é uma atividade complexa, cujos resultados devem ser constantemente atualizado
levando em consideração quantitativos reais de todo o ciclo de vida [MOLØKKEN, 2003].
A construção de uma solução que de fato produza resultados significativos e que seja de fácil aplicação e
entendimento ainda está sendo buscada, inclusive por empresas de TI [MOLØKKEN, 2003]. Sendo assim,
métricas de software se mostra como um assunto relevante e que merece certa atenção em relação a seus
conceitos, características e uso. Visando entender os conceitos gerais e possíveis estudos realizados na
indústria sobre métricas de software, tem-se como objetivo responder as seguintes questões de pesquisa:

38
 Conferência IADIS Ibero-Americana Computação Aplicada 2013



(RQ1) Qual o estado da arte atual em relação estudos sobre métricas de software?


(RQ2) Quais o tipos de métricas de software identificadas na revisão sistemática da literatura?


(RQ3) Existem ferramentas que dão suporte ao uso de métricas de software?
(RQ4) Existem publicações científicas de estudos sobre métricas de software realizados na
indústria (empresas e/ou consultorias de TI)?
Para alcançar o objetivo desse trabalho, foi aplicado o método de revisão sistemática da literatura com o
intuito de conseguir as respostas para esse questões de pesquisa. A aplicação da string de busca nas bases
científicas selecionadas resultou em 559 trabalhos, dentre os quais foram classificados após etapas de
seleção, 22 trabalhos relevantes para a pesquisa.
O restante do trabalho está organizado da seguinte forma: Na seção 2 é abordado o referencial teórico da
pesquisa. A seção 3 aborda acerca do processo de aplicação da revisão sistemática da literatura. Na seção 4
são descritos e analisados os resultados alcançados com a pesquisa. E por fim, a seção 5 traz as conclusões do
estudo realizado.

2. MÉTRICAS DE SOFTWARE
Métricas de softwares possibilitam realizar uma das atividades mais fundamentais do processo de
gerenciamento de projetos, que é o planejamento, porém para planejar é necessário estimar, entretanto
estimar softwares continua sendo um grande desafio na área de TI. A construção de uma solução que de fato
produza resultados significativos e que seja de fácil aplicação e entendimento ainda está sendo buscada
[MOLØKKEN, 2003].
Métricas de software servem como suporte a mediação em diversas tipos de atividades e aplicações, como
por exemplo utilização de métricas no contexto organizacional de gestão do conhecimento, no apoio a
sistemas baseados em computação em nuvem, no suporte a medição de complexidade do software, medição
de esforço de trabalho, métricas no contexto de custos em manutenção corretiva de software, como suporte a
mensuração de qualidade em aplicações de negócios, inspeção de software e métricas no contexto de
qualidade e testes de software, dentre outros [Goldoni e Oliveira, 2009; Singh et al 2012; Li et al. 2010;
Curtis et al, 2011; Salger et al 2009; Barros et al. 2008].
Goodman [1993] define métricas de software como sendo, a contínua aplicação de técnicas baseadas na
medição para o processo de desenvolvimento de software e para os seus produtos fornecendo informação de
gestão relevante e, juntamente com a utilização dessas técnicas visando melhorar o processo e os seus
produtos. De acordo com SINGH et al. (2011), as métricas de software são definidas em dois tipos, a
métricas de produto e as métricas de processos.
Métricas de Produto, também são conhecidos como as métricas de qualidade e são usadas para medir as
propriedades do software e ajudam a melhorar a qualidade dos diferentes componentes e existentes do
sistema [SINGH et al. 2011]. Pode-se destacar como exemplos de métricas de produto: Métrica de esforço,
métrica de tamanho, métrica de volume, métrica de complexidade, contagem de pontos de função, contagem
de Tokens, métricas de funcionalidades, métricas de desempenho, métricas de usabilidade, métricas de custo
e tamanho e métricas de estilo, por exemplo.
Já as métricas de processo são conhecidos como métricas de gestão e utilizados para medir as
propriedades do processo que é usado para se obter o software. Métricas de processo incluem as métricas de
custo e esforços, métricas de progresso e métricas de reutilização. Métricas de processo ajuda na previsão do
tamanho do sistema final e determinar se um projeto sobre a execução de acordo com o cronograma [SINGH
et al. 2011]. Como métricas de processos podemos citar: métricas de reusabilidade, métricas de
produtividade, métrica média de ponto de estória por desenvolvedor por dia, métricas de recursos, dentre
outros,
Comparar e avaliar as capacidades e produtividade das pessoas envolvidas no desenvolvimento de
software, elaboração das especificações de qualidade de software, verificação do cumprimento de requisitos
de sistemas de software e especificações, tomada de decisões sobre outra divisão do módulo complexo que
deve ser feito ou não e obtenção de um ideia sobre a complexidade do software - são algumas das
características de métricas que são consideradas vantagens de acordo com [SINGH et al. 2011].

39
ISBN: 978-972-8939-96-0 © 2013 IADIS

Ao mesmo tempo que as métricas de software possuem certas vantagens que ajudam no auxílio de
algumas atividades dentro do processo de desenvolvimento, também possuem certas limitações em relação ao
seu uso. Pode-se destacar como sendo limitação, o fato da aplicação de métricas de software nem sempre ser
fácil e, em alguns casos, pode ser difícil e dispendioso. A verificação e justificação de métricas de software é
baseada em dados históricos / empíricos, cuja validade é difícil de verificar. A maioria dos modelos de
previsão baseiam-se em estimativas de certas variáveis que muitas vezes não são conhecidas exatamente. São
úteis para o gerenciamento de produtos de software, mas não para avaliar o desempenho da equipe técnica
[SINGH et al 2011].
No processo de utilização de métricas de software, deve-se garantir algumas propriedades para que as
mesmas sejam utilizada da maneira mais eficiente possível. As métricas devem ser facilmente entendidas,
calculadas e testadas, devem gerar uma sugestão de melhoria nas estratégias, bem como é de grande
importância que a métrica seja obtida o mais cedo possível no processo de desenvolvimento do software
[COSTA et al 2013]. Sendo assim, Guarizzo [2008] comenta que a utilização de métricas de software tem
seu papel muito importante dentro da engenharia de software, especialmente na gerência de projetos de
software, seja qual for à metodologia ou tipo a ser utilizada. Ela é analisada por gerentes de projetos de
software e coletada pelos engenheiros de software.

3. REVISÃO SISTEMÁTICA DA LITERATURA

A revisão de literatura é o processo central que apoia todo projeto de pesquisa, permitindo que o
conhecimento científico seja identificado de forma a possibilitar uma pesquisa planejada, evitando esforços
duplicados e repetição de erros anteriores [DYBA et al, 2005]. Assim, se a revisão de literatura não for
conduzida de uma forma confiável e abrangente, os resultados possuirão pouco valor científico, uma vez que
ela pode ter sido guiada por interesses pessoais, ocasionando resultados pouco confiáveis [MAFRA E
TRAVASSOS, 2006].
Ainda Segundo Mafra e Travassos [2006], a revisão sistemática atua como um meio para identificar,
avaliar e interpretar toda pesquisa relevante e disponível sobre uma questão de pesquisa específica, tópico ou
fenômeno de interesse, fazendo uso de uma metodologia de revisão que seja confiável, rigorosa e que permita
auditagem.
Estabelece um processo formal para conduzir a investigação, evitando a introdução de vieses da revisão
de literatura informal, dando maior credibilidade à pesquisa em andamento [SAMPAIO E MANCINE, 2007].
Dessa forma, a revisão sistemática pode ser melhor entendida como uma sintetização de resultados obtidos
do estado da arte da literatura, sendo um tipo de estudo retrospectivo e secundário, isto é, a revisão é
usualmente desenhada e conduzida após a publicação de muitos estudos experimentais (primários) sobre o
tema [SAMPAIO E MANCINE, 2007].
O caminho trilhado na revisão sistemática envolve uma série de atividades importantes, atreladas a um
conjunto de fases dentro do processo de condução, estabelecidos dentro de um protocolo, que norteará de
forma sistematizada todo o processo de condução da revisão. Três fases do processo de condução:
planejamento da revisão, execução da revisão e análise e divulgação dos resultados. Outros autores abordam
as atividades de forma um pouco diferente, porém convergentes [BIOLCHINI et al, 2005; PAI et al., 2004;
LITTEL et al., 2008]. As fases de condução da revisão e as atividades utilizadas neste trabalho foram
adaptadas dos trabalhos citados anteriormente.

3.1 Condução da Revisão Sistemática da Literatura

O processo de revisão sistemática da literatura foi iniciado a partir da criação de um modelo de protocolo de
revisão, onde no mesmo constam informações essenciais para a realização da revisão sistemática. O
protocolo foi especificado para identificar os estudos potenciais que possam contribuir para a realização do
objetivo desse trabalho descrito no inicialmente.

40
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

3.1.1 Planejamento da Revisão Sistemática da Literatura

Na fase de planejamento foram estabelecidos os objetivos da pesquisa e foi criado um protocolo de revisão
adaptado do modelo de Biolchini et al. (2005) e Kitchenham et al. (2004), contendo itens como: identificação
e seleção das bases de dados, métodos de busca e palavras-chave, estratégia de busca e critérios de inclusão e
exclusão dos estudos (Biolchini et al., 2005; Kitchenham et al., 2004; Dyba et al., 2005), seguindo ainda a
mesma lógica de atividades propostas e adaptadas por Pai et al. (2004) e Littell et al. (2008). As subseções a
seguir trazem de forma objetiva informações que foram estabelecidas no protocolo de pesquisa.
3.1.2 Termos, Sinônimos e String de Busca
Devido ao foco da pesquisa abranger um conteúdo de relevância mundial, evidentemente as palavras-chaves
foram formuladas no idioma universal Inglês. Também escolheu-se utilizar as palavras chaves nesse idioma,
devido as fontes de buscas serem internacionais e possuírem publicações na língua inglesa. Os termos e
sinônimos para as palavras-chave identificadas são apresentadas a seguir.
Termo: Métricas em projetos de software (Sinônimos: Metrics, Software Metrics, Software estimation
Metrics, Software Indicators, Software Development Metrics, Software Project Metrics, Software
Engineering Metrics)
Termo: Empresas de TI (Sinônimos: IT Companies, IT Consulting)
Com base nos sinônimos identificados e definidos anteriormente, buscou- se estabelecer a string de
buscas. A string foi aplicada de acordo com a disponibilidade técnica de estratégia de busca do mecanismo a
ser utilizado, podendo sofrer pequenas adaptações para que o mecanismo consiga executá-las. A string
definida é apresentada a seguir.
((Metrics OR "Software Metrics" OR "Software estimation metrics" OR
"Software Indicators" OR "Software Development Metrics" OR
"Software Projects Metrics" OR "Software Engineering Metrics") AND
("IT Companies" OR "IT consulting"))
Essa string de busca definida passou por testes pilotos e foi aprimorada de acordo com os resultados
obtidos, sendo esta, a quarta versão da string definida – aprimorada e restrita para o objetivo dessa pesquisa:
Levantar estudos significativos com abordagem geral e estudos realizados na indústria (empresas e
consultorias de TI) com o objetivo de responder as questões de pesquisas definidas para esse trabalho.
3.1.3 Fontes de Busca
Para a seleção de fontes de busca para a aplicação da revisão sistemática, levou- se em consideração alguns

 As fontes devem possuir mecanismos avançados de busca que permitam a combinação de

critérios, sendo eles:

palavras-chave com os termos relacionais “AND” e “OR”;

 As fontes devem ser de renome científico-acadêmico mundial, com exceção de sites web de
universidades, caso seja necessário, que contenham os mecanismos de busca exigidos;
Através desses critérios chegou-se a uma lista de fontes que serão utilizadas para aplicação das strings de
busca para realização da revisão sistemática da literatura. São elas: IEEE Xplorer, Sciece Direct, Scopus, El
Compendex e ACM Digital Library.
3.1.4 Critérios de Inclusão e Exclusão

 Artigos Científicos publicados entre 2008 e 2013;

Os seguintes critérios de inclusão nortearam a seleção dos trabalhos:

 As fontes devem disponibilizar os trabalhos na íntegra, ou seja, completo;

 Devem ser escritos em inglês;
 Para trabalhos que representam os mesmo resultados de pesquisa, será aceito o trabalho que
apresentar os dados de forma mais completa.

 Não satisfizeram os critérios de inclusão;

Foram excluídos os trabalhos que:

 Teses e dissertações que não foram disponibilizadas em forma de artigo.

41
ISBN: 978-972-8939-96-0 © 2013 IADIS

3.1.5 Seleção dos Trabalhos

Inicialmente, os critérios de inclusão e exclusão foram aplicados no título, onde os estudos que tiveram o seu
título considerado relevante ao contexto da pesquisa foram potencialmente selecionado para a próxima etapa,
e os demais excluídos. Essa etapa resultou em 88 artigos selecionados. Em seguida, os estudos
pré-selecionados na etapa anterior tiveram seus resumos (abstract) e palavras chaves lidos, depois foram
selecionados para a próxima etapa e fichados no formulário de condução da revisão os estudos considerados
relevantes, os demais foram excluídos. Nessa etapa foram selecionados 25 trabalhos. Por fim, mais um filtro
foi aplicado, dessa vez, analisando a introdução e a conclusão dos trabalhos pré-selecionados até o momento.
Essa etapa resultou em 22 trabalhos aceitos. Sendo 5 desses inclusos de forma manual.
A seção a seguir aborda a análise dos resultados obtidos com a aplicação da revisão sistemática da
literatura. A análise será feita de forma separada e organizada de acordo com as questões de pesquisa
estabelecidas para esse trabalho.

4. APRESENTAÇÃO DOS RESULTADOS OBTIDOS

Nessa seção, são apresentados os resultados para as questões de pesquisa, parte motivadora desse trabalho.
Foram selecionados 22 trabalhos relevantes com a aplicação da revisão sistemática da literatura. Nenhum
critério de qualidade é estabelecido em relação aos trabalhos selecionados, pois, acredita-se que os critérios
de seleção por si só, já garantem certa qualidade em relação aos trabalhos selecionados. A seguir são
apresentadas os resultados por questão de pesquisa estabelecida no protocolo desta pesquisa.

4.1 (RQ1) Qual o Estado da Arte Atual em Relação Estudos sobre Métricas de
Software?
O estado da arte sobre métricas de software compreendem trabalhos publicados que abordam métricas no
contexto organizacional de gestão do conhecimento [Goldoni e Oliveira, 2009], Métricas de apoio a sistemas
baseados em computação em nuvem e software as a service [Singh et al 2012], Métricas para medição de
complexidade do software [Singh et al. 2012],[Li et al. 2010], métricas no contexto de custos em manutenção
corretiva de software [Li et al. 2010], Métricas como suporte a mensuração de qualidade em aplicações de
negócios [Curtis et al, 2011], Métricas no contexto de inspeção de software [Salger et al 2009], Métricas no
contexto de qualidade e Testes de Software [Kanij et al 2012], Métricas de software de grande escala [Barros
et al. 2008], Métricas de desenvolvimento baseadas em resultados [THAMMARAK, e INTAKOSUM, 2011]
dentre outros. As respostas para as outras questões ajudarão ainda mais, a contextualizar acerca do estado da
arte de trabalhos relacionados ao assunto métricas de software, visto que abordam aspectos relevantes ao
estado da arte.

4.2 (RQ2) Quais o Tipos de Métricas de Software Identificadas na Revisão

Sistemática da Literatura?
Vários dos trabalhos selecionados abordam alguns tipos de métricas que são usadas em projeto de software.
Para melhor apresentar os resultados, os autores criaram um quadro com informações relevantes como
resposta a essa questão de pesquisa. As informações no quadro estão organizadas da seguinte forma: Nome
da métrica e Referência. As métricas identificadas foram organizadas de acordo com o tipo de classificação
de métricas: Métricas de produto e Métricas de processo e por último uma extensão das métricas de produto
que são focadas em orientação à objetos. Devido ao limite de páginas estabelecido, não foi possível comentar
e detalhar cada métrica identificada.

42
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Quadro 1. Métricas de Software identificadas na RSL

Tipo da Métrica Nome da métrica Referência
Métrica de Esforço Base (Effort Base Metric) / Métrica de
Tamanho / Métrica de Volume / Métrica de Complexidade / [Barros et al. 2008]
Métrica de Número de Variáveis / Métrica de Número de [Wu et al. 2009]
Métrica de Produto Variáveis / Métrica Número de Linhas de Código (NLOC) / [Singh et al. 2012]
Métrica Número de milhares de instruções fonte entregues [Li et al. 2010]
(KDSI) / Contagem de Pontos de Função (FPC) / Métrica [Singh et al. 2011]
Absoluta / Métrica de Relação / Contagem de Tokens / Métrica [Curtis et al. 2011]
de qualidade de produto / Número de Defeitos / Severidade do [Kanij et a. 2012]
Defeito.

Número de Classe / Número de pacotes [Johari e Kaur, 2011]

Métricas de Produto Número de Métodos por classe / Número de Atributos / Métrica [Singh et al. 2011]
Orientados a Objetos de Acoplamento entre classes e objetos / Falta de Coesão de [Yu e Zhou, 2010]
Métodos (LCOM) / Profundidade de árvore de herança (DIT) / [Singh et al. 2011]
Número de Filhos (NOC)

Métricas de Reusabilidade / Métricas de Processos / Métricas de [Nerurkar, N.W. 2010]

Métricas de Processo Recursos / Métrica de Produtividade /Métrica Média de ponto de [Singh et al. 2012]
estória por desenvolvedor por dia [Wu et al. 2009]
[Swaminathan, e Jain
2010]

4.3 (RQ3) Existem Ferramentas que dão Suporte ao Uso de Métricas de

Software?
Muitos são os tipos de métricas disponíveis na literatura, que abrangem e suportam diversas atividades dentro
dos processo de desenvolvimento de software. Sendo assim, não basta apenas ter as métricas, é preciso saber
usá-las. Para isso existem diversas ferramentas que podem ajudar os gestores de software a usar as métricas
da forma mais adequada e automatizada possível.
Dentre os 22 trabalhos selecionados, apenas 1 trouxe resultados significativos que pudessem ser usados
como subsídio para a contextualização da resposta a essa questão de pesquisa. O trabalho intitulado
“Comparing Software Metrics Tools” dos autores Rüdiger Lincke, Jonas Lundberg e Welf Löwe da
Universidade da Suécia, publicado em 2008, traz um levantamento de algumas ferramentas que são usadas
com suporte para o uso de métricas, em especial, uso de métricas de produtos (Orientação a objetos).
[LINCKE et al 2008] destaca as seguintes ferramenta: Anlyst4j, CCCC, Chidamber & Kemmerers Java
Metrics, Dependency Finder, Eclipse Metrics Plugin 1.3.6, Eclipse Metrics 3.4, OOMeter, Understand for
Java e VizzAnalyzer.
Todas as ferramentas apresentadas acima, dão suporte ao uso de métricas como Linhas de Código,
Número de Métodos, Número de Filhos, Métricas de Acoplamento entre classes e objetos, Falta de Coesão
de Métodos (LCOM), Profundidade de árvore de herança (DIT), Métodos ponderados por classe e Resposta
para uma Classe. A seguir serão abordados aspectos e conceito relevantes em relação a estudos realizados na
indústria sobre métricas de software.

4.4 (RQ4) Existem Publicações Científicas de Estudos sobre Métricas de

Software Realizados na Indústria (Empresas e/ou Consultorias de TI)?
Através da análise dos trabalhos selecionados através da revisão sistemática, foi possível identificar algumas
publicações que tratam de estudos de caso realizados na indústria. Assim, podemos afirmar que existem sim
publicações científicas de estudos sobre métricas de software realizados na indústria em diversos segmentos
de atuação. Não é objetivo desse trabalho apresentar os resultados obtidos dos estudos presentes nos
trabalhos que serão apresentados – e sim, mostrar que estudos vem sendo feito na indústria nos últimos anos.
Os parágrafos a seguir apresentam cada um desses estudos.

43
ISBN: 978-972-8939-96-0 © 2013 IADIS

[Curtis et al, 2011] No trabalho intitulado - “An Evaluation of the Internal Quality of Business
Applications: Does Size Matter?” - procurou-se realizar um estudo com o intuito de verificar a qualidade
interna, estrutural de 288 aplicativos de negócios que compreendem 108 milhões de linhas de código
recolhidos de 75 empresas de oito segmentos da indústria, incluindo bancos, seguros, telecomunicações,
energia, manufatura, consultoria de TI, software e governo. Estas aplicações foram submetidos a uma análise
estática que avalia a qualidade dentro e entre os componentes do aplicativo que podem ser codificadas em
diferentes idiomas. A análise consiste em avaliar a aplicação com um repositório de mais de 900 regras de
boas práticas de arquitetura e codificação. Os resultados são apresentados para as medidas de segurança,
desempenho e mutabilidade. O efeito do tamanho na qualidade é avaliada, bem como a capacidade modular a
reduzir o impacto do tamanho é sugerido pelos resultados. Métricas de qualidade interna foram mostradas
para correlacionar com os critérios, tais como o esforço de manutenção e detecção de defeitos. O dados
analisados nesse estudo compreendem segurança, performance, atributos de mudança (changeability) e efeito
de tamanho na qualidade.
[Li et al 2010] No trabalho intitulado - “Cost Drivers of Software Corrective Maitenance: An Empirical
Study in Two Companies” - os autores tiveram como objetivo realizar um estudo em duas organizações que
desenvolvem software com o intuito de conhecer os fatores que têm maior influência sobre as atividades de
manutenção corretiva do software. Foram analisados nesse estudo, as atividades e esforços de corrigir 810
defeitos de software em uma empresa de software norueguesa e 577 defeitos de software em outra empresa.
Nesse estudo foi realizada uma comparação entre os perfis de defeitos de acordo com o esforço de correção
de defeitos. Também foram analisadas as descrições de defeitos e discussões gravadas entre desenvolvedores
no curso de correção de defeitos, a fim de entender o que levou ao alto custo de corrigir alguns tipos de
defeitos. Foi possível identificar nesse estudo que o tamanho e complexidade do software a ser mantido, a
experiência do mantenedor e suporte a processos e ferramentas são fatores de custo mais influentes da
manutenção corretiva. Nesse estudo foram utilizadas métricas de produtos como tamanho, esforço, tempo,
complexidade e métricas para estimativa de manutenção adaptativa.
[Kanij et al 2012] No trabalho intitulado - “Performance Assessment Metrics for Software Testers” - os
autores contextualizam sobre problema e/ou a dificuldade em se avaliar o desempenho de testadores de
software. Diante dessa dificuldade os autores realizaram um survey com 104 testadores profissionais de
software da índia e dos Estados Unidos, com o objetivo de identificar através do ponto de vista deles, a
importância de fatores proposto que possam ajudar o gestores a mensurar o desempenho dos testadores de
software. Esses fatores contribuem para geração de métricas. Nesse trabalho, foram abordadas métricas de
qualidade que poderão servir como fatores que contribuem para avaliação de desempenho dos testados como,
número de defeitos reportados por dia, qualidade do report do defeito, número de defeitos graves
identificados, rigorosidade dos testes e número de bugs reportados em produção.
[Goldoni e Oliveira, 2009] No trabalho intitulado – “Knowledge management metrics in software
development companies in Brazil” – as autoras objetivaram analisar métricas de avaliação da gestão do
conhecimento em empresa de software a partir da percepção dos gestores e dos usuários. Essa pesquisa foi
aplicada em duas empresas brasileiras de TI. Usou-se métricas identificadas na literatura e associadas as fases
do processo de gestão do conhecimento: criação, armazenamento, disseminação, utilização e medição.
Algumas métricas foram identificadas de processos, como número de discussões em grupos relacionadas a
processos/produtos de inovação, número de documentos armazenados em sistemas, qualidade do
conhecimento armazenado, número de usuários do sistema, dentre outras – E métricas de resultados como,
média de resolução de problema, Redução do tempo de ciclo do produto, Nível de aprendizagem individual,
Aumento do patrimônio líquido, etc. Percebe-se que esse trabalho preocupou-se não em analisar métricas
relacionadas a atividades diretas do processo de desenvolvimento de software, mas sim em analisar métricas
relacionadas a circulação de conhecimento entre as equipes de desenvolvimento de software, que pode ser
considerado fator importante na era da informação.
[Bouwers et al 2013] No trabalho intitulado – “Evaluating Usefulness of Software Metrics: an Industrial
Experience Report” – os autores contextualizam a cerca de uma problemática em relação a falta de análise
estrutural e mostra que para muitas métricas, avaliação consiste em verificar as propriedades matemáticas da
métrica, a investigar o comportamento da métrica para um certo número de sistemas de código aberto ou
comparando o valor da métrica contra outras métricas quantificando atributos de qualidade relacionados. Para
Bouwers et al [2013] infelizmente, uma análise estrutural da utilidade de métricas num ambiente de avaliação
do mundo real é frequentemente ausente, sendo que essa avaliação é importante para compreender as
situações em que uma métrica pode ser aplicada, para identificar áreas de possíveis melhorias, para explorar

44
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

problemas gerais detectadas pelos indicadores e definir estratégias de solução geralmente aplicáveis. Sendo
assim, o objetivo desse trabalho foi executar tal análise para duas métricas de nível de arquitetura, balanço de
componentes e perfis de dependência, através da análise dos desafios envolvidos na aplicação dessas
métricas em um ambiente industrial. Além disso, foi explorado a utilidade dos indicadores através de
entrevistas semiestruturadas com os avaliadores experientes. Foram documentadas as lições aprendidas, tanto
para a aplicação destas métricas específicas, bem como para o método de avaliação de indicadores na prática.

5. CONCLUSÕES
Através da revisão sistemática da literatura, foi possível identificar diversos trabalhos relevantes que nos
ajudou a identificar possíveis respostas para as questões de pesquisa estabelecidas. Através dessa revisão, foi
constatado que existem diversos estudos sobre métricas de software realizados com várias aplicações
diferentes que vão desde software convencionais, passam por computação em nuvem, e chegam à gestão do
conhecimento. Foi possível perceber que 5 trabalhos dentre os selecionados, abordavam como metodologia a
aplicação de estudos de casos aplicados na indústria.
Também ficou evidente que as métricas de software proporcionam diversas vantagens para que as utiliza,
entretanto não deve-se ressaltar que mesmo possibilitando diversas vantagens, essa abordagem oferece
algumas limitações. Esse trabalho mostrou através do levantamento realizado os mais diversos tipos de
métricas hoje utilizadas sendo possível levantar pelo menos 28 tipos de métricas classificadas em dois
grandes grupos: produtos e processos. Inicialmente, não é possível apontar se esse número de métricas
levantadas na literatura é um número alto ou baixo, mas percebe-se que é um número significante. Além de
algumas ferramentas de suporte ao uso de métricas de produtos orientados a objetos.
Pode-se afirmar que vários estudos sobre métricas de software foram realizados na indústria, tornando
possível identificar e analisar conceitos, características, dentre outras informações a fim de aprimorar os
estudos na área e enriquecer o seu conteúdo teórico.

REFERÊNCIAS
BARROS, Rodrigo C.; RUIZ, Duncan D.; BASGALUPP, Márcio P.; BECKER, Karin. Issues on Estimating Software
Metrics in a Large Software Operation. 32nd Annual IEEE Software Engineering Workshop, 2008.
BIOLCHINI, Jorge; MIAN, Paula Gomes; NATALI, Ana Candida Cruz; TRAVASSOS, Guilherme Horta. Systematic
Review in Software Engineering. Technical Report. PESC – COPPE/UFRJ, 2005.
BOUWERS, Eric; DEURSEN, Arie Van; VISSER, Joost. Evaluating Usefulness of Software Metrics - an Industrial
Experience Report -.Software Engineering Research Group, Department of Software Technology, Faculty of
Electrical Engineering, Mathematics and Computer Science, Delft University of Technology, 2013.
COSTA et al 2013. Utilizando métricas para dimensionar um software. Disponível
em:<http://www.csi.uneb.br/engenharia_de_software/anexos/Artigo>MetricasdeSoftware.pdf>. Acessado em 20 de
Julho de 2013.
CURTIS, Bill; SAPPIDI, Jay; SUBRAMAYAM; Jintendra. An Evaluation of the Internal Quality of Business
Applications: Does Size Matter?. 33rd International Conference on Software Engineering, Honolulu, Hawaii, 2011.
DYBA, T.; KAMPENES, V.; SJOBERG, D. A Systematic Review of Statistical Power in Software Engineering
Experiments. Journal of Information and Software Technology, v. 1, n. 11, 2005.
FENTON, Norman E; NEIL, Martin. Software Metrics: A roadmap. ICSE '00 Proceedings of the Conference on The
Future of Software Engineering, 2000.
GOLDONI, Vanessa; OLIVEIRA, Mírian. Knowledge management metrics in software development companies in
Brazil. JOURNAL OF KNOWLEDGE MANAGEMENT, 2009.
GOODMAN, Paul. Practical Implementation of Software Metrics, McGraw Hill, London, 1993.
JOHARI, Kalpana; KAUR, Arvinder. Effect of software evolution on software metrics: An open source case study. ACM
SIGSOFT Software Engineering Notes, 2011.
KANIJ, Tanjila; MERKEL, Robert; GRUNDY, John. Performance Assessment Metrics for Software Testers. CHASE
2012, Zurich, Switzerland, 2012.

45
ISBN: 978-972-8939-96-0 © 2013 IADIS

LI, Jingyue; STALHANE, Tor; KRISTIANSEN, Jan M. W.; CONRADI, Reidar. Cost Drivers of Software Corrective
Maitenance: An Empirical Study in Two Companies. 26th IEEE International Conference on Software Maintenance
in Timișoara, 2010
LINCKE, Rudiger, LUNDBERG, Jonas, LOWE Welf. Comparing Software Metrics Tools. ISSTA’08, July 20–24,
Seattle, Washington, USA, 2008.
LITTLEFAIR, Tim. CCCC - C and C++ Code Counter. A free software tool for measurement of source code related
metrics by Tim Littlefair. Disponível em: <http://cccc.sourceforge.net/>. Acessado em 05 de Julho de 2013.
MAFRA, S.N., TRAVASSOS, G.H. Estudos Primários e Secundários Apoiando a Busca por Evidência em Engenharia
de Software, Relatório Técnico ES-687/06. COPPE/UFRJ. Rio de Janeiro: Brasil, 2006.
MOLØKKEN, Kjetil; JØRGENSEN, Magne; A Review of Surveys on Software Effort Estimation. Proceedings of the
2003 International Symposium on Empirical Software Engineering, ISESE '03, IEEE Computer Society, pp.223-230,
2003.
NERURKAR, N.W. Assessment of Reusability in Aspect-Oriented Systems using Fuzzy Logic. ACM SIGSOFT
Software Engineering Notes, 2010.
SALGER, Frank; ENGELS, Gregor; HOLFMANN, Alexander. Inspection Effectiveness for Different Quality Attributes
of Software Requirement Specifications: An Industrial Case Study. 2009 ICSE Workshop on Software Quality, 2009.
SAMPAIO, R.F; MANCINI, M.C. Estudos de Revisão Sistemática: Um guia para síntese criteriosa da evidência
científica. Revista Brasileira de Fisioterapia. São Carlos, 2007.
SINGH, Gurdev; SINGH, Dilbag; SINGH, Vkram. A Study of Software Metrics. IJCEM International Journal of
Computational Engineering & Management, Vol. 11, January 2011.
SINGH, Ram; BHAGAT, Avinash; KUMAR, Navdeep. Generalization of Software Metrics on Software as a Service
(SaaS). International Conference on Computing Sciences, 2012.
SPINELLIS. ckjm — Chidamber and Kemerer Java Metrics. Disponível em: <http://www.spinellis.gr/sw/ckjm/> .
Acessado em 06 de Julho de 2013.
SWAMINATHAN, Balachander; JAIN, Karuna. Implementing the Lean concepts of Continuous Improvement and Flow
on an Agile Software Development Project - An Industrial Case Study. Agile India 2012.
YU, Sheng; ZHOU, Shijie. A Survey on Metric of Software Complexity. Information Management and Engineering
(ICIME), 2010
WU, Ching-seh; CHANG, Wei-chun; SETHI, Ishwar, K. A Metric-Based Multi-Agent System for Software Project
Management. Eigth IEEE/ACIS International Conference on Computer and Information Science, 2009.

46
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

HERRAMIENTA DE MEDICION DE LA SATISFACCION

DE LAS NECESIDADES DE LOS USUARIOS DE SISTEMAS
INFORMATICOS. EXPERIENCIAS CON USUARIOS

Marisa Panizzi, Diego Arenas, Damián Gimenez, Elisa Licata Caruso y Mayra Carabajal
Universidad de Morón, Facultad de Informática, Ciencias de la Comunicación y Técnicas Especiales - Cabildo 134,
(B1708JPD) Morón, Buenos Aires, Argentina

RESUMEN
En un primer estadio de la línea de investigación, se ha diseñado una herramienta para la medición de la satisfacción de
las necesidades de los usuarios de un sistema informático de gestión empresarial. Esta herramienta permite la medición
de dos variables, la satisfacción socio y la satisfacción técnica de sus necesidades. En la medición de la satisfacción socio,
se contemplaron las siguientes dimensiones: satisfacción en la empresa, satisfacción en el puesto de trabajo, satisfacción
con el medio ambiente, comunicación y participación. En la medición de la satisfacción técnica, se contemplaron las
siguientes dimensiones: requerimientos funcionales, requerimientos no funcionales y las características del usuario del SI
(Sistema Informático). La herramienta en cuestión se compone de dos cuestionarios, el cuestionario que permite la
medición del enfoque socio denominado ¨MES¨ y el cuestionario que permite la medición del enfoque técnico
denominado ¨MET¨. Actualmente, nos encontramos aplicando la herramienta a usuarios de sistemas informáticos de
diferentes industrias, para realizar los ajustes necesarios a la misma como así también para generar evidencias empíricas
de su aplicación.

PALABRAS CLAVE
Implantación de sistemas informáticos/Satisfacción de usuarios de Sistemas informáticos/Medición de
satisfacción/Requerimientos funcionales/Requerimientos No funcionales/enfoque socio técnico.

1. INTRODUCCION
Los usuarios de los sistemas informáticos, son empleados de una organización podrían considerarse expertos
en su trabajo diario, ellos pueden aceptar o rechazar un nuevo sistema de trabajo en este caso se puede
considerar a un sistema informático como tal.
Recopilando experiencias en diferentes industrias, hemos detectado que en las organizaciones, el capital
humano todavía aún no forma parte de todos los sistemas de trabajo. Las personas tienen valores, actitudes y
necesidades psicológicas, el abandono de sus intereses vinculados al trabajo puede ocasionar una situación de
cambio que perjudique a la organización. En lugar de producirse el cambio deseado por la organización
tendiente a aumentar la eficiencia con la incorporación del nuevo sistema informático (SI), se produce la no
satisfacción por parte de los usuarios ocasionando la no aceptación en el uso del nuevo sistema, generando
nuevamente un fracaso en la implantación del mismo.
Para la construcción de la herramienta de medición se revisaron los siguientes antecedentes respecto a las
metodologías de implementación de sistemas de información y modelos de cambio organizacional, se han
analizado las siguientes propuestas: la Metodología ETHICS de Enid Mumford (Mumford, 2003), el modelo
de cambio organizacional de Kolb/Frohman (Kolb, 1970), el modelo “Diamond Model" de Leavitt (Leavitt,
1965), la Metodología de Sistemas Suaves de Checkland (Checkland, 1993) entre otras.
Se revisaron marcos teóricos de las Ciencias del Comportamiento, entre los cuales se pueden mencionar:
la Teoría del Cima Laboral de Likert (Likert, 1967), teorías sobre la motivación, entre ellas, la jerarquía de
necesidades de Maslow (Maslow, 1991), las teorías X y Y de McGregor (Robbins, 2005) y la teoría de la
motivación e higiene de Herzberg (Robbins, 2005).

47
ISBN: 978-972-8939-96-0 © 2013 IADIS

Se revisaron algunos estándares, enfoques y prácticas, entre ellos: el concepto de Usabilidad definido en
el estándar ISO 9241(Grau, 2000), la disciplina denominada HCI (Human-Computer Interaction) (Grau,
2005) las ISO 9000:2000 e ISO 9004 (ISO 9004:2009, 2009).
En una primera instancia del trabajo de investigación, se considero relevante revisar conceptos asociados
a la satisfacción de un empleado en su puesto de trabajo y adoptamos la definición propuesta por Mumford
(Mumford, 2003). A partir de esta definición, se elaboró la siguiente enunciación:
¨Un usuario de un sistema informático (denominado USI) se encuentra satisfecho cuando el sistema
informático (denominado SI) le permite realizar su trabajo plenamente¨ (Estayno, M. et al, 2011).
Con el propósito de ofrecer herramientas para la toma de decisiones de los profesionales responsables de
llevar a cabo el proceso de implementación de los sistemas informáticos o aquellos roles que trabajan
vinculados a los clientes/usuarios es que se consideró el desarrollo de esta herramienta.

2. DESARROLLO
Para el diseño de la herramienta se siguieron los lineamientos generales de construcción de un instrumento de
medición propuesto por Hernández Sampieri Roberto, Fernández Collado Carlos y Baptista Lucio Pilar
(Hernández Sampieri, 2006) De la revisión y análisis del procedimiento mencionado, se ha realizado un
ajuste en función de lo que se necesitaba en el presente trabajo, se presenta en la Figura 1.

Paso 1 Paso 2 Paso 3 Paso 4 Paso 5

Construcción del Prueba Piloto: Versión final
1.1. Identificar el Decisiones: instrumento, en -Confiabilidad -Revisar el
conjunto o - Tipo y formato función de las Inicial instrumento y
dominio de del instrumento decisiones tomadas -Validez inicial hacer cambios.
conceptos o de medición (incluye la -Entrevistas a los -Construir la
variables a medir. - Utilizar uno generación de todos participantes para versión definitiva.
1.2. Identificar los existente, los ítems y evaluar
indicadores de adaptarlo o categorías, así -Ensayo
cada variable. construir uno como la
nuevo. codificación y los
- Contexto de niveles de medición
administración de los reactivos).

Figura 1. Pasos para la construcción de la herramienta de medición (Panizzi, 2012)

La herramienta preliminar de medición de satisfacción de las necesidades de los usuarios se construye
basándose en el enfoque socio-técnico.
Por cuestiones de practicidad para el uso de la herramienta de medición como así también el
procesamiento y análisis de los datos, dicha herramienta se compone de dos cuestionarios, el cuestionario
MES (medición de enfoque socio) y el cuestionario MET (medición del enfoque técnico).
En la Tabla 1., se presenta la variable, sus dimensiones, la nomenclatura propuesta para cada dimensión y
los indicadores del MES (Medición del Enfoque Socio). La composición de la variable para la medición
socio resultó del análisis de los diferentes aportes que las ciencias de la conducta ofrecen al comportamiento
organizacional, se pueden mencionar la psicología, la sociología, la psicología social, normas como la ISO
9004-2000.
El cuestionario para realizar la medición técnica se denominará MET (Medición del Enfoque Técnico). Se
tomó como marco de referencia el IEEE/ANSI 830-1998 (IEEE ANSI 830-1998,1998) para la medición
técnica de la satisfaccion de las necesidades de los usuarios. Se consideraron los requerimientos funcionales,
los requerimientos no funcionales y las características del usuario del SI (sistema informático).
En la Tabla 2.; se presenta la variable, sus dimensiones, la nomenclatura propuesta para cada dimensión
y los indicadores del MET (Medición del Enfoque Técnico).

48
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Tabla 1. Variable, sus dimensiones, la nomenclatura propuesta para cada dimensión y los indicadores del MES (Medición
del Enfoque Socio).
Variable Dimensión Nomenclatura Indicador
a de la
medir Dimensión
Satisfacción en la MES1 Grado en que los empleados de una organización (en
empresa este trabajo, serían los usuarios) se sienten involucrados
Satisfacción socio de las necesidades de los usuarios

con la misma.
Satisfacción en el MES2 Grado en que los empleados (usuarios) de una
puesto de trabajo organización perciben el “ajuste” entre lo que buscan
en sus puestos de trabajo (necesidades, expectativas y
aspiraciones) y lo que la organización requiere que
hagan en sus puestos (requerimientos de conocimientos,
habilidades y competencias)” (Mumford E.., 1983)
Satisfacción con el MES3 Valor percibido por los empleados (usuarios) respecto al
medio ambiente ambiente de trabajo adecuado
(combinación de factores humanos y físicos) brindado
por la organización. (ISO 9004)
Comunicación MES4 Grado en que los empleados (usuarios) perciben los
flujos de información dentro de la organización.
Especialmente todos aquellos flujos relacionados al
diseño de los sistemas informáticos.
Participación MES5 Nivel en que los empleados (usuarios) perciben su aporte
en el Diseño de un Sistema Informático. Cabe aclarar
que se toma en cuenta el principio de Diseño
Participativo.
Tabla 2. Variable, sus dimensiones, la nomenclatura propuesta para cada dimensión y los indicadores del MET (Medición
del Enfoque Técnico).
Variable Dimensión Nomenclatura Indicador
a de la Dimensión
medir
Requerimientos MET1 Grado en que los usuarios de una
Funcionales organización perciben que el SI realiza
Satisfacción técnica de las necesidades de los

las operaciones que requieren para

realizar su trabajo.
Requerimientos No MET2 Nivel en que los usuarios perciben las
Funcionales cualidades no funcionales del SI que
utilizan para realizar su trabajo.
usuarios

Características del MET3 Nivel de educación, experiencia del

usuario dominio de la aplicación y
especialización técnica que los usuarios
perciben haber recibido.

Con el propósito de realizar una medición que permita un análisis de la satisfacción técnica con un mayor
nivel de granularidad, se ha decidido dividir las dimensiones Requerimientos No funcionales y
Características del usuario en sub dimensiones. La Dimensión Requerimientos No Funcionales, se presenta
en la Tabla 3. Dimensión Requerimientos No Funcionales y Sub dimensiones, la nomenclatura propuesta
para cada sub dimensión y sus sub indicadores. En la Tabla 4., se presenta la Dimensión Características del
usuario, Sub dimensiones, la nomenclatura propuesta para cada sub dimensión y los sub indicadores.

49
ISBN: 978-972-8939-96-0 © 2013 IADIS

Tabla 3. Dimensión Requerimientos No Funcionales, Sub dimensiones, la nomenclatura propuesta para cada sub
dimensión y los sub indicadores.
Dimensión Sub Dimensión Nomenclatura Sub Indicador
de la Sub dimensión

Interfaces de usuario MET2.1. Nivel percibido por los usuarios respecto

a los formatos de las pantallas, a la
distribución de las pantallas, a los menús,
a los mensajes de error, a los contenidos
de las salidas, a los formatos de los datos
de las salidas, a los contenidos de los
Requerimientos
menús, a los formatos de los datos de los
menús del SI.
No Restricciones de Diseño MET2.2. Grado en que los usuarios perciben los
formatos de los informes, las
Funcionales convenciones de los nombres, los
procedimientos contables que se reflejan
en el SI como así también las pistas de
auditoría que mantiene el SI.
Requerimientos de MET2.3. Nivel percibido por los usuarios respecto
Performance al tiempo de respuesta de una operación
que pueden realizar con el SI (períodos
de trabajo normal y períodos de sobre
carga de trabajo).
Operación MET2.4. Nivel percibido por los usuarios respecto
a cómo el SI protege los datos y a cómo
se
recuperan.
Interfaces de software MET2.5. Grado percibido por los usuarios
respecto a las interfaces de software.
Tabla 4. Dimensión Características del usuario, Sub dimensiones, la nomenclatura propuesta para cada sub dimensión y
los sub indicadores.
Nomenclatura
Dimensión Sub Dimensión de la Sub dimensión Sub indicador

Educación MET3.1. Grado percibido por los usuarios

Características respecto a la capacitación que
requiere para el uso del SI.
del Experiencia MET3.2. Nivel percibido por los usuarios
respecto a la experiencia requerida
usuario del dominio del SI.
Especialización técnica MET3.3. Nivel percibido por los usuarios
respecto a la necesidad de
especialización técnica para el uso
del SI.

Se sometió a prueba el instrumento de medición (Cuestionario MES y Cuestionario MET) y se realizaron

las pruebas que se describen en la Tabla 5, para asegurar la validez, confiabilidad u objetividad de la
herramienta de medición. Estas pruebas demostraron que el instrumento refleja verazmente el nivel de
satisfacción de la muestra de la comunidad usuaria.

50
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Tabla 5. Procedimiento aplicado para someter a prueba el instrumento de medición (Panizzi, 2012)

Prueba Objetivo de la ¿Qué permitió? ¿Qué resultó?

realizada prueba

Prueba piloto inicial
Validación de caso único
Validez del Someter a prueba el Una versión mejorada de la
instrumento instrumento de medición herramienta de medición
Evaluar las condiciones de
aplicación y los
procedimientos
involucrados

Prueba piloto 2 Método de
estabilidad (test – retest).
Confiabilidad Realizar dos veces la
del instrumento medición con versión 2 de
la herramienta al mismo
grupo de usuarios
La herramienta tiene un nivel de
confiabilidad aceptable ya que hay
consistencia entre los resultados y
reflejan la realidad de la satisfacción
de la muestra.

Estrategia de validación de Validez y Adquirir el conocimiento La herramienta de medición tiene un

experto (face valitidy) Confiabilidad de la experta respecto a la nivel de confiabilidad aceptable ya
del instrumento satisfacción de los usuarios que hay consistencia entre los
resultados obtenidos y las pruebas
anteriores

Todas las anteriores Objetividad del Evaluar la La herramienta de medición no se

instrumento estandarización del
instrumento de medición,
se mantuvieron las mismas
instrucciones y
condiciones para los
participantes como así
también el cálculo de los
datos obtenidos.
encuentra sesgada ni influenciada
por un único investigador.
Se ha realizado una adecuada
revisión de bibliografía sobre el
tema, ha sido consensuada con el
equipo de investigación.

Para aplicar la herramienta de medición en una muestra de usuarios, se requiere aplicar el proceso que se
detalla a continuación (Panizzi, 2012):
1. Identificar a los usuarios de un determinado sistema informático y los requerimientos funcionales del
sistema informático o del módulo que utilizan. Se propone la matriz que se presenta en la Tabla 6.
2. Identificar los interfaces de entrada y-o salida y su relación con los requerimientos funcionales del
sistema informático o del módulo. Se propone la matriz que se presenta en la Tabla 7.
3. Relevar las estrategias de comunicación y participación respecto a los cambios de los sistemas
informáticos que se desarrollan en la organización. Esta información es necesario para la ponderación
de algunas preguntas del cuestionario de medición socio.
4. En el caso de que el sistema informático no sea un sistema contable, se debe eliminar la pregunta del
cuestionario de medición de enfoque técnico relacionada a este tema.
5. Definir la técnica que se empleara para la administración de los cuestionarios (autoadministrado
grupal, individual, vía mail, etc.).

51
ISBN: 978-972-8939-96-0 © 2013 IADIS

Tabla 6. Matriz de relación Usuario del Sistema Informático & Requerimiento Funcional del Sistema Informático (RF del
SI) (Panizzi, 2012).

Usuario 1

Usuario 2

Usuario 3

Usuario 4

Usuario n
Requerimientos Funcionales del SI
/Usuarios del Sistema de Informático
RF 1
RF 2
RF 3
RF 4
RF n

Tabla 7. Matriz de relación de los Requerimientos Funcionales & Entradas y Salidas del Sistema Informático (Panizzi,
2012)

Sistema Informático
Interface 1

Interface 2

Interface 3

Interface n
Entradas
y Salidas
(Interfaces
de software)
Requerimiento Funcional 1 E

Requerimiento Funcional 2 E/S

Requerimiento Funcional 3 E S
Requerimiento Funcional n E/S

El procesamiento de los datos obtenidos de las mediciones y su cálculo se ha realizado en planillas de

cálculo, se presenta un extracto de la hoja de cálculo en la Figura 2.

Figura 2. Resultados de los cálculos de una medición técnica.

En la Tabla 8, se sintetizan las mediciones realizadas a algunas comunidades de usuarios de sistemas
informáticos de gestión empresarial de diferentes sectores industriales.

52
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Tabla 8. Resultados de experiencias con usuarios de sistemas informáticos.

Casos de
Caso 1 Caso 2 Caso 3 Caso 4 Caso 5
validación
Tipo de Administración
Privada Privada Privada Privada
Organización Pública
Desarrollado a Desarrollado a
Tipo de sistema Parametrizado Desarrollado a Medida Parametrizado
Medida Medida
Sistema de
Gestión de
Expedientes – Sistema de SAP – Sistema
Función del Módulo Sistema de Atención de Administración de COBALT
SAP - Modulo Ventas
sistema Consulta de Colas Consultas de Módulo
Expedientes y Equipos Importación
tablas de
parametría.
Telecomunicacione
Sector industrial Gestión Comercial Telecomunicaciones Comercial
s
Cantidad de
40 6 20 20 9
usuarios
Técnica
empleada para la Autoadministra Autoadministrado Autoadministrado Autoadministrado Autoadministra
administración do Grupal individual individual individual do individual
del instrumento
Resultados de la
75,00%
medición de la 63,08% 74,43% 74,63%
satisfacción socio
Resultados de la
medición de la 79,89%
73,23% 81,41% 76,95%
satisfacción
técnica
El indicador de
Todos los indicadores Socio
satisfacción comunicación Los indicadores de
El indicador de tienen bajo porcentaje de
y participación tiene un la satisfacción
capacitación y satisfacción. Y los
bajo porcentaje de Técnica están bajos
participación indicadores de la
satisfacción en los en cuanto a las
Conclusiones tiene un bajo satisfacción Técnica:
usuarios, si bien es bajo Características del
porcentaje de Características del Usuario
respecto de los otros Usuario –
satisfacción en – Educación y Experiencia
porcentajes, éste es Capacitación
los usuarios tienen un bajo porcentaje de
aceptable porque es recibida
satisfacción de usuarios
mayor a 70%
Estado de la
Realizada Realizada Realizada Realizada En proceso
validación

Para el desarrollo de esta línea de investigación, desde un primer momento se quiso reflexionar sobre las
personas que reciben el producto resultante de la ingeniería de software, los usuarios.
Se ha decidido conocer con exactitud cuáles son las cuestiones con las que los usuarios se sienten no
satisfechos con un sistema informático, para poder conocerlas y analizarlas es que se pensó en la herramienta
de medición propuesta.
Se comparten algunas experiencias realizadas con usuarios a través de la aplicación de la herramienta de
medición e invitamos a la comunidad científica y a la industria del software a aumentarlas.

3. CONCLUSION
En este trabajo, partimos de la premisa que usuario satisfecho aceptará el cambio y usará el nuevo sistema
informático si ha participado en la definición del mismo. Esta satisfacción se robustece si además ha sido
escuchado de cuáles son sus necesidades de satisfacción a cubrir, independientemente del tipo de
participación (directa o indirecta). Esto, dió origen a evaluar estas necesidades de satisfacción de los usuarios
no solamente desde el punto de vista técnico, sino también desde el punto de vista social.

53
ISBN: 978-972-8939-96-0 © 2013 IADIS

Al haber aplicado la herramienta de medición en distintos casos se concluye que posee un nivel de
confiabilidad, validez y objetividad aceptable ya que demostró consistencia entre los resultados obtenidos,
reflejando veracidad de satisfacción de la muestra.
Las experiencias realizadas nos han permitido confirmar una vez más, que parte de los fracasos de las
implantaciones de los sistemas informáticos se deben a aspectos sociales y no solo a aspectos técnicos.
Se tiene planificado ampliar la generación de evidencias mediante la herramienta fuera del contexto
nacional, para lo cual habrá que adaptar el lenguaje al país en que se aplicaría la misma.
Se tiene planificado experimentar con diferentes maneras de administración de la herramienta para poder
evaluar las diferentes reacciones de los usuarios.
De esta línea de investigación se desprendió una sub línea, orientada hacia la Ingeniería del
conocimiento, en la cual nos encontramos trabajando en la generación de un prototipo de sistema experto en
el cual la base de conocimiento sea el juicio de los expertos.

AGRADECIMIENTOS
En primer lugar, quiero agradecer a Marcelo Estayno, por el desarrollo de mi tesis de Maestría en Informática
y mi desarrollo profesional como investigadora. Y a mi equipo de investigación, Diego Arenas, Damián
Gimenez, Elisa Licata Caruso y Mayra Carabajal, quienes han avanzado con esta línea de investigación en
sus tesinas de grado.

REFERENCIAS
Checkland, P. 1993. Pensamiento de sistemas, práctica de sistemas. México: Megabyte - Grupo Noriega Editores.
Estayno, M. et. al, 2012, Aproximación a una Herramienta para la medición de la satisfacción de las necesidades de los
usuarios. XIV Workshop de Investigadores en Ciencias de la Computación. Misiones, Argentina, pp. 428-432
Estayno, M. et al, 2011, Medición socio-técnica de las implementaciones de los sistemas de información automatizados.
XIII Workshop de Investigadores en Ciencias de la Computación. Rosario. Argentina, pp. 514-518
Estayno, M. et. al, 2012, Prototipo de herramienta para la medición socio- técnica de la satisfacción de las necesidades de
los usuarios. XVIII Congreso Argentino de Ciencias de la Computación. Bahía Blanca, Argentina, pp. 1313-1322
Grau, X. F. Marco de integración de la usabilidad en el proceso de desarrollo de software. Tesis Doctoral . Departamento
de Lenguajes y Sistemas Informáticos e Ingeniería de Software. Facultad de Informática. Universidad Politécnica de
Madrid. (2005).
Grau, X. F. 2000. Principios Básicos de Usabilidad para Ingenieros de Software. V Jornadas de Ingeniería de Software y
Bases de Datos.Valladolid, España, pp. 39-46
Hernández Sampieri R. et al, 2006. Metodología de la investigación. México: Mc Graw Hill.
IEEE ANSI 830-1998. 1998. IEEE Recommended Practice for Software Requirements Specifications. USA: Institute of
Electrical and Electronics Engineers.
Kolb, D. et al. 1970. An Organization Development Approach to Consulting. Sloan Management Review , 51-65. ((pre-
1986); Fall 1970).
ISO 9004:2009. International Organization for Standardization. http://www.iso.org/iso/home/standards/management-
standards/iso_9000.htm
Mumford, E. 2003. Redesigning Human Systems. United States of America / United Kingdom: Information Science
Publishing.
Leavitt, H. J. 1965. Applied Organizational Change in Industry: Structural, Technological and Humanistic, Handbook of
Organizations. James G. March.
Likert, R. 1967. The Human Organization. McGraw Hill.
Maslow, A. 1991. Motivacion y Personalidad. España: Diaz de Santos.
McGregor. 1960. The Human Side of Enterprise. McGraw Hill.
Robbins S. et al, 2005. Administración (Octava ed.). Mexico: Pearson Educacion.
Panizzi, Marisa Daniela (2012). Propuesta de Recomendaciones para la implementación de Sistemas Informáticos. MS.
Tesis de Maestría en Informática. Universidad Nacional de La Matanza. 168 pp.

54
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

REDES NEURAIS APLICADAS NO RECONHECIMENTO

DE CARACTERES EM IMAGENS DE PLACAS
VEICULARES

Célio Hoepers e Max Pereira

Universidade do Sul de Santa Catarina – UNISUL - Av. José Acácio Moreira, 787 - Tubarão(SC)

RESUMO
Esse artigo descreve o desenvolvimento e apresenta um protótipo de uma aplicação de reconhecimento de placas de
veículos. O reconhecimento de placas veiculares tem como objetivo identificar, a partir de uma imagem, os caracteres
que compõem a placa do veículo presente na imagem. A aplicação foi desenvolvida utilizando técnicas de processamento
de imagens e análise de variação tonal para a localização da placa na imagem e para a segmentação dos caracteres e,
utiliza de redes neurais, para o reconhecimento de caracteres. A aplicação obteve 81% de acerto no reconhecimento dos
caracteres em teste executado com uma base de 357 fotos de veículos.

PALAVRAS CHAVE
Placas veiculares, Redes neurais, Variação tonal, Processamento de imagens.

1. INTRODUÇÃO
As informações obtidas através do reconhecimento de placas de automóveis podem ser utilizadas para
inúmeros fins, desde o monitoramento até a geração de estatísticas de tráfego. Essa tecnologia pode ser
aplicada em diversos setores, tanto em órgãos públicos como em empresas privadas. Podem ser citados
vários exemplos de aplicações possíveis para a ferramenta proposta como: Monitorar rodovias com a
finalidade de buscar carros roubados ou procurados pela polícia. Monitorar rodovias buscando identificar
veículos que estão com documentação irregular ou com débitos junto aos órgãos regulamentadores.
Monitorar rodovias para criar histórico de tráfego como, por exemplo, gerar estatísticas da quantidade e dos
tipos de veículos que trafegam na rodovia, podendo efetuar análises por períodos. Sendo possível também
identificar o tipo de tráfego da rodovia, como por exemplo, municipal, estadual, interestadual, possibilitando
assim auxiliar no planejamento da infraestrutura rodoviária e, ainda, monitorar a entrada e saída de veículos
em locais restritos como, por exemplo, estacionamento de empresas, supermercados, shoppings, entre outros.
Em abril de 2013 o número de veículos registrados no país atingiu 77.849.890 segundo levantamento do
Departamento Nacional de Trânsito (DENATRAN, 2013) e, ainda segundo Moreira (2011), em dez anos o
aumento acumulado foi de 119%, ou seja, mais 35 milhões de veículos chegaram às ruas no período. Com
base nesses números pode-se concluir que o monitoramento automatizado da crescente frota de veículos no
país se faz cada vez mais necessário.
Souza e Susin (2000) desenvolveram o projeto SIAV (Sistema de Identificação Automática de Veículos).
O projeto visa alcançar a capacidade de localizar e interpretar o conteúdo da placa de um veículo qualquer
através da utilização de técnicas de processamento de imagens e inteligência artificial. Para obter o resultado
esperado foram utilizados alguns algoritmos e técnicas, como por exemplo: Algoritmo de localização da
placa, técnicas de segmentação e redimensionamento dos caracteres encontrados e uma rede neural para
reconhecimento dos caracteres. O SIAV foi desenvolvido para Windows 95 utilizando a linguagem C++.
Após aperfeiçoamento, a versão SIAV 2.0 obteve 88,70% de acerto na localização da placa e 82,70% de
acerto no reconhecimento dos caracteres em testes feitos pelos autores do projeto.

55
ISBN: 978-972-8939-96-0 © 2013 IADIS

Guingo (2003) propõe um sistema que possa fazer o reconhecimento automático das placas dos
automóveis através da aplicação das técnicas de processamento de imagens e de inteligência computacional.
A estratégia adotada para a concepção e desenvolvimento do sistema é modular, dividida em seis fases, que
cobrem desde a tomada da imagem até o reconhecimento de cada um dos caracteres que compõem a placa.
Em alguns testes apresentados na dissertação observa-se um percentual de acerto de 86% em imagens com
qualidade boa, 78% em imagens com qualidade normal e 40% em imagens com qualidade ruim. Gualberto
(2010) divide o reconhecimento de imagens em 3 etapas: A primeira consiste na localização da placa. A
segunda consiste num pré-processamento da placa e, a terceira etapa, consiste em aplicar uma função de
Reconhecimento Ótico de Caracteres (OCR) a fim de identificar os caracteres. O projeto proposto pelo autor
se limita a realização da segunda e terceira etapa do reconhecimento.
É perceptível a necessidade de desenvolvimento de aplicações para automatizar a identificação de placas
veiculares. Os trabalhos publicados, em geral, apresentam uma combinação de técnicas de processamento de
imagem, aliada à técnicas de inteligência artificial. O objetivo desse artigo é descrever o método de
processamento da imagem, principalmente o reconhecimento da localização das placas nas imagens,
utilizando a técnica de variação tonal, bem como a descrição da estrutura de rede neural utilizada para o
reconhecimento dos caracteres e, com isso, apresentar os resultados obtidos.

2. MATERIAIS E MÉTODOS
O desenvolvimento da aplicação foi dividido em três etapas, sendo elas, a localização da placa na imagem, a
segmentação de caracteres e o reconhecimento óptico de caracteres. A metodologia de divisão do processo
nas três etapas foi baseada nas etapas seguidas por Trentini et al (2010).

2.1 Localização da Placa

Como para a realização do processamento da imagem não é necessário que a mesma seja colorida, em um
primeiro momento é aplicado um algoritmo de transformação para escala de cinza com o intuito de facilitar
as etapas de processamento da imagem e melhorar o desempenho dos algoritmos. Esse algoritmo utiliza as
coordenadas R, G, B da imagem para a transformação.
Para a conversão dentro da escala de cinza utilizou-se a abordagem YCoCg, citada por Malvar et al
(2008) como sendo um método de transformação de cor reversíveis para compressão de imagem. Para os
pixels de uma imagem em tons de cinza, R = G = B = Y, e Cg = Co = 0. O cálculo do YCoCg pode ser feito
utilizando as equações apresentadas por Rijsselbergen (2005):

Co = R - B
t = B + (Co >> 1) (1)
Cg = G - t
Y = t + (Cg >> 1)

Para transformar a imagem do formato RGB em escala de cinza é atribuído o valor encontrado para Y
(luminância), que representa a intensidade de cinza na abordagem YCoCg, aos atributos R, G e B de cada
pixel. Nessa transformação as cores dos pixels, que são representadas pelo Co (crominância laranja) e Cg
(crominância verde), são ignoradas.
2.1.1 Análise de Variação Tonal
Após a transformação para a escala de cinza, buscou-se criar um gráfico de variação tonal da imagem. As
técnicas desenvolvidas para criação de gráfico de variação tonal e quantização foram inspiradas nos conceitos
de amostragem e quantização. Essas técnicas são utilizadas no processo de digitalização de sinais analógico
(conversão analógico/digital), tais como sinais de áudio e vídeo [Fernandes e Panazio, 2009].
O gráfico de variação tonal de uma linha representa, no eixo x, os pixels da linha da imagem e, no eixo y,
seu valor no padrão RGB de 0 a 255, da imagem em escala de cinza. Para efeito de melhor visualização e
entendimento do gráfico foi invertido os valores RGB do eixo y do gráfico, considerado o valor 0 como
branco e o valor 255 como preto, ficando assim, o oposto do padrão RGB. No gráfico da Figura 1a é possível

56
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

observar nitidamente uma alta variação tonal dos locais onde se encontram as placas. No gráfico da Figura 1b
é possível observar uma área da imagem que não possui placa, portanto não possui a alta variação tonal
característica de uma placa.

Figuras 1a e 1b. Variação tonal de uma placa (1a) e variação tonal sem a presença da placa (1b)
Após a quantização da variação tonal é aplicada uma normalização da quantização (Figura 2), visando
diminuir a quantidade de blocos. Esse processo visa unir os blocos consecutivos de aumento ou diminuição
da variação tonal. O uso dessa técnica melhora a precisão dos métodos que analisam os blocos em busca das
características de variação tonal das placas, pois une alguns dos blocos que não caracterizam a presença de
um caractere na imagem.

Figura 2. Variação tonal quantizada e normalizada

A etapa de detecção de regiões candidatas (placas na imagem) normalmente encontra mais de uma região
que possui variação tonal característica da presença de uma placa. Assim, se torna necessária à análise de
todas essas regiões em busca da que mais se caracteriza como sendo uma placa de fato. A escolha da região é
baseada na análise de duas características, sendo elas, a altura dos blocos e as dimensões da região:
O cálculo da diferença de tamanho (dt) da dimensão da placa comparada a dimensão esperada para uma
placa é feito utilizando a equação 2, onde x é a largura da placa, y é a altura da placa e 5,5 é o valor definido,
durante experimentos realizados, como o ideal para a divisão de x/y de uma placa veicular.
dt = |5,5 - x/y| (2)

57
ISBN: 978-972-8939-96-0 © 2013 IADIS

O cálculo do desvio padrão de altura dos blocos é calculado para cada linha da região, para mensurar a
homogeneidade dessa região, ou seja, quanto mais homogênea maior a possibilidade de presença da placa na
imagem. As equações 3 e 4, são utilizadas para esse fim, onde é a média de altura dos blocos, é o desvio
padrão de altura, é a altura de um bloco e é a quantidade de blocos, sendo que são considerados apenas
os blocos de subida entre o primeiro e o último bloco candidato da linha.

(3)

(4)
Depois de calculado o desvio padrão de altura dos blocos para todas as linhas da região é selecionado a
linha que possui o menor desvio padrão, e esse desvio padrão ( ) é somado a diferença de tamanho (dt)
calculada para a região. Esse cálculo é efetuado para todas as regiões, e a região com menor resultado será a
escolhida para ser segmentada.

2.2 Extração da Identificação da Placa e Binarização da Imagem

Para que a região possa ser processada com sucesso pela segmentação é necessário realizar uma expansão no
tamanho da região, que tem como objetivo aumentar o tamanho da região para que ela passe a abranger toda
a placa. A expansão é realizada aumentando a região em 50 % da sua altura original para cima e para baixo, e
em 20 % da sua largura original para a direita e para a esquerda. As figuras 3a e 3b mostram o resultado da
localização da região da placa e o resultado da execução do algoritmo de expansão respectivamente.

Figuras 3a e 3b. Resultado da aplicação do algoritmo de expansão

A binarização consiste em transformar uma imagem de tons de cinza para uma imagem que tenha apenas
pixels pretos e brancos, utilizando-se de um ponto de corte (threshold). (CONCI; MONTEIRO, 2004). O
cálculo do threshold de binarização da região se baseia na linha mediana da região e é efetuado através da
equação 5, onde, é o threshold, que consiste na média de altura dos blocos, é a altura de um bloco e é a
quantidade de blocos, sendo que são considerados para cálculo todos os blocos entre o primeiro e o último
bloco candidato da linha.
(5)

Na etapa de segmentação de caracteres o objetivo é extrair os 7 caracteres que são encontrados nas placas
e prepará-los para o envio a etapa de reconhecimento óptico dos caracteres. Alguns dos algoritmos da etapa
de segmentação necessitam dos valores referentes a densidade das linhas e/ou das colunas da imagem.
Conforme Trentini et al (2010) a densidade pode ser calculada somando-se a quantidade de pixels pretos
encontrados em determinada parte de uma imagem binarizada.
O processo de segmentação da imagem efetua cortes da imagem nos pontos em que a densidade da coluna
for menor que 10% da densidade máxima encontrada na imagem, considerando para a criação dos segmentos
os intervalos em que a densidade é superior ao delimitador. As figuras 4a e 4b mostram os resultados dos
processos de binarização e segmentação da imagem.

58
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Figuras 4a e 4b. Resultados obtidos após a binarização da imagem e segmentação dos caracteres
Quando a etapa de segmentação encontrar mais de 7 segmentos, conforme mostrado na figura 4b, é
necessário a aplicação de uma heurística para a seleção dos 7 segmentos que mais se aproximam das
características esperadas de um caractere. Para tal, foram definidas algumas regras para a análise dos
segmentos.
Primeiramente são selecionados os 7 elementos com altura mais próxima entre si, em seguida adicionado
ao conjunto os segmentos que possuem uma diferença de altura de até 5 pixels comparados a altura dos
elementos do conjunto anterior. Após essa etapa é efetuado uma análise das dimensões dos segmentos do
conjunto selecionado.
Para analisar as dimensões do segmento é feita a divisão de y/x, onde y é a altura do segmento e x é a
largura do segmento. O resultado esperado para essa equação é um valor entre 1,45 e 5,65 (valores
padronizados para caracteres das placas veiculares). Caso o resultado da equação não esteja nesse intervalo,
então é calculado o desvio de tamanho que é a distância do resultado obtido ao intervalo esperado. São
selecionados para a etapa de reconhecimento óptico 7 elementos com distância igual a 0 e/ou com menor
distância do padrão esperado da imagem.

2.3 Reconhecimento dos Caracteres

A etapa de reconhecimento foi desenvolvida utilizando duas redes neurais distintas seguindo a arquitetura
MultiLayer Perceptron com o algoritmo Backpropagation (HAYKIN, 2001). Houve a necessidade da
utilização de duas redes neurais, uma para reconhecer letras e outra para reconhecer números, pelo fato de
existirem letras e números com representações idênticas, como é o caso da letra ‘I’ e do número ‘1’ que
possuem a mesma representação. Essa abordagem também permite que os resultados das redes neurais sejam
mais precisos.
Para auxiliar o desenvolvimento das redes neurais foi utilizado o framework de redes neurais neuroph
(NEUROPH, 2012), que está publicado como uma biblioteca de código aberto sob a licença Apache 2.0 e é
de uso gratuito. O framework neuroph possui suporte para a arquitetura de rede neural Multi Layer
Perceptron com Backpropagation, entre diversas outras arquiteturas.
Os três primeiros segmentos de imagem são enviados para a rede neural de reconhecimento de letras e os
quatro segmentos subsequentes são enviados para a rede neural de reconhecimento de números, obtendo
assim os 7 dígitos que compõem uma placa de licença de veículo.
Ambas as redes neurais recebem como entrada, no treinamento e no reconhecimento, imagens nas
dimensões de 52x52 pixels, trabalham com o modelo de imagem preto e branco e utilizam a função sigmoide
(MITCHELL, 1997) como função de ativação. A rede possui camada de entrada de 2704 neurônios, camada
intermediária de 72 neurônios e camada de saída de 26 neurônios para letras e 10 neurônios para números.
Para o treinamento da rede neural de reconhecimento foi utilizado um modelo binarizado de letras e números
retirado da resolução do Contran (2007), que utiliza a fonte Mandatory.
Para prever as diversas situações de deformações e diferenças em que os caracteres podem chegar à rede
neural, é necessário a criação de mais modelos de treinamento. Com a finalidade de obter novos modelos de
treinamento foram aplicados, no modelo de letras e números do Contran, algoritmos de Erosão e Dilatação
(GONZALEZ; WOODS, 2010) e foi criado um modelo manipulado para prever algumas perdas de
informações da imagem que ocorrem na segmentação. Para o desenvolvimento dos filtros de erosão e
dilatação foi utilizada a API Java Advanced Imaging (ORACLE JAI API, 2007) que é uma API para
processamento de imagens e possui funções para o desenvolvimento dos filtros morfológicos.

59
ISBN: 978-972-8939-96-0 © 2013 IADIS

3. RESULTADOS E DISCUSSÕES
A interface para demonstração dos resultados obtidos foi desenvolvida utilizando as tecnologias Java SE e
Swing, conforme pode ser visto na Figura 5. Essa interface tem como objetivo apresentar o resultado da
aplicação de reconhecimento de placa.

Figura 5. Interface da aplicação

Para validar a precisão e o desempenho da aplicação foi efetuado um teste utilizando uma base de
imagens de 357 fotos coloridas de veículos, fotografadas a uma distância média de 1,00 a 2,00 metros do
veículo e com uma resolução de 1280x960 (1,3 M. pixels). A aplicação obteve acerto em 289 imagens e erro
em 68 imagens, isso corresponde a uma taxa de 81% de acerto no reconhecimento das placas. Na Tabela 1 há
detalhes sobre as taxas de acertos para cada etapa do reconhecimento.
Tabela 1. Resultados obtidos nas etapas do reconhecimento de caracteres

Etapa Acertos Percentual de

acerto
Localização da placa 332 de 357 (25 falhas) 93 %
Segmentação de caracteres 292 de 332 (40 falhas) 88 %
Reconhecimento dos caracteres 289 de 292 (3 falhas) 99 %
Resultado Geral 289 de 357 (68 falhas) 81 %

Entre as falhas ocorridas, 25 são falhas na localização da placa, decorrentes algumas vezes por conter
ambiente com muita variação tonal ou por confundir a variação tonal da placa com a variação tonal de
adesivos do carro. Outras 40 falhas são decorrentes de erro de segmentação dos caracteres, onde alguns deles
são causados pelo fato de a placa estar com alguns caracteres um pouco apagados e outros pelo fato de a
placa possuir parafusos, próximos aos caracteres, que acabam não sendo separados na segmentação. A etapa
de reconhecimento dos caracteres apresentou 3 falhas, sendo elas 2 no reconhecimento de letras e 1 no
reconhecimento de números. Ambas as falhas foram ocasionadas pelo efeito de inclinação presente na placa.

60
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Para verificar a compatibilidade com diversas resoluções, a aplicação foi testada utilizando dois cenários
onde foram obtidas imagens nas resoluções 2560x1920, 2048x1536, 1600x1200, 1280x960, 640x480. Nas
imagens com resolução 640x480 não foram obtidos sucesso do reconhecimento, apresentando falha na
segmentação dos caracteres devido a baixa resolução. Nas demais resoluções a aplicação se mostrou
compatível e não apresentou falhas, a mais, devido a diversidade de resolução.
A validação foi executada em um notebook com processador Core i5-2410M com 2,30 Ghz, 4 GB de
memória RAM e com sistema operacional Windows 7 Home Premium. Nesse cenário a aplicação efetuou o
reconhecimento das 357 imagens sequencialmente, sem a utilização de thread, em 5:10 minutos, sendo
aproximadamente 868 milissegundos por imagem.

4. CONCLUSÃO
A aplicação obtém uma taxa de acerto de 81% utilizando a base de imagens de validação, cumprindo assim a
expectativa obtida em torno do projeto. Esses resultados podem ser considerados bons e bastante
promissores. Os resultados mostram a eficácia dos métodos aplicados, porém, para que a aplicação possa ser
utilizada em ambientes reais ainda se torna necessário um estudo aplicando-a nesses ambientes para obter
dados mais realistas de precisão e desempenho. Também se torna necessário o estudo de melhorias nas
técnicas utilizadas na aplicação visando um aumento na precisão dos resultados. Contudo os resultados
obtidos já mostram que a aplicação tem grande potencial para poder vir a atender a diversas necessidades de
reconhecimento de placas de veículos.
Os pontos em que a aplicação apresenta a maior quantidade de falhas são nas etapas de segmentação dos
caracteres e localização da placa, que são etapas cruciais no sucesso do reconhecimento. Essas etapas
poderiam ser alvo de futuros estudos visando o aumento das taxas de acerto para aprimorar o desempenho da
aplicação, com o objetivo de aumentar a viabilidade do uso em ambientes reais.
Os resultados do trabalho desenvolvido chegaram próximos aos resultados de alguns trabalhos correlatos,
sendo até superiores em alguns casos. Porém não é possível fazer um comparativo justo entre os trabalhos,
pois a análise de percentual de sucesso é muito subjetiva, dependendo muito das características da base de
imagens que foi utilizada para fazer a validação e coleta de resultados do trabalho. Sendo assim, torna-se
muito susceptível a cometer equívocos, qualquer comparação dos percentuais de acerto do trabalho
desenvolvido com qualquer trabalho correlato apresentado.

REFERÊNCIAS
Conci, Aura; Monteiro, Leonardo Hiss, 2004. Reconhecimento De Placas De Veículos Por Imagem. In: III Congresso
Nacional de Engenharia. Belém, 2004, Belém, Brasil.
CONTRAN. Resolução no 241, de 22 de Junho de 2007. Dá nova redação aos incisos I e II do art. 6o, ao art. 11 e ao
Anexo da Resolução no 231/2007 – CONTRAN.
DENATRAN. Frota de veículos: Frota 2013. 2013. Disponível em: <http://www.denatran.gov.br/frota.htm>. Acesso em:
01 jun. 2013.
Fernandes, Tales Gouveia; Panazio, Aline Neves, 2009. Do analógico ao digital: amostragem, quantização e codificação.
In: II Simpósio de Iniciação Científica da Universidade Federal do ABC. Santo André, 2009.
Gonzalez, Rafael C.; Woods, Richard E., 2010. Processamento digital de imagens. 3. ed. São Paulo: Pearson Prentice
Hall, 624 p.
Gualberto, Daniel Rocha. 2010. Em rumo a um sistema automático de controle de acesso de veículos automotivos:
Reconhecimento de caracteres em placas de veículos. 51 f. Monografia (Graduação em Ciência da Computação) -
Universidade Federal de Ouro Preto, Ouro Preto
Guingo, Bruno Clemente, 2003. Reconhecimento Automático de Placas de Veículos Automotores. 143 f. Dissertação
(Mestrado em Ciência da Computação) - Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2003.
Haykin, Simon. 2001. Redes neurais: princípios e prática. 2.ed. - Bookman, Porto Alegre, Brasil.
Malvar, Henrique S. et al. 2008. Lifting-based reversible color transformations for image compression. In: Applications
of Digital Image Processing XXXI. Microsoft Corporation, USA.
Mitchell, Tom M. 1997. Machine Learning. WCB–McGraw–Hill

61
ISBN: 978-972-8939-96-0 © 2013 IADIS

Moreira, Ardilhes. 2011. Frota de veículos cresce 119% em dez anos no Brasil, aponta Denatran. Disponível em:
<http://g1.globo.com/carros/noticia/2011/02/frota-de-veiculos-cresce-119-em-dez-anos-no-brasil-aponta-
denatran.html>. Acesso em: 29 nov. 2012.
NEUROPH. Java neural network framework. 2012. Disponível em: <http://neuroph.sourceforge.net>. Acesso em: 01 jun.
2013.
ORACLE JAI API. Java Advanced Imaging API. 2007. Disponível em:
<http://www.oracle.com/technetwork/java/javase/tech/jai- 142803.html>. Acesso em: 01 jun. 2013.
Rijsselbergen, Dieter Van. 2005. YCoCg(-R) Color Space Conversion on the GPU. In: Sixth FirW PhD Symposium,
Faculty of Engeneering, Ghent University.
Souza, Fernando P. Coelho de.; Susin, Altamiro Amadeu. 2000. SIAV: Sistema de Identificação Automática de Veículos.
In: XIII Congresso Brasileiro de Automática, Universidade Federal do Rio Grande do Sul. Porto Alegre.
Trentini, Vinicius Bergoli et al. 2010. Reconhecimento Automático de Placas de Veículos. In: VI Workshop de Visão
Computacional, Universidade Estadual Paulista, Presidente Prudente.

62
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

DESENVOLVIMENTO DE UM SISTEMA DINÂMICO DE

MAPEAMENTO DE LINHAS DE ÔNIBUS PARA UM
MODELO DE TRANSPORTE INTELIGENTE

Williams M. de Araújo1 e Moisés P. Bastos2

1
Department of Mobile Software, Instituto Nokia de Tecnologia - INdT
Av. Torquato Tapajós, 7200, Colônia Terra Nova, Manaus - AM, 69093-415
2
Department of Control Engineering, Universidade do Estado do Amazonas – UEA
Av. Darcy Vargas, 1200, Parque 10 de Novembro – 69.065.020 - Manaus– AM – Brasil

RESUMO
O objetivo deste trabalho é desenvolver um sistema dinâmico de mapeamento de linhas de ônibus que fornecerá
informações a respeito do transporte coletivo da cidade de Manaus para os usuários. Utilizando tecnologias de
geolocalização em tempo real em conjunto com plataformas móveis, o projeto pretende fornecer para o usuário
informações detalhadas a respeito do itinerário completo das linhas de ônibus da cidade e também sua geolocalização no
mapa em um determinado momento. Uma API padrão de comunicação será desenvolvida a fim de possibilitar o acesso
aos dados a partir de qualquer plataforma.

PALAVRAS-CHAVE
Geolocalização, transporte urbano, GPS, GPRS, arduino

1. INTRODUÇÃO
A falta de informação a respeito do transporte coletivo nas grandes cidades brasileiras ainda é um grande
problema que afeta tanto os moradores da cidade quanto os turistas que pretendem utilizar o transporte
público.
Os órgãos responsáveis não divulgam abertamente estas informações, e como ainda não há uma
organização a respeito dos horários que cada ônibus irá passar em um determinado lugar, os usuários muitas
vezes perdem o ônibus e com isso se atrasam para a chegada ao seu destino. Diante deste grave problema que
afeta grande parte da população brasileira, a qual depende do transporte coletivo diariamente, propomos aliar
a tecnologia para resolver ou minimizar tal situação.
Este projeto tem como objetivo desenvolver uma solução que fornecerá informações a respeito do
transporte coletivo, esta solução será um sistema que irá aliar sistemas embarcados, comunicação GPRS,
webservices, banco de dados, redes e sistemas operacionais móveis, onde juntos fornecerão para o usuário o
itinerário completo de cada ônibus da cidade, ônibus disponíveis a partir da origem e destino selecionadas e
mapas para auxiliar a visualização em tempo real da posição dos ônibus.

2. FUNDAMENTOS TEÓRICOS
Este capítulo visa fornecer a fundamentação teórica de acordo com as tecnologias utilizadas durante o
desenvolvimento do projeto, assim como identificar quais os componentes e ferramentas utilizadas.

63
ISBN: 978-972-8939-96-0 © 2013 IADIS

2.1 GPS
A funcionalidade principal do projeto irá utilizar o sistema de posicionamento global – GPS, e seu
funcionamento é relevante para o desenvolvimento do projeto. O GPS é um sistema de posicionamento de
abrangência global em tempo real, desenvolvido pelo departamento de defesa dos Estados Unidos em 1973,
ele consta com dois tipos de serviço de posicionamento diferentes: o padrão SPS (Standard Positioning
Service) e o preciso PPS (Precise Positioning Service). O SPS está disponível a todos os usuários do globo e
proporciona valores com precisão de 100 a 140m ou 10 a 20m, enquanto o PPS, de uso restrito militar
apresenta precisão de 10 a 20 m. Nota-se, assim, que ambos os serviços podem proporcionar valores com a
mesma precisão [1].
O GPS é dividido em três segmentos: espacial, de controle e de usuários. O segmento espacial consiste de
24 satélites distribuídos em seis planos orbitais igualmente espaçados, que cruzam o centro da terra. Cada
plano conta com quatro satélites. Essa configuração permite que, em qualquer local da superfície terrestre, a
qualquer momento, pelo menos quatro satélites estejam “visíveis” por um receptor. O segmento de controle é
o responsável pelo monitoramento, correção dos relógios e atualização periódica das mensagens de
navegação de cada satélite. O segmento de usuários é constituído pelos receptores GPS, dependendo da
aplicação a qual se destina, o aparelho necessita um grau maior ou menor de qualidade do seu relógio interno
[2].
Considerando a sofisticação existente por trás da tecnologia, o princípio de funcionamento do GPS é
relativamente simples. Cada um dos 24 satélites componentes do sistema transmite continuamente um sinal
de rádio (onda eletromagnética) que contém informações sobre a sua posição orbital, vinculado à um
referencial geodésico, e o tempo marcado por seu relógio atômico interno. Um receptor GPS localizado na
terra recebe informações de, no mínimo, quatro satélites diferentes e usa esses dados para calcular sua
posição no planeta [3].

2.2 Rede GSM/GPRS

O GPRS (General Packet Radio Service) é uma tecnologia de transferência de dados nas redes de celulares
GSM utilizadas atualmente. Fornece uma taxa teórica máxima de 56 kbps para transmissão de dados e
28kbps para a recepção [4].
No GPRS o serviço é “sempre ativo”, ou seja, é um modo no qual os recursos somente serão utilizados
por um usuário quando for necessário enviar ou receber dados. Algumas das vantagens do GPRS são



Utilização de voz e dados ao mesmo tempo;


Ampla cobertura
Redução de custos. Com apenas o GSM a tarifação poderá ser efetuada por tempo de conexão.

Com o GPRS, a informação é dividida em “pacotes” relacionados entre si antes de ser transmitida e
remontada no destinatário.
Durante o transporte entre a origem e o destino, as informações são misturadas. Quando o destinatário
recebe todos os dados do pacote ele as remonta, formando a informação completa original [4].
O GPRS faz o uso eficiente de diversos recursos que possibilitam um grande número de usuários
compartilhando a mesma largura de banda, utilizando a modulação por chaveamento de fase gaussiano [5].

2.3 Protocolo HTTP

O HTTP (Hyper Transfer Protoco) é um protocolo de rede que atua na camada de aplicação no modelo
TCP/IP e é definido no [RFC 1945] e no [RFC 2616]. O HTTP é implementado em dois programas: um
programa cliente e outro servidor. Os dois programas, executados em sistemas finais diferentes, conversam
um com outro por meio de troca de mensagens HTTP. O HTTP define a estrutura dessas mensagens e o
modo como o cliente e o servidor as trocam [6].

64
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Um cliente em geral é referenciado como User Agent, ou simplesmente UA. Os recursos HTTP são
identificados e localizados por meio de um URI (Uniform Resource Identifier), mais especificamente, do tipo
URL (Uniform Resource Locator) [7].
As requisições são feitas por meio dos métodos HTTP. A seguir são listados os principais métodos.



GET: requisição de recurso . É um método básico do HTTP.


POST: envia dados a serem processados pelo servidor a um recurso identificado.
OPTIONS: retorna os métodos http suportados pelo servidor.

3. METODOLOGIA
A concretização deste projeto ocorreu de acordo com as seguintes etapas definidas no início do mesmo:

1. Modelar e criar o banco de dados interno

Elaborar o modelo conceitual e o diagrama de entidade-relacionamento do banco de dados embarcado.
2. Modelar a aplicação
Elaborar a modelagem do sistema, projetando os cenários e os diagramas de casos de uso, classes e
sequências de cada módulo envolvido no projeto.
3. Desenvolver a aplicação Cliente
Esta etapa consiste em aplicar os conhecimentos adquiridos nas etapas anteriores desenvolvendo o
aplicativo cliente, que irá fornecer para os usuários informações a respeito dos itinerários dos onibus e
melhores opções de ônibus que ele pode pegar a partir de uma origem e destino.
4. Modelar e criar o banco de dados web
Modelar e criar o banco de dados web que será utilizado para armazenar as infomações de geolocalização.
5. Implementar o serviço web
Desenvolver o serviço web utilizando a linguagem definida na etapa anterior, esse webservice deverá
receber as requisições do sistema embarcado e armazenar a coordenada recebida no banco de dados.
6. Estudar e testar o módulo GPS
Estudar, desenvolver e testar a comunicação entre o módulo GPS com o microcontrolador escolhido.
7. Estudar e testar o módulo GSM/GPRS
Definir o módulo que será utilizado para a comunicação com o servidor, desenvolver e testar as
aplicações para a comunicação entre o servidor com o sistema embarcado.
8. Integrar e testar todos os módulos desenvolvidos
Integrar os módulos desenvolvidos até esta etapa (sistema embarcado, webservice e cliente android), e
fazer os devidos testes para validar o funcionamento.

4. DESENVOLVIMENTO
Neste tópico serão apresentadas as etapas de desenvolvimento do projeto. Serão abordados os componentes
de software e hardware envolvidos e a integração física entre os módulos. Também será descrito o
desenvolvimento do aplicativo cliente e do firmware embarcado. Por fim, o desenvolvimento do webservice
será detalhado e como foi realizada a integração dos módulos.

65
ISBN: 978-972-8939-96-0 © 2013 IADIS

4.1 Visão Geral

A Figura 1 representa um diagrama da visão geral do projeto.

Figura 1. Integração dos módulos que compõem o sistema.

O módulo embarcado será o responsável por obter os dados do GPS e enviá-los ao servidor com banco de
dados para que possam ser acessados em tempo real. Este módulo deve ser instalado no ônibus que se
pretende rastrear.
O webservice tem como objetivo gerenciar os dados coletados e deixá-los disponíveis para que as
aplicações clientes possam acessá-los.
O aplicativo cliente é voltado para o usuário final e tem como objetivo facilitar a integração e
visualização dos dados. É composto de um aplicativo para visualizar os dados em tempo real, como a posição
atual de cada ônibus e a hora em que os dados de foram coletados, e também outras informações como o
itinerário de cada ônibu, opções de ônibus disponíveis a partir de uma origem e destino selecionadas e o valor
das passagens de ônibus na cidade.

4.2 Hardware
Para o projeto de hardware embarcado foram utilizados os seguintes módulos: microcontrolador, módulo
GPS e um módulo GPRS. Nas seções seguintes serão apresentados com mais detalhes.
4.2.1 Microcontrolador
O microcontrolador utilizado foi o ATMEGA328. Trata-se de um microcontrolador da fabricante ATMEL,
de 8 bits, com 32kB de memória flash, 2kB de memória RAM e arquitetura RISC (Reduced Instruction Set
Computer). Possui 131 instruções assembly, sendo que a maioria delas realizada em um único ciclo de clock.
Além disso possui 14 pinos de entrada e saídas digitais e 6 entradas analógicas. Com relação a capacidade de
processamento, ele é capaz de executar 20 milhões de instruções por segundo (MIPS), quando associado com
um cristal oscilador de 20 MHz [7].
4.2.2 Módulo Gps
O receptor GPS escolhido é o módulo ME-1000RW fabricado pela M.E Componentes eletrônicos.

Figura 2. Receptor GPS ME-1000RW

66
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

O ME-1000RW é um módulo receptor GPS com antena acoplada. A antena é conectada ao receptor
através de um LNA. (Amplificador de Baixo Ruido). O receptor possui 51 canais de aquisição e 14 canais de
rastreamento que são capazes de receber sinais de até 65 satélites GPS e informar a posição e o tempo
precisos para serem lidos na porta UART ou RS232. O equipamento possui baixo consumo e a faixa de
tensão supor tada é de 3.3V~6.0V. O conector possibilita a saída tanto em nível TTL quanto em nível RS232
[8].
4.2.3 Módulo Gprs
Para o módulo GPRS, foi selecionado o SIM900B, fabricado pela SIMCom Wireless Solutions. Opera em
quatro frequências de banda (quad-band), o módulo dispõe de interfaces seriais USART, SPI e I2C,
conversor analógico-digital, e é preparado com entradas e saídas para microfone e alto-falantes.

Figura 3. Módulo GPRS SIMCom SIM900B

A motivação para a utilizar deste módulo é a flexibilidade em relação às interfaces que ele possui. A
começar pelas interfaces seriais disponíveis. A gama de frequências de banda que ele opera permite que
possa ser utilizado com qualquer operadora de celular no Brasil e no mundo. Basta apenas um plano de dados
e um SIM card da empresa escolhida.

4.3 Firmware
O software embarcado irá controlar os módulos GPS e GSM/GPRS na coleta de dados e em seguida enviar
para o webservice. Pelo fato de a cominucação depender diretamente da rede de celular foi necessário
desenvolver um firmware robusto o suficiente para lidar com eventuais interrupções na comunicação. O
fluxograma do firmware desenvolvido se encontra na figura 4.
O firmware tem como papel coletar os dados provenientes do módulo GPS (coornedadas, velocidade e
data/hora) e enviar para o webservice através do módulo GSM/GPRS. Esta operação será realizada a cada 20
segundos.

Figura 4. Fluxograma do Firmware

67
ISBN: 978-972-8939-96-0 © 2013 IADIS

4.4 Interface Módulo-Servidor

O módulo GPRS se comunica com o servidor através dos métodos GET e POST especificados no HTTP.
Através dessa requisição, são passados como parâmetros a função que será execudada no servidor, o código
identificador do ônibus (único para cada dispositivo), latitude, longitude e data/hora da coleta. A mensagem
final é construida da seguinte maneira no dispositivo embarcado.

GET http://whatbus.no-ip.org:8185/apimobile/index.php?funcao=registra_localizacao?id=1234&latitude=
3.2342&longitude=4.3232&data=12/04/2013&hora=11:12:32
HTTP/1.1[CR][LF]
Host:whatbus.no-ip:8185.org[CR][LF]
User-agent: Arduino [CR][LF]
[CR][LF]

Quadro 1. Requisição http criada pelo módulo embarcado

Se a transação for efetuada com sucesso o servidor irá enviar uma resposta no formato JSON do tipo
“{sucesso:1}”.

4.5 Servidor HTTP

Ao receber a requisição http, o servidor coleta os parâmetros, analisa a função que será executada e em
seguida faz a chamada desta função passando como parâmetro os valores adiquiridos na requisição. No
quadro 2 apresenta o código que trata das requisições recebidas.

<?php
if(isset($_GET['funcao']) && $_GET['funcao'] != '') {
$funcao = $_GET['funcao'];

require_once 'include/DB_Functions.php';
$db = new DB_Functions();

if(method_exists($db,$funcao)) {
call_user_func_array(array(&$db, $funcao),array($_GET));
} else{
echo "Access Incompatible!";
}

} else {
echo "Access Denied";
}
?>

Quadro 2. Código que trata das requisições HTTP recebidas

Para registrar uma localização o módulo embarcado deve mandar a string “registra_localizacao” como
valor do parametro “funcao”.

4.6 Aplicativo Cliente

O aplicativo cliente desenvolvido é a interface para que o usuário possa visualizar em tempo real a
localização do ônibus desejado e também obter informações a respeito do itinerário das linhas alternativas de
ônibus a partir de uma origem e destino selecionadas.
O usuário poderá acessar o aplicativo e ver informações básicas a respeito do transporte coletivo da
cidade, estas informações não dependem de conexão com a internet, os dados irão persistir na memória
interna do dispositivo utilizando o SGBD (Sistema Gerenciador de Banco de Dados) SQLite. A figura 5
demonstra o esquema relacional do banco de dados interno.

68
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Figura 5. Modelo relacional do banco de dados interno no aplicativo Android.

Com os dados persistidos na memória do dispositivo cliente, as consultas de itinerários ou alternativas de
ônibus irão ter uma boa performace pois não dependem da conexão com a rede de internet.

5. RESULTADOS OBITIDOS
Para a validação do projeto a aplicação web foi hospedada provisoriamente em um servidor doméstico
utilizando o Apache como servidor http e banco de dados MySQL, ambos operando no sistema operacional
Linux.
Uma amostra de coordenadas coletadas pela aplicação web pode ser vista na figura 6.

Figura 6. Amostra de coordenadas coletadas pela aplicação web

69
ISBN: 978-972-8939-96-0 © 2013 IADIS

A figura 7 mostra as telas do protótipo da aplicação cliente desenvolvida.

Figura 7. Amostra das telas da aplicação cliente.

6. CONCLUSÃO
O estudo apresentado neste projeto é de uma importância estratégica, uma vez que o transporte público está
passando por um processo de descrédito cada vez maior junto ao público alvo.
Em Manaus, por exemplo, o transporte púbico por meio de linhas regulares vem perdendo mercado para
sistemas alternativos. Um dos motivos é justamente o modelo tecnológico ultrapassado no qual o transporte
brasileiro se baseia no seu funcionamento.
O projeto aqui apresentado foi capaz de mostrar a viabilidade de se implementar uma solução tecnológica
que permite apresentar ao usuário o posicionamento da rota em tempo real e também informações básicas
referente ao transporte coletivo como, itinerário dos ônibus e alternativas de rotas a partir de uma origem e
destino.
Como sugestão para trabalhos futuros, pode-se estudar a viabilidade de aproveitar o sistema embarcado
até aqui desenvolvido para acrescentar um dispositivo de alerta de roubo, no qual o motorista irá apertar um
botão e um sinal de alerta será enviado diretamente para o distrito policial mais próximo.

REFERÊNCIAS
[1] Zanotta, D. C., Cappelletto, E., & Matsuoka, M. T. (2011). O GPS: unindo ciência e tecnologia em aulas de fısica.
Revista Brasileira de Ensino de Fısica, 33(2), 2313.
[2] J.F.G. Monico, 2008. Posicionamento Pelo GNSS: Descrição, Fundamentos e Aplicações. Unesp, São Paulo.
[3] W. Hoffmann, B.H. Lichtenegger and J. Collins, 1994. GPS: Theory and Practice. Springer-Verlag, New York.
[4] NOVATEL WIRELESS INC, 2002. Technical Manual with Specifications: Merlin for GPRS. Novatel, 215 p.
[5] TURLETTI, Thierry, 1996. A brief Overview of the GSM Radio Interface. Massachusetts: Massachusetts Institute of
Technology.
[6] Kurose, J., & Ross, K.,2006. Redes de Computadores e Internet. São Paulo: Person.
[7] ATMEL INC. Atmel Microcontroller with 4/8/16/32K Bytes In-Stytem Programmable Flash ATMEGA328P-P.
Atmel, 2011. 567 p.
[8] ME Componentes eletrônicos, 2009. MÓDULO GPS COM ANTENA ACOPLADA ROM ME-1000RW. 14 p.

70
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

UTILIZANDO TÉCNICAS DE ALGORITMO GENÉTICO

PARA RESOLUÇÃO DO PROBLEMA DE GERAÇÃO DE
GRADE HORÁRIA PARA ENFERMARIAS

Ricardo Soares Bôaventura1, Bruno Queiroz Pinto1 e Keiji Yamanaka2

1
Instituto Federal do Triângulo Mineiro – Câmpus Uberlândia Centro
Rua Blanche Galassi, 150 CEP 38401-114 Uberlândia/MG, Brasil
2
Universidade Federal de Uberlândia – Faculdade de Engenharia Elétrica
Av. João Naves de Ávila, 2121 CEP 38408-100 Uberlândia/MG, Brasil

RESUMO
A teoria da evolução inspirou a criação da computação evolutiva, ramo da computação capaz de solucionar problemas de
otimização. Esta categoria de problemas pode ser solucionada eficientemente através da adoção de técnicas como
algoritmos genéticos. Problemas de geração de grade horária são identificados em diversos contextos, o objetivo deste
trabalho é descrever a aplicação de algoritmos genéticos na criação de uma grade horária otimizada para enfermarias.

PALAVRAS-CHAVE
Algoritmo Genético, Geração de Horário, Horários de Enfermarias e Inteligência Artificial

1. INTRODUÇÃO
Uma importante tarefa na computação é a otimização na resolução de problemas, existe diversos problemas
que apresentam grande quantidade de soluções possíveis e a identificação de uma solução eficiente é uma
tarefa complexa, podendo demandar um esforço computacional considerável [Linden 2012].
Há diversas técnicas que podem ser utilizadas na solução deste tipo de problema, tais como: Algoritmos
Genéticos (AG), GRASP (Greedy Randomized Adaptive Search Procedure) , Busca Tabú, Algoritmo da
colônia de formigas, Redes neurais artificiais, Simulated annealing, entre outras. Este trabalho utilizou a
técnica de algoritmo genético. Tal técnica é baseada em três partes distintas: a codificação do problema, a
função objetivo que se deseja maximizar ou minimizar e o espaço de soluções associado. A escolha da
técnica de algoritmos genéticos é baseada na ampla utilização desta técnica na elaboração de escala de
trabalho, devido principalmente à diversificação promovida pelo AG para obter os melhores resultados.
O Problema de Geração de Horários, também conhecido como Timetabling Problem, trata da alocação de
horários para as atividades em um determinado contexto, considerando-se restrições nestes horários. Este
problema pode ser identificado em diversos contextos, tais como: escalonamento de enfermeiros, horários de
aulas em instituições de ensino, horários de médicos e planejamento de transporte publico, entre outros. O
desenvolvimento de uma solução para este problema de forma manual, além de ser trabalhosa e lenta, pode
gerar soluções não tão boas. Este tipo de problema tem sido constantemente solucionado através do uso da
técnica de algoritmos genéticos [Poltosi and Goméz 2007].
Desta forma, este trabalho desenvolveu um algoritmo, utilizando técnicas de algoritmos genéticos, capaz
de encontrar uma boa solução na montagem de grade horária para enfermarias.

2. ALGORITMO GENÉTICO
Algoritmo Genético é uma técnica baseada em computação evolutiva, tais técnicas se inspiram em princípios
da teoria da evolução e seleção natural e utiliza modelos destes processos naturais para encontrar soluções de
problemas [Bergamaschi and Bonfim 2010].

71
ISBN: 978-972-8939-96-0 © 2013 IADIS

Uma atividade essencial nesta técnica é a definição da representação de cada individuo que fará parte do
processo de seleção natural, tal individuo é definido como cromossomo. Existem diversas formas de
representá-lo, tais como: binária, inteira, real ou alfanumérica. Esta representação também é conhecida como
alfabeto do Algoritmo Genético [Bergamaschi and Bonfim 2010]. A Figura 1 mostra um exemplo de
representação do tipo alfanumérica, onde cada gene pode possuir somente um caractere.

a b a b 0 1 a a 1 5 T r k v
Figura 1. Representação alfanumérica do cromossomo.
A primeira atividade na elaboração de um algoritmo genético é a criação de uma população aleatória de
cromossomos (indivíduos). Os indivíduos que possuírem os cromossomos que representem uma boa solução
receberão valores maiores, indicando uma maior probabilidade de ser uma boa solução do problema.
A seleção de um bom indivíduo é dependente de uma função objetivo, que indica aquele que atende de
forma mais adequada o problema que está sendo solucionado. A função objetivo informa o quanto um
cromossomo está próximo da solução. Essa função fornece um valor que será usado para o cálculo de sua
probabilidade para ser selecionado para reprodução. Esta função também é conhecida como função de
aptidão [Linden 2012].
Dois indivíduos (pais) deverão ser selecionados para permitir a geração de dois novos indivíduos (filhos).
Existem vários métodos de seleção utilizados nas aplicações de Algoritmos Genéticos: seleção por roleta,
seleção Boltzmann, seleção por torneio, entre outros [Mattioli and Yamanaka 2009].
A seleção por roleta divide os indivíduos em grupos e faz aleatoriamente a sua seleção. Os melhores
indivíduos ganham maiores espaços na roleta e piores indivíduos ganham espaços menores na roleta. Esta
técnica permite selecionar indivíduos mais aptos, mas não exclui os indivíduos que não possuem um bom
material genético [Russel and Norvig 2004].
Para a otimização ou substituição da seleção por roleta é possível adotar a técnica de seleção por torneio,
que limita o tamanho (k) da população colocada na roleta. Esta técnica permite que indivíduos com baixa
probabilidade participe de alguns cruzamentos.
A geração dos novos indivíduos é possível pelo cruzamento entre os cromossomos dos indivíduos
selecionados. Tal operação é essencial para o funcionamento de um Algoritmo Genético. Há diversas formas
de realizar o cruzamento como: ponto de cruzamento único, dois pontos de cruzamento, cruzamento
uniforme e cruzamento aritmético [Poltosi and Goméz 2007].
Garantir uma varredura ampla no espaço de possíveis soluções é essencial em todos os problemas de
otimização. Para atender esta necessidade, algoritmos genéticos aplicam a operação de mutação após a
operação de cruzamento. Esta operação evita que o algoritmo genético encontre precocemente mínimos ou
máximos locais. A mutação é efetuada alterando-se o valor de um ou mais genes de um indivíduo sorteado
aleatoriamente com uma determinada probabilidade, denominada probabilidade de mutação [Russel and
Norvig 2004].
A reinserção dos indivíduos na população é a última etapa necessária, na qual os indivíduos capazes são
preservados e os indivíduos com menor aptidão são descartados. Nesta etapa é possível utilizar a técnica de
Elitismo, que permite manter os k melhores indivíduos e aleatoriamente preencher o restante, outra
abordagem é o Elitismo Total, que mantém apenas os melhores indivíduos [Poltosi and Goméz 2007].

3. GERAÇÃO DE GRADE HORÁRIA EM ENFERMARIAS

A geração de horário em enfermaria geralmente apresenta o problema de determinar um cronograma de
trabalho, geralmente no prazo de um mês, para os enfermeiros, que seja razoável e eficiente. Apesar de
parecer trivial, este é um problema complexo devido às suas diversas restrições e muitas combinações
possíveis [Camillo and Stelle 2008][Beppler and Leite 2009]. Este problema pode ser classificado como
NP(Non-Deterministic Polynomial time), implicando a necessidade de utilizar técnicas não determinísticas na
solução do problema [Camillo and Stelle 2008].

72
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Neste problema é necessário realizar a atribuição de turnos e férias para cada enfermeiro. Cada
enfermeiro tem a sua vontade e suas preferências. A solução deve atender ao máximo possível estas
preferências e também atender as necessidades das enfermarias. Normalmente um enfermeiro pode trabalhar
nos turnos da manhã, tarde e noite (seis primeira horas) [Dias 2010].
Um enfermeiro também pode realizar plantão de 12 horas, que durante o dia compreende os turnos da
manhã e tarde e durante a noite compreende toda a noite [Burke et. al. 2001]. As restrições das enfermarias
são definidas por regras internas ou mesmo leis nacionais ou do órgão que regula a profissão. Uma
enfermaria precisa respeitar estas regras para não ter problemas trabalhistas [Dias 2010].
A definição de uma grade horária eficaz permite a geração de quadros de horários otimizados garantindo
a cobertura correta de profissionais ao longo do período e diminuindo o montante necessário de horas extras
exigidas dos funcionários, o que implica em uma significativa redução de custos. Já os enfermeiros têm como
benefício uma melhor qualidade de vida, visto que a escala gerada permite uma distribuição mais uniforme
do trabalho. A melhoria no ambiente de trabalho permite que se ofereça um melhor atendimento à população
[Camillo and Stelle 2008].

4. DESENVOLVIMENTO DA APLICAÇÃO

4.1 Representação do Indivíduo

Neste problema foi utilizado um cromossomo com n genes, onde n é igual a 2*Quantidade de
Enfermeiros*Quantidade de Dias no Mês. A representação do cromossomo utiliza valores decimais, onde
o gene em uma posição par representa o trabalho realizado pelo enfermeiro e as posições impares representa
a enfermaria onde deverá ser realizado tal trabalho. Na representação do cromossomo há valores entre 0 e 6,

 0 representa que o enfermeiro irá trabalhar durante a manhã.

onde:

 1 representa que o enfermeiro irá trabalhar durante a tarde.

 2 representa que o enfermeiro irá trabalhar durante a noite.
 3 representa que o enfermeiro folga nos três períodos do dia.
 4 representa que o enfermeiro está de férias neste dia.
 5 representa que o enfermeiro irá trabalhar em plantão durante o dia.
 6 representa que o enfermeiro irá trabalhar em plantão durante a noite.
Já na representação da enfermaria temos valores entre 1 e n, que indicam a enfermaria no qual o
enfermeiro irá fazer seu trabalho, onde n é a quantidade de enfermarias cadastradas. Quando o trabalho é
folga ou férias o valor da enfermaria será -1, pois este trabalho não é vinculado a nenhuma das enfermarias.
A figura 2 mostra a representação de um cromossomo. Cada par de genes representa um dia especifico e
2*quantidade de dias representa o horário de um enfermeiro. Um cromossomo é um vetor com n*m
elementos, onde n é a quantidade de enfermeiros e m é a quantidade de dias no mês multiplicado por dois. A
escala de um enfermeiro é representado a cada m elementos.

0 1 0 1 1 2 1 2 2 1 3 3 3 5 1 3 6 2 3 …
Figura 2. Representação de parte do cromossomo.

4.2 Função Objetivo

A função de aptidão foi gerada a partir de informações coletadas junto ao hospital das clinicas da USP de
Ribeirão Preto. Nesta versão desenvolvida são consideradas 11 regras básicas que quando unidas geram o
resultado da função de aptidão. A função de aptidão é definida pela fórmula: temR1*regra1() +
temR2*regra2() + temR3*regra3() + temR4*regra4() + temR5*regra5() + temR6*regra6() +
temR7*regra7() + temR8a*regra8a() + temR8b*regra8b() + temR9a*regra9a() + temR9b*regra9b().

73
ISBN: 978-972-8939-96-0 © 2013 IADIS

Cada uma das regras pode ser desativada ou ativada pelo usuário. Abaixo a descrição de cada uma das
regras:
Regra 1: penaliza a solução, quando ela não respeita o período de férias de um enfermeiro. A cada dia de
férias não respeitado é acrescido o valor da penalidade.
Regra 2: penaliza a solução, quando ela permite que um determinado período (Manhã, Tarde e Noite) fique
sem enfermeiro. A cada período não atendido é acrescido o valor da penalidade.
Regra 3: penaliza a solução, quando ela não permite a um enfermeiro que trabalhou a noite, folgar no outro
dia. A cada ocorrência é acrescido o valor da penalidade da regra.
Regra 4: penaliza a solução, quando ela não permite a um enfermeiro que trabalhou em um plantão noturno,
folgar 36 horas. A cada ocorrência é acrescido o valor da penalidade da regra.
Regra 5: penaliza a solução, quando ela não encontra uma quantidade suficiente de enfermeiros por período,
esta quantidade é definida pelo usuário. Quando esta regra esta ativa ela desabilita a regra 2.
Regra 6: penaliza a solução, quando ela não respeita a carga horária máxima de trabalho de um enfermeiro.
A penalidade nesta regra é a quantidade de horas que excederam o limite mensal multiplicada pelo valor da
penalidade da regra.
Regra 7: penaliza a solução, quando ela permite a um enfermeiro trabalhar mais de 6 dias seguidos. A cada
ocorrência é acrescido o valor da penalidade da regra.
Regra 8a: penaliza a solução, quando um determinado dia fica sem plantonista noturno. A cada ocorrência é
acrescido o valor da penalidade da regra.
Regra 8b: penaliza a solução, quando um determinado dia fica sem plantonista diurno. A cada ocorrência é
acrescido o valor da penalidade da regra.
Regra 9a: penaliza a solução, quando a preferência do enfermeiro quanto ao período preferido não é
atendido, o enfermeiro pode indicar o período de preferência para seu trabalho (Manhã, Tarde ou Noite). A
cada ocorrência é acrescido o valor da penalidade da regra.
Regra 9b: penaliza a solução, quando a preferência do enfermeiro quanto aos seus plantões não é atendido, o
enfermeiro pode indicar o horário de preferência para seus plantões (noturno ou diurno). A cada ocorrência é
acrescido o valor da penalidade da regra.
A tabela 1 apresenta os pesos e situação padrão de cada regra. O usuário tem opção de modificar tais
valores.
Tabela 1. Pesos e condição de cada regra.
Regra Ativada Peso Regra Ativada Peso
Regra 1 Sim 10 Regra 7 Sim 3
Regra 2 Não 5 Regra 8a Sim 5
Regra 3 Sim 4 Regra 8b Não 1
Regra 4 Sim 4 Regra 9a Sim 1
Regra 5 Sim 3 (5 caso, número de enfermeiros = 0) Regra 9b Sim 1
Regra 6 Sim 3

4.3 Mutação, Cruzamento e Reinserção

 Mutação: Mutação de um ponto. Foi adaptado para permitir mudar uma quantidade de até 10 genes.
Nesta solução foram desenvolvidas as seguintes estratégias:

 Cruzamento: Foram desenvolvidas as técnicas de roleta e torneio que podem ser utilizados para
Mas o padrão é realizar a mutação de apenas um gene.

 Reinserção: Foram desenvolvidas soluções baseadas em elitismo total ou parcial, com um máximo
selecionar os pais para o cruzamento, no cruzamento é considerado um ponto de corte.

de k indivíduos elitizados.

74
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

4.4 Interface Gráfica Desenvolvida

 Enfermaria: Permite ao usuário selecionar um arquivo em formato excel (XLS) que armazena os
Neste projeto foi desenvolvido uma interface gráfica, apresentada na figura 3, que contém 5 partes distintas:

 Horário Mensal da Enfermaria: O usuário pode selecionar o mês e então executar o algoritmo
dados da enfermaria.

genético. Após a sua execução, o usuário tem três modos de visualizar o resultado: Tabela com

 Preferências: O usuário tem a possibilidade de habilitar ou desabilitar regras, bem como modificar
todos os dados gerados, grade horária por enfermaria, grade horária por enfermeiro.

 Configuração do Algoritmo Genético: Esta interface permite definir várias configurações para a
os pesos delas.

execução do algoritmo, tais como: quantidade de gerações, de indivíduos, taxas de mutação e de

 Gráfico: apresenta o desempenho do algoritmo genético.

cruzamento, definição de quantidade de genes mutáveis e seleção do modo de elitismo.

Figura 3. Interface Gráfica desenvolvida

5. EXPERIMENTOS
O algoritmo genético desenvolvido foi executado em seis experimentos em ciclos contínuos de 5.000
gerações para evolução da solução. O experimento é finalizado quando um ciclo não apresenta melhorias ou
quando apenas erros gerados em regras relacionadas às preferências dos enfermeiros ou horas extras forem
identificados.
Cada experimento foi executado três vezes, modificando a quantidade de enfermeiros. Em cada uma
delas, a quantidade de enfermeiros testará os limites na geração da grade horária, de uma configuração fácil
até uma difícil. A tabela 2 apresenta a configuração de cada um dos experimentos.

75
ISBN: 978-972-8939-96-0 © 2013 IADIS

Tabela 2. Configurações dos experimentos

Experimento Configurações
1 2 3 4 5 6 7 8 9 10 11
Primeiro 50 0.8 1 0.5 Ativa Ativa 2 11 15 7 2
Segundo 100 0.9 3 0.6 Ativa Ativa 2 11 15 7 2
Terceiro 100 0.9 3 0.5 Ativa Ativa 2 15 30 7 4
Quarto 50 0.9 3 0.6 Ativa Ativa 3 11 15 10 2
Quinto 50 0.7 1 0.6 Ativa Ativa 3 17 15 10 2
Sexto 100 0.9 5 0.7 Ativa Ativa 3 17 15 10 2
Legenda das configurações: 7: Quantidade de Enfermarias;
1 : Quantidade de Indivíduos; 8: Quantidade de Preferências
2 : Taxa de mutação; 9: Quantidade de dias de férias dos enfermeiros
3: Quantidade de genes mutáveis; 10: Necessidade de enfermeiros por
4: Taxa de Cruzamento; dia(manhã+tarde+noite) nas enfermarias
5: Seleção por torneio (ativo ou inativo); 11: Mês (1 à 12);
6: Elitismo Total (ativo ou inativo);

A figura 4 apresenta os gráficos gerados pela aplicação, com o desempenho do algoritmo no primeiro
experimento. A ferramenta desenvolvida disponibiliza informações quando ao desempenho apresentado,
permitindo ao usuário otimizar a sua configuração. Cada gráfico mostra a evolução da solução do problema
em cada configuração.

Figura 4. Gráfico com o desempenho do algoritmo genético.

A tabela 3 apresenta a análise das execuções de cada um dos experimentos, apresentando, a quantidade de
enfermeiros (QE) cadastrados para teste, a penalidade identificada (Erros) pela função objetivo e o número
de gerações que foram necessárias para encontrar uma solução adequada. Uma solução adequada é aquela no
qual todas as regras que apresentam grande penalidade são satisfeitas e geram erro próximo a zero. O
segundo número presente no campo Erros, entre parênteses, representa uma descrição do erro.
Os experimentos um e dois conseguiram criar soluções que respeitavam as regras da enfermaria,
entretanto não conseguiram atender a todas as preferências dos enfermeiros. Quando a quantidade de
enfermeiros foi igual a 13 gerou soluções que necessitam de hora extra de alguns enfermeiros.

76
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Tabela 3. Resultado dos experimentos

Primeira Execução Segunda Execução Terceira Execução
QE Erros Gerações QE Erros Gerações QE Erros Gerações
1 13 15 (2) 15000 14 6 (1) 5000 15 5 (1) 5000
2 13 13 (2) 15000 14 6 (1) 5000 15 5 (1) 5000
3 13 52 (3) 25000 14 36 (2) 15000 15 24 (2) 10000
4 18 20 (3) 20000 19 6(2) 5000 20 2(1) 5000
5 18 25 (3) 20000 19 10(2) 5000 20 6(1) 5000
6 18 22 (3) 20000 19 08(1) 5000 20 5(1) 5000
QE: Quantidade de Enfermeiros
Erros: valor retornado pela função objetivo, indicando a penalidade da solução, onde:
(1): Apenas regras relacionadas a preferências dos enfermeiros não respeitadas.
(2) : Regra número 6 não respeitada, necessidade de pagar hora extra.
(3) : Regras internas ou leis foram desrespeitadas (regras 1, 2, 3, 4, 7, 8)

O experimento três apresentou mais restrições, gerando soluções que acarretaram uma quantidade maior
de horas extras e no caso de poucos enfermeiros, o não atendimento da folga de 36 horas após a execução de
um plantão.
Os demais experimentos mostraram que é possível evoluir a solução propondo configurações diferentes
para o algoritmo genético.
Os experimentos demonstram que o algoritmo consegue evoluir a solução, entretanto necessita, em alguns
casos, de muitas gerações. O algoritmo conseguiu na maioria dos casos encontrar uma solução satisfatória.
Tais soluções podem ser evoluídas disponibilizando mais gerações para a sua evolução.

6. RESULTADOS E DISCUSSÕES
As regras propostas apresentaram um bom desempenho, permitindo definir um horário que foi capaz de
satisfazer tanto restrições das enfermeiras como dos hospitais, entretanto seria possível criar diversas outras,
tais como: restringir um enfermeiro a uma enfermaria especifica, definir uma preferência a dias da semana,
definir preferências de trabalho em equipe e definir restrições de acessibilidade nas enfermarias.
A solução proposta, além de poder ser utilizada para geração do escalonamento da força de trabalho de
uma enfermaria, pode ser empregada para o planejamento do quadro necessário de enfermeiros.
A configuração do problema gera cromossomos grandes, que oneram muito o processamento. A criação
de grades horárias para diversas enfermarias com dezenas de enfermeiros pode gerar cromossomos com
milhares de genes.
O algoritmo demandou uma grande quantidade de gerações para encontrar uma solução adequada ao
problema, isto se deve principalmente a complexidade do cromossomo. A função de aptidão influenciou
diretamente no desempenho do algoritmo, uma grande quantidade de regras ativas gera uma necessidade de
grande processamento.
Para superar tais dificuldades, é proposto como trabalho futuro: paralelizar a solução das regras e os
processos de cruzamento e mutação, otimizar a representação do cromossomo e também estudo e
implantação de outras técnicas de computação evolutiva para solucionar o problema. A identificação de uma
configuração ótima para o algoritmo genético poderia ser obtida através da aplicação de técnicas de redes
neurais, que permitiria identificar um padrão ótimo para tal configuração.

77
ISBN: 978-972-8939-96-0 © 2013 IADIS

REFERÊNCIAS BIBLIOGRÁFICAS
Beppler, A. and Leite, D. P., 2009. Sistema para geração de escalas de plantões médicos, in III EPAC – Encontro
Paranaense de Computação. pp. 174-183.
Bergamaschi, P. R. and Bonfim, I. P, 2010). O Método de Otimização Evolução Diferencial: uma análise dos parâmetros
– fator de perturbação e probabilidade de cruzamento, in Anais do II Simpósio de Matemática e Matemática
Industrial – SIMMI’ ’2010, Vol. 1, ISSN 2175-7828.
Burke, E. B., et al, 2001. Fitness Evaluation for Nurse Scheduling Problems. In Evolutionary Computation. pp. 1139 -
1146 vol. 2.
Camillo, C. and Stelle, D., 2008. Aplicando Algoritmos Genéticos ao problema de definição de escala de trabalho do
corpo de enfermagem de um Hospital Universitário. In XL SBPO Simpósio Brasileiro de Pesquisa Operacional. pp.
1216-1224.
Dias, H. J. C., 2010. Escalonamento de equipas de enfermagem de acordo com a previsão das necessidades de serviço.
Dissertação de Mestrado. Universidade Técnica de Lisboa. Instituto Superior de Economia e Gestão.
Linden, R., 2012. Algoritmos genéticos: uma importante ferramenta da inteligência computacional. 3ª Edição. São
Paulo: Brasport.
Mattioli, F. and Yamanaka, K., 2009. Algoritmos Genéticos aplicados à programação de Manutenção de Sistemas
Elétricos de Potência.
Poltosi, M. R. and Goméz A. T., 2007. Elaboração de escalas de trabalho de técnicos de enfermagem com busca tabu e
algoritmo genético. In XXXIX Simpósio Brasileiro de Pesquisa Operacional - SBPO. Pp 1832-1843.
Russel, S. and Norvig P., 2004. Inteligência Artificial. São Paulo : Editora Campus.

78
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

APLICAÇÃO DE RACIOCÍNIO BASEADO EM CASOS A

SISTEMAS DE SUPORTE DE TI – HELP DESK

Aldair Hoepers, Max Pereira e Ademar Schmitz

Universidade do Sul de Santa Catarina – UNISUL - Av. José Acácio Moreira, 787 – Tubarão (SC)

RESUMO
Este artigo apresenta a aplicação da técnica de Raciocínio Baseado em Casos (RBC), que consiste em utilizar experiência
passada para a solução de problemas e para o aprendizado, em uma ferramenta para auxiliar os funcionários do suporte de
TI – Tecnologia da Informação. O setor de Help-Desk tem como função auxiliar os clientes em qualquer tipo de
assistência e recebe diariamente várias dúvidas ou problemas, que muitas vezes são semelhantes. O sistema desenvolvido
utiliza uma base de dados com 12.716 registros de chamados e em 85,1% das buscas o sistema retornou pelo menos um
caso similar. Das buscas onde o sistema retornou pelo menos um caso similar, 68,3% das soluções desses casos puderam
ser reutilizadas.

PALAVRAS CHAVE
Help-Desk, Raciocínio baseado em Casos, Recuperação Inteligente de Informações

1. INTRODUÇÃO
Segundo Lagemann (1998), os setores de Help-Desk atualmente são usados para auxiliar clientes a qualquer
tipo de assistência. Os clientes fazem um contato com os operadores de Help-Desk que, tomam
conhecimento do problema, e baseados na sua experiência e conhecimento prestam uma informação ou
recomendam uma determinada ação para resolver o problema.
O trabalho realizado nesses setores é baseado em processo, ou seja, um conjunto de atividades
padronizadas que através de uma entrada, realiza um processamento para gerar a saída. Segundo Statdobler
(2006), no caso do processo de atendimento, uma das entradas é facilmente identificável como sendo o
contato do cliente, seja este contato uma reclamação, sugestão ou solicitação; é uma necessidade que o
mesmo apresenta para a qual espera um retorno. A saída deste processo de atendimento é definida como a
entrega ao cliente do resultado que o mesmo espera, seja um problema resolvido, uma solicitação atendida,
uma dúvida sanada, etc.
Raciocínio Baseado em Casos (RBC) é uma técnica de Inteligência Artificial (IA) que consiste em utilizar
experiência passada para a solução de problemas e para o aprendizado. Pode-se entender RBC como a
solução de um novo problema através de um caso similar já conhecido. Para Lee (1998), os sistemas de RBC
simulam o ato humano de relembrar um episódio prévio para resolver um determinado problema em função
da identificação de afinidades entre os mesmos que, para o domínio de sistemas de Help-Desk, pode ser
aplicado de forma simples. Cada atendimento ao cliente pode ser modelado em um caso que se forma
basicamente de problema e solução.
Segundo Wangenheim (2003), RBC tem sido utilizado em uma série de domínios de aplicação, entre elas:
análise financeira, assessoramento de riscos, diagnóstico médico, suporte a sistemas de software, avaliação
imobiliária, suporte ao cliente, etc. Fernandes et al (2010a) apresentam o desenvolvimento de uma FAQ
(Frequently Asked Questions, em português, perguntas mais frequentes) baseada em RBC para suporte a
usuários do sistema web ECG®, sistema voltado para a área de têmperas e vidraçarias. O sistema foi
desenvolvido devido ao fato de que as dúvidas dos usuários sobre o sistema são resolvidas através de e-mail,
telefone, fax e chats por duas pessoas que também são responsáveis pelo desenvolvimento do sistema. Para o
desenvolvimento da ferramenta RBC utilizou-se um dicionário de sinônimos que contém todo o vocabulário
de palavras formado com o cadastro das dúvidas dos usuários. Em Oliveira (2008) apresenta-se uma pesquisa
cujo objeto é avaliar a medida de precisão de um sistema de recuperação de informação jurídica

79
ISBN: 978-972-8939-96-0 © 2013 IADIS

(jurisprudência) do Tribunal Regional Eleitoral do Distrito Federal que utiliza a técnica de RBC. O modelo
definido como modelo clássico, que utiliza o modelo de recuperação de informação booleano, sendo que esse
modelo apresenta um índice de precisão máximo de 25%. O modelo de recuperação baseado em casos
utilizado na pesquisa apresentou-se como um mecanismo eficiente na recuperação de jurisprudência eleitoral
na medida em que o resultado da avaliação da precisão obteve uma média global de 54%.
Fernandes et al (2010b) também apresentam um estudo que consiste em aplicar a técnica de RBC em uma
ferramenta já existente de service desk chamada de SYSDESK, buscando auxiliar na resolução de
problemas/incidentes encontrados por vários níveis de usuários, melhorando o atendimento do chamado. O
protótipo desenvolvido utiliza a técnica de nearest neighbour para realizar o cálculo de similaridade entre os
casos. Outra ferramenta de apoio a Help-Desk [Viel, 2010] aplicada na empresa inDATA Sistemas tem
como objetivo agilizar o atendimento a clientes, bem como simplificar a resolução de eventuais problemas e
facilitar o serviço do atendente, apresentando sugestões similares através da técnica de similaridade do RBC.
Foram levantados dados estatísticos ao longo do período de implantação da ferramenta, bem como na
utilização do mesmo, sendo que se constatou um aumento de praticamente 50% no número de atendimentos
solucionados por dia.
Atualmente, os funcionários do suporte de TI da Universidade do Sul de Santa Catarina (UNISUL)
realizam em média 1.200 atendimentos por mês, onde os atendimentos classificados como incidentes levam
cerca de 27 horas para serem finalizados e os atendimentos classificados como requisição de serviços levam
cerca de 46 horas. A implementação de uma ferramenta inteligente de Help-Desk para apoiar esses
funcionários visa principalmente agilizar o atendimento aos usuários melhorando a qualidade do trabalho
prestado.
Ademais, os funcionários que não tem conhecimento sobre o problema que estão resolvendo podem
utilizar a ferramenta para buscar um problema anterior, similar já solucionado e assim utilizar sua respectiva
solução, não tendo a necessidade de consultar funcionários mais experientes. Com isso, diminui-se o tempo
de atendimento, que por sua vez gera a satisfação do cliente. A ferramenta também poderá oferecer a solução
para o problema, relatado pelo funcionário, sendo que esta solução foi anteriormente proposta por um
funcionário mais experiente e que pode ter passado por uma revisão de um especialista.
A implementação de uma ferramenta Help-Desk inteligente é uma proposta para auxiliar os funcionários
do suporte de TI da UNISUL utilizando a técnica de RBC. Uma importante vantagem na implementação da
ferramenta proposta é a associação da tecnologia inteligente, que é o RBC, com o aproveitamento da base de
dados já existente do setor de suporte de TI da UNISUL.

2. MATERIAIS E MÉTODOS
Segundo Lee (1998), o raciocínio humano reproduzido no sistema de RBC funciona de acordo com a
suposição de que problemas cuja descrição possui forma similar apresentam soluções similares e que os tipos
de problemas se repetem. Com isso, soluções de problemas resolvidos anteriormente e armazenados na base
de casos que sejam similares ao problema atual são um ponto de partida muito útil para a solução desse novo
problema.
A ferramenta RBC para Help-Desk foi desenvolvida para o ambiente web, utilizando as tecnologias Java
(frameworks JSF, PrimeFaces, Spring e Hibernate), servidor web Apache Tomcat 7 e banco de dados
relacional PostgreSQL.
Os casos da aplicação foram armazenados no banco de dados PostgreSQL, sendo que para a
representação dos casos foi utilizada a estrutura atributo-valor, que é a estrutura mais simples e que resolve
grande parte dos problemas de sistemas de RBC.

2.1 Representação dos Casos

A representação atributo-valor utiliza vetores atributo valor (Ex.: preço (atributo) e R$ 1,99 (valor)), onde um
par desses representa um dado e um conjunto desses pares representa um caso. Para determinar um caso,
definiu-se um conjunto fixo de atributos, onde cada atributo está associado a um domínio (tipo de dado) ou
faixa para seus possíveis valores. A representação definida para o sistema pode ser vista na Tabela 1.

80
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Tabela 1. Representação dos casos

Atributo Tipo Caso exemplo
Aluno não consegue acessar o EVA, ocorre
Descrição do problema Texto
erro de senha.
Solicitante Símbolo Aluno
Tipo do chamado Símbolo Incidentes
Data do chamado Data 27/01/2013
Data de finalização Data 15/02/2013
Categoria 1 Símbolo Serviços de Aplicações
Categoria 2 Símbolo Ensino a Distância
Categoria 3 Símbolo EVA
Problema de integração EVA e AD. resolvido
Solução Texto com reset de senha diretamente no Active
Directory.
Nome do atendente Texto José Maria

Um instrumento muito importante para orientar a avaliação de similaridade dos casos na base de casos é a
indexação, que define quais atributos (índices), devem ser usados para realizar a comparação entre um caso e
a situação presente. O conjunto de descritores que são usados como índices modelam a resposta para a
pergunta, "o que faz um caso ser similar a outro?" - representando a relevância dos casos [Lee 1998].
Segundo Wangenheim (2003), bons índices são relevantes para uma meta de recuperação específica e

 Serem fáceis de extrair dos casos armazenados na base de casos;

deveriam possuir as seguintes propriedades:

 Serem usáveis e disponíveis como pistas de recuperação;

 Categorizarem os casos na base de casos ao longo de algumas dimensões interessantes.
No sistema implementado, os índices foram definidos de acordo com o contexto de Help-Desk e com o
auxílio de um especialista do setor de suporte da UNISUL, que são os seguintes: Descrição do problema,
Solicitante, Tipo do chamado, Categoria 1, Categoria 2 e Categoria 3 (as categorias referem-se às aplicações
e seus respectivos setores na universidade).

2.2 Recuperação dos Casos

A medida de similaridade nearest neighbour [Coomans e Massart, 1982] é uma das técnicas mais utilizadas
por ser bastante simples e foi adotada para a implementação do sistema. Essa técnica baseia-se na
comparação entre um novo caso e aqueles armazenados na base de casos utilizando uma soma ponderada das
suas características.


Onde:


Q = novo caso


C = caso existente na base


n = número de atributos


i = atributo individual variando de 1 a n


f = medida de similaridade local
w = peso do atributo i

O cálculo é feito para cada caso da base de dados, tendo com isso a ordenação dos casos. A similaridade é
normalizada entre zero (0) e um (1), ou seja, zero não possui nenhuma semelhança e um é exatamente
similar. Os atributos definidos com os seus respectivos pesos pode ser visto na Tabela 2.

81
ISBN: 978-972-8939-96-0 © 2013 IADIS

Tabela 2. Atributos para o cálculo de similaridade e seus pesos

Atributo Peso
Descrição do problema 0.65
Solicitante 0.05
Tipo do chamado 0.10
Categoria 1 0.10
Categoria 2 0.07
Categoria 3 0.03

Ao se calcular a similaridade global, pode-se considerar também a similaridade local entre atributos
específicos, a fim de tornar o cálculo de similaridade muito mais sensitivo entre uma questão dada e os casos
na base de casos.
A medida de similaridade para cada um dos atributos Solicitante, Tipo do chamado, Categoria 1,
Categoria 2 e Categoria 3 é calculada da seguinte forma: 1 se o valor do atributo do novo caso for igual ao do
caso da base, e 0 se o valor do atributo do novo caso não for igual ao do caso da base.
Já para o atributo Descrição do Problema foi utilizada a técnica de recuperação inteligente de
informações, que consiste na representação, organização, armazenamento e recuperação de informações
textuais. Para tanto, foi implementado um módulo com todos os aspectos relevantes de um sistema de
indexação e recuperação de informações textuais, tais como parsing, remoção de stopwords, stemming,
weighting, indexação, etc. [Manning et al, 2008]. Este módulo considera a representação dos textos num
espaço vetorial, sendo o cálculo da similaridade entre os textos (Descrição do Problema) realizado por meio

 xy
da similaridade do cosseno [Feldman e Sanger, 2006] [Tan et al, 2005]:
X Y
sim( X , Y)  
x  y
n
i 1 i
X Y
i
2 2
i i
i i


Onde:


sim(X, Y): valor entre 0 e 1, representando o grau de similaridade entre os vetores X e Y.


X: vetor representando a primeira descrição.


Y: vetor representando a segunda descrição.


xi: elementos de X na posição i.
yi: elementos de Y na posição i.

Como método de recuperação, o sistema utiliza a técnica de recuperação sequencial, onde a medida de
similaridade é calculada sequencialmente para todos os casos da base de casos. Em seguida, todos os casos
são ordenados de acordo com sua similaridade, e então, como resultado retorna-se os m casos mais similares.
Um exemplo de recuperação no sistema por ser visto na Figura 1.

82
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Figura 1. Exemplo de recuperação dos casos

Na ferramenta implementada não foi utilizada nenhuma técnica de adaptação automática de casos, sendo
assim, foi disponibilizada a solução para o usuário, deixando-o livre para proceder à adaptação. Para a
revisão de casos, foi implementada uma tela que somente os especialistas têm acesso, e nela eles podem
encontrar os casos desejados através de vários filtros, e em seguida editar os dados do caso, conforme
acharem necessário.

3. RESULTADOS E DISCUSSÕES
Para validação e análise dos resultados a base de dados foi criada no PostgreSQL versão 8.4.13, exportando
para esta nova base 12.716 casos do sistema utilizado pelo suporte atualmente. Os testes para validação
foram feitos por um especialista do setor de suporte de TI da UNISUL utilizando chamados recentes que já
foram fechados, sendo possível comparar a solução dada no chamado com as soluções apresentadas pelo
sistema RBC. Foram executadas 74 buscas por casos similares no sistema, obtendo-se os seguintes

 Em 85,1% das buscas o sistema retornou pelo menos um caso similar.

resultados:

 Das buscas onde o sistema retornou pelo menos um caso similar, 68,3% das soluções

 Dos casos onde a solução pode ser reutilizada, 62,8% das soluções foram reutilizadas em
desses casos puderam ser reutilizadas.

 A média do percentual de similaridade dos casos reutilizados foi de 59,8%.

partes e 37,2% das soluções foram reutilizadas por completo.

 A média de casos retornados nas buscas foi de 12 casos similares.

A frequência do percentual de similaridade utilizado como filtro nas buscas pode ser vista na Tabela 3.

83
ISBN: 978-972-8939-96-0 © 2013 IADIS

Tabela 3. Frequência dos filtros de similaridade

% de similaridade Frequência
70 1,4%
60 17,6%
50 43,2%
40 37,8%
Nas buscas onde o sistema não encontrou um caso similar, segundo o especialista, o caso de entrada
utilizado para o teste era um caso bem específico ou pouco frequente. Nas buscas onde foi encontrado pelo
menos um caso similar, mas não foi possível utilizar a mesma solução, se deve ao fato de que realmente é um
novo caso, ou a solução não foi registrada corretamente no sistema de chamados (impossibilitando a
reutilização da mesma).
O Gráfico 1 mostra um exemplo de uma relação entre um caso ideal e quatro casos retornados na busca
pelo sistema. Neste gráfico, pode-se verificar a similaridade para cada atributo, ou seja, o quanto o percentual
de similaridade de cada atributo dos casos retornados se aproxima dos atributos do caso ideal.

0,7

0,6
Peso de cada atributo

0,5

0,4 caso 1
caso 2
0,3 caso 3
caso 4
0,2
caso ideal
0,1

0
categoria 3 solicitante categoria 2 tp. chamado categoria 1 descrição
Atributos do caso

Gráfico 1. Problema apresentado x casos retornados

O Gráfico 2 é uma amostra com 19 testes executados onde foi possível reutilizar a solução de um caso da
base de dados. Este gráfico possui a relação do percentual de similaridade utilizado no filtro, a quantidade de
casos retornados na busca e o percentual de similaridade do caso reutilizado. É possível perceber que grande
parte dos casos reutilizados teve um percentual de similaridade acima de 50% em relação ao caso de entrada,
e que praticamente em todas as buscas a quantidade de casos retornados foi acima de 1 caso.

84
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

90
80
Percentual de similaridade do caso

70
60
50
reutilizado

40
30
20
10

5
13,0
0

11
40 40 40

2,0
40 40 40

15
40 50 50
50 50 50

37
50 50 Casos retornados
50 60
Percentual de similaridade do filtro 60 60

16
70

Gráfico 2. Resultados das buscas na base de casos

Nas buscas executadas pelo especialista foi evitado utilizar chamados semelhantes, sendo escolhidos
problemas bem diversos. Após a validação, o especialista relatou que mesmo não encontrando a solução, os
casos similares retornados pelo sistema RBC podem ajudar os técnicos na condução do atendimento do
chamado, dando dicas/caminhos do que ele pode fazer para solucionar o problema do chamado. O mesmo
ainda relatou que a utilização do sistema RBC vai influenciar na melhoria da qualidade dos registros de
solução dos problemas, pois hoje como esses registros servem somente para feedback para o usuário, muitas
vezes não é feito o devido registro da solução dos problemas.

4. CONCLUSÃO
Como objetivo geral tinha-se desenvolver uma ferramenta utilizando RBC para o setor de suporte de TI da
UNISUL. Com uma grande massa de casos do próprio suporte, executaram-se os testes e a validação com um
especialista do setor, e após isso, pode-se perceber o quanto esta ferramenta poderá vir a ajudar o dia-a-dia de
todos os colaboradores nos atendimentos aos usuários, porque ao invés da equipe de suporte ter de formular
uma nova solução a cada dúvida relatada, o RBC propiciou que se utilizassem soluções de questionamentos
similares salvos na base de casos.
Os resultados obtidos após a validação foram satisfatórios, pois em 68,3% das buscas onde retornou-se
pelo menos um caso similar, pôde-se reutilizar algo da solução apresentada pela ferramenta. Além disso, nas
buscas onde nenhuma solução apresentada pelo sistema pode ser reutilizada, as soluções apresentadas
serviram de auxílio a possíveis caminhos que o técnico atendente pode tomar para solucionar o problema do
chamado.
O setor atualmente possui uma alta demanda de atendimentos e está sempre sobrecarregado, e com isso é
perceptível que a utilização da ferramenta desenvolvida no setor poderá trazer mais qualidade e agilidade na
maioria dos atendimentos prestados. O uso de uma ferramenta RBC quando uma base de casos já existe é de
grande valia, não somente no suporte de TI da UNISUL, mas em qualquer setor de Help-Desk, pois utiliza os
dados em forma de conhecimento para auxílio nos atendimentos.
Como trabalho futuro pretende-se integrar a ferramenta implementada com o sistema de gerenciamento
de atendimentos já existente no setor, tendo assim a base de casos sempre atualizada para as buscas por casos
similares.

85
ISBN: 978-972-8939-96-0 © 2013 IADIS

REFERÊNCIAS
Coomans D.; D.L. Massart, 1982. Alternative k-nearest neighbour rules in supervised pattern recognition : Part 1. k-
Nearest neighbour classification by using alternative voting rules. Analytica Chimica Acta, No. 136, pp 15-27.
Feldman, R. Sanger J., 2006. The Text Mining Handbook: Advanced Approaches in Analyzing Unstructured Data.
Cambridge University Press.
Fernandes, Anita Maria da Rocha et al., 2010. Aplicação de Raciocínio Baseado em Casos em Service Desk. VII SEGeT
– Simpósio de Excelência em Gestão e Tecnologia. Resende, Brasil.
Fernandes, Anita Maria da Rocha et al., 2010. Desenvolvimento de uma FAQ baseada em RBC para suporte a usuários
web. VII SEGeT – Simpósio de Excelência em Gestão e Tecnologia. Resende, Brasil.
Lagemann, Gerson Volney, 1998. RBC para o problema de suporte ao cliente nas empresas de prestação de software: o
caso Datasul. 1998. Dissertação (Mestrado em Engenharia) – Universidade Federal de Santa Catarina, Florianópolis,
Brasil.
Lee, Rosina Weber, 1998. Pesquisa Jurisprudencial Inteligente. Tese (Doutorado em Engenharia) – Universidade
Federal de Santa Catarina, Florianópolis, Brasil.
Manning, C. D., P. Raghavan, H. Schütze, 208.An Introduction to Information Retrieval . Cambridge University Press.
Oliveira, Symball Rufino de, 2008. Recuperação Inteligente de Jurisprudência: Uma Avaliação do Raciocínio Baseado
em Casos Aplicado a Recuperação de Jurisprudências noTribunal Regional Eleitoral do Distrito Federal. 126 f.
Dissertação (Mestrado em Ciências da Informação) – Universidade de Brasília, Brasília, Brasil.
Statdobler, Juliano, 2006. Help-Desk e SAC com qualidade. Brasport, Rio de Janeiro, Brasil.
Tan, P. N., Steinbach, M., Kumar, V., 2005. Introduction to Data Mining. Addison-Wesley Longman Publishing, Boston,
USA.
Viel, Mateus. 2010. Workcontrol – ferramenta de apoio ao Atendimento a clientes utilizando técnica de Raciocínio
baseado em casos. 77 f. Monografia (Graduação em Sistemas de Informação) – Universidade Regional de Blumenau,
Blumenau, Brasil.
Wangenheim, Cristiane Gresse von; Wangenheim, Aldo von, 2003. Raciocínio Baseado em Casos. Ed. Manole, Barueri,
Brasil.

86
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

SCHISTOSYSTEM – INTELIGÊNCIA ARTIFICAL PARA

DIAGNÓSTICO AUTOMÁTICO POR IMAGENS

André Caetano Alves Firmo1, Allison Dantas de Oliveira2, Julyana Viegas Campos3,
Jones Albuquerque4 e Constança Barbosa3
1
Epi Schisto Risk Modeling
2
Universidade Federal Rural de Pernambuco
3
CPqAM/FIOCRUZ
4
UFRPE

RESUMO
Com o avanço da esquistossomose no estado de Pernambuco e a descoberta de focos na região litorânea, são necessárias
novas ações para a contenção da doença. Uma das medidas de controle é a identificação e o tratamento das pessoas
doentes. O diagnóstico mais rápido e eficiente é de extrema prioridade para a quebra do ciclo e erradicação da epidemia.
Neste trabalho é apresentada uma proposta de implementação de um sistema de identificação e contagem dos ovos de
Schistosoma Mansoni a partir da proposta de um dispositivo de aquisição de imagens coletadas de lâminas de amostras
de fezes. Este trabalho foi fruto de uma parceria entre o grupo de pesquisa Epischisto, o laboratório de Esquistossomose
do Departamento de Parasitologia da CpqAM/FIOCRUZ e o Programa de pós-graduação da Universidade Federal Rural
de Pernambuco. O sistema é baseado em uma solução de hardware composta por uma webcam acoplada ao microscópio
capturando imagens das lâminas dos exames de fezes de indivíduos suspeitos de estarem infectados. A partir do
processamento digital dessas imagens, é utilizado um software de reconhecimento de padrões baseado em uma cascata de
classificadores fracos. Esses classificadores fracos são formados por características de haar compondo um único
classificador forte capaz de reconhecer e contar os ovos de S. mansoni. Os classificadores são treinados por uma técnica
de inteligência computacional chamada de otimização por enxame de partículas garantindo maior rapidez e precisão ao
sistema.

PALAVRAS CHAVES
Kato-Katz, Esquistossomose, diagnóstico, automação, inteligência artificial, sistema.

1. INTRODUÇÃO
O presente trabalho tem como escopo principal o desenvolvimento de uma solução de detecção de imagens
para contagem de ovos de Schistosoma mansoni em exames de fezes. A solução é composta de um hardware
para a aquisição das imagens e um sistema baseado em uma cascata de classificadores fracos formados por
características de haar e treinados a partir de uma otimização por enxame de partículas no algoritmo
AdaBoost.

1.1 Caracterização do Problema

A Esquistossomose mansônica afeta cerca de 200 milhões de pessoas em várias regiões do mundo. Segundo
(Katz, Peixoto-2000), no Brasil, a doença é considerada uma endemia e apresenta de 2,5 a 6 milhões de
indivíduos parasitados. Sua distribuição é observada na faixa litorânea que compreende desde a região Norte
até a região Sul, apresentando-se como endêmica em vários estados do Nordeste. Segundo (Kano-1992),
Pernambuco tem a segunda maior prevalência entre os estados nordestinos, representando 15,2% da região.
Nesse estado, a esquistossomose é historicamente endêmica na região rural, em localidades onde as taxas de
infecção humana variam de 12% a 82%.

87
ISBN: 978-972-8939-96-0 © 2013 IADIS

A prevalência e a intensidade da infecção nas comunidades de Pernambuco afetadas pela doença estão
condicionadas a práticas culturalmente moldadas como: atividades econômicas, de lazer ou domésticas,
peculiares em cada localidade como aponta (Barbosa, Gonçalves, Albuquerque-1998).
Recentemente, casos humanos de infecção aguda têm sido detectados em regiões praieiras (Barbosa,
Gonçalves, Albuquerque-1998) (Barbosa, Pieri-2000) (Barbosa, Coutinho, Montenegro, Abath, Spineli-
2001), onde a doença está sendo introduzida devido à ausência de planejamento socioeconômico na ocupação
desses espaços. Este fato tem sido comprovado através de focos de vetores da esquistossomose encontrados
em localidades litorâneas do estado, além de novos sítios de transmissão ativa da doença detectados em
praias de turismo e veraneio de classe média alta. Levantamentos malacológicos realizados em municípios do
litoral pernambucano apontam 12 novos focos de esquistossomose em localidades praianas do Estado
(Barbosa, Gonçalves, Albuquerque-1998) (Barbosa, Pieri-2000) (Barbosa, Coutinho, Montenegro, Abath,
Spineli-2001).
O método de diagnóstico através do exame parasitológico de fezes ainda é a melhor alternativa por ter
uma boa sensibilidade e um menor custo de operação. Neste método ainda não há uma ferramenta
automatizada que auxilie na contagem dos ovos de S. mansoni, necessitando de um profissional devidamente
qualificado para tal trabalho. Na Figura 1é apresentado o ciclo da doença.

Figura 1. Ciclo da esquistossomose.

As técnicas de inteligência computacional são capazes de proporcionar maior desempenho e eficiência no
treinamento de sistemas baseados em técnicas de reconhecimento de padrões. Tais sistemas são uma boa
alternativa para o desenvolvimento de uma ferramenta que auxilie na automatização da contagem de ovos de
S. mansoni a partir de exames parasitológico de fezes com o objetivo de diagnosticar a esquistossomose.

2. SOLUÇÃO PROPOSTA
A descrição da solução proposta para a contagem automatizada dos ovos de S. mansoni nos exames
parasitológicos de fezes dos indivíduos suspeitos, está dividida em 2 (duas) fases distintas: Na primeira fase,
é feita a aquisição das imagens da lâmina do exame parasitológico de fezes dos indivíduos suspeitos e
realizado o processamento adequado das imagens. Na segunda fase é apresentado o desenvolvimento de um
sistema que identifique e detecte o ovo de S. mansoni nas imagens geradas a partir da primeira fase.

88
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

2.1 1ª Fase – Captura e Pré-processamento da Imagem

Na primeira fase da solução proposta o grande desafio é a captura da imagem da lâmina do exame
parasitológico de fezes de um indivíduo infectado. A realização desta fase pode ser descrita em três
atividades principais: A seleção do equipamento de captura de imagens, o acoplamento do equipamento
selecionado ao microscópio e o pré-processamento das imagens capturadas. Na escolha do equipamento de
captura foram verificadas várias câmeras fotográficas e webcams onde a melhor relação de custo e benefício
foi uma webcam com sensor CMOS de 2ª geração, resolução de 2M pixels.
O acoplamento da webcam a lente ocular do microscópio foi feito através de um adaptador desenvolvido
para fixar as lentes em posição de justaposição e com o ajuste do foco manualmente. Na figura 2 é possível
verificar a webcam e o adaptador.

Figura 2. Vista frontal (A) e lateral (B) da webcam com o adaptador para acoplamento ao microscópio.
Com a fase de captura concluída e funcional, foi necessário definir quais recursos de pré-processamento
deveriam ser aplicados às imagens capturadas. A primeira técnica utilizada foi a conversão da imagem
colorida para Grayscale. O uso da imagem em Grayscale proporciona uma maior velocidade no
processamento e menor uso de recursos computacionais. Após a conversão da imagem, foi aplicado uma
equalização por histograma para configurar adequadamente o contraste e realçar informações que antes
estavam perdidas. Por fim foi aplicado um detector de borda baseado em um operador gaussiano de primeira
derivada além de suavizar os ruídos na imagem.

2.2 2ª Fase – Desenvolvimento do sistema SchistoSystem

Com a conclusão da 1ª Fase e a disponibilização das imagens das lâminas dos exames parasitológicos de
fezes dos indivíduos, é necessário um software para realizar a detecção dos ovos de S. mansoni. A realização
desta fase pode ser descrita em três atividades principais: A criação do conjunto de treinamento, o
desenvolvimento da aplicação de detecção de ovos de S. mansoni e o teste do sistema.
O desenvolvimento do sistema foi fundamentado na biblioteca OpenCV de visão computacional
desenvolvida e distribuída livremente pela intel.
2.2.1 Criando o Conjunto de Treinamento
A criação do conjunto de treinamento consiste em capturar dois tipos de imagens distintas: positivas e
negativas. As imagens positivas são aquelas que contêm o objeto de interesse a ser detectado e as imagens
negativas são exemplos onde não contém o objeto de interesse.
Foi utilizada a linguagem de programação python e as funções da biblioteca OpenCV para o
desenvolvimento de uma ferramenta chamada de xistocap para captura das imagens. No Algoritmo 1 está
descrito o pseudocódigo do xistocap.

89
ISBN: 978-972-8939-96-0 © 2013 IADIS

Algoritmo 1. Pseudocódigo do xistocap.

Inicializa a webcam;
Transforma a imagem associada a webcam em uma estrutura de imagem do OpenCV;
Exibe a imagem em uma janela intitulada “Câmera”;
Se pressionada a tecla “P” do teclado.
Salva a imagem com estrutura de nome “Positivaxxx”;
Se pressionada a tecla “N” do teclado.
Salva a imagem com estrutura de nome “Negativaxxx”;
Se pressionada a tecla “Q”.
Fecha o programa.

Após a captura das imagens é necessário marcar o objeto de interesse nas imagens positivas. Essa
marcação é feita com o auxílio de uma aplicação que carrega cada imagem positiva e permite marcar com um
retângulo o objeto de interesse. A aplicação cria um arquivo de texto contendo o caminho da imagem
positiva, a posição do retângulo que marca o objeto de interesse, as dimensões largura e altura do retângulo e
a quantidade de objetos em cada imagem. Este arquivo de texto será utilizado pela ferramenta de criação dos
exemplos. Nesta etapa foi necessária a colaboração de um técnico de laboratório experiente no
reconhecimento dos ovos de S. mansoni para marcar as imagens positivas. Na Figura 3 é mostrada uma
imagem positiva marcada e um exemplo negativo.

Figura 3. (A) Imagem positiva marcada e (B) imagem negativa

Com o arquivo das imagens marcadas é usado uma ferramenta chamada Createsamples disponível no
OpenCV para criação de um arquivo com os exemplos gerados. O Createsamples forma os arquivos de
exemplos já aplicando Grayscale e equalização de histograma, gerando a caracterização de cada exemplo em
um arquivo .vec. A quantidade de imagens do conjunto de treinamento influência diretamente na taxa de
acerto do sistema.
2.2.2 Desenvolvimento da Aplicação SchistoSystem
Com os arquivos de exemplos criados, o próximo passo é treinar a cascata de classificadores com a
ferramenta Haartraining disponível no OpenCV.
No OpenCV, o processo de detecção de objetos é baseado na classificação de simples características. As
características são baseadas nas funções básicas de Haar e foram descritas em (Papageorgiou, Oren, Poggio-
1998). As características de Haar são simples retângulos compostos de duas regiões uma clara e outra escura.
O valor da característica é a diferença entre a soma das intensidades dos pixels da região clara e a soma das
intensidades dos pixels da região escura.
A escolha de características de haar, ao invés de modelos estatísticos que são baseados em pontos da
imagem, é justificada em (Viola, Jones-2004) pelo fato de serem de simples e rápida computação, utilizando-
se de imagem integral e por conterem informações de atributos embutido e de difícil mapeamento de forma
estatística.

90
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

(Viola, Jones-2004) descreve quatro tipos de características básicas de Haar para uso em detecção de
faces. A Figura 4 mostra as características básicas de Haar.

Figura 4. Características básicas de Haar.

Um classificador fraco hj é uma simples estrutura contendo um vetor de características fj, um limiar θj e
uma paridade pj. A idéia central deste classificador é encontrar um limiar que melhor separe o valor de uma
característica entre imagens definidas como positivas das características definidas como negativas.
Boosting é um algoritmo de aprendizagem supervisionado que forma hipóteses fortes por meio de uma
combinação linear de hipóteses fracas. No OpenCV, representam-se hipóteses fracas como classificadores
fracos derivados de um conjunto de características básicas de Haar.
AdaBoost (Adaptative Boost) foi desenvolvido por (Freund, Schapire-1999) e tem como característica
principal a distribuição de pesos nos conjuntos de exemplos e a modificação desta distribuição com o
decorrer das iterações do algoritmo.
Nesta etapa foi realizada uma modificação na estrutura de treinamento da cascata onde ao invés da
utilização do algoritmo AdaBoost implementado no Haartraining foi utilizado um algoritmo AdaBoost com
uso de uma técnica de inteligência de enxames o PSO (Particle Swarm Otimization).
Otimização por Enxame de Partículas foi proposto por (Kennedy, Eberthart-1995)(Eberthart, Kennedy-
1995) e é um dos mais importantes paradigmas de inteligência de enxames. O PSO usa um mecanismo
simples baseado no comportamento do vôo de pássaros para guiar partículas em busca de uma solução ótima
global. O PSO é baseado em um método estocástico e não se utiliza de gradientes. Sua implementação é
bastante simples e é aplicado na resolução de problemas de otimização com várias variáveis em espaços
contínuos.
O algoritmo de PSO é baseado em uma população de partículas, onde cada partícula representa uma
possível solução do problema em questão. Cada partícula p pode ser representada como um objeto com
várias características. A posição da partícula é ajustada de acordo com sua própria experiência e da
experiência de sua vizinhança. A melhor posição individual da partícula representa a posição em que a
partícula esteve onde obteve a melhor avaliação. Como exemplo, numa tarefa de uma minimização, a posição
de uma partícula que obteve o menor valor da função é considerada como sendo a posição com melhor
avaliação ou com mais alta aptidão.
O PSO foi utilizado para selecionar as características que possuem menor erro com o conjunto de
imagens positivas. O resultado do treinamento é um arquivo .xml que contém todas as informações sobre o
treinamento, as características escolhidas por estágios e seus respectivos limares.
O desenvolvimento da aplicação foi realizado em dois módulos: um módulo instalado no cliente onde é
responsável pela aquisição da imagem e do processamento das informações e um módulo web que armazena
as informações e exibe relatórios de acompanhamento.
No módulo cliente foi utilizada a linguagem de programação python e a biblioteca OpenCV para acesso à
webcam com a captura das imagens e processamento das informações. Na Figura 5 é mostrada a tela de
utilização do sistema cliente onde são inseridos os dados do número da amostra, nome do paciente,
município, data do exame e o técnico responsável.
Na utilização do módulo cliente após a inserção dos dados o técnico de laboratório vai correndo a lâmina
no microscópio e o sistema vai identificando e contando os ovos de S. mansoni. A pós correr toda a lâmina
no microscópio, o técnico aciona o botão enviar e terá o resultado de quantos ovos há naquela amostra e esses
dados são armazenados em um banco de dados do tipo MySQL que será acessado pelo módulo web para
geração dos relatórios.
O módulo Web é uma ferramenta onde os gestores e supervisores podem acompanhar e extrair os
resultados das análises laboratoriais. Este módulo foi desenvolvido com páginas web implementadas com
PHP para acessar o banco MySQL e gerar as informações dinamicamente. Para acesso ao sistema é
necessário apenas um browser e ter login e senha para gerar essas informações. Na Figura 6 temos a tela
inicial do módulo web.

91
ISBN: 978-972-8939-96-0 © 2013 IADIS

Figura 5. Tela de utilização do sistema cliente.

Figura 6. Tela de login do módulo web.

A pós ter acesso ao sistema é possível realizar uma consulta por 3(três) parâmetros: município, técnico ou
data. Na Figura 7 é exibida a tela de consulta.

Figura 7. Tela de consultas do módulo web.

Com a escolha do parâmetro para a geração do relatório, é acionado o botão Gerar que formata as
informações e as exibe como mostrado na Figura 8.

92
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Figura 8. Tela com relatório de acompanhamento das análises gerado pelo sistema.

2.2.3 Teste com o Sistema

Foram realizados alguns testes com o sistema SchistoSystem onde foi utilizado algumas lâminas de
referências. Nestes testes preliminares foi verificado uma melhora significativa na ergonomia dos técnicos e a
utilização do sistema teve uma curva de aprendizado bastante curta. Com relação aos primeiros resultados
foram animadores onde houve uma taxa de acerto em torno de 80% com uma taxa de falsos positivos de
50%. Esses valores são justificados pela quantidade de exemplos do conjunto de treinamento ser inferior ao
considerado ideal em um sistema de reconhecimento de padrão onde (Viola, Jones-2004) indica 10.000
imagens como conjunto relevante. Uma das ações já em andamento é a construção de um conjunto de
treinamento com mais exemplos, a fim de melhorar a precisão na detecção e contagem. Com relação ao
tempo de treinamento, o PSO obteve um tempo médio de 32,8s para uma cascata de 30 estágios contra 7200s
do treinamento utilizando a implementação do Haartraining disponível no OpenCV.

3. CONCLUSÃO
Os primeiros testes com o sistema foram bastante animadores, pois o tempo médio para a realização da
análise da lâmina por um técnico de laboratório experiente é em torno de 15 minutos contra 5 minutos com o
uso do sistema. A precisão e nível de acertos do sistema ainda não estão em um percentual que possa ser
utilizado em produção por necessitar que o conjunto de treinamento seja ampliado. Na elaboração desta
primeira versão foram usadas 2000 imagens positivas e 2000 imagens negativas, onde observando outros
sistemas de detecção de padrões, é indicado o uso de um conjunto de treinamento com um mínimo de 10.000
imagens positivas e 10.000 imagens negativas.
A forma com que a análise das lâmina é realizada com o uso do sistema é uma quebra de paradigmas que
proporciona melhor ergonomia para os técnicos de laboratório, pois não é mais necessário a exposição do
olho as variações de luminosidade do microscópio bem como a postura de sentar e manipular o microscópio
ajuda a prevenir doenças associadas ao LER/DOR.

93
ISBN: 978-972-8939-96-0 © 2013 IADIS

Além disso, pode-se destacar o uso do sistema para realizar treinamentos e exposição de casos incomuns
que podem ser encontrados nas lâminas já que há a possibilidade de gravação das imagens do microscópio. A
criação de um banco de dados integrado e georreferenciado de localidades com casos positivos; relatórios e
acompanhamento de resultados; realização de screennings rápidos para selecionar localidades com maior
numero de casos e presteza na realização dos exames são outros benefícios associados ao uso do sistema.
Como trabalhos futuros e atualizações pode-se destacar as seguintes ações que já são objeto de estudos: A
implementação de um mecanismo automatizado para a manipulação das lâminas; o aumento do conjunto de
treinamento; o desenvolvimento de uma versão para o uso com dispositivos móbiles; integração com outras
plataformas de análise de epidemiologia e construção de uma base de dados nacional sobre a evolução de
prevalência da esquistossomose.
O uso da proposta implementada pela solução SchistoSystem pode ser abrangente e incorporar outras
formas de microorganismos e de objetos de análises microscópicas como, por exemplo: análise de bactérias;
uso em análises sanguíneas, podendo contemplar outras doenças e uso como instrumento de pesquisa onde
para cada novo caso é necessária a criação de um novo conjunto de treinamento e ajustes na formulação dos
relatórios e da interface com o usuário.

REFERÊNCIAS
N. Katz., S. V. Peixoto, 2000. Análise crítica da estimativa do número de portadores de esquistossomose mansoni no
Brasil. Revista da Sociedade Brasileira de Medicina Tropical, Brasil.
P.H. Kano, 1992. Measures for Control of Schistosomiasis Adapted by the Fundação Nacional de Saúde. In Memórias do
Instituto Oswaldo Cruz, 87 (Sup. IV), 315-318.
C. S. Barbosa, J. F. Gonçalves, Y. Albuquerque, F. S. Barbosa, 1998. Urban Schistosomiasis in Itamaracá island, Brasil,
epidemiological factors 66 involved in the recent endemic process. In Memórias do Instituto Oswaldo Cruz, 93 (01),
265-266.
C. S. Barbosa, O. S. Pieri, 2000. Aspectos epidemiológicos e malacológicos da esquistossomose mansônica na Ilha de
Itamaracá, Pernambuco. In Revista de Saúde Pública, 34(4), 33-41.
C. S. Barbosa, A. L. Coutinho, S. M. L. Montenegro, F. Abath, V. Spinelli, 2001. Epidemia de esquistossomose aguda na
praia de Porto de Galinhas, Pernambuco. In Rev. Inst. Med. trop. S. Paulo, 10:295-8.
Freund Y. and Schapire R. E., 1999. A Short Introduction to Boosting. In Journal of Japanese Society for Artificial
Intelligence, 771-780.
P. Viola, M. J. Jones., 2004. Robust real-time face detection. In Journal of Computer Vision, 57(2):137–154.
C. P. Papageorgiou, M. Oren, T. Poggio, 1998. A general framework for object detection. Proceedings of the Sixth
International Conference on Computer Vision. Washington, DC, USA, pp. 555.
J. Kennedy, R. C. Eberhart, 1995. Particle swarm optimization, in Proc. of the IEEE Int. Conf. on Neural Networks.
Piscataway, NJ, IEEE Service Center, pp. 1942–1948.
R. C. Eberhart and J. Kennedy, 1995. A new optimizer using particle swarm theory, in Proc. 6th Int. Symp.
Micromachine Human Sci., Nagoya, Japan, pp. 39–43.

94
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

EXTRAÇÃO E SELEÇÃO DE CARACTERÍSTICAS PARA

DIAGNÓSTICO AUTOMÁTICO DE DEFEITOS EM
MÁQUINAS ROTATÓRIAS

Francisco de Assis Boldt, Thomas Walter Rauber e Flávio Miguel Varejão

Universidade Federal do Espírito Santo, Avenida Fernando Ferrari, Goiabeiras, Vitória, Brasil

RESUMO
Neste trabalho apresentamos três modelos de extração de características a partir de dados vibratórios, coletados de
máquinas rotatórias, para detectar defeitos em rolamentos. Os nossos experimentos indicaram que utilizar mais de um
modelo de extração de características para criar uma base de dados global e selecionar as melhores características,
apresenta resultados melhores do que o uso de apenas um modelo de extração de características.

PALAVRAS-CHAVE
Extração de características, seleção de características, diagnóstico de defeitos, máquinas rotatórias, reconhecimento de
padrões.

1. INTRODUÇÃO
O diagnóstico automático de defeitos em equipamentos complexos possui vantagens econômicas e de
segurança. A identificação de um defeito, em seu estágio inicial, em uma peça de um equipamento possibilita
que esta peça seja trocada antes que esse defeito impeça o funcionamento da máquina. Este tipo de
manutenção preditiva é mais vantajoso do que a manutenção preventiva, que troca peças sem que estas
estejam necessariamente defeituosas, e também, mais vantajoso do que a manutenção reativa, que troca as
peças do equipamento apenas quando este não tem mais condições de funcionar.
O uso de técnicas de reconhecimento de padrões é muito utilizado no diagnóstico automático de defeitos
em máquinas rotatórias [Wandekokem, E. et al., 2011, Xia, Z. et al., 2012, Liu, J., 2012, Wu, S. D. et al.,
2013]. As técnicas de reconhecimento de padrões, do paradigma de aprendizado supervisionado, necessitam
de uma base de dados com padrões rotulados para treinar um classificador. Este, depois de treinado, deve ser
capaz de identificar os rótulos dos exemplos utilizados no treinamento, assim como, novos exemplos que
sejam apresentados a este classificador [Duda, R. O. et al., 2001]. A base de dados que treina o classificador é
extraída a partir de dados coletados no domínio do problema abordado.
Nos experimentos apresentados neste trabalho, as bases de dados foram extraídas a partir de dados
vibratórios, coletados através de acelerômetros conectados a máquinas rotatórias. Utilizamos três modelos de
extração de características, fizemos testes de desempenho com cada modelo separadamente e com os três
modelos conjuntamente para gerar uma base de dados com um número considerável de características. Os
nossos experimentos mostraram que a junção de vários modelos de extração de características pode melhorar
o desempenho de classificação, dependendo do classificador utilizado.
Também aplicamos técnicas de seleção de características e notamos que estas sempre melhoraram o
desempenho dos classificadores, além de reduzir o custo computacional. Utilizamos uma técnica gulosa
conhecida como pesquisa sequencial para frente com dois critérios de seleção diferentes, a probabilidade de
erro médio estimado e a distância interclasse. Os dois critérios de seleção conseguiram resultados melhores
do que o uso da base de dados com todos os tipos de características extraídas. Os critérios diferenciaram-se
quanto à preferência de modelo de característica a ser selecionado.
Na seção 2 apresentamos os modelos de classificador usados nestes trabalhos, na seção 3 os modelos de
extração de características. Na seção 4 mostramos os experimentos feitos e os resultados obtidos e na seção 5
as conclusões e considerações finais, assim como trabalhos futuros.

95
ISBN: 978-972-8939-96-0 © 2013 IADIS

2. DIAGNÓSTICO AUTOMÁTICO DE FALHAS

Neste trabalho utilizamos o paradigma de aprendizado de máquina supervisionado [Duda, R. O. et al., 2001]
para diagnosticar falhas automaticamente. Quando este paradigma é utilizado no contexto de classificação,
um algoritmo de aprendizado usa padrões rotulados para treinar um modelo de classificador. Um
classificador treinado deve ser capaz de identificar os padrões utilizados no treino e novos padrões sem
rótulo. A estimativa de desempenho de um classificador pode ser calculada utilizando dados rotulados que
não foram apresentados no treino do classificador.
Este trabalho apresenta experimentos que utilizaram o algoritmo do vizinho mais próximo e a máquina de
vetor de suporte como classificadores. Utilizamos as estimativas de desempenho conhecidas como leave-one-
out e validação cruzada de 10 folds.
O algoritmo do vizinho mais próximo (K-Nearest Neighbor – KNN) [Cover, T., & Hart, P., 1967] é um
método que classifica um padrão não rotulado de acordo com a sua proximidade com padrões rotulados,
fornecidos durante a fase de treinamento. O treinamento do KNN se resume a armazenar os padrões
fornecidos. Várias métricas podem ser usadas para medir a distância entre os padrões. Neste trabalho
utilizamos a distância euclidiana no espaço de características. O parâmetro K indica a quantidade de vizinhos
que serão verificados para classificar um padrão novo. Por exemplo, o classificador 1-NN rotulará um padrão
novo com o mesmo rótulo do exemplo mais próximo. O KNN rotula os novos exemplos de acordo com a
maioria dos K vizinhos mais próximos. Empates são resolvidos arbitrariamente.
A máquina de vetor de suporte (Support Vector Machine – SVM) [Burges, C. J., 1998] possui um
algoritmo de treinamento que encontra um hiperplano que maximiza a separação entre duas classes no espaço
de características. A SVM pode extrapolar a separação linear entre as classes utilizando uma função de
kernel.
A validação cruzada é uma técnica que divide os dados, alternando as partes entre treino e teste
[Bouckaert, R. R., 2004]. Para estimar o desempenho de um algoritmo de classificação utilizando a validação
cruzada de 10 folds, a base de dados deve ser dividida aleatoriamente em dez partes. Devem ser feitas dez
rodadas. Cada rodada é treinada com nove partes e testada com aquela não utilizada no treinamento. Ao final,
todas as partes da base de dados devem ter sido usadas como teste. Um caso especial de validação cruzada é
o leave-one-out, que possui a quantidade de folds igual à quantidade de exemplos da base dados.
Várias métricas podem ser usadas para calcular o desempenho. A métrica mais utilizada é a acurácia, que
é a porcentagem de padrões da base de testes que foram corretamente rotulados. Esta é a métrica que
utilizamos neste trabalho.

3. EXTRAÇÃO DE CARACTERÍSTICAS
É muito comum a extração de características para diagnóstico de falhas em máquinas rotatórias a partir da
leitura de dados vibratórios, obtidos por meio de acelerômetros [Wandekokem, E. et al., 2011, Xia, Z. et al.,
2012, Liu, J., 2012, Wu, S. D. et al., 2013]. Os sinais coletados da máquina são convertidos em dados
discretos. Os dados vibratórios puros trazem informações em geral não diretamente aplicáveis a classificação
dos estados da máquina, portanto, é necessário utilizar alguma técnica de extração de características para
transformar os dados adquiridos em informações úteis para o diagnóstico.
Neste trabalho, utilizamos várias técnicas de extração divididas em três modelos básicos de extração de
características: características estatísticas no domínio do tempo e no domínio da frequência, características no
domínio tempo-frequência utilizando transformada wavelet packet [Xia, Z. et al., 2012] e características
extraídas do espectro de envelope complexo.

3.1 Modelo Estatístico

O modelo estatístico de extração de características utiliza medidas estatísticas do sinal discreto para extrair o
valor de uma característica. Este sinal discreto pode estar no domínio do tempo ou no domínio da frequência.
Utilizamos aqui dez parâmetros estatísticos no domínio do tempo e três no domínio da frequência. A
Tabela 1 mostra a definição das características estatísticas do domínio do tempo utilizadas neste trabalho,
onde x representa um vetor de sinais discretos no domínio do tempo e N o tamanho deste vetor.

96
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Tabela 1. Definição de características estatísticas no domínio do tempo

Valor Eficaz N 1 /2 Valor Eficaz da N 2

(Root Mean Square
- RMS)
Xrms = ( 1
∑ x2
N i= 1 i ) Amplitude
(Square Root of the
Xsra= (1
∑ ∣x ∣
N i= 1 √ i )
Amplitude - SRA)
Valor de Curtose N
x− x 4 Valor de Obliquidade N
x− x 3
(Kurtosis Value - Xkv = ∑ iσ
1
N i= 1
( ) (Skewness Value - SV) Xsv= ∑ iσ
1
N i= 1
( )
KV)
Valor pico a pico Fator de Crista
(Peak-peak Value - (Crest Factor - CF)
PPV)

Fator de Impulso Fator de Margem

(Impulse Factor - (Margin Factor - MF)
IF)

Fator de Forma N 1 /2 Fator de Curtose N

xi − x 4
(Shape Factor -
( 1
∑ x2
N i= 1 i ) (Kurtosis Factor - KF)
1
∑
N i= 1 σ
( )
SF) Xkf =
X sf = N 2

( )
N
1
∑ ∣x ∣
N i= 1 i
1
∑ x2
N i= 1 i

A Tabela 2 apresenta a definição das características estatísticas do domínio da frequência utilizadas neste
trabalho, onde f é um vetor com os valores absolutos dos sinais discretos após passarem pela Transformada
de Fourier.
Tabela 2. Definição de características estatísticas no domínio da frequência
Frequência central N
(Frequency Center - FC) Xfc=
1
∑f
N i= 1 i
Valor Eficaz da Frequência N 1 /2
(RMS Frequency - RMSF) Xrmsf =( )1
∑ f2
N i= 1 i
Desvio Padrão da Frequência N 1 /2
(Root Variance Frequency - RVF) Xrvf =( ∑ ( ))
1
N i= 1
f i − Xfc 2

3.2 Modelo de Análise de Transformada Wavelet Packet

A análise de transformada wavelet packet se enquadra nos métodos de tempo-frequência [Xia, Z. et al., 2012]
e permite uma decomposição nível a nível, utilizando uma função wavelet. A decomposição de nível um
resulta em dois sinais complementares. Cada sinal resultante pode ser novamente decomposto para gerar os
sinais do próximo nível. Desta forma, a quantidade de sinais gerados é igual a 2n, onde n é o nível desejado.
A Figura 1 apresenta um esquema de transformada wavelet packet de três níveis.

97
ISBN: 978-972-8939-96-0 © 2013 IADIS

Figura 1. Transformada wavelet packet de três níveis

A técnica de extração baseada neste modelo apresentada aqui utiliza como função a Daubechies Wavelets
de ordem 4, com quatro níveis de decomposição. A energia calculada em cada sinal decomposto é utilizada
como característica.

3.3 Modelo de Espectro do Envelope Complexo

O modelo de envelope complexo [McInerny, S.A., Dai, Y., 2003] permite calcular o valor da amplitude de
um sinal na frequência em que os defeitos se manifestam. Para utilizar técnicas desse modelo de extração é
necessário conhecer a frequência em que os defeitos devem se manifestar. No caso de diagnóstico de defeitos
em rolamentos, é possível se calcular esta frequência quando as dimensões do rolamento são conhecidas.
A técnica de extração de características do espectro de envelope complexo apresentada neste trabalho
utiliza um filtro passa alta para filtrar as baixas frequências, pois as frequências esperadas dos defeitos foram
moduladas sobre a frequência natural do rolamento. O sinal filtrado passa pela transformada de Hilbert para
gerar o sinal analítico e posteriormente gerar o espectro de envelope pela transformada de Fourier.
Finalmente, calcula-se o valor eficaz de uma janela definida em torno da frequência de manifestação do
defeito a ser identificado.

4. EXPERIMENTOS E RESULTADOS
Para nossos experimentos, utilizamos os dados disponíveis no Bearing Data Center da Case Western Reserve
University [CWRU, 2013]. Estes dados disponibilizam dados de testes de rolamentos normais e defeituosos
em um motor elétrico de dois cavalos de potência.
Os defeitos dos rolamentos foram induzidos com falhas de 0,007 até 0,028 polegada de diâmetro. Foram
induzidos separadamente defeitos na pista interna, pista externa e no elemento rotatório. Os dados vibratórios
foram coletados do equipamento com cargas de zero a três cavalos de potência, induzidas por um
dinamômetro. Desta forma, a velocidade de rotação do motor variou de 1797 a 1720 rotações por minuto
(RPM). Dois modelos de rolamentos foram testados. Um modelo no eixo e outro no ventilador.
As leituras dos dados vibratórios foram feitas por até três acelerômetros, localizados na base do motor,
próximo ao rolamento do ventilador e próximo ao rolamento do eixo. Nem todas as leituras possuíam os
dados do sensor da base do motor, por isso, não utilizamos os sinais deste sensor. Assim como feito em
outros trabalhos [Xia, Z. et al., 2012, Liu, J., 2012, Wu, S. D. et al., 2013], dividimos os sinais em várias
partes antes de extrair as características desejadas, para termos mais exemplos, permitindo verificar o
desempenho dos algoritmos de classificação. Para extrair as características usadas nos experimentos
apresentados aqui dividimos cada sinal em 15 partes, totalizando 2415 exemplos. Esta foi a maior divisão
sem perda de acurácia nos experimentos preliminares.

4.1 Classes Identificadas

As classes a serem identificadas podem ser rotuladas de acordo com quantidade de rolamentos, de estados de
cada rolamento, de gravidades de defeito induzido e de cargas induzidas no motor. Os trabalhos que
utilizaram a base de dados vibratórios da CWRU vistos até o momento [Xia, Z. et al., 2012, Liu, J., 2012,
Wu, S. D. et al., 2013] utilizaram poucas classes em seus experimentos e avaliaram apenas um tipo de

98
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

rolamento, normalmente o do eixo. Um tipo de experimento visto utiliza quatro classes, sendo elas, normal,
defeito na pista interna, na pista externa e no elemento rotatório. Outro tipo de experimento, que também
utiliza quatro classes, fixa um dos três tipos de defeitos apresentados e avalia a gravidade do defeito (0,007,
0,014, 0,021 ou 0,028 polegada).
Nossos experimentos foram feitos com uma classe normal, três defeitos (pista interna, pista externa e
bola), dois tipos de rolamentos, três intensidades de gravidade (0,007, 0,014, 0,021 polegada) para cada tipo
de defeito nos dois tipos de rolamentos e uma intensidade de gravidade (0,028 polegada) para o rolamento do
eixo com os defeitos no elemento rotatório e na pista interna, totalizando 1+2*3*3+1*1*2 = 21 classes. A
Tabela 3 mostra as classes utilizadas nos experimentos com suas respectivas descrições e distribuições a
priori.
Tabela 3. Classes utilizadas nos experimentos com suas respectivas descrições e distribuições
Classe Nome Nº de Distri- Descrição
Exem- buição
plos
1 Ball_DE_007 120 4,97 % Defeito de 0,007 polegada na bola do rolamento do eixo.
2 Ball_FE_007 60 2,48 % Defeito de 0,007 polegada na bola do rolamento do ventilador.
3 Ball_DE_014 120 4,97 % Defeito de 0,014 polegada na bola do rolamento do eixo.
4 Ball_FE_014 60 2,48 % Defeito de 0,014 polegada na bola do rolamento do ventilador.
5 Ball_DE_021 120 4,97 % Defeito de 0,021 polegada na bola do rolamento do eixo.
6 Ball_FE_021 60 2,48 % Defeito de 0,021 polegada na bola do rolamento do ventilador.
7 Ball_DE_028 60 2,48 % Defeito de 0,028 polegada na bola do rolamento do eixo.
8 InnerRing_DE_007 120 4,97 % Defeito de 0,007 polegada na pista interna do rolamento do eixo.
9 InnerRing_FE_007 60 2,48 % Defeito de 0,007 polegada na pista interna do rolamento do ventilador.
10 InnerRing_DE_014 120 4,97 % Defeito de 0,014 polegada na pista interna do rolamento do eixo.
11 InnerRing_FE_014 60 2,48 % Defeito de 0,014 polegada na pista interna do rolamento do ventilador.
12 InnerRing_DE_021 120 4,97 % Defeito de 0,021 polegada na pista interna do rolamento do eixo.
13 InnerRing_DE_021 60 2,48 % Defeito de 0,021 polegada na pista interna do rolamento do ventilador.
14 InnerRing_DE_028 60 2,48 % Defeito de 0,028 polegada na pista interna do rolamento do eixo.
15 Normal 60 2,48 % Rolamento normal (sem defeito).
16 OuterRing_DE_007 360 14,91 % Defeito de 0,007 polegada na pista externa do rolamento do eixo.
17 OuterRing_FE_007 180 7,45 % Defeito de 0,007 polegada na pista externa do rolamento do ventilador.
18 OuterRing_FE_014 75 3,11 % Defeito de 0,014 polegada na pista externa do rolamento do eixo.
19 OuterRing_DE_014 120 4,97 % Defeito de 0,014 polegada na pista externa do rolamento do ventilador.
20 OuterRing_DE_021 360 14,91 % Defeito de 0,021 polegada na pista externa do rolamento do eixo.
21 OuterRing_FE_021 60 2,48 % Defeito de 0,021 polegada na pista externa do rolamento do ventilador.

4.2 Modelos de Extração de Características

Utilizamos três modelos básicos de extração de características: espectro de envelope complexo,
características estatísticas no domínio do tempo e da frequência e transformada wavelet packet. Criamos uma
base de dados utilizando cada modelo e mais uma utilizando os três modelos conjuntamente. A Tabela 4
mostra a quantidade de características extraídas pelos modelos nos experimentos.
Tabela 4. Quantidade de características extraídas em cada modelo
Modelo de extração de características Quantidade de características
Espectro de envelope complexo 72
Estatísticas (tempo + frequência) 26
Transformada wavelet packet 32
Todos anteriores conjuntamente 130
Para avaliar comparativamente cada modelo, utilizamos o classificador KNN, atribuindo os valores 1, 3, 5
e 7 para o parâmetro k. Este classificador foi escolhido por ser muito rápido para essas bases de dados e por
apresentar boa acurácia nas quatro bases de dados extraídas. O método de estimativa de desempenho foi o
leave-one-out e a métrica foi a acurácia. Podemos ver na Figura 2 que a base de dados que utiliza todas as
características conjuntamente sempre obteve acurácia maior do que as demais para todos os valores de K
utilizados nestes experimentos.

99
ISBN: 978-972-8939-96-0 © 2013 IADIS

100.00%
98.00% Envelope
96.00% Estatística
Wavelet
94.00% Todas
92.00%
1NN 3NN 5NN 7NN
Figura 2. Acurácia do classificador KNN para bases de dados extraídas por diferentes modelos de extração de
características

4.3 Seleção de Características

Para seleção de características utilizamos a busca sequencial para frente (BSF), utilizando dois critérios de
seleção: a probabilidade de erro médio estimado (PEME) e a distância interclasse (DIC). O classificador
utilizado foi o KNN com o parâmetro K igual a 1, por este ter obtido maior acurácia na maioria dos casos dos
testes preliminares. Fizemos experimentos que iniciaram com a seleção de três características e aumentamos
a quantidade de características de três em três, até que noventa características fossem selecionadas. A Figura
3 mostra a relação entre acurácia e a quantidade de características, para até trinta características.

Figura 3. Acurácia obtida em bases de dados com características selecionadas pela heurística gulosa BSF com dois
critérios de seleção
Podemos ver na Figura 3 que, para selecionar nove características ou menos, o uso da PEME como
critério de seleção foi melhor do que a DIC, mas a partir de vinte e sete características, os dois critérios
tiveram desempenho igual.

Figura 4. Tipos de características selecionadas

A principal diferença entre os critérios de seleção foi o tipo de característica selecionada. A Figura 4
mostra que enquanto o critério PEME tende a selecionar os tipos de características mais equitativamente, o
critério DIC seleciona preferencialmente as características de envelope.

100
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

4.4 Experimentos com Máquina de Vetor de Suporte

Devido ao custo computacional de treinamento de uma máquina de vetor de suporte (SVM – Support Vector
Machine), utilizamos como estimativa de desempenho a validação cruzada de 10 folds. O tipo de SVM
utilizada foi o C-SVC, com a função de base radial como função de kernel, com o parâmetro γ (gamma) igual
a 0.007692, custo C igual a 1. Estes valores foram selecionados através de experimentos preliminares.
Os experimentos com a SVM iniciaram com a seleção de três características, que foram aumentando de
três em três, até que sessenta características fossem selecionadas. Para SVMs utilizamos apenas a PEME
como critério de seleção.
As SVMs que utilizaram a base de dados extraída pelo método de transformada wavelet packet tiveram
acurácia muito maior do que aquelas que utilizaram os métodos de espectro de envelope complexo,
estatísticos e os três métodos conjuntamente. Entretanto, utilizando técnicas de seleção de características para
selecionar entre 12 e 60 características, as SVMs apresentaram acurácias maiores do que utilizando a base de
dados wavelet unicamente. Isso é mostrado na Figura 5, comparando a acurácia das SVMs que utilizam bases
de dados extraídas por métodos de envelope, estatísticos, wavelet, com os três métodos conjuntos e com 15
características selecionadas a partir da base de dados com os três métodos conjuntos.
100.00%

95.00%
Envelope
90.00% Estatística
Wavelet
85.00%
Todas
80.00% 15 Características

75.00%
SVM
Figura 5. Comparação de SVMs em diferentes bases de dados

5. CONCLUSÕES E TRABALHOS FUTUROS

Nos experimentos executados notamos que os três modelos de extração de características usados
conjuntamente obtiveram acurácia de classificação maior do que o uso de cada modelo de extração
individualmente quando utilizado o classificador KNN, mas o mesmo comportamento não foi observado
quando foi utilizada a SVM como classificador. Também vimos que a redução da quantidade de
características através do método SFS aumentou a acurácia de classificação para o classificador KNN, com K
igual a um, e também para os experimentos que utilizaram a SVM como classificador. Para seleção de menos
de 21 características, as bases de dados que foram extraídas utilizando a probabilidade de erro médio
estimado como critério de seleção de características, tiveram maiores acurácias do que as que utilizaram a
distância interclasse. Entretanto, quando selecionadas mais de vinte e uma características, os dois critérios de
seleção tiveram desempenhos compatíveis. O uso da probabilidade de erro médio estimado como critério
selecionou as características dos três modelos de extração mais equitativamente, enquanto o uso da distância
interclasse selecionou mais características de espectro de envelope complexo. Para nove características
selecionadas, ou mais, a SVM apresentou acurácias maiores do que o uso de um modelo de extração de
características específico ou todos os modelos juntos.
Para a continuação deste trabalho, pretendemos fazer testes com Redes Neurais Artificiais, mais técnicas
de seleção de características, técnicas de combinação de classificadores (Classifier Emsembles), mais bases
de dados e outras métricas para estimar o desempenho dos classificadores.

101
ISBN: 978-972-8939-96-0 © 2013 IADIS

REFERÊNCIAS BIBLIOGRÁFICAS
Bouckaert, R. R., 2004. Estimating replicability of classifier learning experiments. In Proceedings of the twenty-first
international conference on Machine learning – ACM, pp 15.
Burges, C. J., 1998. A tutorial on support vector machines for pattern recognition. Data mining and knowledge discovery,
2(2), 121-167.
Cover, T., & Hart, P., 1967. Nearest neighbor pattern classification. Information Theory, IEEE Transactions on, 13(1), 21-
27.
CWRU, 2013. Bearing Data Center. [ONLINE] Available at: http://csegroups.case.edu/bearingdatacenter. [Acessado em
30 de Maio de 2013].
Duda, R. O. et al. 2001. Pattern classification. Wiley-interscience. New York, USA.
Liu, J., 2012. Shannon wavelet spectrum analysis on truncated vibration signals for machine incipient fault detection.
Measurement Science and Technology, 23(5).
McInerny, S.A., Dai, Y., 2003. Basic vibration signal processing for bearing fault detection. IEEE Transactions on
Education 46, 149-156.
Wandekokem, E. et al., 2011. Diagnosing multiple faults in oil rig motor pumps using support vector machine classifier
ensemble. Em Integrated Computer-Aided Engineering, Vol. 18, No. 1, pp 61-74.
Wu, S. D. et al., 2013. Multi-Scale Analysis Based Ball Bearing Defect Diagnostics Using Mahalanobis Distance and
Support Vector Machine. Entropy, 15(2), 416-433.
Xia, Z. et al., 2012. Spectral Regression Based Fault Feature Extraction for Bearing Accelerometer Sensor Signals.
Sensors, 12(10).

102
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

AGRUPAMENTO FUZZY E REGRESSÃO LOGÍSTICA

APLICADOS NA ANÁLISE DE TRAUMATISMO
CRANIOENCEFÁLICO GRAVE

Merisandra Côrtes de Mattos Garcia1, Evandro Tostes Martins2 e Fernando Mendes de Azevedo3
1
Instituto de Engenharia Biomédica, Departamento de Engenharia Elétrica, Universidade Federal de Santa Catarina -
Florianópolis-SC- Brasil - Curso de Ciência da Computação, Universidade do Extremo Sul Catarinense
Criciúma –SC- Brasil
2
Unidade de Terapia Intensiva do Hospital Universitário, Universidade Federal de Santa Catarina - Unidade de Terapia
Intensiva do Hospital Governador Celso Ramos - Florianópolis –SC- Brasil
3
Instituto de Engenharia Biomédica, Departamento de Engenharia Elétrica, Universidade Federal de Santa Catarina -
Florianópolis-SC- Brasil

RESUMO
A mineração de dados, parte constituinte da descoberta de conhecimento em bases de dados, refere-se a integração de
métodos tradicionais de análise de dados com algoritmos sofisticados de aprendizado de máquina, com o intuito de
identificar padrões entre os dados. Dentre as tarefas de mineração de dados tem-se o agrupamento que separa um
conjunto de dados em grupos de acordo com as suas semelhanças, sendo que uma das formas de sua realização é por
meio do método de lógica fuzzy. Dentre as áreas de aplicação da mineração de dados tem-se a biomédica, cujo
crescimento das pesquisas tem ocasionado um aumento no número de conjuntos de dados oriundos dos mais diversos
estudos, como por exemplo, de traumatismo cranioencefálico. O traumatismo cranioencefálico é um problema de saúde
pública que se constitui em uma das principais causas de morbidade e mortalidade no Brasil e no mundo. A análise
apresentada neste artigo consiste na aplicação da mineração de dados por meio da tarefa de agrupamento fuzzy pelo
algoritmo Gustafson-Kessel em dados de traumatismo cranioencefálico da tipologia grave, os quais em pesquisa prévia
foram submetidos a regressão logística, que é uma das formas mais empregadas na análise tradicional de dados em saúde,
sendo que o modelo de regressão logística obteve acurácia em torno de 55% para previsão do óbito. No desenvolvimento
do agrupamento fuzzy, executaram-se as etapas de pré-processamento dos dados, aplicação do algoritmo Gustafson-
Kessel e avaliação dos grupos formados.

PALAVRAS-CHAVE
Mineração de Dados, Agrupamento Fuzzy, Algoritmo Gustafson-Kessel, Regressão Logística, Traumatismo
Cranioencefálico Grave.

1. INTRODUÇÃO
Ferramentas estatísticas, modelos matemáticos, consultas estruturadas são comumente utilizadas para auxiliar
na obtenção de informações a partir das bases de dados. Porém, estas ferramentas possuem limitações que
podem comprometer a precisão da informação gerada. Neste contexto surge a mineração de dados que reúne
técnicas de diferentes áreas como inteligência computacional, reconhecimento de padrões, aprendizado de
máquina, métodos estatísticos e banco de dados a fim de realizar a descoberta de conhecimento em bases de
dados.
A mineração de dados é uma ferramenta de análise de dados que tem sido usada para explorar a
informação em busca de conhecimento nas mais diferentes áreas, como por exemplo, na biomédica a fim de
prever a taxa de sobrevivência em pacientes com câncer de mama, identificar os preditores das infecções do
trato urinário, resultados de traumatismo cranioencefálico, entre outros (LEE et al, 2011).
O Traumatismo Cranioencefálico (TCE) é um problema de saúde pública que é uma das principais causas
de morbidade e mortalidade no mundo, acometendo a maioria das vítimas em idade produtiva (GHAJAR,
2000; SAATMAN et al, 2008), o que também se observa no Brasil (ANDRADE et al, 2009).

103
ISBN: 978-972-8939-96-0 © 2013 IADIS

Ao sofrerem este tipo de lesão os pacientes e familiares preocupam-se com o prognóstico, porém os
métodos atuais para a determinação deste prognóstico são imperfeitos e apresentam para os médicos questões
importantes referentes a heterogeneidade dos dados dos pacientes, variedade das causas dos traumas e outros
fatores como idade e prevalência de doenças sistêmicas. Portanto, predizer o desfecho de um TCE é um
processo complexo e cognitivo (SUT; SIMSEK, 2011).
Tradicionalmente, empregam-se técnicas que não são ideais para trabalhar com dados biológicos
complexos, por vezes multidimensionais e armazenados em grandes repositórios de dados, tornando-se
demorado o processo de análise. Assim, devido ao fato de que não há consenso quanto a um método ideal, é
interessante explorar diferentes métodos (THEODORAKI et al, 2010).
Nesta pesquisa realizou-se a aplicação da tarefa de agrupamento pelo método de lógica fuzzy pelo
algoritmo Gustafson-Kessel na análise do TCE grave, a fim de se separar o conjunto de dados conforme o
desfecho em dois grupos de pacientes, os que vão a óbito e aqueles que sobrevivem.
O agrupamento pode ser entendido como uma tarefa básica no processo de mineração de dados, que
auxilia na estruturação e compreensão do conjunto de dados original identificando os grupos existentes em
um conjunto de objetos. A partir do agrupamento, outras tarefas de mineração de dados, tais como a
classificação e sumarização, podem realizar o seu trabalho nos grupos encontrados (BERRY; LINOFF, 2004;
HAN; KAMBER; PEI, 2011).
A tarefa de agrupamento é explorada com o objetivo de facilitar a identificação de padrões complexos,
por meio de diferentes técnicas que auxiliem o reconhecimento de características ocultas dentro das bases de
dados, considerando suas diversas áreas de aplicação (BEZDEK et al, 2005). A fim de atingir este objetivo,
analisa-se cada dado da base por meio de critérios de similaridade ou dissimilaridade, devendo a divisão
seguir as propriedades de homogeneidade nos grupos e de heterogeneidade entre os grupos (TAN;
STEINBACH; KUMAR, 2009).
Dentre os métodos utilizados para agrupamento de dados, nesta pesquisa aplicou-se a lógica fuzzy, pois é
capaz de identificar com maior precisão registros que se encontram entre dois grupos, ou seja, dados com
características semelhantes a estes grupos. O método efetua cálculos de pertinência nestas informações e
dependendo das operações matemáticas, estes registros podem pertencer a vários grupos simultaneamente,
permitindo que os elementos distintos de um grupo ou dados que estão entre grupos sejam classificados com
menor taxa de erro, melhorando a abstração do conhecimento gerado (BEZDEK et al, 2005).
O algoritmo de agrupamento fuzzy empregado foi o proposto por Gustafson e Kessel e tem como objetivo
produzir grupos de tamanhos e formas variados, aumentando sua flexibilidade na divisão dos grupos. No
entanto, este algoritmo exige maior capacidade de processamento, o que não inviabiliza a sua aplicação, visto
que possui a característica de cada grupo mudar de forma ou tamanho, a fim de se adaptar as diferentes
informações existentes na base de dados (BEZDEK et al, 2005; HÖPPNER et al, 1999).
O estudo apresentado dá continuidade ao trabalho desenvolvido por Martins et al (2009), utilizando-se o
mesmo conjunto de dados. Martins et al (2009) analisou a mortalidade em TCE grave na cidade de
Florianópolis no período de 1994 a 2003, empregando métodos estatísticos tradicionais por meio das análises
univariada (teste t) e multivariada (regressão logística). O modelo final por meio da regressão logística
obteve acurácia em torno de 55% para a predição do óbito.

2. ALGORITMO GUSTAFSON-KESSEL
Desenvolvido em 1979 por Donald E. Gustafson e William C. Kessel, o algoritmo Gustafson-Kessel (GK) é
uma extensão do algoritmo Fuzzy C-Means (FCM). No entanto, o GK utiliza uma matriz de covariância
fuzzy, matriz que contém as medidas de distância entre um grupo de elementos, para calcular as relações
entre os atributos da base de dados e utilizá-la na atualização da distância (GUSTAFSON; KESSEL, 1979).
O diferencial do GK em relação ao FCM é que esta matriz permite ao algoritmo adaptar-se a diferentes
formas de grupos, contrariando os círculos criados pelo FCM. Os grupos possuem suas próprias matrizes de
covariância fuzzy, permitindo a formação de protótipos (prototypes) de formas e tamanhos variados
(BEZDEK et al, 2005).
A principal alteração em relação ao FCM foi a troca da distância euclidiana por outra que encontra com
maior precisão os grupos existentes. Considerando isto, os autores adotaram a distância de Mahalanobis, a
qual implementa uma matriz de covariância entre os atributos disponíveis na base de dados. Esta matriz

104
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

possui a função de calcular a relação entre as diferentes propriedades, a fim de possibilitar maior
flexibilidade ao determinar os grupos encontrados (BEZDEK et al, 2005).
A matriz de covariância permite ao algoritmo Gustafson-Kessel encontrar grupos de formas geométricas
independentes, ou seja, cada grupo possui suas próprias características de dimensões. Por isso, os resultados
gerados pelo GK são, em geral, superiores em relação aos algoritmos tradicionais e ao FCM (GUSTAFSON;
KESSEL, 1979).
Este algoritmo implementa o parâmetro fuzzyficador (m), o qual determina a fuzzyficação entre os
elementos e seus protótipos. Se o valor de m for 1, não existirá esta relação de fuzzyficação entre dados e
grupos, o que gera um agrupamento tradicional, onde cada elemento pertence exclusivamente a um grupo. A
medida em que este valor é incrementado, a fuzzyficação entre os protótipos aumenta (COX, 2005).
Normalmente, é utilizado o valor 2 para este parâmetro, pois desenvolve uma fuzzyficação satisfatória
entre elementos e grupos, onde os registros pertencem um pouco a cada grupo. No entanto, as características
específicas de cada dado determinarão a qual grupo este irá pertencer (BEDZEK et al, 2005; HÖPPNER et
al, 1999).
O algoritmo Gustafson-Kessel permite apenas a utilização de valores numéricos, pelo fato de todo o
processo de agrupamento realizar somente operações matemáticas. Se for necessário a utilização de atributos
nominais, estes devem ser convertidos em valores decimais (BEZDEK et al, 2005).
Antes de começar os cálculos, deve-se escolher o número de grupos que se deseja identificar e determinar
o parâmetro de fuzzyficação m. A fim de finalizar a clusterização, deve-se definir o grau de erro (ɛ), que será
comparado com o erro calculado ao final de cada iteração do algoritmo.
O erro calculado pelo algoritmo consiste na variação entre as duas últimas pertinências entre todos os
elementos e grupos. Este valor é comparado com o número definido pelo grau do erro e o algoritmo encerra
sua execução se todas as pertinências forem menor que o valor do grau do erro (GUSTAFSON; KESSEL,
1979).
A matriz de pertinências U, que contém as pertinências dos elementos em relação aos grupos, deve ser
criada antes de se iniciar os cálculos. Como os primeiros valores desta matriz não interferem no resultado
final, os graus iniciais podem ser randômicos, desde que respeitem a propriedade de soma das pertinências


dada por (GUSTAFSON; KESSEL, 1979):

1
c
(1)
i 1
ij

Onde: (a) c: número total de grupos; (b) μij: grau de pertinência entre o i-ésimo grupo e o j-ésimo
elemento.
Esta propriedade (1) determina que a soma dos graus de pertinência de cada elemento j em relação aos c
grupos deve ser igual a 1, sendo adotada sempre que as pertinências forem recalculadas.
Posteriormente, dado um vetor de dados de tamanho p [x1, x2, x3, ..., xp], onde cada elemento possua um

  d x c 
vetor transposto de N dimensões [xp1, xp2, xp3, ..., xpN]T, deve-se minimizar a seguinte função objetivo

E  
(GUSTAFSON; KESSEL, 1979):
c p m
2
(2)
i 1 j 1
ij j i

Onde: (a) E: valor a ser minimizado, o qual determina os centros dos grupos e os graus de pertinências
dos dados; (b) c: número total de grupos; (c) p: número total de elementos; (d) μij: grau de pertinência entre o
i-ésimo grupo e o j-ésimo elemento; (e) m: parâmetro de fuzzyficação; (f) d²: distância entre o j-ésimo
elemento x e o i-ésimo grupo c.
Utilizando-se desta equação (2), é possível executar o agrupamento pelo método de lógica fuzzy, onde
cada algoritmo possui suas próprias funções de distância entre elementos e grupos. No caso do algoritmo
Gustafson-Kessel, cinco fases principais estão envolvidas no processo, as quais devem ser executadas na
seguinte ordem (GUSTAFSON; KESSEL, 1979): calcular o centro dos grupos; computar as matrizes de
covariância fuzzy; atualizar as distâncias entre os elementos e os seus grupos; determinar os novos graus de
pertinência e definir a condição de parada do algoritmo.
O cálculo dos centros dos grupos objetiva encontrar um ponto que determinará o centro de cada grupo.
Este valor não é um dado existente na base de dados, e sim, um número fictício calculado pelo algoritmo a
fim de representar o centro. A equação (3) é utilizada a fim de calcular o centro de cada grupo existente no
agrupamento (GUSTAFSON; KESSEL, 1979):

105
ISBN: 978-972-8939-96-0 © 2013 IADIS

   x
  
p
m

Ci 
j 1
ij j
(3)
p
m

j 1
ij

Onde: (a) ci: centro do i-ésimo grupo; (b) p: número total de elementos; (c) uij: grau de pertinência entre o
i-ésimo grupo e o j-ésimo elemento; (d) m: parâmetro de fuzzyficação; (e) xj: j-ésimo elemento.
Cada centro encontrado possuirá o mesmo número de dimensões dos elementos, ou seja, se a base de
dados possuir N dimensões, o resultado de cada centro calculado será um vetor transposto de N dimensões
[ci1, ci2, ci3, ..., ciN]T. Finalizado o processo de atualização de todos os centros, deve-se encontrar as matrizes
de covariância fuzzy de cada grupo.

   
As matrizes de covariância fuzzy podem ser calculadas de acordo com a equação (4) (GUSTAFSON;

   
KESSEL, 1979):

  
p
m T

Fi
j 1
ij x j ci x j ci
(4)
p
m

j 1
ij

Onde: (a) Fi: matriz de covariância fuzzy do i-ésimo grupo; (b) p: número total de elementos; (c) μij: grau
de pertinência entre o i-ésimo grupo e o j-ésimo elemento; (d) m: parâmetro de fuzzyficação; (e) xj: j-ésimo
elemento; (f) ci: centro do i-ésimo grupo.
Ao atualizar todas as matrizes, pode-se computar as novas distâncias de cada elemento da base de dados
em relação aos centros dos grupos encontrados. O cálculo da distância define uma medida entre cada ponto e
os grupos encontrados. Este valor é de fundamental importância para o algoritmo, pois os números
computados serão utilizados a fim de atualizar as pertinências dos elementos disponíveis na base de dados
(BEZDEK et al, 2005).
A distância utilizada pelo algoritmo Gustafson-Kessel é a de Mahalanobis, a qual executa seus cálculos

d x , c   x j ci  M x  c 
por meio de matrizes de covariância. A equação (5) define a atualização das distâncias (GUSTAFSON;
KESSEL, 1979):
2 T

j i i j i
(5)
Onde: (a) d²: distância entre o j-ésimo elemento x e o i-ésimo grupo c; (b) xj: j-ésimo elemento; (c) ci:
centro do i-ésimo grupo; (d) Mi: matriz de covariância modificada do i-ésimo grupo.

 N det F i  F i
A matriz de covariância Mi deve ser ajustada a dimensão e a forma do grupo, definida pela equação (6)
(GUSTAFSON; KESSEL, 1979):
1
M i
(6)
Onde: (a) N: número de dimensões da base de dados; (b) Fi: matriz de covariância fuzzy do i-ésimo
grupo.
Finalizando-se os cálculos, pode ocorrer de alguma distância entre um dado e um grupo ser zero. Neste
caso, a pertinência deste elemento em relação a este grupo deve ser igual a 1 e todos os outros graus de
pertinência devem ser igual a zero (HÖPPNER et al, 1999).
Os valores obtidos definirão uma distância em relação a todos os grupos existentes para cada elemento.
Considerando estes valores, pode-se atualizar a matriz de pertinência U, a qual definirá o quanto um
elemento pertence a cada grupo. A atualização das pertinências é dada por (GUSTAFSON; KESSEL, 1979):

1
U
 2  m1
(7)


1

 d ij 
ij

 2 
c

k 1 
 d kj 

Onde: (a) uij: grau de pertinência entre o i-ésimo grupo e o j-ésimo elemento; (b) c: número total de
grupos; (c) d²ij: distância entre o j-ésimo elemento e o i-ésimo grupo; (d) d²kj: distância entre o j-ésimo
elemento e o k-ésimo grupo; (e) m: parâmetro de fuzzyficação.

106
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Ao final da atualização de todas as pertinências dos elementos, deve-se calcular uma condição de parada,
a fim de terminar a execução do algoritmo. A condição de parada deve finalizar o processamento do
algoritmo. O método padrão adotado por Gustafson-Kessel é o cálculo do erro entre pertinências. No entanto,
outro método pode ser adotado, o do número de iterações, o qual o usuário determina a quantidade de
iterações do algoritmo (BEZDEK et al, 2005).
Porém, o cálculo de erro entre os graus de pertinência é satisfatório, visto que o algoritmo após várias
iterações apresenta pouca modificação dos valores de pertinência, o qual registra o fim dos cálculos de
agrupamento. A utilização deste cálculo é recomendado, pois na maioria dos casos reduz a quantidade de
ciclos que o algoritmo necessitaria a fim de finalizar o agrupamento. A equação (8) descreve o cálculo do
erro e a condição de parada (GUSTAFSON; KESSEL, 1979):
U U 
l l 1
(8)
Onde: (a) U: matriz de pertinências; (b) l: número de iterações atual; (c) ɛ: valor do erro.

3. METODOLOGIA
O processo de desenvolvimento iniciou-se com a definição do problema em foi aplicada a mineração de
dados, observando-se a base de dados bruta no que se refere a estrutura do conjunto de dados em termos dos
seus atributos e registros. Esta etapa também foi caracterizada pela definição do especialista no domínio de
aplicação que detém o conhecimento sobre o problema, sendo fundamental no processo, pois auxilia na
identificação dos objetivos da mineração de dados e na avaliação dos resultados. Os objetivos da aplicação
também compõem esta fase e consistem nas características esperadas do modelo de conhecimento.
A base de dados utilizada nesta pesquisa é composta por registros de pacientes com Traumatismo
Cranioencefálico (TCE) do tipo grave que foram admitidos na Unidade de Terapia Intensiva do Hospital
Governador Celso Ramos, na cidade de Florianópolis, no período compreendido entre Janeiro de 1994 a
Dezembro de 2003. A base de dados é formada por 748 registros, sendo que cada um possui 18 atributos que
representam as características relacionadas ao TCE (Tabela 1).
Tabela 1. Base de dados de TCE grave
Atributos Valores
Sexo Masculino, feminino
Idade 12 anos
Glicose ≤ 60 até > 300
Ano de atendimento 1994 a 2003
Causa do TBI Acidentes: rodoviário, automóvel, bicicleta; quedas, agressão, outros
Classificação de Marshall Tipo I, II, III e IV
Hemorragia subaracnóide Sim, não
Trauma associado Sim, não
Tipo de trauma associado: Face/Coluna
cervical/Coluna dorso lombar/ Sim, não
Tórax/Abdominal/Membros/Outros
Escala de Coma de Glasgow 3a8
Pupilas Isocóricas, mióticas, anisocóricas, midriáticas
Desfecho Sobrevida, óbito

Conforme Martins et al (2009) este é um hospital público de referência para o TCE atendendo uma
população de aproximadamente um milhão, que compõe a região metropolitana de Florianópolis.
O TCE consiste em uma agressão ao cérebro, ocasionando lesão anatômica ou comprometimento
funcional do crânio, meninges ou encéfalo. Esta agressão é causada por uma força física externa que pode
diminuir ou alterar o estado de consciência e comprometer as capacidades cognitivas ou motoras
(GRAHAM; CARDON, 2008). O TCE ocasiona no sistema nervoso central várias alterações estruturais,
fisiológicas e funcionais. Assim, pode acarretar a morte da vítima de TCE como também comprometer as
suas capacidades cognitivas, físicas e comportamentais (CÉSPEDES et al, 2001; COLANTONIO et al,
2009).

107
ISBN: 978-972-8939-96-0 © 2013 IADIS

Após a definição dos dados realizou-se a etapa de modelagem que compreendeu o pré-processamento dos
dados e a execução da mineração de dados. O pré-processamento consistiu na organização e tratamento dos
dados, preparando-os para serem submetidos ao algoritmo. A mineração de dados refere-se a etapa de
aplicação dos algoritmos a fim de se separar os padrões presentes nestes em grupos, sendo que nesta pesquisa
foi empregada a tarefa de agrupamento pelo método de lógica fuzzy por meio do algoritmo Gustafson-
Kessel.
A avaliação compreendeu a análise dos grupos identificados pelo algoritmo supracitado, empregando-se
medidas de qualidade, que consistem em índices estatísticos, a fim de se avaliar o desempenho e a qualidade
dos grupos gerados.
Inicialmente realizou-se o pré-processamento dos dados a fim de se melhorar a aplicação da mineração de
dados em termos de tempo, custo e qualidade. Nesta etapa executaram-se as funções de seleção dos dados,
agregação, limpeza e transformação de variáveis.
Os dados utilizados nesta pesquisa já se encontravam organizados em uma única tabela, portanto a
seleção dos dados consistiu na escolha dos atributos a serem considerados na mineração de dados. A seleção
por redução de dados vertical foi implementada pela eliminação dos atributos cujo conteúdo não foi
considerado relevante para o problema, como, por exemplo, o código identificador. Além deste, outros
atributos também foram eliminados de algumas análises, conforme orientações do especialista do domínio de
aplicação, como por exemplo: ano de atendimento e tipo de trauma associado. A redução de dados verticais,
segundo Tan, Steinbach e Kumar (2009), pode auxiliar na obtenção de modelos de conhecimento com maior
acurácia e concisão, pois eliminam características irrelevantes e reduzem o ruído.
A agregação também foi empregada para reduzir o número de valores de um determinado atributo, como
por exemplo, em ano de atendimento, glicose e idade, as quais foram categorizadas (discretização), conforme
as orientações do especialista do domínio de aplicação.
A limpeza dos dados compreendeu a eliminação de valores ausentes no conjunto de dados, por meio da
exclusão dos casos que possuíam atributos com valores ausentes.
A transformação das variáveis deve atender as necessidades dos algoritmos de mineração de dados, no
caso desta pesquisa, os atributos nominais foram transformados para numéricos, como por exemplo, sexo,
desfecho, entre outros, pois o algoritmo Gustafson-Kessel trabalha apenas com valores numéricos, estes
dados foram transformados a fim de permitir o seu agrupamento. Nestes dados empregou-se um número
identificador, a fim de possibilitar a execução do algoritmo e sua posterior identificação.
Após o pré-processamento dos dados a base passou a ter 728 registros, os quais foram submetidos ao
agrupamento fuzzy pelo algoritmo Gustafson-Kessel.
A etapa de execução da mineração de dados compreendeu a aplicação do agrupamento fuzzy pelo
algoritmo Gustafson Kessel, para isso empregou-se a Shell Orion Data Mining Engine, que consiste em uma
ferramenta de mineração de dados que implementa em Java diversos algoritmos, desenvolvida em meio
acadêmico e disponibilizada gratuitamente. Todas as análises realizadas tiveram os mesmos parâmetros de
entrada definidos, os quais foram: (a) quantidade de grupos: 2; (b) parâmetro de fuzzyficação: o grau de
fuzzyficação dos elementos em relação aos seus grupos foi definido em 2, conforme indicado pela literatura
da área e explicitado anteriormente neste artigo; (c) quantidade de iterações: foi definido o valor zero, a fim
de que o algoritmo execute um número ilimitado de iterações, sendo sua condição de parada exclusivamente
a taxa de erro; (d) taxa de erro: o erro aceitável dos resultados determinados pelo algoritmo foi estabelecido
em 0.00001; (e) atributos de entrada: foram considerados os campos da base de dados a serem utilizados nos
cálculos de agrupamento pelo algoritmo Gustafson-Kessel.
A definição dos parâmetros de entrada demonstra que por meio de uma base de dados, pode-se obter
diferentes resultados, considerando que os valores podem ser selecionados de acordo com a preferência do
usuário.
Na etapa de avaliação, os resultados gerados foram avaliados aplicando-se algumas das medidas de
qualidade indicadas pela literatura, Bedzek et al (2005) e Guillet e Hamilton (2010), para a avaliação da
qualidade do agrupamento fuzzy em mineração de dados: coeficiente de partição, coeficiente de entropia e
índice Xie-Beni.

108
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

4. RESULTADOS OBTIDOS
Algumas análises realizadas empregaram apenas alguns atributos da base de dados, os quais foram
selecionados conforme orientações do especialista do domínio de aplicação, enquanto em outras, utilizaram-
se todos os atributos da base. Em ambos os casos, constatou-se a dispersão dos dados pelo espaço, o que
demonstra a proximidade dos atributos, independente de fatores como o sexo, classificação de Marshall,
presença de hemorragia subaracnóide, estado das pupilas, desfecho, entre outros.
Considerando-se todos os atributos da base de dados, o algoritmo GK realizou um número pequeno de
iterações (apenas uma), tendo-se como critério de parada a taxa de erro de 0.00001 e os índices de validação,
como o coeficiente de partição de 0.50, o coeficiente de entropia de 0.69 e o índice Xie-Beni 0.34, obteve-se
resultados que demonstraram a similaridade entre os dados disponíveis, não se conseguindo um agrupamento
fuzzy adequado do TCE grave para estes dados (Figura 1(a)). O coeficiente de partição é uma função
maximizadora cujo resultado mais próximo de 1 é o ideal, significando que os grupos estão bem definidos. O
coeficiente de entropia e o índice Xie-Beni são funções minimizadoras. O coeficiente de entropia varia de
zero até o log do número de grupos, sendo que quanto mais alto indica a ausência de grupos definidos. O
índice Xie-Beni não tem um intervalo definido, porém é considerado ideal o quanto menor for, pois indica
que os grupos estão bem definidos.
Em uma análise considerando apenas alguns atributos da base de dados (Idade, Sexo, Glicemia, Causa,
Classificação de Marshall, Hemorragia Subaracnóide e Pupilas), os resultados mostram que o algoritmo GK
encontrou como referência relevante o atributo Sexo, separando-os em dois grupos. Considerando-se o
gráfico (Figura 1(b)) pode-se perceber que os dados estão dispersos pelo espaço disponível, o que demonstra
a proximidade dos atributos, independente do sexo, e a proximidade das centróides.
Essa tendência foi observada em todas as análises realizadas, mesmo no uso de atributos categóricos e
não categóricos, não se conseguindo separar os grupos, tanto em situações em que ocorreram poucas
iterações, quanto naquelas em que se teve um número maior.

(a) (b)
Figura 1. Agrupamento fuzzy dos dados de TCE grave.

5. CONCLUSÃO
O TCE é um dos tipos de trauma que mais acomete a população, ocorrendo lesões graves que levam a
hospitalização. Aplicando-se o agrupamento fuzzy pelo algoritmo Gustafson-Kessel não foi possível separar
os dados em grupos que auxiliassem no entendimento de padrões similares que acarretam o óbito ou a
sobrevida. Isso se deve a similaridade entre os dados nos dois desfechos, comprovadas pelas medidas de
qualidade aplicadas e pela mistura das informações entre os clusters encontrados.
Mediante os resultados do agrupamento fuzzy, pode-se concluir que o modelo de regressão logística
empregado em estudos anteriores, obteve uma acurácia baixa para a previsão do óbito (55%) em função da
similaridade entre os dados nos diferentes desfechos de óbito e sobrevida, não conseguindo identificar um
modelo linear com taxas superiores.

109
ISBN: 978-972-8939-96-0 © 2013 IADIS

AGRADECIMENTOS
Ao Instituto de Engenharia Biomédica, Departamento de Engenharia Elétrica, Universidade Federal de Santa
Catarina e ao Curso de Ciência da Computação, Universidade do Extremo Sul Catarinense.

REFERÊNCIAS
Berry, Michael J.; Linoff, Gordon. Data mining techniques: for marketing, sales, and customer relationship management.
Indianapolis: Wiley Publishing, 2004.
Bezdek, James et al. Fuzzy models and algorithms for pattern recognition and image processing. New York: Springer,
2005.
Cox, Earl. Fuzzy modeling and genetic algorithms for data mining and exploration. California: Morgan Kaufmann, 2005.
Graham, D.P. , Cardon,A.L. “An update on substance use and treatment following traumatic brain injury”, Annals of the
New York Academy of Sciences, vol. 1141, pp.148-162, oct. 2008.
Guillet, F.,Hamilton, H. J. Quality measures in data mining. Chichester: Springer, 2010.
Gustafson, Donald E.; Kessel, William C. Fuzzy clustering with fuzzy covariance matrix. Proceedings of the IEEE
Control and Decision Conference, San Diego, p. 761-766, jan 1979.
Han J., Kamber M., Pei, J. Pei, Data mining: Concepts and Techniques. Morgan Kaufmann, San Francisco, 2011.
Höppner, Frank et al. Fuzzy cluster analysis: methods for classification, data analysis, and image recognition. Chichester:
John Wiley & Sons, 1999.
Lee, T.T. et al, “Application of data mining to the identification of critical factors in patient falls using a web-based
reporting system”, International Journal of Medical Informatics, vol.80, pp.141–150, feb. 2011 .
Martins, E.T. et al, “Mortality in severe traumatic brain injury: a multivariated analysis of 748 Brazilian patients from
Florianopolis City”, The Journal of Trauma, vol. 67, pp. 85-90, jul. 2009.
Saatman, K.E. et al, “ Classification of traumatic brain injury for targeted therapies”, Journal of Neurotrauma, vol. 25,
pp. 719-738, jul. 2008.
Sut, N. ; Simsek O., “Comparison of regression tree data mining methods for prediction of mortality in head injury”,
Expert Systems with Applications, vol. 38, pp. 15534-15539, nov./dec. 2011.
Tan P.N., Steinbach M., Kumar,V. Introdução ao Data Mining. Ciência Moderna, Rio de Janeiro, 2009.
Theodoraki, E. M. et al, “Innovative data mining approaches for outcome prediction of trauma patients”, Journal
Biomedical Science and Engineering, vol. 3, pp. 791-798, aug. 2010.

110
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

MODELO DE SISTEMA DE MONITORAMENTO PARA

ESTRUTURAS DE AÇO UTILIZADOS EM CONSTRUÇÃO
CIVIL

Diogo Lucena Gomes de Melo1, Eneias Bezerra da Silva Junior2, Gilmar Gonçalves de Brito2,
Paulo Sérgio Brandão do Nascimento2, Mêuser Jorge Silva Valença1
e Sérgio Murilo Maciel Fernandes1
1
Escola Politécnica de Pernambuco, Universidade de Pernambuco , Rua Benfica, 455 - Campus Recife - Recife - PE
2
Instituto Federal de Educação, Ciências e Tecnologia de Pernambuco , Av. Prof Luiz Freire,
500 - Campus Recife - Recife - PE

RESUMO
Os parâmetros de segurança e manutenção, de grande importância nas estruturas civis, envolvem aspectos de risco que
podem resultar em perdas econômicas ou mesmo de vidas humanas. Para que as estruturas civis sejam permanentemente
monitoradas, faz-se necessária a presença de dispositivos sensores que exerçam esta atividade permanentemente. No
presente artigo, propõe-se a realização de um experimento de monitoramento de um corpo de prova de aço através de
sensores. Foram utilizados os sensores strain gage, giroscópio e acelerômetro, além da plataforma de desenvolvimento
arduino como sistema de aquisição de dados, a fim de averiguar sua eficiência na identificação de deformações causadas
pela torção. Espera-se que esse trabalho possa servir de base para o desenvolvimento de sistemas de monitoração em
projetos de engenharia civil, a fim de avaliar a saúde estrutural das construções de um modo permanente e seguro.

PALAVRAS-CHAVE
Acelerômetro, strain gage, giroscópio, monitoração, sistema de aquisição.

1. INTRODUÇÃO
A segurança e manutenção das estruturas civis são de extrema importância para o desenvolvimento
econômico e social, pois afetam diretamente o governo e a população. Programas de monitoramento vêm
sendo desenvolvidos por meio de computadores com a utilização de sensores. Estes programas permitem que
processos e sistemas, antes monitorados de forma arcaica, se tornem mais rápidos e precisos, economizando
tempo, dinheiro e proporcionando não apenas uma melhor forma de armazenamento dos dados, como
também uma maior agilidade na análise dos sinais (Leuckert, 2000). Contudo, apesar do crescente
desenvolvimento desta tecnologia, ainda não é prática comum o monitoramento de estruturas civis,
principalmente no Brasil.
Na década passada observou-se que o gasto dos EUA para recuperação de pontes era de USD 10 bilhões
por ano. A razão para tão elevado gasto estava na avaliação das estruturas a qual era realizada através de
inspeções visuais e audíveis, conforme resposta de modelos construídos utilizando o método dos elementos
finitos (Chase, 2001 apud Chang et al., 2003). No entanto, neste tipo de monitoramento não se tem como
informar parâmetros suficientes e básicos como, por exemplo, o envelhecimento dos componentes
estruturais, o que fazia com que estruturas fossem interditadas erroneamente (Chang et al., 2003). Isto reforça
a importância da aquisição de dados por meio de um sistema computacional de monitoramento com o
objetivo de reduzir custos e obter dados mais precisos e em tempo real.

111
ISBN: 978-972-8939-96-0 © 2013 IADIS

As estruturas de maior durabilidade e segurança geralmente são aquelas que possuem um programa de
gerenciamento que ajudam a otimizar o tipo de intervenção que deve ser feito na estrutura, de forma objetiva,
através da análise dos dados obtidos (Glisic et al., 2002). No trabalho de Camargo (2008), foram utilizados
strain gages para monitoração de esforços e deformação mecânica em estruturas civis. No artigo de Sardinha
et al. (2006) relata-se o monitoramento de dois pilares com acelerômetro onde foi comparado os seus dados
com um modelo numérico em elementos finitos, pela análise de suas frequências naturais, taxas de
amortecimento e modos de vibração .
Atualmente as grandes beneficiárias do monitoramento por meio de sensores são as pontes, sendo o
monitoramento de edifícios ainda pouco pesquisado (Neto, 2012). Com o sensoriamento espalhado na
estrutura pode-se chegar a conclusões mais precisas e rápidas de possíveis danos estruturais. Segundo
Thomaz (1989), alguns diagnósticos não são tão simples, precisando da ajuda de especialistas, ensaios em
laboratórios, revisão do projeto, além de acompanhamento da obra e instrumentação. Apesar de todas estas
iniciativas, ainda assim pode-se não ter a certeza da origem do problema. Neste sentido, busca-se neste artigo
mostrar o funcionamento de um sistema de monitoramento de vergalhões de aço utilizados em estrutura de
concreto por meio de sensores como strain gage , acelerômetro e giroscópio. Este sistema de monitoramento
procura identificar variações dos sinais provenientes dos sensores, inseridos no vergalhão de aço CA 25,
quando submetido ao esforço de torção, a fim de validar o funcionamento destes sensores pelo sistema.

2. MATERIAIS E MÉTODOS

2.1 Strain Gage

O strain gage ou extensômetro é um resistor variável que ajusta sua resistência de acordo com a deformação
do corpo no qual ele foi fixado (Campos, 1991). Logo, para conhecer a deformação "ε" do material, basta
conhecer a variação da resistência elétrica RSG (Resistência do Strain Gage), obedecendo à relação ∆R/R
onde ∆R é a variação da resistência e R é a Resistência Elétrica do strain gage fixado no corpo do material
(Assis, 2007). Um parâmetro importante do strain gage é o seu Gage Factor (GF), descrito na Equação 1,
que mede a sua sensibilidade à distorção, normalmente fornecida pelo fabricante (Assis, 2007).

Para o condicionamento do sinal geralmente é utilizada a ponte de wheatstone (Assis, 2007). O modelo de
ponte de wheatstone, a ser descrito mais adiante, permite que o desbalanceamento, causado pela deformação
do extensômetro, acarrete em uma diferença de potencial.

2.2 Acelerômetro e Giroscópio

Os acelerômetros e os giroscópios com tecnologia MEMS (Microelectromechanical Systems) são sensíveis,
compactos e de baixo custo, podendo ter mais de um eixo. Observa-se, em artigo descrito por Santana,
(2005), que o acelerômetro fornece a variação da aceleração nos seus 3 eixos enquanto o giroscópio fornece a
velocidade angular.
Santana (2005) ainda resalta que os erros mais significativos dos sensores inerciais como o acelerômetro e
giroscópio são: "Bias", fator de escala, erro de quantização, "Drift" e o desalinhamento.
O princípio de funcionamento do giroscópio MEMS baseia-se no efeito Coriolis, e o princípio de
funcionamento do acelerômetro MEMS consiste em um sistema similar ao de massa e mola onde sua
aceleração pode ser calculada pela segunda lei de Newton devido à movimentação da massa (Morgado,
2009).

112
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

2.3 Arduino
O arduino é uma plataforma computacional de código aberto baseado em um microcontrolador e dispositivos
periféricos, bastante utilizados por causa de sua fácil manipulação (Roberts, 2011). Ele é constituído por um
circuito impresso, acoplado a um microcontrolador ATMega da ATMEL, cuja linguagem de programação é
baseada em C/C++. O Arduino Duemilanove com microcontrolador ATmega328 é composto por 14 pinos
I/O digitais, 6 entradas analógicas, um oscilador de 16 MHz, uma conexão USB, uma interface de
alimentação, um conector ICSP, e um botão de reset.

2.4 Metodologia Aplicada

Os sensores utilizados neste trabalho foram um acelerômetro com giroscópio, para obtenção da variação do
ângulo de rotação sofrido pelo vergalhão, além do strain gage, modelo roseta com resistência de 120 ohms, a
fim de aferir a deformação do aço.
Foi utilizado um arduino composto por um microprocessador ATmega 328, cujos dados de medição
foram enviados, via USB, para um computador cujo código de aquisição de dados, em linguagem C, estava
embarcado no microcontrolador. Os dados foram armazenados através do software PLX-DAQ da Parallax
por meio do Microsoft Excel. Este método mostrou-se bastante prático e simples para as necessidades do
projeto. Para se obter as medidas dos ângulos foi usado a unidade de navegação inercial (IMU) constituída
por um acelerômetro e um giroscópio em uma única placa, ambos com sensibilidade tri-axial (medição ao
longo de três eixos ortogonais). O IMU utilizado foi o MPU6050 pela sua disponibilidade de mercado e
preço.
Devido a problemas observados no par giroscópio e acelerômetro, citados anteriormente, foi montado um
filtro complementar. Este filtro foi escolhido devido a sua simplicidade e por ser de baixa complexibilidade
computacional comparado com o filtro de Kalman. Esse filtro complementar utiliza-se de um filtro passa-
baixa no acelerômetro e o outro passa-alta no giroscópio. A expressão analítica utilizada leva em conta as
expressões de ambos os filtros, pela combinação dos dados do acelerômetro e giroscópio, conforme a
Equação 2 (COLTON, 2007):

Equação 2

Onde a constante representa a sintonia do filtro que pode ser ajustado como desejado, T é o intervalo de
tempo das atualizações e a variável i indica, individualmente, os eixos X,Y ou Z. Define-se ainda como o
ângulo filtrado, como a velocidade angular média do eixo i do giroscópio e o como o ângulo do
acelerômetro do eixo i. Vale resaltar que o filtro complementar foi aplicado a cada um dos 3 eixos X, Y e Z,
individualmente, garantindo uma maior estabilidade dos dados.
A medição realizada nos eixos X e Z não apresentou qualquer problema por estarem paralelos ao nível do
solo. Porém o eixo Y por estar perpendicular ao solo e alinhado com a aceleração gravitacional apresentou
medidas distorcidas, não sendo possível medir o ângulo de rotação deste eixo de forma precisa, pela
utilização desta técnica de filtragem, em razão de restrições intrínsecas ao acelerômetro. O cálculo do ângulo
de rotação através do acelerômetro no eixo Y, em virtude deste estar alinhado com o vetor de aceleração
gravitacional (eixo perpendicular ao solo), apresenta variação nula. Ainda assim foi possível a captação da
variação da torção no eixo Y através desta filtragem. Porém esta variação tende a retroceder quando a força
de torção deixa de ser aplicada, devido ao acelerômetro. Com isto pode-se saber o início e o fim da aplicação
da força de torção.
Outra forma possível de medir essa variação no eixo Y seria considerando apenas o valor do ângulo de
rotação do giroscópio. Contudo, este método também seria impreciso devido aos problemas citados
anteriormente em Santana (2005). Durante a experimentação se percebeu que os dados do giroscópio eram
incrementados com o passar do tempo, mesmo estando em repouso, o qual não foi aplicado o filtro
complementar.

113
ISBN: 978-972-8939-96-0 © 2013 IADIS

As saídas dos sensores foram conectadas aos canais do conversor A/D (Analógico/Digital) do arduino,
que converte a tensão elétrica de entrada em números binários, com resolução de 10 bits que equivale a 1024
combinações binárias. O conversor A/D converte uma tensão de 0-5V para 1024 bits de 0 a 1023,
corespondente a 1023 degraus , com resolução de 4,8876 mV/degrau. Foi utilizada na configuração do
arduino uma taxa de transferência 9600 bits por segundo. Para obter-se uma maior precisão foi tirada uma
média dos valores recebidos.
Para o cálculo da tensão (mV) do strain gage conectado no arduino, basta dividir a tensão máxima do
arduino 5 V pela sua faixa de resolução 1023. Em seguida multiplica-se este valor pelo valor retornado pelo
arduino, onde:

Tensão = valor do arduino * (5.0V / 1023) = valor do arduino * (4,8876mV) Equação 3

Contudo, devido ao baixo nível de sinal gerado pela deformação do strain gage, este necessita passar por
um circuito amplificador do tipo CI TL 072, que são circuitos operacionais dedicados para instrumentação,
além de passar pela ponte de wheatstone representada na Figura1 por 2 resistores de 1k5 (R1 e R2), um strain
gage (RG1) de 350 ohms, e um resistor variável na configuração de reostato (P1) de 500 ohms. O resistor
variável serve para que se possa estabilizar a ponte de wheatstone com a resistência do strain gage, ou seja,
RG1 deve ser igual a P1 para que a diferença de potencial em Volt entre os pontos A e B, na Figura 1, seja 0.
No circuito foi colocado um filtro na saída do circuito do strain gage com o intuito de eliminar o ruído.

Figura 1. Esquema do circuito elétrico da ponte de wheatstone utilizado no projeto.

Para confecção do experimento foi utilizado um vergalhão de aço CA 25 de tamanho 34,5cm de
comprimento e diâmetro de 12,5 mm e em uma de suas extremidades, a qual estava livre, foi soldada uma
porca de número 18 para que a torção pudesse ser realizada. Os sensores que foram instalados no corpo de
prova de aço foram o MPU6050 (acelerômetro com giroscópio) e o sensor strain gage, conforme a Figura 2.

Figura 2. Visualização da disposição dos sensores no corpo de prova.

Para realização do ensaio de torção foi utilizado um torquímetro de vareta com 47 cm de comprimento,
com escala de 0 a 20 mkp, equipado com uma chave de encaixe número 18, para que pudesse ser acoplada na
porca do aço a fim de se aplicar a torção, conforme Figura 3.a. Uma das extremidades do aço foi fixado em
um torno mecânico para servir como base de sustentação para a torção, conforme Figura 3.b.

114
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Figura 3. a) Aplicação da força de torção. b) Aço fixado no torno de bancada.

Os dados dos sensores junto com o tempo de execução foram armazenados automaticamente pelo
software PLX-DAQ, enquanto os dados da força, obtida pelo torquímetro, foram verificados de forma visual.
Como cada incremento unitário do torque em mkp estava relacionado ao tempo, se pode relacionar os dados
dos sensores com a força, em virtude de ambas as medidas estarem relacionadas com a grandeza tempo.
Foram realizados 10 experimentos de torção no aço no sentido horário e anti-horário, a fim de averiguar o
funcionamento e o comportamento dos sensores. Serão mostrados os resultados de 2 desses experimentos:
um no sentido horário e outro no sentido anti-horário.

3. RESULTADOS E DISCUSSÃO
O primeiro ensaio de torção realizado no aço foi feito com a força de torque sendo aplicada no sentido anti-
horário, no qual a força máxima aplicada foi de 6 mkp. Os dados dos sensores durante a torção são mostrados
na Figura 4.

Figura 4. Gráficos da variação tensão e dos ângulos causados pela torção.

115
ISBN: 978-972-8939-96-0 © 2013 IADIS

Neste experimento a tensão inicial registrada pelo strain gage foi de 4,74 mV e ao final foi para 4,08 mV.
O gráfico de tensão na Figura 4 foi quase linear, mostrando que o torque foi aproximadamente proporcional à
variação da tensão, que variou de forma decrescente. Essa não linearidade pode ter sido causada pela forma
como foi aplicada a força, devido à resistência do material. Quanto mais se rotacionava o aço mais força de
torque tinha que ser aplicada, o que poderia ter causado uma pequena variação da força devido à instabilidade
na sua aplicação.
Já os dados dos ângulos registrados pelo MPU6050, mostraram o momento de torção do aço no ângulo Y
como era de se esperar devido ao posicionamento do sensor e seus eixos representados na Figura 5. Outra
análise sobre o gráfico gerado pelos ângulos Y e Z é que com a aplicação da força de torque gradativa, os
ângulos Y e Z vieram a responder com maior intensidade a cada variação da sua força aplicada. Isso se deve
ao fato do MPU 6050 ter sido fixado a 20 cm de distância do ponto de aplicação da torção, logo, o local que
sofreu maior deformação foi o local mais próximo de onde estavam sendo aplicada a força de torção. Pode-se
observar ainda que os gráficos dos ângulos Y e Z apresentam certa similaridade. Isso se deve a posição na
qual foi aplicado o torque, onde se gerou de forma quase que proporcional uma flexão em torno do eixo Z e
uma torção em trono do eixo Y. Foi constatado também a variação dos ângulos X e Y, devido à flexão
sofrida pelo aço no momento da aplicação da força de torque, visto que apenas uma extremidade do aço
estava fixada.

Figura 5. Posicionamento dos eixos do MPU6050 fixado no aço.

O segundo experimento foi realizado com a força de torção aplicada no sentido horário, com a carga
máxima aplicada de 4 mkp. Na Figura 6 temos os gráficos gerados com os dados fornecidos pelos sensores
durante o ensaio de torção.

Figura 6. Gráficos da variação tensão e dos ângulos causados pela torção aplicada no sentido horário.

116
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

No segundo experimento a força de torque aplicada foi inferior ao do primeiro experimento devido à
saturação da tensão. Como a tensão inicial do segundo experimento estava em 4,80 mV muito próxima da
tensão de saturação 5 mV, a força aplicada no sentido horário fez a tensão subir ao seu limite,
impossibilitando novos aumentos da tensão, independente da força aplicada. Já a informação dos gráficos de
ângulos Y e Z da Figura 6 mostraram-se diferente do experimento anterior. Isso pode ter ocorrido devido a
uma pequena deformação do aço causada pelo experimento anterior ou pela fragilização do aço que o deixou
mais sensível à torção, além da posição que força foi aplicada. Já o ângulo X, ainda do segundo
experimento, evidenciou mais uma vez a influência causada pela força de torção aplicada, causando uma leve
flexão do aço além da interferência causada pelo o apoio da mão sobre o experimento, para evitar que o aço
não viesse a flexionar, conforme Figura 3.a.
Pela análise dos valores iniciais dos 2 experimentos vê-se que os ângulos não coincidem. Isto se deve a
uma série de fatores como a movimentação do aço no próprio torno, que causa uma pequena alteração do
ângulo, além do próprio deslocamento do MPU 6050, devido ao modo como ele foi fixado no aço, fazendo
com que ele tenha se inclinado um pouco, e por fim a uma pequena deformação permanente decorrente do
primeiro experimento.
Um outro ponto importante na análise dos experimentos diz respeito a redundância de informação
propiciada pelos dois sensores instalados, uma vez que o strain gage consegue medir a deformação do objeto
no local onde ele está fixado. Deste modo ele consegue obter ao mesmo tempo a deformação causada pela
torção e pela flexão do aço no decorrer do experimento. Contudo, neste experimento, não se sabe a direção
da força aplicada através do strain gage, o que é obtido por meio do Mpu 6050, o qual fornece a direção do
deslocamento do material em função das forças aplicadas.

4. CONCLUSÃO
Através dos gráficos gerados pelos dados obtidos dos sensores, percebe-se que o sistema conseguiu
identificar a deformação sofrida pelo aço mediante a força de torção a ele aplicada, além de identificar a
força de flexão sofrida mediante a execução da torção.
Pode-se concluir ainda que os dados de torção poderiam ser mais eficientes e precisos caso fosse usada
uma máquina especifica para torção, evitando assim problemas como aquele da flexão ocorrida no aço, além
da obtenção de dados mais lineares durante a aplicação da força. Contudo a metodologia utilizada na
condução do experimento mostrou-se interessante, pois influências de outros tipos de forças foram captadas
pelo sistema, dando um maior subsídio de informações para análise e validação do mesmo.
Com o aperfeiçoamento do ensaio de torção e a realização específica do ensaio de flexão com esses
sensores, pode-se ter um maior subsídio de informações para criação de um sistema robusto a fim de
identificar as forças atuantes na deformação do aço, criando assim um sistema de monitoração estrutural.
Com esses sensores instalados nas estruturas civis pode-se mensurar a deformação causada em aços que
são utilizados em concreto armado, além analisar os tipos de forças a eles aplicadas, uma vez que se
conseguiu identificar o direcionamento das forças que estavam sendo aplicadas no experimento com o aço
CA 25. Esses dados fornecidos pelo sistema de monitoração estrutural contribuem para uma melhor
manutenção da estrutura, além de fornecer uma maior segurança com o objetivo de evitar acidentes graves
proporcionados por desabamentos, causados pela má conservação, e falhas nas observações dessas estruturas.
Para trabalhos futuros pretende-se criar uma rede de sensores sem fio para monitoramento de uma
estrutura de concreto armado, além da colocação de novos sensores a fim de se aumentar à confiabilidade dos
dados por meio de redundância. Pretende-se ainda desenvolver pesquisas relacionadas ao encapsulamento
dos sensores no interior dos corpos de prova de concreto, de modo a possibilitar a captura de sinais por meio
de um correto isolamento, sem a influência danosa do cimento sobre os dispositivos. Outra meta é conseguir
medir de forma mais precisa a variação do ângulo do eixo de rotação paralelo ao vetor gravitacional.

117
ISBN: 978-972-8939-96-0 © 2013 IADIS

REFERÊNCIAS
Assis, W. A., 2007. Sistemas computacionais de apoio à monitoração de estruturas de engenharia civil. Tese de
Doutorado. Escola Politécnica, Escola Politécnica da Universidade de São Paulo, São Paulo, Brasil.
Campos, F. F., 1991 Sistema de Condicionamento de Sinais, Aquisição, Armazenagem d Dados para Transdutores Strain
Gage. Dissertação de Mestrado, Universidade Federal de Pernambuco, Recife, Brasil.
Camargo, V. L. A., 2008. Desenvolvimento e implementação de uma plataforma para monitoramento estrutural
utilizando sensores extensométricos conectados em rede. Tese de mestrado. Universidade Estadual de Londrina
Mestre em Engenharia Elétrica, Londrina, Brasil.
Chang, P. C. et al., 2003. Review Paper: Health monitoring of civil infrastructure. Structural Health Monitoring vol. 2, p.
257–267.
Colton, S.2007: The balance filter – A simple solution for Integrating Accelerometer and Gyroscope Measurements for a
Balancing proble. Massachusetts Institute of Technology. Disponível em: <web.mit.edu/scolton/www/filter.pdf>
Acesso em: 8 jan. 2013.
Glisic, B. et al., 2002. Structural monitoring of concrete structures. Third World Conference on Structural Control,
Como, Italy, p. 10.
Leuckert, C, 2000. Sistema portátil de aquisição de dados para análise dinâmica de estruturas mecânicas, Dissertação
de Mestrado, Universidade Federal do Rio Grande do Sul, Porto Alegre, Brasil.
Morgado, F. L. M., 2009.Concepção de um Pequeno Sensor Inercial 3D. Dissertação de Mestrado, Universidade de
Aveiro, Aveiro, Portugal.
Neto, G., 2012. Contribuição o desenvolvimento de técnicas de monitoramento remoto para blocos de fundação de
edifícios em concreto armado com vistas à durabilidade. Tese de Doutorado, Escola Politécnica da Universidade de
São Paulo, São Paulo, Brasil.
Roberts, M., 2011. Arduino Básico. Editora Novatec, São Paulo, Brasil.
Sardinha, I. B. et al., 2006. Monitoração de estruturas para identificação de parâmetros modais. Proceedings of the XXVII
Iberian Latin American Congress on Computational Methods in Engineering, Pará, Brasil.
Santana, D. D., 2005. Estimação de trajetórias terrestres utilizando unidades de medição inercial de baixo custo e fusão
sensorial. Dissertação de Mestrado, Escola Politécnica da Universidade de São Paulo, São Paulo, Brasil.
Thomaz, E., 1989 Trincas em Edifícios : causas, prevenção e recuperação, 1.ed, Editora Pini. São Paulo, Brasil.

118
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

MIF-RC: UMA METODOLOGIA INTEGRADA PARA

APLICAÇÃO DE FORENSE COMPUTACIONAL EM LOGS
DE E-MAIL

Toni Escobar, Cristiane Ellwanger, Cristina Paludo Santos, Alessandro Freitas de Oliveira
e Paulo Ricardo Baptista Betencourt
Universidade Regional Integrada do Alto Uruguai e das Missões – Campus de Santo Ângelo/RS
Av. Universidade das Missões, 464 – Bairro Universitário, Santo Ângelo-RS - 98.802-470

RESUMO
Este artigo apresenta uma proposta para aplicação da forense computacional em logs de e-mail a partir da integração de
duas abordagens já consolidadas e sugere sua aplicação como complementar ao gerenciamento de riscos e não como uma
forma de substituí-lo. Um estudo de caso foi desenvolvido com o intuito de especificar e demonstrar a aplicabilidade da
metodologia proposta, com ênfase nas fases de coleta, armazenamento e manuseio de dados. Os resultados obtidos
sugerem ganhos de tempo e qualidade nos dados gerados e analisados em comparação às metodologias isoladas.

PALAVRAS-CHAVES
Segurança, Forense Computacional, Gerenciamento de riscos, Logs de e-mail

1. INTRODUÇÃO
Vinculada diretamente a área de segurança da informação a Forense Computacional destina-se não somente à
coleta e manuseio de informações como subsídio a processos judiciais, mas também como auxílio ao
gerenciamento de riscos no intuito de minimizar os problemas relacionados à segurança que possam de
alguma maneira comprometer as informações críticas existentes no ambiente interno das organizações.
Diante disso, pode ser definida como a inspeção científica e sistemática em ambientes computacionais, com a
finalidade de se coletar evidências derivadas de fontes digitais, tendo como objetivo promover a
reconstituição dos eventos encontrados, determinando se o ambiente em análise foi utilizado para práticas
ilegais ou não autorizadas [Palmer, 2001].
Dificuldades em sua aplicação estão relacionadas ao desconhecimento do escopo real e abrangência da
área de Forense Computacional, ou seja, estão atreladas à concepção de seu processo, no entendimento de
quais áreas das organizações devem ser envolvidas, à verificação da existência de ferramentas
computacionais viáveis para a prática forense e à relação custo/benefício que podem advir de sua aplicação
no âmbito organizacional [Reynaldo, 2007]. Na concepção do autor, uma forma de auxiliar o processo de
análise forense computacional voltado a redes de computadores é dispor de um ambiente computacional e
tecnológico controlado e uma equipe de monitoração, o que proporciona um maior número de informações
(logs) de um determinado evento bem como uma sequência bem definida de passos, visto que as evidências
de um crime são passiveis de serem impugnadas judicialmente, caso não tenham sido coletadas sob o amparo
de metodologia bem definida com critérios válidos. Entretanto, no que se refere às metodologias direcionadas
à aplicação da forense computacional, algumas a abordam de forma genérica e não demonstram de forma
prática como mesma pode ser aplicada em contextos específicos [Reynaldo, 2007; Melo, 2009], enquanto
outras se direcionam especificamente ao aspecto jurídico, sem levar em consideração os benefícios advindos
da aplicação da forense computacional no gerenciamento e controle de riscos [Peron; Deus; Junior, 2011].
Isto tem impulsionado o desenvolvimento deste estudo que tem por intuito não somente contextualizar a
forense computacional, mas, além disso, demonstrar como a mesma pode ser aplicada sobre logs de e-mail e
propor uma metodologia integrada, composta pela união de outras duas metodologias, demonstrando como
são aplicadas as fases essenciais da forense computacional. Para isso, estrutura-se conforme segue: a seção 2

119
ISBN: 978-972-8939-96-0 © 2013 IADIS

apresenta uma contextualização geral sobre forense computacional, a seção 3 retrata os preceitos conceituais
que a permeiam, a seção 4 direciona-se às metodologias para sua aplicação, a seção 5 apresenta a
metodologia MIF-RC e os fundamentos de sua aplicação e a seção 6 apresenta os resultados e as sugestões
para trabalhos futuros.

2. FORENSE COMPUTACIONAL
A segurança da informação, no contexto de redes de computadores, remete para a proteção dos sistemas de
informação contra a negação de serviço a usuários autorizados, assim como, contra a intrusão e a
modificação não autorizada de dados ou informações armazenados em processamento ou em trânsito,
estabelecendo medidas para prevenir, detectar, deter e documentar eventuais ameaças [NBR ISO/IEC 17799,
2003].
Tanto a nível nacional quanto global, os principais incidentes ocorridos em relação a crimes digitais
voltam-se à exploração de dados, seguido de exploração de redes, sistemas, aplicações, dispositivos móveis e
engenharia social [Alves, 2010] [CERT.br, 2012]. Por mais que medidas de segurança sejam empregadas,
existe a possibilidade de que em algum momento uma vulnerabilidade seja explorada, assim, todo o incidente
deve ser analisado para que se crie um ambiente mais seguro. Nesse contexto a forense computacional
propicia um exame do que houve de errado, ajudando para a implantação de medidas mais seguras [Macedo,
2010]. Sua implantação propicia às organizações uma confiabilidade maior em suas informações e respostas
mais rápidas à tentativas de violação de sistemas e/ou informações. Entretanto, o contexto real de sua
aplicação tem sido realizado de forma superficial, perdendo o caráter relevante das ações a ela vinculadas,
tendo em vista que a mesma pode ser conduzida de duas maneiras distintas, mas inter-relacionadas. A
primeira classificada como Geração de Documentos Internos (GDI) que tem como objetivo realizar uma
investigação para identificar os problemas, melhorar processos e mitigar riscos e a segunda direcionada a
Geração de Documentos para embasamento jurídico (GDEJ), sendo que esta se diferencia da primeira pela
necessidade de um cuidado maior por resultar na documentação que será utilizada em um processo jurídico
[Reynaldo, 2007]. Embora tais processos possuam objetivos distintos, ambos utilizam praticamente as
mesmas ferramentas forenses para suas análises. Destaca-se que pelo fato de gerar documentação apenas para
o ambiente interno, o GDI torna-se um processo menos complexo, gerando um custo menor para a
organização em termos de implantação. Entretanto partes das organizações aplicam as atividades de forense
computacional de forma isolada ou ainda por áreas desvinculadas da prática de forense. Entretanto parte das
organizações aplicam as atividades de forense computacional de forma isolada ou ainda por áreas
desvinculadas da prática de forense.

3. METODOLOGIAS VOLTADAS A FORENSE COMPUTACIONAL

No que se refere ao estabelecimento de metodologias para a implantação de forense computacional a
literatura apresenta trabalhos que as descrevem de forma generalizada com pouca ênfase na forma como tais
metodologias são aplicadas. Dentre tais trabalhos destaca-se a metodologia proposta por Reinaldo (2007),
dividida em três fases: a fase inicial, a fase de coleta de dados e fase final. A fase inicial detém-se no
levantamento de informações para documentação do processo, no desenvolvimento de um fluxograma
detalhado do processo e contatos estabelecido tanto com especialistas do negócio quanto com os técnicos. Na
fase de coleta de dados é iniciada a preparação das informações, em que são verificadas as tecnologias e
evidências que serão analisadas. Já na fase final é realizada a análise de resultados dos dados coletados de
forma a identificar todas as atividades relacionadas a um suspeito ou evento ocorrido.
Kent et al. (2006) também se detêm na especificação de fases para o processo de investigação, referencia-
as como coleta, exame, análise e resultados. A autora ressalta que na fase de coleta, os dados relacionados a
um evento devem ser obtidos com o intuito de se preservar a integridade dos mesmos, sendo os
equipamentos, posteriormente, devidamente identificados, embalados, etiquetados e suas identificações
registradas; na fase de exame os dados devem ser selecionados e ferramentas e técnicas devem ser verificadas
e adequadas a cada tipo de dado coletado; a fase de análise refere-se à análise dos dados filtrados na etapa
anterior com vistas a se obter informações úteis e relevantes que possam responder às perguntas que deram

120
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

origem à investigação; por fim, na fase de interpretação, gera-se um relatório contendo os procedimentos
realizados e os resultados obtidos.
Já Mello (2009) propõe a aplicação da forense computacional em etapas, denominadas aquisição,
identificação, avaliação e apresentação e são referenciados pelo autor conforme segue: (a) Aquisição:
Período em que o perito forense atua coletando potenciais dados e artefatos relacionados ao incidente de
segurança (artefatos a serem analisados); (b) Identificação: métodos que podem ser aplicados sobre os dados
coletados [Holperin; Leobons, 2007]. Nesta fase também são aplicadas diversas ferramentas e técnicas como
a utilização de filtros como palavras-chave ou tipos de arquivos nas pesquisas, o que torna a localização das
informações mais eficazes [Pereira, 2010]; (c) Avaliação: fase em que se correlacionam informações de
várias fontes de dados e (d) Apresentação: retrata de forma clara e concisa, todas as evidências localizadas e
analisadas, com base nas etapas anteriores, fornecendo a equipe de segurança da informação dados sobre
incidentes de segurança e sugestões de melhoria no ambiente interno.
Tais metodologias voltam-se ao estabelecimento de passos para a realização da forense computacional de
forma generalizada. Além disso, no que se refere à adoção das mesmas deve ser observado o contexto de
aplicação de tais metodologias bem como sua viabilidade de aplicação.

4. MIF-RC: UMA METODOLOGIA INTEGRADA PARA APLICAÇÃO

PRÁTICA DE FORENSE COMPUTACIONAL
A Metodologia Integrada para Aplicação prática de Forense Computacional (MIF-RC) não esta restrita ao
ambiente de redes de computadores, tendo em vista que seus fundamentos teóricos e seu escopo de aplicação.
Baseada na metodologia de Reinaldo (2007), MIF-RC traz a distribuição e organização das tarefas em cada
fase da pericia a ser realizada e agrega em si contribuições propostas por Melo (2009), tais como a fase de
coleta de dados e a apresentação final de resultados, conforme demonstra a Figura. Os pontos retratam as
contribuições dos autores que a embasaram e agrega a proposta deste trabalho para o ambiente de rede, o
qual é incorporado ao processo de implantação de forense computacional em âmbito organizacional.

Figura 1. Metodologia Proposta adaptado [Melo 2009].

Aplicada sob o enfoque (GDI) tem como objetivo realizar uma investigação para identificar os problemas,
melhorar processos e mitigar riscos. Não tem por intuito a substituição do processo de gerenciamento de
riscos, mas sim como uma forma complementar a este. Para isso, agrega em si as etapas de levantamento de
informações, coleta de dados, análise de dados, análise de resultados e apresentação de resultados, mantendo
os fundamentos básicos da forense computacional. Assim, o levantamento de informações é a etapa na qual o
perito se volta para a compreensão da organização como um todo (estrutura organizacional, serviços do

121
ISBN: 978-972-8939-96-0 © 2013 IADIS

ambiente de rede, entre outros) e busca extrair o máximo de informações possíveis, pois estas direcionam o
pericia forense e auxiliam na escolha de ferramentas para sua realização. A coleta de dados é direcionada sob
dois métodos. O primeiro envolve a coleta de dados online e contempla os dados voláteis, sendo realizada
com o equipamento (computador) ligado, eventuais descuidos nesta fase podem eliminar informações
importantes. O segundo envolve a coleta de dados off-line, realizada com o equipamento desligado e
demanda ferramentas forenses adequadas para sua realização.
A etapa de análise de dados direciona-se ao conhecimento técnico do perito forense no entendimento das
ferramentas a serem utilizadas e na seleção de informações que realmente contribuam para a prática forense.
Assim está sedimentada sob uma análise criteriosa dos resultados advindos dos dados coletados. Tendo em
vista que algumas informações podem não fazer sentido quando interpretadas de forma isolada faz-se
necessário o estabelecimento de uma linha do tempo, realizada a partir dos eventos identificados. Além disso,
devem-se identificar os motivos pelos quais determinados eventos ocorrem e os efeitos de sua ocorrência.
Tais motivos evidenciam a importância da interação e o compartilhamento de informações entre especialistas
envolvidos no intuito de eliminar eventuais dúvidas que, por ventura, possam surgir durante o caso.
Por fim a apresentação dos resultados retrata a finalização dos procedimentos realizados e consiste na
elaboração de um relatório detalhado das conclusões advindas da prática forense, sendo este de suma
relevância para a reconstituição de eventos (se necessário) em ambiente computacional, oferecendo ainda
subsídios para revisões e adequações ao ambiente de rede. Todas as etapas são de fundamental importância e
a integração e o estabelecimento das mesmas serviram de subsídio para a realização do estudo de caso,
proporcionando a demonstração dos resultados advindos de sua aplicação, os quais são descritos nas seções
subsequentes.

5. CENÁRIO DE APLICAÇÃO DA METODOLOGIA MIF-RC

A aplicação prática da Metodologia Integrada foi realizada utilizando-se um estudo de caso na Universidade
Regional Integrada do Alto Uruguai e das Missões (URI) - Campus de Santo Ângelo, visando contemplar a
aplicação das etapas descritas na seção anterior. Salienta-se, entretanto, que para preservar a identidade das
partes envolvidas algumas informações obtidas foram omitidas na fase de apresentação dos resultados.
Na fase de Levantamento de Informações verificou-se a infraestrutura de servidores no intuito de se
determinar as características específicas da mesma. Nesta fase também foram identificados alguns serviços
tais como serviços de e-mail e a hospedagem de site. Dando seguimento a esta fase, anomalias no serviço de
e-mail foram mencionadas nos relatos da equipe de TI, retratando um alto tráfego de mensagens enviadas a
uma lista de destinatários distintos. Ao identificar o remetente das mensagens houve um bloqueio da conta de
e-mail, no entanto, tal ação não foi suficiente para resolver o problema, pois novamente houve o envio de
mensagens em massa a partir de um remetente diferente. Embora houvesse atualizações no servidor,
mensagens em massa ainda eram enviadas. Normalmente esse envio não autorizado ocorria em períodos
posteriores ao recebimento de mensagens supostamente envidas pelo suporte da universidade solicitando
resposta da mensagem com usuario e senha da conta de e-mail.
De posse das informações obtidas o perito tem condições de listar os pontos relevantes para a perícia,
sendo a análise dos logs dos serviços de e-mail indispensável para se identificar o modus operandi de ação do
responsável pelo envio dos e-mails em massa. Certificando-se que o servidor de e-mail continua ligado e em
operação, deu-se inicio a fase de Coleta de dados online, ou seja, a captura de informações voláteis
(processos em execução no servidor, conexões estabelecidas, dados da memória principal e outros). Devido à
volatilidade dos dados faz-se necessário a coleta de tais informações com ferramentas existentes no próprio
sistema, pois a instalação uma ferramenta auxiliares podem comprometer informações significativas. Os
dados coletados foram armazenados em um dispositivo de armazenamento (HD externo) certificando-se de
os dados coletados estar na mídia de armazenados. Em seguida foi gerado o hash dos arquivos com as
ferramentas md5sum e sha256sum. Posteriormente, o servidor foi desligado objetivando a coleta de dados
off-line. Para o estudo de caso fez-se uso da ferramenta BackTrack, a partir da qual capturou-se a imagem do
HD do servidor suspeito, integrando-se o HD da máquina ao BackTrack e agregando outro HD de capacidade
maior (formatado) para copia do conteúdo com o auxilio do software Automated Image & Restore (AIR),
uma interface gráfica para as ferramentas dd e dcfldd que facilita a criação da imagem, diminuindo os riscos
do usuário errar parâmetros de cópia do disco.

122
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Para a fase de Análise dos Dados utilizou-se o software strings (componente da BackTrack) para a
verificação dos arquivos coletados no modo online, enquanto que para a análise off-line foi utilizada a
imagem gerada do HD suspeito. A coleta online dentre outras tem a informação da partição correspondente
ao diretorio de armazenamento de log do servidor (var/log) estando essa em /dev/sda5, iniciou-se ao processo
de montagem da partição em modo apenas de leitora de dados com o utilitário mount, sendo que a sintaxe de
execução para este procedimento é mount -t ext3 -o ro /dev/sdb5 /hd2.
Iniciada a verificação dos logs, detendo-se a análise sobre os eventos que referenciam, de alguma forma,
o envio de e-mails em massa, usando-se a sintaxe ls -lha /hd2/log/mail-201210*, a qual lista todos os
arquivos de log de e-mail, correspondentes a um determinado período. A partir do comando verificou-se que
dois arquivos apresentavam tamanho maior que os demais (mail-20121024.bz2 e mail-20121031.bz2). Além
disso, o levantamento realizado evidenciou um e-mail, cujo remetente é identificado como conta-01 e
destinatário das respostas o endereço conta-02. Tais endereços foram pesquisados no log utilizando-se da
ferramenta bzcat, sob a sintaxe “# bzcat /hd2/log/mail-201210* | grep conta-01 | grep from”, que possibilita
a consulta de mensagens em todos os arquivos de log de e-mail, cujo remetente origina-se da conta-01. Ao
alterar a sintaxe da consulta para “# bzcat /hd2/log/mail-201210* | grep conta-01 | grep to” verificou-se as
mensagens enviadas para a conta-01, sabendo-se que ao responder a mensagem suspeita ela tem como
destino o endereço de e-mail conta-01. Para identificar se houveram respostas e quais usuários a responderam
utilizou-se o comando “# bzcat /hd2/log/mail-201210* | grep conta-01”, cujo resultado demonstra que
quatro mensagens foram enviadas ao e-mail conta-02, e os usuários identificados de responder a mensagem
são usuário-01, usuário-02, usuário-03, sendo que o usuário-02 respondeu duas vezes a mensagem.
O arquivo de log identificado como mail-20121024.bz2 apresenta as mensagens do dia posterior ao
e-mail e demostra que houve envio de e-mails em massa do usuário-02. No mesmo log pode-se observar que
o IP do Servidor de e-mail da universidade foi incluído em algumas listas de SPAM. A Figura 2 demonstra a
situação informada.

Figura 2. Resultado da busca nos logs por bloqueios de SPAM.

Após identificação do usuário-02 como o responsável pelo envio destas mensagens foram feitas
pesquisas nos logs no intuito de se verificar como essa conta teve acesso aos servidores da universidade,
usando a expressão de busca “# bzcat /hd2/log/mail-201210* | grep "LOGIN, user= usuário-02". Contatou-se
que todos os acessos eram provenientes do IP 10.1.10.102, identificado como o servidor de webmail da
universidade. Como havia também outro servidor envolvido, realizaram-se todos os processos de coleta e
análise de dados no mesmo. Sabendo que se trata de um servidor de webmail, a verificação é realizada nos
arquivos de log do serviço web, utilizando as técnicas utilizadas até o presente momento.
O log do serviço web armazena entre outras, a informação do IP que acessou a pagina do webmail, o
código de identificação do usuário (id), hora de acesso e outros. Sabido o endereço de e-mail, é possível
realizar a consulta no banco de dados do sistema de webmail pra identificar o uid do usuário-02. De posse do
uid do usuário, a procura no log do serviço web passa a ser realizada com a sintaxe: “bzcat access_log-
20121023.bz | grep id=2373”.
O resultado da operação pode ser verificado apresenta-se na Figura 3, no qual o IP 10.1.1.5 refere-se ao
firewall da rede, indicando que um novo servidor deve ser periciado. Nas verificações do servidor firewall foi
constatado que ele faz apenas o redirecionamento da porta 80 do IP externo da empresa para a porta 80 do
servidor de webmail que responde no ip 10.1.10.102. Além disso, um problema na execução do projeto de
rede implantado pela universidade foi identificado, pois o servidor de firewall esta mascarando todos os
acessos externos que tem como destino o webmail, colocando como origem da solicitação seu próprio
endereço IP sem gravar o log desta operação.

123
ISBN: 978-972-8939-96-0 © 2013 IADIS

Figura 3. Resultado da busca nos logs pelo id do usuário02.

Identificou-se também que a conta-02 realizou alterações no perfil da conta de e-mail do usuário-03 no
dia posterior ao envio dos e-mails (conforme seus logs). Após o término da análise dos dados deu-se início a
fase de Análise dos Resultados obtidos. Para tanto, desenvolveu-se a linha do tempo dos acontecimentos,
visando encontrar correlações dos eventos (causas e efeitos), conforme apresenta a Tabela 1.
Tabela 1. Sequência de Registros.
Período Evento
Mesmo dia O e-mail do remetente conta-01 foi recebido às 13h41min com a identificação
A8E7B6E51A o último registro de mensagens desse remetente é 13h49min com as
identificações 8872C6E51A.
Mesmo dia Primeira resposta para conta-02 às 13h54min, mensagem 2446F6E1CE, a segunda às
17h45min mensagem 1295E6E51A e a terceira às 17h47min mensagem D756B6E51A.
1 dia após Inicio do envido de e-mail em massa por usuário-02 as 04h06min mensagem 07DF16E518, as,
04h57min a mensagem 7C0556E56C é recusada pelo servidor de e-mail do destinatário devido
ao IP do servidor de e-mail da universidade estar em listas de SPAM.
2 dias após 09h01min registrada última mensagem em massa de usuário-02 com identificação
F41AB6E59B, a conta do usuário responsável pelo envio foi bloqueada.
6 dias após Nova ocorrência de resposta ao e-mail conta-02 13h29min mensagem 846D96E550.
7 dias após Inicio do envio de e-mail em massa por usuário-03 as 05h02min mensagem
450E06E54E, IP em listas de SPAM 06h01min mensagem 71C256E54E é recusada pelo
servidor de destino devido à lista de SPAM.
8 dias após Término do envio de e-mail em massa de usuário-03 as 08h57min último registro do
envio de mensagens desse remetente 7186E6E196, conta do usuário foi bloqueada.
20 dias após Coleta dos dados para perícia.
Os envios de e-mails em massa estão diretamente ligados com os dados informados na resposta do e-mail
que alguns usuários fizeram para conta-02. Agora com o material coletado sobre o caso podemos passar a
redigir as considerações que findam nossa pericia (relatório final de perícia).
A Apresentação dos Resultados da pericia é realizada através de um relatório que contém as
informações do fato ocorrido e remonta o modo de operação que a conta-02 utilizou. O incidente que foi alvo
da investigação começou no momento do envio do e-mail apresentado na Figura 4, com o recebimento de
uma mensagem eletrônica via e-mail, cujo remetente é conta-01 tendo como destinatário diversos usuários do
e-mail da universidade e como beneficiário em caso de resposta da mensagem o endereço conta-02. A
técnica utilizada neste incidente é conhecida como engenharia social, onde uma pessoa convence outra a lhe
fornecer informações privilegiadas por meio de uma mensagem escrita, por telefone ou até mesmo
presencialmente. Nesta ocasião a técnica de engenharia social foi empregada com a utilização de e-mail, a
mensagem enviada aos usuários tenta transmitir a informação de que o atacante faz parte da equipe de
suporte da universidade, e devido algumas manutenções o usuário deveria informar seus dados, nome
completo, endereço de e-mail, nome de usuário, senha e confirmar a senha. Embora contivesse vários erros
de grafia, alguns usuários confiaram na mensagem e responderam-na com os seus dados, de forma que o
responsável pelo e-mail conta-02 passa a ter acesso a estas informações e faz o uso indevido delas.
Por volta das 04h06min do terceiro dia da investigação, teve início nos servidores da universidade o envio
de mensagens de e-mail em massa (SPAM), o responsável pelo envio foi o usuário-02 que respondeu a
mensagem do atacante com seus dados. A ação do envio acabou ocasionando a inclusão do IP do servidor de
e-mail da universidade em listas de SPAM, fazendo com que alguns provedores recusassem por um
determinado período mensagens envidas pela universidade. Durante esse bloqueio mensagens que não eram

124
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

objeto de envio em massa também foram rejeitadas, gerando assim prejuízos no que diz respeito à utilização
do e-mail, ora pela recusa das mensagens e ora pelo consumo de link de internet sem necessidade. Por volta
das 09h01min do quarto dia a equipe de suporte notou que o serviço de e-mail estava lento e ao acessar o
servidor de e-mail verificou a existência de milhares de mensagens enviadas por usuário-02, bloqueando o
mesmo. Após o ocorrido, o tráfego de mensagens na rede normalizou e nos dias subsequentes os bloqueios
de IP saíram das listas. No oitavo dia de análise, ao realizar acesso ao servidor de e-mail foi verificado que
houve novo envio de e-mail em massa, dessa vez realizada por usuário-03. A única ação adotada pelo
suporte técnico foi realizar o bloqueio dessa conta. A ocorrência verificada no oitavo dia pelo suporte teve
como origem uma mensagem recebida no segundo dia e que foi respondida no sétimo dia de análise, às
13h29min pelo usuário-03. O Início do envio de e-mail em massa originou-se as 05h02min do sétimo dia. Às
06h01min do mesmo dia mensagens começam a ser recusadas pelos servidores de destino pelo fato de que o
IP da universidade estava, novamente, em listas de SPAM. Neste caso, recomenda-se que seja realizada a
correção do firewall para que possam ser identificados os reais IP’s de quem está acessando o webmail, pois
nas provas colhidas existe o indicativo de que não foram os usuários legítimos que realizaram as ações de
envio em massa por terem respondido a mensagem com os dados de e-mail e senha de acesso, mas não se
tem como comprovar isso pela falta da correta informação de IP nos logs. Desta maneira sem poder provar os
verdadeiros responsáveis pelos danos sofridos, a universidade não pode ser indenizada por este dano.
A fase de Adequação do Ambiente propõe ajustes, adequando o ambiente de rede às práticas da forense
em consonância com a metodologia proposta. Com destaque para que todos os componentes em rede
possuam o mesmo horário; minimização do risco de que um invasor apague o log das transações, pois se
sugere que este não fique em um servidor local; que a autenticação para acesso ao ambiente informe qual
usuário realizou o acesso; que o firewall, liberando acesso apenas às portas realmente necessárias para os
serviços e enviando o log de todas suas transações para o servidor de logs, prove melhor segurança ao
ambiente trabalhando em conjunto com o servidor de identificação de intrusões ao ambiente. Com essas
adequações pretende-se maximizar as possibilidades de sucesso na identificação de eventos que ocorrem no
ambiente de rede. O ambiente de rede da universidade contempla a maioria dos servidores sugeridos,
necessitando apenas a centralização dos logs e a aplicação de auditoria dos serviços configurados, a fim de
identificar e sanar falhas como a identificada no servidor de firewall. Neste caso a ferramenta BackTrack
pode auxiliar na realização de testes sobre vulnerabilidades existentes no ambiente.

6. CONCLUSÕES E SUGESTÕES PARA TRABALHOS FUTUROS

A integração de metodologias proporcionou a aplicação da forense computacional de uma forma ágil,
obtendo resultados com menor tempo comparado à aplicação da metodologia proposta por Reynaldo (2007),
pois suprimindo a etapa correspondente à geração de laudos judiciais reduziram-se os custos voltados à
equipe jurídica, dando ênfase na correta coleta, armazenamento e análise dos dados, gerando apenas relatório
técnico e aplicando as ações corretivas ao ambiente de rede. Sugere-se a aplicação de forense computacional
como complementar ao processo de gerenciamento de riscos e não como uma substituição ao mesmo.
A partir da forense computacional verificou-se que a segurança da informação foi violada após um
usuário legítimo do sistema de webmail responder uma mensagem fraudulenta com seus dados de acesso ao
e-mail, tornando evidente a necessidade de revisões na politica de segurança da informação da universidade,
assim como revisão nos processos de implantação de sistemas de segurança, uma vez que foi identificada a
falha no redirecionamento de portas do servidor de firewall, causa da impossibilidade de se identificar o IP
que realizou o acesso ao sistema. No que tange a verificação do ambiente de rede da universidade verificou-
se a necessidade de implantação do servidor de log centralizado, visto que os demais servidores de controle
de domínio, firewall, horário, IDS já estão em uso, havendo somente a necessidade de revisões em suas
configurações. Verificou-se ainda que a forense computacional quando incorporada aos processos da
organização, seja com intuito judicial ou não, pode auxiliar a equipe de TI com informações na demonstração
de como ocorreu um determinado evento, suas consequências e formas de contorná-los, proporcionando a
melhoria contínua dos processos internos da organização. O sucesso da investigação de um incidente de
segurança está relacionado com a maneira que o ambiente é controlado pela equipe de Tecnologia de
Informação (TI). Se o ambiente possuir servidor de log centralizado, servidores de horas (NTP Server),

125
ISBN: 978-972-8939-96-0 © 2013 IADIS

mecanismos de proteção do ambiente como firewall, sistema de identificação de intrusos (IDS) e servidor de
autenticação de usuários, a possibilidade de resultado conclusivo é maximizada.
A metodologia MIF-RC proposta neste trabalho, resultante na união de dois métodos validados, agrega a
contribuição de uma etapa que ressalta a verificação do ambiente de rede a fim de adequá-lo para melhores
resultados na implantação do processo de computação forense. Para trabalhos futuros sugere-se pesquisas
para desenvolvimento e avaliação dos procedimentos de análise forense, testes e certificações de ferramentas
utilizadas para sua prática.

REFERÊNCIAS
ALVES, V. Dois terços das empresas do Brasil elevarão gastos com segurança. Revista TI Inside Online. Disponível em
<http://www.tiinside.com.br/09/11/2010/dois-tercos-das-empresas-do-brasil-elevarao-gastos-com-
seguranca/ti/203735/news.aspx> Acesso em 18 maio 2011.
BACKTRACK Linux. Penetration Testing Distribution. Home page da ferramenta BackTrack. Disponível em <
http://www.backtrack-linux.org/> Acesso dia 14 agosto 2012.
CERT.BR. Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil. Incidentes Reportados ao
CERT.br de Julho a Setembro de 2012. Disponível em < http://www.nic.br/imprensa/releases/2010/rl-2010-02.htm >
Acesso em 08 outubro 2012.
ELEUTERIO, P.; MACHADO, M.. Desvendando a Computação Forense. São Paulo: Novatec Editora, 2010.
FARMER, D.; Venema, W. Pericia Forense Computacional. São Paulo: Pearson Prentice Hall, 2007.
FILHO, J. Perícia Forense Computacional: Guia de referência rápida, Parte 2: Análise de evidências e laudo. Disponível
em <http://eriberto.pro.br/forense/guia_forense_1.1_parte_2.pdf> Acesso em 12 novembro 2012.
FREITAS, A. Perícia Forense Aplicada à Informática. Monografia de Pós-Graduação “Lato Sensu” em Internet Security.
IBPI, 2003. Disponívem em <http://www.linuxsecurity.com.br/info/general/andrey-freitas.pdf> Acesso dia 06 de
setembro 2012.
HOLPERIN, M.; LEOBONS, R. Análise Forense. Site sobre Análise Forense. Disponível em
<http://www.gta.ufrj.br/grad/07_1/forense/manuseio.html> Acesso em 12 novembro 2012.
Information Week Brasil. Dilemas da Segurança. Ano 12.Número 230.Agosto de 2010.
KENT, K.; Chevalier, S.; Grance, T.; Dang, H. Guide to Integrating Forensic Techniques into Incident Response.
Disponível em http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf; 2006. Acesso em 08 setembro 2012.
LYRA, M. Segurança e Auditoria em Sistemas de Informação. Rio de Janeiro: Editora Ciência Moderna Ltda., 2008.
MACEDO, D.. O que é a computação forense e sua importância no âmbito empresarial. Site de Diego Macêdo – Analista
de T.I. Disponível em < http://www.diegomacedo.com.br/o-que-e-a-computacao-forense-e-sua-importancia-no-
ambito-empresarial/>, 2010. Acesso 05 julho 2012.
MADEIRA, D. Computação forense com o Sleuth Kit e Autopsy. Site de Daniel Madeira. Disponível em http://dan-
scientia.blogspot.com.br/2010/10/computacao-forense-com-o-sleuth-kit-e.html. Acesso em 06 agosto 2012.
MELO, S. Computação forense com software livre. Rio de Janeiro: Alta Books, 2009.
NBR ISO/IEC 17799 – Tecnologia da Informação. Código de Prática para Gestão da Segurança da Informação.
Associação Brasileira de Normas Técnicas. Rio de Janeiro, 2003.
PALMER, G. and Corporation, M. A road map for digital forensic research. Technical report, 2001.
PEREIRA, E. Investigação Digital: conceitos, ferramentas e estudos de caso. Disponível
em:<http://www.infobrasil.inf.br/userfiles/26-05-S5-2-68766-InvestigacaoDigital.pdf> Acesso em 12 novembro
2012.
PEREIRA, E; Fagundes, L., Neukamp, Paulo, LUDWIG, Glauco, KONRATH, Marlom. Forense Computacional:
fundamentos, tecnologias e desafios atuais. 2010. Disponível em
<http://www.dainf.ct.utfpr.edu.br/~maziero/lib/exe/fetch.php/ceseg:2007-sbseg-mc1.pdf> Acesso em 12 novembro
2012.
QUEIROZ, C.; V. Insvetigação e Perícia Forense Computacional: certificações, Leis processuais e estudos de caso. Rio
de Janeiro: Brasport, 2010.
SILVA, P. Onde deveria começar em uma investigação: cadeia de custódia. Disponível em:<
http://blog.prenato.com/2010/03/onde-deveria-comecar-em-uma.html> Acesso em 09 de setembro 2012.
PERON, A.; Deus, F.; Júnior, R.. Ferramentas e Metodologia para Simplificar Investigações Criminais Utilizando
Interceptação Telemática. Proceeding in Sixth International Conference on Forensic Computer Science, ICoFCS
2011.

126
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

SEGURANÇA DA INFORMAÇÃO: UMA INVESTIGAÇÃO

NA PERSPECTIVA DO USUÁRIO DE SISTEMAS DE
INFORMAÇÃO CORPORATIVOS EM UMA
ORGANIZAÇÃO DE SAÚDE

Luciana Emirena dos Santos Carneiro e Maurício Barcellos Almeida

Escola da Ciência da Informação, Universidade Federal de Minas Gerais
Avenida Antônio Carlos, 6627 – Campus Pampulha – Belo Horizonte - MG

RESUMO
Questões que envolvem Segurança da Informação sempre estiveram dentre as preocupações das organizações. Com o
advento da Internet, a disseminação da informação foi amplamente incrementada. Sistemas de informação que antes
trabalhavam isoladamente passaram a se comunicar facilmente com outras organizações, como por exemplo, sistemas de
informação de parceiros comerciais ou do governo. Essa facilidade de comunicação e disseminação da informação trouxe
benefícios, mas tem exigido novas estratégias para lidar a questão da segurança da informação. No presente artigo,
propõe-se uma investigação sobre segurança da informação do ponto de vista da percepção do usuário de sistemas de
informação corporativos. Apresentam-se resultados de pesquisa qualitativa realizada em organização da área de saúde e
discute-se a relação entre o elemento humano e a segurança da informação no contexto organizacional. Espera-se que
esse trabalho promova melhor entendimento de questões que permeiam a segurança da informação, não apenas do ponto
de vista tecnológico, mas a partir do ponto de vista das falhas causadas por pessoas.

PALAVRAS-CHAVE
Segurança da Informação; Comportamento Informacional; Gestão da Informação

1. INTRODUÇÃO
A disponibilidade da informação é um atributo da Sociedade da Informação, que traz consigo inúmeros
benefícios e grandes preocupações, como por exemplo, a necessidade segurança dos ativos informacionais.
A evolução dos sistemas de informação possibilitaram às empresas ganhos com mobilidade, inteligência e
real capacidade de gestão. O aumento da competitividade e da descentralização promovido pelos avanços
tecnológicos gera a necessidade de gestão, controle, segurança da informação e a proteção do conhecimento
crítico (Sianes, 2005). As empresas demandaram por tecnologias que garantissem aos seus negócios a
confidencialidade, integridade e disponibilidade, fazendo com que a segurança da informação passasse a ser
uma estratégia de gestão da informação (Wylder, 2004; Koskosas, Charitoudi & Louta, 2008; Kraemer,
Carayon & Clem, 2009; Ghernaouti-Helie, 2009; Colwill, 2010).
Na atualidade, os investimentos em segurança da informação são crescentes, como de fato as tecnologias
da informação conseguem solucionar parte do problema diminuindo as ameaças físicas ou virtuais frente a
pessoas ou informações que estas possuem. Almeida (2007) ratifica esse posicionamento, afirmando que a
expressão “segurança da informação” representa um conceito amplo que, geralmente, nas empresas e
instituições, está associada a sistemas informatizados e aos dados que estes manipulam.
Em contrapartida observa-se que por mais investimentos que se faça em segurança, se o elemento
humano não for devidamente considerado, falhas de segurança ocorrerão (Colwill, 2010). Solms (2008)
ressalta que qualquer investimento em tecnologia não terá a eficiência esperada se os usuários não obtiverem
uma consciência de Segurança Informacional. Nesse sentido, busca-se nesse artigo mudar o viés de análise
em relação às pesquisas que enfatizam aspectos tecnológicos da segurança da informação, focando na
subjetividade inerente aos seres humanos, suas relações e seu comportamento informacional nas
organizações. O problema de pesquisa aqui delineado diz respeito a como os incidentes de segurança da

127
ISBN: 978-972-8939-96-0 © 2013 IADIS

informação envolvem pessoas. Apresentam-se resultados de pesquisa conduzida em organização de saúde

brasileira, a qual lida com dados confidenciais de clientes. Buscou-se entender qual é a percepção dos
usuários de sistemas de informação em relação à segurança da informação e em relação ao tipo de falha que
podem causar, independentemente de ações de cunho tecnológico. Espera-se identificar potenciais falhas de
segurança da informação ocasionadas por pessoas para explorar as circunstâncias nas quais esses incidentes
de segurança ocorrem e, consequentemente, poder reduzir custos financeiros com a perda de informações
sigilosas, ganhar competitividade, além de reduzir ameaças, vulnerabilidade e riscos nas empresas.
O restante do presente artigo está organizado conforme segue. Na seção 2 apresenta-se uma breve revisão
de literatura que discute as várias facetas da segurança da informação no contexto organizacional. Na seção
3, após uma breve descrição da pesquisa realizada, apresentam-se e discutem-se os principais resultados
obtidos de pesquisa sobre segurança em organização de saúde. Finalmente, a seção 4 traz conclusões e
perspectivas de trabalhos futuros.

2. SEGURANÇA DA INFORMAÇÃO E TECNOLOGIA: PERSPECTIVAS

No âmbito e na variedade dos sistemas de informação é que a informação é processada no ambiente
organizacional.
O propósito de um sistema de informação, segundo Buckland (1991), é esclarecer os questionamentos
que venham a surgir e despertar a curiosidade. Um sistema de informação é um recurso para a investigação e
um veículo para procurar informar pessoas sobre determinado assunto. Por esse motivo, um sistema de
informação é proposital. Dependendo do valor de cada usuário, pode-se concordar ou discordar com um
determinado propósito, mas os serviços de informações são baseados em um tipo de escopo mesmo que eles
sejam caracterizados como partidários, altruístas, frívolos ou ineficazes. A característica de uma gestão eficaz
de um sistema de informação é o esforço contínuo para tornar os recursos de informação disponíveis no
momento e no local nos quais forem necessários.
Nesse sentido, é importante destacar que a necessidade e uso da informação são determinados pelo
usuário e ele utiliza os sistemas de informação para satisfazer suas necessidades informacionais. O ato de
informar, segundo Allen (1996), envolve tanto uma atividade realizada quanto um processo vivenciado por
alguém. Sendo que, na perspectiva do usuário, a informação é algo que acontece com este usuário, ou seja,
pessoas se informam ou informam alguém.
Complementar a essa abordagem, destaca-se a contribuição de Ingwersen (1992) que coloca que o
conceito de informação deve incluir o processo no qual o conhecimento do informante é transformado pelo
ato da comunicação e, da parte de quem busca a informação, o conhecimento é transformado pelo processo
de percepção, avaliação, interpretação e aprendizado.
As duas perspectivas apontadas são arcabouço para discutir a definição de sistemas de informação
apontada pelos dois autores Buckland (1991) e Allen (1996). O primeiro aponta que os sistemas de
informação usados por seres humanos são sistemas abertos e complexos, que interagem com outros sistemas
de informação ao redor do mundo. Adicionalmente, outro aspecto importante e relevante é o fato desses
sistemas terem habilidade de responder a mudanças, de adaptar seus ambientes e manter a estabilidade para
sobreviver. Já o segundo autor destaca os sistemas de informação como a junção de um ou mais dispositivos
de informação que promovem acesso a um ou mais repositórios de conhecimento, além de se constituírem de
ações através de mecanismos nos quais pessoas podem informar outras ou se informarem.
Efetivamente, trata-se de definições complementares, uma vez que apontam abordagens concernentes ao
ambiente e seu dinamismo no mundo globalizado, aos usuários, suas necessidades e possibilidade de acesso a
informações através das tecnologias num curto espaço de tempo e, por último, às informações que se
confirmam como ativo de valor, sendo artefato de busca dos usuários e item de ação por parte das
tecnologias.
Complementar a essa visão, Marchionini (1998) ressalta que infraestruturas de informação se
desenvolvem à medida que os usuários da informação ganham conhecimento acerca dos fatores condutores
da busca de informações e também das habilidades para gerenciar esse processo de busca informacional.
Desta forma, entender qual o conhecimento e as habilidades necessárias em ambientes manuais e eletrônicos
levará a melhores projetos para futuros sistemas de informação e melhores treinamentos, tanto para
profissionais quanto para usuários.

128
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

As reflexões sobre o elemento sistemas de informação e as variantes que o compõem apontam para o
paradigma da tecnologia da informação que contextualiza a sociedade da informação e as empresas como
parte da sociedade, sob a perspectiva tecnológica. Nesse sentido, Castells (2000) aponta que as tecnologias
são desenvolvidas para agir sobre a informação e que essa informação é elemento presente tanto no contexto
coletivo quanto individual, sendo moldado pelo blogs, facebook, twitter, youtube novo meio tecnológico.
Esse novo meio tecnológico traz consigo a lógica das redes como fator unificador de sistemas ou conjunto de
relações, sendo preponderantemente flexível. Essa característica de flexibilidade e sistematização em redes
propicia a convergência das tecnologias para um sistema integrado e global.
As características de flexibilidade e de integração das informações em sistemas globais apontam para uma
mudança de costume dos indivíduos. As pessoas demandam por tecnologias e essas tecnologias passam a
ficar cada vez mais presentes na vida dos cidadãos. Nesse sentido, as novas tecnologias vêm mudando as
atitudes sociais, tornando os dados e comunicações móveis cada vez mais disponíveis e de fácil uso.
Por isso, é importante entender o conceito de tecnologia da informação. A técnica denota o caminho de
como fazer algo e a tecnologia pode ser descrita como o recurso físico que serve como ferramenta para
realizar algo. Assim, as tecnologias da informação podem ser delineadas como aquelas utilizadas para
“manejar” a informação (Buckland, 1991).
A totalidade desta conjuntura faz perceber a incontestável relação entre tecnologia e sociedade.
Entretanto, é respeitável perceber, através da análise pela ótica dos recursos humanos no âmbito dos sistemas,
redes e tecnologias da informação, que a tecnologia é projetada uma vez que é implementada e operada por
pessoas. Assim, é o fator humano que determina as formas como usamos sistemas de informação ou o uso
indevido destes (Lacey, 2009).
Analogamente, faz-se notar que os sistemas de segurança da informação são desenvolvidos visando
minimizar riscos decorrentes de acesso não autorizado e posse de informação e, nessa perspectiva na qual o
ativo são os dados, a estratégia é garantir às bases de dados segurança através dos critérios de integridade,
confidencialidade e autenticidade (Koskosas, Charitoudi & Louta, 2008).
Os autores Sveen, Torres & Sariegi (2009) esclarecem que controles técnicos são ferramentas de
hardware e software, tais como dispositivos biométricos, bloqueios, software antivírus, firewalls etc. que
restringem o acesso a prédios, sistemas de computador, programas e etc. a fim de evitar seu uso indevido. Já
Colwill (2010) contribui trazendo uma especificação dos controles técnicos contra invasores não somente
externos, mas também internos à empresa, e diz que estes devem incluir, minimamente, criptografia, controle
de acesso, privilégio mínimo, acompanhamento, auditoria e relatórios. Já Kraemer, Carayon & Clem (2009)
enfatizam a utilização de métodos específicos de segurança da informação, como os smart cards, dispositivos
biométricos, software de criptografia PGP 5.0, senhas, segurança nos navegadores web básico, indicadores de
identificação, análise das aplicações de desktop, tais como o Word 2007 e Internet Explorer.
Hoje em dia, as pessoas usufruem dos benefícios do uso de computadores e da Internet para a
comunicação e para fazer negócios. Por isso, o problema da segurança da informação está se tornando cada
vez mais relevante (Huang, Rau & Salvendy, 2010). Muitas abordagens foram desenvolvidas para auxiliar
na gestão da segurança da informação e na limitação de ocorrências de incidentes e violação de segurança.
A maioria dos controles desenvolvidos implica em check lists, análise de risco, avaliação e métodos.
Entretanto, há a necessidade de se questionar essas abordagens com foco estreito, soluções tecnicamente
orientadas que ignoram os aspectos sociais dos riscos e da estrutura informal de organizações (Koskosas,
Charitoudi & Louta, 2008). Apesar de toda evolução nos controles técnicos, promovida por mudanças
tecnológicas constantes, as organizações devem ter em mente que sua maior vulnerabilidade é seu
colaborador, por isso as empresas devem enfocar os fatores humanos, suas percepções e expectativas, em
detrimento da objetividade inerente à tecnologia (Colwill, 2010).
Nessa vertente, Koskosas, Charitoudi & Louta (2008) ressaltam a importância dos cursos de educação e
formação de membros para adequada percepção dos riscos em matéria de segurança e pontuam que esta
percepção reflete no sucesso global dos projetos de segurança de informação em sistemas. Compartilhamento
de informações e experiências sobre o tema segurança também foram ressaltados e os autores concluem
enfatizando que cultura e estabelecimento de metas são inter-relacionados e podem ter um efeito sobre
sistemas na gestão de segurança da informação.
A ameaça dos empregados por negligência ou ignorância frente a questões de segurança é susceptível de
ser exacerbada quando as pessoas fundem trabalho e vida pessoal. O Centro Nacional de Computação afirma
que os indivíduos têm dificuldade em ter uma verdadeira fronteira entre o trabalho e a vida pessoal e que eles
gastam tempo compartilhando informações pessoais e profissionais em sites e redes sociais com a "inocência

129
ISBN: 978-972-8939-96-0 © 2013 IADIS

e confiança". Esta constatação deixa o colaborador e, consequentemente, a organização abertos a uma gama
de downloads de pornografia e música e a uma variedade de ataques de malware. Existe uma crescente
pressão sobre as empresas para dar liberdade maior aos colaboradores, entretanto essa medida precisa do
aparato tecnológico apoiado a regras claras e regulamentos definidos para prevenir uma descida ao caos
(Colwill, 2010).
Um ponto interessante constatado na pesquisa de Colwill (2010) são as falhas de segurança geradas pelo
uso de dispositivos de dados portáteis por parte dos “insiders” da organização, facilitando assim o
comprometimento da informação da organização. Fazendo uma leitura da pesquisa de Kavanagh (2006),
Colwill (2010) observou que 89% dos trabalhadores usavam dispositivos portáteis de cunho pessoal na rede
das empresas nas quais trabalhavam pelo menos uma vez por semana e que mais da metade das empresas
pesquisadas do Reino Unido não tinham controles para gerenciar o uso de dispositivos de mídia removível.
Paralelamente, pessoas que trabalhavam em uma empresa financeira em Londres carregavam livremente CDs
nos sistemas da empresa apesar das orientações e advertências. O fato é que a política de segurança, os
controles, as orientações e os treinamentos não recebem prioridade de ação, alteração e atualização por parte
das empresas.
Através da gestão da segurança, vê-se que as atuais abordagens gerenciais não atendem requisitos de
transparência e controle de segurança. Fica a necessidade das tecnologias serem menos vulneráveis para
diminuir o número de potenciais ameaças que podem ser desenvolvidas (Ghernaouti-Helie, 2009) e,
paralelamente, vale ressaltar a necessidade de uma conscientização prévia sobre questões da segurança da
informação, uma vez que se constatou que a referida “consciência” sobre questão de segurança da
informação, na maioria dos casos, não ocorreu com a introdução de novas tecnologias, mas sim através de
incidentes vivenciados após a sua introdução (Sveen, Torres & Sariegi, 2009). Conforme afirmam Kraemer,
Carayon & Clem (2009), a tecnologia e segurança da informação têm se concentrado em soluções
tecnológicas para evitar vulnerabilidades e ataques, entretanto essas áreas precisam se relacionar, através de
uma abordagem sócio-técnica, com aspectos humanos e organizacionais, uma vez que estes corroborarão
diretamente na eficácia de outros sistemas críticos, tais como segurança e redução de incidentes.

3. MÉTODOS E RESULTADOS
Buscando entender a interferência do elemento humano na segurança da informação, uma pesquisa foi
realizada em uma organização privada brasileira na área de saúde do estado de Minas Gerais, localizada na
cidade de Belo Horizonte (o nome não será divulgado a pedido da instituição). A população-alvo desta
pesquisa foi constituída pelos funcionários do setor de tecnologia da informação da instituição.
Trata-se de uma pesquisa quali-quantitativa e exploratória, cujos meios de investigação são a pesquisa de
campo e o estudo de caso. No que concerne ao raciocínio lógico empregado na pesquisa, ele pode ser
caracterizado como dedutivo.
Desenvolveu-se um questionário estruturado com base em um conjunto de variáveis que compõe cada
arena – pessoas, processos e tecnologias previamente levantadas na literatura. Esse instrumento quantitativo
foi aplicado através de link encaminhado ao e-mail dos colaboradores componentes da amostra por
conveniência, na instituição pesquisada. Foram obtidas 35 respostas ao questionário, sem identificação do
respondente, que foram armazenadas no site http://www.kwiksurveys.com/, ao qual somente o pesquisador
teve acesso. Ressalva-se que os instrumentos tiveram como característica o anonimato, de modo que não se
corresse o risco de obter uma análise individual do colaborador que venha a prejudicá-lo, no sentido de
sanções e/ou mesmo demissões. Outra característica importante foi a não interferência do pesquisador na
condução das perguntas junto aos respondentes.
O instrumento quantitativo de coleta de dados denominado questionário, foi estruturado em duas partes.
A primeira com o objetivo de obter o perfil do entrevistado, com relação ao sexo e escolaridade. A segunda
parte, composta por 49 afirmativas, seguiu uma estrutura matricial com uma escala tipo Likert (Likert, 1932).
A escala de Likert é uma escala de mensuração itemizada, também denominada de “escala multi-itens”.
Exige que os entrevistadores indiquem um grau de concordância ou discordância com cada uma de uma série
de afirmações. Os dados geralmente são tratados como intervalares, assim, a escala Likert possui as
características de descrição, ordem e distância (Malhotra, 2012). É importante salientar que, neste trabalho,
optou-se por trabalhar com quatro itens, sem ponto neutro, sendo: (1) Discordo totalmente, (2) Discordo

130
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

parcialmente, (3) Concordo parcialmente, e, por fim, (4) Concordo totalmente. A escala utilizada, segundo
categorização de Malhotra (2012) pode ser classificada como balanceada, pois apresenta número igual de
categorias favoráveis e desfavoráveis e forçada, pois os entrevistados foram forçados a emitir uma opinião,
não havendo a posição neutra, ou seja, para cada afirmativa, o respondente tinha necessariamente que
discordar ou concordar.
Cabe esclarecer que a pesquisa foi planejada como pesquisa quantitativa, o que explica o uso de variáveis
estatísticas na descrição da pesquisa. Entretanto pela dificuldade em conseguir, nessa etapa da pesquisa, uma
amostra de significância quantitativa, optou-se por apresentar análises de natureza qualitativa.
No restante da presente seção, apresentam-se os resultados conclusivos obtidos, além de inferências sobre
esses resultados que nos permitiram visualizar os cenários de utilidade no contexto da segurança da
informação organizacional. Propõem-se então cruzar as respostas das perguntas do instrumento de coleta de
dados primários e fazer análises.
A primeira parte do questionário continha questões relativas ao entendimento do colaborador sobre o
significado de segurança da informação e, na sequência, seu sentimento como forma de se reconhecer como
parte responsável pela segurança da informação na instituição pesquisada. As respostas para esses dois
questionamentos receberam 100% de concordância total da parte dos participantes. Destarte, a discrepância
começa a aparecer quando os colaboradores são questionados sobre suas capacidades de identificar as atuais
medidas que estão sendo tomadas em relação à segurança da informação na instituição, quando questionados
sobre as atuais medidas que estão sendo tomadas em relação à segurança informacional na instituição na
qual o participante trabalha, 57% afirmam que conseguem identificar essas medidas e 43% afirmam que não
conseguem identificar essas medidas. A partir desse resultado, cabe uma análise: como entender o que é
segurança da informação e se sentir parte dela sem haver uma maioria expressiva que compreende as ações
que estão sendo desenvolvidas pela empresa como corroborativas à gestão de segurança informacional na
organização na qual trabalham?
Buscando entender com clareza como os colaboradores compreendem seu papel na segurança
informacional da empresa, os novos dados obtidos indicam que pouco mais da metade dos respondentes
(55%) concordam que sabem com clareza qual é o seu papel, embora 34% deste total concordam
parcialmente com a afirmativa, ou seja, em mais da metade dos concordantes ainda há dúvidas.
Doravante, quando questionados sobre os responsáveis pela segurança informacional da empresa, 77%
sabem quem são essas pessoas, sendo que 51% sabem com total certeza (concordo totalmente).
Complementar a essa reflexão está o fato de que 43% dos respondentes concordam que a segurança da
informação é responsabilidade do setor de tecnologia da informação e 57% discordam da afirmativa.
Nota-se que um número muito alto de pessoas acredita na abordagem técnica às questões de segurança da
informação e talvez seja esse um dos motivos pelos quais os colaboradores não consigam identificar com
clareza seu papel na segurança informacional da organização. Apesar de saberem com lucidez quem são os
responsáveis pela segurança informacional corporativa, eles não conhecem com a mesma transparência as
atuais medidas em vigor na instituição no que concerne à segurança da informação.
Um cenário com forte fundamentação na abordagem tecnológica não poderia ter outro resultado, ou seja,
pessoas se estruturando totalmente nas tecnologias e fazendo delas a solução cômoda para todos os
problemas de insegurança informacional.
Avaliando um pouco mais a fundo a percepção dos colaboradores com relação aos investimentos que são
feitos pela empresa, sendo um montante maior para tecnologias e menor para treinamentos de pessoas no que
concerne à segurança da informação corporativa, os resultados demonstraram que 80% dos entrevistados,
têm a percepção de que a instituição investe mais em tecnologias do que em pessoas para garantir a
segurança da informação empresarial. Quando são questionados se são treinados para terem um
comportamento seguro, mais de 65% dos respondentes afirmam que não, observando-se que 50% deles tem
total segurança de sua resposta (discordo totalmente). Esse parecer vem a se ratificar um pouco mais à frente
no questionário, quando se pergunta aos colaboradores se existem na instituição programas de educação para
formar pessoas, no que concerne à segurança da informação e 77% dos respondentes afirmam que não. Outro
ponto importante de se mencionar é que 45% dos respondentes discordaram totalmente da afirmativa,
ratificando que na organização não se investe na formação do colaborador sob o aspecto da segurança
informacional.
Respectivamente, quando os participantes foram questionados se as ações de segurança da informação na
instituição geram conhecimento e promovem o aprendizado, e, se ocorrem interações sociais entre eles e
demais colaboradores para discutir temas sobre segurança da informação, as respostas obtidas destacam mais

131
ISBN: 978-972-8939-96-0 © 2013 IADIS

de 90% de discordância, nenhuma resposta que concordasse totalmente e pouco mais de 8% que concordam
parcialmente, levando os pesquisadores a traçar um cenário no qual quase nunca ocorrem interações sociais
com o objetivo de discutir a temática segurança da informação, ou seja, a instituição não tem aproveitado as
ocorrências (ou fatos) do dia-a-dia para discutir de forma integrativa ações de segurança informacional.
O primeiro fator direcionador de comportamento seguro é entender se os colaboradores conhecem e
compreendem as políticas, procedimentos, normas e diretrizes de segurança da informação adotadas pela
instituição. Os dados obtidos com a aplicação do instrumento de coleta de dados demonstram um equilíbrio
muito grande entre concordâncias (51%) e discordâncias (48%), sendo que quando os dados são desdobrados,
observa-se que os maiores percentuais estão em concordo parcialmente (40%) e discordo parcialmente
(31%). Outro ponto interessante é que, apesar de todo o cenário traçado até agora no que concerne à
segurança da informação e sua aplicação nas políticas de segurança informacional da instituição pesquisada,
77% das respostas obtidas indicam que os colaboradores têm consciência que devem cumprir todas as
políticas de segurança da informação instituídas e não escolher algumas ou as que consideram mais fáceis
para cumprir. Entretanto, apesar da existência de uma política determinando a necessidade de se fazer
backups frequentes dos dados e informações contidos em máquinas e equipamentos, quando questionados
sobre a existência de orientação ou obrigação para fazer back-ups diários das informações processas pelo
usuário, 74% dos respondentes discordam da afirmativa, ou seja, não se sentem orientados e nem obrigados a
fazer backups. Mais um elemento que indica a necessidade de equilíbrio de investimentos da organização
entre as variáveis, recursos humanos, políticas e procedimentos, e, tecnologias da empresa. De que adianta
investir maciçamente em tecnologias se o usuário permitir a entrada de um desconhecido nas bases de dados
da empresa? Como equalizar o progresso na segurança tecnológica se os usuários não fazem backups?
Mesmo diante de uma fortaleza tecnológica digital e física, os seres humanos continuam sendo uma
vulnerabilidade em potencial, haja vista que eles transformam os dados e informações e não estão preparados
para agir, efetivamente, com a proteção dos ativos informacionais da empresa.
Acredita-se que um dos caminhos, diante desse cenário, seja olhar para pessoas, processos e tecnologias
de forma equitativa e equilibrada.
A dúvida sobre o desenvolvimento da gestão de segurança informacional equitativa entre os pilares
pessoas, processos e tecnologias, se confirma quando 60% dos respondentes concordam parcialmente, que o
desenvolvimento da segurança da informação na instituição na qual trabalham inclui proteção de hardware,
software, pessoas e processos, contra ameaças e vulnerabilidades presentes no ambiente corporativo, sejam
elas internas e/ou externas à organização.
Os incidentes de segurança da informação podem ser derivados de invasões na máquina ou equipamento
no qual se processa as informações, contudo, muitas das vezes essa invasão tem a permissão, intencional ou
não, do usuário. Observa-se que 89% discordam que postem em redes sociais fatos ou ocorrências que
acontecem na organização ou no setor para alertar amigos. Não obstante, 9% dos respondentes afirmaram
que fazem essas postagens. Percebe-se que, por falta de definição do comportamento que a empresa espera
do colaborador em relação à segurança da informação, algumas informações relevantes ou estratégicas de
fragilidade do sistema da empresa podem estar sendo compartilhadas com pessoas estranhas ao ambiente
institucional, gerando verdadeiras ameaças aos ativos informacionais da empresa.
Outro ponto importante de se mencionar é o déficit comunicacional da empresa, no que concerne às
informações sobre segurança informacional. Assim, quando questionados se os colaboradores ficam cientes
de todas as atualizações de avaliação de riscos de seu departamento, setor ou área, identificou-se uma
deficiência na comunicação entre empresa e trabalhadores, uma vez que menos da metade dos trabalhadores
afirmaram ter ciência de todas as atualizações de avaliação de riscos de seu departamento, setor ou área,
ratificando que os colaboradores constantes nessa amostra trabalham no setor de tecnologia da informação
que é responsável pela segurança das informações da organização pesquisada.
Apesar desse cenário de valorização da tecnologia e de desfavorecimento do elemento humano, nota-se
que 65% dos respondentes têm interesses em absorver os valores, missão e visão da empresa para a qual
trabalham, contra 35% que concordaram que, em primeiro lugar, dedicam atenção à sua profissão e à
especialidade do computador com o qual trabalham, para depois absorver os valores, missão e visão da
empresa. Esse cenário demonstra que se deve dedicar especial atenção a esse fator, uma vez que 72% dos
respondentes concordaram ou discordaram parcialmente da afirmativa, demonstrando dúvidas com relação a
suas respostas, podendo ser este um indicativo que o elemento pessoas precisa de atenção devida para que
haja efetividade nas ações de segurança da informação da instituição.

132
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Complementar a essa visão, apesar de 63% dos respondentes considerarem que o ambiente da empresa é
seguro no que concerne às informações que nele são processadas, entretanto, 9% dos respondentes sentem
vontade de explorar redes, invalidar códigos de segurança e desafiar os profissionais de segurança para
mostrar o quão frágil é a segurança da informação da instituição. Já 58% dos respondentes se sentem
prejudicados pela alta carga de trabalho imposta pela instituição, indicando que esse fator os prejudica com
relação à percepção e ações relativas à segurança da informação.
Com relação ao fato da instituição permitir o acesso à rede corporativa, para gravar dados em pen-drives,
CD´s, DVD´s e/ou imprimir informações para uso tanto no ambiente institucional quanto em casa, 80% dos
respondentes discordaram enfatizando que essas não são ações permitidas. Os mesmos 80% dos respondentes
observam, ao utilizar o e-mail corporativo, a supressão de mensagens que possuem anexos não solicitados.
Concomitante, não há acesso irrestrito a sites de acordo com 80% dos respondentes e nem permissão de
acesso remoto a sistemas de informação corporativos, de acordo com 75% dos respondentes.
Vinculando a parte tecnológica com as políticas de segurança da informação da empresa observa-se,
conforme afirmam 77% dos respondentes, que não existe um check list de segurança informacional que os
colaboradores devem seguir no seu dia-a-dia. Já com relação à alteração mensal das senhas de acesso aos
recursos corporativos, 65% dos respondentes concordam que a senha de acesso deve ser modificada
mensalmente, todavia, observa-se que se trata de uma concordância parcial, haja vista que o maior
percentual, 37% concordantes, não tem total certeza sobre esse assunto.

4. CONCLUSÕES
Através da avaliação descritiva dos dados e da discussão dos resultados, pode-se concluir que o elemento
pessoas é uma variável crítica na gestão de segurança informacional corporativa. As políticas de informação
devem ser acessíveis aos funcionários e factíveis de serem executadas. Com relação à tecnologia, é válido
que continuem os investimentos, entretanto eles devem ser equilibrados com o desenvolvimento de controles
informais (pessoas) e controles formais (políticas e processos) para que haja uma gestão de segurança
informacional mais efetiva e eficaz.
Dos resultados apresentados na seção 3, reúnem-se aqui, a título de resumo, impressões obtidas através da


pesquisa, as quais caracterizam a segurança da informação do ponto de vista do usuário.
Os colaboradores em geral acreditam que todos na organização entendem o que é segurança da


informação e, conseguem identificar quais são as medidas de segurança da informação corporativa adotadas;
Há duvidas entre uma boa parte dos colaboradores sobre o seu papel em segurança da informação,


apesar de saberem identificar quem são os responsáveis pela segurança da informação na organização;
Metade deles acredita que segurança da informação é assunto apenas para os responsáveis pela


tecnologia da informação;
A grande maioria dos colaboradores têm a percepção de que a instituição investe mais em
tecnologias do que em pessoas para garantir a segurança da informação, e, acreditam que não há investimento


suficiente na formação das pessoas no âmbito da segurança informacional;
A grande maioria não identifica a existência de fórum, no âmbito da organização, apropriado para


discutir a temática segurança da informação;
Menos da metade dos colaboradores admitem conhecer e compreender políticas, procedimentos,
normas e diretrizes de segurança da informação adotadas pela instituição; paradoxalmente, a maioria afirma
que se sente obrigado cumprir as políticas de segurança da informação instituídas (mesmo considerando que


não as entendem);
A quase totalidade dos respondentes relata não postar informações sobre a organização em redes


sociais e que, se o fazem, não incorrem em riscos de segurança;
Grande maioria dos respondentes acredita na necessidade de considerar o elemento pessoas para que


haja efetividade nas ações de segurança da informação;
A maioria dos colaboradores reporta a falta de um check list de segurança para orientação.
Ao se fazer uma leitura dos dados obtidos com a pesquisa, observa-se que tratar as questões de segurança
informacional nas empresas requer ações em diversos campos. Entretanto, nem sempre as empresas possuem
recursos para investir em soluções para todos os gargalos. Nesse sentido, há a necessidade de uma avaliação
do cenário de segurança informacional corporativo, delimitando através dos pilares pessoas, processos e/ou

133
ISBN: 978-972-8939-96-0 © 2013 IADIS

tecnologias aquele que é mais crítico para a empresa. O plano de ação será traçado a partir desse panorama.
As próprias perguntas apontarão para possíveis restrições, e, paralelamente para mecanismos de ação.
Conclui-se ainda que a inter-relação entre o usuário da informação e a segurança informacional
institucional deve ser monitorada constantemente, para que se consiga agir antecipadamente frente à
dinâmica dos incidentes de segurança. Como demonstrado na pesquisa de campo, uma das formas de se
checar e controlar essa inter-relação é através da medição constante das ações de segurança informacional
implementadas e a reação dos colaboradores frente a elas. Essa medição mostrará o cenário da instituição e
que ajudará as organizações a se prevenir dos incidentes de segurança informacional sistemicamente.
Uma conclusão clara da pesquisa espelhada nas respostas dos funcionários, é que o tema segurança da
informação ainda é controverso, e muitas vezes confundido com uma abordagem puramente tecnológica. O
experimento testou a metodologia proposta, através de sua aplicação a um contexto específico. A amostra
utilizada para o experimento não é passível de gerar capacidade de generalização dos resultados obtidos
através de uma abordagem quantitativa, apesar de atender estatisticamente aos quesitos confiabilidade e
validação de conteúdo . Espera-se propor o teste com amostra representativa junto a empresas e usuários que
atenda a critérios estatísticos em trabalhos futuros de forma que tal amostra seja suficiente para determinar a
capacidade de generalização do questionário. Mesmo assim, como a nascer um entendimento que o elemento
pessoas é essencial para uma boa gestão de segurança informacional e desenvolvimento de políticas bem
sucedidas.

REFERÊNCIAS
Allen, B. L. Information Tasks: Toward a User-centered approach to information systems. California,USA, A.P.,1996.
Almeida, M. B. Aplicação de Ontologias em Segurança da Informação. Revista Fonte. Ed.Fonte, Belo Horizonte: 2007.
Buckland, M. Information as a thing. Journal of American Society for Information Science, 1991, v. 42, n. 5, p. 351-360.
Castells, M. The Rise of the Network Society. New York: Wiley-Blackwell, 2000.
Colwill, C. R. Human factors in information security: The insider threat & Who can you trust these days? Information
Security Technical Report, 2010, p. 01-11.
Ghernaouti-Hélie, S. An inclusive information society needs a global approach of information security. International
Conference on Availability, Reliability and Security. Computer Society, 2009.
Huang, D. L., Rau, P. L. P. and Salvendy, G. Perception of information security. Behavior & Information Technology,
2010. v.29, n.3, p. 221- 232.
Ingwersen, P. The cognitive view and information. In: ______. Information retrieval interaction. London: Taylor
Graham Publishing, 1992. Chapter 2. Disponível em: <http://vip.db.dk/pi/iri/files/Ingwersen_IRI_Chapter2.pdf>.
Acesso em: 8 mar. 2010.
Koskosas, I. V., Charitoudi, G. and Louta, M. The role of organizational cultures in information-systems security
management. Journal of Leadership Studies. Spring, 2008. v.2, issue 1, p.7–17.
Kraemer, S., Carayon, P. and Clem, J. Human and organizational factors in computer and information security. Computer
& Security. 2009. v.28, p. 509-520.
Lacey, D. Managing the human factor in information security. Wiley. 2009.
Likert, R. A Technique for the Measurement of Attitudes. Archives of Psychology, 1932. V.140, p.1–55.
Malhotra, N. K. Pesquisa de Marketing: Uma Orientação Aplicada, Porto Alegre: Bookman, 2012, 4a edição.
Marchionini, G. Digital Library Research and Development. Enc. of Library and Information Science, 1998, v.63
Sianes, M. Compartilhar ou proteger conhecimentos? Grande desafio no comportamento informacional das organizações.
In: Gestão Estratégica da Informação e Inteligência Competitiva. São Paulo: Saraiva, 2005.
Solms, R. V. Information security governance. South Africa, Springer, 2008.
Sveen, F.O., Torres, J.M. and Sarriegi, J.M. Blind Information Security Strategy. International Journal of Critical
infrastructure Protection, v.2, 2009, p.95-109
Wylder, J. Strategic Information Security. [s.l.]: Auerbach Publications, 2004.

134
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

BUSCA EXPLORATÓRIA: UM ESTUDO DE CASO SOBRE

DESENVOLVIMENTO E AVALIAÇÃO DE UM SISTEMA

Deyvid Heric de Moraes1, Luciano Tadeu Esteves Pansanato1,

Douglas Felipe Pereira1 e Diogo Arenhart Marinho2
1
Universidade Tecnológica Federal do Paraná – UTFPR
Av. Alberto Carazzai, 1640, 86300-000 Cornélio Procópio, PR, Brazil
2
ForLogic Software Ltda., Rua Piauí, 1070, 86.300-000 Cornélio Procópio, PR, Brazil

RESUMO
O desenvolvimento e a avaliação de sistemas de busca exploratória demandam desafios principalmente devido ao nível
de interação do usuário com o sistema. Neste trabalho é apresentado um estudo de caso de desenvolvimento e avaliação
de um sistema de busca exploratória. O estudo de caso inclui aspectos relacionados às funcionalidades principais,
arquitetura do sistema, projeto da interface e avaliação. As informações fornecidas a partir de experiências, como neste
estudo de caso, têm um potencial grande de contribuição para problemas práticos.

PALAVRAS-CHAVE
Sistema de informação; busca de informação; busca; busca exploratória.

1. INTRODUÇÃO
Busca Exploratória (Exploratory Search) é definida como uma classe de atividades mais complexas de busca
em relação à abordagem tradicional de Recuperação de Informação (RI) (Marchionini, 2006). A abordagem
tradicional de RI consiste em obter resultados precisos relacionados às consultas especificadas. Marchionini
(2006) classifica as atividades de busca exploratória em três tipos: busca (lookup), aprendizagem e
investigação. A busca exploratória está relacionada especialmente às atividades de aprendizagem e
investigação, mas a atividade de busca também pode ser empregada. Por exemplo, as atividades de busca
estão geralmente embutidas nas atividades de aprendizagem e investigação.
Os Sistemas de Busca Exploratória têm por objetivo tornar a busca mais efetiva fornecendo uma
variedade de funcionalidades na interface e alterando dinamicamente como os resultados são apresentados
(White et al., 2007; White e Roth, 2009). Alguns sistemas para busca exploratória que podem ser citados
como exemplo são o Flamenco (Yee et al, 2003), para o domínio de imagens de obras de arte, e o mSpace
(Schraefel et al., 2006), para o domínio de música clássica. Esses trabalhos, assim como outros encontrados
na literatura sobre sistemas de busca exploratória, possuem o foco centrado principalmente na interface ao
invés de nos aspectos de desenvolvimento e avaliação.
O objetivo deste trabalho é apresentar um estudo de caso sobre o desenvolvimento e a avaliação de um
sistema de busca exploratória. O objeto do estudo de caso é um sistema de busca exploratória desenvolvido
para um software de gerenciamento de documentos denominado Gestor Eletrônico de Documentos e
informações (GEDi) (Mussi et al., 2009), que é um produto comercializado pela empresa ForLogic Software
Ltda. Assim, o estudo de caso apresentado tem um potencial grande de contribuição para problemas práticos,
uma vez que as informações coletadas são fornecidas a partir de experiências concretas. As lições aprendidas
podem ser úteis em outras situações nas quais seja necessário o desenvolvimento e/ou a avaliação de sistemas
para auxiliar a busca exploratória de informações.

135
ISBN: 978-972-8939-96-0 © 2013 IADIS

2. SISTEMA DE BUSCA EXPLORATÓRIA

O sistema desenvolvido para auxiliar a busca exploratória de informações possui características de sistemas
de busca exploratória descritas por White e Roth (2009): suporte a busca por palavra-chave integrada;
recurso de busca por metadados; suporte à visualização instantânea do conjunto de resultados; recurso para
visualização do histórico e acompanhamento das ações de busca realizadas.
O sistema de busca exploratória foi projetado e desenvolvido com características genéricas e
independência do domínio de aplicação. A coleção de objetos de informação utilizada neste trabalho como
domínio de aplicação é um conjunto de arquivos de música popular brasileira. O uso desse conjunto tem por
objetivo evitar a exposição dos dados reais referentes aos documentos de clientes.
A ideia principal do sistema desenvolvido é que o usuário tem várias funcionalidades de busca à sua
disposição na interface e os resultados são alterados dinamicamente à medida que acontece a interação com o
sistema (White et al., 2007). A dinâmica da interação do usuário com o sistema pode ser assim resumida: o
usuário idealiza e executa uma estratégia de busca, avaliando os resultados encontrados e a estratégia
utilizada, modificando ou não a estratégia adotada até que os objetivos sejam atingidos. A estratégia é o
planejamento do usuário em termos das ações de busca que devem ser executadas no sistema para satisfazer
uma necessidade de informação. Para idealizar a sua estratégia, o usuário pode levar em consideração a
estrutura do espaço de informação (por exemplo, os tipos de objetos de informação disponíveis e como estão
organizados), assim como as funcionalidades disponíveis na interface do sistema.
O sistema desenvolvido possui as seguintes funcionalidades principais para auxiliar a busca exploratória
de informações: histórico das ações de busca; busca por palavra-chave integrada; busca por facetas de
metadados; apresentação dinâmica dos resultados; armazenamento do histórico; e importação dos dados de
objetos de informação. Essas funcionalidades são descritas a seguir para facilitar a compreensão dos aspectos
relacionados à arquitetura e interface.
Histórico das ações de busca. Essa funcionalidade mantém uma representação da sequência de ações de
busca realizadas pelo usuário, isto é, da sua estratégia. A visualização da estratégia utilizada até o momento
auxilia o usuário a manter o processo de busca de informação sob o seu controle e também auxilia na
compreensão de como os resultados foram obtidos. Além disso, se os resultados não são satisfatórios, o
usuário pode utilizar esse histórico para avaliar e reformular a sua estratégia. Ao modificar o histórico, os
resultados automaticamente refletem a nova sequência de ações de busca (resultante) como se fosse aquela a
sequência executada pelo usuário.
Busca por palavra-chave integrada. Uma interface para busca exploratória de informações tem
disponível a busca por palavra-chave para uso a qualquer momento (Hearst et al., 2002). O escopo da busca é
o conjunto atual de resultados (itens) por padrão, embora os usuários possam também escolher realizar a
busca considerando todos os objetos de informação que estão disponíveis por meio da interface. A busca por
palavra-chave integrada tem a função similar a uma máquina de busca (search engine), isto é, a função de
retornar uma lista de referências aos objetos de informação nos quais as palavras-chave especificadas foram
encontradas.
Busca por facetas de metadados. O conceito de facetas de metadados refere-se a um conjunto de rótulos
significativos organizados de modo a refletir um domínio específico (Hearst, 2006). Esses rótulos são
utilizados para referenciar categorias em uma coleção de objetos de informação. A busca por facetas de
metadados tem como função apresentar ao usuário um conjunto de facetas para que este possa filtrar os
objetos de informação por meio da seleção progressiva somente das facetas que possuem itens (objetos de
informação) associados. Os rótulos das facetas apresentam uma indicação da quantidade de itens atualmente
associada a cada uma das facetas. Depois que uma faceta é selecionada, a lista das facetas da interface
também é filtrada para apresentar somente aquelas que possuem itens disponíveis.
Apresentação dinâmica dos resultados. A função é apresentar uma lista dos itens obtidos a partir de uma
ação de busca realizada pelo usuário. Essa lista também pode ser utilizada como base para a execução de
outras ações de busca (search in results). A denominação de dinâmica refere-se à constante atualização da
lista de itens sempre que uma nova ação de busca é realizada ou a sequência no histórico das ações de busca
é alterada.
Armazenamento do histórico. O armazenamento do histórico permite ao usuário salvar a sequência atual
do histórico de ações de busca para repeti-la posteriormente com a finalidade de recuperar novamente os
itens que haviam sido encontrados e também outros itens que porventura passaram a satisfazer as mesmas
condições (por exemplo, itens novos que foram adicionados à coleção). Essa funcionalidade é popularmente
conhecida como pesquisa salva (saved search).

136
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

3. ARQUITETURA
Uma questão de projeto importante relacionada ao desenvolvimento é a definição de uma arquitetura
adequada para sistemas de busca exploratória. Uma das características desses sistemas é o acesso a uma ou
mais fontes de informação que podem estar logicamente inter-relacionadas e distribuídas por uma rede de
computadores. Neste trabalho são descritas duas arquiteturas, apresentadas inicialmente por Pereira e
Pansanato (2012), e o uso de um componente intermediário como parte da arquitetura para o tratamento de
múltiplas fontes de informação.
A organização da arquitetura do sistema é apresentada na Figura 1. O componente “Interface” é
responsável pelos elementos interativos da interface oferecida ao usuário e os componentes “Controle” e
“Engine” são responsáveis, respectivamente, pelo acesso aos Objetos de Informação (Arquivos) referentes ao
domínio de aplicação e pelo acesso ao Servidor (Base de Dados) do sistema. A base de dados mantém as
informações sobre os metadados referentes aos arquivos que podem ser pesquisados a partir do sistema.
Além disso, o subsistema “Engine” também é responsável pela construção das consultas em SQL referentes
às ações de busca realizadas pelo usuário.
O sistema segundo essa arquitetura foi implementado na linguagem C#, que é parte da plataforma .NET,
com o gerenciador de banco de dados SQL Server para o armazenamento da base de dados sobre o conjunto
de arquivos referente ao domínio de aplicação. Nessa versão, o componente “Controle” tem acesso somente
aos objetos armazenados no sistema de arquivos do sistema operacional. No entanto, o “Controle” também
seria responsável pelo acesso a objetos de informação disponíveis na Web ou em um servidor remoto (por
exemplo, através de um web service). O componente “Controle” não faz controle de acesso; ao contrário, a
garantia de que apenas os usuários com as permissões adequadas podem acessar objetos de informação é de
responsabilidade do sistema (ou aplicação) original que mantém o conteúdo. O sistema de busca exploratória
trabalha somente com referências para os objetos de informação.
Uma arquitetura alternativa é mostrada na Figura 4. A principal diferença para a arquitetura apresentada
anteriormente (Figura 1) é a divisão do sistema em duas partes, Cliente e Servidor, e o componente “Engine”
mantido na parte Servidor. A vantagem é que uma alteração no componente “Engine” não requer a geração
de uma nova versão para todos os computadores cliente. Por exemplo, é possível atualizar, reparar ou mesmo
substituir o componente “Engine” no Servidor sem que o sistema no Cliente (componentes “Interface” e
“Controle”) seja afetado por essa mudança. A desvantagem é que o componente “Engine” deve ser capaz de
executar todas as solicitações simultâneas sem ficar sobrecarregado.
O sistema segundo essa arquitetura alternativa foi implementado na linguagem Java (somente a parte
Servidor), com o Apache Lucene para o armazenamento das informações sobre o conjunto de arquivos
referente ao domínio de aplicação. O Apache Lucene é uma biblioteca, ou Application Programming
Interface (API), criada inicialmente em Java e que permite adicionar mecanismos de indexação e busca de
informações às aplicações (Hatcher et al., 2010).
A comunicação entre o componente “Controle”, no Cliente, e componente “Engine”, no Servidor, tem
papel importante na arquitetura alternativa da Figura 2. As mensagens são estruturadas usando a Extensible
Markup Language (XML) e codificadas em JavaScript Object Notation (JSON) para minimizar o
processamento dessas mensagens. A JSON é um formato leve para intercâmbio de dados computacionais
(uma alternativa para XML).
A abordagem utilizada é orientada a dados: o Cliente (componente “Controle”) envia os dados da
solicitação, que são processados no Servidor (componente “Engine”); e o Servidor (componente “Engine”)
retorna os dados de resposta, que são processados no Cliente (componente “Controle”) e utilizados para
atualizar os estados do sistema e/ou a interface do usuário (componente “Interface”).

137
ISBN: 978-972-8939-96-0 © 2013 IADIS

Figura 1. Arquitetura do sistema de busca exploratória

Figura 2. Arquitetura alternativa do sistema de busca

exploratória
Na Figura 3 é mostrado um exemplo de mensagem de solicitação no formato XML. Uma solicitação é
composta da ação a ser executada, da sequência de ações executada até o momento e da lista das referências
para os objetos de informações encontrados como resultado dessa sequência de ações. Nesse exemplo, o
usuário escolheu utilizar a busca por palavra-chave (linhas 4-9) depois de ter utilizado a busca por metadados
(linhas 14-19). Para simplificar o exemplo, apenas duas referências para objetos de informação são mostradas
na lista de itens (linhas 22-26) que corresponde aos resultados.
Na Figura 4 é mostrado um exemplo de mensagem de resposta. Uma resposta é composta principalmente
da nova lista de itens com as referências para os objetos de informação encontrados como resultado da ação
de busca. Para simplificar o exemplo, apenas duas referências são mostradas na lista de itens (linhas 2-16). A
lista de itens contém todos os dados necessários para a construção da parte da interface correspondente à área
de resultados. Além disso, a resposta também contém outras informações necessárias para a atualização da
interface, por exemplo, a lista de facetas da interface deve ser atualizada depois de cada ação de busca porque
a quantidade de itens relacionada com cada faceta pode ser alterada. Para simplificar o exemplo, apenas são
mostradas as novas informações com relação à faceta “A..G” de “Título” na lista de facetas que deve ser
utilizada para a atualização da interface (linhas 17-24).
A maior parte do processamento das funções de apresentação é mantida no Cliente. Por essa razão, o
Servidor tem apenas a função de processar a solicitação e gerar o formato da resposta. A introdução dessa
comunicação na arquitetura acarretou no aumento da carga de processamento devido à análise (parsing)
realizada nas mensagens (por exemplo, aquelas mostradas nas Figuras 3 e 4), tanto no Cliente quanto no
Servidor.
O componente “Engine” é responsável pelo processamento da solicitação e geração da resposta no
Servidor. Em outras palavras, a tarefa principal desse componente é processar a nova ação de busca (de uma
estratégia) contida em uma solicitação (por exemplo, aquela da Figura 3), além de computar o novo conjunto
de resultados (com base no conjunto atual contido na solicitação) e gerar a resposta (por exemplo, aquela da
Figura 4). Nesse componente estão integradas as diferentes funcionalidades (descritas na Seção 2) que
compõem o sistema desenvolvido.
O componente “Engine” também é capaz de processar uma estratégia completa, isto é, uma sequência
composta de várias ações de busca. Na versão atual, essa funcionalidade é utilizada para implementar o
recurso de desfazer uma ação da estratégia. Ao invés de manter os estados anteriores e permitir desfazer
somente a última ação executada, a interface do sistema permite desfazer qualquer ação da estratégia,
inclusive uma ação intermediária.
Quando uma ação é desfeita, o que realmente ocorre é uma solicitação para processar uma estratégia
completa, mas sem o item referente àquela ação. Essa funcionalidade é importante para, por exemplo,
permitir ao usuário colecionar estratégias bem sucedidas e repetir uma estratégia periodicamente em uma
mesma fonte de informação (ou em outras fontes de informação).

138
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

1 <request>
2 <step> 1 <response>
3 <strategy> 2 <itemList>
4 <action tool="keywordSearch"> 3 <item id="1309" rank="1">
5 <option name="words" value="chorar"> 4 <title>É Rir Pra Não Chorar</title>
6 </option> 5 <author>Jota Quest</author>
7 <option name="operator" value="and"> 6 <type>mp3</type>
8 </option> 7 <create>1998</create>
9 </action> 8 </item>
10 </strategy> 9 <item id="548" rank="2">
11 </step> 10 <title>Pode Chorar</title>
12 <history> 11 <author>Jorge e Mateus</author>
13 <strategy> 12 <type>mp3</type>
14 <action tool="facetBrowse"> 13 <create>2009</create>
15 <option name="facet" value="type"> 14 </item>
16 </option> 15 ...
17 <option name="instance" value="mp3"> 16 </itemList>
18 </option> 17 <facetList>
19 </action> 18 <facet name="title" label="Título">
20 </strategy> 19 <instance name="a..g" label="A..G" occurences="53">
21 </history> 20 </instance>
22 <itemList> 21 ...
23 <item id="88" rank=""></item> 22 </facet>
24 <item id="1208" rank=""></item> 23 ...
25 ... 24 </facetList>
26 </itemList> 25 </response>
27 </request>

Figura 3. Exemplo de mensagem de solicitação Figura 4. Exemplo de mensagem de resposta (response)

(request) enviada pelo cliente enviada pelo servidor

4. INTERFACE
O projeto da interface do sistema de busca exploratória iniciou com a análise dos sistemas de busca
exploratória da literatura. A partir dessa análise foram identificadas quatro principais estruturas de interface
consideradas relevantes. Essas estruturas não aparecem nos sistemas sempre da mesma forma, mas diferem
em termos de posição, de tamanho (em relação à interface toda) e da quantidade de informações
apresentadas. Para essa análise foram estudados os seguintes sistemas de busca exploratória encontrados na
literatura: Open Video Digital Library (Marchionini et al., 2006); Relation Browser ++ (Marchionini e
Brunk, 2003); Flamenco (Yee et al., 2003); mSpace (Schraefel et al, 2006); e Phlat (Cutrell et al., 2006).
Os resultados dessa análise, isto é, as estruturas de interface identificadas, são ilustradas na Figura 5 e
estão presentes na maioria dos sistemas analisados: (A) histórico de busca e navegação; (B) busca por
palavra-chave integrada; (C) busca (ou navegação) por facetas de metadados; e (D) visualização de objetos
de informação.
A

B D

Figura 5. Estruturas de interface de sistemas de busca exploratória

O projeto da interface foi realizado considerando um processo iterativo no qual cada etapa apresentou
evoluções a partir da etapa anterior (Dix et al., 2004). Cada etapa do projeto da interface envolveu a
especificação de funcionalidades, a prototipação da interface (que possibilitava realizar a interação) e a
avaliação da interface. A partir dessa avaliação seguia uma nova etapa de especificação, prototipação e

139
ISBN: 978-972-8939-96-0 © 2013 IADIS

avaliação. A avaliação nesse contexto era realizada por meio de testes de usabilidade informais (Preece et al.,
2002), com ênfase em contribuições rápidas ao invés de testes formais, devido à característica de evolução
dinâmica para identificação das interações possíveis na interface. Além disso, eram também comuns as
sessões de brainstorming com especialistas em usabilidade (da empresa ForLogic), as quais foram muito
importantes para atingir a aparência e o modo de atuar (look and feel) da interface atual.
Na Figura 6 é apresentado um exemplo da interface do sistema de busca exploratória. As principais partes
da interface são: (A) busca por palavra-chave; (B) busca por facetas de metadados (“Categorias”); (C)
histórico das ações de busca (“Histórico”); e (D) área de resultados (“Arquivos”). Pode-se observar em
“Categorias” o conjunto de metadados (“Título”, “Autor”, “Tipo” e “Data criação”) e suas respectivas
facetas. Na frente de cada faceta de um elemento de metadados é mostrado o número de itens (objetos de
informação) existentes que estão associados àquela faceta. As informações em (B) “Categorias” são sempre
alteradas de acordo com os itens resultantes de uma ação de busca.

Figura 6. Exemplo da interface do sistema de busca exploratória

5. AVALIAÇÃO
O foco da pesquisa em sistemas de busca exploratória tem sido no desenvolvimento de novos sistemas e
interfaces para apoiar as atividades de busca exploratória, ao invés da sua avaliação (White et al., 2008). Os
sistemas de busca exploratória são construídos sobre novas tecnologias e paradigmas de interface que
facilitam o aumento do nível de interação com objetos de informação e suas representações. Esse nível alto
de interação, que é parte integral da busca exploratória, demanda desafios para a avaliação.
Ao final do desenvolvimento do sistema de busca exploratória, uma avaliação foi realizada de acordo
com as recomendações do padrão ISO/IEC 14598-5, que divide o processo de avaliação em quatro estágios:
especificação, planejamento, avaliação piloto e avaliação (ISO/IEC, 1998).
Na etapa de especificação, o escopo e o objetivo da avaliação foram definidos. O escopo da avaliação foi
a interface e suas funcionalidades para auxiliar a busca exploratória. O objetivo da avaliação foi encontrar
problemas de usabilidade na interface e obter experiência em avaliação de sistemas de busca exploratória.
Na etapa de planejamento, um plano para a realização da avaliação foi elaborado, contendo os
procedimentos e o formulário que seria utilizado pelos avaliadores. O método escolhido para a avaliação foi a
Avaliação Heurística (Nielsen, 1994) porque é o método de avaliação de usabilidade mais utilizado devido à
facilidade de ser aplicado e ao custo baixo. Os avaliadores, no total de seis, são desenvolvedores de software
da empresa ForLogic, com experiência em usabilidade e não participaram do desenvolvimento do sistema de

140
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

busca exploratória. As heurísticas utilizadas na avaliação foram as heurísticas propostas originalmente,

reformuladas e reunidas por Nielsen (1994).
Uma avaliação piloto foi realizada para identificar problemas com o planejamento da avaliação (Preece et
al., 2002). Durante a avaliação piloto, as seguintes questões foram analisadas: (a) se os procedimentos da
avaliação estavam descritos com clareza para a condução da avaliação; e (b) se as informações necessárias
seriam registradas corretamente no formulário. Nessa avaliação piloto, nenhum problema foi identificado.
Na etapa de avaliação, os avaliadores percorreram a interface pelo menos duas vezes, analisando todos os
elementos de interação, comparando-os com as heurísticas e anotando os problemas identificados no
formulário. Um supervisor conduziu a avaliação e auxiliou os avaliadores na operação da interface quando
estes precisavam de explicação para determinados aspectos da interface. Os formulários foram compilados e
consolidados em um documento único que foi apresentado aos avaliadores em uma sessão de brainstorming
para discutir os principais problemas de usabilidade e as soluções possíveis. Além disso, os problemas foram
classificados em uma escala de quatro pontos com base no impacto sobre o usuário final.
Na Figura 7 são mostrados quais avaliadores encontraram determinados problemas de usabilidade. Cada
linha representa um dos seis avaliadores e cada coluna representa um dos dezenove problemas de usabilidade
encontrados. Cada um dos quadrados pretos (intersecção de linha e coluna) indica a descoberta de um dos
problemas de usabilidade por um dos avaliadores. As colunas foram ordenadas de maneira que os problemas
de usabilidade que receberam o maior nível de severidade estão à direita e aqueles que receberam o menor
nível de severidade estão à esquerda. A maioria dos problemas encontrados, problemas de 1 a 15, foi
considerado um problema de usabilidade superficial ou pequeno (em termos da facilidade/dificuldade de
recuperação do usuário), que será corrigido conforme uma lista de prioridades. Como esperado, os problemas
considerados mais severos, problemas de 16 a 19 foram na maioria os mais encontrados pelos avaliadores.

Figura 7. Ilustração que mostra os avaliadores que encontraram determinados problemas de usabilidade
O principal problema de usabilidade, considerado um problema grande e cuja solução tem alta prioridade,
está relacionado ao modo de operação da funcionalidade histórico das ações de busca. Os avaliadores
consideraram difícil para o usuário a compreensão de que, após excluir uma ação, a lista de itens
(“Arquivos”) reflete a sequência de ações resultantes após a exclusão. Apesar de o usuário poder superar essa
dificuldade inicial por meio de um treinamento básico, os avaliadores sugeriram o reprojeto dos elementos
interativos da interface referentes a essa funcionalidade.
Outro problema de usabilidade também considerado grande está relacionado à apresentação na interface
dos metadados cujas facetas não assumem valores de um conjunto predefinido, por exemplo, os metadados
“Título” e “Autor”. As facetas desses metadados são representadas por rótulos previamente fixados que
indicam um determinado intervalo do alfabeto. Dependendo da sequência das facetas escolhidas pelo usuário,
a interface pode apresentar números muito díspares na quantidade de itens atualmente associada a cada uma
das facetas. A sugestão dos avaliadores é calcular automaticamente os intervalos que possuem itens
disponíveis e alterar os rótulos das facetas dinamicamente.
O trabalho de consolidação exige tempo e muita atenção, pois cada avaliador relata à sua maneira os
problemas de usabilidade encontrados, assim como a sua localização na interface do sistema. A maior
dificuldade está na atividade de comparação dos diversos problemas para encontrar problemas igualmente
relatados ou parecidos em sua descrição e localização. Outra dificuldade surgia quando as informações
fornecidas pelo avaliador não foram suficientes para reproduzir o problema; sempre que possível, o avaliador
foi consultado sobre qual a melhor decisão a ser tomada.

141
ISBN: 978-972-8939-96-0 © 2013 IADIS

6. CONCLUSÃO
Neste trabalho foi apresentado um estudo de caso sobre o desenvolvimento e avaliação de um sistema de
busca exploratória. As informações, apresentadas a partir de experiências concretas, têm um potencial grande
de contribuição para problemas práticos. Os diversos aspectos apresentados estão relacionados às principais
funcionalidades, projeto da interface, arquitetura do sistema e avaliação.
O sistema de busca exploratória apresentado foi desenvolvido para um software de gerenciamento de
documentos denominado Gestor Eletrônico de Documentos e informações (GEDi). A empresa ForLogic deve
incorporar no sistema GEDi as ideias subjacentes ao sistema proposto, desenvolvendo um módulo com
funcionalidades semelhantes e de acordo com os seus padrões de desenvolvimento de software. Nesse
sentido, também é esperado algo similar para a versão para a Web do sistema GEDi.

AGRADECIMENTOS
Os autores agradecem à UTFPR, Fundação Araucária, Secretaria de Estado da Ciência, Tecnologia e Ensino
Superior (SETI-PR) e Governo do Estado do Paraná pelo apoio financeiro.

REFERÊNCIAS
Cutrell, E., Robbins, D., Dumais, S., and Sarin, R., 2006. Fast, flexible filtering with phlat. Proceedings of the SIGCHI
conference on Human Factors in computing systems, pp. 261-270.
Dix, A., Finlay, J., Abowd, G., and Beale, R., 2004. Human-Computer Interaction. 3. ed. Prentice-Hall, Harlow, England.
Hatcher, E., Gospodnetic, O., and McCandless, M., 2010. Lucene in Action. 2. ed. Manning Publications.
Hearst, M. A., 2006. Clustering versus faceted categories for information exploration. In CACM, 49, 4, pp. 59-61.
Hearst, M., Elliott, A., English, J., Sinha, R., Swearingen, K., and Yee, K., 2002. Finding the Flow in Web Site Search. In
CACM, 45, 9, pp. 59-61.
ISO/IEC, 1998. ISO/IEC 14598-5:1998 Information technology – Software product evaluation – Part 5: Process for
evaluators. Available at http://www.iso.org.
Marchionini, G. and Brunk, B., 2003. Towards a General Relation Browser: A GUI for Information Architects. In
Journal of Digital Information, 4, 1.
Marchionini, G., 2006. Exploratory search: From finding to understanding. In CACM, 49, 4, pp. 41-46.
Marchionini, G., Wildemuth, B. M., and Geisler, G., 2006. The Open Video Digital Library: A Möbius Strip of Research
and Practice. In Journal of the American Society for Information Science and Technology, 57, 12, pp. 1629–1643.
Mussi, L. P. S., Takemiya, S. H., Pansanato, L. T. E., Pozza, R. S., Yasui, P. H. Z., Della Mura, W. A., and Bastiani, J.
A., 2009. GEDi: Gestor Eletrônico de Documentos e informações. Anais do XVIII Workshop de Ferramentas e
Aplicações (WFA), V Simpósio Brasileiro de Sistemas Multimídia e Web, 2, pp.124-126.
Nielsen, J., 1994. Heuristic evaluation. in Nielsen, J. and Mack, R. L. (Eds.). Usability Inspection Methods. John Wiley &
Sons, New York.
Pereira, D. F. and Pansanato, L. T. E., 2012. Estudo de Caso: Arquitetura de Sistema para Auxiliar a Busca Exploratória
de Informações. Anais do XVII Seminário de Iniciação Científica e Tecnológica da UTFPR, Curitiba.
Preece, J., Rogers, Y., and Sharp, H., 2002. Interaction Design: Beyond Human-Computer Interaction. John Wiley &
Sons, New York.
Schraefel, M. C., Wilson, M., Russell, A., and Smith, D. A., 2006. mSpace: improving information access to multimedia
domains with multimodal exploratory search. In CACM, 49, 4, pp. 47-49.
White, R. W. and Roth, R. A., 2009. Exploratory Search: Beyond the Query–Response Paradigm. Morgan & Claypool.
White, R. W., Drucher, S. M., Marchionini, G., Hearst, M., and Schraefel, M. C., 2007. Exploratory search and HCI:
designing and evaluating interfaces to support exploratory search interaction. Proceedings of the CHI Extended
Abstracts, pp. 2877-2880.
White, R. W., Marchionini, G., and Muresan, G., 2008. Evaluating exploratory search systems. In Information
Processing and Management, 44, 2, pp. 433-436.
Yee, K., Swearingen, K., Li, K., and Hearst, M., 2003. Faceted metadata for image search and browsing. Proceedings of
the SIGCHI conference on Human factors in computing system, pp. 401-408.

142
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

RFDroid: SOLUÇÃO PARA AUXÍLIO À MOBILIDADE DE

PESSOAS COM DEFICIÊNCIA VISUAL
EM AMBIENTES INDOOR

Cristina Paludo Santos, Cristiane Ellwanger, Denilson Rodrigues da Silva

e Thomaz Colpo de Lima
Universidade Regional Integrada do Alto Uruguai e das Missões – Campus de Santo Ângelo
Av. Universidade das Missões, 464 – Universitário – Santo Ângelo/RS – 98.802-470

RESUMO
Este artigo apresenta a solução RFDroid que propõe integrar as tecnologias de identificação por radiofrequência (RFID) e
dispositivos móveis para o desenvolvimento de aplicações voltadas a auxiliar pessoas com deficiência visual no que se
refere à locomoção e reconhecimento de pontos específicos em ambientes fechados. Acredita-se que as pesquisas
realizadas possam servir como subsídios para a concepção de novas aplicações que façam uso da integração das
tecnologias propostas nos mais variados domínios.

PALAVRAS-CHAVE
Tecnologia RFID, Ambientes Indoor, Deficiência Visual, Dispositivos Móveis, Tecnologia Assistiva

1. INTRODUÇÃO
Atualmente, a tecnologia de identificação por radiofrequência (RFID) experimenta um vasto crescimento
entre as tecnologias de transmissão sem fio. Seu uso já é frequente e está consolidado em aplicações como,
por exemplo, casas inteligentes, monitoramento de bagagens em aeroportos e gerenciamento da cadeia de
suprimentos, atendendo de forma eficiente as necessidades das soluções desenvolvidas (Santini, 2008). No
entanto, em muitas áreas o RFID é uma tecnologia emergente que impõe muitos desafios na sua utilização,
incluindo a leitura e recuperação eficiente dos dados em um processo de identificação automática (Batocchio,
2011).
Dentre as várias aplicações que ainda requerem estudos e experimentos no uso de sistemas RFID
destacam-se as soluções para mobilidade em ambientes fechados. A mobilidade é uma importante
característica das redes sem fio, pois permite ao usuário permanecer conectado a rede, mesmo enquanto se
move através do uso de diferentes dispositivos móveis (celulares, smartfones, tablets, etc) e em locais
distintos (Werb, 2010)(Ferrer,2010). Entretanto esta facilidade pode acarretar problemas, principalmente, no
que se refere ao projeto das redes que estabelecem a comunicação entre estes diferentes dispositivos. No caso
de rede infra-estruturada, o local onde o usuário se encontra dentro da área de cobertura de um ponto de
acesso é que garante a manutenção da conexão à rede e, a mobilidade pode fornecer uma indesejável latência
no momento em que ocorre a transição do usuário de um ponto de acesso para outro. Em redes não
estruturadas (adhoc), a mobilidade pode trazer problemas no estabelecimento de rotas para a transmissão de
dados e na capacidade da rede como um todo (Loureiro, 2013).
Várias tecnologias oferecem auxílio à orientação e localização de pessoas com deficiência visual, tanto
em ambientes fechados quanto abertos. Entretanto, isto só foi possível efetivamente com o surgimento dos
dispositivos eletrônicos, visto que os recursos que subsidiavam esta orientação e localização voltavam-se à
utilização de ferramentas convencionais, tais como, bengalas, utilização de cães-guia, relevo sobre o chão,
linguagem em braile, dentre outros. Embora tais tecnologias sejam de suma relevância e ofereçam uma
contribuição significativa às pessoas com deficiência visual por possibilitarem autonomia e mobilidade, elas
são desprovidas de recursos oriundos da computação embarcada e apresentam-se bastante limitadas em
termos de quantidade de informações fornecidas ao seu utilizador na realização de suas tarefas cotidianas.

143
ISBN: 978-972-8939-96-0 © 2013 IADIS

Para suprir tais limitações o sistema RFID apresenta-se como uma tecnologia emergente que oferece
contribuições significativas para esta área devido as suas particularidade e características específicas tais
como o custo acessível, a possibilidade de reuso, a capacidade de armazenamento de informações em um
sistema compacto e, sobretudo, por não necessitar do contato físico das pessoas para com um determinado
objeto ou ainda que este objeto esteja no campo de visão destas pessoas (Yelamarthi, 2010), (Al-Qutayri,
2011).
Diante do exposto a proposta RFDroid apresenta-se como uma solução computacional que se utiliza da
tecnologia RFID para o desenvolvimento de aplicações capazes de auxiliar a locomoção de pessoas com
deficiência visual em ambientes fechados. Em termos gerais, a solução proposta visa promover contribuições
científicas que demonstrem a sua aplicabilidade no desenvolvimento de soluções que requeiram mobilidade
em ambientes fechados e ao mesmo tempo amplia o leque de tecnologias assistivas que realmente promovam
impactos significativos no cotidiano de pessoas com deficiência visual, principalmente no que se refere à
familiarização destas pessoas para com ambientes inicialmente desconhecidos. Vislumbra-se a aplicabilidade
desta solução em vários contextos de uso reais, no entanto, neste artigo apresenta-se como estudo de caso
para fins de validação da proposta, o desenvolvimento de uma aplicação que facilita a locomoção e
identificação de espaços por pessoas com deficiência visual.
No intuito de melhor descrever a solução RFDroid o presente artigo estrutura-se conforme segue: a seção
2 apresenta a arquitetura do RFDroid, descrevendo as diferentes camadas que a compõem; a seção 3
descreve as tecnologias empregadas na concepção da solução RFDroid; a seção 4 direciona-se à apresentação
e descrição do protótipo implementado a partir da arquitetura proposta e de posse das tecnologias utilizadas e
a seção 5 apresenta as conclusões advindas da realização deste trabalho, vem como os direcionamentos para
o desenvolvimento de trabalhos futuros.

2. ARQUITETURA DA SOLUÇÃO RFDroid: CARACTERÍSTICAS

ESPECÍFICAS
A arquitetura RFDroid origina-se a partir de três componentes principais, ou seja, por um aplicativo Android,
um WebService e por um sistema RFID composto por leitor de TAGs. Em um contexto mais abrangente a
arquitetura pode ainda ser dividida em duas camadas específicas, uma que compreende o software em si,
composto pelo aplicativo e pelo WebService; e outra que envolve as características pertinentes ao hardware,
composto pelo leitor RFID e o módulo Bluetooth, os quais correspondem as tecnologias empregadas no
desenvolvimento do RFDroid e suas interações, conforme demonstrado na Figura 1.

Figura 1. Visão Geral da Arquitetura RFDroid

O hardware é responsável por inicializar as ações de comunicação entre o ambiente e o usuário. Neste
cenário, o leitor RFID assume um papel crucial, pois se encarrega da captura de informações através da
leitura do identificador (id) das TAGs disponíveis no ambiente, dando inicio ao processo de comunicação

144
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

com os demais dispositivos enquanto que na camada de software, o aplicativo em questão é responsável pelo
controle de todas as funções que favorecem a interação do dispositivo para com o usuário a partir da
inicialização de funções que estabelecem uma comunicação entre o sistema RFID e o aplicativo fornecendo
informações sobre o ambiente. De posse de tais informações é realizada uma pesquisa na base de dados sobre
os dados fornecidos e em seguida estas informações são disponibilizadas ao através do sintetizador de voz.
Além disso, nesta camada prevê ainda o uso de um WebService a fim de que as informações mantenham-se
sempre atualizadas e reflitam o estado atual do ambiente. Para que isso ocorra o WebService armazena as
mesmas informações presentes na base de dados do dispositivo móvel, porém no formato de arquivos XML.
A arquitetura da solução RFDroid contempla ainda um versionamento entre informações existentes na base
de dados e as informações contidas no WebService o qual é responsável por verificar a existência de novos
dados disponíveis no ambiente e que necessitam de atualização. Tais atualizações são realizadas através da
conexão entre o dispositivo móvel e o WebService com a utilização da variável version, presente tanto no
dispositivo móvel quanto no WebService, a qual verifica se houve alterações das informações no ambiente e
em caso positivo retorna-as ao dispositivo móvel.

3. TECNOLOGIAS EMPREGADAS NA SOLUÇÃO

Diferentes tecnologias foram utilizadas para o estabelecimento da solução RFDroid sendo que estas
direcionam-se às principais camadas que compreendem sua arquitetura, ou seja, a camada de hardware e
camada de software. As características e especificidades destas tecnologias são descritas conforme segue:
Na camada de Hardware o protótipo da solução contemplou o uso da plataforma de prototipação
Arduino, em conjunto com o leitor RFID e um módulo Bluetooth para a comunicação com um Smartphone
Android. Para auxiliar o processo de comunicação/integração entre Android e Arduino utiliza-se o Amarino
toolkit para Android e a biblioteca MeetAndroid para Arduino (Kaufmann, 2010), conforme demonstra a
Figura 2.

Figura 2. Componentes de hardware e suas interações

O Arduíno caracteriza-se como uma plataforma de prototipação simples, de fácil utilização e de baixo
custo. Além disso, permite a conexão de diversos componentes de hardware e a criação de software para
controle de suas funções. Características estas que viabilizam a utilização do Arduíno como um meio de
integração entre o leitor RFID e o módulo Bluetooth para comunicação com um smartphone Android. Dentre
os diversos modelos de Arduino disponíveis, propõem-se a utilização do micro controlador ATmega 328
(Atmel 2012), devido a vários fatores dentre os quais citam-se: (a) sua ampla utilização na prototipação de
diversos projetos; (b) seu baixo custo; (c) sua facilidade de aquisição e, (d) seu desempenho de
processamento, tornando-o a escolha ideal no quesito custo/benefício.
Para o módulo leitor RFID utilizou-se o “YHY502CTG”, o qual possui capacidade de leitura e gravação
que contempla o padrão ISO 14443ª e suporte a TAGs sedimentadas no padrão Mifare Classic 1K e Classic
4K, eximindo, desta forma as preocupações dos desenvolvedores quanto aos detalhes da comunicação direta
com as TAGs e métodos anticolisão, havendo somente a necessidade de envio de um comando de
leitura/gravação para o módulo, o qual, posteriormente, se encarrega da requisição e estabelecimento da
comunicação com a TAG e executa todas as tarefas necessárias para retornar a resposta requerida
automaticamente [EHU 2010].

145
ISBN: 978-972-8939-96-0 © 2013 IADIS

Para o desenvolvimento do protótipo da solução adquiriu-se um kit completo composto por um leitor,
uma antena, um adaptador para Arduíno e um conjunto de seis TAGs, que opera na freqüência de 13,56
mhz,. Para o estabelecimento da comunicação entre o dispositivo móvel e o Arduino incorporou-se a
tecnologia Bluetooth devido sua praticidade por ser um meio sem fio para troca de informações e com um
baixo custo de consumo, utiliza-se este método como padrão para estabelecimento de conexão na proposta do
RFDroid.
Apesar da plataforma Android oferecer uma serie de recursos que podem ser utilizados em dispositivos
móveis, a habilitação do bluetooth pode acarretar vários entraves no processo de interação das pessoas com
deficiência visual com o dispositivos móveis devido as diferentes opções direcionadas a habilitação deste
recurso (ativar do Bluetooth; tornar o dispositivo visível; escolher o dispositivo com o qual deseja se conectar
e autorizar a conexão). Para contornar estes entraves optou-se pela utilização da biblioteca Amarino a fim de
suprir as necessidades de interação do usuário para o estabelecimento a conexão Bluetooth. O uso da API
Amarino torna mais simples para a comunicação entre Android e Arduino, eliminando a necessidade de
interação do usuário para com a aplicação e promovendo o gerenciamento automático para inicialização dos
serviços de conexão.
Para a implementação da camada de software contemplou-se a plataforma móvel Android devido a
grande quantidade de dispositivos que se utilizam da mesma e também grande variedade de recursos que a
mesma oferece aos desenvolvedores tais como o acesso ao Bluetooth, utilização da classe TextToSpeech e o
uso do banco de dados SQLite Agregado a isto o sintetizador de voz está incorporado à plataforma Android
desde a versão 1.6, rodando sobre a engine PICO, o que facilita a sua utilização por aplicações para gerar um
trecho de áudio referente a textos em geral, sendo ele amplamente utilizado nesta proposta por estabelecer a
comunicação direta entre a solução e o usuário. O uso do TTS é relativamente simples, bastando importar a
classe TextToSpeech(), inicializá-la e invocar o método speak() passando, como parâmetro, uma string com
um texto para ser lido. A string utilizada está armazenada em banco de dados.
A base de dados destina-se ao armazenamento de duas informações principais a saber: (a) o identificador
de TAGs RFID, onde cada TAG é referenciada por um id de identificação que compreende um número
hexadecimal único que a identifica, sendo este armazenado em forma de string e, (b) a descrição de um ponto
específico do ambiente, vinculado ao identificador da TAG, por exemplo, a TAG cujo id é “3EA297F90”
referencia um banheiro. Todas estas informações são armazenadas em uma base de dados, criada localmente
no dispositivo com o uso da biblioteca SQLite, disponível na plataforma Android. As alterações no ambiente
podem ser realizadas em uma aplicação servidora e logo após, a aplicação móvel comunica-se com o
WebService, responsável por enviar ao dispositivo as novas informações do ambiente. Toda a comunicação
entre o dispositivo Android e o WebService é realizada com o uso da biblioteca externa “Ksoap2” que auxilia
a criação de pacotes para envio de mensagens.
Outro fator que merece destaque é a inicialização do sintetizador de voz. O processo de narração das
informações não possui nenhum tipo de fila ou política para que o sintetizador pare ou continue uma
narração, ou seja, ele simplesmente segue o fluxo normal de execução. Em outras palavras, o gatilho que
dispara o processo de narração é a chegada dos dados referente à leitura do identificador de uma TAG ao
sistema. Se o mesmo encontra-se no meio de uma narração e um novo id é identificado a narração é,
imediatamente, cancelada e uma nova leitura é iniciada. Esta abordagem garante que as informações
repassadas para o usuário referentes à localização dele no ambiente sejam sempre confiáveis, contornando
problemas que por ventura possam surgir tais como o posicionamento de duas TAGs uma próxima a outra e a
velocidade de movimentação do usuário no ambiente. A Figura 3 demonstra graficamente a comparação
entre estas duas abordagens de narração.

146
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Figura 3. Demonstração da Política de Narração das Informações

No primeiro caso é utilizada uma política onde a narração só pode ser iniciada quando a anterior tiver
terminado enquanto que no segundo caso, a narração da TAG1 é cancelada logo depois que o usuário entra
no campo de atuação da TAG2, independente da situação ela é iniciada com o usuário posicionado no local
desejado.

4. PROTÓTIPO DA SOLUÇÃO RFDroid

RFDroid é uma solução computacional que se utiliza das vantagens dos sistemas RFID juntamente com os
avanços de tecnologias móveis para o desenvolvimento de aplicações que facilitem a mobilidade de pessoas
em ambientes fechados. Diferencia-se de outros métodos e propostas já existentes que, em sua maioria,
pecam em confiabilidade e desempenho ou possuem um custo muito elevado e envolvem um conjunto de
vários dispositivos integrados que não oferecem praticidade de uso (Ferrer, 2010)(Conti, 2004).
Diante do exposto a solução RFDroid visa minimizar os problemas acima mencionados fundamentando-
se em um processo no qual o leitor RFID é responsável pela captação de informações provenientes do
ambiente por meio de TAGs e pelo envio destas ao dispositivo móvel do usuário, fornecendo-lhe
informações sobre o ambiente e mais especificamente sobre os pontos que possam por ventura ser de seu
interesse ou estar próximos ao mesmo. Para tanto faz uso da plataforma Android (Pereira, 2009), devido ao
crescimento exponencial na aquisição de dispositivos móveis que se utilizam deste sistema operacional.
A utilização da plataforma Android justifica-se à medida que a mesma oferece componentes robustos e a
disponibilização de ferramentas e APIs necessárias ao desenvolvimento de aplicações capazes de acessar
todos os recursos de hardware do dispositivo móvel (Wi-Fi, multimídia e bluetooth,) e também às
atualizações constantes provenientes desta plataforma, oferecendo novas funcionalidades, tanto para o
usuário quanto para desenvolvedores, principalmente no que se refere as melhorias de interface e
performance, a disponibilização de novas APIs para controle de eventos de sensores e outras funções dos
dispositivos, que são aprimoradas a cada nova versão (Android 2012). Além disso, o RFDroid agrega em si
a tecnologia Text-To-Speech (TTS), um sintetizador de voz que funciona em várias línguas e que reproduz
artificialmente a voz humana, tecnologia esta que permite que aplicações Android sejam capazes de interagir
com o usuário de uma forma inovadora (Hashimi 2010).
A aplicação desenvolvida pode ser dividida em quatro partes gerais, sendo elas um banco de dados,
responsável por comportar as classes DBAdapter, DbHelper e _Tags; o gerenciador de conexão
Bluetooth , feito através da biblioteca externa Amarino (Bonifaz, 2010) já mencionada; um mecanismo de
comunicação com o usuário, realizado pelo sintetizador de voz (TextoToSpeech) e um sistema de webservice
para a realizações de atualizações de informações na base de dados, as quais são realizadas pela classe
Consome_WS. A Figura 4 apresenta o diagrama UML das principais classes que compõem o aplicativo,
acima referenciadas.

147
ISBN: 978-972-8939-96-0 © 2013 IADIS

Figura 4. Demonstração da Política de Narração das Informações

A classe principal da aplicação desenvolvida é a classe Main_BT.Activity, nela são diretamente
implementados o TextToSpeech e o ArduinoReceiver, sendo este responsável pelas conexões Bluetooth e
pela realização das consultas à base de dados da aplicação através das classes DbHelper e DBAdapter. A
aplicação foi inicializada com com uma base de dados que contêm informações pré-definidas tais como o
identificador (id) real das TAGs e um “nome” para a mesma que corresponde à descrição a ser narrada pelo
TTS.
Tão logo a base de dados é inicializada e os demais componentes do aplicativo carregados é necessário o
start de todas as ações do sistema (resposta do leitor RFID). O processo de interação com uma TAG inicia-se
quando o código, desenvolvido para o Arduino, envia ao leitor um comando de leitura. No momento que uma
das TAGs se aproxima, a informação é captada analisada e enviada para o dispositivo móvel através do
módulo Bluetooth. Assim, o dispositivo móvel fica incessantemente aguardando a chegada de uma
mensagem (via Bluetooth) através da classe ArduinoReceiver. Quando esta informação chega,
imediatamente, é feita uma chamada ao método lookn_speak() da classe Main_BT, a qual é responsável pela
abertura da base de dados e pela chamada do método getTag() da classe DBAdapter responsável pelas
pesquisas na base de dados através do identificador de uma determinada TAG. O resultado dessa pesquisa é
uma String referente ao identificador pesquisado, a qual é utilizada como parâmetro a ser narrado através do
método speakOut(). Para a realização das operações de recebimento de um identificador de TAGs (via
Bluetooth) e pesquisa para encontrar o nome referente a esta TAG na base de dados, foi utilizada uma
interface composta por dois TextViews que comprovam o recebimento dos dados e possibilitam ao usuário
ouvir novamente a ultima informação narrada.
Para a codificação da solução RFDroid foi utilizado o Toolkit Android Development integrado à IDE
Eclipse, sendo os testes realizados em um aparelho LG Optimus L5 com a versão 4.1 do sistema Android. No
dispositivo móvel foi instalada a aplicação RFDroid em conjunto com um Arduino (micro controlador
Atmega328) equipado com um leitor RFID (YHY502CG) e um módulo Bluetooth. Estas tecnologias
agregam os componentes utilizados na concepção do protótipo da solução, conforme demonstra a Figura 5.

148
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Figura 5. Integração dos Componentes do Protótipo do RFDroid

O led vermelho, disponível no leitor RFID, permanece habilitado enquanto existir uma TAG no campo de
atuação da antena. As informações referentes à leitura da TAG são apresentadas na tela da aplicação.
Ressalta-se ainda que para a realização dos testes iniciais, foi desenvolvido um protótipo que teve como
cenário de teste, um ambiente fictício composto por seis (6) salas no intuito de se verificar o alcance e o
desempenho da solução na captura de informações do ambiente para posterior envio ao dispositivo móvel.

5. CONCLUSÕES E DIRECIONAMENTOS FUTUROS

Nos últimos anos observa-se que o cotidiano das atividades das pessoas com deficiência sofre um impacto
significativo das novas tecnologias de informação e comunicação. Nesta perspectiva amplia-se o leque de
novas tecnologias assistivas e cresce o interesse pelo desenvolvimento de aplicações com viés inclusivo e que
promovam melhorias na qualidade de vida das pessoas.
Sistemas que comportam tecnologias RFID apresentam várias vantagens em detrimento de outros tipos de
sistemas similares, dentre as quais se destacam a utilização da comunicação sem fio, não necessitando de
contato físico nem de campo visual direto; a leitura e escrita de dados a grandes velocidades e uma alta
capacidade de armazenamento de informação, sendo superior a tecnologias similares. Outro ponto positivo é
o fato das tags, além de não apresentarem um alto custo (adquiridas em grande quantidade seu custo torna-se
mais acessível), podem ser reutilizadas e exigem uma manutenção mínima.
Um dos sistemas cujas possíveis aplicações são bastante semelhantes às da RFID é o código de barras. De
fato, ambos possibilitam o armazenamento de informações ao mesmo tempo em que permitem manter um
registro da localização e de vários recursos. Isto faz com que sejam de grande utilização em vários domínios
de aplicação, permitindo uma melhor gestão de recursos. No entanto, o sistema RFID evidencia uma grande
superioridade tecnológica em relação ao código de barras, motivo que justifica a sua expansão e aumento de
preferência em face deste último.
Neste cenário insere-se a proposta do RFDroid que propõe o uso da tecnologia de identificação por
radiofrequência (RFID) no desenvolvimento de aplicações voltadas a auxiliar pessoas com deficiência visual
a movimentar-se livremente e encontrar pontos de interesse em ambientes fechados [ALM 08].
No que se refere às avaliações de desempenho, está sendo realizado um conjunto de testes exaustivo
considerando diferentes parâmetros de entrada tais como o tempo necessário para concluir um determinado
percurso e a previsão de erro de direção. Além disso, vários cenários estão sendo concebidos a fim de simular
o comportamento de um utilizador com deficiência visual. Tais testes permitirão a realização de ajustes no
protótipo desenvolvido. Uma vez efetuadas as modificações pertinentes, prevê-se a elaboração de testes reais,
fazendo uso dos diversos cenários concebidos, envolvendo usuários finais, ou seja, pessoas com deficiência
visual.

149
ISBN: 978-972-8939-96-0 © 2013 IADIS

Cabe ressaltar que, apesar da proposta estar vinculada ao desenvolvimento de aplicações de cunho
assistivo, a integração entre dispositivos móveis Android e sistemas RFID por meio de uma comunicação
Bluetooth pode ser empregada na concepção de aplicações em outros contextos. Assim, estima-se que a
pesquisa realizada oferece subsídios para que desenvolvedores promovam contribuições em outros domínios
onde a integração das tecnologias propostas seja viável.

REFERÊNCIAS
ANDROID Developer, “Android 1.6 Plataform Highlights”. Disponível em:
http://developer.android.com/about/versions/android-1.6-highlights.html. Acessado em novembro de 2012.
AL-QUTAYRI, M., J. JEEDELLA, et al. (2011). An integrated wireless indoor navigation system for visually impaired.
Systems Conference (SysCon), 2011 IEEE International: 17-23.
ATMEL 2012. “Atmega328P”. Disponível em: http://www.atmel.com/devices/. Acessado em novembro de 2012.
BATOCCHIO, Antonio. Uma Visão Geral sobre RFID e Áreas de Aplicações. In: X SBAI – Simpósio Brasileiro de
Automação Inteligente. Proceedings… São João del-Rei , MG. Brasil, 2011.
CONTI, M.; CLIQUET, A. KASSAB, F. Substituição Sensorial para Auxílio à Mobilidade de Deficientes Visuais via
Eletroestimulação Tátil. Universidade Católica Dom Bosco, Campo Grande, Mato Grosso do Sul, 2004.
FERRER, G.; DEW, Nicholas. When is RFID right for your service? International Journal of Production Economics.
Elsevier, Volume 124, Issue 2. Pg 414–425. April 2010.
HASHIMI, S; KOMATINENI, S; MACLEAN, D. ProAndroid 2, eBook. Editora Atica, 2010.
KAUFMANN, Bonifaz. Amarino: a toolkit for the rapid prototyping of mobile ubiquitous computing. In: Proceedings of
the 12th International Conference on Human Computer Interaction with Mobile devices and Services. ACM, New
York, 2010.
LOUREIRO, Antonio A.F.; et al. Comunicação Sem Fio e Computação Móvel: Tecnologias, Desafios e Oportunidades.
Disponível em: http:// http://homepages.dcc.ufmg.br/~loureiro/cm/docs/jai03.pdf. Acesso em março, 2013.
PEREIRA, Lúcio Camilo Oliva. Android para desenvolvedores. Brasport, Rio de Janeiro, 2009.
SANTINI, A.G. RFID: Conceitos, Aplicabilidades e Impactos. Rio de Janeiro, Editora Ciência Moderna, 2008.
WERB J., e LANZL C. Designing a positioning system for finding things and people indoors. IEEE spectrum, vol. 35,
nº.9, Setembro de 2010.
YELAMARTHI, K., D. Haas, D. Nielsen, and S. Mothersell. Rfid and Gps Integrated Navigation System for the Visually
Impaired. Circuits and Systems (MWSCAS), 2010 Proceedings… 53rd IEEE International Midwest Symposium on
(2010): 1149-52.

150
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

FERRAMENTA DE APOIO AO ENSINO DE

PROGRAMAÇÃO COM INTRODUÇÃO A ORIENTAÇÃO
A OBJETOS

Eduardo Guedes Carvalho, Gabriel Viana Guedes e Luiz Alfredo Soares Garcindo
Universidade do Sul de Santa Catarina - José Acácio Moreira, 787, Tubarão, Santa Catarina

RESUMO
Este artigo apresenta uma ferramenta para apoiar o ensino de programação e que permita introduzir aos alunos iniciantes
os conceitos de orientação a objetos. A ferramenta possibilita que os acadêmicos escrevam programas utilizando
pseudocódigo na língua portuguesa, em uma interface simples e de fácil utilização. Compõe a ferramenta uma linguagem
de programação interpretada que gera código para execução na máquina virtual do Java (JVM). Testes de avaliação,
feitos com professores e alunos através de questionários, mostraram resultados positivos.

PALAVRAS-CHAVE
Orientação a objetos, ensino de programação, algoritmos, ferramenta de apoio.

1. INTRODUÇÃO
O ensino de programação tem sido alvo de muitas pesquisas nos últimos anos, todas com a mesma
preocupação, o processo de ensino/aprendizagem de programação. Rocha et al (2010, p. 1) mencionam que
tais estudos são motivados pelo fato que ensinar programação não é tarefa fácil e saber programar é
importante para a maioria das disciplinas ligadas à computação.
Existem problemas relacionados à dificuldade em aprender conceitos de orientação a objetos,
principalmente quando se trata da transição de paradigmas, entre o procedural e o orientado a objetos
(Kölling, 1999; Sheetz et al, 1997; Santos, 2009; Biju, 2013). Devido à própria natureza distribuída do
paradigma, à complexidade das linguagens que o utilizam, e à troca de paradigmas, os alunos têm dificuldade
na compreensão de seus conceitos. Isso se deve ao fato, também, de as ferramentas atuais utilizarem
linguagens muito complexas, ambientes de programação confusos, onde alguns sistemas foram
desenvolvidos para engenheiros de software profissionais sendo difícil para alunos iniciantes se adaptarem a
estes ambientes (SHEETZ et al, 2000; KÖLLING, 1999; BIJU, 2013).
No curso de Ciência da Computação da UNISUL (Universidade do Sul de Santa Catarina), por exemplo,
as disciplinas de programação tratam, numa fase inicial, exclusivamente do ensino de algoritmos, com o
paradigma imperativo. Em fases subsequentes dos currículos são introduzidos os conceitos de orientação a
objetos e se inicia o ensino de linguagens profissionais que normalmente utilizam os dois paradigmas citados.
Em pesquisa a currículos de outras instituições, que são consideradas entre os dez melhores cursos de
ciência da computação no Brasil pela revista virtual o Guia do Estudante (Previdelli, 2013), constatou-se que
são utilizados métodos semelhantes para ensinar programação. Algumas dividem os conteúdos, e dedicam
disciplinas para os diferentes paradigmas de programação. Mas na maior parte delas são utilizados os
algoritmos em forma de pseudocódigo para passar o conteúdo aos alunos.
Existem também estudos que questionam os métodos de ensino convencionais, e propõem utilizar o
paradigma de orientação a objetos logo no início dos cursos de computação. Diversos autores defendem este
método, mas diferem na forma de apresentar os conceitos aos alunos. Alguns propõem utilizar uma
linguagem totalmente orientada a objetos como o Smalltalk para passar os conceitos aos alunos, já outros
utilizam linguagens híbridas como o C++, e frameworks específicos como objetos de estudo (SHEET et al,
2000; KÖLLING, 1999; BIJU, 2013; DEMUTH et al, 2000; BRUDERER, 2005).

151
ISBN: 978-972-8939-96-0 © 2013 IADIS

Desta forma, é proposta neste artigo uma ferramenta que compõe um ambiente didático capaz de
amenizar os problemas citados, seja na visão essencialmente imperativa, ou na introdução dos conceitos de
orientação a objetos. Pretende-se, em resumo, atender diferentes cenários no ensino de programação para
iniciantes: os conceitos de orientação a objetos são passados aos alunos inicialmente; e o modelo tradicional
onde os conceitos de programação imperativa são passados primeiro. A ferramenta proposta utiliza uma
linguagem interpretada, com notação intuitiva, concisa e de fácil aprendizado.

2. TRABALHOS RELACIONADOS
Ferramentas de apoio ao ensino de programação têm sido cada vez mais utilizadas e tem contribuído bastante
na obtenção de resultados positivos no ensino de programação. A seguir são comentadas de forma sucinta
algumas ferramentas de expressão no mercado.
O VisuALG, segundo a Apoio Informática, sua empresa de criação, tem como objetivo permitir aos
alunos iniciantes em programação o exercício de seus conhecimentos em um ambiente próximo da realidade.
A linguagem que ele interpreta é uma versão portuguesa de pseudocódigo (Portugol) e utiliza o paradigma
procedural.
O Tepequém segundo Hinterholz Jr. (2009, p. 485 - 488), é uma linguagem de programação imperativa
focada no paradigma estruturado, baseada em pseudocódigo. Os programas feitos nesta linguagem podem
rodar em qualquer máquina e qualquer sistema operacional. Ela é utilizada através de um plugin para o IDE
Netbeans, e as funções extras dele podem ser aproveitadas.
Portugol IDE, segundo Manso, Oliveira e Marques (2009, p. 3), é um ambiente de aprendizagem de
programação constituído de duas linguagens de definição de algoritmos: pseudo-código e fluxogramas. O
pseudo-código é baseado no português estruturado, e incorpora características das mais recentes linguagens
de programação.

3. FERRAMENTA PROPOSTA
A seguir são apresentadas as principais características da ferramenta.

3.1 Visão Geral

A ferramenta permite ao usuário escrever um algoritmo e executá-lo na máquina virtual do Java (JVM). Ele
poderá fazer isso utilizando pseudocódigo, na língua portuguesa. Na linguagem projetada para a ferramenta
estão incluídos conceitos de estruturas de controle, como repetição e seleção (enquanto, para..faça, repita,
se..então, caso..faça), funções e procedimentos, assim como conceitos de orientação a objetos (classes,
herança, métodos, objetos). Os tipos de dados permitidos são: inteiro, real, lógico, literal, caractere, e ainda
os objetos, que terão seu tipo associado a sua classe.
Conforme a figura 1, a interface da ferramenta é composta por um editor de texto dividido em duas
partes, a parte esquerda é reservada para o algoritmo principal, e a parte direita para definição de classes. O
usuário pode usar ou não os conceitos de orientação a objetos. Logo abaixo se encontra o console de erros. O
console de erros é responsável por mostrar as mensagens que indicam erros no código do usuário. O primeiro
erro encontrado será apontado no código do usuário, sendo destacado em vermelho exatamente onde ele
ocorre. Inclui opções de fonte e manipulação de arquivos, e também menu de ajuda. Ao clicar no menu ajuda
é aberta uma janela contendo o manual da linguagem.
A ferramenta reconhece teclas de atalho para refazer e desfazer as ações executadas no editor de texto
(ctrl+y, ctrl+z), assim como função de autocompletar (ctrl+espaço) contendo os tokens reservados. Ao clicar
no editor de texto com o botão direito do mouse, é possível visualizar a sintaxe das estruturas de seleção e
repetição, a sintaxe dos métodos e a estrutura de definição de classes, podendo estas assim ser geradas
automaticamente. Para facilitar a visualização do código, o editor de texto apresenta os tokens reservados em
azul, números em vermelho escuro, comentários em vermelho, e literais e caracteres representados entre
aspas e apóstrofos respectivamente, em verde.

152
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Figura 1. Exemplo da interface

Quando o código é executado, uma nova janela é aberta, sendo essa o console de execução. Nela será
possível visualizar a saída do programa criado e entrar com dados quando necessário conforme a figura 2.

Figura 2. Exemplo do console em funcionamento

153
ISBN: 978-972-8939-96-0 © 2013 IADIS

3.2 Sintaxe da Linguagem

O quadro 1 mostra a estrutura sintática da linguagem em notação BNF estendida.

<Algoritmo> ::= {<Declaração de classes>} <Algoritmo Principal>

<Declaração de classes> ::= CLASSE <Nome> [<Herança>]
{<Declaração de variáveis>}
{<Declaração de procedimentos e funções>}
FIMCLASSE
<Herança> ::= HERDAR <Nome>
<Algoritmo Principal> :: ALGORITMO <Nome>
{<Declaração de variáveis>}
{<Declaração de procedimentos e funções>}
INICIO
{<Comandos>}
FIM.
<Declaração de procedimentos e funções> ::= PROCEDIMENTO <Nome> (<Parâmetros>)
{<Declaração de variáveis>}
INICIO
{<Comandos>}
FIMPROCEDIMENTO
<Declaração de procedimentos e funções> ::= FUNCAO <Nome> (<Parâmetros>) <Tipo>
{<Declaração de variáveis>}
INICIO
{<Comandos>}
FIMFUNCAO
RETORNA <Expressão>
<Declaração de variáveis> ::= <Tipo> {<Array>} id { , id}
<Tipo> ::= LITERAL | INTEIRO | REAL | LÓGICO | CARACTERE | OBJETO
<Array> ::= ‘[‘ INTEIRO ‘]’
<Variável> ::= id {<Array>} {. <Variável> }
<Parâmetros> ::= <Tipo> {<Array>} id
<Comandos> ::= <Atribuição> | <Entrada> | <Saída> | <Instancia> | <Seleção> | <Repetição> | <Chamada>
<Entrada> ::= LEIA <Variável> { , <Variável>}
<Saída> ::= ESCREVA <ItemSaída> { ,<ItemSaida>}
<ItemSaida> ::= <Variável> | <Expressão>
<Atribuição> ::= <Variável> = <Expressão>
<Instancia> ::= <Variável> = NOVO id
<Seleção> ::= SE <Expressão> ENTAO {<Comandos>} {SENAO
<Comandos>} FIMSE | CASO <Variável> SEJA {<Expressão> : <Comandos>}+ FIMCASO
<Repetição> ::= ENQUANTO <Expressão> FAÇA {<Comandos>} FIMENQUANTO | REPITA {<Comando>} ATÉ <Expressão>
| PARA id DE <Expressão> ATE <Expressão> FAÇA {<comando>} FIMPARA
<Chamada> ::= <Variável> ( {<Variável> | <Valor> } )

Nota: <Expressão> representa qualquer expressão aritmética, lógica ou relacional.

Nota 2: <Valor> representa qualquer valor alfanumérico (literal, inteiro, real...)

Quadro 1. Representação da sintaxe em BNF estendida

4. DESENVOLVIMENTO DA FERRAMENTA
O processo de tradução, conforme a figura 3, é realizado em um passo, tendo o analisador sintático como
controlador geral do processo. O analisador léxico extrai os tokens (símbolos básicos da linguagem)
classificando-os em categorias, tais como identificadores, palavras reservadas, sinais de operação e símbolos
especiais. O analisador sintático verifica se a sequência de tokens recebidos da análise léxica esta de acordo
com as regras da gramática especificada para a linguagem (usado método preditivo). O analisador semântico,
dirigido por sintaxe, determina o significado de cada construção sintática, aponta os eventuais erros e traduz
o programa fonte para uma representação intermediária de instruções, no caso o bytecode. O bytecode é então
convertido para o formato binário que é armazenado em um arquivo class, próprio para ser executado pela
JVM.

154
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Figura 3. Estrutura geral do processo de tradução

Para obter este arquivo class é utilizado um assembler que realiza as devidas conversões das instruções.
Na linguagem proposta foi utilizado o software Jasmin, um assembler muito utilizado, para criar o arquivo
class executável pela JVM. O Jasmin recebe as instruções (bytecode em formato ASCII) geradas pela
ferramenta proposta, e as converte para o arquivo class (bytecode em formato binário).
Para o desenvolvimento da ferramenta foram considerados os seguintes requisitos: seguir o paradigma de
linguagem imperativa e também o paradigma de orientação a objetos permitindo, de forma facilitada, a
construção de algoritmos através de comandos baseados em linguagem estruturada e linguagem orientada a
objetos; conter os comandos básicos da programação estruturada; além dos tipos de dados básicos de dados
como inteiro, real, literal, booleano e caractere, conter variáveis multidimensionais, como vetores e matrizes,
de todos os tipos de dados apresentados; conter o conceito de classes, objetos, e herança, vistos no paradigma
de orientação a objetos, além de conceitos como métodos com e sem retorno; permitir ao usuário escrever
programas em pseudocódigo na língua portuguesa, e executá-lo na máquina virtual do Java (JVM); permitir a
verificação dos erros de codificação, indicando-os antes de executar o código; permitir salvar e abrir os
trabalhos do usuário, com formato próprio da ferramenta; permitir ao usuário uma função de completar, ou
gerar o exemplo de uma estrutura de comandos; permitir a depuração do código passo a passo, facilitando a
visualização da execução.

5. RESULTADOS
A avaliação da ferramenta foi feita através da aplicação de testes em duas turmas, de Programação I e II do
curso de Ciência da Computação, com vinte alunos cada uma. O primeiro teste feito na turma I foi para
verificar a adaptação dos alunos à ferramenta. Foi pedido que tentassem resolver um problema simples, que
demanda escrever a região de procedência de um produto, de acordo com um código digitado pelo usuário.
Nesta turma os alunos ainda estavam aprendendo sobre orientação a objetos, desta forma foi feita uma breve
explanação sobre o assunto, abordando os tópicos básicos, como métodos, classes, instanciação e herança, e
também sobre a interface e a sintaxe da linguagem. Os alunos reagiram bem à forma como o conteúdo foi
explanado, através da sintaxe do pseudocódigo e com a ferramenta. Após as explanações, os alunos então
foram colocados diante do exercício. Primeiramente foi pedido que eles resolvessem o problema da maneira
como sabiam, com os conceitos de programação procedural. A adaptação à ferramenta e a sintaxe da
linguagem foi rápida, pois eles recentemente haviam estudado pseudocódigo. Tendo resolvido o problema,
foi pedido aos alunos que tentassem resolvê-lo utilizando os conceitos de orientação a objetos passados
anteriormente. A dificuldade dos alunos nessa etapa foi mínima, residindo apenas em como utilizar os
objetos que eles criaram. Mas os resultados foram positivos e a adaptação foi rápida.

155
ISBN: 978-972-8939-96-0 © 2013 IADIS

Já na turma II o teste foi feito para verificar o quão rápido os alunos resolveriam o problema, e se eles
teriam preferido aprender os conceitos de orientação a objetos com a ferramenta. O problema pedia para
registrar a altura, nome e idade de N pessoas, e com isso calcular a altura média entre elas, a pessoa mais alta
e a média de idade. Os alunos desta turma já conheciam os conceitos de orientação a objetos, e se
impressionaram com a maneira simples em que este foi apresentado na ferramenta. Foi feita uma explanação
sobre a sintaxe da linguagem para que eles pudessem relembrar dos comandos de pseudocódigo, e também
sobre a interface da ferramenta e seu funcionamento. Não houve dificuldade por parte dos alunos em
resolverem o problema, o que foi feito em pouco tempo. Também se adaptaram bem à ferramenta, e foram
capazes de utilizar os conceitos de orientação a objetos facilmente dentro dela.
No final de cada teste foram aplicados questionários aos alunos envolvendo as seguintes questões: quanto
à interface da ferramenta; quanto à facilidade em aprender a utilizar a ferramenta; quanto à simplicidade da
sintaxe; quanto à facilidade para identificar erros; quanto à facilidade para editar o código; quanto à execução
do código; o quanto facilita na resolução de problemas; e quanto aos recursos que a ferramenta oferece. Foi
utilizado como medida uma nota de um à quatro, sendo: um = deficiente; dois = regular; três = bom; e quatro
= excelente.
Mais de 80% das avaliações desses quesitos durante os testes foram positivas para ambas as turmas, ou
seja, entre boas e excelentes. E mais de 70% das avaliações no quesito de facilidade na resolução de
problemas, para ambas as turmas, também foram positivas.
Além desses quesitos apresentados, também foi levantada uma questão muito importante: se a ferramenta
poderia ser útil na introdução do conceito de orientação a objetos, ao invés de utilizar diretamente uma
linguagem de programação mais complexa, como o Java. Em ambas as turmas, 100% dos alunos
concordaram que a ferramenta seria sim, útil na introdução dos conceitos de orientação a objetos, justificando
que seria mais fácil aprender uma linguagem de programação que utiliza este paradigma, já sabendo os seus
conceitos.
O questionário dos professores envolveu as mesmas questões quantitativas, mas voltadas ao pedagogo.
Suas opiniões em relação aos quesitos da ferramenta foram semelhantes, e positivas. Eles concordaram que a
ferramenta é de fácil utilização e que seus comandos possuem abrangência mais do que suficiente para apoiar
no ensino. No restante dos quesitos, a avaliação foi 100% positiva. Além disso, foi-lhes questionado sobre a
importância de ter uma ferramenta deste tipo para introduzir os conceitos de orientação a objetos, e se a
ferramenta proposta seria útil nesta abordagem. Ambos concordaram com a importância da ferramenta e de
sua proposta, e que ela poderia ser muito útil no apoio a introdução dos conceitos de orientação a objetos.

6. CONCLUSÕES
O paradigma de orientação a objetos está muito presente no mercado atualmente, desta forma, é importante
que o seu ensino seja objetivo, claro, e de qualidade. Para que o mercado cresça com qualidade os
profissionais necessitam ser capacitados da mesma forma.
A ferramenta além de permitir que se trabalhe na forma tradicional com algoritmos, possibilita também
que se introduza de forma simples e objetiva os conceitos de orientação a objetos. Esta propriedade foi
percebida e comprovada claramente nas avaliações realizadas em sala de aula e junto a professores que
colaboraram com a pesquisa. Permitir aos alunos aprenderem e testarem os conceitos de orientação a objetos
em uma ferramenta simples, e em língua nativa, mostrou-se positivo de acordo com os resultados. Isso
mostra que introduzir os conceitos de orientação a objetos, antes de aplicar diretamente uma linguagem de
programação profissional, pode favorecer o aprendizado dos alunos.
O estudo indica também que a utilização de ferramentas para apoiar o ensino de programação é bem
aceita por alunos iniciantes e professores.

156
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

REFERÊNCIAS
APOIO INFORMÁTICA. VisuALG. Disponível em:
http://www.cafw.ufsm.br/~bruno/disciplinas/introd_programacao/materiais/visualg/help/objetivos.htm. Acesso em:
17 de junho de 2013.
BIJU, M. Difficulties in understanding object oriented programming concepts. University of Wollongong in Dubai:
Papers, Holanda, pp. 319-326. 2013.
BRUDERER, R. Object oriented framework for teaching introductory programming. 2005. 85 f. Tese (Mestrado em
Ciência da Computação) – Swiss Federal Institute of Technology in Zurich. Zurich, 2005.
DEMUTH, B. et al. A framework-based approach to teaching OOT: aims, implementation, and experience. CiteSeerXi,
Alemanha. 2000. Disponível em: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.4120. Acesso em: 17
de junho de 2013.
HINTERHOLZ, O. Jr. Tepequém: uma nova ferramenta para o ensino de
algoritmos nos cursos superiores em computação, In: XXIX Congresso da Sociedade Brasileira de Computação, 6.
2009, Bento Gonçalves. Anais, Boa Vista: Faculdade Atual da Amazônia, 2009. 485 – 488 p.
KÖLLING, M. The problem of teaching object-oriented programming part 1: languages. Journal of Object-Oriented
Programming, v. 11, nº 8: 8-15, 1999.
MANSO, A.; OLIVEIRA, L.; MARQUES, C. Ambiente de aprendizagem de algoritmos - Portugol IDE. Disponível em:
http://orion.ipt.pt/~manso/papers/2009/Portugol%20Challenges2009.pdf. Software disponível em:
http://www.dei.estt.ipt.pt/portugol/. Acesso em: 17 de junho de 2013.
PREVIDELLI, A. Os 11 melhores cursos de Ciência da Computação do Brasil. Disponível em:
http://guiadoestudante.abril.com.br/blogs/melhores-faculdades/category/ciencia-da-computacao/. Acesso em: 26 de
junho de 2013.
ROCHA, P. et al. Ensino e aprendizagem de programação: análise na aplicação de proposta metodológica baseada no
sistema de ensino personalizado. RENOTE: Revista Novas Tecnologias na Educação, Porto Alegre, v. 8, nº 3, 11 p.
Dezembro de 2010. SANTOS, F. Programação orientada a objetos x Programação estruturada. Disponível em:
http://www.devmedia.com.br/programacao-orientada-a-objetos-x-programacao-estruturada/11747. Acesso em: 17
de junho de 2013.
SHEETZ, S. et al. Exploring the difficulties of learning object-oriented techniques. Disponível em:
www.acis.pamplin.vt.edu/faculty/tegarden/wrk-pap/JMIS-2.PDF. Data de acesso: 17 de junho de 2013.

157
ISBN: 978-972-8939-96-0 © 2013 IADIS

AVALIAÇÃO HEURÍSTICA PARA GROUPWARES

MÓVEIS: UM ESTUDO DE CASO UTILIZANDO UM
AUDIENCE RESPONSE SYSTEM

Márcio J. Mantau, Luciana P. Araújo, Jucilane R. Citadin e Carla D.M. Berkenbrock

Departamento de Ciência da Computação, Universidade do Estado de Santa Catarina (UDESC) - Campus Universitário
Prof. Avelino Marcante – 89.219-710 – Joinville – SC – Brasil

RESUMO
Em conferências, congressos e simpósios existem questões que podem ser tratadas por aplicações que utilizam
dispositivos móveis. Neste contexto, o groupware móvel intitulado Simple Question foi desenvolvido para auxiliar na
elaboração de questionamentos ao longo do evento, utilizando os dispositivos móveis dos participantes. Este artigo tem
como o objetivo avaliar a usabilidade da ferramenta Simple Question utilizando um conjunto de 13 heurísticas. Com base
nestas heurísticas, três especialistas avaliaram a interface em três etapas: (i) exploração do sistema e de seus recursos; (ii)
avaliação da usabilidade; (iii) consolidação dos dados coletados e reflexões. Os resultados demonstram que o conjunto de
heurísticas levantadas foram eficientes, sendo que a maioria dos 11 problemas discutidos estão relacionados ao
gerenciamento de erros, métodos de entrada facilitados, e visualização e leitura dos dados.

PALAVRAS-CHAVE
Groupware Móvel , Avaliação Heurística, Usabilidade.

1. INTRODUÇÃO
A utilização adequada de dispositivos móveis durante palestras aumenta a interação entre público e o
palestrante (Teevan et al., 2012). Student Response Systems, Classroom Student Sytems, Audience Response
Systems, ou Clickers são termos utilizados para definir sistemas que podem ser utilizados durante
apresentações para fornecer um feedback ao palestrante, bem como uma maior iteração entre os participantes
(Rechenthin, Molenda, 2009).
Clickers possibilitam realizar pesquisas rápidas, de forma anônima e seus resultados podem ser utilizados
instantaneamente durante a palestra. De acordo com Esponda (2008) e Scornavacca et al. (2009), dentre os
benefícios da utilização Clickers em salas de aula pode-se citar: aumentam o interesse, a participação, a
compreensão e a discussão entre alunos; melhoram a percepção do professor das dificuldades dos alunos;
promovem um aprendizado mais efetivo; fornecem feedback para o professor; possibilitam maior motivação
dos alunos; e permitem o aprendizado coletivo. Rechenthin e Molenda (2009) mostram que, quando
utilizados corretamente, estes sistemas aumentam o envolvimento dos alunos na sala de aula.
O presente trabalho tem por objetivo avaliar a usabilidade do sistema colaborativo Simple Question a
partir de um grupo de heurísticas selecionadas. A avaliação heurística é um método consolidado e de custo
acessível, que permite identificar de forma rápida possíveis problemas no sistema avaliado (Kimura et al.,
2012). O Simple Question propõe uma nova dinâmica para reuniões presenciais. Entre suas funcionalidades
destacam-se: a elaboração de perguntas a qualquer momento sem interromper o palestrante; a utilização de
dispositivos moveis para elaborar perguntas; o anonimato do autor da pergunta; e a colaboração do publico
para seleção das melhores perguntas.
As próximas seções deste artigo estão organizadas da seguinte maneira: na Seção 2 são apresentados os
trabalhados relacionados com a presente pesquisa. Na Seção 3 é apresentado em detalhes o sistema a ser
avaliado, o Simple Question. A Seção 4 aborda as heurísticas selecionadas para a avaliação do sistema. A
avaliação da usabilidade do sistema Simple Question, realizada a partir das heurísticas, é descrita na Seção 5.
A Seção 6 apresenta os resultados obtidos. Na Seção 7 estão descritas as considerações finais e possíveis
trabalhos futuros.

158
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

2. TRABALHOS RELACIONADOS
Alguns trabalhos apresentam ferramentas do tipo Clickers para auxiliar na interação dos participantes em
grupos colocalizados. Dentre estas ferramentas, algumas são destinadas para dipositivos móveis (Lindquist et
al., 2007; Esponda 2008; Scornavacca et al., 2009; Teevam et al., 2012; Furquin et al., 2013), outras foram
desenvolvidas para serem utilizadas em ambiente desktop ou web (Rechenthin e Molenda, 2009).
Rechenthin e Molenda (2009) desenvolveram um Student Response System para a aplicação de
questionários em sala de aula. Cada aluno responde o questionário de forma individual, e ao final, o professor
tem acesso aos resultados.
Teevam et al. (2012) desenvolveram um sistema Clicker que permite ao público repassar o feedback ao
palestrante. O sistema é constituído de três componentes: cliente móvel, que fornece o feedback; visualização
compartilhada, para apresentar o feedback; e widgets desenvolvidos para incluir o palestrante no feedback. O
cliente móvel permite que os usuários forneçam o feedback positivo ou negativo da palestra. O aplicativo é
acessado via navegador web instalado no dispositivo (smartphones, tablets, laptops), através de uma URL.
Os resultados coletados pelos clientes móveis são apresentados diretamente em uma visualização
compartilhada, constituída de uma barra lateral disposta juntamente com a apresentação de slides. Os widgets
foram projetados para lembrar os membros da audiência a fornecer feedback e chamar a atenção quanto
situações interessantes ocorrem (grande quantidade de feedbacks positivos ou negativos, um grande período
de inatividade, grande quantidade de participantes, dentre outros).
Esponda (2008) desenvolveu um sistema intitulado Classroom Response System (CRS’s) para ser
utilizado via navegador de dispositivos móveis (smartphones ou tablets). O sistema permite realizar
perguntas de forma espontânea, no momento em que a pergunta surge (on-the-fly), mas também há a
possibilidade de aplicar questionários pré-elaborados.
Scornavacca et al. (2009) apresentam um sistema denominado de TXT-2-LRN (text-to-learn), que utiliza
mensagens SMS para que os alunos respondam as perguntas levantadas pelo professor durante as aulas. De
acordo com os autores, a utilização do sistema gerou um aumento na qualidade de feedback dos alunos, bem
como melhorou o interesse e a participação dos alunos.
Lindquist et al. (2007) desenvolveram um sistema que permite aos alunos apresentar soluções para os
exercícios propostos, de forma textual ou através de fotos, utilizando-se de seus dispositivos móveis.
Alguns autores desenvolvem modelos ou frameworks para melhorar os aspectos de colaboração em
aplicações móveis. González e Ruggiero (2006) apresentam um modelo conceitual de aprendizagem
colaborativa baseada na execução de projetos. Silva e Rabelo (2012) apresentam um sistema com suporte a
decisão com base em um protocolo de decisão como apoio gerencial.

3. SIMPLE QUESTION
O Simple Question foi desenvolvido para possibilitar a colaboração dos participantes de palestras, na
elaboração de perguntas a partir de dispositivos móveis (Balestrin et al., 2011). Esta ferramenta permite que
as perguntas possam ser realizadas a qualquer momento do evento sem a necessidade de interromper a
palestra e de forma anônima. Ao longo da palestra o público pode escolher de forma colaborativa as
perguntas de maior interesse.
O sistema desenvolvido consiste em duas interfaces principais: a interface móvel utilizada para a
realização das perguntas dos participantes, e a interface do mediador. O mediador será o responsável por ler
as perguntas realizadas pelos participantes e dirigi-las ao palestrante.
Furquin et al. (2013) desenvolveram novas funcionalidades no Simple Question apresentado por Balestrin
et al. (2011): verificação do entendimento da resposta, ou seja, após a pergunta ser respondida pelo
palestrante, pode-se verificar se o público conseguiu entender a resposta; filtragem das perguntas na interface
do mediador, útil em palestras com um grande volume de perguntas; ordenação das perguntas por diferentes
atributos, tais como título, autor e número de votos; e ajuste de visualização, permitindo que a aplicação se
ajuste de uma forma adequada a diferentes resoluções de tela.

159
ISBN: 978-972-8939-96-0 © 2013 IADIS

Para participar da sessão colaborativa, é necessário que os participantes tenham dispositivos móveis com
acesso a rede Wi-Fi e um navegador web instalado. A aplicação possui suporte aos idiomas inglês e
português. Após efetuado o login no sistema é apresentado a tela com as respectivas perguntas da sessão
atual, conforme a Figura 1(a).
A partir da tela apresentada na Figura 1(a), o usuário tem a possibilidade de adicionar uma nova pergunta
bem como visualizar ou apoiar uma pergunta já existente. O processo para adicionar uma nova pergunta é
apresentado na Figura 1(b). Caso o usuário queira visualizar as informações de uma pergunta, ele deverá
selecioná-la na listagem da Figura 1(a), fazendo que esta seja exibida na tela como apresentado na Figura
1(c). Nesta tela o usuário tem a possibilidade de apoiar a pergunta, o que permite verificar, ao longo das
atividades, quais são as perguntas de maior interesse do público.
O Simple Question permite que os participantes avaliem as respostas dadas às perguntas, como
apresentado na Figura 1(d). Estes dados são convertidos em estatísticas e podem ser utilizados para avaliar o
desempenho do palestrante.

Figura 1. a) Apresentação das perguntas realizadas; b) Tela para realizar uma nova pergunta; c) Tela para visualizar e
apoiar uma pergunta realizada; d) Tela para a avaliação do entendimento da resposta.
A colaboração no sistema Simple Question se dá pelo fato dos participantes poderem votarem nas
perguntas dos outros durante a palestra. Os participantes podem apoiar uns aos outros, fazendo com que a
pergunta fique em uma colocação melhor na interface do mediador, tendendo a ser respondida. Outro fator
que envolve a colaboração é o feedback dos participantes com relação a resposta dada pelo palestrante. Cada
participante pode, individualmente, votar se a pergunta foi bem respondida ou não, permitindo que todos os
participantes da palestra tenham um feedback sobre a qualidade de sua resposta.
Para organizar e acompanhar o andamento da reunião, bem como dirigir as perguntas elaboradas pelos
participantes ao palestrante, foi desenvolvida a interface do mediador. A Figura 2 apresenta a tela principal
dessa interface. Como a interface foi desenvolvida para o ambiente web, é possível acessá-la através de
computadores fixos ou móveis. A partir desta interface, o mediador pode criar, editar, abrir, salvar e fechar as
sessões de perguntas. As perguntas realizadas são exibidas na interface do medidor em ordem decrescente de
apoios. Assim sendo, as perguntas mais relevantes na opinião dos participantes serão visualizadas primeiro.

Figura 2. Interface da aplicação do mediador.

160
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

4. AVALIAÇÃO HEURÍSTICA
A avaliação heurística é um método de inspeção de usabilidade em que a avaliação é realizada com base em
um conjunto de heurísticas, e que descrevem características desejáveis na interação, orientando os
avaliadores a inspecionar a interface em busca de problemas que prejudiquem a usabilidade (Nielsen, Mack,
1994).
Realizar uma avaliação heurística consiste basicamente em analisar a interface para relatar problemas
que, segundo a opinião dos avaliadores, não estejam de acordo com princípios de usabilidade. Nesse método,
os especialistas examinam o sistema e fazem um diagnóstico dos problemas e das barreiras que os usuários
provavelmente encontrarão durante a interação (Barbosa e Silva, 2010). Recomenda-se de três a cinco
avaliadores para a avaliação. Este método é consideravelmente rápido e apresenta um custo inferior em
relação a outros métodos de avaliação (e.g. experimentos/intervenções com usuários).
O conjunto de heurísticas proposto por Nielsen permite aos avaliadores analisar e avaliar a interface a
procura de problemas de usabilidade (Nielsen e Mack, 1994). Contudo, este conjunto de heurísticas foi
concebido para aplicações convencionais e está preocupado apenas com as questões de interação entre
usuário-sistema. Os aspectos de colaboração, essenciais em um sistema groupware, não são contemplados
por este conjunto. Baker et al. (2001) relatam que a avaliação de groupwares é mais difícil do que sistemas
convencionais, pois as metodologias de avaliação de usabilidade nem sempre possibilitam descobrir
problemas específicos do trabalho em grupo.
Baker et al. (2001) definiram um conjunto de heurísticas para avaliar a colaboração em sistemas
groupware, e foram baseadas em heurísticas convencionais (i.e. heurísticas de Nielsen). Apesar de estas
heurísticas não serem específicas para dispositivos móveis, elas apresentam questões importantes que devem
ser atendidas em qualquer groupware a fim de facilitar a colaboração.
Bertini et al. (2009) definiram um conjunto de heurísticas para avaliar aplicações especificamente
desenvolvidas para dispositivos móveis. Este conjunto de heurísticas também foi baseado nas heurísticas de
avaliação convencional, com as heurísticas de Nielsen e Mack (1994).
Para a avaliação apresentada neste trabalho, serão utilizados aspectos importantes com relação a
colaboração encontrados nos três conjuntos de heurísticas apresentados anteriormente (Nielsen e Mack,1994;
Baker et al., 2001; Bertini et al., 2009). Os três conjuntos mostram-se complementares para a avaliação de
groupwares móveis, pois as heurísticas apresentadas por Nielsen e Mack (1994) avaliam a usabilidade de
sistemas de propósito geral, as heurísticas apresentadas por Baker et al. (2001) avaliariam as questões
referentes à colaboração, e as heurísticas apresentadas por Bertini et al. (2009) avaliam as questões referentes
aos dispositivos móveis. Neste trabalho foram adotadas as seguintes heurísticas:
H1 - Visibilidade do estado do sistema: o sistema deve fornecer feedback adequado aos usuários dentro
de um tempo razoável. Através do dispositivo móvel o sistema deve manter o usuário informado sobre o que
está ocorrendo. Além disso, o sistema deve priorizar mensagens a respeito de informações críticas e de
contexto, como status da rede, bateria e condições do ambiente (Nielsen e Mack, 1994; Bertini et al., 2009).
H2 - Compatibilidade do sistema com o mundo real: o sistema deve usar termos familiares ao usuário
ao invés de termos orientados ao software. Devem ser seguidas convenções do mundo real de modo que as
informações apareçam numa ordem sequencial e lógica (Nielsen e Mack, 1994; Bertini et al., 2009). As
informações devem ser apresentadas de forma natural e em uma ordem lógica, e sempre que possível o
sistema deve ter a capacidade de perceber as mudanças no ambiente e adaptar-se a ele (sistemas conhecidos
como context-aware systems).
H3 - Consistência e mapeamento: um usuário não deve adivinhar que diferentes palavras, situações ou
ações significam a mesma coisa. O modelo conceitual de interação do usuário com o sistema deve estar de
acordo com o contexto. O mapeamento entre as ações e interações do usuário (e.g. controles de navegação) e
a tarefa real correspondente (e.g. navegação no mundo real) deve ser consistente (Nielsen e Mack, 1994;
Bertini et al., 2009).
H4 - Reconhecimento ao invés de memorização: tornar objetos, ações e opções visíveis. O usuário não
deve ter que lembrar uma informação de uma parte para outra do diálogo. Instruções devem estar visíveis ou
ser de fácil recuperação quando necessárias (Nielsen e Mack, 1994).
H5 - Flexibilidade e eficiência de uso: prover meios para usuários experientes acelerarem a interação e
de apoiar usuários novatos. Permitir que os usuários personalizem ações frequentes, bem como configurem o
sistema de acordo com a necessidade do contexto (Nielsen e Mack, 1994; Bertini et al., 2009).

161
ISBN: 978-972-8939-96-0 © 2013 IADIS

H6 – Design estético e minimalista: diálogos não devem conter informações irrelevantes ou raramente
necessárias. Exibir apenas as informações que sejam importantes e necessárias. Os recursos de tela são
propriedades escassas e devem ser utilizadas com sabedoria (Nielsen e Mack, 1994; Bertini et al., 2009).
H7 - Gerenciamento de erros: mensagens de erro devem ser expressas com linguagem clara indicando o
problema e construtivamente sugerindo uma solução. Proteger os usuários dos erros que podem ocorrer.
Auxiliar o usuário a reconhecer, diagnosticar e se possível recuperar-se do erro ocorrido (Nielsen e Mack,
1994; Bertini et al., 2009).
H8 - Facilidade de entrada, visualização, e leitura da tela: dispositivos móveis devem fornecer meios
facilitados para entrada de dados, os dados apresentados na tela devem ser fáceis de serem lidos e navegados.
É ideal apresentar apenas informações cruciais sobre o sistema (Bertini et al., 2009).
H9 - Convenções estéticas, sociais e privativas: Levar em consideração aspectos estéticos e emocionais
a serem apresentados nos dispositivos móveis. Deixar claro que as informações do usuário estão seguras
(Bertini et al., 2009).
H10 - Fornecer comunicação de artefatos compartilhados (i.e. feedthrough): uma importante
necessidade de um groupware é disponibilizar informações sobre as ações dos outros usuários, reconhecer o
que os outros estão fazendo com os artefatos compartilhados (Baker et al., 2001).
H11 - Fornecer proteção: Em workspaces compartilhados o acesso simultâneo a um mesmo conjunto de
artefatos pode ocasionar conflitos. Em alguns casos, as ações de um usuário podem vir a interferir nas
atividades dos demais, e assim sendo, o sistema deve disponibilizar mecanismos para que estes conflitos não
ocorram (Baker et al., 2001).
H12 - Gerenciamento de colaboração de baixo e alto acoplamento: o acoplamento é o grau que as
pessoas trabalham em conjunto, e representa a quantidade de trabalho que uma pessoa pode realizar antes de
precisar discutir, consultar ou pedir uma informação para outra pessoa (Baker et al., 2001).
H13 - Permitir que as pessoas coordenem suas ações: um dos problemas encontrados ao longo da
colaboração face a face é como o grupo media suas interações. Ações de coordenação envolvem realizar as
tarefas na ordem certa, no momento certo, sem ignorar as restrições impostas (Baker et al., 2001).
Para cada problema encontrado segundo as heurísticas apresentadas, deve-se associar a uma gravidade,
que é baseada na combinação de três fatores (Kimura et al., 2012): i) A frequência com que ele ocorre (i.e. se
é comum ou raro); ii) O impacto do problema quando ele ocorre (i.e. se é fácil ou difícil para o usuário
superá-lo); iii) A persistência do problema (i.e. problema que ocorre uma única vez e que o usuário pode
superar, ou se os usuários serão repetidamente incomodados por ele).
Esses fatores influenciam os níveis de gravidade utilizados na avaliação, que podem ser classificados
como (Nielsen, Mack, 1994): 0) Não é encarado como um problema; 1) Problema estético que não tem
necessidade de ser corrigido; 2) Problema pequeno com baixa prioridade na correção; 3)Problema grande,
com alta prioridade de correção; 4) Problema catastrófico, onde é indispensável sua correção.

5. AVALIAÇÃO HEURÍSTICA DO SIMPLE QUESTION

A avaliação heurística do Simple Question foi realizada por três avaliadores, todos com conhecimento prévio
do método de avaliação, e também do ambiente a ser avaliado. A avaliação foi realizada apenas na interface
móvel da aplicação, conforme apresentada na Seção 3. A ferramenta Simple Question foi acessada via
browser sob o sistema operacional Android 2.2. Foi utilizado um dispositivo móvel, a saber, Samsung
Galaxy Tab P1000L e dois emuladores Android 2.3.
O processo de avaliação foi realizado em três etapas, como apresentado por (Kimura et al., 2012): i) uma
exploração do sistema, buscando e entendendo as funcionalidades a serem avaliadas; ii) período de avaliação,
onde cada avaliador utilizou o sistema separadamente, inspecionando a interface; iii) consolidação das
informações, onde os avaliadores compartilharam os problemas levantados, discutindo suas respectivas
gravidades e identificando possíveis soluções.
Ao final da avaliação, foram identificadas as seguintes informações: i) problema encontrado; ii)
Heurística violada; iii) Gravidade associada; iv) possível solução encontrada.

162
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

6. RESULTADOS
A avaliação heurística encontrou 11 problemas de usabilidade, sendo que cada um dos avaliadores encontrou
um conjunto diferente de problemas. A Figura 3 apresenta a distribuição dos problemas encontrados para
cada um dos avaliadores.
A distribuição dos problemas encontrados, conforme apresentado na Tabela 1, indica que os principais
problemas do Simple Question estão relacionados aos aspectos do gerenciamento de erros (H7) e facilidade
de entrada, visualização e leitura das informações (H8).

Figura 3. Distribuição dos problemas encontrados

Tabela 1. Resumo das heurísticas, problemas e gravidade

Heurística Problemas Gravidade média

H1 3e4 3
H2 5 2
H3 3e4 3
H4 -- --
H5 6 2
H6 11 2
H7 1, 2 e 7 3
H8 7, 8 e 9 3
H9 -- --
H10 -- --
H11 -- --
H12 10 3
H13 -- --

Não foi encontrado nenhum problema com baixa gravidade de correção (gravidade 1), ou que seja
considerado uma catástrofe de usabilidade (gravidade 4). Outro aspecto que pode ser observado, é que para
as heurísticas H4, H9, H10, H11, e H13, não foi encontrado nenhum problema de usabilidade, o que
demonstra que o aplicativo Simple Question está de acordo com o defendido por estas heurísticas.

6.1 Principais Problemas Encontrados

Problema 1: Mensagens de erro são exibidas na interface do usuário sem nenhuma forma de tratamento (e.g.
erros de SQL). Esse problema viola a H7 e é classificado como uma gravidade de grau 3. Como solução
sugere-se tratar os erros SQL, e, caso haja a necessidade de informar ao usuário sobre a ocorrência de um
erro, apresentá-lo em uma linguagem natural ao usuário.
Problema 2: O tamanho máximo de uma pergunta no Simple Question é de 1000 caracteres, entretanto ao
fazer uma pergunta com comprimento maior não é informado nenhum erro ao usuário. E ainda é apresentada
uma mensagem informando que a pergunta foi registrada com sucesso, porém a mesma não é listada junto as
perguntas realizadas. Esse problema também viola a H7, sendo classificado como uma gravidade de grau 3.
Como solução indica-se que seja tratado o limite do campo em tela, avisando o usuário e permitindo os
ajustes necessários na pergunta.

163
ISBN: 978-972-8939-96-0 © 2013 IADIS

Problema 3: Falta de feedback ao usuário quanto à situação do sistema e as ações efetuadas por ele (e.g.
que perguntas fez, quais apoiou, quais avaliou). O usuário descobre com o uso que as perguntas apoiadas por
ele ficam na cor verde. O problema viola a H1 e a H3 e também é classificado como uma gravidade de grau
3. Como solução, aconselha-se a definição de uma legenda indicando o significado das cores e ícones, para
que fique claro ao usuário o status do sistema.
Problema 4: Confusão ao identificar a pergunta avaliada, pois independentemente se o usuário entendeu
ou não a resposta para a pergunta é apresentado na interface o mesmo ícone, indicando apenas que foi
avaliada (e.g. aparece o ícone para a pergunta avaliada, ainda que a resposta não tenha sido
compreendida). O problema também viola H1 e H3 e é classificado com gravidade de grau 3. Como solução
sugere-se definir ícones ou cores diferentes para pergunta entendida e não entendida, por exemplo:
positivo/verde – para entendida; e negativo/vermelho – para não entendida.
Problema 5: Permite ao usuário iniciar uma ação bloqueada, confundindo a lógica do processo (e.g. ao
clicar numa pergunta já apoiada, não é bloqueado o botão de apoio. O sistema informa o usuário que a
pergunta já foi apoiada por ele, apenas após ele tentar apoiar novamente). Esse problema viola H2 e é
classificado como gravidade de grau 2. Como solução indica-se que além da legenda de cores já comentada,
seja bloqueado o botão de apoio, já que a ação não pode mais ser executada pelo participante.
Problema 6: Perda da configuração escolhida pelo usuário (e.g. ao mudar a ordenação das perguntas e
então navegar dentro delas, ao voltar no contexto inicial a ordenação se perde, limitando a alteração da
aparência do sistema). Esse problema viola H5 e possui grau de gravidade 2. Como solução aconselha-se
manter a ordenação escolhida pelo usuário ao voltar no contexto inicial após a navegação.
Problema 7: Tratamento de erro inadequado e perda da entrada de dados do usuário (e.g. quando o
usuário utiliza um título já existente para a pergunta, o sistema trata o erro porém perde a pergunta digitada).
O problema viola H7 e H8 e é classificado como gravidade de grau 3. Como solução recomenda-se manter a
pergunta digitada, editando apenas o campo título para que seja substituído.
Problema 8: Falta de paginação nas perguntas (e.g. não há como paginar as perguntas com opção para
voltar a uma página anterior, ir para a próxima página). Esse problema viola H8 e também é classificado
como gravidade de grau 3. A solução para ele é fazer a paginação e permitir a navegação nas diferentes
páginas das perguntas.
Problema 9: A atualização das informações (e.g. lista de perguntas, participantes, número de apoios)
deve ser realizada de modo manual. Caso o usuário não faça constantemente a atualização da aplicação, sua
interação ficará prejudicada, pois não terá acesso a novas perguntas. O problema viola H8 e é classificado
como gravidade de grau 2. Para solução sugere-se fazer a atualização dos dados automaticamente, para
manter a integridade do ambiente visualizado pelo usuário.
Problema 10: Falta de mecanismo de busca para as perguntas (e.g. não permite ao usuário buscar
perguntas já realizadas por título ou palavra). Desta forma o usuário não visualiza se uma determinada
pergunta já foi feita, prejudicando a colaboração. O problema viola H12 e é classificado com gravidade de
grau 3. Como solução é recomenda-se permitir buscar perguntas por título ou palavras.
Problema 11: Não há separação entre as perguntas já respondidas e as ainda não respondidas (e.g. as
perguntas ficam ordenadas conforme configuração definida e não há separação para as perguntas já
respondidas/não respondidas). O problema viola H6 e é classificado como gravidade de grau 2. Como
solução é sugerida a definição de locais separados para as perguntas respondidas e não respondidas
melhorando o design estético da aplicação.

7. CONCLUSÃO
Este trabalho apresenta um conjunto de 13 heurísticas elaboradas para avaliar a usabilidade de aplicações
colaborativas móveis. Estas heurísticas foram elaboradas com base em três conjuntos de heurísticas presentes
na literatura: as heurísticas de Nielsen para avaliar a usabilidade de aplicações convencionais, ou seja, avaliar
os aspectos da interação humano-computador (Nielsen e Mack,1994); as heurísticas de Baker desenvolvidas
para avaliar os aspectos de colaboração (Baker et al., 2001); e as heurísticas de Bertini desenvolvidas para
avaliar a usabilidade de aplicações móveis (Bertini et al., 2009).

164
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Com o conjunto de heurísticas levantadas neste trabalho, foi possível avaliar a usabilidade e a eficiência
de um sistema colaborativo para dispositivos móveis, denominado Simple Question. Percebe-se que dentre as
13 heurísticas levantadas, algumas não encontraram problemas de usabilidade na interface (H4, H9, H10,
H11 e H13), o que indica que o sistema avaliado está em conformidade com o defendido por estas
heurísticas. Conforme apresentado, 6 dos 11 problemas levantados estão relacionados ao gerenciamento de
erros (H7), facilidade de entrada, leitura e visualização das informações (H8), o que indica que a aplicação
precisa melhorar sua interface em relação a esses aspectos.
Com base na avaliação realizada, sugere-se que as heurísticas levantadas sejam aplicáveis para avaliar
outros groupwares móveis. Os requisitos analisados no sistema Simple Question atendem várias heurísticas
abordadas. Contudo, algumas heurísticas não foram atendidas, mostrando que há detalhes a serem
melhorados no sistema em questão.

REFERÊNCIAS
Baker, K. et al., 2001. Heuristic Evaluation of Groupware Based on the Mechanics of Collaboration. Proceedings of the
8th IFIP Working Conference on Engineering for Human-Computer Interaction. Toronto, Canada. pp. 123-139.
Balestrin, G. et al., 2011. Uma Ferramenta de Colaboração Móvel para Auxiliar a Interção em Palestras Presenciais.
Proceedings of XI Brazilian Symposium on Collaborative Systems, Paraty, RJ.
Barbosa, S.D.J. and Silva B.S., 2010. Interação Humano-Computador. Editora Campus.
Bertini, E. et al., 2009. Appropriating Heuristic Evaluation for Mobile Computing. International Journal of Mobile
Computer Interaction.
Esponda M. 2008. Electronic voting on-the-fly with mobile devices. In ACM SIGCSE Bulletin.Vol. 40, No. 3, pp. 93-97.
Furquin, A. et al., 2013. Simple Question: Uma Extensão da Ferramenta de Colaboração Móvel para tornar
Apresentações mais Efetivas. Proceedings of VI SULCOMP. Criciúma, SC.
González, L.A.G. and Ruggiero, W.V. 2006. Modelo Aprendiz para atividades colaborativas de projeto em Sistemas de
Aprendizagem Eletrônico. Revista IEEE América Latina. Vol. 4, pp. 283-288.
Kinura, M.H. et al., 2012. Avaliação de usabilidade das funcionalidades assíncronas de privacidade do Facebook.
Proceedings of IV WAIHCWS - Workshop on Aspects of Human-Computer Interaction for the Social Web.
Lidquist, D. et al, 2007. Exploring the Potential of Mobile Phones for Active Learning in the Classroom. In ACM
SIGCSE Bulletin 39.1. pp. 384-388.
Nielsen, J. and Mack R.L., 1994. Usability inspection methods. John Wiley & Sons, Inc.
Rechenthin, M. and Molenda, P. 2009. Student Response Systems. Loyola University Chicago, Chicago.
Scornavacca, E. et al. 2009. Mobile phones in the classroom: if you can't beat them, join them. Communications of the
ACM. Vol. 52, No. 4, pp. 142-146.
Teevan, J. et al., 2012. Displaying Mobile feedback during a Presentation. In Proceedings of the 14th international
conference on Human-computer interaction with mobile devices and services. pp. 379-382.
Silva, M.V.D. and Rabello, R.J., 2012) A semi-automated distributed decision support system virtual enterprises. IEEE
Latin America Transactions, Vol. 10, No. 1, pp. 1235-1242.

165
ISBN: 978-972-8939-96-0 © 2013 IADIS

UM SERVIÇO DE GERENCIAMENTO DE QUALIDADE DE

CONTEXTO EM REDES DE SENSORES SEM FIO

Joéver Silva Hoffman1, Isaac S. A. Pereira1, Sérgio Teixeira1,2,3, Janaína Scal Duia Castello1,
José Gonçalves Pereira Filho1 e Patricia Dockhorn Costa1
1
Universidade Federal do Espírito Santo (UFES), Vitória, ES, Brasil
2
Universidade Católica de Brasília (UCB), Brasília, DF, Brasil
3
Faculdade Católica Salesiana do Espírito Santo (FCSES), Vitória, ES, Brasil

RESUMO
Aplicações sensíveis ao contexto são uma categoria emergente de sistemas computacionais que utilizam informações
contextuais como meio de enriquecer a interação humano-computador. Essas aplicações se caracterizam por adaptar o seu
comportamento de acordo com a situação do usuário e do ambiente físico que o cerca. Redes de Sensores sem Fio
(RSSF) são consideradas importantes fontes de contexto. No entanto, falhas nos nós sensores decorrentes de problemas
nas plataformas de hardware e de características particulares dos ambientes em que as RSSF são instaladas, impõem uma
série de desafios quanto à gestão eficiente da informação de contexto, por exemplo, a necessidade de tratamento de
eventuais imperfeições nos dados coletados. Parâmetros de Qualidade de Contexto (QoC – Quality of Context) podem ser
usados para resolver conflitos que surgem na tomada de decisão baseada em informações contextuais imperfeitas. Este
trabalho propõe um serviço de gerenciamento de qualidade de contexto em redes de sensores sem fio que fornece
facilidades para análise, processamento e entrega de dados de QoC às aplicações sensíveis ao contexto.

PALAVRAS-CHAVE
Redes de Sensores sem Fio; Aplicações Sensíveis ao Contexto, Qualidade de Contexto

1. INTRODUÇÃO
O conceito de Computação Pervasiva, sugerido por Weiser (1991), vislumbra inteligência computacional
permeando o cotidiano das pessoas. No cenário vislumbrado por Weiser, uma grande variedade de dispositivos
com inteligência embarcada alimentam aplicações e serviços que suportam, de forma orgânica, as atividades
rotineiras das pessoas. Avanços recentes nas áreas de comunicação móvel e sem fio, microeletromecânica,
tecnologias de sensores e sistemas embarcados (Yick et al. 2008) têm contribuído para a concretização da
proposta de Weiser, ao permitir a construção e a disponibilização, cada vez mais corriqueira, de diversos tipos
de novos “objetos inteligentes” (smart objects).
As Redes de Sensores sem Fio (RSSF) são um exemplo de infraestrutura de comunicação inteligente
formada a partir de um certo arranjo topológico de objetos ou nós sensores com inteligência embarcada. Com
base em dados fonecidos por uma RSSF é possível adaptar pró-ativamente o comportamento das aplicações e
serviços de acordo com a situação e necessidades dos usuários. Tal capacidade é conhecida como
“sensibilidade ao contexto” (context-awareness). Nesse caso, contexto é entendido como qualquer informação
que caracterize a situação de uma pessoa, lugar ou objeto relevante para a aplicação. (Dey, 1999; Costa, 2007).
De acordo com (Henricksen & Indulska, 2004), as aplicações sensíveis ao contexto geralmente assumem
que a informação contextual é completa e acurada; entretanto, como resultado de ruídos, falhas nos sensores e
outros fatores, os dados sensoriados podem estar sujeitos a erros. Diante disso, um desafio na construção de
serviços e aplicações sensíveis ao contexto é saber como lidar com contextos imperfeitos, visto que eles
podem ocasionar comportamentos inadequados das aplicações.
Parâmetros de “Qualidade de Contexto” (QoC – Quality of Context) podem ser usados para medir a
qualidade da informação e resolver conflitos que surgem na manipulação de informações contextuais.
(Buchholz et al., 2003), (Manzoor et al., 2008) e (Neisse et al., 2008) sugerem um conjunto de métricas de
qualidade relevantes no escopo das aplicações sensíveis ao contexto, as quais podem ser usadas como

166
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

indicadores da qualidade da informação contextual e servir de base para a implementação de infraestruturas de

apoio ao gerenciamento da qualidade de contexto. De acordo com (Zimmer, 2006), (Manzoor et al., 2008)
existem poucas aplicações que consideram informações de QoC sobre os dados adquiridos – ou o fazem de
forma insatisfatória. Atualmente, existe uma percepção clara de que as aplicações sensíveis ao contexto reais
ou mais complexas devam ser desenvolvidas com ciência dos problemas inerentes à aquisição de dados
contextuais.
Este artigo apresenta uma infraestrutura de gerenciamento de QoC que visa apoiar o desenvolvimento de
serviços e aplicações sensíveis ao contexto que assumem a existência de imperfeição nos dados coletados. A
solução proposta inclui a definição e a implementação de uma arquitetura conceitual que realiza a aquisição,
avaliação e distribuição de contexto com QoC agregado e que permite a configuração flexível de requisitos de
qualidade relativos às aplicações-clientes. O sistema fornece ainda um valor global de qualidade, calculado a
partir da importância relativa de cada um dos parâmetros de qualidade.
O restante do artigo está assim organizado: a Seção 2 apresenta alguns trabalhos relacionados; a Seção 3
introduz um cenário de uso; a Seção 4 apresenta o modelo de métricas de QoC adotado e a arquitetura
conceitual proposta; a Seção 5 trata da implementação realizada e, finalmente, a Seção 6 conclui o trabalho.

2. TRABALHOS RELACIONADOS
A investigação sobre a natureza imperfeita da informação contextual, a proposição de métricas de qualidade de
contexto e as arquiteturas de suporte à manipulação de QoC já podem ser vistas nos trabalhos de (Dey et al.,
2000; Buchholz et al., 2003; Schmidt, 2004). Desde a introdução do termo Quality of Context (QoC),
atribuída a (Buchholz et al., 2003), uma série de trabalhos sugerindo diferentes parâmetros de QoC foram
propostos na literatura. Devido à ausência de padronização dos indicadores de qualidade, vários trabalhos
posteriores, tais como (Manzoor et al., 2008; Krause & Hochstatter, 2005; Bu, 2006), exploraram a definição
de novas métricas e processos de avaliação de QoC.
De acordo com (Buchholz et al., 2003; Krause & Hochstatter, 2005; Manzoor et al., 2008), são métricas
importantes de avaliação da QoC: (i) Precision – conformidade do dado informado com a realidade, (ii)
Trustworthiness – probabilidade da informação estar correta; (iii) Resolution – refere-se à granularidade da
informação; e (iv) Up-to-dateness (que em alguns trabalhos é citada como Freshness) – o quão recente é a
informação recebida. Outros trabalhos, como (Gray & Salber, 2011; Toninelli, 2009), sugerem parâmetros
como: Coverage, relevance e completeness. (Neisse et al., 2008) propõe um conjunto de métricas (Accuracy,
Precision, Temporal Resolution) alinhadas com definições de qualidade do vocabulário da International
Organization for Standardization (ISO).
Em um linha de pesquisa paralela, na qual o presente trabalho se inclui, arquiteturas de avaliação de QoC
são investigadas, geralmente propostas como uma camada entre aplicações e as fontes de dados das quais
dependem. Exemplos desta abordagem são os trabalhos de (Abid, 2009; Manzoor, 2010; Filho et al., 2010) e
mais recentemente de (Zheng et al. 2012), que descrevem a integração de QoC a frameworks e sistemas de
middleware provedores de contexto. Estes trabalhos propõem o uso de middleware para o desacoplamento
entre as aplicações e a heterogeneidade dos sensores de contexto e o uso dos mesmos para aferir qualidade de
contexto. (Abid, 2009) realiza a integração de QoC a um framework provedor de contexto já existente
(COSMOS). Essa abordagem permite a comunicação de QoC como metadado na entrega de pacotes de dados
contextuais ou separadamente, além de permitir a fácil extensão do serviço com novas métricas de QoC. Em
(Manzoor, 2010) é apresentada uma arquitetura centrada em serviço para inferir o valor de informações de
contexto, agregando métricas de QoC de acordo com requisitos de um dado serviço consumidor de contexto.
(Filho et al., 2010) e (Zheng et al. 2012), apresentam arquiteturas com composições similares. Ambos
apresentam as camadas de coleta ou obtenção de contexto, avaliação de qualidade e entrega de dados como
elementos-chave da arquitetura. Ainda, (Zheng et al. 2012), apresenta os chamados planos de configuração de
qualidade como uma forma de usuários (consumidores de contexto) ajustarem particularidades da avaliação de
QoC para si.
Este trabalho lança mão de uma arquitetura semelhante a (Filho et al., 2010) e (Zheng et al. 2012). No
entanto, como diferencial, há um esforço para tornar a arquitetura mais centrada nos usuários do serviço, com
uma interface rica e intuitiva. Nossa arquitetura permite, por meio de um front-end, (i) a configuração das
métricas e pesos relativos aos clientes de contexto (semelhante aos planos de configuração de qualidade de

167
ISBN: 978-972-8939-96-0 © 2013 IADIS

Zheng), (ii) o monitoramento do processo de avaliação de QoC (estatísticas e gráficos) e (iii) a simulação de
um ambiente de RSSF, que facilita o ajuste do serviço para entrega de contexto de melhor qualidade por
usuários não-desenvolvedores, mas especialistas do domínio do problema.

3. CENÁRIO DE APLICAÇÃO
A poluição do ar está se tornando uma problema cada vez mais preocupante nas grandes cidades, com
consequências sérias para a saúde das populações urbanas e impacto direto na rede hospitalar devido ao
aumento do número de pacientes, principalmente crianças e idosos. Uma das causas que podem ser apontadas
é o rápido aumento da frota de veículos que, aliado ao crescimento desordenado das grandes cidades, tem
diminuído a qualidade do ar que respiramos. De acordo com pesquisa realizada pela Organização Mundial de
Saúde (OMS), no período de 2006 a 2009, respirar o ar da capital do Estado de São Paulo, por exemplo,
equivale a fumar dois cigarros por dia. Outra pesquisa realizada pela Universidade de São Paulo (USP) em
parceria com a Secretaria Estadual de Saúde (SESA) e o Instituto Estadual de Meio Ambiente (IEMA) do
estado do Espirito Santo, apontou um aumento de 19% nas internações de adultos em dias mais poluídos na
Grande Vitória.
De modo geral, as soluções de monitoramento de ar existentes são de alto custo e de baixa granularidade,
pois as medidas são limitadas aos locais de presença das estações. Por exemplo, em uma região metropolitana
como a da Grande Vitória, existem apenas nove estações de monitoramento em operação na Rede Automática
de Monitoramento da Qualidade do Ar (RAMQAr) do IEMA. Essas questões prejudicam uma avaliação mais
eficaz da qualidade do ar das metrópoles pois os resultados são sensíveis a arbitrariedade do posicionamento
das estações (IEMA, 2013).
Uma alternativa barata frente aos elevados custos e complexidade das atuais redes de monitoramento da
qualidade do ar é o Air Quality Egg (AQE) (Air Quality Egg, 2013), um projeto que propõe a criação de uma
comunidade aberta de monitoramento da qualidade do ar de forma cooperativa (crowdsourcing). O projeto, de
código aberto, engloba o hardware e software do sensor e o compartilhamento dos dados com as medidas
atmosféricas como temperatura, umidade e de poluentes, realizadas pelos sensores que ficam disponíveis na
infraestrutura de sensor-cloud que também faz parte do projeto AQE.
Os sensores AQE são capazes de monitorar temperatura, humidade, índices de Monóxido de Carbono
(CO), Dióxido de Nitrogênio (NO2), Material Particulado (PTS), Partículas Inaláveis com diâmetro inferiores a
dez microns (PM10), Dióxido de Enxofre (SO2), Óxidos de Nitrogênio (NOx), Hidrocarboneto (HC), Ozônio
(O3) e outros componentes. Esses são alguns dos poluentes que devem ser monitorados para analisar a
qualidade do ar das cidades (Air Quality Egg, 2013).
As pequenas dimensões e o baixo custo de dispositivos de sensoriamento similares ao AQE, fazem deles
uma solução com potencial de alta granularidade, permitindo levar o serviço de monitoramento da qualidade
do ar para qualquer local da cidade, ampliando consideravelmente a cobertura do serviço. Existem, entretanto,
questões importantes que devem ser consideradas ao se optar por uma solução de mais baixo custo baseada em
uma rede de sensores. Uma dessas questões é a necessidade de tratamento das eventuais imperfeições dos
dados coletados. Uma solução de gerencimento de QoC, como a proposta neste trabalho, poderia ser integrada
ao ambiente de monitoramento, provendo às aplicações clientes um conjunto de métricas que permitem medir
a qualidade da informação contextual sendo adquirida pelos nós da rede. Além disso, as leituras podem ser
salvas em banco de dados para acesso e processamento posterior.

4. ABORDAGEM PROPOSTA
Como discutido anteriormente, indicadores de QoC podem tornar as aplicações cientes da qualidade dos dados
manipulados para que os utilizem da melhor forma na tomada de decisão. Apesar da reconhecida demanda de
qualidade de contexto, deixar a implementação de avaliação de QoC à cargo das aplicações constitui um
modelo pouco eficaz devido a fatores como o overhead de processamento de QoC sobre a aplicação e o não
compartilhamento de dados de QoC entre aplicações interessadas num mesmo contexto. Desta forma, o
tratamento de qualidade de contexto é geralmente abordado numa camada intermediária entre as aplicações e
as fontes contextuais de interesse.

168
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Baseada nessas premissas, nossa abordagem divide-se em três etapas: (i) a definição de modelo de métricas
de QoC; (ii) proposta de arquitetura conceitual da camada de gerência de QoC com base no modelo
formalizado e (iii) a realização da mesma como um serviço aplicado no cenário de monitoramento de ar
proposto na Seção 3.

4.1 Modelo de Qualidade e Avaliação de QoC

Como ressaltado em (Nazário, Dantas & Todesco, 2012), ainda não foram criadas padronizações dos
parâmetros de qualidade de contexto. Devido a grande variedade desses parâmetros, selecionamos cinco
métricas recorrentemente sugeridas em trabalhos como (Gray & Salber, 2001; Buchholz, 2003; Toninelli,
2009): Coverage, Up-to-dateness, Frequency, Accuracy e Significance. Adotamos um valor geral de qualidade
baseado nos sub-parâmetros de QoC mencionados, aplicando respectivos pesos de acordo com o tipo de dado
contextual, como sugerido por (Yasar, 2011).
Consideramos tipo de contexto uma entidade que representa um tipo de dado monitorado por uma fonte
contextual específica. Aos valores aferidos para um tipo de contexto damos o nome de dado de contexto.
Compõem um dado de contexto: o valor aferido (escalar) e o timestamp da aferição.
Com base nas entidades apresentadas, definimos uma classe de funções de QoC, representada por f(di), di ϵ
C, tal que di representa um dado de contexto, e C o conjunto de dados de um determinado tipo de contexto.
Sua imagem varia no intervalo [0..1], onde f(di )=1 significa a total aderência com o requisito de qualidade, e
f(di )=0 a total falta de cumprimento do mesmo. Para caracterizar a sequencialidade - em relação ao instante de
geração - entre dados contextuais, consideramos que di é um dado consecutivo a di-1. Também foi definida uma
classe de funções de parâmetro de contexto f(C), que retorna valores arbitrários de parametrização de
determinado Tipo de Contexto, por exemplo, min, max, lifespan, period, os quais eventualmente compõem as
fórmulas das funções de QoC. A seguir, as métricas de QoC utilizadas neste trabalho são introduzidas.
Coverage (C(di)). Representa o escopo aceitável de valores (min e max) esperado para o tipo de contexto.
Um dado que obedece ao coverage do seu tipo de contexto representa, a priori, um valor possível de ser
manifestado.
Up-to-dateness (U(di)): Denota relevância temporal. Em algumas aplicações é importante que a tomada de
decisão seja baseada em dados recentes e temporalmente válidos. Nossa abordagem considera que dados de
determinado tipo de contexto apresentam um lifespan ou tempo de vida. O intervalo entre a produção do dado
pela fonte de contexto e o seu processamento (age) deve estar contido em seu lifespan para que seja
considerado atual.
Frequency (F(di)): Indica se a geração do dado ocorre na periodicidade esperada (period). Sua estimativa
baseia-se no intervalo entre dados adquiridos consecutivamente de uma mesma fonte contextual.
Accuracy (A(di)): Corresponde ao grau de corretude entre o valor do dado adquirido (val(di)) e seu valor
real. No entanto, é dificil determinar o valor real de um contexto. Nossa abordagem estima um intervalo de
confiança entre leituras consecutivas de um mesmo contexto, semelhante ao sugerido por (Kim & Lee, 2006),
de forma que para uma leitura obter A(di) alto seu valor não pode ser relativamente superior à leitura anterior
(di-1) baseado em um fator de variação (consecutive_var).
Significance (S(di)): mede a relevância ou a importância de um dado contextual. Apesar da subjetividade
do termo, nesta abordagem, a significância de um dado indica se esse pertence a um subconjunto de valores
críticos definidos para o seu tipo. Este parâmetro pode ser usado para situações onde alguma ação é
imediatamente necessária. Os valores críticos são avaliados por um conjunto de regras sobre o intervalo do
valor escalar do dado de contexto.
As Tabela 1 e 2 apresentam, respectivamente, como são quantificadas as funções QoC e a definição de
cada função de parâmetro de contexto.

169
 ISBN: 978-972-8939-96-0 © 2013 IADIS

Tabela 1. Métricas QoC

Métrica Sigla Fórmula

Coverage

Up to dateness

Frequency

Accuracy

Significance

QoC Geral

Tabela 2. Funções de Parâmetro de Contexto

Função Definição
min(C) Valor mínimo para um contexto C
max(C) Valor máximo para um contexto C
lifespan(C) Intervalo de validade de um contexto C
period(C) Periodo esperado entre leituras adquiridas de um contexto C
Porcentagem de variação entre dados consecutivos de um contexto C

O cálculo do QoC Geral (QoC(di)), como apresentado na Tabela 1, depende da parametrização de pesos
relativos à cada métrica. pC(C), pU(C), pA(C) são exemplos de funções que retornam os pesos das métricas
coverage, up-to-dateness e accuracy, para um tipo de contexto C, respectivamente.

4.2 Arquitetura Conceitual do Serviço

Na abordagem proposta, o tratamento de QoC é fornecido por uma camada entre as redes de sensores sem fio
– as fontes contextuais – e as aplicações sensíveis ao contexto. Esta “Camada de QoC” implementa um serviço
que realiza a aquisição, avaliação e distribuição de contexto com QoC agregado e permite a configuração de
requisitos de qualidade relativos às aplicações-clientes. O tratamento de QoC dos dados obtidos das RSSF é
feito por meio da geração de medidas de QoC (Manzoor, 2008), conforme discutido na seção anterior. A
Figura 1 apresenta uma visão conceitual da arquitetura proposta.

Figura 1. Arquitetura Conceitual

A arquitetura conceitual é constituída de quatro componentes principais: (i) Configuração de Métricas
QoC e RSSF; (ii) Adaptador de Contexto; (iii) Avaliador de QoC; e (iv) Distribuidor de Contexto e QoC. O
componente de configuração gerencia a parametrização da rede onde é definido o tipo de contexto, as medidas
de qualidade desse tipo, o gateway que irá transmitir o contexto e a aplicação que deverá receber o contexto
avaliado juntamente com as medidas de QoC geradas. Dessa forma, um tipo de contexto é definido por (i) sua

170
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

fonte – no caso, um gateway de uma rede de sensores sem fio; (ii) a aplicação sensível ao contexto destino ou
cliente; (iii) o tipo de dado sensoriado, e.g., temperatura, umidade, etc; e (iv) a parametrização dos requisitos
de QoC, e.g., definição das situações em que esse contexto é considerado significante, intervalos de valores
aceitáveis, definição dos pesos de cada métrica, etc. Todas as etapas do processo, desde a aquisição até a
distribuição, dependem das configurações dos tipos de contexto.
O componente Adaptador de Contexto é responsável por receber os dados das fontes de contexto
cadastradas, classificá-los por tipo de contexto, e instanciá-los na forma de uma entidade dado de contexto (d)
e encaminhá-los ao módulo avaliador. Um entidade dado de contexto possui um tipo de contexto, um valor
escalar e um timestamp de geração, que é a data e hora em que o contexto foi coletado.
O componente Avaliação de QoC recebe os dados de contexto (d), realiza o tratamento com base nas
parametrizações do respectivo tipo de contexto, gera e agrega um timestamp de avaliação e medidas de QoC
repassando-os ao componente de distribuição de contexto, em uma abordagem tipicamente publish-subscribe
(Eugster, 2001). Este componente, por sua vez, pode operar em dois modos: on-line ou off-line. No modo on-
line, a distribuição é realizada em tempo real, entregando dados de contexto e QoC agregado proativamente à
respectiva aplicação. No modo off-line, a aplicação realiza uma requisição ao serviço, especificando uma
janela de tempo ou quantidade máxima de dados contextuais que devem ser entregues, o serviço por sua fez
realiza uma consulta na base de dados histórica e entrega o seu resultado a aplicação solicitante no mesmo
formato que o módulo on-line faz, ou seja, dado de contexto com as medidas de QoC geradas.
Além desses quatro módulos, a figura 1 mostra um componente chamado de simulador. Esse componente
foi criado para avaliar e simular a utilização do serviço proposto em um ambiente controlado, onde poderam
ser incluídos com facilidade vários tipos de dados em várias redes de sensores. O simulador foi incluído na
arquitetura, no entanto ele não é um módulo essencial para o funcionamento do serviço.

5. SERVIÇO DE GERÊNCIA DE QUALIDADE DE CONTEXTO

O Serviço de Gerência de Qualidade de Contexto (SGQoC) é um protótipo de sistema que implementa
elementos da arquitetura conceitual proposta na Seção 4. Para a sua implementação foi adotada a linguagem
Java como base de programação, MySQL como tecnologia de persistência de dados e a biblioteca Swing para
desenvolvimento da interface com o usuário.
A realização da arquitetura contempla a implementação dos seguintes módulos, reunidos em uma
Arquitetura de Implementação: (i) SGQoC Front-End; (ii) Context Adapter; (iii) Context Evaluator; (iv)
Context Generator; e (v) SGQoC Client como apresentado na Figura 2.

Figura 2. Arquitetura de Implementação

O SGQoC Front-End é o módulo de interface com o usuário. Por meio dele, são definidos os Tipos de
Contexto (CtxType) de cada RSSF que o serviço irá manipular e as configurações das medidas de QoC, ou
seja, esse módulo implementa o componente Configuração de Métricas QoC e RSSF apresentada na seção de
Arquitetura. Essas definições e configurações das redes e das métricas de QoC são gravadas na base de dados
do sistema (representado pela interação 1 da Figura 2) para posterior utilização pelos demais módulos. A
tabela 3 apresenta a configuração de dois tipos de contexto (PM10@RSSF 1 e PM10@RSSF 2) monitorados no
cenário proposto na Seção 3. Nele são associados o gateway de origem do dados e a aplicação a qual o dado
se destina. Além disso, são informados os dados de parametrização que serão considerados no cálculo das
métricas de QoC. Para efeitos de teste foram adotados pesos iguais para todas as métricas (peso 1).

171
ISBN: 978-972-8939-96-0 © 2013 IADIS

Tabela 3. Parametrização de Tipos de Contexto (CtxType).

Parametrização para Gerar Métricas de QoC RSSF

CtxType min-max lifespan period consecutive_var Gateway Aplicação

~0-500 g/m3
~0-500 g/m3
PM10@RSSF 1 3600 s 5s 10% 2001:db8:0:1200:fe0::1 App1@localhost:80
PM10@RSSF 2 3600 s 15 s 10% 2001:db8:0:1200:fe0::2 App2@localhost:80

O Context Adapter lida com a construção de instâncias de CtxData – objeto que representa uma unidade
de dado de contexto – provenientes de uma fonte de contexto, por exemplo, um gateway de uma RSSF.
Nossa implementação oferece um componente de simulação, o Context Generator, que age como um
facilitador do processo de desenvolvimento e validação da solução. Com base no CtxType configurado, ele é
capaz de simular uma RSSF geradora de contexto, aplicando deficiências de qualidade, e.g., adição de ruídos,
durante sua geração.
Uma vez instanciado, um objeto CtxData é encaminhado ao módulo Context Evaluator (interação 3),
composto por dois sub-componentes: QoCEvalManager (QEM) e CtxEval. O QEM gerencia um pool de
threads CtxEval (interação 4), que por sua vez implementam as funções de QoC apresentadas na Seção 4.1 e
as aplicam às instâncias CtxData de um CtxType específico. Quando recebe um novo CtxData, o QEM
verifica a existência de um CtxEval responsável pelo respectivo CtxType, caso exista, o dado é entregue, caso
contrário, é criado um novo CtxEval para iniciar o processamento desse tipo. Esse sub-componente também
instancia um CtxEval ao detectar que algum tipo de contexto recebido não foi processado pelo serviço
imediatamente.
A Tabela 4 apresenta um trecho da execução do Context Generator para a simulação do cenário de
monitoramento de qualidade do ar. Nesta tabela pode-se observar o CtxData e QoCData resultantes do
processamento do contexto PM10@RSSF 1, que representa a concentração (g/m3) da partícula PM10 aferida por
uma determinada rede de sensores.
Tabela 4. CtxData e QoCData para PM10.

CtxData QoCData
Context Source Final Generation Arrival
C U A F S QoC
Type Value Value Time Time
PM10 @RSSF 1 20.6 20.6 20:58:01 20:58:02 1 1 1 1 0 0.8
PM10 @RSSF 1 21.06 21.06 21:02:05 21:02:07 1 1 1 1 0 0.8
PM10 @RSSF 1 50.24 21.06 21:10:09 21:10:12 1 1 0 1 0 0.6
PM10 @RSSF 1 20.72 20.72 21:13:13 21:13:15 1 1 1 1 0 0.8
PM10 @RSSF 1 20.87 20.87 21:17:17 21:17:19 1 1 1 1 0 0.8

O processo de simulação permite definir o número de sensores e uma respectiva distribuição de

probabilidade, e.g, uniforme, normal, poisson, exponencial ou triangular, para geração de seus dados. A linha
destacada na Tabela 4 indica um erro induzido na simulação que afeta o valor de Accuracy do dado. Em casos
como este - onde QoC do dado é insatisfatório - o CtxEval é capaz de aplicar medidas de tratamento pós-
avaliação de QoC. São possíveis sua rejeição, manutenção ou correção. O primeiro caso consiste no descarte
do CtxData; o segundo, em manter o valor errado e por último, na repetição do valor do último CtxData com
QoC aceitável. Este último foi aplicado na simulação (observe que o atributo Final Value replicou o valor da
leitura anterior), como o CtxData foi corrigido antes da sua entrega e utilização pela aplicação cliente que é
sensível ao contexto, isso evitou uma possível falha na tomada de decisão da aplicação. Se um conjunto de
leituras posteriores (como L4 e L5) a linha destacada (L3) apresentassem valores dentro de certa margem em

não apresenta coerência com as leituras posteriores, que retornam a valores próximos de 20 g/m3.
relação a L3, o SGQoC não consideraria um erro e o transmitiria à aplicação cliente, no entanto, L3 também

A Figura 3 ilustra o front-end do serviço durante a execução da simulação, com o tratamento por correção
sendo aplicado ao longo do processo, e seu impacto nos dados destinados às aplicações. Pode-se ver que a
simulação gerou picos de aproximadamente 50 g/m3 em um sinal de entrada, cujo valor médio é 20 g/m3,
enquanto a saída foi ajustada conforme a configuração de QoC definida pela aplicação (repetir medição
anterior).

172
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Figura 3. Comparação entre entrada de dados com ruído e saída com correção
Com os processos de avaliação de QoC e eventual tratamento do dado, CtxData e seu respectivo QocData
são armazenados no banco de dados do serviço (interação 5), os quais podem ser posteriormente utilizados
pelas aplicações. Na implementação atual, a interação 6 é feita por meio de um componente de integração que
deve estar presente na aplicação cliente, o SGQoC Client, que realiza a abordagem off-line de distribuição de
contexto, como apresentada na Seção 4.

6. CONCLUSÕES
Esse trabalho propôs uma infraestrutura para avaliação de qualidade da informação de contexto proveniente de
redes de sensores sem fio (RSSF). O objetivo é a entrega de contexto enriquecido com informações de QoC
(Quality of Context) à aplicações clientes. A abordagem proposta permite a seleção e especificação de
métricas de QoC e o protótipo desenvolvido é capaz de avaliar contexto de diferentes fontes e aplicar
correções em dados contextuais antes de entregá-los as aplicações interessadas. Além disso, ele oferece um
front-end de monitoramento que permite aos desenvolvedores acompanharem estatísticas do processo de
sensoriamento em tempo real. Um exemplo de uso foi mostrado em um cenário de monitoramento de
qualidade do ar, ilustrando o potencial de aplicação do sistema proposto.
Desenvolvimento futuros da infraestrutura incluem: (i) desenvolvimento de uma API para integração dos
gateways das redes de sensores sem fio com o SGQoC; (ii) indução de outros tipos de degradação de
qualidade durante a simulação, e.g., atraso e inconstância no envio de dados. (iii) proposta de novas políticas
de correção de dados, e.g, implementação de padrão publish-subscribe para o desenvolvimento da distribuição
de contexto (Context Publisher) e uma API para facilitar a integração das aplicações-clientes ao serviço.

AGRADECIMENTOS
Este trabalho foi financiado e apoiado por FAPES/CNPq e pelo Projeto CIA2 – CTIC-RNP Cidades
Inteligentes.

REFERÊNCIAS
Weiser, M. 1991, The computer for the 21st century. Scientific American, pp. 94–104.
Yick, J. et al. 2008, Wireless sensor network survey, Computer Networks, vol. 52, no. 12, pp. 2292–2330.
Dey, A.K. & Abowd, G.D. 1999. Towards a better understanding of context and context-awareness. GVU Technical
Report GITGVU-99-22, College of Computing, Georgia Institute of Technology. pp. 304—307.
Costa, P.D., 2007, Architectural Support for Context-Aware Applications: From Context Models to Services Platforms,
Ph.D. Thesis, University of Twente.
Henricksen, K., Indulska, J. 2004, Modelling and Using Imperfect Context Information. Proceedings of the Second IEEE
Annual Conference on Pervasive Computing and Communications Workshops, pp. 33–37.
Buchholz, T. et al. 2003. Quality of Context: What It Is And Why We Need It. In Proceedings of the 10th Workshop of the
HP OpenView University Association.
Manzoor, A.et al. 2008. On the Evaluation of Quality of Context. 3rd European Conference on Smart Sensing and
Context, pp. 140–153.

173
ISBN: 978-972-8939-96-0 © 2013 IADIS

Neisse, R. et al 2008. Trustworthiness and Quality of Context Information. In Proceedings of the 9th International
Conference for Young Computer Scientists (ICYCS’08), pp. 1925-1931.
Zimmer, T. 2006. QoC: Quality of Context – Improving the Performance of Context-Aware Applications. Advances in
Pervasive Computing 2006, Dublin, Ireland, pp. 209–214.
Dey, A.K. 2000. Providing Architectural Support for Building Context-Aware Applications. Ph.D. Thesis. Georgia
Institute of Technology.
Schmidt, A., 2004. Management of Dynamic and Imperfect User Context Information. In: R.Meersman et al (Eds), OTM
Workshops, LNCS 3292, pp.779-786.
Krause, M. and Hochstatter, I. 2005. Challenges in Modelling and Using Quality of Context (QoC). Mobility Aware
Technologies and Applications, pp. 324–333.
Bu, Y. et al 2006. Managing quality of context in pervasive computing. In Proceedings of the 6th International
Conference on Quality Software. , pp. 193–200.
Gray, P., and Salber, D. 2001. Modelling and Using Sensed Context Information in the design of Interactive Applications.
In LNCS 2254: Proceedings of 8th IFIP International Conference on Engineering for Human-Computer Interaction
(EHCI 2001), Toronto, Canada. pp. 317–336.
Toninelli, A. et al., 2009. A quality of context-aware approach to access control in pervasive environments,
MobileWireless Middleware, Operating Systems, and Applications: LNCS, v. 7, p. 236–251.
Abid, S. Z. et al., 2009. A framework for quality of context management, in Proceedings of the 1st international
conference on Quality of context, pp. 120–131.
Manzoor, A. et al., 2010. Service-centric Inference and Utilization of Confidence on Context. Services Computing
Conference (APSCC), pp. 11-18.
Filho, J. B. et al., 2010.Modeling and Measuring Quality of Context Information in Pervasive Environments. In
Proceedings of the 24th IEEE International Conference on Advanced Information Networking and Applications, 690-
697.
Zheng, D. et al. 2012. Evaluation of Quality Measure Factors for the Middleware Based Context-Aware Applications. In
Proceedings of the 11th International Conference on Computer and Information Science, pp. 403-408.
IEMA, 2013. Rede automática de monitoramento da qualidade do ar da região da grande vitória. Portal do Governo do
Estado do Espírito Santo. Disponível em: <http://www.meioambiente.es.gov.br/default.asp> Acesso em 21 ago 2013.
Air Quality Egg, 2013. A community-led air quality sensing network that gives people a way to participate in the
conversation about air quality. 2013. Disponível em: <http://www.kickstarter.com/projects/edborden/air-quality-
egg> Acesso em 22 ago 2013.
Nazário, D. C., Dantas, M. A. R., Todesco, J. L. 2012. Taxonomia das publicações sobre Qualidade de Contexto
Sustainable Business International Journal, v. 20, pp. 1–28.
Yasar, A. U. H. et al. 2011. When efficiency matters: Towards quality of context-aware peers for adaptive
communication in VANETs. IEEE Intelligent Vehicles Symposium (IV), pp. 1006–1012.
Kim, Y. and Lee, K. 2006. A quality measurement method of context information in ubiquitous environments. In ICHIT
’06: Proceedings of the 2006 International Conference on Hybrid Information Technology, pp. 576–581.
Eugster, P.T., et al. 2003, The many faces of publish/subscribe, ACM Computing Surveys, ACM, pp. 114-131.

174
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

VALIDAÇÃO DE DEPENDÊNCIAS FUNCIONAIS

CONDICIONAIS EM DADOS XML: UMA ABORDAGEM
BASEADA EM GRAMÁTICA DE ATRIBUTOS

Aryadne Guardieiro Pereira Rezende e Maria Adriana Vidigal de Lima

Universidade Federal de Uberlândia
Faculdade de Computação, Avenida João Naves de Ávila 2121 – Bloco B, Uberlândia - MG

RESUMO
A representação e o intercâmbio de informações provenientes de diferentes fontes de dados, como empresas e governos,
através de documentos XML, tornam-se cada vez mais comuns graças à simplicidade sintática da linguagem XML, auto-
documentação e baixo custo de transmissão e armazenamento dos dados. Assim, garantir a qualidade dos dados contidos
em documentos XML é um desafio, pois podem conter redundâncias e inconsistências, uma vez que fontes diferentes
geralmente utilizam esquemas diferentes de armazenamento, além da falta de garantia de que existe a correspondência
bilateral entre os dados armazenados e suas representações no mundo real. Neste contexto, dependências funcionais
condicionais definidas sobre documentos XML servem como ferramentas para aumentar a qualidade dos dados antes que
sejam manipulados, armazenados e interrogados. Este trabalho apresenta um conjunto de algoritmos utilizados para a
validação de dependências funcionais condicionais em documentos XML baseados em autômatos finitos e na utilização
de gramáticas de atributos. A abordagem utilizada nesses algoritmos independe do esquema dos arquivos XML, levando
em conta apenas a semântica expressa na dependência funcional condicional a ser verificada.

PALAVRAS-CHAVE
XML, restrições de integridade, dependências funcionais condicionais.

1. INTRODUÇÃO
A linguagem XML se tornou o formato preferido para a integração e a transferência de informações entre
organizações. Este intercâmbio permite transformar a imensa quantidade de dados existentes nestas
organizações em informação útil e confiável para a realização de operações diversas e para auxiliá-las nos
processos de tomada de decisão. No contexto relacional, muitos trabalhos vêm sendo desenvolvidos para
melhorar a qualidade dos dados integrados, com interesse renovado na aplicação de dependências clássicas
(Fan, 2008, Liu et al, 2011, Bakhtouchi et al, 2011) e condicionais (Bohannon et al, 2007, Fan et al, 2008)
para a preservação da semântica, detecção e reparo de possíveis inconsistências. De forma similar, as
dependências clássicas e condicionais sobre dados XML foram propostas (Bunemanet et al, 2001, Liu et al,
2003, Wang et al, 2005, Shahriar et al, 2008, Bouchou et al, 2011, Tan et al, 2011, Vo et al, 2011) para a
verificação semântica dos dados.
Uma dependência condicional representa uma forma mais fraca de dependência, definida para atuar num
escopo de dados limitado por condições sobre diversos atributos. Apenas as tuplas que satisfazem estas
condições devem ser avaliadas e esta aplicação condicional tem possibilitado contextualizar análises sobre os
dados, além de encontrar e corrigir inconsistências específicas. As dependências funcionais condicionais em
XML (DFCX) estendem as dependências funcionais com uma expressão condicional que permite a aplicação
de uma dependência funcional sobre partes de um documento XML, representando um subconjunto
específico dos dados. Para mostrar a importância da utilização de uma DFCX, imagine que se deseja
representar informações sobre dados bancários de clientes e que sobre estes dados sejam verificadas
dependências como:(i) caso o banco seja B1, então o número da conta implica no cliente (ii) se o cartão for
do tipo Platinum então o juro do cheque especial é o mesmo para todos os clientes com o cartão desse
tipo.Tais condições colaboram na compreensão mais detalhada das características de um determinado
subconjunto, possibilitando a identificação de falhas e aumentando a qualidade dos dados.

175
ISBN: 978-972-8939-96-0 © 2013 IADIS

Neste trabalho, um documento XML é visto como uma estrutura composta de uma árvore de aridade
variável e de funções para sua manipulação. As dependências a serem verificadas no documento são
definidas por expressões de caminho. Assim, uma dependência funcional, denotada X →Y, tem os atributos X
e Y substituídos por expressões de caminho nos lados esquerdo e direito respectivamente. Tais caminhos
permitem atingir quaisquer níveis de profundidade na árvore e exprimem uma consulta simples, cujo
resultado é um conjunto de nós. A DFCX estende a dependência funcional com a incorporação de uma
expressão condicional, responsável por selecionar apenas os resultados (nós) que a satisfazem.
A abordagem utilizada, neste trabalho, para a validação de DFCXs independe do esquema do documento
e se baseia numa função de percurso que tem como entradas um documento XML e um conjunto de
dependências funcionais condicionais, e verifica se todas as dependências são respeitadas pelo documento,
como ilustrado na Figura 1. Durante a validação, as expressões de caminho que definem as dependências são
traduzidas em autômatos finitos, que formalizam os caminhos a serem verificados. Os algoritmos definidos
para a verificação das DFCXs se baseiam em gramática de atributos. Os atributos armazenam anotações na
direção descendente, para marcar os nós que fazem parte do caminho definido para uma dependência, e na
direção ascendente, para resguardar os valores obtidos para que sejam organizados e comparados ou o
resultado do tratamento das informações previamente obtidas até aquele nível.

Figura 1. Verificação de um documento XML por um conjunto de DFCXs

2. PRELIMINARES

2.1 Dependências Funcionais em XML

As dependências funcionais atribuídas a documentos XML (DFXs) possuem uma definição análoga àquela
das dependências funcionais definidas no contexto de bancos de dados relacionais, e são impostas sobre um
determinado documento XML. Uma DFX pode ser aplicada ao documento todo ou à partes específicas, e esta
aplicação é definida por uma expressão de caminho inicial, chamada caminho de contexto. Abaixo do
caminho de contexto temos os caminhos que envolvem o lado direito e o lado esquerdo da dependência
funcional. Formalmente podemos definir uma DFX como:

γ = (C, ({P 1[E1], ... ,P k[Ek]} → Q[E]))

em que C, P k e Q são respectivamente o caminho de contexto, os caminhos determinantes e o caminho

determinado. Os caminhos definidos para uma DFX são mostrados na Figura 2 para uma árvore XML. Cada
final de caminho possui uma igualdade E associada, podendo ser igualdade referente ao nó (posição) ou
igualdade referente ao valor. Igualdade de valor leva em conta o dado (se o nó for um nó folha) ou os dados
(se o nó for um nó interno da árvore) associados aquele nó. Já a igualdade de nó leva em consideração a
posição daquele nó na árvore XML. Na Figura 2, os valores (dados) são representados por █ e os valores de
posições do nó estão contidos dentro de cada nó para o trecho da árvore XML.

176
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

r.0 r.0 r.0

... ... ...

r.0.0 r.0.2 r.0.2 r.0.0 r.0.2
r.0.0

... ... ...

r.0.0.0 r.0.0.1 r.0.0.2 r.0.0.1 r.0.0.0 r.0.0.1 r.0.0.2

r.0.0.0 r.0.0.2

... ... ...

█ █ █
r.0.0.1.0 r.0.0.1.1 r.0.0.1.0 r.0.0.1.1 r.0.0.1.0 r.0.0.1.1

█ █ █
r.0.0.1.0.0 r.0.0.1.0.0 r.0.0.1.0.0

█ █ █

(a) (b) (c)

Figura 2. Caminhos na árvore XML: (a) de contexto, (b) determinantes (k =1) e (c) determinado

2.2 Dependências Funcionais Condicionais

Dependências funcionais condicionais (DFCs) são similares a dependências funcionais tradicionais, porém
com a peculiaridade de possuírem uma expressão condicional que permite estabelecer à dependência uma
restrição (condição) associada a valores encontrados na árvore. Para ilustrar a usabilidade desse tipo de
dependência, considere uma situação na qual um banco se associe a outro e que ambos ofereçam diversos
tipos de cartões de crédito. Para facilitar a verificação de fraudes e inadimplências, essa nova empresa deseja
garantir que todos seus clientes possuam apenas um tipo de cartão de crédito associado a ele, se ele tiver se
tornado cliente depois de 2004. Da integração dos bancos dessa empresa surgiu o documento da Figura 3.
conf = { M.e1 }
registros
conf = { M.e1 ,, C.e1 ,T '.e7, T ''.e10 }

conf = { M.e1 ,, C.e1 ,T '.e7, T ''.e10 } ...

conta conta
conf = { T '.e8 }
conf = { T '.e1 } conf = {, C.e4 , T ''.e11 }
conf = {, C.e4 , T ''.e11 }
cliente cartao cliente cartao
conf = { C.e5 }
conf = { C.e5 }
69392-1 ... tipo ano 69392-1 ... tipo ano

Platinum 2005 Gold 2010

Figura 3. Trecho da árvore resultante da integração de dados advindos dos bancos dos bancos que se associaram

177
ISBN: 978-972-8939-96-0 © 2013 IADIS

2.2.1 Definição de Dependências Funcionais Condicionais XML

Formalmente, DFCXs podem ser definidas da seguinte maneira:

η = (C, (Cond,{P1[E1], ... ,P k[Ek]} → Q[E]))

em que Cond é uma expressão da forma {expr 1 θ1 expr 2 θ2 ... θn-1 expr n}, sendo expr i uma expressão booleana
do tipo PC ϕ vc associada a um nó particular da árvore do documento na qual PC é uma expressão de
caminho, vc um valor, ϕ um dos operadores do conjunto {= ; ≠ ; < ; > ; ≤ ;≥ } e θ um operador lógico do tipo
and ou or.
Como exemplo, uma dependência funcional condicional que especifica a regra de validação mencionada
na introdução para os registros do banco pode ser expressa por:

= (\registros, ({\conta\cartao\ano > 2004}), {\conta\cliente[V]}→ \conta\cartao[V])

O símbolo V indica igualdade de valor. A igualdade de valor fica subentendida nos caminhos expressos
pela condição (todos os fins de caminhos da expressão condição indicam igualdade de dados).
2.2.2 Satisfação de Dependências Funcionais Condicionais
Seja T um documento XML e η= (C; (Cond;{P 1 [E1],..., P k[Ek]} → Q [E])) uma DFCX e seja M o padrão
C/expr 1,...,C/expr k, C/P 1,..., C/P k , C/Q. Dizemos que T satisfaz η (denotado T ╞ η) se e somente se para todas
I1M e I2M que são instancias de M em T e que coincidem pelo menos no prefixo C e que tenham as expressões
expr i com o respectivo valor respeitado (PCi ϕi vci), temos:τ1[C/P 1 ,..., C/P k]=Ei,i [1,2,..., k] τ2[C/P 1,...,
C/P k]→τ1[C/Q]=Eτ2[C/Q] no qual τ1 e τ2 são tuplas de valores obtidas ao fim dos caminhos de I1M e I2M
respectivamente. □
Assim, a DFCX será satisfeita se o ano for posterior a 2004 (caso contrário a tupla não será avaliada), e
quaisquer duas tuplas t1 e t2 que identificarem o mesmo cliente (lado esquerdo, determinante) devem conter o
mesmo número de cartão (lado direito, determinado). Caso contrário a DFCX será dada como falsa.
2.2.3 Autômatos de Estados Finitos para DFCX
Para que seja executado o algoritmo de validação de dependências funcionais condicionais é necessário que
as expressões de caminho sejam convertidas em autômatos de estados finitos. O alfabeto de entrada é o
conjunto de tags do documento XML. O AEF (autômato de estados finitos) é denotado por uma 5-tupla A =
(Θ;Σ;Δ;e;F), na qual Θ representa o conjunto de estados; Σ é o alfabeto; e Θ é o estado inicial; F ⊆ Θ é o
conjunto de estados finais, e Δ : Θ x Σ→Θ é a função de transição entre os estados de A. Já um transdutor de
estados finitos (TEF) é uma 7-tupla T = (Θ;Σ;Γ;Δ;e;F;λ) tal que: (i) (Θ;Σ;Δ;e;F) são os mesmos do AEF;
(ii) Γ é o alfabeto de saída (valores computados para cada valor de entrada dependendo do estado do AEF em
que se encontra) e (iii) λ é a função de F em Γ indicando a saída associada a cada estado final. Existem várias
instâncias destes caminhos na árvore XML e existem também nós que não fazem parte de nenhuma dessas
expressões. Para demarcar o papel de cada nó da árvore XML na DFCX são utilizados os seguintes
autômatos e transdutores:
M = (Θ; Σ; Δ; e; F): Autômato de contexto que expressa o caminho C. O alfabeto Σ é composto pelas
tags do documento XML;
T′ = (Θ′;Σ′;Γ′;Δ′;e′;F′;λ′): Transdutor determinante que representa os caminhos P i (i [1;k]). O
conjunto dos símbolos de saída é dado por Γ′ = {V;N} x N* tal que V representa a igualdade de valor e N a
igualdade de nó, valores esses associados a cada caminho P i. Cada caminho é numerado, pois pode haver
mais de um caminho do lado determinante. Assim, a função λ associa o par (igualdade, posição) a cada
estado final q F′, no qual posição é o número do caminho do lado determinante;
T′′ = (Θ′′;Σ′′;Γ′′;Δ′′;e′′;F′′;λ′′) : Expressa o caminho determinado Q. O conjunto de símbolos de saída é
dado por Γ′′ ={V;N} e a função de saída λ′′ associa um símbolo V ou N a cada estado final q F′′.
C = (Θc ;Σc ;Γc ;Δc ;ec ;F c): Autômato condicional representante dos caminhos PCj que determinam as
expressões dadas em Cond.

178
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

e0 registros e1 e2 conta e3 cartao e4 ano e5| (2004)

M: C:

e6 conta e7 cliente e8| (V,1) e9 conta e10 cartao e11| (V)

T': T'':

Figura 4. Autômatos e transdutores gerados para a DFCX

3. VALIDAÇÃO DE DFCXS
O processo principal de validação de dependências funcionais condicionais recebe um conjunto de DFCXs e
um documento XML. A validação de uma DFCX é baseada nas técnicas de anotação de uma gramática de
atributos. A cada nó de uma árvore, são associados atributos herdados e sintetizados que anotam na direção
descendente as informações passadas pelos nós superiores e na direção ascendente as informações colhidas
dos nós filhos. Esses conceitos remetem a análise sintática, feita por compiladores, que utilizam uma
gramática de atributos, e são detalhadas em (Aho et al, 1988). Cada atributo se aproveita de um dos dois
momentos chave do percurso na árvore para serem calculados, ou seja, a abertura de tags que indica a
descida na árvore XML e o fechamento de tags que indica a subida na árvore. Considerando ω um conjunto
de DFCXs a serem avaliadas, o percurso na árvore se dá de acordo com o Algoritmo 1:
início da avaliação;
para cada elemento do documento faça
para cada DFCX η pertencente a ω faça
se abertura de tag então
cálculo do atributo conf;
senão
se fechamento de tag recém aberta então
cálculo dos atributos sintetizados de nós folhas;
senao
cálculo dos atributos sintetizados de nós internos;
fim da avaliação do documento;
retorna raiz.c de cada DFCX η pertencente a ω;
No conjunto de atributos associados a cada nó se encontram atributos herdados – atributos calculados
manipulando-se o valor dos nós ancestrais (nós pais) que são obtidos na descida da árvore – e atributos
sintetizados – atributos cujo valor se calcula utilizando valores resgatados de nós filhos, feito durante a

 conf: atributo herdado, que marca o papel do nó na DFCX.

subida na árvore XML. Os atributos utilizados para a validação são:

 ds: atributo sintetizado, ou seja, é calculado no momento de subida na árvore. É responsável por
recolher os valores correspondentes ao lado esquerdo da DFCX. Pode haver diversos caminhos
associados ao lado esquerdo da dependência, logo o dsj guarda o valor associado a j-ésima
expressão de caminho (podendo ser um único valor, no caso de o nó representado pelo caminho

 dc: atributo sintetizado cuja função é carregar o valor único associado ao lado direito da
ser um nó folha, ou uma tupla, caso seja um nó intermediário).

 dcond: atributo sintetizado que recolhe os valores atribuídos a cada caminho k da expressão
dependência funcional condicional.

 inters: representa um conjunto de tuplas, onde cada tupla é composta de outras duas. A primeira
condicional dada.

contém os valores associados à expressão condicional (atributos dcond), a segunda contém uma
tupla interna de valores referentes ao atributo ds e um campo referente ao atributo dc:
inters = {< < dcond1, dcond2,..., dcondk> ;< < ds1,ds2,..., ds j > , dc > > ,...}.
Seu papel é ser o conjunto que expresse a interseção dos valores obtidos dos nós filhos durante o

 c: também do tipo sintetizado, armazena o valor da dependência funcional contida na

caminho ascendente na árvore XML.

dependência funcional condicional até o momento corrente.

Cada atributo possui uma maneira para que seja feito seu cálculo. O atributo conf é preenchido durante a
descida na árvore de acordo com o Algoritmo 2, dado a seguir. Esse procedimento se baseia no papel do nó
corrente do percurso. A partir dos autômatos gerados antes de se iniciar o Algoritmo 1, o cálculo do atributo

179
ISBN: 978-972-8939-96-0 © 2013 IADIS

conf é feito copiando-se todas as configurações de cada autômato no qual o nó corrente provoca uma
mudança de estado, com base no seu nó pai. É utilizada a configuração do nó anterior no caminhamento da
árvore, ou seja, a tag aberta anteriormente que não foi fechada, e com os valores presentes no atributo conf
desse nó pai, é feito o cálculo para o nó corrente, testando se alguma configuração do pai gera uma mudança
de estado quando se lê aquele nó filho. Caso o nó seja raiz, único nó sem pai, é feito então o teste de transição
apenas para o autômato que representa o caminho de contexto. A Figura 4 mostra o resultado do Algoritmo 2
para o exemplo dado. Observe que os elementos abaixo do nó cartao contém o mesmo atributo conf que
cartão (cartao leva a um estado final do autômato T’’ e é nó interno). Admitindo-se K um dos autômatos
utilizados na validação e A o nó corrente, o cálculo do atributo conf , dado pelo Algoritmo 2, se dá da
seguinte maneira:
entrada: nó A
se A = RAIZ então
RAIZ.conf := M.q1| M(q0,RAIZ) = q1;
senao
P:= A.pai;
para cada K.q P.conf faça
se (K = M) ∧ (q FK)então
A.conf := A.conf ∪ {T’.q1′ |δT′(q′0;A) = q1′}∪
{T′′.q1′′ | δT′′ (q0′′;A) = q1′′} ∪ {C.q1c |δC(q0c;A) = q1c};
senão
A.conf := {K.q’| K(q,A) = q’};
Quando um nó folha é localizado, o caminhamento na árvore muda para o sentido ascendente, ou seja,
caminha-se das folhas em direção à raiz. Caso o nó pertença a algum caminho i do lado esquerdo da DFCX
(lado determinante), seu valor é inserido em seu atributo dsi. Caso o nó folha encontrado seja o nó
correspondente ao fim do lado direito da DFCX (lado determinado), o valor encontrado é depositado no
atributo dc, se o nó faz parte da condição da DFCX por algum caminho k da condição imposta, seu valor será
inserido no atributo dcondk. Durante o procedimento expresso no Algoritmo 3 o atributo inters do nó corrente
é preenchido, e depois no fim do procedimento é acrescido ao atributo inters de seu pai. Repare que
dependendo do tipo de igualdade é utilizada função valor_no (igualdade de nó) ou função valor_dado
(igualdade de valor). A função mapping será utilizada para unificar a tupla inters do nó P a fim de preencher
os campos vazios ou combinar os já preenchidos com os que foram encontrados. Dessa maneira o Algoritmo
3 (cálculo dos atributos sintetizados dos nós folhas) é dado pelo seguinte procedimento a seguir:
entrada: nó A
para cada configuração K.q no nó A.conf faça
se(K = T’ )∧ (q FT’) então
y:= λ’T’(q);
j:= y.rank;
se y.igualdade = V então
A.dsj:= <valor_dado(A)>;
senão
A.dsj:= <valor_no(A)>;
A.inters := A.inters ∪ {<< >,<<<A.dsj>j>, >>};
se(K = T’’ ) ∧ (q FT’’) então
se λ’’T’’(q) = V então
A.dc:=<valor_dado(A)>;
senão
A.dc:=<valor_no(A)>;
A.inters := A.inters∪ {<< >,<< >,A.dc>>};
se(K = C ) ∧(q FC )então
z:= λC (q);
k:= z.rank;
A.dcondk := <valor_dado(A)>;
A.inters := A.inters ∪ {<<<A.dcondk>k>,<< >, >>};
P := A.pai;
P.inters := P.inters ∪ mapping(A.inters);
Note que no procedimento anterior os campos vazios são preenchidos com o símbolo ε. Continuando o
caminho bottom-up, o cálculo dos valores dos atributos ds e dc é feito para cada nó interno da árvore,
utilizando os valores dos atributos dos nós descendentes do nó atual para o cálculo de seus atributos
sintetizados. Pode-se observar que em (4) do Algoritmo 4 que o valor de A.c se mantém neutro (verdadeiro)
se não existem instâncias da DFCX que respeitem a condição. A verificação das instâncias válidas presentes

180
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

em inters é feita com os valores presentes em dcond. O cálculo dos atributos sintetizados de nós internos, o
Algoritmo 4 é feito da seguinte forma:
entrada nó A;
para cada configuração K.q no nó A.conf faça
P = A.pai;
(1) se (K = T’) ∧ (q FT’) então
y:= λ’T’(q);
j:= y.rank;
se y.igualdade = N então
A.dsj:=<valor_no(A)>;
A.inters := A.inters ∪ {<< >,<<<A.dsj>j>, >>};
(2)se(K = T’’) ∧(q FT’’) então
se λ’’T’’(q) = N então
A.dc:=<valor_no(A)>;
A.inters := A.inters ∪ {<< >,<<< >>,A.dc>>};
(3)se( K ≠ ε ) ∧ (q FK) então
P.inters := mapping(A.inters);
(4)se( K = M ) ∧ (q FM) então
A.c = verdadeiro
A.c := <∀ w,z validas A.inters, w ≠ z: w.l1 = z.l1⇒ w.l2 = z.l2>;
P.c := A.c ∧ P.c;
(5)se(K = M) ∧ (q FM) então
P.c := A.c ∧ P.c
A figura 5 mostra o resultado do cálculo de inters para nós internos e folhas, e de c para o nó do fim do
caminho do contexto da DFCX , obtidos pelo procedimento anterior. Como as duas tuplas encontradas são
instancias da DFCX e respeitam a condição (ano > 2004), ou seja, são válidas, resta submetê-las ao teste
dos lados esquerdos e direitos (l1 e l2, respectivamente). Como possuem lados esquerdos iguais e direitos
diferentes a DFCX é tida como violada, (c igual a false), conclui-se dessa maneira que nesse documento um
número de conta não está associado a apenas um tipo de cartão, o anos posteriores a 2004.
c = false
registros
inters = {< 2005> ,< 69392-1,< < Platinum>,< 2005> > > } inters = {< 2010> ,< 69392-1,< < Gold>,< 2010> > > }

...

conta conta inters = {< 2010> ,

inters = {< 2005> , < ε,< < Gold>,< 2010> > > }
< ε,< < Platinum>,< 2005> > > }
cliente cartao cliente cartao
inters = inters = {< 69392-1>}
{< 69392-1>}
69392-1 ... tipo ano 69392-1 ... tipo ano

Platinum 2005 Gold 2010

Figura 5. Cálculo dos atributos sintetizados de nós folha. Campos não preenchidos recebem o valor de ε

4. CONCLUSÃO
Uma gramática de atributos pode ser definida para a validação de restrições de integridade sobre dados XML
para que sejam realizadas diversas anotações nos nós da árvore de dados durante um percurso. A principal
vantagem da presente proposta é a de ser baseada num método genérico fundamentado em autômatos finitos
e gramática de atributos, que pode ser adaptado para a validação de outros tipos de restrição. A validação de
dependências funcionais condicionais permite que a qualidade dos dados XML seja analisada a partir de
condições específicas aplicadas sobre os dados (imposição semântica) o que pode ser bastante útil em
ambientes de integração de dados. Como continuação deste trabalho, pretende-se a criação de um ambiente
de validação de restrições XML, em que diversas restrições, de tipos diferentes possam ser validadas num
único percurso e que reparos possam ser indicados para as inconsistências encontradas.

181
ISBN: 978-972-8939-96-0 © 2013 IADIS

AGRADECIMENTO
Agradecemos às nossas famílias por nos dar o suporte necessário e ao Conselho Nacional de
Desenvolvimento Científico e Tecnológico (CNPq) pelo apoio financeiro.

REFERÊNCIAS
Abiteboul, S. et al, 2000.Data on the Web: From Relations to Semistructured Data and XML. Morgan Kaufmann
Publishers, San Francisco, USA.
Aho, A. V., Sethi, R., 1988. Ullman, J. D. Compilers: principles, techniques, and tools. Addison-Wesley, Reading,
Mass., USA.
Bakhtouchi, A. et al, 2011. Ontologies and functional dependencies for data integration and reconciliation. Proceedings
of the 30th international conference on Advances in conceptual modeling: recent developments and new directions,
Brussels, Belgium, pp. 98-107.
Bohannon, P. et al, 2007. Conditional functional dependencies for data cleaning. IEEE 23rd International Conference on
Data Engineering (ICDE), Istanbul, Turkey, pp. 756-755.
Bouchou, B. et al, 2011. Attribute Grammar for XML Integrity Constraint Validation. 22nd International Conference on
Database and Expert Systems Applications (DEXA 2011), Toulouse, France, pp. 94-109.
Buneman, P. et al, 2001. Constraints for Semistructured Data and XML. ACM Special Interest Group on Management of
Data (SIGMOD Rec.), Vol. 30, No.1, pp. 47-54.
Fan, W., 2008. Dependencies revisited for improving data quality. Proceedings of the twenty-seventh ACM SIGMOD-
SIGACT-SIGART Symposium on Principles of database systems (PODS), Vancouver, Canada, pp. 159-170.
Fan, W. et al, 2008.Conditional functional dependencies for capturing data inconsistencies.ACM Transactions on
Database Systems, Vol. 33 No. 2, pp. 1-48.
Liu, J. et al, 2011. Discover dependencies from data: a review. IEEE Transactions on Knowledge and Data Engineering,
Vol. 24 No 2, pp. 251-264.
Tan, Z. et al, 2011.Improving XML data quality with functional dependencies. Proceedings of the 16th international
conference on Database systems for advanced applications (DASFAA'11). Hong Kong, China, pp. 450-465.
Wang, J. et al, 2005. Removing XML data redundancies using functional and equality-generating dependencies.16th
Australasian Database Conference, 39, 65-74.
Liu, J. et al, 2003. Functional Dependencies, From Relational to XML, Perspectives of System Informatics, LNCS Vol.
2890, pp. 531-538.
Shahriar, M. S. et al, 2008. Preserving Functional Dependency in XML Data Transformation. Advances in Databases and
Information Systems, Lecture Notes in Computer Science (LNCS), Vol. 5207, pp. 262-278.
Shahriar, M. S. et al, 2009. Towards Data Quality and Data Mining Using Constraints in XML. International Journal of
Database Theory and Application. Vol. 2, No. 1, pp. 23-30.
Vo, L. T. H. et al, 2011. Discovering Conditional Functional Dependencies in XML Data. Proceedings of Australasian
Database Conference (ADC 2011), Perth, Australia, pp. 143-152

182
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

ESCALONAMENTO DE TAREFAS EM FERRAMENTA DE

SEQUENCIAMENTO GENÉTICO

Jéfer Benedett Dörr, Guilherme Galante e Luis Carlos E. de Bona

Universidade Federal do Paraná

RESUMO
Este trabalho propõe um escalonador de tarefas para controlar a demanda de envio de lacunas encontradas durante o
processo de sequenciamento genético para o processamento, considerando os recursos computacionais disponíveis. Estas
lacunas são espaços sem representação no processo de sequenciamento genético. Esta atividade gera muitas tarefas
concorrentes que consomem uma grande quantidade de recursos computacionais, principalmente memória. O objetivo do
escalonador é evitar que sejam solicitados mais recursos computacionais do que os que podem ser fornecidos, pois nesse
caso, o sistema sofre degradação de desempenho e causa atraso no tempo de processamento das tarefas. A motivação para
este trabalho é a melhoria na eficiência da execução do fechamento de lacunas no sequenciamento de genomas. Para a
avaliação da proposta, foi implementado um escalonador de lacunas com políticas de escalonamento baseadas no
monitoramento dos recursos computacionais.

PALAVRAS-CHAVE
Bioinformática; Escalonamento de Tarefas; Sequenciamento Genético.

1. INTRODUÇÃO
As informações contidas no genoma podem ser de grande valor para muitos estudos. O genoma é toda a
informação hereditária codificada no DNA, que é passada para os descendentes de um organismo, sendo
formado por monômeros chamados nucleotídeos. Cada um destes nucleotídeos possui uma molécula
denominada base, que pode ser Adenina, Citosina, Timina ou Guanina.
Para conhecer o DNA de um organismo é necessário extrair estes dados utilizando um sequenciador
genético [18] e em seguida sequenciá-los. O sequenciador genético extrai do organismo alvo uma grande
quantidade de pequenos fragmentos de DNA desordenados e repetitivos [20, 21, 23] que precisam ser
montados para obter uma sequência consensus das bases que representam um DNA [24, 25]. O processo de
montagem exige um grande poder computacional e um conjunto de algoritmos específicos e eficientes para
realizar o sequenciamento [17, 26].
O pipeline denovo2 [15, 16] é um conjunto de programas bastante utilizado para realizar a montagem
deste grande volume de dados obtidos dos sequenciadores e a partir destes dados gerarem uma sequência
consensus de DNA. A montagem é realizada pelo velvet [7, 8, 9], um montador que utiliza grafos de Bruijn,
uma abordagem capaz de tratar a grande quantidade de dados com boa cobertura [22]. Após a montagem,
realiza-se o fechamento de lacunas (gaps), que consiste em encontrar representação de bases para posições
vazias. Nesse processo, uma instância do montador velvet é utilizada para cada lacuna, resultando em uma
grande quantidade de tarefas.
Estas diversas instâncias são executadas simultaneamente e em alguns casos podem exigir recursos de
memória maiores do que o ambiente computacional pode disponibilizar. As tarefas em execução são bastante
heterogêneas, ocupando desde poucos até centenas de Gigabytes (GB). Manter todas as tarefas em execução
consome toda a memória disponível e, como consequência, o sistema entra em uma situação de degradação
de desempenho, causando atraso no processamento das tarefas. Esta situação pode ser evitada com a
verificação dos recursos computacionais disponíveis antes de iniciar novas instâncias do montador. Com este
objetivo, um escalonador de tarefas é proposto.
Com o escalonador proposto, ao invés de processar todas as tarefas ao mesmo tempo e sem nenhum
critério como era feito originalmente, as tarefas são disparadas observando a disponibilidade dos recursos

183
ISBN: 978-972-8939-96-0 © 2013 IADIS

necessários para a sua execução. Dessa forma, diversas tarefas podem ser executas em paralelo consumindo
os recursos de forma controlada, não causando o problema de degradação de desempenho e resultando na
redução do tempo necessário para o processamento das tarefas. Com esta abordagem, o tempo de execução
foi reduzido em até 55% em relação ao tempo obtido na implementação original.
O restante do texto está organizado da seguinte maneira. Na Seção 2 são apresentados os trabalhos
relacionados. A Seção 3 apresenta os detalhes do problema encontrado durante a execução do pipeline de
sequenciamento genético denovo2. A Seção 4 apresenta o escalonador proposto. Na Seção 5 são apresentados
os resultados dos experimentos. Por fim, a Seção 6 apresenta as conclusões deste trabalho e sugere trabalhos
futuros.

2. TRABALHOS RELACIONADOS
Este trabalho faz o escalonamento de tarefas prevenindo a paginação e o trashing em um super computador
paralelo utilizando expectativa de uso de memória de cada tarefa, tendo relação com os seguintes trabalhos.
Em [10] é apresentado o problema de divisão de recursos para muitas tarefas simultâneas em um sistema
paralelo, o que pode resultar em problemas de paginação não tornando possível garantir a qualidade de
serviço para a execução de todas as tarefas. A paginação prejudica o sincronismo entre as tarefas. Uma
alternativa é impor controles de acesso, e só admitir novas tarefas que se encaixam na memória disponível.
Apesar de sofrer de execução atrasada, isto leva a um melhor desempenho geral, evitando os efeitos nocivos
da paginação e do trashing. Assim como também em [5] é avaliado o impacto do uso de memória para o
escalonamento de tarefas considerando o longo prazo para evitar os problemas de paginação e trashing em
super computadores paralelos utilizando as características de uso de memória de cada tarefa. Por fim, em
[11] é explorada a prevenção da paginação e do trashing para o escalonamento eficiente de tarefas paralelas.

3. PIPELINE DENOVO2: PROBLEMAS ENCONTRADOS

Dependendo do conjunto de dados a ser processado, a execução do pipeline denovo2 pode consumir toda
memória disponível, causando lentidão no sistema computacional como um todo e fazendo com que a
execução da tarefa seja prolongada indefinidamente.
Para identificar a origem do problema, foi necessário realizar o acompanhamento do trabalho realizado
por cada fase do pipeline denovo2. Para isto utilizou-se uma máquina Altix-UV 100 que disponibiliza, na sua
atual configuração, um total de 256 GB de memória RAM e 64 núcleos de processamento. Foram executados
experimentos com o conjunto de dados denominado Conjunto Treinamento1, fornecido pelo Departamento de
Bioquímica da Universidade Federal do Paraná. Não foram disponibilizadas mais informações sobre o
conjunto de dados devido a sigilo de pesquisa.
O Conjunto Treinamento, possui o tamanho de 111,6 milhões de pares de bases, contém 4.756 lacunas
que ocupam 8 GB de espaço em disco, e resulta em uma saída de 300 GB de dados. Com a utilização deste
conjunto de dados a execução ocorreu normalmente até a fase de montagem, no entanto na fase de
fechamento de lacunas foi possível verificar o consumo da totalidade da memória disponível impactando no
desempenho da aplicação.
Nesta fase, para cada uma das lacunas encontradas uma instância do velvet é executada, de modo a tentar
realizar a montagem dos trechos que ficaram sem representação de bases. Este procedimento é repetido 4
vezes com a parâmetros distintos para cada lacuna. Como todas as instâncias são executadas
concorrentemente, é possível estimar aproximadamente 280.000 tarefas simultâneas para o caso do Conjunto
Treinamento.
Esta grande quantidade de tarefas simultâneas exige alocação de memória para manter as lacunas em
execução. Nesta etapa os 512 GB de memória RAM não são suficientes e são utilizados ainda 8 GB de swap.
Ao utilizar trocas na memória virtual, swapping, a velocidade de acesso aos dados cai drasticamente [1]. O
consumo excessivo de memória RAM pela grande quantidade de tarefas em execução e a necessidade de
escrever e ler muitos dados do disco rígido causada pelo mecanismo de paginação, fazendo com que os

1
Não foram disponibilizadas mais informações sobre o conjunto de dados devido a sigilo de pesquisa.

184
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

processos fiquem esperando muito tempo pelo uso da CPU. Este problema é conhecido como thrashing, que
geralmente provoca sérios problemas de desempenho tornando o sistema inutilizável [12].
O trashing é fenômeno que ocorre quando é realizada paginação excessiva reduzindo a utilização de CPU
e a vazão. Como fator agravante do trashing o sistema operacional detecta que a CPU está ociosa (durante o
fechamento de lacunas o uso de CPU fica abaixo de 1%) e admite mais processos aumentando o nível de
multiprogramação, e consequentemente a taxa de falha de páginas, piorando o desempenho [11, 12]. O
gráfico da Figura 1 adaptado de [12] demonstra como o trashing afeta o desempenho, o eixo X demonstra o
aumento do nível de multiprogramação, eneste o eixo Y demonstra o rendimento da execução. Enquanto o
esperado é um aumento de desempenho com o aumento do nível de multiprogramação, o rendimento cai
subitamente após uma carga crítica [12].

Figura 1. Desempenho esperado sendo afetado pelo trashing

Com os experimentos realizados foi possível constatar que o problema é a grande quantidade de tarefas
sendo executas em paralelo. Uma maneira de resolver este problema é organizar a instanciação destas tarefas
levando em consideração a disponibilidade de recursos computacionais.

4. ESCALONADOR DE TAREFAS PARA O DENOVO2

É considerado um escalonador de tarefas um componente que faz a gerência de recursos. Escalonar consiste
em determinar em que ordem as tarefas serão executadas. Um escalonador é a ferramenta que permite
realizar o controle das tarefas de acordo com as políticas, restrições apresentadas [2, 3]. O problema básico
do escalonador é satisfazer objetivos como obter tempo de resposta rápido, maximizar a produção do sistema
(vazão), maximizar a utilização do processador, evitar a espera indefinida, conciliar tarefas de alta e baixa
prioridade e minimizar o tempo de execução [1, 4, 5, 6] de acordo com o critério de escalonamento definido.
O escalonamento das tarefas envolve três principais componentes: consumidores, recursos e política. As
tarefas esperando para serem executadas são os consumidores. Os recursos são os recursos computacionais
disponíveis, como a memória, o disco e o processador. Por fim, a política de escalonamento é o conjunto de
regras utilizadas para determinar quando e qual tarefa deverá ser executada. A política definida pelo
escalonador impacta diretamente no desempenho da aplicação que esta controlando.
O escalonador proposto utiliza informações do sistema como políticas de escalonamento. Ao receber uma
nova lacuna para ser processada, o escalonador já conhece a expectativa de uso máximo de memória RAM
para aquela lacuna. Então a memória livre da máquina naquele momento é consultada para verificar se existe
a possibilidade de executar a lacuna sem extrapolar os limites de memória disponível, como demonstrado na
Seção 4.2. Realizada esta consulta, caso a condição satisfeita, o escalonador pode submeter uma nova lacunas
para ser executada. Em seguida o escalonador recebe outra lacuna e realiza este mesmo processo de
verificação antes de submetê-la a execução, como demonstra o algoritmo da Figura 2. Desta forma algumas
tarefas sofrem atraso de submissão, mas é garantida toda execução dentro dos limites da capacidade da
máquina e desta forma permitindo uma execução mais efetiva resultando em ganho de desempenho.

185
ISBN: 978-972-8939-96-0 © 2013 IADIS

A política utilizada no escalonador proposto é a previsão de uso de memória, considerando a memória

livre dada por um controle interno. O escalonador dispara uma tarefa quando a memória disponível for maior
que a quantidade de memória prevista para a execução da tarefa.

Figura 2. Implementação de algoritmo para escalonamento de lacunas

4.1 Previsão de Uso de Memória

É possível que conjuntos de dados diferentes ocupem o mesmo espaço em disco que outros conjuntos. Então
duas lacunas com o mesmo espaço ocupado em disco podem ter uma grande diferença no tempo de execução
e na memória consumida.
Para prever o uso de memória pela execução das lacunas, foram selecionadas 4 amostras de lacunas para
5 diferentes classes de intervalos de tamanhos. As amostras foram classificadas de acordo com o tamanho
ocupado em disco e nas classes: mini (até 3 Megabytes (MB)), pequeno (de 3,1 a 17 MB), médio (de 17,1 a
37 MB), grande (de 37,1 a 77 MB) e extra (acima de 77,1 MB). Para cada uma destas classes foi calculada a
média de uso de memória RAM e somado o desvio padrão, de modo que estes dados projetem a expectativa
máxima do uso de memória, como demonstra a Tabela 1. Expectativa de uso de memória RAM pelas classes
das lacunas.
Tabela 1. Expectativa de uso de memória RAM pelas classes das lacunas

Mini Pequeno Médio Grande Extra grande

Tamanho em disco (MB) 3 13 37 77 112
Média de uso de memória (GB) 0,6 3,5 10 32 80
Desvio padrão 0,4 0,5 3 3 5
Previsão de uso de memória RAM (GB) 1 4 13 35 85

Com estes valores foi criada uma base de dados de valores estimados que cada classe de lacuna utiliza
durante o processamento. Estes valores são utilizados na política de decisão do escalonador para avaliar se
submete novas lacunas ou, se aguarda até liberar a quantidade necessária de memória.
A memória livre no sistema é armazenada em uma variável, a partir deste momento é esta variável que
vai responder pela expectativa de memória livre da máquina. Como o pico de uso de memória das tarefas é
próximo ao seu término, o escalonador deve considerar a longo prazo, então por este motivo ao lançar uma
tarefa a memória livre esperada é consultada desta variável e não diretamente do sistema. A expectativa de
uso máximo de memória para a lacuna que será executa é subtraída desta variável e ao término este valor é
devolvido. Desta forma faz-se um controle paralelo da quantidade de memória disponível e que pode ser
alocada sem sobrecarregar o sistema.

186
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

5. RESULTADOS EXPERIMENTAIS
Para avaliar os resultados obtidos foi feita uma análise comparativa do comportamento dos recursos
computacionais durante a execução do escalonador original com a execução do escalonador proposto, que
implementa nas políticas de escalonamento os pontos levantados durante este trabalho que poderiam resultar
em melhoria de desempenho. As ferramentas utilizadas no monitoramento dos recursos foram ferramentas do
próprio sistema operacional GNU/Linux SUSE Enterprise Server 11 SP1 versão 64. Os resultados foram
obtidos observando os logs gerados durante a execução de cada uma das duas alternativas para o fechamento
das lacunas.
Como consequência do monitoramento dos recursos e gerenciamento das tarefas, o gráfico de Figura 3
demonstra a diferença dos tempos obtidos na execução das duas abordagens utilizando o mesmo conjunto de
lacunas, resultantes do Conjunto Treinamento1. No eixo X é apresentado o tempo em horas e no eixo Y estão
representados em azul o escalonador original e em vermelho o escalonador proposto.

Figura 3. Comparativo dos tempos de execução

O gráfico da Figura 4 demonstra em vermelho o uso de memória durante execução do script original
escalonador original e em azul da implementação alternativa escalonador proposto. No eixo Y está
representada em GB a quantidade de memória RAM utilizada nas execuções ao longo do tempo em horas
que é representado no eixo X. A linha em verde indica o limite em GB da memória disponível, valor que
nunca deveria ser extrapolado.Como pode ser visto no gráfico da Figura 4, o escalonador original, em
vermelho, solicitou a totalidade da memória RAM disponível e consumiu todo o swap, mantendo o uso
máximo praticamente durante toda a execução. O uso da multiprogramação com o consumo de toda memória
e todo o swap ocasionam o fenômeno de trashing, estendendo o tempo necessário para terminar o
processamento e obter o resultado. Enquanto o escalonador proposto, em azul, em nenhum momento
extrapola a memória disponível e mantém uma margem de segurança para deixar memória disponível para o
sistema. Quando o uso de memória RAM chega perto do limite de memória definido como mínimo
necessário para manter o sistema em pleno funcionamento, o escalonador proposto aguarda liberar memória
para instanciar novas lacunas. Por este motivo, podem ser observadas curvas no gráfico da Figura 4 com o
comportamento parecido com dentes de serra. Quando é liberada memória suficiente, outra lacuna é lançada
para a execução. A memória vai sendo liberada e o escalonador vai efetuando dinamicamente a consulta até
que a quantidade livre seja suficiente para todo o processamento da próxima lacuna, de acordo com a
previsão de uso de memória da política de escalonamento.

Figura 4. Comparativo do uso de memória durante a execução

187
ISBN: 978-972-8939-96-0 © 2013 IADIS

O gráfico da Figura 5 demonstra o uso de CPU durante a execução do escalonador original e do

escalonador proposto para serem comparadas as duas abordagens. Em vermelho está representado o uso de
CPU durante a execução do escalonador original, que devido ao problema de espera por operações de entrada
e de saída ocasionado pelo trashing, o uso do CPU permanece baixo, abaixo de 1%. Em azul pode-se
observar um melhor aproveitamento do tempo de CPU pelo escalonador proposto. Por monitorar os recursos
não sobrecarregar o sistema, lançando novas tarefas apenas quando o recurso necessário para execução
estiver disponível, foi possível evitar o problema do thrashing. Não sofrendo da degradação causada pelo
trashing pode-se aproveitar melhor a capacidade de processamento e com isto o tempo de execução diminui.

Figura 5. Demonstrativo de uso de CPU durante o execução das alternativas para o fechamento de lacunas
O uso do disco foi monitorado pelo resultado do comando iostat do sistema operacional GNU/Linux, que
reporta estatísticas de entrada e saída do sistema. No modo de exibição estendida, com o uso do parâmetro -x
é possível visualizar o resultado do campo %util, que indica a porcentagem da utilização, vazão, do acesso ao
disco.
Este campo indica o quanto está ocupada a capacidade do disco atender a novas requisições, a taxa de
ocupação da vazão do disco. O campo %util em 100% indica saturação no acesso ao disco, quando o acesso
ao disco esta saturado, o dispositivo se torna um gargalo, reduzindo o desempenho do sistema.. Valores
acima de 100% indicam que o acesso esta congestionado, o que resulta em espera no acesso ao disco e
consequentemente uma maior demora para o término da atividade. Operações de leitura e escrita estão sendo
um gargalo e atrasando a evolução da execução do fechamento de lacunas. Neste caso, a espera pelo acesso
ao disco se torna um gargalo que atrasa todo o sistema. Mas com o controle de memória resultante do uso do
escalonador, este índice se manteve baixo e contribuiu para a redução do tempo de execução.
A Figura 6 compara os resultados do comando iostat demonstrando o pico da porcentagem de utilização
do disco durante a execução do escalonador original e do escalonador proposto. Como pode ser observado no
gráfico da Figura 6, o valor da variável %util do escalonador original, em vermelho, atingiu valores de pico
de 5000%. No caso do escalonador proposto, em azul, devido a implementação da verificação dos recursos
computacionais antes de lançar novas lacunas, este valor se manteve abaixo de 10% durante todo o tempo da
execução, não ocasionando nenhum atraso.

Figura 6. Demonstrativo de espera no acesso ao disco

188
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Como demonstram os gráficos das Figuras 4 e 6 os recursos de memória e acesso ao disco eram exigidos
além da sua disponibilidade, o que causava gargalo de desempenho e não permitia aproveitamento do
processamento, como mostra o gráfico da Figura 5 e, consequentemente causava atraso na execução das
tarefas. Gerenciando o uso destes recursos foi possível obter uma melhoria no desempenho por evitar o
gargalo e o problema de trashing, sendo possível reduzir o tempo de execução como demonstrado no gráfico
da Figura 3.

6. CONCLUSÃO E TRABALHOS FUTUROS

Com o uso do escalonador foi possível controlar as tarefas para que utilizassem os recursos de forma
eficiente e fosse possível executar diversas tarefas em paralelo. Com esta abordagem, o tempo de execução
do conjunto de dados Conjunto Treinamento1 utilizado nos experimentos foi reduzido em 55% em relação ao
tempo obtido na implementação original.
Como trabalhos futuros, é possível melhorar este escalonador atualizando os campos de previsão de uso
de memória para manter em execução paralela a maior quantidade possível de tarefas. O escalonador pode
ser melhorado utilizando o escalonamento best-fit para escolher a melhor tarefa e não aguardar os recursos
para a próxima da fila. Como o processamento de cada tarefa é independente, pode-se propor um
processamento distribuído e ainda como há um grande fluxo de leitura e escrita em disco durante todo o
tempo, uma execução em memória poderia ser mais eficiente.

REFERÊNCIAS
[1] TANENBAUM, A. S. e ZUCCHI, W. L. 2009. Organização estruturada de computadores. Pearson Prentice Hall.
[2] CASAVANT, T. L. e KUHL, J. G. 1988. A taxonomy of scheduling in general-purpose distributed computing
systems. IEEE Transactions Software Engineering (TSE), Vol. 14 No.2, pp 141–154.
[3] EL-REWINI, H.; LEWIS, T. G. e ALI, H. 1994. Task scheduling in parallel and distributed systems. Prentice-Hall,
Inc., Upper Saddle River, NJ, USA.
[4] T. KUNZ. 1991. The influence of different workload descriptions on a heuristic load balancing scheme. In IEEE
Transactions Software Engineering (TSE), Vol. 17, No. 7, pp 725–730.
[5] SETIA, S.; SQUILLANTE, M. e NAIK, V. 1999. The impact of job memory requirements on gang-scheduling
performance. SIGMETRICS Performance Evaluation Review (PER),Vol. 26, No.4, pp 30–39.
[6] WU, M. e SUN, X. 2004. Memory conscious task partition and scheduling in grid environments. Proceedings of the
5th IEEE/ACM International Workshop on Grid Computing, GRID ’04, pp 138–145, Washington, DC, USA.
[7] ZERBINO, D. R. 2008. Velvet Manual - version 1.1. "Disponível em:
http://helix.nih.gov/Applications/velvet_manual.pdf. Acessado em Dez./2012".
[8] ZERBINO, D. R. 2009. Genome assembly and comparison using de Bruijn graphs. Hinxton, Cambridge, United
Kingdom.
[9] ZERBINO, D. R. e BIRNEY, E. 2008. Velvet: algorithms for de novo short read assembly using de Bruijn graphs.
Genome research, Vol. 18 No.5, pp 821–9.
[10] BATAT, A. e DROR, F. 2000. Gang scheduling with memory considerations. in Proc. Of the 14th Intl. Parallel and
Distributed Processing Symp., pp 109–114.
[11] NIKOLOPOULOS, D. S.e POLYCHRONOPOULOS, C. D. 2003. Adaptive scheduling under memory constraints
on non-dedicated computational farms. Future Gener. Comput. Syst. Vol. 19, No. 4 , pp 505-519.
[12] DENNING, P. J. 2008. Thrashing. Wiley Encyclopedia of Computer Science and Engineering. Wiley Encyclopedia
of Computer Science and Engineering.
[13] DENNING, P. J. 1968. Thrashing: its causes and prevention. Proceedings of the December 9-11, 1968, fall joint
computer conference, part I (AFIPS '68 (Fall, part I)). ACM, New York, NY, USA.
[14] Life Technologies. 2009. v.2.2. De Novo Error Correction for SOLiD data SAET "Disponível em:
http://www.biostars.org/static/downloads/solid/47solid-denovo-assembly/saet.2.2/SAET.v2.2.pdf. Acessado em
Mar./2011".
[15] Life Technologies. 2012. Project denovo. "Disponível em: http://solidsoftwaretools.com/gf/project/denovo.
Acessado em Jun./2012".

189
ISBN: 978-972-8939-96-0 © 2013 IADIS

[16] Applied Biosystems. 2010. SOLiD de novo accessory tools 2.0 1. "Disponível
http://gsaf.cssb.utexas.edu/wiki/images/7/71/DeNovo_Assembly_Pipeline_2.0.pdf. Acessado em Fev./2012".
[17] PEVZNER, P. ; TANG, H e WATERMAN, M. S. 2001. An Eulerian path approach to DNA fragment assembly.
Proceedings of the National Academy of Sciences of the United States of America, Vol. 98, No. 17, pp 9748–53.
[18] SHENDURE, J.; WANG, M. D.; et al. 2005. Accurate multiplex polony sequencing of an evolved bacterial genome.
Science. Vol. 309, No. 5741, pp 1728–32. New York, USA.
[19] MEIDANIS, J. SETUBAL, J. C. 1997. Introduction to Computacional Molecular Biology. PWS Publishing
Company.
[20] PANDEY, V.; NUTTER, R. C. e PREDIGER, E., 2008. Next-generation genome sequencing: Twoards personalized
medicine. Wiley-VCH verlag GmbH Co.
[21] CHAISSON, M.; PEVZNER, P. e TANG, H. 2004. Fragment assembly with short reads. Bioinformatics, Vol. 20,
No. 13, pp. 2067–74. Oxford, England.
[22] COMPEAU, P.; PEVZNER, P. e TESLER, G. 2011. How to apply de Bruijn graphs to genome assembly. Nature
biotechnology, Vol. 29, No. 11, pp. 987–91.
[23] SUNDQUIST, A.; RONAGHI, M.; TANG, H.; PEVZNER, P. e BATZOGLOU, S. 2007. Whole-genome sequencing
and assembly with high-throughput, short-read technologies. PloS one, Vol. 2, No. 5, pp. 484.
[24] METZKER M. L. 2009. Sequencing technologies, the next generation. Nature Reviews Genetics, Vol. 11, No. 1, pp.
31–46.
[25] MARDIS E. The impact of next-generation sequencing technology on genetics. Trends in genetics : TIG, 24(3):133–
41, mar de 2008.
[26] CHAISSON, M. J.; BRINZA, D. e PEVZNER, P. 2009. De novo fragment assembly with short mate-paired reads:
Does the read length matter? Genome research, Vol. 19 No. 2, pp. 336-46.

190
Artigos Curtos
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

APLICABILIDADE DE TÉCNICAS DE ALGORITMOS

GENÉTICOS VIA WEB UTILIZADA EM APLICAÇÕES DE
GERENCIAMENTO DA CARTEIRA DE CLIENTES E DO
SCHEDULE DIÁRIO DA FORÇA DE VENDAS BANCÁRIA

Ricardo Soares Bôaventura1, Bruno Queiroz Pinto1, Miriellen Augusta da Assunção1,

Keiji Yamanaka2 e Christina Testa Marques3
1
Instituto Federal do Triângulo Mineiro – Câmpus Uberlândia Centro, Rua Blanche Galassi, 150 CEP 38401-114
Uberlândia/MG, Brasil
2
Universidade Federal de Uberlândia – Faculdade de Engenharia Elétrica, Av. João Naves de Ávila, 2121 CEP 38408-
100 Uberlândia/MG, Brasil
3
ESAMC - Faculdade de Administração, Propaganda e Marketing de Uberlândia, Av.Vasconcelos Costa, 270 CEP
38400-448 Uberlândia/MG, Brasil

RESUMO
O Problema da definição do Schedule diário dos funcionários para venda de produtos é estrategicamente importante para
as empresas, pois, minimiza custo, aumenta eficiência e lucro. Este problema é semelhante ao problema do caixeiro
viajante e ao problema do multi-rotas de veículos na área da computação, com o diferencial de selecionar clientes de
acordo com a maior rentabilidade, faturamento e estratégias da empresa. O objetivo é descobrir diariamente,
semanalmente ou mensalmente a melhor rota a ser construída para visitar os clientes sempre iniciando e retornando no
ponto de partida. O sistema foi desenvolvido utilizando as técnicas de algoritmos genéticos e pode ser acessado via Web.
O sistema permite recalcular a rota de um dia retirando os clientes que não conseguiu agendar a visita. O resultado da rota
apresentado pelo sistema utiliza a representação de mapas geográficos informados pelo serviço do Google Maps.

PALAVRAS CHAVES
Algoritmo genético, problema de roteamento, vendas bancárias

1. INTRODUÇÃO
As compras realizadas pelos clientes em estabelecimentos físicos e pela Internet vem aumentando a cada dia
e as empresas necessitam iniciar um processo interno para encontrar soluções que melhorem suas operações
internas agregando valores importantes aos produtos e/ou serviços sem aumentar demasiadamente os custos
internos. Essas alternativas bem implementadas aumenta a satisfação dos clientes.
Para Carvalho et al. (2007), a logística tem como objetivo diminuir as dificuldades encontradas entre a
produção de bens ou serviços e a necessidade de consumo, uma vez que, os recursos necessários para a
produção e os consumidores podem estar geograficamente distantes. E segundo Ballou (2006), a missão da
logística é entregar os produtos ou serviços certos nos lugares certos, no momento certo, e nas condições
desejadas. Para conseguir respeitar essas variáveis faz-se de uma análise adequada de informações: tempo de
viagem, quantidade de visitas ou entregas de produtos máximas, peso excedente e espaço ocioso.
Segundo Novaes (1989) e Kaiser (2007), o principal problema de empresas na área de logística associada
ao transporte é o roteamento de veículos cujo objetivo é encontrar um conjunto de rotas que partem de um
único depósito para vários pontos de entrega com a característica de minimizar a distância total a ser
percorrida. Os métodos são classificados em cinco classes: heurísticos, meta-heurísticos, programação
matemática, simulação e os métodos baseados em inteligência artificial (Conceição et al., 2004).

193
ISBN: 978-972-8939-96-0 © 2013 IADIS

Os Algoritmos Genéticos é uma técnica de inteligência artificial e são métodos de busca aleatória que
permite encontrar soluções aproximadas em problemas de otimização e busca. Esse algoritmo é uma
subclasse dos algoritmos evolutivos que usam técnicas que estão da biologia evolutiva como: mutação,
seleção natural e cruzamento (Mitchell, 1996; Tang et al., 1996; Goldberg, 1989; Haupt & Haupt, 2004).
O presente trabalho tem como objetivo desenvolver um sistema denominado, Gestão da Carteira de
Clientes e Gerenciamento do Schedule Diário da Força de Vendas Bancária baseado no método de
inteligência artificial (algoritmos genéticos). O sistema proposto baseada nas distâncias extraídas do serviço
do Google e apresenta ao gerente de vendas no formato de mapas geográficos informados pelo Google Maps.

2. CARACTERIZAÇÃO DO PROBLEMA E MÉTODOS

O sistema proposto é semelhante ao problema do caixeiro viajante (Bodin Et Al., 1983) e ao problema de
roteirização de veículos (Christofides, 1979) e pode ser descrito da seguinte forma: dado uma central de
partida (residência do funcionário, hotel ou empresa) e vários clientes ligados à central de partida e entre si
através de vários caminhos com custos diferentes (distâncias reais em quilometragem). Com o objetivo de
descobrir a cada dia da semana a melhor rota a ser construída por um gerente de vendas da instituição
financeira, que saia do ponto de partida, visite alguns clientes e retorne para o ponto de partida novamente.
Para análise do modelo proposto, utilizou-se de dados de um banco financeiro do estado de Minas Gerais,
com uma carteira de 150 clientes localizados no estado da Bahia nas cidades de Salvador, Catu, Pojuca,
Lauro de Freitas e Simões Filho. Os dados do banco e dos clientes (nome, CNPJ) foram preservados e não
serão apresentados no corpo do trabalho, porém informações como endereço, cidade, bairro, estado, valor do
faturamento e valor da rentabilidade foram informadas corretamente para a aplicação da técnica para
encontrar o roteamento.
Segundo a referida instituição financeira os clientes são divididos em quatro grupos: clientes: são
empresas que possuem serviços com o banco; potenciais: são empresas que podem vir a serem futuros
clientes; obrigados a visitar: são empresas que não podem deixar de serem visitadas durante a semana ou
mês; e visitados: são empresas que já foram visitadas e não precisam ser incluídas no processo de visita
dependendo da data da última visita e da frequência determinada pela empresa.

3. APLICAÇÃO DE GERENCIAMENTO DE SCHEDULE DIÁRIO DA

FORÇA DE VENDA
O sistema permite através de um banco de dados inserir informações dos funcionários, endereço de partida
do gerente de vendas. É Importante salientar que o gerente pode cadastrar somente um endereço de partida,
caso o mesmo deseje cadastrar outro endereço ele deverá alterar o já cadastrado. Cada gerente de vendas
possui uma carteira de clientes. Serão armazenadas as distâncias reais entre todos os pontos observados.
Estas distâncias reais serão informadas pela API do Google Maps.

3.1 Módulo de Cadastro

O sistema permite através de um banco de dados inserir informações dos funcionários (matricula e nome),
endereço de partida (rua, bairro, cidade, estado, CEP, latitude e longitude) do gerente de vendas. É
importante salientar que o gerente pode cadastrar somente um endereço de partida, caso o mesmo deseje
cadastrar outro endereço ele deverá alterar o já cadastrado.
Cada gerente de vendas possui uma carteira de clientes (CNPJ, nome, rua, bairro, cidade, estado, CEP,
valor do faturamento, valor da rentabilidade, data da ultima visita, status do cliente, latitude e longitude).
Serão armazenadas as distâncias reais entre o endereço de partida e todos os clientes do funcionário e entre
todos os clientes do gerente com o ponto de partida e também as distâncias reais entre todos os clientes. Estas
distâncias reais serão informadas pela API do Google Maps.

194
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

3.2 Módulo de Consultas

Depois de carregado a base de dados, o sistema permite realizar consultas simples e personalizadas. Em
quaisquer consultas, o sistema apresenta o mapa para o gerente visualizar a localização geográfica dos
clientes. A Figura 01 mostra uma consulta simples com os clientes em potenciais localizados em Salvador.

Figura 1. Clientes somente potenciais pertencentes à carteira de clientes do funcionário

3.3 Módulo de Roteamento

Para a geração da rota o gerente de vendas poderá escolher quaisquer tipos de clientes fazem parte do roteiro
de visitas (Figura 02). O módulo de roteamento é dividido em sub-módulos: sub-módulo de inserção de
parâmetros iniciais utilizados no algoritmo genético; sub-módulo de inserção de despesas com a visita
(diárias, combustível, alimentação); e sub-módulo de inserção de restrições em que o gerente poderá escolher
qual o perfil dos clientes;

4. RESULTADOS ENCONTRADOS
No presente artigo serão apresentados os resultados de três experimentos que foram simulados no sistema
proposto e apresentados para a análise da instituição financeira em estudo. Nesses estudos de casos a empresa
possui um gerente de vendas que atende os clientes que estão situados na cidade de Salvador e proximidades.
Segundo as informações coletadas do sistema interno do banco em um dia o gerente de vendas visitou
clientes das cidades de Catu e Pojuca no estado da Bahia tendo como ponto de partida um hotel de Salvador
(hotel não foi informado).
Porém esse mesmo gerente de vendas informou no sistema interno do banco que visitou 10 clientes em
um dia totalizando 249 quilômetros rodados. Além disso, o gerente de vendas deixou de visitar um cliente em
Catu e um cliente em Pojuca que eram obrigados a serem visitados, pois, estes tinham sidos indicados pelo
banco (Cliente24 e Cliente106). Portanto o banco não sabe qual o motivo do gerente de vendas não ter
visitado esses dois clientes, pois o mesmo não inseriu nenhuma observação no sistema.
O mesmo caso foi simulado no sistema desenvolvido. Como entrada foram submetidos 23 clientes das
cidades de Catu e Pojuca, os quais seriam selecionados 10 clientes que deveriam ser visitados em um dia.

195
ISBN: 978-972-8939-96-0 © 2013 IADIS

Figura 2. Visão geral do módulo de roteamento

Como não tinha a referência do hotel que o gerente de vendas ficou hospedado, para o teste foi inserido
nos sistemas um hotel localizado no sul de Salvador, ou seja, o hotel mais distante de Pojuca e/ou Catu.
Essas informações foram inseridas no sistema e solicitado ao algoritmo genético que calculasse a melhor
rota. O sistema informou ainda que o gerente de vendas gastaria um total de 231,36 KM (Figura 03).

Figura 3. Resultado do roteamento visitando os clientes de Pojuca/BA e Catu/BA

O resultado apresentado pelo sistema apresentou um ganho de 17,64 KM e, além disso, os dois clientes
que deveriam ser visitados (Cliente24 e Cliente106) estavam na rota do gerente de vendas. Ou seja, esse
modelo possibilitou tanto uma econômica de recursos financeiros, uma vez que houve redução no total de
quilômetros rodados, quanto uma melhor gestão da carteira de cliente do banco, pois forneceu ao gerente de
vendas um roteiro que otimizou seu tempo e portanto o permitiu visitar todos os clientes da rota, inclusive os
prioritários que não haviam sidos atendidos na primeira rota traçada pelo gerente de vendas.

196
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

5. CONSIDERAÇÕES FINAIS
O sistema de gestão de carteira de clientes e gerenciamento do Schedule diário da força de vendas bancária
em todos os casos informados pelo banco mostrou resultados iguais e melhores ao aplicados pelos gerentes
de vendas, obedecendo as restrições impostas pelos gestores da instituição analisada.
Os problemas apresentados pelo banco como: alto custo da viagem; alta quilometragem rodada e clientes
que são obrigatórios a serem visitados e não estão sendo visitados, foram sanados com a construção de um
sistema que permite o banco gerenciar as atividades dos gerentes de vendas.
O modelo proposto facilita a tomada de decisão do gestor, pois lhe fornece a melhor rota a ser traçada
pelo gerente de vendas, considerando inclusive possíveis restrições e clientes prioritários, que merecem
maior atenção da instituição financeira. Não se trata de uma ferramenta estática, pois permite que o usuário
insira ou exclua os clientes a serem visitados dado alguma alteração inesperada, e é de fácil visualização,
uma vez que se utiliza da ferramenta de mapas do Google, amplamente conhecida e utilizada.
A interface gráfica do sistema e permite ao gerente de relacionamento analisar a resposta do sistema com
base em relatórios e mapas geográficos informados pelo Google Maps. Os mapas podem ser apresentados em
forma de: mapa, satélite, hibrida e terreno. O gerente de relacionamento poderá aumentar a escala do mapa
ou diminuir com a ferramenta de zoom. Por fim o gerente de relacionamento poderá verificar a rota passo a
passo através de mapa de roteiro apresentado no lado esquerdo do mapa.

REFERÊNCIAS
BALLOU, R. H. Logística empresarial: transporte, administração de materiais e distribuição física. 5.ª ed., Porto Alegre:
Bookman. 2006.
BODIN, L. D. et al. Routing and scheduling of vehicle and crews: the state of the art. Computers and Operations
Research, v. 10, n. 2, p.63-211, 1983.
BRYANT K. & BENJAMIN A. Genetic Algorithms and the Traveling Salesman Problem. In. Harvey Mudd College,
Departament of Mathematice, 2000
CARVALHO R. B., et al. Gestão da Informação aplicada à logistica: Estudo de caso de uma grande Agroendústria
Brasileira, Anais do VIII ENANCIB – Encontro Nacional de Pesquisa em Ciência da Informação, Salvador, 2007.
CONCEIÇÃO S. V., et al. Impactos da utilização de roterização de veículos em um centro de distribuição: um estudo de
caso. Anais do XXIV ENEGEP - Encontro Nacional de Engenharia de Produção, Florianópolis, 2004.
CHRISTOFIDES, N. The Traveling Salesman Problem. Combinatorial Optimization. Wiley Chichester, p. 131 – 149,
1979.
GOLDBERG D. E. Genetic Algorithms in Search, Optimization and Machine Learning. Addison-Wesley Longman
Publishing Co., Inc. Boston, MA, USA, 1989.
HAUPT R. L. & HAUPT S. E. Practical genetic algorithms. 2nd edition, Wiley-Interscience Publication, 2004.
KAISER M. S., et al. Análise Comparativa entre o TransCad e Heurísticas de Agrupamento e de Roteamento de
Veículos. Anais do XXI ANPET – Associação Nacional de Pesquisa e Ensino em Transportes, Rio de Janeiro, 2007.
MITCHELL, M. An Introduction to Genetic Algorithms. First MIT Press paperback, 1996.
NOVAES, A.G. Sistemas Logísticos: Transporte, Armazenagem e Distribuição de Produtos. Edgard Blucher, São Paulo,
1989.
TANG, K. S., et al., Genetic Algorithms and their Applications. IEEE Signal Processing Magazine, 1996.

197
ISBN: 978-972-8939-96-0 © 2013 IADIS

CONTROLE FUZZY DO ARMAZENAMENTO DE GRÃOS

DE ARROZ

Marcos Rodrigo Sauki, Maicon Bastos Palhano, Gabriel Felippe, Ruano Marques Pereira,
Priscyla W. T. de Azevedo Simões e Merisandra Côrtes de Mattos Garcia
Curso de Ciência da Computação, Universidade do Extremo Sul Catarinense - Criciúma –SC- Brasil

RESUMO
A lógica fuzzy, técnica da inteligência computacional, pode ser aplicada no controle de um processo térmico, como por
exemplo, no controle da temperatura de armazenagem do grão de arroz bruto. Utilizando o microcomputador, dois
dispositivos, sendo um de aquisição de temperatura e o outro do tipo liga/desliga, foi desenvolvido um protótipo,
denominado Arfuzzy, que controla o tempo de ventilação necessário para que a temperatura alcance níveis satisfatórios
no armazenamento do grão de arroz bruto. Assim, o sistema busca operar de forma semelhante ao raciocínio humano, no
sentido de identificar como o operador raciocina ao manipular o sistema de ventilação dos silos. A funcionalidade do
Arfuzzy é a medição e o controle de temperatura na armazenagem do grão de arroz bruto nesses silos. No decorrer do
trabalho, será apresentada a modelagem fuzzy do protótipo e os resultados obtidos pelo mesmo.

PALAVRAS-CHAVE
Inteligência Computacional, Lógica Fuzzy, Controle de Temperatura.

1. INTRODUÇÃO
O controle da temperatura exerce um papel importante para as indústrias que armazenam e beneficiam o
arroz, principalmente em relação ao grão bruto. Este tipo de grão, também chamado de arroz verde, é o que
vai diretamente do produtor para a indústria. Por se tratar de um produto orgânico, com elevado grau de
umidade, sujeito a contaminação por fungos e parasitas, deve ser mantido a uma temperatura adequada
durante o armazenamento, processo este que inicia logo após a colheita.
Apesar dos avanços da engenharia de automação, muitos produtores e indústrias ligadas à agricultura
realizam o armazenamento dos grãos de maneira inadequada. Isso pode ser constatado em algumas empresas
que fazem o beneficiamento do arroz na região carbonífera do sul de Santa Catarina. Apesar dos silos serem
providos de mecanismos de ventilação, eles ainda são ativados manualmente, onde um operador humano
utiliza a própria experiência e alguns fatores envolvidos no processo para acionar esses mecanismos.
Percebe-se então, que por meio da lógica fuzzy é possível automatizar esse processo, trazendo benefícios às
empresas.
Publicada por Zadeh em 1965, a lógica fuzzy é um modelo adequado para tratar a informação imprecisa
em áreas onde o conhecimento é incompleto, pois permite uma representação significativa dos conceitos
vagos inerentes ao raciocínio humano (Zadeh, 2008).
Wang (1997) comenta que a teoria fuzzy está presente em diversas áreas do conhecimento,
principalmente nos domínios do controle e tomada de decisão.
A teoria dos conjuntos fuzzy amplia a teoria dos conjuntos tradicionais, incorporando o conceito de grau
de pertinência. Por exemplo, na frase “mantenha a temperatura do forno alta” a palavra alta é caracterizada
por uma função de pertinência onde o grau de pertinência expressa o quanto a informação pertence a um
determinado conjunto.
Diferente da teoria clássica dos conjuntos, onde o pertencer ou não de um elemento ao conjunto é
representado por 0 e 1, a teoria dos conjuntos fuzzy aplica graus de pertinência entre 0 e 1. Dessa forma, a
pertinência do elemento ao conjunto é gradual podendo assumir todos os valores desde 0 até 1.

198
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Segundo Cox (1994) o que diferencia a lógica fuzzy, da lógica booleana é a capacidade desta de se
aproximar do mundo real, onde não existem somente respostas extremas. A lógica fuzzy dá espaço ao meio
termo apresentando ainda a possibilidade de mensurar o grau de aproximação da solução exata e assim inferir
algo que seja necessário.
Percebe-se então, que um protótipo de sistema fuzzy computadorizado pode substituir o controle manual
com mais eficiência, além de poder reduzir consideravelmente o consumo de energia elétrica utilizados no
processo. Silva, Neves Filho e Silveira Junior (2006) destacam que o uso de controladores fuzzy em
processos industriais tem aumentado consideravelmente nas últimas décadas, como por exemplo: Lekova e
Batanov (1998), Rowlands e Wang (2000), Kazemian (2001), Vieira et al (2007), Rojas et al (2006), Filev e
Syed (2010), Hou e Huang (2004) e Onut et al (2009).

2. METODOLOGIA
Este trabalho objetiva o desenvolvimento de um protótipo que seja capaz de operar de forma semelhante ao
raciocínio humano, no sentido de identificar como o ser humano raciocina ao manipular o sistema de
ventilação dos silos.
Diferente de um controlador convencional onde os parâmetros são ajustados por meio de um ponto de
controle (set point), o Arfuzzy, protótipo desenvolvido neste trabalho, controla o tempo de ventilação
necessário para que a temperatura alcance níveis satisfatórios de armazenamento.
O Arfuzzy foi construído sobre a abordagem fuzzy baseado em regras envolvendo as etapas de
fuzificação, inferência e defuzificação. A metodologia de desenvolvimento iniciou com aquisição do
conhecimento, seguida pela modelagem fuzzy e o desenvolvimento. Posteriormente, o protótipo foi avaliado
para verificar os resultados obtidos.

2.1 Aquisição do Conhecimento

A aquisição do conhecimento foi realizada junto à empresa Kiarroz Fumacense Indústria e Comércio Ltda,
localizada no município de Morro da Fumaça em Santa Catarina, em especial com o responsável pelo
armazenamento do arroz na empresa. Basicamente, consistiu em obter as informações referentes ao domínio
de aplicação, definição das variáveis envolvidas e formação das regras SE-ENTÃO a serem utilizadas.
Durante os encontros realizados com o especialista do domínio de aplicação, entrevistas desestruturadas e
estruturadas foram aplicadas. As entrevistas desestruturadas tinham como objetivo conhecer a dinâmica e os
detalhes referentes ao armazenamento de grãos, e as estruturadas, determinar as variáveis envolvidas e os
limites para cada conjunto fuzzy. O resultado demonstrou que o tipo de controle a ser aplicado no processo
industrial envolvia uma entrada (Temperatura) e uma saída (Tempo de ventilação). Nesse contexto, além da
modelagem fuzzy, uma regra SE-ENTÃO convencional foi adicionada na malha de controle com o objetivo
de ligar e desligar o motor de ventilação.
O critério que o operador utiliza para desligar os motores de ventilação é baseado na própria experiência.
Quando ele acredita que a temperatura amenizou, suspende o sistema de ventilação. Por não haver um
operador dedicado para realizar essa tarefa, muitas vezes esse processo não acontece sistematicamente. Na
prática, é mais conveniente deixar a ventilação ligada durante semanas e até meses o que provoca um gasto
excessivo de energia.

2.2 Modelagem Fuzzy

A definição dos conjuntos fuzzy de entrada e saída, não é uma tarefa trivial, principalmente com relação à
formação dos conjuntos de saída, onde vários ajustes foram necessários até se chegar a um modelo próximo
do raciocínio do operador humano.
As etapas de implementação de um sistema fuzzy compreende as etapas de fuzificação, inferência e
defuzificação.A fuzificação consiste na transformação das variáveis de entrada (crisp) em graus de
pertinência. Esta etapa foi feita aplicando-se a função trapezoidal sobre o antecedente de cada regra, para
determinar o grau de pertinência da variável de entrada TP em cada conjunto fuzzy.
O cálculo realizado pela função trapezoidal é definido por:

199
ISBN: 978-972-8939-96-0 © 2013 IADIS

Onde, x é valor da variável de entrada TP, a ponto onde o grau de pertinência é 0 e γ é ponto onde o grau
de pertinência é 1.
As funções de pertinência para a variável TP foram definidas no intervalo de 30 a 60 graus Celsius,
abrangendo os conjuntos Baixa, Alta e Muito Alta.
Os graus de pertinência resultantes da etapa de fuzificação são então repassados para o mecanismo de
inferência. O objetivo dessa etapa é determinar o peso ou o grau de relevância de cada regra.
Posteriormente, inicia-se a etapa de defuzificação, sendo necessário definir as funções de pertinência para
a variável de saída tempo de ventilação (TV) formada pelos conjuntos fuzzy Mínimo, Médio e Máximo.
A defuzificação transforma os graus de relevância obtidos na etapa de inferência em um valor de saída
(crisp). Esta etapa agrupa as regras com os mesmos consequentes que tenham graus de relevância diferente
de zero e aplica, por exemplo, a união padrão, ou seja, escolhe o maior valor de grau de pertinência.
Então, utilizando o universo de discurso resultante da união dos conjuntos da variável de saída e os graus
de pertinência traçados pela união dos dois conjuntos, aplicou-se na defuzificação a fórmula do Centro de
Gravidade, que informa o ponto central, isto é, o centro da área formada pela união dos dois conjuntos,
indicando o valor da variável de saída TV. De acordo com Simões e Shaw (2007), a fórmula do Centro de

u U
Gravidade é definida por:
N

u  i 1

u
j Out ( ui )
*
N

i 1
Out ( ui )

Onde UOut(ui) são os graus de pertinência que formam o contorno dos dois conjuntos e U i são os valores do
universo de discurso que compõe os dois conjuntos.

2.3 Desenvolvimento
Encontram-se disponíveis na internet algumas ferramentas para o desenvolvimento de sistemas fuzzy, como
por exemplo, o MatLab Toolbox Fuzzy e o UnFuzzy, sendo esta última gratuita. Porém, optou-se em
desenvolver o sistema no ambiente de programação Delphi 8.0. Sendo assim, o protótipo foi projetado para a
plataforma Windows.
No Arfuzzy tem-se as seguintes especificações dos processos: (a) capturar temperatura: processo que
recebe a temperatura capturada pelo sensor por intermédio do componente TcommPortDriver
(Commdrv.pas), e a transmite para a malha de controle. Este processo ocorre a cada segundo, sendo os
parâmetros da comunicação serial definidos no componente da seguinte forma: bits por segundo = 9600; bits
de dados = 8; paridade = nenhuma; bits de para = 1; controle de fluxo = nenhum; (b) avaliar a temperatura
e verificar o status da ventilação: processo que decide o fluxo de controle a seguir, sendo responsável por
verificar como está a temperatura e o status da ventilação (ligada ou desligada). Caso a temperatura seja igual
ou superior a 30 graus e a ventilação estiver desligada, o fluxo é desviado em direção à malha fuzzy. Do
mesmo modo, se a temperatura estiver igual ou superior a 30 graus, porém com a ventilação ligada, a
temperatura não entra na malha fuzzy pois o tempo previsto de ventilação ainda não terminou. Outra situação
em que o fluxo não segue pela malha fuzzy, é quando a temperatura está abaixo de 30 graus; (c) estimar o
tempo de ventilação: processo que realiza a fuzificação, inferência e defuzificação da variável temperatura,
determinando assim o tempo de ventilação necessário; (d) ligar a ventilação: processo que liga a ventilação,
se ela estiver desligada; (e) iniciar a contagem do tempo e alterar o status da ventilação: processo que
inicia a contagem do tempo decorrido assim que a ventilação é ligada. Também altera o status da ventilação
para Ligada; (f) apresentar informações na tela do computador: processo que mostra em tempo real todas
as ações do sistema na tela do computador; (g) verificar o status da ventilação e o final do tempo

200
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

decorrido: processo que verifica se a ventilação está ligada ou não, e também se o tempo previsto de
ventilação já foi atingido; (h) alterar o status da ventilação: processo que altera o status da ventilação para
Desligado. Dessa forma, caso a próxima temperatura capturada for igual ou superior a 30 graus, o fluxo
seguirá pela malha fuzzy; (i) avaliar a temperatura: processo que verifica se a temperatura capturada está
abaixo de 30 graus. Caso afirmativo, a ventilação é desligada; (j) desligar a ventilação: processo que desliga
a ventilação.

2.4 Dispositivos Utilizados

Fazem parte do protótipo dois dispositivos eletrônicos que foram adquiridos no comércio: o dispositivo de
aquisição de temperatura (figura 1(a)) e o dispositivo que liga e desliga o motor de ventilação (figura 1(b)).
Os dispositivos realizam a comunicação por meio do protocolo RS232, utilizando respectivamente as
portas COM4 e COM1 do microcomputador.
Com relação à estrutura geral do sistema, observa-se que o sensor de temperatura, que é resistivo com
faixa de atuação de 0 até 100 °C, é posicionado na parte superior do silo sobre a massa de grãos. Segundo
orientações recebidas pelo especialista em meteorologia agrícola da EPAGRI, este é o local mais indicado,
pois a tendência do ar quente é subir e consequentemente ocupar a região superior da estrutura. Na figura
1(c) tem-se um esboço da estrutura geral do Arfuzzy, onde ambos os dispositivos podem ser observados.

(a)

(c)
(b)
Figura 1. Estrutura geral do Arfuzzy

3. RESULTADOS OBTIDOS
O presente trabalho vem sendo desenvolvido, atualmente encontra-se na etapa de avaliação dos resultados
obtidos, contudo, até o presente momento, além das simulações feitas em laboratório, uma avaliação foi feita
junto com o especialista do domínio de aplicação para avaliar o protótipo desenvolvido. Constatou-se que o
protótipo está próximo do raciocínio do especialista, porém ainda faltam medições mais concretas com
relação ao tempo de ventilação necessário para que a temperatura diminua dentro do silo. Mesmo assim, isso
não chega a ser um problema, já que o universo de discurso da variável tempo de ventilação (TV) é bem
reduzido. Um fator positivo e que previne desgastes no mecanismo de ventilação, é que o motor permanece
ligado por certo tempo, mesmo que a temperatura alcance valores abaixo de 30 graus. No Arfuzzy é
composto por uma interface principal contendo cinco ícones para a interação com o usuário. Entre eles estão:
Ativar (ativa o protótipo); Desativar (desativa o protótipo); Manual (manual do usuário); Créditos
(informações sobre o projeto); Sair (encerra o protótipo).

201
ISBN: 978-972-8939-96-0 © 2013 IADIS

4. CONCLUSÃO
Este trabalho demonstrou como a lógica fuzzy, pode contribuir para a solução de problemas onde as variáveis
envolvidas são elementos vagos e imprecisos. Apresentou alguns conceitos necessários à implementação de
sistemas fuzzy, resultando no desenvolvimento de um protótipo para o controle da temperatura de
armazenagem do arroz bruto, o Arfuzzy.
Devido a grande abrangência da teoria fuzzy, buscou-se utilizar a abordagem que auxiliasse no controle
da temperatura dentro dos silos que armazenam os grãos de arroz bruto, a fim de poder vir a proporcionar
uma maior facilidade no processo de controle. Salienta-se que esse trabalho encontra-se em desenvolvimento,
sendo o Arfuzzy um protótipo que se encontra em fase de testes e avaliação, bem como o refinamento da
base de conhecimento do Arfuzzy junto a outros especialistas, a expansão da ação de controle para vários
silos, inserção de outras variáveis também importantes nesse processo de controle, como por exemplo, a
umidade, empregando-se um sensor a ser acoplado na malha de controle, visto que existe uma relação direta
entre temperatura e umidade.
A abordagem fuzzy parece evoluir mais rapidamente para a direção dos controladores, pois algumas
empresas fabricam controladores híbridos-fuzzy em escala comercial. Porém, apesar do vasto campo de
aplicação e de existir diversos artigos científicos que comprovam a eficiência dessa tecnologia, sistemas
fuzzy ainda são muito pouco utilizados em algumas realidades.

REFERÊNCIAS
Cox, E. 1994. The Fuzzy systems handbook: a practitioner’s guide to building and maintaining fuzzy System, Ap
professional, Boston.
Filev, D., Syed, F., 2010. Applied intelligent systems: blending fuzzy logic with conventional control. International
Journal of General Systems 39 (4), 395–414.
Hou, T., Huang, C., 2004. Application of fuzzy logic and variable precision rough set approach in a remote monitoring
manufacturing process for diagnosis rule induction. Journal of Intelligent Manufacturing 15 (3), 395–408.
Kazemian, H.B. 2001. "Development of an intelligent fuzzy controller," Fuzzy Systems. The 10th IEEE International
Conference on , vol.1, no., pp.517,520.
Lekova, A., Batanov, D., 1998. Self-testing and self-learning fuzzy expert system for technological process control.
Computers in Industry 37 (2), 135–141.
Onut, S., Kara, S., Mert, S., 2009. Selecting the suitable material handling equip- ment in the presence of vagueness.
International Journal of Advanced Manufacturing Technology 44 (7–8), 818–828.
Rojas, I. et al. 2006. Valenzuela, Adaptive fuzzy controller: Application to the control of the temperature of a dynamic
room in real time, Fuzzy Sets and Systems, Volume 157, Issue 16, Pages 2241-2258
Rowlands, H., Wang, L., 2000. An approach of fuzzy logic evaluation and control in SPC. Quality and Reliability
Engineering International 16 (2), 91–98.
Silva, F.V., Neves Filho L. C. e Silveira Jr. 2006. Experimental evaluation of fuzzy controllers for the temperature
control of the secondary refrigerant in a liquid chiller, Journal of Food Engineering, Volume 75, Issue 3, pp. 349-354
Simões, M., Shaw, I. Controle e Modelagem Fuzzy. 2 ed. Edgar Blucher
Vieira, J. P. A. et al. 2007. Controladores fuzzy aplicados ao conversor de geradores de indução duplamente excitados em
sistemas eólicos integrados a sistemas de potência. Sba Controle & Automação, vol.18, n.1, pp. 115-126.
Wang, L-X. 1997. A course in fuzzy systems and control, Prentice Hall, London.
Zadeh, L. A. 2008. Is there a need for fuzzy logic, IEEE, Information Sciences, Vol. 178, No. 13, pp 2751-2779.

202
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

ARBIO: SISTEMA DE GESTÃO DA ARBORIZAÇÃO

Denis Bruno Viríssimo, Marcelo Cristiano Russo, Sergio Brazolin*

e Raquel Dias Aguiar Moraes Amaral*
Instituto de Pesquisas Tecnológicas - Centro de Tecnologia da Informação, Automação e Mobilidade
*Instituto de Pesquisas Tecnológicas - Centro de Tecnologia de Recursos Florestais

RESUMO
As árvores são uma parte essencial do ecossistema terrestre. A arborização urbana, por vezes denominada floresta urbana,
exerce um papel importante na preservação da biodiversidade e das condições ambientais na cidade. A falta de técnicas e
ferramentas apropriadas para sua gestão, no entanto, pode contribuir de forma negativa e acarretar problemas que vão
desde a incompatibilidade com a infraestrutura urbana até a queda de árvores. Com o intuito de contribuir para o
desenvolvimento e aprimoramento destas ferramentas, este trabalho apresenta um software para gestão da arborização
urbana que visa atender às necessidades de municípios e parques.

PALAVRAS-CHAVE
Sistemas de Informação Aplicados; Arborização Urbana; Gestão de Arborização; Linha de Produto Software

1. INTRODUÇÃO
As árvores conferem uma dimensão especial na paisagem das cidades e desempenham um importante papel
no bem estar das comunidades, seja pela capacidade de minimização dos efeitos adversos da ocupação do
meio urbano, ou pelos serviços ambientais prestados como: a promoção e conservação da biodiversidade; o
conforto térmico; a conservação de energia; a melhoria da qualidade do ar; e a proteção dos recursos hídricos
(Schroeder, 1989), (Nowak, Dwyer e Childs, 1998), (SVMA, 2004).
A arborização deficiente ou mal planejada, além de influenciar na qualidade estética e psicológica de uma
cidade, afeta diretamente o seu clima, pois a falta de sombreamento está fortemente relacionada ao aumento
das temperaturas de superfícies impermeáveis e, consequentemente, à diminuição do conforto térmico
humano (Silva, 2012). A retenção ou absorção de partículas atmosféricas (emissões veiculares) também é
prejudicada deixando de amenizar os ambientes poluídos e afetando à saúde humana (Moreira, 2010).
A queda de árvores nas cidades é, sem dúvida, outro agravante (Brazolin, 2009). O desconhecimento
quanto ao seu estado fitossanitário (pragas e doenças) e das condições de plantio (interferências, canteiros e
passeios públicos) aliado, ou não, aos períodos de chuvas e ventos fortes, predispõe à queda de árvores,
podendo ocasionar sérios danos, desde perdas materiais até humanas.
A inexistência de planejamento urbano e a seleção e plantio inadequados das espécies arbóreas indicam
também a falta de critérios técnicos na correta implantação da arborização urbana, resultando na
incompatibilidade das árvores com a infraestrutura urbana instalada, como, postes de iluminação, instalações
subterrâneas e caixas de inspeção e no manejo inadequado (SVMA, 2005).
Nas prefeituras e nos parques urbanos brasileiros, normalmente, há uma carência de mão de obra
especializada e logística necessárias para gestão da arborização. As informações sobre cada espécie de
árvore, incluindo seus defeitos, suscetibilidade aos agentes biológicos e longevidade não são armazenados e
analisados de maneira adequada e, consequentemente, perdidos. A coleta dos dados de campo é outra etapa
crítica, necessitando da implantação de processos automatizados, como aplicativos móveis, para o transporte
das informações para um sistema centralizado, responsável pelo armazenamento e gestão dos dados de
campo.
Portanto, este trabalho teve como objetivo desenvolver um sistema de gestão de árvores que englobe o
planejamento da arborização, o diagnóstico e a análise de risco de queda, de modo que este venha a se tornar
mais uma ferramenta de apoio à gestão do meio ambiente.

203
ISBN: 978-972-8939-96-0 © 2013 IADIS

2. MODELO DE GESTÃO DE ÁRVORES URBANAS

Como instrumento legal de gestão, toda cidade deve possuir um Plano Diretor de Arborização Urbana -
PDAU com o propósito de maximizar os serviços ambientais associados. O PDAU deve estabelecer as
diretrizes para o inventário, o diagnóstico e o planejamento da arborização. O inventário é o ponto
nevrálgico, pois se as informações coletadas não forem confiáveis e adequadamente armazenadas, não será
possível: i) a realização do diagnóstico qualitativo e quantitativo da arborização e definição dos indicadores
ambientais necessários para a gestão do município; e ii) o planejamento para melhoria do espaço urbano e,
consequentemente, da qualidade de vida. O PDAU ainda deve estabelecer programas importantes como:
plantio; manejo curativo e preventivo; treinamento e qualificação de mão de obra; gestão participativa e
educação ambiental.
Portanto, um Sistema de Gestão de Arborização Urbana deve permitir, de maneira confiável e
minimamente, o inventário, o planejamento e plantio das árvores. Um banco de dados da arborização ganha
maior importância, quando envolvemos outros personagens que atuam direta ou indiretamente sobre a
arborização urbana, como as concessionárias de energia elétrica, que realizam as podas nas árvores para
evitar a interrupção da energia elétrica, devido à queda de galhos ou árvores, as companhias de água e esgoto
e de telefonia, que interagem com a árvore na distribuição de seus serviços (galerias ou instalações
subterrâneas) ou o Ministério Público, no que tange à definição de responsabilidades sobre o manejo
inadequado (podas), acidentes com vítimas ou perda e bens materiais por queda de árvore na cidade.

3. EXPERIÊNCIAS ANTERIORES E TRABALHOS RELACIONADOS

O ARBIO (sistema proposto por este trabalho) foi especificado e projetado com base em experiências e
trabalhos anteriores dos autores (SISGAU, 2004) e o resultado final pode ser considerado uma evolução,
consolidação e amadurecimento de todos os outros.
Durante a pesquisa foram identificados alguns trabalhos que se assemelham ao proposto, tanto em âmbito
nacional como internacional. No entanto, nenhum dos trabalhos encontrados propõe uma ferramenta que
tenha por intuito uma gestão completa do ciclo de vida da arborização e, principalmente, a avaliação do risco
de queda das árvores.
O trabalho proposto por Fróes et al. (2007) apresenta uma abordagem nacional para um sistema de gestão
e manejo da arborização urbana, tendo como enfoque principal as redes elétricas de distribuição; a coleta dos
dados também é realizada por um dispositivo móvel.
O software i-Tree (2009) contempla uma sistema para a ampla gestão, espacialização e valoração da
arborização. No entanto, a utilização de ferramentas desenvolvidas em outros países acaba por ser
inadequada, uma vez que estas foram desenvolvidas com base em características e condições incompatíveis
com as aqui encontradas, dentre as quais pode-se citar: espécies de árvore distintas, diferentes espécies de
pragas e diferentes condições de entorno.

4. ARBIO
O software proposto trata-se de um sistema Web e Móvel, modular, baseado em uma abordagem de linha de
produto de software (LPS). Uma LPS compreende um conjunto de produtos destinados a um mercado
específico e que são desenvolvidos a partir da exploração de aspectos comuns e variáveis entre os produtos e
da utilização de artefatos reutilizáveis (Clements & Northrop, 2001).
O sistema dispõe de duas formas distintas para cadastramento das informações da arborização: por meio
de acesso ao sistema Web, via navegador, ou por dispositivos móveis, tais como smartphones e PDAs
(Personal Digital Assistant).
A escolha da disponibilização de um aplicativo para dispositivos móveis se deu em vista da necessidade
intrínseca do trabalho de inspeção da árvore em campo. De acordo com estudos publicados, a coleta de dados
com dispositivos móveis apresenta uma série de vantagens se comparada à coleta com papel, dentre as quais
se destacam a diminuição do tempo para coleta e o aumento da acurácia das informações (Lane et al, 2006),
(Galliher et al., 2008). A sincronização das informações coletadas em campo pode ser feita por meio de

204
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

conexão de dados ou por conexão do dispositivo móvel a um computador com acesso à rede na qual o
sistema encontra-se instalado.
O software é composto por três módulos diferentes: i) inventário, para cadastro das árvores; ii)
planejamento, para planejamento de plantio; e iii) registro de queda, para cadastro de queda de árvores. A
integração destes três módulos permite controle sobre todo o ciclo de vida de uma árvore, desde o plantio, até
a sua morte.

4.1 Arquitetura
A arquitetura foi definida com base no padrão de três camadas (Eckerson, 1995) e seus principais
componentes estão representados na Figura 1.

Figura 1. Arquitetura do software de gestão da arborização

A camada de interface do usuário, UI, é responsável pela exibição das informações solicitadas pelo
usuário e é construída de acordo com cada plataforma.
Por ser um software baseado em uma LPS, optou-se por realizar a separação das características comuns
(comunalidades) e características variáveis (variabilidade) em dois componentes distintos da camada de
lógica de negócio, denominados respectivamente Core e Variant. Desta forma, permite-se que
funcionalidades sejam adicionadas ou retiradas do software durante a configuração do produto.
A camada de acesso a dados, DAL, é a responsável por efetuar o controle sobre as operações de gravação
e recuperação de dados. O Banco de Dados (BD) do sistema Web compõe a base de dados central do sistema.
O Banco de Dados Móvel (BD Móvel) constitui-se de uma base transitiva, ou seja, mantida com o intuito de
que a coleta de dados possa ser realizada de forma desconectada da base de dados central.
Devido às diferenças existentes entre as plataformas nas quais o sistema é executado (Web e Móvel), para
cada um dos aplicativos foi necessária a criação de componentes específicos para cada camada (Core Web,
Core Mobile, DAL Web, DAL Mobile, etc.). A única exceção foi na camada Domain (que contém as
classes de negócio do domínio da aplicação), desenvolvida sob uma biblioteca portável, ou seja, que opera
igualmente em ambas as plataformas.
A sincronização das informações de campo, coletadas com o Sistema Móvel, com as informações
existentes na base de dados central é realizada pelo componente WCF. Este atua como intermediador para
resolver conflitos e garantir assim a total confiabilidade e integridade das informações.

205
ISBN: 978-972-8939-96-0 © 2013 IADIS

4.2 Inventário
O módulo de Inventário constitui o núcleo do ARBIO. Neste módulo são registradas as informações dos
espécimes inventariados e o histórico de todas as inspeções realizadas.
A partir do Inventário é possível efetuar o monitoramento das árvores cadastradas (principalmente em
relação ao risco de queda) e consultar informações de inspeções para a execução de ações de prevenção. A
Figura 2 ilustra a interface inicial deste módulo.

Figura 2. Interface inicial do módulo de inventário

Os dados coletados e registrados no Inventário foram definidos com base nos atributos de maior
relevância para gestão de árvores urbanas, conforme discutido na seção 2. Estes atributos foram agrupados

 Dados Principais: engloba o conjunto mínimo de informações para a identificação de uma árvore,
em:

 Condição de Entorno: dados do entorno da árvore, como informações sobre a via, calçada, canteiro e
como os dados da inspeção, localização do espécime, identificação botânica e vitalidade;

 Dendrometria: contém as características geométricas e medidas da árvore.

interferências;

 Estado Fitossanitário: engloba informações sobre os organismos presentes na árvore, como fungos,

 Avaliação Radicular: informações das raízes da árvore;

cupins, dentre outros;

 Avaliação Fuste: informações do fuste da árvore (região que compreende o colo e o tronco);
 Avaliação Copa: informações da copa da árvore;
 Ação Antrópica: informações de ações do homem sobre a árvore;
 Análise Interna: engloba o conjunto de dados provenientes da análise do interior da árvore;
 Análise de Risco: contém informações sobre o risco de queda da árvore, a partir de modelos

 Relatório de Risco: apresenta um sumário das características mais relevantes da árvore em se

matemáticos;

 Fotos;
tratando de risco de queda, e permite o registro da avaliação técnica deste risco;

 Recomendações: permite o registro de ações de tratamento e de manejo para a árvore e seus

eventuais problemas.
É importante destacar que, excetuando-se os atributos contidos nos dados principais, todo o restante do
cadastro é de caráter opcional, podendo o utilizador decidir quais os dados mais importantes para a sua
gestão. No entanto, vale ressaltar que, quanto mais informações forem registradas, maior será a qualidade da
gestão da arborização.

206
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Além do cadastro das árvores, o módulo de Inventário oferece uma ferramenta para cruzamento de
informações da base de dados, denominada Relatório de Pesquisa. Por meio desta ferramenta podem-se obter
dados sobre a situação da arborização, tais como: quantidade de árvores inventariadas, espécies
predominantes, árvores com problemas potenciais, problemas com maior recorrência e árvores com alto risco
de queda. Esta ferramenta enriquece a gestão, além de prover informações que auxiliam o planejamento da
arborização.

4.3 Planejamento
O módulo de Planejamento tem por objetivo o registro de oportunidades de plantio. A identificação de
espaços livres, passíveis de arborização, pode ser cadastrada no sistema.
Cada oportunidade é avaliada em termos de atributos e parâmetros de planejamento, e que, seguindo os
valores de referência definidos pela prefeitura ou parques, indicarão as espécies que apresentam o porte mais
adequado (pequeno, médio ou grande). Com base na avaliação é possível indicar quais espécies poderão ser
plantadas. Os atributos e parâmetros de planejamento são apresentados na Tabela 1.
Tabela 1. Atributos e parâmetros de planejamento.
Atributo Parâmetro
Largura mínima
Calçada ou canteiro central
Área do canteiro ou faixa permeável
Edificação
Parte aérea
Rede de energia
Caixa de inspeção e hidrante
Espécies arbóreas
Esquina ou confluência do alinhamento predial
Estai
Iluminação pública
Elemento de referência Guia rebaixada
Iluminação pública
Instalação subterrânea
Mobiliário urbano
Poste
Transformador
Além disso, durante o registro da oportunidade é possível anotar medidas e adequações necessárias que
deverão ser realizadas no local antes do plantio.
Outro recurso disponível é a execução do plantio da árvore, que possibilita ao utilizador indicar que uma
determinada oportunidade de plantio foi concretizada. Este recurso está completamente integrado ao módulo
de Inventário, de modo que, logo após a realização do plantio, as informações da nova árvore já estarão
incorporadas à base de dados central.

4.4 Registro de Queda

O módulo de Registro de Queda auxilia na coleta e armazenamento de dados das quedas das árvores. Tem
por finalidade: i) prover informações quantitativas e qualitativas sobre as razões e causas da queda de
árvores; e ii) fornecer dados históricos que possibilitem o refinamento da análise de risco de queda.
As informações cadastradas no módulo de Registro de Queda dizem respeito principalmente às condições
da árvore, condições climáticas, danos causados e provável causa que motivou a queda. São coletadas
informações sobre o estado das raízes, fuste e copa. Podem também ser anexadas fotos sobre o evento.
O conjunto de informações sobre quedas de árvores colaboram para a gestão da arborização a partir do
momento em que são utilizadas para identificar problemas recorrentes e para adotar medidas preventivas.

207
ISBN: 978-972-8939-96-0 © 2013 IADIS

5. CONCLUSÃO
Neste trabalho é apresentado o ARBIO, um Sistema para Gestão de Arborização Urbana. A partir da
aplicação da computação, empregando-se tecnologias para mobilidade, gestão, armazenamento e integração
de dados, mostrou-se possível o desenvolvimento de uma ferramenta que contribua para a gestão do meio
ambiente.
O Sistema de Gestão da Arborização Urbana proposto atende aos anseios de gestão dos municípios e de
parques, permitindo maximizar as funções ambientais e de qualidade de vida das pessoas em uma cidade,
conforme contextualizado na Constituição Federal de 1988 e regulamentado no Estatuto das Cidades, Lei
nº 10.267/2001.
Embora o trabalho represente mais um passo em direção ao aprimoramento da gestão da arborização,

 Visualização da arborização: atualmente as informações das árvores não podem ser exibidas em um
algumas melhorias e extensões do trabalho foram identificadas, como:

mapa ou por meio de recursos de espacialização. A implementação deste recurso visa facilitar a

 Módulo de valoração: estuda-se a adição de mais um módulo ao sistema, que permitirá quantificar o
coleta, cadastro e visualização das árvores.

 Módulo de relação com a rede elétrica: este módulo permitirá a coleta de informações da árvore com
valor monetário de um espécime.

relação à rede elétrica, permitindo melhor gestão pela prefeitura e respectiva concessionária de
energia elétrica.

REFERÊNCIAS
Brazolin, S., 2009. Biodeterioração anatomia do lenho e análise de risco de queda de árvores de tipuana, Tipuana tipu
(Benth.) O. Kuntze, nos passeios públicos da cidade de São Paulo, SP. Dissertação de Mestrado, Escola Superior de
Agricultura “Luiz de Queiroz” – USP, Piracicaba, Brasil.
Clements, P. e Northrop, L., 2001. Software Product Lines: Practices and Patterns. Addison-Wesley Professional,
Boston, EUA.
Eckerson, W., 1995. Three Tier Client/Server Architecture: Achieving Scalability, Performance, and Efficiency in Client
Server Applications. Open Information Systems 10.
Galliher, J. et al, 2008. Data collection outcomes comparing paper forms with PDA forms in an office-based patient
survey. Annals of Family Medicine, Vol. 6, No. 2, pp. 154-160.
Fróes, C. et al, 2007. Sistema de Gestão e Manejo da Arborização Urbana ao Longo das Redes de Distribuição. IV
Congresso de Inovação Tecnológica em Energia Elétrica, pp. 1-12.
Lane, S. et al, 2006. A review of randomized controlled trials comparing the effectiveness of hand held computers with
paper methods for data collection. BMC Medical Informatics and Decision Making, Vol. 6, No. 23, pp. 1-10.
Moreira, T., 2010. Interação da poluição atmosférica e a vegetação arbórea na cidade de São Paulo. Dissertação de
Mestrado, Escola Superior de Agricultura “Luiz de Queiroz” – USP, Piracicaba, Brasil.
Nowak D., Dwyer J. e Childs, G., 1998. Áreas verdes urbanas en Latinoamérica y el Caribe. Universidad Autónoma
Chapingo, Cidade do México, México.
Prefeitura Municipal de São Paulo, 2004. SISGAU – Sistema de Gerenciamento das Árvores Urbanas [Programa de
Computador].
Secretaria Municipal do Verde e do Meio Ambiente (SVMA), 2004. GEO cidade de São Paulo: panorama do meio
ambiente urbano. São Paulo, Brasil.
Secretaria Municipal do Verde e do Meio Ambiente (SVMA), 2005. Manual técnico de arborização urbana. São Paulo,
Brasil.
Silva, I., 2012. Efeitos do uso e cobertura do solo sobre o conforto higrotérmico. Dissertação de Mestrado, Escola
Superior de Agricultura “Luiz de Queiroz” – USP, Piracicaba, Brasil.
Schroeder, H., 1989. Environment, Behavior, and Design Research on Urban Forests. Advances in Environment,
Behavior and Design, Vol. 2, pp. 87-117.
United States Forest Service, 2009. i-Tree [Programa de Computador]

208
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

AVALIAÇÃO DE SISTEMAS DE BUSCA EXPLORATÓRIA:

UM ESTUDO DE CASO COM O MÉTODO
AVALIAÇÃO HEURÍSTICA

Dferson do Prado Pereira e Luciano Tadeu Esteves Pansanato

Universidade Tecnológica Federal do Paraná – UTFPR
Av. Alberto Carazzai, 1640, 86300-000 Cornélio Procópio, PR, Brazil

RESUMO
Os sistemas de busca exploratória são construídos sobre novas tecnologias e paradigmas de interface que facilitam o
aumento do nível de interação dos usuários com a informação e demandam desafios para a avaliação. Neste trabalho são
apresentados os resultados de um estudo exploratório do uso do método Avaliação Heurística para a avaliação das
funcionalidades para busca exploratória de um sistema para gerenciamento eletrônico de documentos. O estudo visa
identificar características do método que poderiam ser especializadas ou estendidas para apoiar a avaliação de sistemas de
busca exploratória. O estudo envolveu uma avaliação com a participação de oito avaliadores e um supervisor. A
possibilidade de extensão do método, a necessidade de suporte computacional e de heurísticas específicas para sistemas
de busca exploratória foram alguns dos resultados encontrados neste estudo de caso.

PALAVRAS-CHAVE
Busca, busca exploratória, interface de usuário, avaliação, avaliação heurística.

1. INTRODUÇÃO
Um dos interesses das áreas de Recuperação de Informação (RI) e de Interação Humano-Computador (IHC)
é projetar e avaliar tecnologia para o suporte a atividades mais exploratórias de busca (White et al., 2007;
Hendry, 2006; Belkin et al., 2004). Busca Exploratória (Exploratory Search) é definida como uma classe de
atividades mais complexas de busca em relação à abordagem tradicional de RI (Marchionini, 2006).
A abordagem tradicional de RI consiste em obter resultados precisos relacionados às consultas
especificadas. Marchionini (2006) classifica as atividades de busca exploratória em três tipos: busca (lookup),
aprendizagem e investigação. A busca exploratória está relacionada especialmente às atividades de
aprendizagem e investigação, mas a atividade de busca também pode ser empregada. Por exemplo, as
atividades de busca estão geralmente embutidas nas atividades de aprendizagem e investigação. As atividades
do tipo aprendizagem envolvem o processamento cognitivo e a interpretação de conhecimento novo; as do
tipo investigação requerem avaliação crítica antes da integração às bases de conhecimento.
O foco da pesquisa em Busca Exploratória tem sido no desenvolvimento de novos sistemas e interfaces
para apoiar as atividades de busca exploratória, ao invés da sua avaliação (White et al., 2008). Os sistemas de
busca exploratória são construídos sobre novas tecnologias e paradigmas de interface que facilitam o
aumento do nível de interação com a informação. Esse nível alto de interação, que é parte integral da busca
exploratória, demanda desafios para a avaliação.
Neste trabalho são apresentados os resultados de um estudo exploratório do uso do método Avaliação
Heurística para a avaliação das funcionalidades para busca exploratória de um sistema para gerenciamento
eletrônico de documentos. A Avaliação Heurística é o método de avaliação de usabilidade mais utilizado,
uma vez que é fácil de ser aplicado e o custo é baixo. No entanto, a avaliação e eficácia do método Avaliação
Heurística continua ainda a ser um objeto de pesquisa (Hollingsed e Novick, 2007). O estudo deste trabalho
visa identificar características do método que poderiam ser especializadas ou estendidas para apoiar a
avaliação de sistemas de busca exploratória.

209
ISBN: 978-972-8939-96-0 © 2013 IADIS

2. AVALIAÇÃO HEURÍSTICA
A Avaliação Heurística (Nielsen, 1994; Nielsen e Molich, 1990) é um método de inspeção para a avaliação
da usabilidade de sistemas interativos. O objetivo é identificar problemas de usabilidade que serão corrigidos
ao longo do processo de desenvolvimento do sistema. Esse método envolve a participação de um pequeno
grupo de avaliadores na análise da interação e julgamento dos elementos interativos da interface do sistema,
em relação a um conjunto de princípios ou heurísticas.
Para garantir a independência de opiniões e eliminar a influência de um avaliador na análise de outro
avaliador, cada membro do grupo de inspeção analisa a usabilidade do sistema separadamente,
inspecionando-o várias vezes, analisando todos os elementos interativos e comparando-os com as
recomendações, princípios e/ou heurísticas previamente definidas. Heurística é uma parte do conhecimento
capaz de sugerir ações plausíveis que devem ser seguidas ou ações implausíveis que devem ser evitadas
(Lenat, 1982). Assim, heurísticas são regras informais de julgamento que guiam as pessoas numa rápida
tomada de decisão. As heurísticas originais para o método em questão foram propostas por Nielsen e Molich
(1990), reformuladas e reunidas por Nielsen (1994) em dez heurísticas de usabilidade. No entanto, qualquer
outro conjunto de princípios ou heurísticas pode ser usado para a aplicação do método.
Durante uma avaliação com o método Avaliação Heurística, cada avaliador diagnostica problemas de
usabilidade que, em sua opinião, violam os princípios de usabilidade. Em seguida, esses problemas são
associados aos princípios teoricamente violados e apresentados em um relatório elaborado pelo próprio
avaliador. Ao final de todas as avaliações, os resultados individuais são congregados em um relatório final de
avaliação, composto por uma lista consolidada de problemas. Além disso, essa lista também pode ser
submetida aos avaliadores, para que estes classifiquem cada problema de acordo com níveis de severidade.
Essa classificação, além de fornecer uma boa visão da usabilidade geral do sistema, permite a identificação
dos problemas mais sérios, na opinião da maioria dos avaliadores, apontando aqueles que deveriam ser
corrigidos prioritariamente.

3. METODOLOGIA
A avaliação realizada foi organizada de acordo com as recomendações do padrão ISO/IEC 14598-5,
avaliação de produto de software (processo para avaliadores), que divide o processo de avaliação em quatro
estágios: especificação, planejamento, avaliação piloto e avaliação (ISO/IEC, 1998).
Na etapa de especificação, o escopo e o objetivo da avaliação foram definidos. O escopo da avaliação foi
a interface para busca exploratória do Gestor Eletrônico de Documentos e informações (GEDi) (Mussi et al.,
2009), um sistema para o gerenciamento eletrônico de documentos e das informações de contexto
relacionadas a estes documentos. O objetivo da avaliação, além de encontrar problemas de usabilidade no
projeto da interface do sistema GEDi, foi identificar as características do método Avaliação Heurística que
poderiam ser especializadas ou estendidas para apoiar a avaliação de sistemas de busca exploratória.
Na etapa de planejamento, um plano para a realização da avaliação foi elaborado com os procedimentos
relacionados ao método (Avaliação Heurística) que seriam executados e o formulário que seria utilizado
pelos avaliadores. As heurísticas utilizadas neste estudo foram as desenvolvidas originalmente para este
método, reformuladas e reunidas por Nielsen (1994) em dez heurísticas1 de usabilidade. Na avaliação foram
envolvidos oito avaliadores, todos são estudantes de graduação que concluíram a disciplina de Interação
Homem-Computador e têm experiência em desenvolvimento de software.
Na etapa de avaliação piloto, uma avaliação de teste foi realizada para identificar problemas com o
planejamento da avaliação (Preece et al., 2002). Durante a avaliação piloto, as seguintes questões foram
analisadas: (a) se os procedimentos da avaliação estavam descritos com clareza para a condução da
avaliação; e (b) se todas as informações necessárias seriam registradas corretamente no formulário. Ao final
da avaliação piloto, nenhum problema foi identificado.
Na etapa de avaliação, os avaliadores percorreram a interface pelo menos duas vezes, analisando todos os
elementos de interação, comparando-os com as heurísticas e anotando os problemas identificados no
formulário. Os formulários preenchidos pelos avaliadores foram compilados e consolidados em um

1
http://www.nngroup.com/articles/ten-usability-heuristics/.

210
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

documento único, que foi apresentado aos avaliadores em uma sessão de brainstorming para discutir os
principais problemas de usabilidade e as soluções possíveis. Além disso, os problemas de usabilidade foram
classificados em uma escala de quatro pontos com base no impacto sobre o usuário final.

4. RESULTADOS E CONCLUSÃO
Na Figura 1 são mostrados quais avaliadores encontraram determinados problemas de usabilidade. Cada
linha representa um dos oito avaliadores e cada coluna representa um dos vinte e três problemas de
usabilidade encontrados. Cada um dos quadrados pretos (intersecção de linha e coluna) indica a descoberta
de um dos problemas de usabilidade por um dos avaliadores. As colunas foram ordenadas de maneira que os
problemas de usabilidade que receberam o maior nível de impacto sobre o usuário final estão à direita e
aqueles que receberam o menor nível estão à esquerda. Os problemas de usabilidade encontrados não são
comentados porque o objetivo deste trabalho está centrado no método utilizado na avaliação.

Figura 1. Ilustração que mostra quais avaliadores encontraram determinados problemas de usabilidade.
O trabalho de consolidação exige tempo e muita atenção, pois cada avaliador relata à sua maneira os
problemas de usabilidade encontrados, assim como a sua localização na interface do sistema. A maior
dificuldade está na atividade de comparação dos diversos problemas para encontrar problemas igualmente
relatados ou parecidos em sua descrição e localização. Para realizar essa atividade, foi necessário analisar um
mesmo problema várias vezes. Outra dificuldade surgia quando as informações fornecidas pelo avaliador não
foram suficientes para reproduzir o problema; sempre que possível, o avaliador foi consultado sobre qual a
melhor decisão a ser tomada.
Um conflito ocorria quando níveis de impacto diferentes foram atribuídos a problemas considerados
idênticos. Nos casos em que os níveis de impacto possuíam valores diferentes, foi considerado o valor médio
entre eles e esse valor foi atribuído ao nível de impacto do problema. Nos casos em que possuíam valores
iguais, o valor com maior número de ocorrências foi atribuído ao nível de impacto do problema. Por
exemplo, se dois avaliadores atribuíram o valor 2 ao nível de impacto de um problema e outros três
avaliadores atribuíram o valor 3 para o mesmo problema, o valor 3 era atribuído ao nível de impacto do
problema em questão no relatório final consolidado.
A realização de uma avaliação usando o método Avaliação Heurística foi suficiente para a identificação
de algumas questões importantes ao considerar o emprego deste método para a avaliação de sistemas de
busca exploratória:
1. O método Avaliação Heurística poderia ser estendido para obter mais informações dos avaliadores
com relação ao sistema em avaliação e ao próprio método por meio da inclusão de outros
instrumentos de avaliação (por exemplo, um questionário no final do processo). Essas informações
(feedback) poderiam auxiliar, por exemplo, na preparação de testes com usuários finais. Além disso,
a inclusão de uma lista de tarefas que devem ser realizadas pelos avaliadores seria uma boa
estratégia para incentivá-los a percorrer toda a interface do sistema em avaliação.

211
ISBN: 978-972-8939-96-0 © 2013 IADIS

2. O trabalho de consolidar os formulários preenchidos pelos avaliadores em um documento único

poderia ser automatizado por meio de uma ferramenta computacional que utilize técnicas para
encontrar similaridades entre documentos (descrições dos problemas). Adicionalmente, a utilização
de um banco de casos associados às heurísticas utilizadas poderia auxiliar os avaliadores na
identificação das heurísticas violadas e na atribuição de valores aos níveis de impacto. Esse banco de
casos poderia ser consultado por problemas similares sempre que houvesse dúvida quanto às
heurísticas e/ou ao valor a ser atribuído. No entanto, essas abordagens são potencialmente
demoradas e dispendiosas (por exemplo, podem exigir alto poder de processamento).
3. Heurísticas específicas precisam ser elaboradas para avaliar sistemas de busca exploratória. Devido
às características próprias desses sistemas, o conjunto original de heurísticas é insuficiente.
Enquanto algumas delas ainda são aplicáveis, outras não são adequadas. Um novo conjunto de
heurísticas deve considerar as novas descobertas de pesquisas descritas na literatura e os produtos
existentes no mercado.
Alguns dos trabalhos futuros que podem dar continuidade ao estudo apresentado incluem o planejamento
e realização de uma avaliação com as considerações apresentadas anteriormente e a coleta e análise das
impressões dos avaliadores acerca do uso do método estendido com essas considerações (isto é, a avaliação
do próprio método de avaliação).

AGRADECIMENTOS
Os autores agradecem à UTFPR, Fundação Araucária, Secretaria de Estado da Ciência, Tecnologia e Ensino
Superior (SETI-PR) e Governo do Estado do Paraná pelo apoio financeiro.

REFERÊNCIAS
Belkin, N., Dumais, S., Scholtz, J., and Wilkinson, R., 2004. Evaluating interactive information retrieval systems:
Opportunities and challenges. Proc. of SIGCHI conference on Human factors in computing systems, pp. 1594-1595.
Hendry, D. G., 2006. Workspaces for search. In Journal of ASIST, 57, 6, pp. 800-802.
Hollingsed, T. and Novick, D. G., 2007. Usability inspection methods after 15 years of research and practice. Proc. 25th
Annual ACM International Conference on Design of Communication, pp. 249-255.
ISO/IEC, 1998. ISO/IEC 14598-5:1998 Information technology – Software product evaluation – Part 5: Process for
evaluators. Available at http://www.iso.org/.
Lenat, D. B., 1982. The nature of heuristics. In Artificial Intelligence, 19, 2, pp. 189-249.
Marchionini, G., 2006. Exploratory search: From finding to understanding. In CACM, 49, 4, pp. 41-46.
Mussi, L. P. S., Takemiya, S. H., Pansanato, L. T. E., Pozza, R. S., Yasui, P. H. Z., Della Mura, W. A., and Bastiani, J.
A., 2009. GEDi: Gestor Eletrônico de Documentos e informações. Anais do XVIII Workshop de Ferramentas e
Aplicações (WFA) – V Simpósio Brasileiro de Sistemas Multimídia e Web, Fortaleza, 2, pp. 124-126.
Nielsen, J. and Molich, R., 1990. Heuristic evaluation of user interfaces. Proc. of the SIGCHI conference on Human
factors in computing systems, pp. 249-256.
Nielsen, J., 1994. Heuristic evaluation. in Nielsen, J. and Mack, R. L. (Eds.). Usability Inspection Methods. John Wiley &
Sons, New York.
Preece, J., Rogers, Y., and Sharp, H., 2002. Interaction Design: Beyond Human-Computer Interaction. John Wiley &
Sons, New York.
White, R. W., Drucker, S. M., Marchionini, G., Hearst, M., and Schraefel, M. C., 2007. Exploratory search and HCI:
designing and evaluating interfaces to support exploratory search interaction. Proc. of the CHI Extended Abstracts,
pp. 2877-2880.
White, R. W., Marchionini, G., and Muresan, G., 2008. Evaluating exploratory search systems: Introduction to special
topic issue of information processing and management. In Information Processing and Management, 44, 2, pp. 433-
436.

212
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

DISEÑO Y DESARROLO DE UNA APLICACION

DISTRIBUIDA PARA LA ASIGNACION AUTOMATICA DE
HORARIOS DE CLASES

Juan Fajardo Barrero

Universidad de los Llanos

RESUMEN
Este documento describe el diseño y desarrollo de una solución de software para la planificación de horarios de una
institución educativa. La solución descrita fue implementada en la Universidad del Meta en Colombia, aquí se presentan
y explican los componentes utilizados para alcanzar un conjunto de resultados funcionales en el ambiente de producción
para el cual fue desarrollada la solución de software. La aplicación fue concebida como una solución distribuida en donde
los componentes permiten, la recolección de restricciones de manera descentralizada, la coordinación de dichas
restricciones para que la asignación automatizada pueda ser viable, los mecanismos de notificación para control de
restricciones y el diseño optimizado de los horarios finales.

PALABRAS CLAVE
Horarios, Planificación, Software Distribuido, Restricciones.

1. INTRODUCCION
Uno de los problemas que afrontan las instituciones educativas cuando inicia un nuevo periodo académico se
encuentra asociado a la distribución óptima de los horarios de clase, esta problemática reside principalmente
en la gran cantidad de variables que se ven involucradas en el proceso de la construcción del horario de cada
actividad. La distribución de horas para grupos, para profesores, el tamaño y los recursos de los salones, son
solo algunos de los elementos que complican el proceso de asignación inicial. El problema de horarios
educativos concierne a la planificación de un número de eventos o actividades (clases, laboratorios,
exámenes) en un conjunto de recursos limitados, como salones, franjas horarias, sujeto a un conjunto de
restricciones (Lewis & Paechter, 2007). En general estas restricciones pueden clasificarse en restricciones
suaves (soft constraint) y restricciones fuertes (hard constraint) (Burke & Petrovic 2002), una restricción
fuerte es de obligatorio cumplimiento, mientras que las restricciones suaves si bien son deseables, su
cumplimiento no es obligatorio, ejemplos de restricciones suaves son el tiempo máximo que un profesor
puede dictar clases de manera continua, o la cantidad de salones que deben quedar disponibles para
actividades extras. Restricciones fuertes son por ejemplo, que un mismo profesor no puede dictar clase a dos
grupos al mismo tiempo, o un mismo salón no puede ser ocupado por dos grupos de manera simultánea. Si
bien existen soluciones y diferentes aproximaciones a la asignación óptima de horarios de clase para
instituciones educativas, el principal problema de las soluciones existentes reside en que ante un conjunto de
restricciones complejas el software produce solamente horarios parciales o en algunos casos la asignación no
puede completarse. Este trabajo no hace un énfasis primario en la construcción del algoritmo de asignación
final, sino en el diseño de una solución que de manera distribuida permite recolectar las restricciones y
mediante un algoritmo desarrollado para tal fin, permite coordinar el conjunto de restricciones de modo que
su aplicación pueda garantizar un diseño optimizado de los horarios, en donde las restricciones fuertes se
satisfagan en su totalidad.

213
ISBN: 978-972-8939-96-0 © 2013 IADIS

2. DESCRIPCION DEL PROBLEMA

Existen diferentes aproximaciones a la solución del problema de planificación de horarios y distribución de
recursos que van desde complejos algoritmos experimentales hasta productos de software comercial que
permiten lograr asignaciones automáticas con buenos resultados. El problema principal de las soluciones
existentes radica en que ante un conjunto amplio de restricciones y un grupo limitado de recursos es posible
que la asignación automática resulte inviable, esto en términos de operación significa que el software o bien
establece unos horarios iniciales incompletos o bien no puede realizar ningún tipo de planificación al
encontrar restricciones imposibles de satisfacer.

3. ANTECEDENTES Y TRABAJOS PREVIOS

Existen diferentes aproximaciones al problema de planificación de horarios, el proceso de "timetabling" (De
Werra, 1985) ha recibido gran cantidad de contribuciones gracias a la capacidad de procesar información
sobre grandes conjuntos de restricciones, sin embargo por regla general las soluciones han sido diseñadas
para ambientes centralizados en donde solo un usuario se encarga de alimentar la aplicación con los recursos,
las restricciones y demás insumos necesarios para la construcción de los horarios, una vez hecho esto el
usuario ejecuta un proceso de asignación inicial y como resultado el software entrega un horario optimizado
o en su defecto genera un listado de posibles restricciones que hacen inviable la asignación inicial completa.
Las aproximaciones a resolver el problema que existen pueden ser clasificadas en cuatro categorías (Burke &
Petrovic 2002): Métodos Secuenciales, Métodos de agrupación, Métodos basados en restricciones y Métodos
Meta-heurísticos, en la tabla 1 se describen brevemente estos métodos y la afectación al método ante la
presencia de restricciones inviables:
Tabla 1. Métodos para resolución del problema de planificación de horarios.
Métodos Descripción Ejemplo Afectación
Secuenciales En estos métodos se utilizan heurísticas AsC Timetables es un software Los métodos secuenciales
para la asignación secuencial de las para planificación escolar se detienen ante la
actividades y ante la presencia de orientado para su aplicación en presencia de restricciones
restricciones no cumplidas las asignaciones escuelas primarias y secundarias inviables, generalmente ni
se cambian. La mayoría del software con un generador automático de siquiera es posible obtener
existente utiliza métodos secuenciales. horarios único (Mockus & una planificación parcial.
Pupeikiene,2012).
Agrupación En estos métodos las actividades se TimeFinder es un software libre Ante un conjunto de
agrupan y posteriormente se asignan que automatiza la planificación de restricciones inviable solo
tratando de cumplir con las restricciones. horarios para instituciones cierta parte de las
educativas (Hanover Research actividades se asigna.
Council, 2009).
Basado en Las restricciones se definen como un Por ejemplo Arbennadher, S. & Los sistemas basados en
restricciones conjunto de reglas cuyo cumplimiento trata Marte, M., (2000) describe el uso restricciones se detienen
de establecerse mediante técnicas de de reglas tipo predicados para la ante la presencia de
resolución como por ejemplo backtracking construcción del horario sin condiciones que no se
(Arbennadher, S. & Marte, M., 2000). conflictos de restricciones. pueden cumplir.
Meta-HeurísticosExisten diversos métodos en donde se Rawat, S. & Rahamani, L., (2010) El uso por ejemplo de
emplean técnicas de inteligencia artificial o define un algoritmo genético en el algoritmos genéticos limita
sistemas híbridos que mezclan algoritmos que las asignaciones son tratadas la solución final a un
heurísticos con algoritmos genéticos u como individuos que evolucionan estado intermedio ante la
otras técnicas innovadoras. hacia una asignación de presencia de restricciones
actividades cumpliendo parcial o inviables.
totalmente con las restricciones.

4. DISEÑO DE LA APLICACIÓN
La solución propuesta busca atacar el problema de las restricciones fuertes inviables, que afectan cualquier
método que se seleccione para realizar la asignación inicial de los horarios. Todos los componentes de la

214
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

aplicación están orientados hacia la recolección de las restricciones de manera distribuida y la coordinación
efectiva para que dichas restricciones puedan satisfacerse en el componente que realiza la asignación inicial.
En principio la aplicación se construye sobre la base de que la recolección de las restricciones debe realizarse
y depurarse de manera distribuida, entendiendo que el principal insumo para lograr una generación efectiva
de los horarios es el conjunto de dichas restricciones. Las restricciones son específicas para cada curso en
cada programa y el proveedor natural de dicha información es el director de programa. A fin de alcanzar el
objetivo de recolectar y depurar las restricciones se propone el uso de un algoritmo que sea capaz de
identificar las restricciones inviables y evitar que en el proceso de recolección sean incluidas en el conjunto
final. Este algoritmo y su operación suponen el uso de un mecanismo de comunicación y un efecto asíncrono
en la toma de datos que permita reducir las condiciones causantes de asignaciones pobres o incompletas en el
proceso de asignación. Estas restricciones que son proporcionadas a la aplicación pueden ser de dos tipos
como se describe en la tabla 2.
Tabla 2. Tipos de restricciones y su funcionalidad dentro de la aplicación para asignación automática de horarios.
Tipo de Restricción Funcionalidad Ejemplos
Restricciones de Tiempo Evitar cruces de horarios, horarios que resulten - Un profesor solo puede dictar clases en la tarde.
excesivos para alumnos o profesores, permitir a - Un conjunto de alumnos que no pueden asistir a clase
ciertos profesores tener rangos de horario en la mañana.
preestablecidos.
Disponer de salones con capacidad específica, - Una asignatura que requiere laboratorio de química.
Restricciones de recurso disponer de recursos especiales como elementos - Un grupo de estudiantes que requiere de una sala de
de laboratorio o salas de cómputo. conferencias.

La aplicación distribuida se compone de cinco elementos para su funcionamiento: Una base de datos
donde estas restricciones son almacenadas, una interfaz de usuario para recolección de restricciones, un
generador de horarios automático, una interfaz que permite el intercambio de la información entre la base de
datos y el generador de horarios y finalmente con el fin de garantizar la efectividad del generador de horarios
el componente distribuido es un Webservice (Leymann, 2002), el cual permite que las restricciones puedan
coordinarse durante su ingreso al sistema. A continuación se describen brevemente dichos componentes.

4.1 Componentes de la Solución

 Base de datos: Un motor de bases de datos relacional cliente servidor. Para la implementación aquí


descrita se utiliza PostgresSQL (Stonebraker 1990).
Interfaz de usuario: Este componente es desarrollado utilizando PHP (Personal Home Page), PHP es un
lenguaje de programación de propósito general utilizado principalmente en la construcción de
aplicaciones Web (Lerdorf 2002). El objetivo primario de esta interfaz es permitir a los directores de


programa alimentar fácilmente las restricciones de tiempo y recursos de cada asignatura o curso.
Gestor de Horarios automático: FET es un software libre para la planificación automática de horarios
en instituciones educativas (Mansor, Arbain and Hassam 2013). Utiliza un método secuencial que resulta
eficiente cuando las restricciones han sido correctamente depuradas y el formato para definición de las


restricciones es XML, lo cual facilita la interacción con los otros componentes.
Interfaz de Intercambio: La función de este componente es la de permitir a partir de la información
contenida en la base de datos construir las restricciones que serán procesadas por el gestor (FET), en la
implementación gracias al formato XML de FET. Esta operación es realizada por un módulo


desarrollado usando el lenguaje de programación PHP.
Webservice: El Webservice es un componente virtual que puede ser accedido a través de diferentes
formatos y protocolos (Leymann, 2002), el objetivo del componente es garantizar que en el momento del
ingreso de restricciones que provienen de diferentes fuentes, el algoritmo de verificación evite la
inviabilidad del conjunto de restricciones. La figura 1 muestra la arquitectura de la aplicación propuesta.

215
ISBN: 978-972-8939-96-0 © 2013 IADIS

Figura 1. Arquitectura de la aplicación

5. DESARROLLO DE LA SOLUCIÓN
La interfaz Web permite recolectar las restricciones de manera concurrente, la recolección se realiza con la
expectativa de que las restricciones consolidadas podrán transformarse en el formato XML requerido por
FET para la asignación del horario, sin embargo el principal problema de este esquema radica en que muchos
de los recursos son compartidos entre los usuarios de la aplicación, idealmente las franjas horarias para un
recurso podrán ser asignadas si el conjunto de restricciones asociadas al uso de dicho recurso no entran en
conflicto, incluso si han sido establecidas por usuarios diferentes. La solución propuesta busca detectar estos
conflictos durante el proceso de recolección de requerimientos haciendo uso de un algoritmo y un mecanismo
de comunicación (protocolo o servicio), en este caso el Webservice.
La inviabilidad de un conjunto de restricciones consiste en la imposibilidad de asignar un conjunto de t+ 1
actividades que requieren una franja de tiempo dentro de un conjunto de t franjas de tiempo (Brucker, 2004).
El algoritmo para detección temprana de las restricciones inviables consiste en detectar los rectángulos no
superpuestos (Marte, 2002), mediante un algoritmo de procesamiento de matrices los conjuntos de
restricciones son evaluadas recurso a recurso (profesor, salón, franja horaria), cada conjunto de restricciones
es ubicado dentro de los bloques de franjas horarias y luego se sobreponen para identificar la franja horaria
conjunta. En la figura 2 se describe gráficamente el accionar del algoritmo para la detección de restricciones
inviables.

Figura 2. Ejemplo de una restricción que hace inviable la asignación del horario
En el caso de la figura una actividad para un profesor es restringida en un programa X para que sus franjas
horarias se limiten a Lunes 7-9 y miércoles de 7-9, la actividad programada requiere 4 franjas horarias, es
decir que la restricción individual puede satisfacerse, en el otro caso en el programa Y las restricciones de
franja se limitan a lunes de 7-9 y viernes de 7-9, esta restricción también puede satisfacerse, sin embargo en
la restricción conjunta las franjas horarias se limitan a 6, debido a los rectángulos no superpuestos (Marte,
2002), que en la asignación final hacen imposible la programación de los horarios con las restricciones
existentes. En este caso ante la detección de las restricciones inviables el algoritmo genera un mensaje que es
enviado de manera asíncrona a la interfaz Web utilizando un Webservice y dicha interfaz evita que la
restricción conflictiva sea registrada, en este caso el segundo usuario tendrá que tomar los correctivos
necesarios.

216
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

6. RESULTADOS
En la primera implementación del sistema de asignación automática de horarios para el periodo académico 2
de 2013 en la Universidad del Meta el diseño de la aplicación distribuida permitió depurar en tiempo real el
conjunto de restricciones recolectadas, al final de la implementación entre un total de 1859 actividades, se
programaron automáticamente 1710. Las actividades que no se pudieron programar de manera automática
corresponden a clases con requerimientos de salones especiales para los cuales existe una demanda excesiva
y en este caso la universidad no cuenta con salones suficientes para satisfacer dicha demanda. En
experimentos previos utilizando la misma arquitectura y los mismos algoritmos pero sin la identificación
temprana de restricciones inviables, el proceso de asignación de horarios solo alcanzo cerca de un 15% del
total de las actividades a programar, lo cual redundaba en resultados inutilizables para la institución.

7. CONCLUSIONES Y RECOMENDACIONES
Si bien existen gran variedad de algoritmos, implementaciones y productos de software que permiten resolver
de manera efectiva los problemas relacionados con la asignación de horarios en instituciones educativas,
todas estas soluciones dependen de la calidad del conjunto de restricciones en cuanto a su construcción, la
aproximación abordada en este documento permite filtrar de manera efectiva el conjunto de restricciones que
se han de proveer a la herramienta que se encarga de realizar la asignación de horarios, garantizando que el
resultado final pueda ser utilizado en producción. El empleo de protocolos o mecanismos como los
Webservice y las aplicaciones Web, permite obtener una solución distribuida en la que la recolección de las
restricciones sea efectiva y a la vez dicha recolección permita controlar las restricciones eliminando aquellas
que puedan hacer inviable la planificación adecuada y automatizada de los horarios.

REFERENCIAS
Lewis, R. & Paechter, B., 2007. ‘Finding Feasible Timetables Using Group-Based Operators’. IEEE Transactions on
Evolutionary Computation, Vol. 11 No. 3, pp 397-413.
Burke, E.K. & Petrovic, S., 2002. ‘Recent Research Directions in Automated timetabling’, European Journal of
Operations Research-EJOR, Vol. 140, pp 266-280.
Mockus, J. & Pupeikiene L., 2012. ‘On Multi-Start Algorithms for Optimization of High School Timetables’,
INFORMATICA, Vilnius University, Vol. 23 No. 3, pp 405-425.
Hanover Research Council, 2009. ‘Best Practices For Timetabling and Space Allocation Policies in Universities’,
Washington DC: HRC.
De Werra, D., 1985. ‘An Introduction to Timetabling’. European Journal of Operational m Research, Vol. 19, pp. 151-
162.
Arbennadher, S. & Marte, M., 2000. ‘University Course Timetabling Using Constraint Handling Rules’, Applied
Artificial Intelligence: An International Journal, Vol. 14, Issue 4, pp 311-325.
Rawat, S. & Rahamani, L., 2010. ‘A Timetable Prediction for Technical Educational System Using Genetic Algorithm’,
Journal of Theoretical & Applied Information Technology, Vol. 13, Issue 1-2, pp 59-64.
Brucker, P., 2004. Scheduling Algorithms, Springer, Osnabrück, Germany.
Marte, M., 2002. Models and Algorithms for School Timetabling: A Constraint-Programming Approach, Institute of
Computer Science, LMU, Munich, Germany.
Mansor, Z., Arbain, J. and Hassan, M., 2013. ‘Implementation of FET Application in Generating a University Course and
Examination Timetabling’. In: ICIBA2013, the Second International Conference on Information Technology and
Business Application. Palembang, Indonesia, 22-23 February 2013.
Leymann, F., 2002. ‘Web Services: Distributed Applications without Limits –An Outline-’, In: Proceedings of Database
Systems for Business and the Web BTW 2003. Leipzig, Germany, 26-28 February, 2003.
StoneBraker, M., 1990. ‘The implementation of POSTGRES’. IEEE Transactions on Knowledge and Data Engineering,
Vol. 2, Issue 1, pp 125-142.
Lerdorf, R., Tatroe, K., Kaehms, B. and McGredy, R, 2002. Programming PHP, O’Reilly, USA.

217
ISBN: 978-972-8939-96-0 © 2013 IADIS

DETECÇÃO AUTOMÁTICA DE CÉLULAS SANGUÍNEAS

Jaqueline Cristina Sgarbi e Patricia Bellin Ribeiro

Universidade Sagrado Coração - USC

RESUMO
Existem muitas áreas nas quais o processamento de imagem digital é usado tanto em uma melhoria de imagem,
modificação e outros. Neste trabalho será apresentado como o uso de técnicas de processamento de imagem digital com
Otsu, dilatação, Fill-holes, erosão e Watershed podem ser utilizados como um auxílio na área da medicina com um
software capaz de realizar a detecção de células. Este software utiliza várias técnicas de processamento de imagem
digital, a fim de realizar a detecção de células em uma imagem para auxiliar o especialista.

PALAVRAS-CHAVE
Detecção de células, processamento de imagem digital.

1. INTRODUÇÃO
As células sanguíneas são descendentes de uma célula-mãe única, denominada célula pluripotente,
totipotente, steam-cell ou célula-tronco. Aproximadamente 25% das células desenvolvidas são eritrócitos,
enquanto 75% são destinadas a se tornarem leucócitos (SILVERTHORN, 2010). Em um único dia a medula
óssea pode dar origem a cerca de seis bilhões de células.
A importância da contagem das células do sangue consiste em uma indicação primária da saúde. Essas
células podem ser avaliadas quantitativamente por método visual ou manual, ou por métodos automáticos. A
variação da quantidade destas células avalia o estado geral da saúde da pessoa, bem como auxilia a
diagnosticar diversas doenças (JOHNSON, 2003).
Para que seja possível contar as células sanguíneas há a necessidade de detecta-las. Para isso foram
estudadas técnicas de processamento de imagens, que na área médica é encontrado em diversas aplicações
(RIBEIRO et. al, 2013). Por isso neste trabalho temos como objetivo propor um sistema, como alternativa
para a detecção automática de células sanguíneas, para que seja possível, em trabalhos futuros, a contagem
destas células.

2. CONTAGEM DE CÉLULAS SANGUINEAS

As células podem ser avaliadas quantitativamente por método visual ou manual, ou por métodos automáticos.
Neste tópico esses dois métodos são descritos, e são também apresentados alguns equipamentos comerciais
que realizam essas contagens.

2.1 Método Visual ou Manual

Com a finalidade de determinar o número de elementos morfológicos o método de contagem visual ou
manual, baseia-se em diluir um volume conhecido de sangue com uma determinada quantidade de líquido
diluidor, contando-se os glóbulos na área reticulada da câmara, obtém-se o seu número por milímetro cúbico.
Os tipos de câmara (Neubauer, Levy, Spencer e outros) universalmente consistem em lâmina espessa de
vidro, de forma retangular, atravessada transversalmente por dois sulcos, que delimitam três plataformas
(JOHNSON, 2003). Ao calcular o número de células para um hemograma, várias coisas devem ser levadas
em consideração: Unidades de referência; a diluição da amostra de sangue e o volume contado (JOHNSON,
2003).

218
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

2.1.1 Método Automatizado

A contagem eletrônica das células sanguíneas começou em 1950, utilizando um dispositivo capaz de contar e
medir os pulsos de condutividade (impedância) causados pela passagem de partículas através de um orifício
pelo qual flui uma corrente elétrica. Nos anos 1960 e começo dos anos 1970, os instrumentos primitivos
evoluíram, de forma a tornarem os contadores eletrônicos por impedância aperfeiçoados na mecânica, na
eletrônica e, principalmente, no software do computador de apoio. São fabricados e muito utilizados até hoje,
com a designação usual de contadores eletrônicos de pequeno porte (FAILACE, 2009). No fim dos anos
1970, a tecnologia de impedância foi acrescida de citometria de fluxo (técnica para contagem e análise de
partículas microscópicas em meio líquido em fluxo), com inúmeras perspectivas e variantes para
identificação celular, dando origem aos atuais contadores eletrônicos de grande porte (FAILACE, 2009). De
lá pra cá, os instrumentos e o método de contagem continuaram obtendo mudanças, que tornam alguns
equipamentos caros e inviáveis em muitas situações.
2.1.2 Contadores de Impedância
A era moderna da contagem automatizada das células sanguíneas começou nas décadas de 40 e 50, com o
princípio da contagem por impedância. Esse princípio consiste de que as células são contadas e medidas a
partir dos impulsos elétricos que geram. Isso ocorre por serem más condutoras de eletricidade; então quando
passam por uma pequena abertura pela qual circula uma corrente elétrica, há um aumento na impedância
elétrica na abertura à medida que cada célula passa; esse aumento é proporcional ao volume deslocado do
material condutor, sendo, portanto, proporcional ao volume celular. As células que passam ao mesmo tempo,
ou quase ao mesmo tempo, pela abertura, são contadas e medidas como uma única célula; o que causa uma
exatidão que precisa ser corrigida (correção de coincidência). Os contadores de impedância determinam o
volume celular e do conteúdo e concentração de hemoglobina de forma precisa. Porém, existem algumas
inexatidões referentes ao método, que aumentam quando as células são anormais (FAILACE, 2009).
2.1.2.1 Instrumentos de Dispersão da Luz ou Dispersão da Luz/Impedância
Uma célula ao passar por um feixe de luz, dispersa-se. O grau dessa dispersão está relacionado ao tamanho
da célula, o que permite sua contagem e medida. O feixe luminoso pode ser de luz branca ou um laser
coerente de alta intensidade, o qual apresenta melhor qualidade óptica. Colocando-se um detector na linha do
feixe luminoso também se pode medir a absorvância da luz. O detector da luz pode ser um fotomultiplicador
ou um fotodiodo, que converte a luz em impulsos elétricos que podem ser acumulados e contados. A
tecnologia dos instrumentos da série H.1 parece produzir determinações exatas de VCM, Hct e CHCM. Esses
instrumentos conseguiram corrigir a inexatidão dos primeiros instrumentos de dispersão de luz e também as
inerentes aos contadores por impedância. Porém, não são medidas com exatidão as células que não podem ser
convertidas em esferas isovolumétricas (FAILACE, 2009).

3. MATERIAIS E MÉTODOS
Neste item, destaca-se o método para detecção de células proposto, que utiliza técnicas de processamento
digital de imagens. Adotou-se a ampliação de 40x para as imagens, por apresentar as células em tamanho
adequado ao reconhecimento automático. O método está dividido em: aquisição e pré-processamento. Para o
desenvolvimento do software estaremos utilizando a biblioteca ImageJ, desenvolvida em Java para análise e
processamento de imagem, este software é de domínio público.

3.1 Aquisição
A aquisição das imagens foi feita através do sistema AxioVision 4.8 e de um microscópio acoplado a uma
câmera (AxioCam HRc). Esse material é desenvolvido na Alemanha, pela Carl Zeiss. O microscópio é
conectado a um microcomputador PC através da interface USB e o software que é compatível com o
Windows, executa as funções de aquisição e processamento de imagens, além de permitir ao usuário a
inserção de dados relacionados ao exame, em formato texto, no mesmo arquivo que contém a imagem.

219
ISBN: 978-972-8939-96-0 © 2013 IADIS

A aquisição foi feita a partir de uma lâmina com amostra de sangue humano, utilizando o microscópio
Axioskop, de uso acadêmico, com iluminação polarizada. Para a aquisição das imagens, foi utilizada uma
lente de aumento de 40 vezes, para posterior análise, e ou contagem de células. O deslocamento da lâmina no
plano cartesiano deste microscópio é mecânico e é acionado manualmente.
Todas as imagens foram submetidas às mesmas condições de aquisição, de forma a possuírem as mesmas
características. Foram mantidos fixos o foco e a distribuição de iluminação. O sistema de cores adotado foi o
RGB. A resolução escolhida foi de 4128x3108 pixels. O formato de saída utilizado foi o JPEG.

3.2 Pré-processamento
Neste tópico serão apresentadas as principais funções de processamento de imagens utilizadas no programa
proposto antes da etapa final de contagem. Desta forma, a imagem é tratada de acordo com as necessidades
do sistema, para que o algoritmo de contagem possa ter um melhor desempenho em sua utilização.
3.2.1 Transformação: RGB para Escala De Cinza
Uma imagem colorida representada pelo modelo RGB pode ser vista como três imagens de intensidade
monocromática (representando vermelho, verde e azul (cores primárias)). Essas três imagens se combinam na
tela para produzir uma imagem de cores compostas em um monitor RGB (GONZALEZ, 2010). Para este
trabalho, a intensidade (nível de cinza) será extraída de uma imagem RGB, de forma a transformá-la em
apenas uma imagem monocromática. Para isso, a imagem será transformada para o modelo HSI (hue,
saturation, intensity – matiz, saturação, intensidade), porém, apenas o componente de intensidade será obtido.
O modelo HSI, separa o componente “intensidade” das informações de cores (matiz e saturação) em uma
imagem colorida.
3.2.2 Limiarização Global Ótima usando o Método de Otsu
O princípio da limiarização consiste em separar as regiões de uma imagem (o fundo e o objeto), produzindo
uma imagem binária à saída. A forma mais simples de limiarização consiste na bipartição do histograma,
convertendo os pixels cujo tom de cinza é maior ou igual a certo valor de limiar (threshold) em brancos e os
demais em pretos. Matematicamente, a operação de limiarização é dada pela Equação 1, onde os pixels com
o valor 1 correspondem aos objetos, e os pixels com o valor 0 correspondem ao fundo (background) e T
(threshold) é um valor de tom de cinza pré-definido, ao qual denominamos limiar (MARQUES FILHO,
1999).
g(x, y) = 1 se f (x, y) ≥ T (1)
= 0 se f (x, y) < T
O método de Otsu é uma alternativa atraente, pois é ótimo no sentido de maximizar a variância entre
classes. Ele se baseia inteiramente em cálculos realizados no histograma de uma imagem. A ideia básica é
que um limiar que oferece a melhor separação entre as classes em termos de valores de intensidade seria o
melhor limiar (limiar ótimo). Após o cálculo do histograma da imagem de entrada, seus componentes são
designados, e são feitos vários cálculos antes de ser encontrado de forma automática o valor para o limiar
ótimo: devem-se calcular as somas; calcular as médias acumuladas; calcular a intensidade média global e
calcular a variância entre classes (GONZALEZ, 2010). Após esses cálculos o limiar ótimo é encontrado e a
imagem é segmentada através da Equação 1, como na limiarização simples (GONZALEZ, 2010).
3.2.3 Dilatação
“O processo de dilatação consiste em obter a reflexão de b sobre sua origem e depois deslocar esta reflexão
de x. A dilatação de A por B é, então, o conjunto de todos os x deslocamentos para os quais a interseção de B
e A inclui pelo menos um elemento diferente de zero.” (MARQUEZ FILHO, 1999, p. 140).
Para Gonzalez (2010), no entanto, a dilatação de uma imagem por um elemento estruturante em qualquer
posição (x, y) é definida como o valor máximo da imagem na região indicada pelo elemento estruturante
quando a origem dele está em (x, y). Desta forma, para calcular a erosão de A por B, a origem do elemento
estruturante é colocada em todas as posições dos pixels da imagem, calculando-se a dilatação em qualquer
posição através da seleção do valor máximo de todos os valores de A, contidos na região que coincide com B
(GONZALEZ, 2010).

220
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

3.2.4 Preenchimento de Buracos (Fill Holes)

Um buraco pode ser definido como uma região de fundo rodeada por um contorno de pixels de frente
conectados. Para o preenchimento de buracos de uma imagem, será utilizado um algoritmo baseado em
dilatação, complemento e interseção de conjuntos. Seja um contorno A, que pode ser expresso como um
conjunto cujos elementos são pontos do contorno 8-conectados, cada um deles englobando um buraco (região
de fundo), o objetivo do algoritmo é preencher todos os buracos com 1s através da dilatação condicional
(GONZALEZ, 2010).
3.2.5 Erosão
A erosão de uma imagem A por um elemento estruturante plano B em qualquer posição (x, y) é definida
como o valor mínimo da imagem na região coincidente com B quando a origem de B está em (x, y). Para
calcular a erosão de A por B, colocamos a origem do elemento estruturante em todas as posições dos pixels
da imagem. A erosão em qualquer posição é determinada selecionando o valor mínimo de todos os valores de
Os contidos na região que coincide com B (GONZALEZ, 2010).
3.2.6 Segmentação de Imagens - Método Watershed
A segmentação tem como objetivo dividir uma imagem em suas unidades significativas, ou seja, nos objetos
de interesse que a compõem (MARQUES FILHO, 1999). No caso da segmentação por watershed, a imagem
será dividida em várias regiões, o que irá distinguir seus elementos existentes.
Para facilitar o entendimento do algoritmo de segmentação por divisor de águas, a imagem a ser
segmentada pode ser interpretada como uma superfície topográfica, composta por vales e picos, em que a
distância dos pixels ao plano de fundo (intensidades dos pixels), corresponde a valores de altitude ou
elevação dos pontos, como se os valores de intensidade fossem valores de curvas de nível em um mapa
topográfico. Para realizar a segmentação, um processo simula a inundação de toda a superfície. As águas
descem pelos montes e se encontram nos vales entre duas ou mais montanhas. Esse método busca selecionar
justamente o contorno que a água faz envolta destes vales. Pela simulação, o contorno representa as linhas
desenhadas pelas águas vistas de cima da superfície (GONZALEZ, 2010; MARQUES FILHO, 1999).

4. RESULTADOS
Para os testes iniciais foi adquirido um conjunto de 11 imagens adotando-se a ampliação de 40x as imagens,
por apresentar as células em tamanho adequado ao reconhecimento automático, conforme exemplo
apresentado na Figura 1 (a). A informação de cor não seria relevante para a contagem de células neste
trabalho, por isso, optou-se por converter as imagens para escala de cinza. Desta forma, o tempo de
processamento que levaria para processar os três canais de cor (RGB), Figura 1 (a) será reduzido para 1/3,
pois a imagem passará a ter apenas um canal, sendo convertida para escala de cinza em uma imagem de 8
bits, a Figura 1 (b) mostra o resultado obtido através desse processo. A após a conversão das imagens para
escala de cinza, Figura 1 (b) ela será cinza limiarizada através do método Otsu, conforme resultado obtido na
Figura 1 (c), proporcionando assim destacar as células na cor preta e deixar o fundo da imagem (background)
na cor branca. Porém após a limiarização através do método Otsu, foi verificado em Figura 1 (c) que o centro
das células estava na cor branca, para isso, foi necessário aplicar a técnica dilatação conforme resultado
obtido na Figura 1 (d) para que fosse possível reduzir a quantidade de informações na cor branca dentro da
célula, porém, mesmo utilizando a dilatação não foi possível conseguir reduzir a informação em branco no
centro de várias células. Para que fosse possível eliminar todas as informações em branco do centro da célula
foi aplicado após a dilatação a técnica Fill –holes, que tem como objetivo o preenchimento do centro das
células com a cor preta igual a borda das células conforme resultado que pode ser visualizado na Figura 1(f).

221
ISBN: 978-972-8939-96-0 © 2013 IADIS

a) b) c)

d) e) f)
Figura 1. Processamento das Imagens com células sanguíneas.
(a) imagem RGB, (b) imagem em escala de cinza, (c) limiarizada através do método Otsu, (d) Dilatação, (e) Fill-holes e
(f) Erosão
Mesmo após todas as etapas de processamento algumas células se mantinham unidas, com isso,
dificultando uma possível contagem das células corretamente, por isso, para melhorar a detecção dessas
células foi utilizada a Transformada de Watershed para que fosse possível separar as células com uma linha
em branco conforme exemplo na Figura 2. O software de contagem irá tratar os ruídos ou pequenos círculos.

Figura 2. Imagem após aplicar a erosão (a) e em (b) após aplicar Watershed para separar as células.

5. CONCLUSÃO
Com as técnicas utilizadas foi possível realizar a detecção de células de diversos tipos de imagens,
viabilizando assim uma futura contagem correta das células sanguíneas de cada imagem. Este software
poderá auxiliar diversos profissionais da área de biomedicina com a contagem de células, ajudando no
processo de contagem, facilitando seu trabalho e reduzindo as margens de erro humano. É importante
ressaltar que apesar do software poder auxiliar no trabalho desses profissionais ele não os substitui.

REFERÊNCIAS
Silverthorn, Dee Unglaub.(2010) Fisiologia Humana: uma abordagem integrada. 5. Ed.. Porto Alegre: Artmed.
Johnson, Catherine W.; Timmons, Daniel L.; Hall, Pamela E.(2003) Essential Laboratory Mathematics: Concepts and
Applications for the Chemical and Clinical Laboratory Technician. 2. Ed.. Cengage Learning.
Ribeiro, P. B., Romero, R.A F., Oliveira, P.B, Schiabel, H., Verçosa, L.B. (2013) Automatic Segmentation of Breast
Masses using Enhanced ICA Mixture Model. Neurocomputing. DOI: 10.1016/j.neucom.2012.08.062.
Failace, R.; Fernandes, F. B.; Failace, R. (2009) Hemograma: manual de interpretação. 5. Ed.. Porto Alegre: Artmed.
Gonzalez, Rafael C. (2010) Processamento Digital de Imagens. 3. Ed., São Paulo: Pearson Prentice Hall.
Marques Filho, Ogê; Vieira Neto, Hugo (1999) Processamento Digital de Imagens, Rio de Janeiro: Brasport.

222
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

O TEOREMA DE PROBABILIDADE PELO ALGORITMO

NAIVE BAYES PARA A CLASSIFICAÇÃO DE DADOS:
UM ESTUDO EM FERRAMENTAS DE DATA MINING

Marcio Novaski1, Merisandra C. de Mattos Garcia1,2, Maicon Bastos Palhano1, Gabriel Felippe1,
Ruano Marques Pereira1 e Fernando Mendes de Azevedo2
1
Curso de Ciência da Computação, Universidade do Extremo Sul Catarinense, Criciúma –SC- Brasil
2
Instituto de Engenharia Biomédica, Departamento de Engenharia Elétrica, Universidade Federal de Santa Catarina
Florianópolis-SC- Brasil

RESUMO
Os constantes avanços tecnológicos têm permitido que as mais diversas organizações gerem repositórios de dados cada
vez maiores tornando necessário o desenvolvimento de tecnologias que auxiliem nas análises e obtenção de
conhecimento a partir destes dados. O data mining destaca-se dentre essas tecnologias utilizando algoritmos específicos
para extração de possíveis padrões existentes nesses conjuntos de dados. Este artigo demonstra a implementação do
algoritmo Naive Bayes, que utiliza o Teorema de Bayes e os conceitos de estatística e probabilidade para a tarefa de
classificação, e a sua aplicação em uma base de dados da área médica referente á dados clínicos de pacientes com
diagnóstico positivo para o câncer de mama. A tarefa de classificação consiste na identificação de propriedades comuns
entre os elementos de uma base de dados e a associação desses elementos a uma classe predefinida, sendo que o
algoritmo implementado atribui ao registro o rótulo de classe que apresentar a probabilidade máxima a posteriori,
considerando a independência condicional entre os atributos, o que simplifica os cálculos necessários tornando mais
rápido o processo de treinamento do algoritmo. Ao final da pesquisa foram realizados testes em uma base de dados e o
resultados gerados pelo algoritmo foram avaliados usando algumas medidas de qualidade como sensibilidade,
especificidade, acurácia, confiabilidade positiva e índice Kappa.

PALAVRAS-CHAVES
Inteligência Computacional, Data Mining, Classificação, Algoritmo Naive Bayes, Probabilidade.

1. INTRODUÇÃO
O data mining objetiva a descoberta de padrões válidos e novos em grandes conjuntos de dados (Fayyad et
al, 1996), sendo composta por tarefas, no qual são implementadas em ferramentas conhecidas como shells,
sendo que existe em desenvolvimento a Shell Orion Data Mining Engine, que consiste em um projeto
implementado em âmbito acadêmico. Dentre as diversas tarefas existentes no processo de data mining, a
Shell Orion atualmente disponibiliza as tarefas de associação, classificação e clusterização.
A classificação é vista como uma das mais populares e utilizadas tarefas do data mining (Goldschmidt e
Passos, 2005). Consiste em associar um registro de uma determinada base de dados a uma classe predefinida.
Os classificadores estatísticos baseados no teorema de Bayes, também conhecidos como classificadores
bayesianos, utilizam a probabilidade como principal recurso para identificação da classe. Usados para lidar
com situações de incerteza por aleatoriedade, destacam-se por apresentar um menor tempo no processo de
aprendizagem.
Neste artigo apresenta-se o desenvolvimento do algoritmo Naive Bayes, baseado no teorema de Bayes, no
módulo de classificação da Shell Orion e uma avaliação dos seus resultados por meio de medidas de
validação em data mining, bem como a comparação dos resultados com o de outra ferramenta, no caso a
Weka.

223
ISBN: 978-972-8939-96-0 © 2013 IADIS

2. O ALGORITMO NAIVE BAYES NA TAREFA DE CLASSIFICAÇÃO

DA SHELL ORION DATA MINING ENGINE
O algoritmo Naive Bayes foi proposto por Richard Duda e Peter Hart no livro Pattern Classification and
Scene Analisys em 1973 na Califórnia, Estados Unidos, originado do trabalho de reconhecimento de padrões
e análise de cenas em aprendizado de máquina.
É um classificador estatístico que utiliza os conceitos da probabilidade para identificar a qual classe
predefinida pertence um determinado registro. A sua principal característica é a suposição da independência
condicional, ou seja, ele assume que o efeito do valor de um atributo a uma determinada classe é
independente dos valores dos demais atributos (Coppin, 2010).
A modelagem do algoritmo Naive Bayes iniciou-se com a construção dos diagramas de caso de uso,
atividades e seqüência utilizando os padrões Unified Modeling Language (UML). Posteriormente foi
desenvolvida a demonstração matemática do funcionamento do algoritmo com a finalidade de facilitar o
entendimento e a sua implementação.
O algoritmo necessita de dois conjuntos de dados sendo um para o treinamento e outro para testes.
Definidos os dois conjuntos de dados, o primeiro passo consiste em:
a) identificar o número de classes;
b) identificar o total de amostras no conjunto de treinamento;
c) identificar o total de amostras para cada classe;
Com os parâmetros obtidos, calcula-se primeiramente a probabilidade a priori de cada classe conforme a
fórmula:

Esse cálculo consiste na divisão do número de amostras Si rotuladas como classe Ci pelo total de amostras
S. Visto que o cálculo da probabilidade é dado por uma fração, se o numerador assumir o valor zero o
resultado pode ser comprometido. Para evitar esse problema utiliza-se o teorema da aproximação de Laplace
adicionando a constante 1 ao numerador e a variável k ao denominador:

Onde nc é o número de instâncias pertencentes à classe Ci, n é o número total de instâncias de treinamento
com classe Ci e k corresponde à quantidade máxima de valores distintos, ou seja, k=3.
A fórmula para o cálculo da probabilidade a priori de cada classe é alterada para:

O próximo passo consiste em calcular a probabilidade de cada atributo da amostra de teste condicionada a
cada uma das classes aplicando o teorema de Laplace à fórmula:

Estima-se então as probabilidades da amostra total P(X|Ci). Segundo Coppin (2010), Duda e Hart (1973)
e Han e Kamber (2001), para reduzir o custo computacional durante o cálculo de P(X|Ci), o Naive Bayes
considera a independência condicional de classe, ou seja, o efeito do valor de um determinado atributo sobre
uma classe é considerado independente dos valores dos outros atributos. Esta afirmação é dada por:

Posteriormente as regras de classificação são aplicadas considerando-se a probabilidade a priori de cada

classe:

O resultado obtido pela a aplicação das regras de classificação define a máxima a posteriori que indicará
a qual classe pertence o registro analisado.

224
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

2.1 Implementação
O algoritmo Naive Bayes foi desenvolvido no módulo de classificação da Shell Orion Data Mining Engine,
por meio da linguagem de programação Java e do ambiente de programação integrado NetBeans 7.1.1.
Para a execução do algoritmo é necessário que seja informado pelo usuário o método de teste a ser
realizado. Entre as opções disponíveis na Shell Orion tem-se o método holdout e a opção de usar o conjunto
de treinamento.
A opção holdout permite resultados mais confiáveis, uma vez que as amostras reservadas para o conjunto
de testes não fazem parte do conjunto de treinamento (Witten et al, 2011).
A sugestão de proporção para dados reservados é de 2/3 para treinamento e 1/3 para testes, mas a
alteração do percentual de dados reservado para treinamento também é permitida (Tan et al, 2009).
Nas análises dos resultados obtidos, foram empregados os seguintes medidas de qualidade:
a) sensibilidade: é a capacidade do classificador para encontrar os registros que realmente pertencem a
classe considerada;
b) especificidade: consiste na capacidade do classificador para encontrar os registros que não
pertencem a classe considerada;
c) acurácia: é o grau de exatidão, relação entre os valores estimados e os valores reais;
d) erro: refere-se à taxa de erro geral, ou seja, a proporção de registros classificados incorretamente;
e) confiabilidade positiva: é a capacidade do classificador para identificar corretamente os verdadeiros
positivos;
f) índice kappa: é o coeficiente de avaliação da concordância entre os resultados.

2.2 Resultados Obtidos

A base de dados utilizada na avaliação do algoritmo Naive Bayes na Shell Orion refere-se a dados clínicos de
pacientes com diagnóstico positivo para o câncer de mama dos hospitais da Universidade de Wisconsin,
Madison nos Estados Unidos disponibilizada pelo repositório UCI Machine Learning Repository. É
composta por 683 registros com 10 atributos e 2 classes que identificam o resultado do diagnóstico como
benigno ou maligno.
Os testes realizados abrangem a análise da precisão dos resultados obtidos e a comparação com os
resultados da ferramenta Weka 3.6.7 (http://www.cs.waikato.ac.nz/ml/weka/), a comparação entre os tempos
de processamento durante o treinamento e a classificação na Shell Orion, e os tempos de processamento entre
a Shell Orion e a ferramenta Weka.
2.2.1 Classes Identificadas pelo algoritmo Naive Bayes
O teste para a identificação das classes e validação do desempenho foi realizado utilizando o método holdout.
Optou-se por repetir o teste por três vezes usando percentuais diferentes para cada teste.
A melhor taxa de acertos confirmou que a proporção de 2/3 dos registros reservados para treinamento
apresenta resultados mais precisos.
A tabela 1 mostra a matriz de confusão que exibe o número de classificações preditas versus o número de
classificações corretas. Por meio da contagem destes registros tem-se a avaliação de desempenho do modelo
(Tan et al, 2009).
Tabela 1. Matriz de confusão – Classificação da base do câncer de mama na Shell Orion
Predita Predita
Classe Total
Classe 2 Classe 4
Verdadeira
176 2 178
Classe 2
Verdadeira
0 54 54
Classe 4
Total 176 56 232
Dos valores obtidos na matriz de confusão pode-se extrair as seguintes variáveis mostradas na tabela 2:

225
ISBN: 978-972-8939-96-0 © 2013 IADIS

Tabela 2. Relação de verdadeiros e falsos positivos e verdadeiros e falsos negativos.

Variável Valor
Verdadeiros Positivos 176
Falsos Positivos 0
Verdadeiros Negativos 54
Falsos Negativos 2
Com os valores das variáveis da tabela 2, calcularam-se as medidas de qualidade do modelo. A tabela 3
demonstra os valores obtidos pela Shell Orion.
Tabela 3. Medidas de Qualidade – Shell Orion.

Variável Shell Orion

Registros classificados corretamente 230
Registros classificados incorretamente 2
Sensibilidade 98,88%
Especificidade 100%
Acurácia 99,14%
Erro 0,86%
Confiabilidade positiva 100%
Índice Kappa 0,976
A análise dos valores obtidos nas medidas de qualidade mostram que o desempenho do módulo
desenvolvido pode ser considerado satisfatório por apresentar medidas próximos de 100% e taxa de erro
próxima de zero.
2.2.2 Comparação das Medidas de Qualidade com a Ferramenta Weka 3.6.7
Nessa etapa analisou-se a qualidade dos resultados gerados pela Shell Orion e comparou-se com os
resultados obtidos pela ferramenta Weka. Apenas as medidas de qualidade foram considerados nessa
avaliação, portando os tempos de processamento foram ignorados.
A análise seguinte optou-se por utilizar o método holdout reservando 66% da base de dados para
treinamento e o restante para teste. Os valores obtidos para as medidas de qualidade nas duas ferramentas são
mostrados na tabela 7.
Tabela 6. Medidas de qualidade – Comparação entre Shell Orion e Weka

Variável Shell Orion Weka

Registros classificados corretamente 230 229
Registros classificados
2 3
incorretamente
Sensibilidade 98,88% 98,88%
Especificidade 100% 98,1%
Acurácia 99,14% 98,7%
Erro 0,86% 1,3%
Confiabilidade positive 100% 99,4%
Índice Kappa 0,976 0,964
A análise dos valores obtidos nas medidas de qualidade e a comparação com a Weka mostrou que a Shell
Orion obteve resultados melhores em quase todos as medidas confirmando o seu correto funcionamento,
especialmente no que diz respeito a percentuais de acerto (Shell Orion – 99,14%; Weka – 98,71%) e índice
Kappa (Shell Orion – 0,976; Weka – 0,964).
Concluiu-se que ambas as ferramentas têm comportamento semelhante com relação à qualidade dos
resultados do processo de classificação.

226
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

3. CONCLUSÃO
Este artigo apresentou o algoritmo Naive Bayes que utiliza os conceitos de estatística e probabilidade
baseados no teorema de Bayes, para a tarefa de classificação da Shell Orion Data Mining Engine,
contribuindo com a ampliação das funcionalidades da ferramenta.
Pode-se confirmar, diante dos resultados obtidos, a aplicabilidade do algoritmo para a tarefa de
classificação visto que os resultados avaliados apresentaram boas medidas de qualidades relacionados à
precisão e confiabilidade dos valores obtidos.
Concluiu-se que o algoritmo foi implementado com sucesso, pois apresentou resultados satisfatórios
obtidos no processo de classificação e ainda melhores quando comparados com uma ferramenta de data
mining bastante utilizada e também gratuita, confirmando o seu correto funcionamento.

REFERÊNCIAS
Coppin, B. 2010. Inteligência artificial. LTC, Rio de Janeiro.
Fayyad, U. M., Piatetsky-shapiro, G. e Smyth, P. 1996. From data mining to knowledge discovery in databases. AI
Magazine, Providence, v.17, n. 3, p. 37-54.
Duda, R. O., Hart, P. E. e Stork, D. G. 2000. Pattern Classification, JohnWiley & Sons, New York.
Goldschmidt, R. e Passos, E. L. 2005. Data mining: uma guia prático, Elsevier, Rio de Janeiro.
Han, J. e Kamber, M. 2006. Data mining: concepts and techniques. Morgan Kaufmann, San Francisco.
Tan, P. et al. 2009. Introdução ao Datamining: mineração de dados, Ciência Moderna, Rio de Janeiro.
Witten, I. H. et al. 2011. Data mining practical machine learning tools and techniques, Morgan Kaufmann, Burlington.

227
ISBN: 978-972-8939-96-0 © 2013 IADIS

SISTEMA DE ANÁLISE DE VÍDEO EM TEMPO REAL NA

DETECÇÃO DE PADRÕES DE MOVIMENTO

Davi Alberto Sala, Adriane Parraga e Letícia Vieira Guimarães

Universidade Estadual do Rio Grande do Sul

RESUMO
Uma das seções mais ativas nos campos de pesquisa da área de visão computacional é a segurança eletrônica, onde o
processamento de vídeo em tempo real necessita ser eficaz e rápido. Com a rápida evolução e baixo custo de hardware, é
possível a criação de sistemas mais inteligentes. Para estes sistemas, a segmentação e análise do movimento são
essenciais. O movimento é uma informação importante em sequências de imagens, indicando a dinâmica na cena
apontada pela diferença espacial entre os objetos deslocados. Porém a tarefa de análise de movimento permanece um
desafio e um problema fundamental em visão computacional devido à complexidade que a cena apresenta. É possível
extrair várias características importantes a partir do movimento de um objeto, como a direção, velocidade média e
velocidade instantânea. A partir das características extraídas, pode-se rastrear e reconhecer padrões de movimento. Neste
artigo, serão implementados métodos para a criação de um sistema capaz de rastrear e classificar o movimento de objetos
em tempo real. Os métodos utilizados foram o fluxo óptico para a detecção dos vetores de movimento e para a remoção
de ruídos foram utilizados filtros e subtração de fundo. O método de subtração de fundo foi o que apresentou o melhor
desempenho em termos de velocidade.

PALAVRAS CHAVE
Segurança, detecção de movimento, fluxo óptico, opencv, segmentação.

1. INTRODUÇÃO
Vigilância eletrônica é a observação de pessoas, carros, animais e outros objetos de relevância, em tempo
real, com a descrição de suas atividades e interações e a respectiva classificação de seu potencial de
periculosidade (Nascimento et al. 2005). O desenvolvimento de sistemas de monitoramento automático de
movimentos em vídeo tem crescido muito nos últimos anos. Em (Mueller et al. 2013) é proposto o uso de
visão computacional baseado em fluxo óptico para a detecção de chamas para a prevenção de destruição de
bens materiais e humano. Em (Feng-Li et al., 2013) é proposto o uso de câmeras em rede para fornecer a
segurança pública. Porém, devido à grande quantidade de dados e considerando transmissão em tempo real
de banda limitada, é proposto um método de seleção dos dados das câmeras que serão enviados para uma
central.
Câmeras de segurança são instaladas em todo lugar. E por isso, a vigilância eletrônica tem se tornado um
dos campos de pesquisa mais ativos na área de visão computacional e processamento de sinais (Liang Wang
et al., 2003). Com o baixo custo de câmeras de segurança, hoje, é comum ter várias câmeras espalhadas em
centros comerciais, bancos, condomínios e outros locais com alta circulação de pessoas, porém, esse grande
número de câmeras instaladas excede a capacidade humana de rastreá-las adequadamente, assim, não
aproveitando completamente o potencial disponibilizado por todo esse equipamento instalado. Assim as
imagens das câmeras tornam-se apenas ferramentas para auxiliar na investigação policial após o crime ou
acidente ter ocorrido.
O objetivo deste trabalho é desenvolver um sistema capaz de identificar situações de risco em tempo real
para então emitir sinais de alerta para que as ações necessárias sejam tomadas. Para alcançar este objetivo,
serão utilizados vários métodos de processamento de imagem, como aplicação de filtros e subtração de fundo
para remoção de ruído e o estudo e análise do fluxo óptico para a detecção de análise do movimento.

228
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

2. MATERIAIS E MÉTODOS
Neste trabalho serão apresentados os resultados das aplicações do fluxo óptico para detecção do movimento
em vídeo em tempo real. Para isso, serão utilizados uma câmera comum para obtenção das imagens, a
linguagem de programação c++, a biblioteca de computação visual openCV para as funções de
processamento de imagem e o framework Qt para implementação da interface gráfica. O diagrama de blocos
apresentado na Figura 1 representa o fluxo de desenvolvimento e funcionamento do sistema.

Figura 1. Diagrama representando o fluxo de desenvolvimento do sistema

2.1 Aquisição do Sinal

O sistema é capaz de capturar imagens a partir de câmeras USB, também é possível adquirir imagens a partir
de um stream de vídeo online, como, por exemplo, o vídeo gerado por câmeras IP, e por fim pode-se também
obter as imagens diretamente de um arquivo de vídeo.

2.2 Segmentação dos Objetos

O fluxo óptico é calculado a partir de uma sequência de imagens, porém a quantidade de ruído presente nas
imagens dificulta consideravelmente o resultado obtido. Por isso é necessário um pré-tratamento das
imagens. Neste caso o ruído é definido como qualquer a alteração na cena que não corresponda a um objeto
de interesse em movimento, como alteração na iluminação, interferências causadas pelo software ou
hardware da câmera, perdas de qualidade na compressão da imagem, entre outros fatores. A eliminação de
ruído em imagens utilizando filtros de suavização, como filtros gaussianos e de mediana, acaba sendo um
processo demorado e com resultados pouco satisfatórios.
Como alternativa à aplicação de filtros, foi utilizado o método da subtração de fundo adaptativa, que
consiste em determinar um fundo para a cena, onde mudanças de cada quadro analisado também são
incluídas para a cálculo do fundo da cena, criando assim um fundo que se adapta a cena atual, fazendo com
que novos objetos estáticos e alterações permanentes no ambiente se incorporem ao fundo (KaewTraKulPong
and Bowden, 2011).

2.3 Fluxo Óptico

Fluxo óptico é definido como a distribuição 2D do vetor de velocidade aparente entre os pixels de quadros
consecutivos (Smith, 1998) e pode ser utilizado para descrever uma movimentação de objetos numa sequência
de imagens. O fluxo óptico (Shui-gen et al., 2011) foi desenvolvido para detectar objetos em movimento em
uma sequência de imagens.

229
ISBN: 978-972-8939-96-0 © 2013 IADIS

Seja uma imagem em movimento dada por I(x,y; t), onde (x; y) são as coordenadas de um pixel na
imagem I e t é o tempo. A hipótese do fluxo óptico é que a intensidade dos pixels na imagem é preservada no
movimento ou que a imagem pouco se mexeu de um quadro para outro. Assume-se então que a intensidade
da imagem em movimento permanece constante (Horn; Schunck, 1981), de forma que:

I ( x, y, t )  I ( x  dx, y  dy, t  dt ) (1)

Aplicando-se a regra da cadeira na equação (1), chega-se na equação de restrição do fluxo óptico,

I .v  I t  0
conforme a equação (2):
(2)

Onde I   I , I  é o gradiente da Imagem I e v   x , y , é o vetor de movimento que se busca.

 x y   t t 
 
Somente a equação de restrição não é suficiente para estimar os componentes de, pois não é possível
resolver a equação diretamente, pois se tem duas incógnitas. Existem vários métodos propostos para a
resolver desta equação, entre eles, o escolhido foi o método Lucas-Kanade (Lucas and Kanade, 1981), onde
se assume que a movimentação num espaço curto de tempo ocorre é pequena e ocorre o deslocamento de um
grupo de pontos e não somente do ponto. Portanto, todos esses pontos possuem o mesmo vetor de velocidade
e sendo assim, é possível montar um sistema entre as equações de fluxo de todos estes pontos para descobrir
o vetor do fluxo óptico.
A Figura 2 mostra a aplicação do fluxo óptico utilizando o método de Lucas-Kanade, onde em (a) tem-se
duas imagens de um círculo sendo deslocado para a direita e em (b) o resultado obtido.

(b)

(a)
Figura 2. Exemplo da aplicação do fluxo óptico aplicada em um par de imagens (a) Imagens de um círculo deslocado
para a direita e (b) vetores do fluxo óptico aplicado entre as imagens.

2.4 Extração de Características

Com os vetores obtidos com a aplicação do fluxo óptico é possível inferir certos aspectos da cena, como, por
exemplo, velocidade instantânea dos objetos de interesse. Tendo um conhecimento prévio do ambiente
também é possível estimar a direção do objeto no espaço 3D. A quantidade de vetores disponíveis após o
cálculo pode ser relativamente grande comparado com o tempo de computação disponível para uma
aplicação em tempo real, então, para garantir um desempenho melhor do sistema, torna-se necessário
selecionar os vetores que melhor representam a movimentação do objeto.
A filtragem dos vetores é necessária, pois é possível a obtenção de vetores falsos, que são considerados
como ruído, definidos como todos os vetores que não representam a real movimentação do objeto, como, por
exemplo, os vetores provenientes da rotação das rodas de um carro em um ambiente externo, ou do
movimento natural do braço que se movimenta para frente e para trás enquanto a pessoa caminha apenas em
uma direção. Para esta filtragem, levam-se em conta vários fatores, como quantidade de vetores do objeto em
questão, direção sentido e módulo da maioria dos vetores e estado anterior do objeto. Feita esta filtragem, os
vetores de interesse podem ser analisados para a extração de características e classificação.

230
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

2.5 Classificação do Movimento

A partir dos vetores de velocidade é criado um vetor de características que será utilizado para efetuar a
classificação. Com estes vetores é possível rastrear o objeto de interesse e reconhecer certos padrões de
movimentos já determinados conforme o ambiente, classificando assim o potencial de perigo de cada
situação. Após a criação do vetor de características, que representam o movimento em uma determinada
cena, este deve ser classificado. Entre os métodos de classificação existentes, será utilizada uma rede neural
artificial (Muller, 2013).
Quando o sistema detectar uma situação de risco, um sinal será enviado para que a atenção do observador
seja voltada para aquela cena. O sistema terá uma interface gráfica onde é possível definir situações de risco,
como por exemplo, movimento mais rápido que a maioria dos objetos em movimento no local, acesso a áreas
restritas, movimentações fora do horário estabelecido, entre outros.

3. RESULTADOS PARCIAIS
A implementação do sistema se encontra na fase de extração de características, onde já é possível determinar
velocidade, direção e estimar uma distância do objeto em relação à câmera no ambiente. Inicialmente foram
utilizados filtros passa baixa para suavizar a quantidade de ruídos presentes nas imagens, porém como a
aplicação filtros sucessivos requer uma quantia de tempo grande para ser realizada, outra solução foi
necessária. O método da subtração de fundo provou-se mais robusto e rápido tanto em relação ao tempo de
processamento quanto aos resultados. A comparação de tempo de processamento entre os diferentes métodos
de remoção de ruídos pode ser observada na tabela 1.
A média de quadros por segundo é o principal fator para a escolha do método escolhido, porém é
necessário levar em conta o número de recálculos feitos para os pontos de referência do fluxo óptico. Uma
vez que o fluxo óptico não é calculado para toda a imagem, e sim apenas para alguns pontos, deixando assim
o cálculo do fluxo óptico mais rápido. Um número elevado de recálculos significa que o objeto não possui
mais uma quantidade de pontos rastreáveis suficientes e é necessário obter novos pontos, podendo perder
assim algumas informações sobre o objeto.
Tabela 1. Comparação de desempenho entre a aplicação de filtros e a utilização da subtração de fundo.
Método utilizado Média de quadros processados Número de recálculos
por segundo
Filtro Gaussiano 58 33
Filtro de mediana 22 28
Filtro Gaussiano e de mediana 20 28
Subtração de fundo 32 12

A subtração de fundo além de apresentar um bom resultado em comparação à aplicação de filtros,

também deixa os objetos separados da cena, auxiliando no processo de segmentação dos objetos da cena.

4. CONCLUSÃO E TRABALHOS FUTUROS

Através dos estudos e experimentos realizados pode-se constatar que é possível, com o poder computacional
atual, rastrear e classificar objetos em movimento em tempo real. Ainda é possível afirmar que a classificação
e rastreamento do movimento serão realizáveis a partir do momento em que os resultados obtidos na extração
de características sejam satisfatórios.
O Método de subtração de fundo apresentou um bom desempenho no auxílio dos vetores de movimento,
juntamente com o Fluxo óptico. Como o objetivo final do trabalho é a classificação do tipo de movimento, os
resultados com método de Kanade foram satisfatórios. Contudo, o diferencial deste trabalho é que os vetores
de velocidade são estimados nos contornos dos objetos segmentados, e não na imagem toda. Isso faz com que
o método seja rápido e preciso.

231
ISBN: 978-972-8939-96-0 © 2013 IADIS

As próximas etapas consistem em implementar uma rede neural para a classificação do tipo de
movimento encontrado numa cena, e também o aperfeiçoamento dos métodos já utilizados para a obtenção
de melhores resultados. A classificação do movimento neste caso será o principal ponto de estudo, pois a
partir do momento em que a extração das características foi realizada com sucesso, é necessário um estudo e
comparação dos vários métodos para classificação de características possíveis.

REFERÊNCIAS
Feng-Li Lian, Yi-Chun Lin, Chien-Ting Kuo, and Jong-Hann Jean, 2103. Voting-Based Motion Estimation for
Real-Time Video Transmission in Networked Mobile Camera Systems. IEEE Transactions on Industrial Informatics,
VOL. 9, NO. 1, February 2013.
Horn, b. K.; schunck, b. G. 1981. Determining optical flow. Artificial Intelligence, v.17, p.185–203
KaewTraKulPong , P. and Bowden, R., 2011. An Improved Adaptive Background Mixture Model for Realtime Tracking
with Shadow Detection. In Proc. 2nd European Workshop on Advanced Video Based Surveillance Systems,
AVBS01. Sept 2001.
Liang Wang, Weiming Hu, and Tieniu Tan, 2003. Recent developments in human motion analysis. Pattern Recognition.
Lucas B. D. and Kanade T., 1981. An iterative image-registration technique with an application to stereo vision. In
DARPA Image Understanding Workshop.
Mueller, M. ; Karasev, P. ; Kolesov, I. ; Tannenbaum, A. 2013. Optical Flow Estimation for Flame Detection in Videos.
Image Processing, IEEE Transactions on Volume: 22 , Issue: 7. Page(s): 2786 - 2797
Nascimento, J. C. and Figueiredo, M. A. T. and Marques, J. S. 2005. Motion segmentation for activity surveillance. In 1st
Workshop on Systems, Decision and Control Robotic Monitoring and Surveillance, Lisbon.
Shui-gen Wei, Lei Yang, Zhen Chen, Zhen-feng Liu 2011, Motion Detection Based on Optical Flow and Self adaptive
Threshold Segmentation, Procedia Engineering, Volume 15, 2011, Pages 3471-3476, ISSN 1877-7058, 10.1016.
Smith S. M., and Brady J. M. et al, 1995. Asset-2: Real time motion segmentation and shape tracking. IEEE
Transactions on Pattern Analysis and Machine Inteligence, 17(8).

232
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

MODBUS SECURE: INCORPORANDO MECANISMOS DE

SEGURANÇA NO PROTOCOLO MODBUS

Édson Fick , Rodrigo Marques de Figueiredo e Janaína Conceição Sutil Lemos

Universidade do Vale do Rio dos Sinos - UNISINOS
Av. Unisinos, 950, Bairro Cristo Rei, São Leopoldo, Rio Grande do Sul, Brasil

RESUMO
Os sistemas de controle industriais, antes isolados, têm sido conectados a uma quantidade crescente de redes. Por
executarem funções críticas e pelo fato de os protocolos de comunicação utilizados nesses sistemas não empregarem
mecanismos de segurança, os mesmos tornaram-se alvos de diversos ataques nos últimos anos. Com objetivo de
aumentar a segurança nas redes industriais, este trabalho propõe a agregação de mecanismos para autenticação e
verificação de integridade ao protocolo Modbus, que é largamente utilizado nesse tipo de rede.

PALAVRAS-CHAVE
Redes industriais, Modbus, Segurança, Autenticação, Integridade.

1. INTRODUÇÃO
Sistema de controle industrial (Industrial Control System – ICS) é um termo genérico utilizado para
referenciar diversos tipos de sistemas de controle, como por exemplo, os sistemas supervisórios e de
aquisição de dados (SCADA) e também as malhas de controle que são formadas por controladores lógicos
programáveis (CLPs) e dispositivos como atuadores e sensores. Tais exemplos são comumente encontrados
em indústrias químicas, de óleo e gás, automotiva, alimentícias e de papel, entre outras (Castrucci e Moraes,
2007).
Os sistemas SCADA são utilizados para controlar dispositivos localizados geograficamente distantes uns
dos outros e também do próprio sistema, monitorando alarmes e processando informações de status dos
mesmos através de redes de longa distância. De acordo com as informações recebidas, comandos
automatizados ou definidos por um operador podem ser enviados para os dispositivos de campo, que é como
são chamados os CLPs.
Mesmo desempenhando funções críticas, os sistemas de controle industriais apresentam diversas
vulnerabilidades, sendo diversas delas relacionadas com as redes de campo e de controle, nas quais são
utilizados diversos protocolos de comunicação que não empregam mecanismos de segurança. A exposição
desses sistemas às ameaças aumenta à medida que eles são conectados a um número cada vez maior de redes
e sistemas, fato que causou nos últimos anos um aumento considerável de ataques a redes industriais. Tais
ataques podem resultar em prejuízos a saúde das pessoas e ao meio ambiente, além dos impactos negativos
no processo produtivo e dos prejuízos financeiros (NIST 2011).
Pelo exposto até então surge a motivação para agregar recursos de segurança as redes industriais Modbus
(Modbus Organization 2012). Para atingir esse objetivo esse trabalho propõe a incorporação ao protocolo
Modbus de mecanismos capazes de garantir a integridade dos dados recebidos e enviados e a autenticação
das partes envolvidas na comunicação.
Para esse fim são utilizadas assinaturas digitais em todas as mensagens. O uso das assinaturas digitais
possibilita que as partes envolvidas na comunicação (como por exemplo, um sistema SCADA e um CLP)
possam verificar a integridade dos dados recebidos e ter a certeza de que o emissor da mensagem é mesmo
quem afirma ser. A implementação destes recursos é focada em equipamentos novos, com capacidade para
realizar os cálculos e as comparações necessárias em tempos curtos.

233
ISBN: 978-972-8939-96-0 © 2013 IADIS

2. VULNERABILIDADES DOS SISTEMAS DE CONTROLE

INDUSTRIAIS
Muitos dos sistemas de automação industrial que estão em uso atualmente foram desenvolvidos antes do
surgimento ou da popularização da Internet. Esses sistemas foram projetados para atender requisitos de
desempenho e de flexibilidade, com softwares e protocolos de comunicação que possuem mecanismos para
realizar somente a detecção de erros básicos (como por exemplo, o emprego de CRC nas mensagens), mas
sem os recursos de comunicação segura exigidos nos sistemas interligados utilizados na atualidade.
Tais recursos tornam-se cada vez mais necessários uma vez que a interligação dos ambientes corporativos
e industriais expõe os sistemas de automação às mesmas ameaças presentes nas redes corporativas. Por
exemplo, em 2003, um ataque a rede corporativa da usina nuclear de Davis-Besse, em Ohio, através do “MS
SQL Slammer worm” causou uma sobrecarga na rede e fez com que os sistemas de controle da usina ficassem
inacessíveis por horas (Miller e Rowe 2012). Um ataque como esse oferece risco significativo à saúde e a
segurança de vidas humanas, podendo também causar danos graves ao meio ambiente e impactos negativos
nos processos produtivos. Entre as operações que podem ocasionar sérias consequências, está a possibilidade
de qualquer computador realizar a descoberta de dispositivos presentes nessas redes e o envio de comandos
para CLPs por uma entidade mal-intencionada.

3. TRABALHOS RELACIONADOS
Com o objetivo de prevenir ataques às redes industriais, gradualmente os sistemas de automação industrial
foram adotando soluções de Tecnologia da Informação (TI) para promover de forma segura a conectividade
corporativa e recursos de acesso remoto, utilizando redes TCP/IP.
Um exemplo de solução que tem sido adotada pelas corporações é o firewall com funcionalidades
específicas para proteger os sistemas industriais (Tofino Security, 2012). Diferentemente do firewall
convencional que aplica filtros com base no endereço IP e porta de origem e destino dos pacotes, esse tipo de
equipamento possui inteligência para inspecionar os pacotes dos protocolos usados em automação
determinando se os mesmos contêm comandos para leitura de status ou, por exemplo, um comando para
atualização de firmware de um CLP. Esta solução pode ser empregada para proteger as redes formadas por
dispositivos antigos sem que seja necessário substituir equipamentos.
Por outro lado, os protocolos de comunicação utilizados nas redes industriais – como é o caso do
Modbus, que é tratado na seção a seguir, oferecem somente mecanismos para verificação de integridade dos
dados (CRC), sem a possibilidade de autenticar as partes envolvidas na comunicação.

4. O PROTOCOLO MODBUS
O MODBUS é um protocolo de requisição / resposta que oferece serviços específicos por códigos de função.
Criado em 1979 na versão serial, este protocolo continua sendo largamente utilizado na comunicação de
dispositivos de automação. O Modbus possui a mesma implementação na camada de aplicação, independente
do meio físico utilizado. O mapeamento do protocolo Modbus em uma rede específica pode adicionar mais
campos na unidade de dados da aplicação (Application Data Unit – ADU)

4.1 Modbus TCP

O Modbus TCP/IP utiliza a mesma unidade de dados do protocolo (Protocol Data Unit – PDU) da versão
serial, com os mesmos campos de código de função e dados. Na pilha TCP/IP, a porta 502 é reservada para o
Modbus (Modbus Organization 2012). A diferença no frame do Modbus TCP/IP está no ADU do mesmo. A
identificação do ADU do Modbus TCP/IP é feita através de um cabeçalho dedicado denominado pela sigla
MBAP (Modbus Application Protocol Header). O ADU é definido pelo cliente, que por sua vez inicializa a
transação. O campo código da função indica qual ação deverá ser executada pelo servidor, que pode ser, por

234
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

exemplo, um CLP. O protocolo de aplicação Modbus estabelece o formato da requisição inicializada pelo
cliente, como por exemplo, um sistema SCADA (Modbus Organization 2012).
Um sistema de comunicação Modbus TCP/IP pode conter diferentes tipos de dispositivos, como
dispositivos cliente/servidor conectados a uma rede TCP/IP, dispositivos de interconexão (bridges, gateways,
roteadores) para interligar a rede TCP/IP a uma sub-rede serial, permitindo a conexão com dispositivos
Modbus de uma linha serial (Modbus Organization 2006).

5. O PROTOCOLO MODBUS SECURE

Com o objetivo de agregar segurança ao protocolo Modbus, são utilizadas assinaturas digitais nas mensagens.
Para que ambas as partes (como por exemplo, um sistema SCADA e um CLP) possam verificar a
autenticidade das mensagens enviadas, é necessário que ambos possuam a chave pública um do outro. O
armazenamento das chaves públicas deverá ser feito no momento da instalação do dispositivo na rede de
campo.
Para o envio de uma requisição Modbus, após a geração do pacote que contém a mesma, é gerado um
hash da mensagem, sendo este assinado digitalmente com a chave privada do emissor. O hash assinado é
então enviado com a mensagem original. Quando recebe a requisição assinada, a outra parte verifica a mesma
descriptografando o hash recebido com alguma das chaves públicas que ele armazena. Após ter concluído
esta etapa ele gera um hash da mensagem recebida e compara com o que foi descriptografado. Se ambos
coincidirem, o receptor pode afirmar que os dados estão íntegros e que o emissor da mensagem é mesmo
quem afirma ser. Caso contrário, a mensagem é descartada, conforme mostra a figura 1a.
Estando a requisição correta, a ação presente na mensagem é executada (no caso de solicitação de escrita)
ou a resposta é enviada (se a requisição for de leitura). Nesse segundo caso, a outra parte deverá proceder da
mesma forma explicada acima para verificar a autenticidade da mensagem. No que diz respeito ao espaço
ocupado nas mensagens, a inserção do hash assinado digitalmente ocupa 112 bytes, independentemente do
tamanho da mensagem original. Assim, o pacote Modbus Secure terá o tamanho máximo de 367 bytes (255
bytes do pacote Modbus + 112 do hash assinado). As mensagens Modbus TCP tradicional e Modbus Secure
são mostradas na figura 1b.
Em relação ao desenvolvimento do protótipo Modbus Secure, para geração dos hashes é utilizada a
ferramenta Md5Sum e as assinaturas digitais são feitas com o auxílio do software GPG (GNU Privacy
Guard), utilizando o tipo de chave “DAS e Elgamal” e par de chaves de 1024 bits. A implementação está em
andamento.

Figura 1. Fluxograma do Modbus Secure (a) e Mensagens do Modbus TCP/IP e Modbus Secure (b)

235
ISBN: 978-972-8939-96-0 © 2013 IADIS

6. DESEMPENHO DO MODBUS SECURE

A requisição Modbus Secure enviada através da rede contém além da mensagem original um hash dessa
mensagem assinado digitalmente com a chave privada do emissor. Quando recebe a requisição, a outra parte
envolvida na comunicação deve verificá-la revertendo a criptografia do hash e gerando um hash da
mensagem recebida para comparar com o que foi recebido.
O tempo gasto no processamento de uma requisição é proporcional ao tempo gasto para descriptografar o
hash mais o tempo necessário para o cálculo do hash e a posterior comparação dos dois hashes. A fim de
obter uma estimativa deste tempo e permitir uma comparação do mesmo com o tempo gasto no
processamento de uma requisição Modbus tradicional, foram realizadas execuções sucessivas dos módulos
responsáveis pela análise de requisições e pela autenticação no protótipo do Modbus Secure. Estes módulos
utilizam o MD5Sum e o software GPG (GNU Privacy Guard).
Os resultados são apresentados na tabela 1 e representam os valores médios obtidos em 20 execuções para
cada protocolo. Todos os testes foram executados em uma máquina com processador Intel Core I5
executando o sistema operacional Ubuntu 8.04 em uma máquina virtual utilizando o software Virtualbox.
Tabela 1. Tempos obtidos no processamento de requisições com Modbus padrão e Modbus Secure
Mensagem Protocolo Tempo (ms)

Requisição de leitura de um Modbus 2 ms

registro

Modbus Secure 26.21 ms

7. CONCLUSÕES
A solução apresentada neste trabalho permite a verificação de integridade dos dados e para autenticação das
mensagens do protocolo Modbus TCP. O uso de mecanismos de segurança utilizados (geração de hashes e
assinaturas digitais nas mensagens) não causa impactos significativos nos tempos de resposta dos CLPs, uma
vez que os mesmos possuem atualmente capacidade computacional suficiente para executar as rotinas
relacionadas à segurança em tempos curtos. O Modbus Secure pode ser utilizado em conjunto com os
firewalls que inspecionam pacotes de protocolos de redes industriais para agregar uma camada extra de
segurança nas transações entre sistemas SCADA e CLPs, uma vez que ele pode atuar nos equipamentos
novos, enquanto que o firewall permite proteção também aos sistemas legados.

REFERÊNCIAS
Modbus Organization, 2012. Modbus Application Protocol Specification V1.1b3, 2012. Hopkinton, EUA.
Modbus Organization, 2006. Modbus Messaging on TCP/IP Implementation Guide V1.0b. Hopkinton, EUA.
National Institute of Standards and Technology - NIST, 2011. Guide to Industrial Control Systems (ICS). Gaithersburg,
EUA.
Moraes, C. e Castrucci, P., 2007. Engenharia de Automação Industrial. Editora LTC, São Paulo, Brasil.
Miller, B. e Rowe, D., 2012, A Survey of SCADA and Critical Infrastructure Incidents. 13th ACM Conference on
Information Technology. Calgary, Canadá, pp. 51-56.
Tofino Security, 2012. Understanding Deep Packet Inspection for SCADA Security. Vancouver, Canadá.

236
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

SISTEMA RECONFIGURÁVEL PARA AQUISIÇÃO DE

SINAIS DE ELETROCARDIOGRAMA

Marcel Seiji Kay e Fábio Iaione

Faculdade de Computação – Universidade Federal de Mato Grosso do Sul
Cidade Universitária – Caixa Postal 549 – CEP: 79070-900

RESUMO
Os Smartphones com sistema operacional Android representam atualmente 75% dos celulares vendidos no mundo. Uma
tecnologia amplamente presente nos Smartphones é o Bluetooth, que consiste em uma especificação para comunicação
sem fio baseada em rádio frequência. Ultimamente, diversos sistemas para utilização na área médica (m-health)
aproveitam os recursos dos Smartphones, sendo que um dos exames médicos mais realizados é o eletrocardiograma
(ECG), o qual é efetuado de forma não invasiva e visa diagnosticar diferentes doenças cardíacas. O objetivo deste
trabalho é desenvolver um sistema embarcado reconfigurável para aquisição de sinais de ECG e um software para
visualização e armazenamento destes sinais obtidos em um Smartphone com SO Android. A comunicação entre o sistema
de aquisição e o smartphone será realizada via Bluetooth. Para os testes preliminares foram captados sinais de ECG reais
através de 3 eletrodos descartáveis e o sistema funcionou satisfatoriamente. Através da FPAA obteve-se grande
flexibilidade - pois através da reconfiguração é possível reduzir os riscos de projeto e permitir a atualização em campo - e
confiabilidade.

PALAVRAS-CHAVE
Sistema Embarcado, Eletrocardiograma, FPAA, Bluetooth, Microcontrolador.

1. INTRODUÇÃO
A popularização dos Smartphones - aliado ao aumento da expectativa de vida da população, o qual requer
maiores cuidados de saúde - possibilitaram o desenvolvimento de sistemas para utilização na área médica,
conhecida pelo termo m-Health. Existem diversos trabalhos na área, como por exemplo: uso de um
Smartphone com um adaptador acoplado ao aparelho para exames oftalmológicos, englobando miopia,
hipermetropia, astigmatismo e catarata (Pamplona et al. 2010; Pamplona et al. 2011), desenvolvimento de um
oxímetro de dedo de baixo custo (utilizado para medir a quantidade de oxigênio presente no sangue)
(Khandoker & Palaniswami. 2010), estetoscópio utilizando o microfone do Smartphone (Domenech-Asensi
et al. 2006), ultrassonografia e, um microscópio e um espectrômetro que utilizam a câmera embutida do
dispositivo móvel (Mertz. 2012).
Um dos exames médicos mais realizados é o eletrocardiograma (ECG), o qual é efetuado de forma não
invasiva e permite o diagnóstico de diferentes doenças cardíacas, possibilitando um tratamento prévio para
evitar problemas mais graves. Através de eletrodos fixados no paciente, os sinais bioelétricos gerados pela
atividade eletroquímica das células cardíacas são captados, permitindo ao médico a análise posterior de certas
informações do coração do paciente. A Tabela 1 apresenta as características de diversos biopotenciais, onde
observa-se que os potenciais elétricos de ECG possuem uma amplitude baixa, na faixa de 0,05 a 3 mV. Vale
ressaltar que a largura de banda do sinal a ser captado deve ser definida conforme a aplicação, podendo variar
entre: 0,05 - 100 Hz (registro das 12 derivações), 0,50 - 50 Hz (monitoramento do ECG dinâmico), 17 Hz
(para a determinação da frequência cardíaca) e 250 Hz (para obter ECGs com maior resolução).

237
ISBN: 978-972-8939-96-0 © 2013 IADIS

Os sistemas eletrônicos que realizam exames de ECG consistem basicamente de um estágio analógico
(amplificação e filtragem do sinal) e um estágio digital (digitalização do sinal). Durante o processo de
aquisição de sinais de ECG, geralmente necessita-se ajustar os níveis de amplificação e sintonizar a largura
de banda. Para isso, podem ser utilizados componentes analógicos discretos ou uma Field Programmable
Analog Array (FPAA), na qual implementa-se, de forma reconfigurável, todo circuito eletrônico necessário
para o condicionamento do sinal de ECG.
Neste sentido, o objetivo deste trabalho é desenvolver um sistema embarcado para aquisição de sinais de
ECG, composto por um módulo microcontrolado (responsável pelo condicionamento, digitalização e
transmissão dos sinais captados via Bluetooth) e um software, para a visualização e armazenamento destes
sinais obtidos em tempo real, através de um Smartphone com sistema operacional Android. O SO Android
foi escolhido pelo fato deste SO representar 75% do mercado mundial (existem cerca de 900 milhões de
Android ativos) (Google. 2013).
Tabela 1. Características dos biopotenciais.
Biopotencial Faixa de frequências (Hz) Faixa de amplitudes (mV)
Eletrocardiograma 0.01 – 100 0.05 – 3
Eletroencefalograma 0.1 – 80 0.001 - 1
Eletro-oculograma 0.01 – 10 0.001 – 0.3
Eletromiograma 50 – 3000 0.01 - 100

2. TRABALHOS CORRELATOS
Existem na literatura, poucos trabalhos que tiveram como objetivo a utilização da FPAA para o
desenvolvimento de sistemas m-Health aplicados à aquisição de sinais de ECG.
Em (Grzechca. 2010) realizou-se uma pesquisa para incentivar os alunos no desenvolvimento de um
detector do complexo QRS em hardware (para detecção de arritmias). Para isso, foram utilizados uma
FPAA, um osciloscópio e um computador. Através da FPAA, as seguintes funções analógicas foram
implementadas: filtro passa-faixa, retificador e comparador. A partir destas funções, os alunos avaliaram
sinais de ECG reais no osciloscópio conectado ao computador, resultando em 85% de sucesso nos testes.
O trabalho (Rodríguez. 2006) desenvolveu um sistema embarcado de baixo custo e consumo, para a
aquisição de sinais elétricos do coração. O sistema é composto por um microcontrolador, uma FPAA e um
módulo para transmissão dos sinais de ECG para o computador. Este último permite a visualização e o
armazenamento de sinais de ECG, os quais podem ser transmitidos pela Internet para um médico avaliar
remotamente. Através de testes realizados, constatou-se que o sistema desenvolvido apresenta sinais de ECG
com características de forma, amplitude e período similares ao eletrocardiógrafo Siemens E350, validando
portanto, o correto funcionamento do sistema.
Os trabalhos (Morales. 2011, Morales. 2013) apresentam um sistema para aquisição de
eletrocardiograma, baseado nos seguintes dispositivos reconfiguráveis: FPAA e FPGA. A FPAA é
responsável pela aquisição e condicionamento do sinal analógico de ECG, enquanto que o FPGA permite o
processamento de sinais digitais, além de transmitir a configuração dos blocos analógicos para a FPAA. Nos
testes realizados, a plataforma reconfigurável apresentou desempenho considerável com diferentes tipos de
eletrodos. Vale ressaltar que a reconfigurabilidade do sistema permitiu a realização da extração do
eletrocardiograma fetal de forma não invasiva, o qual é eficaz para monitorar a oxigenação do coração e do
cérebro do feto, sendo este, desconhecido pela maioria das gestantes.

3. MATERIAIS E MÉTODOS
Primeiramente foram selecionados os dispositivos a serem utilizados: microcontrolador (MCU), FPAA,
módulo Bluetooth e Smartphone. O MCU selecionado foi o C8051F320 (Silicon Laboratories. 2006) que é
um dispositivo de 8 bits com núcleo compatível com o conjunto de instruções da família MCS-51. Esse
núcleo possui um pipeline que permite a execução de 70% das instruções em 1 ou 2 ciclos de clock,
proporcionando uma aceleração de aproximadamente 12 vezes em relação ao núcleo original MCS-51, para

238
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

um mesmo clock. Além dos recursos disponíveis nos MCUs da família MCS-51, o C8051F320 apresenta
ainda em seu interior: oscilador de 24,5 MHz, memória de dados (RAM) de 2304 Bytes (256 B originais, 1
kB extra e 1 kB para FIFO da USB), memória de programa (FLASH) de 16 kB programável no sistema,
portas seriais SPI e SMBus, controlador/transceptor USB 2.0, 2 temporizadores/contadores de 16 bits
adicionais, matriz de contadores programáveis de 16 bits com 5 módulos de captura/comparação, conversor
A/D (10 bits, 200 ksps, 17 entradas multiplexadas), referência de tensão de 2,44 V para o conversor A/D,
regulador de tensão de 3,3 V, detector de brown-out, sensor de temperatura, 2 comparadores de tensão e
crossbar que permite configurar a função de cada pino de E/S do microcontrolador. O invólucro do MCU é
do tipo SMD (LQFP) de 32 pinos e foi soldado em uma placa adaptadora para DIL (passo de 2,54 mm)
permitindo sua utilização em matriz de contatos.
A Field Programmable Analog Array (FPAA), que permite a reconfiguração dos componentes analógicos
presentes em seu interior (é semelhante a um Field-Programmable Gate Array (FPGA), mas com blocos
analógicos), selecionada foi a AN221E04, esta funciona com 5 V e permite que seja reconfigurada
dinamicamente (totalmente ou parcialmente), durante sua operação. Outras características relevantes são: 4
blocos analógicos configuráveis em uma matriz 2x2, 4 células configuráveis de E/S, 2 células dedicadas para
interface de saída, 1 tabela LUT (Look-up-table), 1 conversor A/D de 8 bits do tipo SAR (Successive
Approximation Register), 1 bloco de osciladores e 1 bloco de interface de configuração. O aplicativo
fornecido pela fabricante permite que diversos circuitos analógicos sejam projetados e implementados,
através de vários Configurable Analog Modules (CAM) selecionados no projeto. Vale ressaltar que cada
CAM implementa uma função analógica. A partir disso os arquivos de dados necessários são gerados para a
configuração da FPAA. O armazenamento da configuração de uma FPAA é feita na memória on-chip
(SRAM).
O módulo Bluetooth HC-05 permite a comunicação serial sem fio de forma transparente. Ele é um
Bluetooth v2.0 + EDR (Enhanced Data Rate) com 3 Mbps e modulação de 2.4 GHz. As principais
especificações são: interface UART (níveis TTL), baixo consumo de energia, antena integrada e tensão de
alimentação de 3.3 V. O Smartphone utilizado foi o Samsung I9250.
Para a programação em C do MCU foi utilizado o ambiente integrado de desenvolvimento (IDE) Silicon
Laboratories 4.50, instalado no sistema operacional Windows 8. Esta IDE permite criar programas para
MCUs da família MCS-51 utilizando-se o compilador open-source Small Device C Compiler (SDCC).
A Figura 1 mostra o diagrama de blocos do sistema, que foi montado em matriz de contatos para a
realização de testes. O invólucro da FPAA é do tipo QFP (SMD) e portanto foi necessário construir uma
placa de circuito impresso adaptadora que permitisse a utilização em uma matriz de contatos (QFP para DIL).
O layout dessa placa adaptadora foi feito no aplicativo KiCad e a fabricação da placa foi executada em uma
prototipadora ProtoMat E33. Para a transferência dos firmwares para o MCU utilizou-se um firmware
bootloader – que ocupa 5 kB da memória FLASH do microcontrolador e permite a gravação de firmwares
utilizando-se a porta USB do computador -, e o aplicativo USBbootloader instalado em um IBM-PC
(Windows 8), sendo ambos fornecidos pelo fabricante do microcontrolador. O firmware bootloader foi
gravado previamente no microcontrolador utilizando-se o adaptador/gravador serial EC2 (Silicon
Laboratories).

Figura 2. Diagrama de blocos para o módulo de aquisição de ECG. Observa-se que o sistema será alimentado com uma
bateria de 9 V e o processamento dos sinais de ECG será realizado através de uma FPAA e um MCU.
Para a análise inicial dos sinais captados pelos eletrodos utilizou-se um osciloscópio virtual (National
Instruments MyDaq) conectado a porta USB de um notebook.

239
ISBN: 978-972-8939-96-0 © 2013 IADIS

4. RESULTADOS E DISCUSSÃO
A Figura 2 mostra o módulo NI MyDAQ, a matriz de contatos com os dispositivos utilizados e os eletrodos
usados no teste. Existem dois leds, sendo um utilizado para demonstrar que a FPAA foi configurada
corretamente e o outro para realizar testes do código. Dois push-buttons estão presentes, um para reiniciar o
microcontrolador e o outro para entrar no modo bootloader. O módulo HC-05 está configurado para
transmitir a uma taxa de 9600 bits/s, sendo testado a partir da transmissão de valores que foram recebidos
corretamente no Smartphone, através de um aplicativo desenvolvido para Android 4.1.
O sinal de ECG é enviado pelo módulo de aquisição e recebido pelo smartphone a uma taxa de 9600
bits/s, onde cada amostra será composta de 10 bits. O conversor A/D estará trabalhando a uma taxa de 480
amostras/s, resultando portanto, em uma taxa de transmissão de 4800 bits/s, ou seja, a perda de amostras não
comprometerá as informações cardíacas.

Figura 2. À esquerda está o módulo NI MyDAQ, no centro a matriz de contatos com os dispositivos utilizados no projeto
e à direita, os eletrodos aplicados nos testes.
A configuração da FPAA (Figura 3 esquerda) foi criada no aplicativo AnadigmDesigner2, onde foram
utilizados os seguintes módulos: entrada diferencial com filtro passa-baixas (Fcorte = 76 kHz e ganho = 128)
e um filtro bilinear (com clock = 1500 kHz, Fcorte = 1.5 kHz e ganho = 10). Através do AnadigmDesigner2
foi gerado um arquivo de configuração contendo os Bytes necessários para configurar a FPAA. Esses Bytes
foram inseridos no firmware do microcontrolador na forma de um vetor, permitindo que este configure a
FPAA.
A Figura 3 (direita) mostra o software Oscilloscope, fornecido juntamente com o dispositivo NI MyDAQ,
que foi utilizado para observar o funcionamento da configuração carregada na FPAA.

Figura 3. Configuração feita no software AnadigmDesigner2 e utilizada pela FPAA durante os testes (esquerda). Sinal
presente em um pino de saída da FPAA mostrando o sinal de ECG real captado por eletrodos em um indivíduo (direita).

240
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

5. CONCLUSÃO
Dado o exposto, percebe-se que o trabalho apresentado utilizou dispositivos analógicos reconfiguráveis
(FPAA) para captar os sinais do coração, os quais possuem baixo grau de amplitude (cerca de 3 mV). Apesar
das vantagens geradas pela FPAA, poucos trabalhos utilizando-a são encontrados na literatura.
Como o trabalho encontra-se em andamento, a reconfiguração da FPAA não foi amplamente explorada (a
flexibilidade proporcionada pela FPAA possibilita alterar o ganho de amplificadores, frequências de corte de
filtros e até mesmo o circuito de condicionamento do sinal). Com isso, os próximos passos do trabalho são:
permitir que várias derivações de ECG sejam medidas (a escolha da derivação desejada será feita a partir do
Smartphone), digitalização e envio dos sinais captados para o Smartphone via Bluetooth (para serem
visualizados no Smartphone), armazenamento dos sinais captados na memória do Smartphone (permitindo
que seja enviado pela Internet para algum médico analisar os dados), identificar o pacote perdido durante a
transmissão e retransmití-lo (via software), realizar um estudo comparativo com eletrocardiógrafos
comerciais para validar o sistema confeccionado neste trabalho e expandir o sistema para captar sinais de
EEG e EMG.

REFERÊNCIAS
Anadigm. (2003), AN221E04 Datasheet, (Internet), Anadigm, Available from <
http://www.anadigm.com/_doc/DS030100-U006.pdf> (Accessed 18 June, 2013)
Domenech-Asensi, G. and Martinez-Alajarin, J. and Ruiz-Merino, R. and Lopez-Alcantud, J.A. (2006), Synthesis on
FPAA of a Smart Sthetoscope Analog Subsystem, Field Programmable Logic and Applications, 2006. FPL '06.
International Conference on pages 1-5
Google. (2013), Google I/O 2013 - Keynote, (Internet), Google, Available from <http://youtu.be/9pmPa_KxsAM>
(Accessed 12 June, 2013)
Grzechca, D. and Rutkowski, J. (2010), The use of FPAA in Signal Processing Laboratory for Biomedical Engineering
Students, The International Conference on Singnals and Electronic Systems, 2010 on pages 453-456.
Khandoker, A.H. and Black, J. and Palaniswami, M. (2010), Smartphone-based low cost oximeter
photoplethysmography, Electrical and Computer Engineering (ICECE), 2010 International Conference on.
International Conference on pages 634-637
Mertz, L. (2012), Ultrasound? Fetal Monitoring? Spectrometer? There's an App for That!: Biomedical Smart Phone Apps
Are Taking Healthcare by Storm, Pulse, Vol. 3 March, pp16-21, IEEE
Morales, D. et al. (2011), Flexible ECG acquisition system based on analog and digital reconfigurable devices, Sensors
and Actuators A: Physical, Vol. 165, n. 2, pp. 261-270, 2011.
Morales, D. et al. (2013), An application of reconfigurable technologies for non-invasive fetal heart rate extraction,
Medical Engineering & Physics, Vol. 35, n. 7, pp. 1005-1014, 2013.
Pamplona, V. et al. (2010), NETRA: Interactive Display for Self-evaluation of an Eye for Visual Accommodation and
Focal Range, Special Interest Group on Graphics and Interactive Techniques (SIGGRAPH), 2010 International
Conference on.
Pamplona, V. et al. (2011), CATRA: Cataract Probe with a Lightfield Display and a Snap-on Eyepiece for Mobile
Phones, Special Interest Group on Graphics and Interactive Techniques (SIGGRAPH), 2011.
Rodriguez, P. et al. (2006), Diseño de un microsistema para adquisición de señales cardiacadas usando fpaas, IBERCHIP,
2006, International Conference on.
Silicon Laboratories. (2006), C8051F320, (Internet), Silabs, Available from
<http://www.silabs.com/Support%20Documents/TechnicalDocs/C8051F320-Short.pdf> (Accessed 16 June, 2013)

241
Artigo de Reflexão
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

UMA PROPOSTA DE SOFTWARE PARA PUBLICAÇÃO DE

PROCEDIMENTOS DE SUPORTE À INFORMÁTICA NOS
PADRÕES DA WEB SEMÂNTICA

Matheus Dimas de Morais e Diego da Silva Sales

Instituto Federal Fluminense
Bom Jesus do Itabapoana - RJ

RESUMO
Os setores de Tecnologia da Informação (TI) são cada vez mais comuns em empresas de diversos portes e ramos de
atividades. Geralmente, estes setores, auxiliam principalmente no aumento do desempenho operacional e na redução de
custos dessas empresas, tornando-as mais competitivas. Neste contexto, é primordial ter todos os equipamentos de
informática em pleno funcionamento, para isso, frequentemente os setores de TI, estão utilizando os chamados
Procedimentos de Suporte à Informática (PSI), que facilitam e agilizam o suporte desses equipamentos. Este artigo
apresenta uma proposta de software, que tem como objetivo possibilitar aos setores de TI a publicação de seus PSI
utilizando as tecnologias da web semântica como o Resource Description Framework (RDF), que permite publicar os
dados em uma estrutura padrão, e a Ontologia, que provê sentido (semântica) aos dados publicados. Este software
permitirá cadastrar e consultar diversos tipos de PSI, tais como: instalações, desinstalações, configurações e suportes de
hardwares e softwares, correções de erros e normativas. Além disso, com a tecnologia RDF, o software proposto, poderá
ser integrado a outros softwares que possuam a mesma tecnologia, o que resultará em buscas mais precisas e agregação
de dados adicionais através dos RDF Links.

PALAVRAS-CHAVE
Procedimentos de Suporte à Informática, Web Semântica, RDF, Ontologia.

1. INTRODUÇÃO
Atualmente, empresas dos mais diversos portes e ramos de atividades, possuem um forte relacionamento com
seus setores de Tecnologia da Informação (TI). Para permanecerem competitivas no mercado, as empresas,
buscam informações instantâneas e isso se torna possível através de equipamentos de informática. Sales et al.
(2009) ratificam que, além de otimizar a eficiência e eficácia das empresas, os setores de TI, também tem o
papel de obter vantagens competitivas, de forma que, as informações sejam mais precisas e dinâmicas afim
de auxiliar as tomadas de decisões. Entretanto, quanto mais equipamento de informática a empresa possui,
maior é a demanda por suporte aos mesmos. Qualquer que seja o ramo de atividade da empresa, o maior
desafio de seu setor de TI, é manter seus equipamentos de informática em total funcionamento e com isso
seus funcionários em plena produtividade. Contudo, por diversas vezes, os profissionais de TI se veem diante
de problemas nos quais não possuem conhecimentos específicos para solucioná-los, uma vez que existem
inúmeros hardwares e softwares novos todos os dias. Desta forma, este profissional, necessita de uma ampla
experiência, para adquirir um know-how e fornecer um suporte satisfatório, pelo menos, no que diz respeito
aos hardwares e softwares na empresa em que trabalha.
Uma das soluções para o problema descrito é a criação de Procedimentos de Suporte à Informática (PSI).
Nestes procedimentos há uma gama de soluções previamente cadastradas e categorizadas manualmente, o
que facilita o suporte que o profissional de TI irá fornecer. Todavia, a variedade de procedimentos é extensa e
encontrar um procedimento pode se tornar uma tarefa árdua (MAGALHÃES & PINHEIRO, 2007). Diante
desse cenário, é pertinente propor o desenvolvimento de um software que cadastre e categorize tais
procedimentos, permitindo a recuperação posterior dos mesmos de forma rápida e eficiente. O software
proposto inova no que tange o processo de cadastro e publicação dos PSI’s, utilizando algumas tecnologias
da web semântica como o Resource Description Framework (RDF) e a Ontologia. Os RDFs são modelos

245
ISBN: 978-972-8939-96-0 © 2013 IADIS

utilizados para representar dados de forma estruturada em conjuntos de triplas: sujeito-predicado-objeto. Para
publicação de dados em RDF se faz necessário também aplicação de uma ontologia, que pode ser descrita
como conjuntos de termos que serve para dar sentidos (semântica) aos dados representados pelas triplas RDF.
Nesse artigo, o objetivo é propor o desenvolvimento de um software, para cadastro e publicação de PSI,
utilizando tecnologias de web semântica. Espera-se que, com a utilização das tecnologias da web semântica,
os resultados obtidos pelo software sejam mais eficazes e eficientes.

2. WEB SEMÂNTICA
A web como é conhecida, foi construída para publicar informações visando às pessoas, consequentemente,
não houve a preocupação de estruturar estas informações para que os computadores pudessem entender o que
estava sendo publicado. Com isso, a web atual, permite aos computadores exibirem as informações
publicadas e não compreendê-las (JACYNTHO, 2012).
Segundo Berners-Lee, Hendler e Lassila (2001), a web semântica, é uma ampliação da web atual, que
livre da forma em que se apresentem, fomentam acessar, compreender e gerir informações disponibilizadas
na web, seguindo os padrões da W3C. A web semântica tem por objetivo auxiliar os computadores a
interpretar informações. Neste paradigma, as informações são publicadas de forma estruturada, permitindo
que os computadores, através de ferramentas, possam processar e compreender as informações.

2.1 Resource Description Framework e Ontologia

O RDF é um padrão criado pela W3C para publicar dados na web de maneira estruturada em formato de
triplas (sujeito – predicado – objeto). De acordo com Heath e Bizer (2011), qualquer dado pode ser publicado
em formato de triplas, permitindo que, independente de sistemas e domínios, esses dados sejam
compartilhados e reusadas por toda a web, uma vez que todas os dados estão descritos sob um mesmo
modelo.
Uma vez que os dados estão representados de maneira estruturada com RDF, é necessário que se dê
sentido a esses dados, para que o computador consiga, enfim, compreender o que está sendo publicado.
Lichtnow et al.(2010) relatam que as ontologias vêm suprir a necessidade, normalmente descritas em
RDFSchema ou OWL, elas provem termos para serem usados nas representações das informações descritas
em RDF, fornecendo informações adicionais que permitem ao computador agregar novos conhecimentos.

3. PROCEDIMENTO DE SUPORTE À INFORMÁTICA

A falta de procedimento implica em erros, atrasos e perdas para as empresas, uma vez que um computador
central de rede sem funcionar, implica em diversos funcionários parados, gerando perdas para a empresa
(CAMPOS, 2004). Assim como em qualquer setor, os procedimentos são fundamentais para os profissionais
de TI, uma vez que as experiências nas resoluções de problemas serão registradas e compartilhadas por todos,
além da padronização dessas ações.
Quando um problema é resolvido por um profissional de TI, o mesmo deve compartilhar a solução
encontrada com os demais profissionais, com isso, assim que problemas similares forem surgindo, as
soluções serão rapidamente resolvidas. Magalhães e Pinheiro (2007) afirmam que, os procedimentos
precisam seguir um padrão, para que se consiga identificar com rapidez o problema tratado, e ainda que são
relevantes informações como: setor destinado, software aplicável, dentre outros.

246
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

4. O SOFTWARE PROPOSTO
O software será desenvolvido para ambiente web usando a linguagem de programação Java com o framework
Jena 2.10. Esta linguagem é orientada a objetos, portável e possui seu código fonte sob a licença Gnu
General Public License (GPL). Segundo The apache foundation (2013), o framework Jena é utilizado para
desenvolvimento de softwares na web semântica, possuindo também licença GPL. O Jena possui diversos
métodos implementados, dentre eles: leitura e escrita de documentos RDF, navegação entre documentos
RDF, pesquisas usando SPARQL (Linguagem de consulta para dados em RDF). Esse projeto se divide em
duas etapas bem definidas e obrigatoriamente sequenciais, como segue:

4.1 Ontologia de Domínio

Para apresentar os dados de modo estruturado, é preciso descrevê-los em RDF. Entretanto, para que o
computador compreenda-os, se faz necessário uma ontologia. Assim, deve-se ter uma ontologia que
represente o domínio de PSI, ou seja, tem-se que encontrar uma ontologia que possua todos os termos
necessários para representar os dados contidos em um PSI.
Na pesquisa literária, onde foi pesquisado na base SCOPUS e ISI Web of Knowledge por artigos que
tratassem de criação de ontologias, foram feitas buscas em títulos, resumos e palavras-chaves, utilizando
como critério de busca a seguinte cláusula: (ontology OR “semantic web”) AND “ontology creation”.
Complementando essa pesquisa, também foram feitas buscas por diversos termos (procedure, process, IT
procedure, IT process, workflow, entre outros) no buscador SWOOGLE, buscador que se propõe encontrar os
termos pesquisados em diversas ontologias publicadas na web, e na Linked Open Vocabularies (LOV).
Notou-se como resultado dessas pesquisas, que ainda não existe uma ontologia que represente o domínio
deste projeto, que é o PSI. Todavia, como não há uma ontologia representativa disponível pra reuso, será
necessário desenvolver uma ontologia própria. Esta será descrita utilizando Web Ontology Language (OWL),
que é uma linguagem para definir e instanciar ontologias na web, sendo um dos principais produtos deste
projeto. Cabe ressaltar que uma ontologia não se limita à um software, ela pode ser reusada por outros
softwares que estejam tratando do mesmo domínio.
Essa ontologia deve representar todos os dados contidos em uma PSI, como software, hardware mínimo,
data de criação e publicação, quem criou/aprovou/solicitou o procedimento, os passos que devem ser
executados, cópias de arquivos necessários para a execução do procedimento, permissões a serem dadas em
pasta ou arquivos, restrições e requisitos que devem ser observados antes da execução do procedimento, entre
outros tantos dados que serão mapeados no decorrer do desenvolvimento da ontologia.
No final, com a ontologia pronta, espera-se que está tenha condições de responder algumas questões, tais
como:
• Qual procedimento de instalação de um determinado software?
• À qual regional ou setor esse procedimento é válido?
• Para a execução do procedimento, é necessário instalar softwares adicionais?
• Qual a configuração mínima de hardware para executar o procedimento?
• Esse procedimento tem alguma restrição?
• Quando e quem criou esse procedimento?
• Esse procedimento está relacionado com outro procedimento?
Para o desenvolvimento dessa ontologia, será utilizado como modelo metodológico o guia Ontology
Development 101, descrito em Noy e McGuinness (2001). Este guia consiste basicamente em dividir o
processo de desenvolvimento de ontologias em 7 (sete) etapas:
• Determine o domínio e o escopo da ontologia;
• Considere o reuso de ontologias existentes;
• Enumere o termos importantes da ontologia;
• Defina as classes e a hierarquia de classes;
• Defina as propriedades das classes;
• Defina as restrições;
• Crie instâncias.
Assim, espera-se que a ontologia criada neste trabalho sirva tanto para o software aqui proposto, quanto
para reuso em outros softwares que trabalhe dentro do mesmo domínio.

247
ISBN: 978-972-8939-96-0 © 2013 IADIS

4.2 Formulário de Cadastro

Posteriori a criação da ontologia que represente os dados do PSI, será desenvolvido o software web contendo
um formulário de cadastro. Este formulário receberá todos os dados do PSI e por fim publicará esses dados
em RDF, com ligação automática (RDF Link) e com dados contidos na Linked Open Data (LOD) que
incrementa consideravelmente a quantidade de informações sobre o PSI, uma vez que os RDF Links
permitirão que se agregue novas informações, de fontes de dados diferentes, de grande valor sem que haja
inserção manual, aumentando o poder e valor deste software. O mesmo contará também com um módulo de
pesquisa, que será útil na localização dos PSI já cadastrados e utilizará SPARQL como linguagem de busca.
Embora o projeto esteja em fase de pesquisa, podem-se identificar algumas informações importantes e
comuns a todos os PSIs, dentre elas: título do procedimento, tipo do procedimento (instalação, desinstalação
etc.), qual software e hardware se aplica, qual a compatibilidade do sistema operacional, quem criou, alterou
e aprovou o procedimento, os requisitos físicos e lógicos para realização do procedimento. Com o decorrer
deste projeto, espera-se mapear os principais dados que devem estar contidos num PSI, para desenvolver um
software que atenda às necessidades dos profissionais de TI.

5. CONCLUSÃO
O software proposto poderá ser usado em diferentes contextos, de uma intranet empresarial com PSI próprios
até mesmo como fórum.
Como este software utiliza tecnologias da web semântica, todos os dados cadastrados estarão
estruturados, permitindo buscas precisas usando SPARQL. Outra vantagem é a utilização da LOD de forma
automática, com esta tecnologia, o software terá mais informações do que as cadastradas previamente, pois
reusa dados de outras bases existentes. Ainda sobre as vantagens, outra importante é que através das
ontologias, o computador compreende os dados, possibilitando que o mesmo insira novas informações além
das cadastradas. Finalizando, destaca-se o acesso a todas as fontes de dados de forma padrão, sem precisar de
um novo formato de dados para cada nova fonte da qual está sendo acessada, sendo assim, o
compartilhamento e reuso de dados são facilitados em escala mundial.
Espera-se que este software sirva como base para outros softwares que tenham como foco o
compartilhamento e publicação de informações relevantes na área de TI.

REFERÊNCIAS
Berners-Lee, T.; Hendler, J.; Lassila, O. 2001, The Semantic Web: Scientific American. Scientific American, May 2001.
Campos, V. F. 2004, Gerenciamento da rotina do trabalho do dia-a-dia. Belo Horizonte: INDG.
Heath T; Bizer C. 2011, Linked Data: Evolving the Web into a Global Data Space, (1ª Edição). Synthesis Lectures on the
Semantic Web: Theory and Technology, 1:1, 1-136. Morgan & Claypool, California, US.
Jacyntho, M. D. A. 2012, Um Modelo de Bloqueio Multigranular para RDF, 277 f, Tese (Doutorado) Departamento de
Informática, Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro, Rio de janeiro, BR.
Lichtnow, D; Oliveira, J. P. M. D. et al, 2009, Relato e Considerações sobre o Desenvolvimento de uma Ontologia para
Avaliação de Sites da Área de Saúde. Cadernos de Informática, Volume 4, Número 1, 7-46 f, Instituto de Informática,
Universidade Federal do Rio Grande do Sul, Porto Alegre, Rio Grande do Sul, BR.
Magalhães, I. L; Pinheiro, W. B., 2007, Gerenciamento de Serviços de TI na Prática: uma abordagem com base na ITIL
- inclui ISO/IEC 20.000 e IT Flex, (1ª Edição), Novatec, 672 p, São Paulo, São Paulo, BR.
Noy, N. F.; McGuinness, D. L., 2001, Ontology development 101: A guide to creating your first ontology. [s.l.] Stanford
knowledge systems laboratory technical report KSL-01-05 and Stanford medical informatics technical report SMI-
2001-0880.
Sales, D.S; Romero, C.M.; Silva, F.L.C.; Cortes, J.M.R.; Carvalho, R.A. Benefícios percebidos após a implantação de um
ERP de serviços: Estudo de caso em um help desk. In: XVI SIMPEP, 2009, Baurú, Anais do XVI SIMPEP.
The apache foundation. Apache Jena. Disponível em <http://jena.apache.org/> acessado em 29/07/2013.

248
Posters
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

ESTUDO SOBRE MINERAÇÃO DE DADOS PARA

DETECÇÃO DE SPAMS EM REDES DE COMPUTADORES
UTILIZANDO TÉCNICAS INTELIGENTES

Patricia Bellin Ribeiro, Kelton Augusto Pontara da Costa, Henrique Pachioni Martins,
Miguel José das Neves, Atair Alves Camargo Junior e Victor Vavalle Rossi
Faculdade de Tecnologia de Bauru

RESUMO
Este estudo propõe a utilização de Mineração de Dados para auxiliar na detecção de eventos maliciosos que podem
causar danos no comportamento e na segurança das redes de computadores. A metodologia proposta objetiva apoiar a
correta identificação de anomalias utilizando técnicas inteligentes tais como Árvore de Decisão e Redes Neurais
Artificiais. Sendo utilizada uma base de dados pública denominada SPAMBASE para que fosse possível simular os
diferentes formas como um SPAMs pode ser apresentado, para que seja possível identificar se o dados recebido possui
característica de SPAM ou não. Nos experimentos foi utilizada a ferramenta Weka para obter os resultados desta
pesquisa.

PALAVRAS-CHAVE
Mineração de Dados, SPAM, Árvore de Decisão, Redes Neurais Artificiais

1. INTRODUÇÃO
Mineração de dados é parte do processo em KDD (Knowledge Discovery in Databases) que objetiva a
seleção das técnicas a serem utilizadas para localização de padrões nos dados, tendo como finalidade a busca
dos referidos padrões relacionados a um determinado interesse (Fayyad et al, 1996; Narendran, 2009).
Pesquisas nesta área estão sendo desenvolvidas, sendo possível destacar neste contexto a utilização de alguns
métodos como as Redes Neurais Artificiais e Processos de Mineração de Dados utilizando, por exemplo,
árvore de decisão, com o objetivo de minimizar os efeitos danosos de SPAMs.
Neste estudo, tendo uma base de dados supervisionada, ou seja, uma base que contempla os SPAMs
identificados, propõe-se na base de dados denominada SPAMBASE [3] a aplicação do processo de
mineração de dados, através da ferramenta Weka, com intuito de analisar e quantificar os tipos de SPAMs
presentes na base de dados estudada, auxiliando no processo da gerência de redes. Neste sentido, o presente
estudo aborda um processo de mineração de dados utilizando técnicas inteligentes como Árvore de Decisão e
Redes Neurais para detectar anomalias em uma base de dados rotulada, SPAMBASE.

2. MATERIAIS E MÉTODOS
O presente trabalho utiliza a base de dados SPAMBASE (Hopkins, 2013) convertida em formato de valores
(CSV – Comma Separated Values). O SPAMBASE possui cinquenta e sete atributos, como cada atributo
representa uma palavra, sendo a frequência em que esta aparece no e-mail pode determinar um SPAM
normal ou anormal. Esta base de dados contém 4.601 SPAMs, sendo, 1.813 classificados SPAMs normais e
2.232 como anormais, para analisar e quantificar os tipos de SPAMs presente na base de dados estudada. O
SPAMBASE foi criado com o objetivo de prover o estudo de melhoria nos softwares desenvolvidos para a
segurança em redes de computadores, visto que os ataques através de SPAMs com anomalias pode gerar
muito prejuízos tais como gasto desnecessário de tempo, aumento de custos, perda de produtividade,
conteúdo impróprio ou ofensivo e prejuízos financeiros causados por fraude (Fogel e Shlivko, 2010).

251
ISBN: 978-972-8939-96-0 © 2013 IADIS

Neste estudo foram utilizados todos os atributos da base de dados, uma vez que todas estas características
são relevantes para os testes. Para a normalização dos dados de entrada (Haykin, 2009) foi utilizada a técnica
Discretize disponível na ferramenta Weka e as técnicas inteligentes utilizadas foram o algoritmo (J48) árvore
de decisão e a rede neural Multi-Layear Perceptron (MLP) (Haykin, 2009).
Para a avaliação do algoritmo, foi escolhida uma ferramenta padrão da estatística, conhecida como cross
validation [5], na qual o conjunto disponível de dados é dividido aleatoriamente em um conjunto de
treinamento, com 75% do conjunto de dados, e em um conjunto de teste, com 25% do mesmo conjunto de
dados. Os exemplos são divididos em 10 partições mutuamente exclusivas, com 75% do conjunto de dados,
para treinar o algoritmo. E os 25% de elementos restantes, de cada partição, são utilizados para testar o
classificador. Repete-se esse procedimento para todas as partições. A avaliação do grau de generalização do
classificador ficará desta forma, garantida com este método.
Para avaliar o desempenho dos classificadores em pesquisas relacionadas com área, vem sendo utilizada
uma técnica de análise de resultados desenvolvida por Metz [6], chamada Curvas ROC (Receiver Operating
Characteristic)[7]. A área sob a curva ROC (Az) é um dos índices mais utilizados e representa o acerto do
sistema que está sendo analisado (classificador), ou seja, quanto maior a área, maior é o número de acertos.
Isso significa que num sistema bastante calibrado e com uma alta precisão, a curva deve estar o mais próxima
possível do canto superior esquerdo do eixo cartesiano, aumentando a área sob a curva [8][9].

3. RESULTADOS
Após a mineração de dados utilizando o algoritmo J48 foi possível obter, com base em um total 4.601
amostras, uma taxa de acerto médio de 92,76%, sendo 89,79% de acerto para classificações do tipo SPAMs
normais e 93,34% de SPAMs anormais obtendo Az igual a 0,941. O melhor resultado obtido com a rede
neural MLP possui arquitetura formada por 57 atributos de entrada, 68 neurônios na camada neural
intermediária e um neurônio na camada neural de saída e topologia com taxa de aprendizagem igual a 0,3 e
momentum igual a 0,2. Obtendo taxa de acerto nos testes igual a 93,89%, sendo que a taxa de acerto para não
SPAMs foi de 93.93% e para SPAMs foi igual a 93,78%, e com Az igual a 0.98. Mesmo utilizando todos os
atributos do SPAMBASE como entrada, os testes apresentaram bons resultados. Cabe ressaltar que foi
utilizada a técnica cross-validation para a validação dos testes (Haykin, 2009).

4. CONCLUSÕES
Atualmente muitas pesquisas na área da computação, mais precisamente em redes de computadores, estão
sendo desenvolvidas utilizando métodos de mineração de dados para identificar o comportamento da rede. A
base de dados denominada SPAMBASE, que contempla amostras de SPAMs, foi utilizada neste estudo.
Neste trabalho propomos a utilização de todos os atributos da base citada. Após a utilização do algoritmo de
árvores de decisão J48 e a rede neural MLP, foi possível obter boas taxas de acertos (92,76% para J48 e
93,89% para MLP) demonstrando assim, a vantagem do uso de técnicas inteligentes em redes de
computadores para detecção de SPAMs. Mesmo a árvore de decisão (J48) possuir uma alta taxa de acerto a
Rede Neural MLP demonstrou ser superior na detecção com taxa de acerto igual a 93,89%.

REFERÊNCIAS
Fayyad, U. M.; Piatesky-Shapiro, G.; Smyth, P., 1996. From Data Mining to Knowledge Discovery: An Overview. In:
Advances in Knowledge Discovery and Data Mining, AAAI Press.
Narendran C. R., 2009. Data Mining - Classification Algorithm – Evaluation, May 8th.
Hopkins M., Reeber E., Forman G., Jaap Suermondt , 2013. SPAMBASE,
http://www.ics.uci.edu/~mlearn/databases/spambase/
Fogel, J.; Shlivko, S., 2010. Weight Problems and Spam E-mail for Weight Loss Products Southern Medical Journal, v.
103, ed. 1, pp 31-36.
Haykin, S., 2009. Neural Networks and Learning Machines. Editora Prentice Hall, 3a. Edição, p. 936.

252
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

APLICAÇÃO DE REDES NEUROFUZZY NA AVALIAÇÃO

DO COMPORTAMENTO DO MERCADO IMOBILIÁRIO
LOCAL

Níria Borges Ferreira1, Maicon Bastos Palhano1, Gabriel Felippe1, Ruano Marques Pereira1,
Priscyla Waleska T. de Azevedo Simões1, Evelise Chemale Zancan2
e Merisandra C. de Mattos Garcia 1
1
Curso de Ciência da Computação, Universidade do Extremo Sul Catarinense, Criciúma –SC- Brasil
2
Curso de Engenharia Civil, Universidade do Extremo Sul Catarinense, Criciúma –SC- Brasil

RESUMO
A utilização das redes neurofuzzy possibilita o desenvolvimento de sistemas onde o conhecimento é representado e
processado de forma explícita com fácil interpretação. Isto ocorre devido à incorporação do conhecimento especialista
pela lógica fuzzy e capacidade de aprendizado das redes neurais artificiais. A aplicação de redes neurofuzzy realizada
consistiu no comportamento do mercado imobiliário de uma cidade do sul catarinense, a fim de se avaliar imóveis
urbanos. A tipologia de apartamento foi a escolhida para o desenvolvimento do aplicativo, pois possui uma maior
representatividade numérica em termos amostrais. Os resultados obtidos foram satisfatórios, apresentando capacidade de
generalização para resolução do problema proposto.

PALAVRAS-CHAVE
Sistemas de Arquitetura Híbrida, Redes Neurofuzzy, Mercado Imobiliário.

1. INTRODUÇÃO
As Redes Neurais Artificiais (RNA) são sistemas paralelos distribuídos capazes de solucionar problemas
complexos, cujo processamento é inspirado no funcionamento do cérebro humano. Uma RNA é composta
por unidades de processamento simples, utilizadas para computar funções matemáticas, dispostas em uma ou
mais camadas e interligadas. Sua principal característica é a capacidade de aprendizado, onde o
conhecimento é adquirido por meio de treinamento (Haykin, 2001).
Apesar desta característica, não é possível controlar o processo de treinamento da rede, tornando difícil o
acesso ao conhecimento adquirido. Desta forma, a solução do problema alcançado torna-se desconhecida e,
muitas vezes, a rede pode gerar resultados inconsistentes e até mesmo incompreensíveis. Com o objetivo de
resolver este tipo de problema é possível que seja realizada uma incorporação da lógica fuzzy as RNA, para
representação e processamento do conhecimento.
A lógica fuzzy é uma teoria que permite formalizar matematicamente as expressões da linguagem natural,
por meio da qual é possível realizar operações com palavras onde os conjuntos fuzzy são os seus valores.
Estes valores são obtidos por uma função e representam a imprecisão por meio de um grau de pertinência.
Desta forma, a imprecisão referente a uma afirmação pode ser expressa por um valor que exprime a
possibilidade desta ser correta (Klir e Yuan, 1995; Nedjah e Mourelle, 2005).
A união de duas ou mais técnicas da inteligência artificial constitui-se no desenvolvimento de um sistema
de arquitetura híbrida que compensa as deficiências de uma com os benefícios da outra. A pesquisa
apresentada consistiu no desenvolvimento de um aplicativo voltado ao mercado imobiliário, empregando
uma arquitetura híbrida onde a lógica fuzzy é incorporada a estrutura de uma rede neural artificial, conhecida
como rede neurofuzzy.

253
ISBN: 978-972-8939-96-0 © 2013 IADIS

2. REDES NEUROFUZZY NA AVALIAÇÃO DE IMÓVEIS

A pesquisa consistiu na implementação do protótipo de um aplicativo híbrido neurofuzzy, tendo-se a
modelagem das variáveis referentes ao domínio de aplicação obtida por meio de conjuntos fuzzy aplicados a
uma rede neural artificial. O desenvolvimento do aplicativo foi realizado em ambiente de programação
Delphi e os dados utilizados foram os referentes ao valor de imóveis do tipo apartamento, em oferta no
mercado imobiliário local, em conjunto com as variáveis que influenciam a geração de valores na avaliação
de imóveis.
A aquisição de conhecimento sobre a avaliação de imóveis consistiu na realização de entrevista
estruturada e desestruturada com uma especialista em engenharia de avaliações, referente as técnicas, bem
como a definição das variáveis e utilização das variáveis a serem utilizadas para obtenção dos resultados. De
acordo com os critérios estabelecidos pela engenheira avaliadora foram definidas as variáveis que possuíam
maior influência na obtenção do valor de um imóvel para que fossem empregadas na pesquisa. As variáveis
utilizadas na modelagem da rede neurofuzzy foram: área total do apartamento, número de dormitórios,
localização e qualidade. A área total do apartamento representa o seu tamanho em m2, sendo composta pelos
conjuntos fuzzy pequeno, médio e grande; número de dormitórios por apartamento (pouco, normal e muito)
definido no intervalo de 1 a 6, considerando-se 0,5 para apartamentos com suíte. A localização refere-se a
distância em metros (m) do imóvel em relação à um pólo de valorização (perto, médio e longe); a qualidade
estipula o padrão de qualidade do imóvel (inferior, média, superior), o qual foi atribuído pela especialista
como o produto entre o padrão do imóvel (1-Alto, 2-Normal e 3-Baixo) e o índice de conservação (1-
Péssimo, 2-Regular, 3-Bom e 4-Ótimo). Finalmente, o valor representa a saída do sistema, com conjuntos
baixo, médio e alto.
O modelo neural é uma estrutura de rede multilayer perceptron, gerando-se a partir dos conjuntos de
entrada e saída fuzzy, uma rede com seis camadas.

3. RESULTADOS OBTIDOS
Foram realizados testes com os dados obtidos na pesquisa, inserindo-se na rede números menores de dados a
fim de realizar uma comparação da influência que a quantidade de amostras exerce no treinamento da rede.
Conforme os resultados apresentados, foi constatado que a arquitetura definida no aplicativo por meio das
variáveis utilizadas, obtém um melhor desempenho com a utilização de uma taxa de treinamento de 0,5 em
um número 150 de épocas, obtendo assim, uma taxa de erro de 0,0706, ou seja, 7,06% (Tabela 1).
Tabela 1. Resultado dos testes
Taxa de Aprendizado Erro Médio Total Percentual de Erro Médio
20 0,079799 7,97%
50 0,07859 7,85%
70 0,077453 7,74%
100 0,076894 7,68%
150 0,070602 7,06%

4. CONCLUSÃO
A utilização de sistemas de arquitetura híbrida tem se mostrado uma alternativa válida na solução de diversos
tipos de problemas. Isto se deve ao fato de uma técnica servir como complemento da outra e ambas
compensarem suas deficiências. Nesta pesquisa a lógica fuzzy permitiu a modelagem do conhecimento mais
próximo a realidade do raciocínio do especialista, além de diminuir a quantidade de processamento
necessário para incorporação do conhecimento, bem como o tratamento da incerteza por imprecisão. O
aplicativo implementado utiliza apenas um modo de inferência e função de pertinência, desta forma, dando
continuidade ao trabalho pode-se gerar outros modelos com diferentes tipos de função e arquitetura.

254
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

REFERÊNCIAS
Haykin, S. 2001. Redes neurais: princípios e prática. Tradução: Paulo Martins Engel. Bookman, Porto Alegre, Brasil.
Klir, G. J. e Yuan, B. 1995. Fuzzy sets and fuzzy logic: theory and applications. Prentice Hall, New Jersey, EUA.
Nedjah, N. e Mourelle, L.M. 2005. Fuzzy Systems Engineering: theory and practice. Springer, New York, EUA.

255
ISBN: 978-972-8939-96-0 © 2013 IADIS

APRENDIZAGEM DA DISCIPLINA DE LINGUAGENS

FORMAIS E AUTÔMATOS FUNDAMENTADA NO
DESENVOLVIMENTO DE UM SIMULADOR PARA
MÁQUINAS DE ESTADOS FINITOS

Andre Henrique Silva, Celso Olivete Júnior, Rogério Eduardo Garcia

e Ronaldo Celso Messias Correia
Departamento de Matemática e Computação - UNESP - Universidade Estadual Paulista Julio de Mesquita Filho
Presidente Prudente, São Paulo, Brasil

RESUMO
Linguagens formais e autômatos é uma disciplina fundamental dos cursos superiores da área de computação,
especialmente daqueles que apresentam ênfase na formação científica do aluno, como é ocaso dos cursos de bacharelado
em Ciência da Computação e de vários cursos de Engenharia de Computação. O objetivo deste artigo é apresentar uma
proposta de ensino, baseado no desenvolvimento de um software, que aborda os formalismos de forma evolutiva,
utilizando uma mesma notação durante todo o processo, a qual será adicionada gradativamente de recursos que
aumentem a sua expressividade computacional, visando o acompanhamento da evolução das LFAs. O simulador
desenvolvido é baseado em uma máquina de estados finitos que atuam no reconhecimento das Linguagens Regulares
através de autômatos finitos.

PALAVRAS-CHAVE
Linguagens formais, autômatos finitos, ensino-aprendizagem.

1. INTRODUÇÃO
O estudo das linguagens formais desenvolveu-se significativamente e com diversos enfoques. Para a Ciência
da Computação, algumas aplicações destacam-se como análise léxica e sintática de linguagens de
programação, desenhos de hardware (circuitos digitais) e aplicações com linguagens naturais (MENEZES,
2000; HOPCROFT, MOTWANI e ULLMAN, 2007). O ensino de LFA engloba o estudo das várias classes
de linguagens formais – de acordo com a Hierarquia de Chomsky (CHOMSKY, 1956) – e os diferentes
formalismos (máquinas) relacionados ao reconhecimento dessas linguagens, como por exemplo, autômatos,
gramáticas e expressões regulares. Esta variedade de conceitos pode atrapalhar o aluno, visto que em cada
tópico da disciplina uma classe de formalismo é adotada (RAMOS, 2009; CHOMSKY, 1956). Uma forma de
auxiliar nesse processo de aprendizagem é através do uso de um software que simule a execução destes
formalismos. Isso permite ao aluno construir o formalismo (na forma autômatos, máquinas, gramáticas ou
expressões regulares) que reconheça uma dada linguagem, escolhida por ele mesmo, e testar o funcionamento
com palavras de entrada, as quais serão validadas pelo formalismo. Dentre os principais simuladores
utilizados em disciplinas de LFA destaca-se o JFLAP1 – uma ferramenta gráfica para criar e simular diversos
tipos de formalismos, além de converter diferentes representações de linguagens.
Nesta pesquisa, o objetivo é apresentar uma proposta de ensino, baseado no desenvolvimento de um
software, que aborde os formalismos de forma evolutiva, utilizando uma mesma notação durante todo o
processo, a qual será adicionada gradativamente de recursos que aumentem a sua expressividade
computacional, visando o acompanhamento da evolução das LFAs. É apresentado um objeto de aprendizado
desenvolvido para a simulação de autômatos e, por fim, são apresentadas as conclusões e a continuidade do
trabalho.

256
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

2. LINGUAGENS REGULARES
As Linguagens Regulares compõem um conjunto restrito de linguagens, que na hierarquia de Chomsky são
categorizadas como Tipo 3. Segundo Menezes (MENEZES, 2000), elas são oriundas de estudos biológicos
de redes de neurônios e circuitos de chaveamentos. São utilizadas no desenvolvimento de analisadores
léxicos (responsáveis pela identificação das estruturas básicas de linguagens como: identificadores, números
e palavras reservadas) de compiladores, em protocolos de comunicação e em editores de texto.

2.1 Autômatos Finitos

Segundo Menezes (2000) e Diverio e Menezes (2000), um Sistema de Estados Finitos é um modelo
matemático de sistema com entradas e saídas discretas, que assume um número finito e predefinido de

 Fita de entrada: a palavra a ser processada está armazenada e será lida pelo autômato. É composta por
estados. Um autômato finito (AF) é um sistema de estados finitos e é uma máquina composta por três partes:

células (uma para cada símbolo);  Unidade de Controle é uma unidade de leitura. Inicialmente posicionada
na célula mais à esquerda da fita. Acessa a uma célula de cada vez e movimenta-se para a direita; 
Programa ou Função de Transição ou Função Programa é a função que determina o comportamento do
autômato, conforme o símbolo lido da fita e o estado em que se encontra.
Na próxima seção é apresentada a ferramenta desenvolvida para atuar no reconhecimento das Linguagens
Regulares através de AFD e AFND.

3. O OBJETO DE APRENDIZADO DESENVOLVIDO

O objeto de aprendizagem foi desenvolvido utilizando a linguagem Java e possui um ambiente visual para
criação e simulação de AFD e AFND. O objeto de aprendizagem permite salvar e abrir autômatos
desenvolvidos anteriormente, bem como importar e exportar autômatos no formato utilizado pelo JFLAP1.
Apresenta também outras funcionalidades, como: testar múltiplas entradas, execução passo a passo e
execução direta de uma palavra. O objeto de aprendizagem não possui limitações com relação ao número
máximo de estados que possam ser criados nem limitações quanto ao tamanho da palavra de entrada a ser
analisada. O usuário possui total interação com o diagrama desenvolvido, podendo alterar o posicionamento
dos estados com a utilização do mouse, remover e/ou alterar estados e transições. Permite também a
visualização dos passos referentes ao fluxo de execução, mostrando os caminhos que vão desde o estado
inicial até um estado de aceitação ou rejeição. A seguir é mostrado um exemplo ilustrando estas
funcionalidades.

3.1 Utilizando a Ferramenta

reconhecer a linguagem formada por palavras com número par de a's e par de b's NPAR_A_B = {a nbn | n 0}.
Para ilustrar o funcionamento da ferramenta, é apresentado na Figura 1, um exemplo de um AFD capaz de

(c) todos estados e transições (d) definição de estado inicial e

(a) definindo estados (b) definindo transições
definidas final

Figura 1. Definição do AFD que reconhece a linguagem formada por palavras com número par de a's e par de b's.

1
Disponível a partir de www.jflap.org

257
ISBN: 978-972-8939-96-0 © 2013 IADIS

A seguir, é apresentada (Figura 2) a forma de realizar a simulação da palavra de entrada, que pode ocorrer
de forma direta, passo a passo ou através de múltiplas entradas.
3.1.1 Simulação: Direta, Passo a Passo e Múltiplas Entradas

(a) simulação b) simulação com múltiplas entradas (c) simulação passo a passo 1 (d) simulação passo a passo 2

Figura 2. Simulações suportadas pela ferramenta

4. DISCUSSÃO, AVALIAÇÃO E CONCLUSÕES

Primeiramente, o desenvolvimento do objeto de aprendizagem e da ferramenta proposta para sua publicação
permitiu não apenas a assimilação do conteúdo proposto aos alunos de Linguagens Formais e Autômatos e a
sua motivação. Foi possível permitir aos alunos um bom aprendizado além da disciplina, inerente à
implementação. Quanto à motivação, ficou evidente a diferença entre a turma atual (primeiro semestre de
2013) em relação a turmas anteriores: os alunos se mostraram mais motivados por ver a materialização de um
produto que pode ser utilizados por outros alunos e que serão ampliados (novas versões) em turmas futuras.
Além disso, durante o próprio desenvolvimento houve a fixação de conteúdo estritamente teórico.
Além disso, a título de avaliação, o objeto de aprendizagem proposto foi utilizado por alunos que já
cursaram a disciplina sem o uso deste. Nesse uso foi feita uma avaliação cujos resultados foram mais que
positivos -- não só pela novidade de se usar o apoio computacional oferecido, mas também por estimular
outros alunos a desenvolver novas funcionalidades, o que foi considerado como um aspecto positivo do
objeto de aprendizagem proposto.
Este artigo apresentou o resultado do desenvolvimento de uma ferramenta computacional com a
finalidade de auxiliar no processo de ensino/aprendizagem da disciplina de LFA. A ferramenta permite o
reconhecimento de palavras da classe das Linguagens Regulares, através da experimentação direta de AFDs e
AFNDS.
Pretende-se seguir esta proposta de ensino com as turmas posteriores das disciplinas de LFA e de Teoria
da Computação, objetivando incorporar formalismos relacionados a linguagens livres de contexto (tipo 2),
linguagens sensíveis ao contexto (tipo 1) e linguagens recursivamente enumeráveis (tipo 0).

REFERÊNCIAS
Aho, A., 2007. Compilers: principles, techniques, & tools. Addison-Wesley series in computer science, Pearson/Addison
Wesley: São Paulo, SP, Brasil.
Chomsky, A. N., 1956. Three models for the description of language. Information Theory, IRE Transactions on, v.2(3),
pp. 113–124.
Diverio, T. A. e Menezes, P. B., 2000. Teoria da computação: máquinas universais e computabilidade. Sagra Luzzatto:
Porto Alegre, RS, Brasil.
Hopcroft, J., Motwani, R. e Ullman, J., 2007. Introduction to automata theory, languages, and computation.
Pearson/Addison Wesley: Boston, MA, USA.
Menezes, P., 2000. Linguagens Formais e Autômatos. Sagra-Luzzatto: Porto Alegre, RS, Brasil.
Ramos, M. V. M., 2009. Linguagens formais: teoria, modelagem e implementação, Bookman: Porto Alegre, RS, Brasil.
Sipser, M., 2007. Introdução à teoria da computação. Thompson Learning: São Paulo, SP, Brasil.

258
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

SISTEMA AGENDA DE COMPROMISSOS DOS

OBJETIVOS DE DESENVOLVIMENTO DO MILÊNIO

Débora Lima1, Sérgio Rodrigues1, Rodrigo Santos1, Jano Souza1, Miriam Chaves2,
Paula Losada3 e Irene Cunha3
PESC/COPPE – Universidade Federal do Rio de Janeiro (UFRJ), Caixa Postal 68511 – CEP 21945-970 – Rio de
1

Janeiro, RJ, Brasil

2
Ministério do Planejamento, Orçamento e Gestão (MPOG), Esplanada dos Ministérios – Bloco K – 4º andar, Brasília,
DF, Brasil
3
Subchefia de Assuntos Federativo / Secretaria Relações Institucionais / Presidência da República
Praça dos Três Poderes, Palácio do Planalto, Anexo I, 1º andar – Sala 205/A Brasília, DF, Brasil

RESUMO
Em setembro de 2000, 189 nações firmaram um compromisso para combater a extrema pobreza e outros males que
afetam a sociedade. Esta promessa foi concretizada nos oito Objetivos de Desenvolvimento do Milênio (ODMs), que
devem ser alcançados até 2015. A fim de gerenciar o atendimento de metas específicas do Brasil, o Ministério do
Planejamento, Orçamento e Gestão tem investido esforços em pesquisa e desenvolvimento na área de sistemas de
informação para supervisionar as demandas nacionais dos ODMs. Nesse contexto, este artigo apresenta o sistema Web
Agenda de Compromissos – Governo Federal e Municípios (Agenda), cujo objetivo é gerenciar os compromissos
brasileiros diante do que foi estipulado pelos ODMs. A contribuição da pesquisa realizada no desenvolvimento do
Agenda está em criar um mecanismo para concretizar a adesão dos municípios e de seus governos aos ODMs, para
melhor compreensão do cenário brasileiro e de suas demandas, em uma estratégia bottom-up.

PALAVRAS-CHAVE
governo eletrônico, sistemas de informação, computação aplicada.

1. INTRODUÇÃO
Com os impactos das tecnologias Web, a expansão da pesquisa e prática em governo eletrônico vem
acontecendo com foco na construção e utilização de sistemas computacionais para a melhoria dos serviços
públicos e da qualidade de vida do cidadão (Lima et al., 2013). Nesse sentido, o Governo Federal tem
investido esforços para planejamento, controle e acompanhamento de processos que compõem as instituições
governamentais (Preti et al., 2010). No que tange aos objetivos globais para melhorar o desenvolvimento e a
qualidade de vida dos cidadãos, a Organização das Nações Unidas (ONU) propôs a Cimeira do Milênio em
setembro de 2000, cujo resultado foi a aprovação da Declaração do Milênio das Nações Unidas (ONU,
2000). Neste documento, foi definido o conjunto de oito objetivos que deveriam ser alcançados em âmbito
mundial, sendo eles: erradicar a extrema pobreza e a fome; universalizar a educação primária; promover a
igualdade entre os sexos e a autonomia das mulheres; reduzir a mortalidade na infância; melhorar a saúde
materna; combater o HIV/AIDS, a malária e outras doenças; garantir a sustentabilidade ambiental; e
estabelecer uma parceria mundial para o desenvolvimento. Para isso, indicadores sociais, econômicos e
ambientais devem ser coletados, analisados e reportados por cada nação (Murasse & Tsunoda, 2010).
Em alguns casos, o Brasil já cumpriu as metas estabelecidas em âmbito mundial, como o primeiro
objetivo acima listado (IPEA, 2010). Ainda assim, torna-se necessário que o trabalho continue para que as
demais metas específicas sejam atingidas e, para isso, surge a demanda da estruturação de sistemas
computacionais que deem suporte à coleta, integração, análise e utilização de dados em uma estratégia
bottom-up, i.e., da gestão eletrônica dos municípios para a gestão da nação, o que valoriza a melhor
compreensão do cenário brasileiro e de suas necessidades (MPOG, 2012). Neste artigo, é apresentado o
sistema Web Agenda de Compromissos – Governo Federal e Municípios (Agenda), cujo objetivo é gerenciar

259
ISBN: 978-972-8939-96-0 © 2013 IADIS

os compromissos do Brasil diante do que foi estipulado pelos ODMs. A contribuição da pesquisa realizada
no desenvolvimento do Agenda está em criar um mecanismo para concretizar a adesão dos municípios e de
seus governos aos ODMs, para melhor compreensão das demandas brasileiras.

2. SISTEMA AGENDA
Desenvolvido em uma parceria entre o Centro de Apoio a Políticas do Governo da COPPE/UFRJ (CAPGov),
o Ministério do Planejamento, Orçamento e Gestão (MPOG) e a Secretária de Relações Institucionais da
Presidência da República (SRI), o sistema Agenda tem como objetivo principal centralizar as informações
relativas às ações realizadas na esfera municipal para atender aos ODMs entre os anos de 2012 e 2016. Neste
caso, 2012 é representante da situação anterior ao mandato atual e 2013-2016 apresenta os dados estimados e
posteriormente realizados. Com o intuito de facilitar a medição e posterior análise dos dados dos indicadores,
os ODMs são estruturados da seguinte forma (Figura 1): para cada objetivo, existe um conjunto de dois a
quatro programas, cuja finalidade é ajudar a alcançar a meta do objetivo, e.g., o Objetivo 1 possui o
Programa “Bolsa Família”. Para cada um dos programas, foi escolhido um indicador que fosse representativo
e de cálculo e coleta fáceis, com o intuito de facilitar a adesão ao sistema como um todo. Este cuidado é
necessário pela natureza altamente diversificada dos municípios brasileiros e pela busca do desenvolvimento
de todos eles. Levando em conta o conjunto de indicadores escolhidos para compor o sistema Agenda, foi
necessário armazenar os seus meta-dados (e.g., formato, periodicidade, órgão responsável), além dos valores
estimados (nos anos de mandato) e realizados (anos de mandato e pelo menos um ano anterior, para fornecer
base histórica) pela prefeitura.

Figura 1. Tela apresentando um indicador relativo ao compromisso 5, composta por um texto explicativo e tabelas
exibindo o valor realizado para o ano de 2011 e os valores estimados para 2013-1016
Para realizar essas funções, é necessário que os dados dos indicadores, que são provenientes de diversos
sistemas estruturantes do Governo Federal, sejam disponibilizados de forma padronizada para realização de
cargas no sistema. Para tal, foi elaborado um par de planilhas eletrônicas (uma contendo os meta-dados dos
indicadores e outra, os dados propriamente ditos), em conjunto com o Comitê de Organização de
Informações da Presidência da República (COI-PR), que deve ser preenchido, através da extração dos dados
do respectivo sistema estruturante, pela fonte provedora do dado (i.e., o órgão responsável por sua coleta e
consolidação). Esta escolha se deu pela ampla utilização dessas planilhas no governo, além de sua fácil
visualização e manipulação. Além disso, deve-se possibilitar a inserção dos dados estimados pelos relatores
das prefeituras (i.e., prefeitos e demais servidores ligados às funções executivas do município) para cada um
dos anos do mandato. Estes usuários efetuam login através de um mecanismo de autenticação interligado ao

260
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Sistema de Convênios do Governo Federal (SICONV, 2013), ou seja, a cada tentativa de autenticação no
sistema Agenda, login e senha são enviados via serviços Web ao servidor do SICONV, que retorna
confirmando/negando a autenticidade dos dados (e a qual município eles se referem). Optou-se por utilizar o
cadastro de usuários do sistema SICONV por sua confiabilidade e por conter dados sempre atualizados.
É possível também emitir um certificado de adesão para a prefeitura, que pode ser utilizado como
documento comprobatório. Por fim, é necessário que as informações possam ser visualizadas publicamente
para facilitar o acompanhamento da população com relação ao esforço empreendido por cada uma das
prefeituras em preencher e alcançar as metas propostas para os indicadores dos ODMs. O Agenda foi
disponibilizado ao público (Agenda, 2013) e foi apresentado no Encontro Nacional com Novos Prefeitos no
dia 30 de janeiro de 2013 pela Secretária Geral da Presidência. Desde então, diversas oficinas para
divulgação e conscientização foram oferecidas de modo a ampliar o uso do sistema. O Agenda foi
desenvolvido com a tecnologia Java Enterprise Edition, fazendo uso da técnica Model Driven Architecture
por meio do framework do Ministério da Defesa e do MPOG, denominado MDArte, utilizando um banco de
dados baseado no sistema gerenciador de banco de dados PostgreSQL.

3. CONCLUSÃO
A Estratégia Geral de Tecnologia da Informação do Governo Federal vem estimulando a pesquisa e
desenvolvimento de sistemas de informação no domínio de governo eletrônico, considerando uma série de
serviços e indicadores que precisam ser geridos de maneira eficaz (MPOG, 2012). Como parte desta
iniciativa, este artigo apresentou o sistema Agenda, cujo foco está na gestão dos compromissos brasileiros
diante do que foi estipulado pelos ODMs. O Agenda está disponível ao cidadão desde janeiro de 2013. Até
setembro deste ano, mais de 2,0% dos governos municipais brasileiros já emitiram seus certificados de
adesão, ou seja, comprometeram-se a preencher as metas específicas dos indicadores durante o seu mandato.
É interessante salientar que a adesão ao sistema é opcional em relação ao seu uso – é possível que uma
prefeitura tenha preenchido as suas metas e, no entanto, não tenha emitido o certificado. Oficinas de
divulgação do sistema vêm sendo realizadas ao longo do ano e a expectativa é que o número de municípios
que optam por aderir ao Agenda cresça com a finalização do primeiro ano do mandato, quando o prazo para o
preenchimento das metas para o ano de 2013 se encerrará.
A carga inicial relativa aos valores dos indicadores no ano de 2011/2012 foi realizada sem grandes
percalços. Como estão previstas cargas de dados com periodicidade no mínimo anual, mecanismos de
automatização desse processo estão sendo pesquisados, de forma a reduzir a necessidade de intervenção
manual. Mecanismos para descoberta de conhecimento em banco de dados também serão explorados a fim de
descobrir padrões e exceções no cenário brasileiro, considerando a estratégia de gestão bottom-up.

REFERÊNCIAS
Agenda, 2013. Sistema Agenda de Compromissos – Governo Federal e Municípios. Disponível em:
<http://agendacompromissosodm.planejamento.gov.br>.
IPEA, 2010. Objetivos do Desenvolvimento do Milênio – Relatório Anual de Acompanhamento. Março de 2010.
Lima, D., Silva, R., Garcia, A., Rodrigues, S.A., Chaves, M., Santos, R.P., e Souza, J.M., 2013. Sistema para Transição
de Governos no Brasil. In IX Simpósio Brasileiro de Sistemas de Informação. João Pessoa, pp. 355-366.
MPOG, 2012. Estratégia geral de Tecnologia da Informação – 2013-2015. MPOG, versão 1.1.
Murasse, C., e Tsunoda, D., 2010. Descoberta de conhecimento a partir de uma base de indicadores de desenvolvimento
social utilizando WEKA. In II Work. de Computação Aplicada em Governo Eletrônico. Belo Horizonte, pp. 609-621.
ONU, 2000. Nações Unidas – Declaração do Milênio. Setembro de 2000.
Preti, J.P.D., Nunes, E.P.S. e Filgueiras, L.V.L., 2010. Arquitetura Crossmedia para Integração de Serviços de Governo
Eletrônico. In II Workshop de Computação Aplicada em Governo Eletrônico. Belo Horizonte, pp. 690-701.
SICONV, 2013. Sistema de Convênios do Governo Federal. Disponível em: <https://www.convenios.gov.br/siconv/>.

261
ISBN: 978-972-8939-96-0 © 2013 IADIS

ROTEAMENTO EM REDES DE COMPUTADORES

UTILIZANDO ALGORITMOS GENÉTICOS

Matheus Dimas de Morais, Wesley Folly Volotão de Souza, Anderson de Souza Lima
e Ítalo de Oliveira Matias*
Instituto Federal Fluminense, Bom Jesus do Itabapoana, RJ
Universidade Candido Mendes, Campos dos Goytacazes, RJ*

RESUMO
Este trabalho utiliza os conceitos de Algoritmos Genéticos (AGs) na tentativa de otimizar e melhorar o desempenho das
técnicas de roteamento, empregadas na interligação de redes. Para isso, foi implementado um algoritmo que analisa
vários parâmetros de rede (Número de saltos, atraso ou latência, taxa de transmissão e taxa de erro), a fim de determinar
qual o melhor caminho dada a origem e o destino. Para testar a eficácia do algoritmo, foi utilizada uma rede com onze
roteadores onde se pôde perceber que o algoritmo implementado mostrou resultados satisfatórios relativos ao encontro de
caminhos pela rede. Desta forma, foi verificado que a evolução destas técnicas pode reduzir a demanda de tempo para o
funcionamento de uma rede.

PALAVRAS-CHAVE
Algoritmos Genéticos; Roteamento; Protocolos de roteamento; Rede de Computadores; Internet.

1. INTRODUÇÃO
Atualmente, na era da informação, as pessoas se tornam cada vez mais dependentes da grande rede mundial
de computadores, a Internet. Esta é formada por um grande conjunto de diferentes redes que oferecem vários
serviços aos usuários e possui características marcantes como não ter sido planejada e nem ser controlada por
ninguém (Tanenbaum, 2003).
Na arquitetura TCP/IP, as informações são divididas em pacotes e estes são encaminhados pela Internet
através dos roteadores. Existem diversas formas de se rotear um pacote através da rede. Este artigo abordará
uma implementação de um Algoritmo Genético que irá auxiliar na busca de melhores caminhos pela rede,
levando em consideração parâmetros encontrados nos dois principais algoritmos de roteamento interno: RIP
e OSPF.

2. CONCEITUAÇÃO TEÓRICA E REVISÃO DE LITERATURA

2.1 Algoritmos Genéticos
Segundo Frestas (2007), os Algoritmos Genéticos são uma forma de programação definida por um método de
busca e otimização baseado na seleção natural que simulam a evolução das espécies. A estrutura é baseada
em cromossomos onde esses evoluem em busca da solução de um problema definido. Uma das principais
partes se resume na forma como os cromossomos serão codificados. Dependendo do problema, a forma de
codificação do cromossomo pode variar. Se tratando deste artigo, o cromossomo é codificado em uma cadeia
de bits, ou seja, é codificado de forma binária.

2.2 Camada de Rede e Roteamento

A camada de rede é a responsável pelo envio do pacote da origem até o destino, ou seja, é responsável pelo
endereçamento dos pacotes e pelo efetivo envio destes através dos diversos roteadores que integram o
caminho entre a origem e o destino. Esta tarefa é chamada de roteamento. (Maia, 2009).

262
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Maia (2009) apresenta algumas métricas de roteamento, sendo que algumas delas serão abordadas pelo
algoritmo desenvolvido para o artigo, sendo elas: Número de saltos; Taxa de transmissão ou carga da rede;
Atraso; Taxa de erro; Disponibilidade e Custo.
No contexto de protocolos de roteamento é importante observar que existem duas grandes ramificações
de protocolos. Temos o EGP (Exterior Gateway Protocols) e o IGP (Interior Gateway Protocols). O
algoritmo desenvolvido neste trabalho é classificado como do tipo IGP, pois objetiva ser utilizando dentro de
um AS (Autonomous System) sendo este por sua vez definido por Tanenbaum (2003) como redes
independentes que podem, cada uma dentro de sua fronteira, utilizar diversos algoritmos de roteamento
distintos.

3. IMPLEMENTAÇÃO DO ALGORITMO GENÉTICO

Para o desenvolvimento da aplicação, foi utilizada a linguagem de programação Java juntamente com os
conceitos de orientação a objetos. Esta linguagem se caracteriza por ser portável e poder ser utilizada
gratuitamente, pois seu código fonte está sob a licença GPL.
No AG implementado foram levados em consideração as seguintes métricas: número de saltos, atraso (ou
latência), taxa de transmissão e taxa de erro. Sendo que cada parâmetro possui um determinado peso no
contexto do cálculo do custo geral.
Inicialmente foi definida uma rede para a realização dos testes com o algoritmo. Essa rede é apresentada
na Figura 1, onde cada vértice representa um roteador.

Figura 1. Estrutura da rede escolhida para os testes. Fonte: Adaptado de Pereira, et al (2012).
No algoritmo implementado cada cromossomo define um caminho completo no grafo de 11 vértices.
Sendo assim, cada cromossomo será um conjunto de vértices, da origem ao destino. Assim sendo, serão
necessários 4 bits para discriminar um vértice. Como o exemplo proposto no artigo possui 11 vértices, são
necessários 4 bits para representar um roteador. Com isso, o exemplo de um cromossomo seria [0000 0010
0101 1000 1010].
Na etapa inicial da geração dos cromossomos esses bits são gerados aleatoriamente. O fitness de cada
cromossomo representa o custo associado ao caminho. Assim sendo, quanto menor o custo, melhor à solução
encontrada.
Para o cálculo do fitness, foi atribuido um grau de significância para cada métrica, conforme expresso na
fórmula de avaliação abaixo:
nota = (3*Atraso)+(2*Erro)+(0.1*Pulos)-(4*Transmissao) + (indisponibilidade *
Integer.MAX_VALUE);
É importante observar que cada métrica possui uma unidade de medida diferente. Sendo assim, torna-se
necessário colocar esses dados dentro de uma mesma escala para que uma métrica não influencie mais do que
a outra. Nota-se que na fórmula de avaliação apresentada, cada parâmetro possui um peso associado. Esses
pesos podem ser modificados de acordo com a utilização da rede.
Os primeiros 80% dos indivíduos da população são escolhidos para cruzamento, o restante é excluído da
próxima geração. É feito o processo de elitismo nos primeiros 20% dos indivíduos selecionados.
A próxima etapa é definir um ponto de corte para o cruzamento. A escolha dos pontos de corte foi
baseada no trabalho de Pereira et al (2012) e pode ser visualizado abaixo:
pontoCorte1 = (int) somatorioPulos / numeroIndividuos;
pontoCorte2 = pontoCorte1 + ((numeroAlelos - pontoCorte1) / 2);
Após o cruzamento é necessário escolher uma taxa de cromossomos para sofrer mutação de forma
aleatória, assim foi escolhida uma taxa de 10%.

263
ISBN: 978-972-8939-96-0 © 2013 IADIS

4. RESULTADOS
Para a realização dos testes no algoritmo genético implementado, foi utilizado o grafo exibido na Figura 1.
Para cada uma das 18 arestas foram definidos valores para os respectivos parâmetros com o objetivo de
simular uma rede real. Para avaliar a eficácia do algoritmo, o mesmo foi executado 100 vezes onde foi
analisada a nota e a geração de cada caminho encontrado. Os resultados das execuções foram classificados
em 5 categorias:
Ótimo - Custo inferior de -0,6855; Bom - Custo entre -0,6855 e 0,3145; Regular - Custo entre 0,3145 e
1,3145; Ruim - Custo acima de 1,3145; Não encontrado.
Na execução dos testes foi definido que o número máximo de gerações seria de 10000 e caso não
houvesse melhora em 1000 gerações, o algoritmo deveria ser encerrado. Foram definidos também que a taxa
de crossover seria de 80% com uma taxa de mutação de 10%. A população era constituída de 100 indivíduos
e os caminhos deveriam ser sempre do vértice 0 para o vértice 10.
Na figura 2 são apresentados graficamente os resultados dos testes classificados conforme descrito acima.

Figura 2. Gráfico dos resultados obtidos. Fonte: elaborado pelo autor.

Com base na figura 2, pode-se observar que o algoritmo obteve 99% de eficiência em encontrar um
caminho válido e que em 20% dos casos, o caminho foi classificado como ótimo; 4% como bom; 52% como
regular e 23% como ruim. Os resultados mostram um bom desempenho do algoritmo implementado, visto
que somente 6% dos caminhos encontrados foram classificados como ruim.

5. CONCLUSÃO E TRABALHOS FUTUROS

Os algoritmos genéticos podem ser utilizados como alternativa no roteamento de redes, visto que os
resultados obtidos foram satisfatórios, com a classificação da maioria dos caminhos encontrados variando
entre regular e ótimo. É relevante informar que a dificuldade do algoritmo em encontrar rotas ótimas aumenta
conforme aumenta a distância entre os nós de origem e destino.
Como trabalho futuro pretende-se testar o algoritmo em uma rede real elaborada para comparar os
resultados obtidos com os outros algoritmos que são utilizados atualmente, sendo eles o RIP, OSPF e IGRP.
Com isso, poderá ser verificada em que situações reais o algoritmo poderia ser utilizado de acordo com as
vantagens e desvantagens sobre os outros algoritmos.

REFERÊNCIAS
FREITAS, Cherze C. et al., 2007, Uma ferramenta baseada em algoritmos genéticos para a geração de tabela de horário
escolar. Sétima Escola Regional De Computação, Vitória da Conquista – BA, Brasil, [sn].
MAIA, L. P., 2009, Arquitetura de redes de computadores, LTC, Rio de Janeiro – RJ, Brasil, 230p.
PEREIRA, R. A. et al., 2012, Algoritmos Genéticos para Roteamento em Redes, Centro Universitário Nove de Julho
(UNINOVE). São Paulo – SP, Brasil, pp 6.
TANENBAUM, A. S., 2003, Redes de Computadores. 4.ed. Campus, Rio de Janeiro – RJ, Brasil, 968p.

264
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

ANÁLISE DE DISPONIBILIDADE NA COMPUTAÇÃO EM

NUVEM: WINDOWS AZURE

Diego von Söhsten e Sérgio Murilo

Escola Politécnica de Pernambuco - Universidade de Pernambuco - Recife, Brasil

RESUMO
A Computação em Nuvem desperta interesse em muitos profissionais de Tecnologia da Informação, devido ao seu
conceito inovador, que consiste em redução de custos e maior flexibilidade em infraestruturas computacionais.
Entretanto, problemas podem ocorrer em ambientes que não possuem um plano de alta disponibilidade. Este trabalho
aborda algumas das políticas de alta disponibilidade apresentadas pelo provedor de Computação em Nuvem Windows
Azure, focando em um de seus recursos, o Traffic Manager, que controla o tráfego de dados entre o usuário e a nuvem.

PALAVRAS-CHAVE
Computação em nuvem; alta disponibilidade; traffic manager; windows azure; autoscaling applcation block.

1. INTRODUÇÃO
A Computação em Nuvem consiste na hospedagem e uso de sistemas, plataformas ou infraestruturas
computacionais, também conhecidos como “nuvens”, em ambientes remotos, através de uma rede. O custo é
flexível, de acordo com os recursos alocados – de uma maneira similar ao que acontece com água e energia
elétrica [1]. O administrador da nuvem pode expandir ou reduzir os serviços utilizados a qualquer momento.
Disponível, na maioria dos casos, através da Internet, as nuvens podem ser acessadas por celulares,
computadores, sistemas embarcados, entre outros dispositivos eletrônicos. Tal abordagem é possível através
de datacenters trabalhando de forma simultânea, cooperada e integrada. Dados de cada usuário precisam estar
armazenados com redundância em múltiplos locais. Deve haver alta disponibilidade em casos de
modificações inválidas ou ataques aos servidores, usando a menor carga de processamento possível. [2]

2. TRABALHOS RELACIONADOS
Em [3], foram propostas fórmulas e equações matemáticas visando mensurar o custo real da implantação de
alta disponibilidade em uma solução em nuvem, e suas implicações. Conceitos como Hot Standby e Cold
Standby, esquemas de tolerância a falhas e suas representações em modelos de Markov, todos em nuvem,
foram abordados em [4]. Foi proposta uma técnica para selecionar o provedor em nuvem mais adequado para
hospedar uma determinada aplicação, com base no orçamento disponível e na disponibilidade necessária [5].

3. ALTA DISPONIBILIDADE NO WINDOWS AZURE

As funcionalidades do Windows Azure ficam hospedadas em um ou mais datacenters, de um total de oito
disponíveis: quatro nos Estados Unidos, dois na Europa e mais dois na Ásia [6]. O administrador da nuvem,
no momento em que solicita os serviços, seleciona qual deles hospedará os recursos.
Uma representação bastante usada, visando a alta disponibilidade em nuvem, é o modelo Hot Standby, em
cenários ativo-passivo (failover). Instâncias de serviços (réplicas) podem ser carregadas em nuvem, visando
obter alta disponibilidade. O serviço secundário está sempre executando, em paralelo ao primário, que
também está ativo [4]. Entretanto, o resultado de saída é liberado por apenas um deles, a réplica primária.

265
ISBN: 978-972-8939-96-0 © 2013 IADIS

O Windows Azure garante, de forma nativa e automática, múltiplas cópias das informações em sistemas
de armazenamento físico independentes [7]. As aplicações também podem ser publicadas em múltiplas
instâncias, embora o usuário pague pelas instâncias adicionais da mesma forma que se fossem
completamente isoladas. O recurso Autoscaling Application Block permite redimensionar a quantidade de
instâncias executando uma aplicação no Windows Azure, de acordo com regras pré-definidas. É possível, por
exemplo, aumentar a quantidade de instâncias, de forma automática, em um horário em que a aplicação esteja
sendo bastante acessada. Há uma interface de programação disponível para o uso deste recurso.

Figura 1. Exemplo de aplicação do Autoscaling Application Block.

3.1 Implantações Ativo/Passivo e Ativo/Ativo usando o Traffic Manager

Foco deste trabalho, esta funcionalidade aplica uma política às consultas DNS (Domain Name Service) no
domínio da aplicação. É possível determinar as regras que vão escolher qual o serviço que vai processar a
requisição de usuários, obtendo um maior nível de disponibilidade [8].
Há três tipos de regras que podem ser definidas: Desempenho e Round-Robin, para cenários de
implantação ativo/ativo, e Failover, para cenários ativo/passivo (onde se aplica o modelo Hot Standby,
conforme visto neste estudo). Em cada uma delas, o administrador define um endereço central para a
aplicação hospedada, e o Traffic Manager vai redirecionar o usuário em questão para o datacenter mais
adequado para ele.
Uma regra de Desempenho consiste em verificar qual dos serviços disponíveis pode processar a aplicação
no menor tempo (melhor latência de rede). Ao usar Round-Robin, é possível dividir, de forma equivalente, a
carga entre os datacenters indicados em uma sequência definida pelo administrador. Já na Failover, uma fila
também é definida pelo administrador, mas apenas o primeiro serviço listado na mesma vai processar as
requisições. Aqueles que vêm em seguida na fila serão acionados apenas quando o primeiro estiver
indisponível.
Para obter os resultados listados a seguir, foram criados três serviços em nuvem: um no datacenter de
Dublin (Irlanda), outro em Cingapura e um último em Chicago (EUA). Uma aplicação simples foi
implantada, usando as ferramentas fornecidas pelo SDK do Windows Azure. Foi calculado, na Figura 2, o
tempo de processamento, em acessos diretos, a cada um dos três serviços. Na Figura 3, um comparativo de
tempos para cada uma das três regras disponíveis no Traffic Manager.
Conforme visto na Figura 3, ao aplicar a regra de Desempenho, a aplicação foi encaminhada, boa parte
das vezes, ao serviço de Chicago, devido à melhor latência de rede e, consequentemente, o menor tempo
médio de processamento (de acordo com a Figura 2).

Figura 2. Tempos de processamento da aplicação para os Figura 3. Tempo de processamento para a aplicação usando
três datacenters selecionados. as três regras do Traffic Manager.

266
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

Ao usar Round-Robin, a fila foi definida, inicialmente na seguinte ordem: Dublin, Cingapura e Chicago.
Por isto, houve tantas oscilações – o primeiro acesso foi encaminhado a Dublin, o segundo a Cingapura, o
terceiro a Chicago, o quarto até Dublin novamente, e assim sucessivamente.
Quando a regra Failover foi aplicada, com o serviço de Chicago atuando como o principal (o primeiro da
“fila” definida pelo administrador), os tempos de processamento foram similares aos encontrados na Figura
2, quando tal datacenter foi acessado diretamente.
A Irlanda é mais próxima de Recife do que Chicago. Mas ao analisar os resultados obtidos, percebe-se
que, ainda assim, o serviço em Chicago é mais rápido. Recentemente, a Microsoft incluiu dois datacenters
nos Estados Unidos à composição do Windows Azure, totalizando quatro datacenters naquele país. É
provável que as condições de rede, assim como o hardware disponível, esteja favorecendo o serviço de
Chicago.

4. CONCLUSÕES
Este estudo apresentou a importância da alta disponibilidade em um ambiente em nuvem. Ao administrador,
cabe o conhecimento das opções fornecidas pelo provedor, para que possa montar um ambiente que esteja
disponível sempre que necessário.
Para planejar a implantação de um software, plataforma ou infraestrutura em nuvem com sucesso, é
preciso conhecer as peculiaridades do provedor escolhido, além de questões técnicas da rede, nas localidades
que hospedarão os recursos.

REFERÊNCIAS
[1] C. Vecchiola, X. Chu, e R. Buyya, 2009, “Aneka: A Software Platform for .NET-based Cloud Computing”. High
Speed and Large Scale Scientific Computing, vol. 18, pp. 267-295. Hardcover, Alemanha.
[2] V. Madhavi, R. Tamilkodi, e R.BalaDinakar, 2012, “Data Storage Security in Cloud Computing for Ensuring
Effective and Flexible Distributed System”. K.. National Conference on Research Trends in Computer Science and
Technology, pp. 2-3. Medchal, Índia.
[3] S. Pandey e S. Nepal, 2012, “Modeling Availability in Clouds for Mobile Computing”. 2012 IEEE First International
Conference on Mobile Services, pp. 80-87. Honolulu, EUA.
[4] A. Chilwan, A. Undheim, e P. E. Heegaard, 2012, “Effects of Dynamic Cloud Cluster Load on Differentiated Service
Availability”. 21st International Conference on Computer Communications and Networks (ICCCN), pp. 1-6.
Munique, Alemanha.
[5] C. Chang, P. Liu, e J. Wu, 2012, “Probability-based Cloud Storage Providers Selection Algorithms with Maximum
Availability”. 41st International Conference on Parallel Processing (ICPP), pp. 199-208. Pitsburgo, EUA.
[6] Windows Azure [online], 2013, “Windows Azure Trust Center – Privacy”. Disponível em:
https://www.windowsazure.com/pt-br/support/trust-center/privacy/ (Acessado em: 03 de março de 2013).
[7] Microsoft [online], 2013, “Business Continuity for Windows Azure”. Disponível em: http://msdn.microsoft.com/en-
us/library/windowsazure/hh873027.aspx (Acessado em: 25 de agosto de 2013).
[8] Microsoft [online], 2013, “Windows Azure Traffic Manager Overview”. Disponível em:
http://msdn.microsoft.com/en-us/library/windowsazure/hh744833.aspx (Acessado em: 12 de março de 2013).

267
ISBN: 978-972-8939-96-0 © 2013 IADIS

DESENVOLVIMENTO DO MÉTODO ICS PARA O ENSINO

DO TDAH ATRAVÉS DE FERRAMENTAS
COMPUTACIONAIS

Eduardo Seige Ianaguivara, Alex Candiago e Alessandro Pereira da Silva

Universidade de Mogi das Cruzes
Av. Dr. Cândido Xavier de Almeida Souza, 200
CEP 08780-911 - Mogi das Cruzes/SP.

RESUMO
O transtorno de déficit de atenção/hiperatividade é o transtorno neuropsiquiátrico mais comum entre crianças em idade
escolar no mundo. Pesquisadores descobriram que o uso de ferramentas computacionais podem oferecer maiores
oportunidades de sucesso para estas crianças do que o método convencional, e também melhorar suas habilidades sociais.
Entre os benefícios da intervenção por computador encontramos: feedback instantâneo, tomada de decisões rápidas e
ensino por meio da ação e não explicação. O método de jogos mais utilizado para o ensino é o serious game, entretanto
alguns autores apontam a falta do componente “diversão” ou entretenimento no processo de desenvolvimento destes
jogos. Este componente é o responsável pelo sucesso dos jogos comerciais e se faz necessário para atingir um maior
público para esta modalidade de jogos. Portanto o trabalho envolveu o desenvolvimento de um método de
desenvolvimento de jogos unindo os conceitos de GDD e serious game.

PALAVRAS-CHAVE
Transtorno de Déficit de Atenção/Hiperatividade, Aprendizado, Ferramentas computacionais

1. INTRODUÇÃO
O Transtorno de Déficit de Atenção / Hiperatividade (TDAH) é definido pela Associação Americana de
Psiquiatria (APA, 2000) como um transtorno neurobiológico caracterizado por padrões comportamentais
subdivididos em três tipos, o desatento, o hiperativo/impulsivo e o combinado. Ainda segundo a APA este
transtorno psiquiátrico é classificado como o mais comum em crianças em idade escolar (APA, 2000).
O TDAH possui um histórico escolar de abandono e insucesso escolar o que pode estar relacionado à sua
característica comportamental de isolamento que pode resultar em depressão, uso de drogas e comportamento
agressivo.
Com o aumento do uso de jogos para treinamento, simulação e ensino dúvidas quanto a sua eficácia
foram levantadas, uma vez que os jogos utilizados eram voltados apenas ao entretenimento sem seguir
qualquer método pedagógico ou psicológico. Para tanto segundo Yussof (2010) o uso do serious game pode
comprovadamente trazer benefícios ao ensino uma vez que suas entradas principais são o conteúdo
educacional, psicológico e computacional a fim de se alcançar a educação lúdica.
Diversos autores como (Pourabdollahian., et al 2012; Hauge et al 2012; Yuda, 2011) apontam os
benefícios do serious game na área da matemática, memória espacial, geometria e engenharia, este método é
o que mais entende as necessidades educacionais da atualidade. Mas, como ele diz em seu próprio projeto
este método é voltado à educação e pode deixar os componentes de entretenimento que trazem à tona muitos
jogadores em todo o mundo passarem despercebidos.
Portanto o objetivo deste trabalho é desenvolver um método que englobe as entradas do serious game, de
modo que não seja perdido o componente de diversão (entretenimento) existente em jogos comerciais e que
chama tanto a atenção dos jogadores como relatado por (POURABDOLLAHIAN., et al 2012; HAUGE et al
2012; YUDA, 2011). Outro componente de extrema importância é a falta de um método de desenvolvimento
de jogos educacionais voltado ao TDAH.

268
 Conferência IADIS Ibero-Americana Computação Aplicada 2013

2. MATERIAIS E MÉTODOS
Para o desenvolvimento do método ICS (Ianaguivara, Candiago e Silva) será utilizada a Estrutura Analítica
de Projeto (EAP) e o Game Design Document (GDD). A EAP é utilizada para visualizar as etapas do projeto
em uma perspectiva de alta à baixa abstração de desenvolvimento de software, para determinar as atividades
necessárias para o desenvolvimento do e-learning dentro do orçamento, prazo e com os recursos disponíveis,
além de determinar em que fase do projeto as atividades devem ser implementadas. O GDD deve ser
adicionado no método proposto, a fim de abranger as fases de desenvolvimento de jogos comerciais, ou seja,
jogos voltados à diversão e ao entretenimento. Os testes são utilizados para visualizar os benefícios obtidos
através desta ferramenta.

2.1 Método ICS

A EAP visualizada na figura 1é dividida em três pacotes principais, o GDD, implementação e testes.

Figura 1. EAP do método ICS.

2.2 Testes
Os testes serão realizados no laboratório de ambientes virtuais e tecnologia assistiva (LAVITA) da
Universidade de Mogi das Cruzes (UMC). Os testes selecionados foram: Testes de software (caixa-branca e
caixa-preta) e teste de usabilidade.
O teste e caixa-branca será aplicado para avaliar a construção lógica do software, ou seja, a lógica de
programação do software. O teste de caixa-preta será aplicado para avaliar as funcionalidades do sistema, por
exemplo, a figura 4 ilustra o desafio de pegar a garrafa com número maior, analisando-a podemos concluir
que é a garrafa com o valor “5” o tester deverá analisar se o software permite o jogador continuar a execução
do aplicativo se a resposta for errada.

3. RESULTADOS
O teste de caixa-branca foi aplicado pelos desenvolvedores do software, uma vez que o usuário não tem
acesso ao código fonte. O jogo foi considerado aprovado neste teste.
O teste de caixa-preta foi avaliado por “5” voluntários formados em Sistemas da Informação, o mesmo foi
considerado aprovado em todas as métricas propostas.
O teste de usabilidade envolveu as métricas de gráfico, som, controle, diversão e animação. Os testes
foram realizados por “5” voluntários com experiência em desenvolvimento de jogos comerciais.
As métricas de avaliação foram divididas em: (5 – Muito Bom, 4 – Bom, 3 – Regular, 2 – Ruim e 1 –
Muito ruim).

269
ISBN: 978-972-8939-96-0 © 2013 IADIS

Tabela 1. Resultados da avaliação.

Teste de Usabilidade
Gráficos Sons Controles Diversão Animações
V1 5 5 4 5 5
V2 4 4 3 4 4
V3 4 4 3 4 3
V4 4 5 4 4 3
V5 4 4 3 4 4

REFERÊNCIAS
AMERICAN PSYCHIATRIC ASSOCIATION (APA) 2000. DIAGNOSTIC AND STATISTICAL MANUAL OF
MENTAL DISORDERS (DSM-IV). 4.ED. WASHINGTON: BRITISH LIBRARY.
BEZERRA, E. PRINCÍPIOS DE ANÁLISE DE SISTEMAS COM UML. IN:____________. 2.ED. RIO DE JANEIRO:
CAMPUS, 2006. P. 19-94.
HAUGE, J, B; POURABDOLLAHIAN, H, B; RIEDEL, C, J, C, K, H (2012). Workshop on the Use of Serious Games
in the Education of Engineers. Procedia Computer Science, n.15, p.340-341.
POURABDOLLAHIANA, B; TAISCHA, M; KERGAA, E (2012). Serious Games in Manufacturing Education:
Evaluation of Learners’ Engagement. Procedia Computer Science, n.15, p.256-265.
YUDA, M (2011). Effectiveness of Digital Educational Materials for Developing Spatial Thinking of Elementary School
Students. Procedia Social and Behavioral Sciences, n.21, p. 116-119.
YUSSOF, A (2010). A Conceptual Framework for Serious Games and its Validation. Thesis for the Degree of Doctor of
Philosophy. Faculty of Engineering, Sciences and Mathematics School of Electronics and Computer Science -
University of Southampton.

270
 ÍNDICE DE AUTORES
Albuquerque, J. ................................................ 87
Almeida, M..................................................... 127
Amaral, R. ...................................................... 203
Araújo, L. ...................................................... 158
Araújo, W. ........................................................ 63
Arenas, D. ........................................................ 47
Arruda, D. ........................................................ 38
Assunção, M. ................................................. 193
Azevedo, F. ............................................ 103, 223
Barbosa, C. ....................................................... 87
Bastos, M. ......................................................... 63
Berkenbrock, C. .............................................. 158
Betencourt, P. ................................................. 119
Bôaventura, R. .......................................... 71, 193
Boldt, F. ........................................................... 95
Bona, L. .......................................................... 183
Brazolin, S. .................................................... 203
Brito, G. ......................................................... 111
Camargo Junior, A. ....................................... 251
Campos, J. ....................................................... 87
Candiago, A. .................................................. 268
Carabajal, M. .................................................... 47
Carneiro, L. ................................................... 127
Carvalho, E. ................................................... 151
Castello, J. ..................................................... 166
Chaves, M. ..................................................... 259
Chen, R. ........................................................... 38
Citadin, J. ....................................................... 158
Correia, R. ...................................................... 256
Costa, C. ........................................................... 11
Costa, K. ........................................................ 251
Costa, P. ......................................................... 166
Cunha, I. ......................................................... 259
Dörr, J. ........................................................... 183
Ellwanger, C. ......................................... 119, 143
Escobar, T. ..................................................... 119
Fajardo, J. ....................................................... 213
Felippe, G. ...................................... 198, 223, 253
Fernandes, S. .................................................. 111
Ferreira, N. .................................................... 253
Fick ,E. .......................................................... 233
Figueiredo, R. ................................................. 233
Firmo, A. ......................................................... 87
Galante, G....................................................... 183
Garcia, M. .............................. 103, 198, 223, 253
Garcia, R. ...................................................... 256
Garcindo, L. .................................................. 151
Gimenez, D. ..................................................... 47
Guedes, G. ..................................................... 151
Guimarães, L. ................................................. 228
Hoepers, A. ...................................................... 79
Hoepers, C. ...................................................... 55
Hoffman, J. .................................................... 166
Iaione, F. ........................................................ 237
Ianaguivara, E. .............................................. 268
Kay, M. ......................................................... 237
Lemos, J. ........................................................ 233
Licata, E. ......................................................... 47
Lima, A. ........................................................ 262
Lima, D. ........................................................ 259
Lima, M.......................................................... 175
Lima, T. .......................................................... 143
Losada, P. ...................................................... 259
Magagnin Junior, A. ........................................ 21
Mantau, M. ..................................................... 158
Marinho, D. .................................................... 135
Marques, C. .................................................... 193
Martins, E. ...................................................... 103
Martins, H. .................................................... 251
Matias, Í. ....................................................... 262
Melo, D. ........................................................ 111
Misaghi, M. ........................................................ 3
Moraes, D. ..................................................... 135
Morais, M. .............................................. 245, 262
Murilo, S. ....................................................... 265
Nascimento, P. ............................................... 111
Neves, M. ...................................................... 251
Novaski, M. ................................................... 223
Oliveira, A................................................ 87, 119
Olivete Júnior, C. .......................................... 256
Palhano, M. ................................... 198, 223, 253
Panizzi, M. ....................................................... 47
Pansanato, L. .......................................... 135, 209
Parraga, A. .................................................... 228
Pereira Filho, J. ............................................. 166
Pereira, D. ..................................................... 135
Pereira, D. ..................................................... 209
Pereira, I. ....................................................... 166
Pereira, M. ................................................. 55, 79
Pereira, R. ....................................... 198, 223, 253
Pinto, B. ................................................... 71, 193
Rauber, T. ........................................................ 95
Rezende, A. .................................................... 175
Ribeiro, P. .............................................. 218, 251
Rodrigues, S. .................................................. 259
Rojas, F. ........................................................... 29
Rossi, V. ......................................................... 251
Russo, M. ....................................................... 203
Sala, D. .......................................................... 228
Sales, D........................................................... 245
Santos, C. ............................................... 119, 143
Santos, R......................................................... 259
Sauki, M. ........................................................ 198
Schmitz, A. ...................................................... 79
Sgarbi, J. ......................................................... 218
Silva Junior, E. .............................................. 111
Silva, A. .......................................................... 268
Silva, A. ......................................................... 256
Silva, D. ......................................................... 143
Simas, J. ........................................................... 21
Simões, P. ............................................... 198, 253
Souza, J........................................................... 259
Souza, W. ...................................................... 262
Sovierzoski, M.................................................. 21
T. Filho, J. ....................................................... 38
Teixeira, S. .................................................... 166
Torres, E. ......................................................... 29
Valença, M. ................................................... 111
Varejão, F. ........................................................ 95
Vera, F. ............................................................. 29
Viríssimo, D. ................................................. 203
von Söhsten, D. ............................................. 265
Yamanaka, K. ........................................... 71, 193
Zancan, E. ...................................................... 253