XX Seminco

XX SEMINCO - SEMINÁRIO DE COMPUTAÇÃO
XX
SEMINCO
XBr
yrj = mi
yrj >n0
{ {
XBi
yji
SEMINÁRIO DE COMPUTAÇÃO
ANAIS
22 a 23 de AGOSTO de 2011
FURB - BLUMENAU - SC
Anais do XX SEMINCO
Seminário de Computação
22 e 23 de agosto de 2011
FURB - Campus I - Blumenau/SC
Promoção
Universidade Regional de Blumenau - FURB
Centro de Ciências Exatas e Naturais - CCEN
Departamento de Sistemas e Computação - DSC
Centro Acadêmico Livre de Computação - CALCOMP
Comissão Organizadora
Prof. Everaldo Artur Grahl (Coordenador)
Prof. Antonio Carlos Tavares
Prof. Aurélio Faustino Hoppe
Prof. Dalton Solano dos Reis
Felipe Demarchi
Luciana Pereira de Araújo
Matheus Luan Krueger
Vilmar Orsi
Ficha Catalográfica Elaborada pela Biblioteca da FURB
Seminário de Computação (20.: 2011 : Blumenau, SC)
Anais do XX SEMINCO / promoção Universidade Regional de Blumenau, Departamento de Sistemas

e Computação; Everaldo Artur Grahl, Dalton Solano dos Reis (coordenadores). - Blumenau, O
Departamento, 2010. 108p. : il.
1. Computação - Congressos. I. Grahl, Everaldo Artur; Reis, Dalton Solano dos. II. Universidade
Regional de Blumenau. Departamento de Sistemas e Computação. III. Tı́tulo.
CDD 004
Universidade Regional de Blumenau

Reitor
Prof. Dr. João Natel Pollonio Machado
Vice-Reitor
Profa . Griseldes Fredel Boos
Diretor do Centro de Ciências Exatas e Naturais
Prof. Dr. Geraldo Moretto
Chefe do Departamento de Sistemas e Computação
Prof. Antonio Carlos Tavares
Coordenador do Colegiado do Curso de Ciências da Computação
Prof. José Roque Voltolini da Silva
Coordenador do Colegiado do Curso de Sistemas de Informação
Prof. Wilson Pedro Carli
Apresentação
A Universidade Regional de Blumenau - FURB, através do Departamento de Sistemas e
Computação, realiza o XX SEMINCO - Seminário de Computação nos dias 22 e 23 de
agosto de 2011. Este ano completando duas décadas de realizações. Este evento foi criado
em 1992 através de um grupo de professores e alunos da FURB interessados em divulgar
e disseminar a produção interna de trabalhos e pesquisas de computação. O evento foi
crescendo e hoje já é uma referência nacional na área, auxiliando na divulgação e produção
cientı́fica de várias instituições brasileiras.
Este ano tivemos a submissão de 24 artigos, sendo que destes foram aprovados 8 artigos
provenientes das seguintes instituições: CPqD, FURB, IPEV, UNIFEI, UNIRITTER, UNI-
SUL, UNIVALI e UTFPR. Estes artigos contemplam as áreas de Engenharia de Software,
Integração Hardware / Software, Inteligência Artificial e Sistemas de informação.
Agradecemos a todos os envolvidos na organização do evento, bem como a Comissão de
Avaliação Interinstitucional que avaliou os artigos submetidos à chamada de trabalhos.
Comissão Organizadora
Agradecimentos
Centro de Ciências Exatas e Naturais - CCEN
Centro de Comunicação e Marketing
Contribuintes do Projeto Acredito
Sociedade Brasileira de Computação - SBC
Comissão de Avaliação Interinstitucional
Adilson Vahldick (UDESC)
Adriana G. Alves (UNIVALI)
Alexandre Cidral (UNIVILLE)
Angelo Frozza (IFC )
Anita Fernandes (UNIVALI)
Aurélio Hoppe (FURB)
Dalton Solano dos Reis (FURB)
Denio Duarte(UFFS)
Everaldo A. Grahl (FURB)
Fabiane Barreto Vavassori Benitti (UNIVALI)
Fernando dos Santos (UDESC)
Frank Siqueira (UFSC)
Jomi Hübner (UFSC)
Marcel Hugo (FURB)
Marcello Thiry (UNIVALI)
Marcos Eduardo Casa (UCS)
Patricia Vilain (UFSC)
Artigos Selecionados
Engenharia de Software
Uma Proposta de Modelo Conceitual para Repositório de Artefatos de Software 6
Visando Promover o Reuso
Beatriz T. Borsoi, Eliane M. de B. Fávero, Rúbia E. O. Schultz Ascari, Adriana Ariati,
Renato Silva Belazi
Análise Comparativa entre Groovy e Java, Aplicado no Desenvolvimento Web 18
Vandir Fernando Rezende, Marcel Hugo
Integração Hardware / Software

Desenvolvimento de um Protótipo para Ensaios de Calibração do Sistema de Dados 31
Aéreos usando Técnicas de Processamento de Imagens
Luiz Eduardo Guarino Vasconcelos, Nelson Paiva Oliveira Leite, Carlos Alberto Murari
Pinheiro, Otávio Augusto Salgado Carpinteiro
Inteligência Artifical
Extensão Swarm Intelligence para o Simulador Robocup Rescue 44
Alessandro A. Ostetto, Fernando dos Santos
Utilização de Processamento Digital de Imagens e Redes Neurais Artificiais para 56

Diagnosticar Doenças Fúngicas na Cultura do Tomate
Felipe S.Vieira, Rafael Paz, Clavison M. Zapelini, Adriana S. Zanini, Eros Comunello,
Anita M.R.Fernandes
Sistema Especialista para Indicação de Medicamentos Fitoterápicos 70
Leonardo Veronese Soletti, Sidnei Renato Silveira
Sistemas de Informação
Sistema Gerenciador de Regras de Negócio Aplicado à Gestão de Recursos de 82
Telecom: Estudo de Caso
Celly de Siqueira Martins, Mauricio Amorim da Silva, Sindo Vasquez Dias, André Lara
Temple de Antonio
Gestão da Informação em Biblioteca Universitária: uma Proposta Utilizando Regras 95

de Associação na Disseminação das Informações de Novas Aquisições Bibliográficas
Maciel F. da Silva, Cláudio Ratke
6
Uma Proposta de Modelo Conceitual para Repositório de

Artefatos de Software Visando Promover o Reuso
Beatriz T. Borsoi1, Eliane M. de B. Fávero1, Rúbia E. O. Schultz Ascari1, Adriana
Ariati1, Renato Silva Belazi1
1
GETIC – Grupo de Estudos e Pesquisas em Tecnologias de Informação e Comunicação
Universidade Tecnológica Federal do Paraná (UTFPR) - Campus Pato Branco
Via do Conhecimento – 85.503-390 – Pato Branco – PR – Brasil
{beatriz,elianedb,rubia}@utfpr.edu.br;
adrianaariati@hotmail.com;rbelazi@hotmail.com
Resumo. O reuso de artefatos de software ainda é um desafio. Isso porque é

necessário que os artefatos sejam desenvolvidos visando reuso e mudanças na
cultura organizacional podem ser necessárias para essa prática. Esse trabalho
propõe um modelo conceitual de repositório de artefatos (documentos,
componentes e procedimentos) com o objetivo de facilitar sua recuperação e
reuso. Esse modelo tem como base técnicas de classificação como vocabulário
controlado, com classificação por palavras-chave, descrição textual e
enumeração ou hierárquica. O modelo proposto é simples em relação à forma de
uso dos métodos, mesmo visando recuperação otimizada em relação aos critérios
de busca.
1. Introdução
O conceito de reuso pode ser aplicado a todo o ciclo de vida de um software, pois como
argumentou Justo (1996), não há razões teóricas que impossibilitem sua aplicação nas fases
iniciais do desenvolvimento. Para esse autor, a especificação de requisitos é uma fase
crucial no ciclo de vida de um sistema e aplicar reuso efetivo nessa fase tornaria possível
construir sistemas que atendessem melhor os requisitos requeridos pelo usuário.
A orientação a objetos está estreitamente vinculada ao reuso de código, inclusive
pelo seu mecanismo de herança. O desenvolvimento baseado em componentes também está
centrado no reuso de elementos de código. Porém há outros escopos para reuso, como
padrões de projeto e experiências e conhecimento adquiridos com a realização de atividades
do ciclo de vida de software.
Os padrões de projeto, tendo como referência os vinte e três padrões propostos por
Gamma et al. (1997), podem ser definidos como componentes conceituais reutilizáveis.
Eles se aplicam à produção de código, mas o que é reutilizado são os conceitos envolvidos,
ou mais especificamente a estrutura conceitual de um padrão que resolve um problema bem
estabelecido.
Basili, Caldiera e Rombach (1994), consideram que o reuso de produtos, processos
e experiências representam uma maneira de solução possível para o problema de
_______________________________________________
Grahl, E. A; Reis, D. S. (Eds.). Anais do XX Seminário de
Computação, Blumenau, 22 a 23 de agosto de 2011.
7
desenvolver sistemas com qualidade alta e custo baixo. Esses autores definem uma fábrica
de experiências na qual há o reuso de conhecimento produzido nas atividades relacionadas
ao desenvolvimento de software.
O reuso pode estar vinculado, também, aos resultados das atividades de análise e de
projeto, como, por exemplo, especificações de requisitos, diagramas de casos de uso, de
classes e de banco de dados. Esses documentos são reaproveitados no desenvolvimento de
projetos que possuam requisitos iguais ou semelhantes.
Este trabalho se refere a reuso em um escopo mais amplo, abrangendo todos os
produtos resultantes no ciclo de vida de software. Esses produtos são denominados
artefatos, e representam componentes de código (software), documentos gerados (como
diagramas de classes, planos de testes, modelos para elaboração de documentos) e
procedimentos (métodos, técnicas, orientações para realizar as atividades) que podem ser
resultantes da experiência da realização das atividades.
O desenvolvimento baseado em reuso requer tempo e esforço consideráveis para
que bons resultados sejam obtidos, o que tem sido uma barreira para pequenas organizações
[Shiva e Shala 2007]. Em função disso, este trabalho propõe a definição conceitual de um
repositório para o armazenamento de artefatos como descritos neste texto, de maneira a
otimizar a busca. Também é proposta uma maneira de recuperação dos artefatos, visando a
localização dos artefatos que atendem plenamente os requisitos de busca e dos que atendem
parcialmente a esses requisitos. Otimização se refere a localizar o artefato mais adequado,
dentre os armazenados no repositório, para o interesse de busca e de acordo com os
critérios informados.
Este texto está organizado em seções. Esta é a primeira e apresenta a introdução
com uma visão geral do assunto, o problema e a proposta de solução. Na Seção 2 estão
conceitos de reuso, repositório e métodos de classificação e busca. A Seção 3 apresenta
trabalhos relacionados. Na Seção 4 está a solução proposta. E na Seção 5 está a conclusão.
2. Reuso e Repositório de Artefatos

Reuso está relacionado ao uso de conceitos ou produtos previamente adquiridos ou
construídos em situações novas [Biggerstaff e Perlis 1989]. Sendo que estes devem ser
definidos e/ou produzidos visando o seu reuso, estarem armazenados de forma a facilitar
sua recuperação e prover a identificação de similaridades entre situações novas e antigas
permitindo sua adaptação [Prieto-Diaz 1989].
Kotonya, Lock e Mariani (2011) fazem um apanhado histórico sobre reuso,
destacando as primeiras associações com o tema, iniciando com o trabalho de McIlroy
(1968) que sugeriu que a indústria de software deveria ser baseada em componentes
reusáveis. Na sequência, Parnas (1976) propôs a noção de família de programas e
Neighbours (1984) definiu os conceitos de domínio e análise de domínio. Essas ideias
iniciaram a sistematização de engenharia de linha de produtos de software, que é tratada
por Greenfield e Short (2004) como fábrica de software. Mais recentemente destacam-se os
trabalhos de Frakes e Kang (2005) e Shiva e Shala (2007) que identificaram mudanças na
forma de localizar artefatos em repositórios. A popularidade do reuso aumentou
_______________________________________________
8
recentemente devido à possibilidade de desenvolvimento distribuído de software [Shiva e

Shala 2007] ocasionada, principalmente, pela globalização e pelo desenvolvimento
compartilhado por empresas distintas.
Embora o conceito de reuso seja usualmente aplicado na fase de implementação de
um software com o objetivo de reutilizar trechos de código, qualquer item gerado no
processo de desenvolvimento de software pode ser reusado. Dentre esses itens estão os
documentos de modelagem do sistema e os resultados de experiências e do aprendizado na
realização das atividades, incluindo procedimentos e maneiras de resolver problemas.
A aplicação de reuso nas fases iniciais de desenvolvimento de software foram
investigadas desde o início da década de 1990, como atestam as publicações de Grosz
(1992), Maiden e Sutcliffe (1992) e Sutcliffe e Maiden (1994). Melo (2007) também afirma
que a reutilização, ou reuso, não é só aplicável a fragmentos de código fonte, mas a todo o
trabalho gerado durante o processo de desenvolvimento de software, como dados,
arquitetura e projeto, resultando nos benefícios: aumento da produtividade; aumento da
qualidade; redução dos custos; redução no tempo de entrega; padronização;
interoperabilidade; previsibilidade, confiabilidade e redução de riscos. A esses benefícios
Sommerville (2007) acrescenta: uso de padrões e obtenção de resultados positivos em
termos de produtividade e qualidade do software, pelo reuso de experiências.
Para que artefatos sejam armazenados visando facilitar a sua localização, a
documentação dos mesmos deve definir as suas características de identificação, tais como
nome, descrição, data de criação e observações. Essas informações podem ser tratadas
como metadados por mecanismos de busca. O aspecto relevante está em como organizar
esses dados e definir os atributos do artefato de maneira que seja possível localizar o
artefato que melhor atende aos interesses do usuário representados pelos critérios de busca.
A estrutura do repositório é um fator essencial para os resultados de busca. Mesmo
que algoritmos de busca possam prover resultados com um esforço mínimo de estrutura e
indexação, repositórios fracamente estruturados com indexação inadequada não terão um
bom desempenho independentemente dos algoritmos de busca [Henninger 1997].
2.1 Métodos de Classificação e Recuperação de Artefatos

A recuperação efetiva de artefatos de software em repositórios é afetada fortemente pela
combinação dos métodos de classificação adotados. Neste trabalho, o termo método se
refere aos diversos esquemas e procedimentos de classificação apresentados na literatura e
utilizados na classificação e recuperação de artefatos.
Um esquema de classificação é um meio de produzir uma organização sistemática
com base em um vocabulário, seja controlado ou não [Prieto-Diaz 1991]. Desta forma, um
vocabulário controlado constitui-se dos termos utilizados para especificar artefatos,
extraídos de um conjunto predefinido de atributos. Já em um vocabulário não-controlado,
os termos são automaticamente extraídos a partir dos textos que descrevem um componente
por linguagem natural [Salton 1983; Vanderlei 2006]. Sendo assim, um esquema de
classificação pode se basear em um ou em ambos os tipos de vocabulários, podendo ser das
_______________________________________________
9
seguintes formas: classificação por palavras-chave, por enumeração e classificação em

facetas, conforme apresentadas a seguir.
De acordo com Vanderlei (2006), a classificação por enumeração é um esquema de
classificação que se baseia na submissão de informações a uma estrutura hierárquica pré-
definida e mutuamente exclusiva. Esse esquema apresenta inflexibilidade inerente e
problemas em entender grandes hierarquias, já que a estrutura pré-definida das categorias
apenas permite a introdução de novos elementos de forma sequencial.
No método de classificação por palavras-chave, os artefatos de software podem ser
classificados, tanto por palavras extraídas automaticamente de textos contidos nos próprios
artefatos (vocabulário não-controlado) ou fornecidas pelo usuário que o está classificando
(vocabulário controlado). Métodos de texto livre são simples para construir e recuperar,
mas precisam de grande quantidade de texto disponível para uma boa precisão nas buscas,
sendo melhor aplicáveis para domínios com extensa documentação, apesar da busca ser
menos cara, pois não requer intervenção humana [Maarek e Smadja 1989; Frakes e Pole,
1994]. Contudo, Hall (1992) destaca a dificuldade inerente ao uso de vocabulário não-
controlado no método por palavras-chave na pesquisa, pois nem sempre a pessoa que
classificou o componente é a mesma que irá recuperá-lo, podendo tornar difícil a
recuperação de componentes por pessoas que não possuam conhecimento específico.
A classificação por facetas consiste em categorizar os artefatos pela síntese dos
valores das facetas. Uma faceta pode ser vista como uma propriedade do componente que
deve aceitar valores pré-definidos. Também pode ser vista como um par atributo-valor,
onde há um atributo fixado pela faceta e vários valores associados. Em um repositório, os
possíveis valores de cada faceta são relacionados por meio de um grafo conceitual que
permite relacionar valores sinônimos ou conceitualmente semelhantes [Prieto-Diaz 1991;
Vanderlei 2006]. Para Vanderlei (2006), essa associação permite localizar componentes que
se aproximam conceitualmente do componente pretendido. Facetas são mais flexíveis,
precisas e se enquadram melhor para repositórios em constante expansão, se comparadas
com esquemas enumerativos em repositórios que armazenam componentes homogêneos.
3. Trabalhos Relacionados
Os primeiros trabalhos voltados para busca e recuperação de artefatos de software
reutilizáveis tiveram seu foco voltado para os métodos de classificação desses artefatos
[Prieto-Diaz 1991; Podgurski e Pierce 1993; Frakes e Pole 1994]. Estudos mostraram que
os métodos de classificação disponíveis até então, não apresentavam diferenças
significativas entre si. Sendo assim, outros aspectos começaram a ser observados e
requisitados, especialmente em relação à recuperação de artefatos. Destaca-se a proposta de
Henninger (1994) para a combinação de métodos de classificação, que visam permitir ao
usuário o refinamento de suas expressões de busca, a fim de obter melhores resultados,
como a recuperação de artefatos próximos aos requisitados e não apenas os que se
apresentassem exatamente iguais à consulta. Anos mais tarde, o mesmo autor propôs um
repositório com índices automaticamente atualizados à medida que novas consultas eram
realizadas, de forma a facilitar futuras consultas do mesmo artefato.
_______________________________________________
10
Desta forma, a partir dos estudos realizados sobre classificação e recuperação de

artefatos de software, visando a sua reutilização, muitos trabalhos têm sido realizados
propondo a mescla de vários métodos já consolidados, como a busca por palavras-chave
(pré-definidas ou em texto livre); por enumeração ou hierárquica (entre categorias pré-
definidas de classificação) ou baseada em facetas. Esta seção apresenta alguns trabalhos
que utilizam esses métodos.
a) Maarek, Berry e Kaiser (1991) utilizam o conceito de busca em texto livre,
identificando palavras-chave que melhor representem o componente em questão.
b) Henninger (1994) propôs o sistema CodeFinger, cuja recuperação é sustentada
pela reformulação interativa de perguntas e por uma aproximação da recuperação usando
uma rede neural, com um algoritmo capaz de recuperar os componentes de software
relacionados a uma dada pergunta, feita por palavras-chave, frases ou afinidades lexicais.
c) Redolfi et al. (2005) identificam um conjunto de funcionalidades para um
repositório de componentes de software oferecer suporte às atividades de desenvolvimento
baseado em componentes. E propõem um repositório que atende a essas funciolidades,
incluindo busca e recuperação, controle de versão e gerenciamento de controle de versão.
d) Garcia et al. (2006) propuseram um mecanismo denominado “Maracatu” que
permite o reuso de componentes de software, por meio de buscas em repositórios de
código-fonte de projetos, realizadas pela combinação de métodos de recuperação por
palavras-chave e facetas. Os autores mostraram, por meio de experimentos, que a
combinação dos esquemas de busca por palavras-chave com facetas apresenta taxa de
recuperação e precisão melhores em relação aos esquemas utilizados separadamente.
e) Vanderlei et al. (2007) combinam técnicas originais de busca por palavras-chave
e facetas com folksonomia. O suporte à folksonomia permite aos desenvolvedores popular
com tags os componentes do repositório para futuras consultas e compartilhamento com os
demais usuários do sistema. O estudo indica que o uso de folksonomia permite maior
aproximação da realidade do usuário, seja no cadastro de artefatos ou na sua recuperação.
f) Petrov e Buchmann (2008) adotaram o uso de palavras-chave, permitindo uma
melhor representação dos requisitos do componente. Para auxiliar o usuário na classificação
e recuperação dos componentes, são apresentadas questões, cujas respostas serão as
palavras-chave pré-definidas para ambas as situações. As palavras-chave poderiam também
ser diretamente informadas pelo usuário, indicando atributos desejáveis e não desejáveis
para o componente de software.
g) Batista Junior e Domingues (2010) definiram um método que gera
automaticamente uma Forma Gráfica de Representação (FGR) para descrições de
componentes de software em linguagem natural ou por questões de usuários. A busca de
componentes na biblioteca é suportada pela avaliação automática do casamento (matching)
entre a FGR de uma questão do usuário e as FGRs das descrições dos componentes da
biblioteca. A análise da questão é realizada com a extração das palavras-chave da questão.
A partir dos trabalhos apresentados, é possível perceber que o foco das pesquisas
está bastante voltado para a eficácia na recuperação de artefatos de software a partir de um
repositório, de forma a tornar essa tarefa mais prática, flexível e efetiva quanto possível,
retornando o artefato desejado de maneira rápida e precisa. Todos os trabalhos apresentados
_______________________________________________
11
referem-se ao armazenamento e recuperação de componentes de código, a fim de oferecer

suporte ao desenvolvimento de softwares baseado em componentes, o que reforça a
relevância desta proposta, que visa trabalhar com artefatos de software diversos.
4. Modelo Conceitual de Repositório de Artefatos Visando Reuso

Esta seção apresenta a proposta de modelo conceitual para um repositório de artefatos e
para a recuperação desses artefatos. Os artefatos armazenados são caracterizados por
atributos e outras informações consideradas necessárias para descrevê-los com o objetivo
de facilitar a sua recuperação e reuso. O modelo proposto utiliza métodos de classificação
baseados em vocabulário controlado, como a classificação por palavras-chave, por
descrição textual e por enumeração ou hierárquica.
A busca dos artefatos é realizada por palavras-chave informadas ou pré-definidas
nos atributos de identificação do artefato e na sua descrição (neste caso a busca é feita por
palavras-chave em texto livre). O uso combinado de técnicas distintas visa prover uma
forma de localizar, além dos artefatos que melhor atendem aos critérios de busca, os
artefatos com características próximas a esses critérios. Henninger (1994) propôs uma
forma de busca aproximada, mas especificamente para componentes de software.
O uso de busca em texto livre não onera o custo de processamento para a
recuperação de artefatos. Isso porque essa busca ocorre no atributo de descrição do artefato
e será realizada a partir de palavras-chave ao invés de indexadas como resultado de busca
em texto livre. Essas palavras podem ser escolhidas a partir de um cadastro prévio ou
informadas pelo usuário no momento da busca.
O uso de palavras-chave facilita a implementação de mecanismos de busca, mas
pode dificultar o cadastramento de artefatos no repositório. Se o conjunto dessas palavras é
restrito, o artefato pode não ficar bem caracterizado. E um conjunto muito amplo pode
conter palavras distintas para um mesmo conceito (sinônimos) e dificultar a recuperação do
artefato desejado ou que melhor atenda aos critérios de busca.
Brito et al. (2009) citam que alguns sistemas de repositório de componentes adotam
técnicas de indexação que geram automaticamente informações de representação dos
componentes, mas, mesmo assim, os componentes são localizados por busca exaustiva na
coleção de informações [Girardi e Ibrahim 1994]. Por exemplo, em abordagens baseadas
em ontologias [Sivashanmugam et al. 2003] a inferência sobre a coleção de conceitos é
bastante custosa [Ding et al. 2004]. Brito et al. (2009) ressaltam que sistemas que adotam
métodos de recuperação clássicos, baseados na indexação de termos, se sobressaem em
eficiência quando comparados aos sistemas que empregam mecanismos de inferência.
Para minimizar os problemas decorrentes de uso de palavras-chave diferentes para
cadastrar e buscar um mesmo artefato, na proposta deste trabalho são definidos critérios
para a inserção e orientações para busca. Os critérios se referem às padronizações
recomendadas e a existência de um dicionário de sinônimos para ser consultado quando da
inserção do artefato. As orientações explicam o contexto e exemplificam o conteúdo de
cada campo de cadastro do artefato. Além disso, sugere-se que a inserção seja cooperativa,
ou seja, os dados de cadastro de um novo artefato são verificados por usuários distintos.
_______________________________________________
12
Ainda assim, para que o reuso seja efetivo o desenvolvimento de software deve
estar inserido em um contexto de desenvolvimento de software para e com reuso. Para
reuso, se refere a que artefatos são produzidos visando reuso e com reuso está relacionado
ao desenvolvimento de software com base em artefatos existentes.
Desta forma, deve haver integração entre as atividades de produção de software e de
componentes e o armazenamento e a disponibilização dos artefatos para reuso. A Figura 1
expressa essa integração por meio de processos que se comunicam. Esses processos são
representados em notação BPMN (Business Process Modeling Notation). Nessa notação,
retângulo com cantos arredondados representa atividade ou subprocesso, círculo com borda
delgada indica o início do processo e círculo com borda espessa o seu final. A interligação
entre processos é representada por seta pontilhada direcionada e entre as atividades de um
processo por seta com traço contínuo.
Produção Software Produção Armazenamento

Componente Disponibilização
Componentes
s (Repositório
Artefatos)
requisitos componentes componentes
especificações
experiências
modelos
experiências
modelos
procedimentos
experiências
componentes
modelos
procedimentos
Figura 1. Processos para produção de software com e para reuso

A Figura 1 representa que a fábrica de software possui um processo de
implementação que é suportado por um processo de produção de componentes. O processo
de implementação envia requisitos e especificações para o processo de produção de
componentes e este os desenvolve com o auxílio de modelos e procedimentos provenientes
do repositório. Os componentes produzidos são disponibilizados no repositório por meio de
um processo de armazenamento. O processo de produção de software implementa software
reusando componentes, modelos e procedimentos. O conhecimento gerado na realização
das atividades (denominado por experiência) é documentado e armazenado no repositório e
disponibilizado para reuso com o nome de procedimento. No processo de implementação,
tanto os modelos quanto os componentes de software podem ser adaptados ao contexto do
projeto em desenvolvimento.
Para serem devidamente recuperados, os componentes precisar ser cadastrados.
Redolfi et al. (2005) classificaram, com base em diversos autores, as informações sobre
_______________________________________________
13
componentes de software em sete grupos: identificação, uso, maturidade, documentação,

tecnologia, alteração e controle de qualidade. Considerando esses grupos é apresentado o
Quadro 1 com os grupos propostos neste trabalho para o armazenamento de artefatos.
Grupo Item
Identificação Identidade; Nome; Versão; Local de disponibilização.
Descrição Descrição; Tipo (componente, documento, procedimento); Classificação (base em palavras-
chave); Requisitos para uso; Restrições; Histórico de alterações.
Acesso Disponibilidade (público ou privado); Leitura/Escrita; Descrição da interface (se
componente); Tecnologia (linguagem, ferramenta de desenvolvimento).
Qualidade Testes de qualidade realizados e respectivos resultados.
Relacionamentos Pode ser usado com; Composto por; Depende de; Projetos que o utilizam.
Quadro 1. Agrupamentos de informações sobre artefatos
Na Figura 2 está o modelo conceitual proposto para o repositório de artefatos tendo
como base o Quadro 1. Essa figura contém um conjunto de conceitos relacionados que
explicitam a estrutura e a organização do repositório.
Figura 2. Visão geral do repositório de artefatos

O repositório provê o armazenamento de componentes de código, documentos
produzidos durante o ciclo de vida (ex. plano de testes, diagrama de casos de uso), modelos
de documentos (padrões e orientações) e procedimentos (o conhecimento gerado com a
realização de atividades). As palavras-chave são utilizadas para definir requisitos do
artefato e restrições (requisitos que o artefato não atende), podendo ser principais e
secundárias. A descrição é utilizada para complementar a classificação baseada em
palavras-chave. As palavras-chave secundárias permitem localizar artefatos que não
atendem os requisitos ou critérios de busca completamente, mas que se aproximam deles.
Os relacionamentos definem as conexões entre os artefatos e eles são estabelecidos
quando da sua inserção no repositório. Na inclusão de um artefato, o sistema faz uma busca
_______________________________________________
14
no repositório visando identificar artefatos que possam estar relacionados e os sugere ao

usuário. Essas sugestões são realizadas após nome, descrição e palavras-chave do artefato
terem sido informados. A busca é realizada nesses campos e na descrição dos artefatos já
armazenados. O usuário valida essas sugestões efetivando os relacionamentos considerados
adequados e pode inserir outros relacionamentos além dos sugeridos pelo sistema. Em uma
busca, os relacionamentos vinculados a um artefato são indicados.
O histórico de mudanças contém as alterações realizadas em um artefato e o seu
tipo, que podem ser correção de defeitos ou melhoria. Correção de defeitos indica que todos
os projetos que utilizam o referido artefato deveriam atualizá-lo. E melhorias podem
agregar ou não funcionalidades e gerar ou não inconsistências em projetos que utilizam o
referido artefato. O registro dos artefatos utilizados nos respectivos projetos é mantido para,
por exemplo, informar os projetos cujos artefatos passaram por alterações de melhoria e de
correção de erros.
Na Figura 4 está representada a definição conceitual para a busca de artefatos no
repositório. O usuário escolhe entre palavras-chave existentes ou informa as palavras
desejadas utilizadas para buscas no texto da descrição do artefato e nos atributos que o
categorizam.
Figura 3. Visão geral da busca no repositório de artefatos

Dependendo do tipo de artefato procurado é definida uma busca hierárquica a partir
das palavras informadas. Os artefatos resultantes de uma busca são apresentados em
classificação descendente ao atendimento dos critérios de busca. E juntamente com cada
artefato são informados os artefatos relacionados.
Os artefatos de acesso público podem ser localizados em buscas por qualquer
usuário. Os artefatos de acesso privado são disponibilizados para o autor e para outros
usuários ou grupos de usuários. Esse controle de acesso possibilita o uso do repositório por
conjuntos de fábricas de software, como, por exemplo, uma incubadora de empresas ou as
que pertençam a um arranjo produtivo local. E, também, para o desenvolvimento
cooperativo ou distribuído de software.
O modelo proposto não determina como obrigatório o preenchimento de todos os
campos para cadastramento de artefatos. Isso torna o sistema flexível e facilita o seu uso,
_______________________________________________
15
inclusive por fábricas de software de pequeno porte, porque uma solução computacional
mais simples pode ser implementada. Contudo, ressalta-se que para maior efetividade na
busca é necessário que os artefatos estejam bem caracterizados, com informações
consistentes e completas.
5. Conclusão
Considerando o levantamento bibliográfico realizado, percebe-se que existe uma carência
de repositórios voltados para o reuso de artefatos de software como definido neste trabalho,
pois os repositórios existentes estão, normalmente, voltados para componentes de software.
A proposta deste trabalho fundamenta-se na necessidade verificada em fábricas de
software, principalmente as de pequeno porte, em reaproveitar conhecimento, experiências,
documentos e componentes de forma a agilizar os processos executados durante o ciclo de
vida do software.
Um repositório e formas de busca como apresentados neste trabalho podem ser
vistos como um diferencial competitivo para fábricas de software de pequeno porte, mas
não deixando de ser uma solução eficaz para o reuso de artefatos de software. Elas podem
estar organizadas de maneira a trabalhar cooperativamente e assim compartilhar artefatos.
O modelo proposto é bastante flexível, não tornando obrigatório o preenchimento de todos
os campos na inserção do artefato. Contudo, ressalta-se que quanto melhor e mais
completas estiverem as informações, mais eficiente e precisa será a busca. Desta forma, são
definidas orientações de como inserir os artefatos, sendo que a inserção deve ocorrer com a
verificação e validação por pessoas distintas.
A forma de classificação e recuperação apresentadas pode representar uma solução
para otimizar o reuso efetivo em repositórios de artefatos. Contudo, para afirmar os
possíveis benefícios obtidos está sendo implementado um protótipo de software com a
estrutura proposta neste trabalho, para então avaliar, na prática, junto a fábricas de software
diversas, sua efetividade.
Referências
Basili, V., Caldiera, G. and Rombach, D. (1994) “Experience Factory”. In: J. Marciniak,
Editor, Encyclopedia of Software Engineering, Wiley, p. 469-476.
Batista Junior, J. and Domingues, P. E. (2010) Method for searching software components.
In: Natural Language. IEEE Latin America Transactions, vol. 8, no. 3, June 2010, p.
296-303
Biggerstaff, T and Perlis, A. (1989) Classification of Reusable Modules, in Software
Reusability. Addison-Wesley, New York.
Brito, T., Ribeiro, T., Nóbrega H. and Elias, G. (2009) “Uma Técnica de Indexação de
Artefatos de Software Baseada em Dados Semi-Estruturados”. In:III Simpósio Brasileiro
de Componentes, Arquiteturas e Reutilização de Software (SBCARS 2009), p. 166-179.
Ding, L. et al. (2004) “Swoogle: A Semantic Web Search and Metadata Engine”. In: 13th
ACM Conference on Information and Knowledge Management, p. 652-659.
_______________________________________________
16
Frakes, W. B. and Pole, T. P. (1994). An empirical study of representation methods for

reusable software component, In: IEEE Transactions on Software Engineering, vol. 20,
no. 8, p.617-630.
Frakes, W. B. and Kang, K. (2005). Software reuse research: status and future, In: IEEE
Transaction Software Engineering, vol. 31, no. 7, p. 529-536.
Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1997), Design patterns. Elements of
reusable object-oriented software, Addison-Wesley.
Garcia, V. C., Lucrédio, D., Durão, F. A., Santos, E. C. R., Almeida, E. S., Fortes, R. P. M.
and Meira, S. R. L. (2006) “From Specification to the Experimentation: a Software
Component Search Engine Architecture”, In: 9th International Symposium on
Component-Based Software Engineering (CBSE 2006), p. 82-97.
Girardi, M. and Ibrahim, B. (1994) “Automatic Indexing of Software Artifacts”, In: 3rd
International Conference on Software Reuse, IEEE Computer Society Press, p. 24-32.
Greenfield, J. and Short, K. (2004), Software Factories: Assembling Applications with
Patterns, Models, Frameworks, and Tools, Indianapolis Indiana: Wiley Publications Inc.
Grosz, G. (1992) “Building Information System Requirements Using Generic Structures”,
In: 16th Computer Software & Applications Conference (COMPSAC 92), p. 200-205.
Hall, P. A. V. (1992), Software Reuse and Reverse Engineering in Practice, London:
Chapman & Hall.
Henninger, S. (1994) Using iterative refinement to find reusable software, In: IEEE
Software, vol. 11, no. 5, p. 48-59.
Henninger, S. (1997). An evolutionary approach to constructing effective software reuse
repositories, In: ACM Transaction on Software Engineering and Methodology, vol. 6,
no. 2, p. 111-140.
Justo, J. L. B. (1996) “A Repository to Support Requirement Specifications Reuse”, In:
Information Systems Congress of New Zealand (ISCNZ'96), p. 53-62.
Kotonya, G., Lock, S. and Mariani, J. (2011), Scrapheap software sdevelopment: lessons
from an experiment on opportunistic reuse, In: IEEE Software, vol. 28, no. 2, p. 68-74.
Maarek, Y. S. and Smadja, F. A. (1989) “Full Text Indexing Based on Lexical Relations,
an Application: Software Libraries”, In: Conference on Research and development in
information retrieval (ACMSIGIR ’89), p. 198-206.
Maiden, N. and Sutcliffe, A. (1992). Exploiting reusable specifications through analogy. In:
Communications of the ACM, vo1.35, no. 4, p. 55-64.
Mcilroy, M. D. (1968). Mass produced software components. In: NATO Software
Engineering Conference, Springer, p. 138-155.
Melo, Cláudia de Oliveira. (2007), Classificação Semi-Automática de Componentes Java,
Dissertação de Mestrado, Instituto de Matemática e Estatística da Universidade de São
Paulo: São Paulo.
_______________________________________________
17
Neighbours, J. M. (1984), The draco approach to constructing software from reusable

components, In: IEEE Transactions on Software Engineering, vol. 10, no. 5, p. 564-574.
Parnas, D. L. (1976). On the design and development of program families. In: IEEE
Transaction On Software Engineering, vol. 2, no. 1, p. 1-9.
Petrov. I; and Buchmann, A. (2008) “Architecture of OMG MOF-based Repository
Systems”, In: International Organization for Information Integration and Web-based
Application and Services (iiWAS2008), p. 193-200.
Podgurski, A. and Pierce, L. (1993). Retrieving reusable software by sampling behavior. In:
ACM Transaction on Software Engineering and Methodology, vol. 2, no. 3, p. 286-303.
Prieto-Diaz, R. (1989) Classification of Reusable Modules in Software Reusability:
Concepts and Models, In: Biggerstaff, T. J. and Perlis, A. J. (Editors). Addison-Wesley
Pub. Co.: New York, NY, p. 99-123.
Prieto-Diaz, R. (1991). Implementing faceted classification for software reuse. In:
Communications of the ACM, vol. 34, no. 5, p. 89-97.
Redolfi, G., Spagnoli, L., Hemesath, P., Bastos, R. M., Ribeiro, M. B., Cristal, M. and
Espindola, A. (2005) “A Reference Model for Reusable Components Description”, In
38th Hawaii International Conference on System Sciences, p. 282-291.
Salton, G. and Mcgill, M.J. (1983) Introduction to Modern Information Retrieval. McGraw-
Hill, N.Y.
Shiva, S. G., and Shala, L. A. (2007) “Software Reuse: Research and Practice”, In: 4th
IEEE Conference Information Technology (ITNG 07), IEEE CS Press, p. 603-609.
Sivashanmugam, K., Verma, K., Sheth, A. and Miller, J. (2003) “Adding Semantics to Web
Services Standards”, In: International Conference on Web Services, p. 395-401.
Sommerville, I. (2007) Engenharia de Software. 8ª ed. São Paulo: Pearson Addison
Wesley.
Sutcliffe, A. and Maiden, N. (1994) “Domain Modeling for Reuse”, In: 3rd International.
Conference on Software Reuse, p. 169-177.
Vanderlei, T. A., Garcia, V. C., Almeida, E. S. and Meira, S. R. L. (2006) “Folksonomy in
a Software Component Search Engine – Cooperative Classification through Shared
Metadata”, In: XX Simpósio Brasileiro de Engenharia de Software (SBES), p. 1-13.
Vanderlei, T. A., Durão, F. A., Garcia, V. C., Almeida, E. S. and Meira, S. R. L. (2007) “A
Cooperative Classification Mechanism for Search and Retrieval Software Components”,
In: 22th Annual ACM Symposium on Applied Computing (ACM SAC), p. 866-871.
_______________________________________________
18
Análise comparativa entre Groovy e Java, aplicado no

desenvolvimento web
Vandir Fernando Rezende, Marcel Hugo
Departamento de Sistemas e Computação

Universidade Regional de Blumenau (FURB) – Blumenau, SC – Brasil
rezende.vandir@gmail.com,marcel@furb.br
Resumo. Este artigo apresenta uma análise comparativa, no desenvolvimento

de softwares web, entre as linguagens de programação Groovy e Java.
Baseando-se na norma NBR ISO/IEC 9126-1 foram determinados os critérios
de avaliação. Para permitir a comparação foi implementado um aplicativo
estudo de caso em ambas as linguagens, com o intuito de medir a diferença de
produtividade no desenvolvimento dos casos de usos. Para comparar o
desenvolvimento, foi calculado a UCP dos casos de usos e posteriormente
verificado o tempo e o desempenho em cada linguagem.
1. Introdução
Com a necessidade de criar ferramentas que facilitassem o seu trabalho diário, o
homem passou a aprimorar cada vez mais os computadores e seus sistemas (SAMPAIO,
1999). Diante da informatização dos processos, a linguagem de programação Java tem
se mostrado importante, principalmente pelo fato de ser muito abrangente, pois
contempla desde dispositivos móveis até mainframes. Para isso, a mesma utiliza-se de
uma das suas principais características, a portabilidade (JAVA, 2010).
Segundo Oliveira (2009), Java conta com inúmeros frameworks, cada um
especializado em um ramo distinto do desenvolvimento de software, incluindo desde a
modelagem do banco de dados até a criação das interfaces visuais. Para ter esta
flexibilidade, Java precisa ser especificamente configurado a cada funcionalidade, pois
não conta com configurações predefinidas, ocasionando assim uma perda de
produtividade no processo, em casos que o tempo levado para configurar a solução é
maior que o tempo gasto com o desenvolvimento da regra de negócio. Pensando neste
fato, foram propostas diversas soluções para a evolução da linguagem Java,
principalmente focando no desenvolvimento ágil. Assim surge o JRuby e o Grails
(Groovy on Rails), tentativas de aproximar a programação Java com a filosofia ágil
(PETERSON, 2010).
Com o lançamento do framework Grails, para desenvolvimento de aplicações
web, Groovy ganhou credibilidade e o interesse da comunidade Java, provando assim,
que o desenvolvimento de aplicações web escaláveis são produtivas e fáceis. Grails
utilizou desde recursos básicos do Groovy, até recursos complexos de aplicações web,
como persistência em banco de dados, Ajax, webservices, relatórios, processamento em
lote, e plugins que permitem aos desenvolvedores melhorar e criar novas ferramentas
que auxiliam o desenvolvimento (JUDD; NUSAIRAT; SHINGLER, 2008).
_______________________________________________
19
Neste cenário, foi desenvolvido um aplicativo de gestão de projetos, sendo ele

implementado em Java e em Groovy, com o intuito de comparar as linguagens. Tomou-
se como base para a análise comparativa a norma NBR ISO/IEC 9126-1
(ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 2003).
2. NBR ISO/IEC 9126-1

A NBR ISO/IEC 9126-1 fornece um modelo de propósito geral, o qual define as
seis amplas categorias de características de qualidade de software, que tem por objetivo
servir de referência básica na avaliação de produto de software: funcionalidade,
confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.
Comparar linguagens de programação (LPS) não é exatamente o objetivo dessa
norma, contudo é o documento técnico que mais se aproxima com o objetivo proposto.
Desta forma, tornou-se necessário adaptar o modelo para a análise comparativa de
linguagens de programação, elencando as características e subcaracterísticas que são
relevantes a este tipo de comparação. Assim foram definidas as seguintes características
como critérios de avaliação, a serem aplicados na análise comparativa:
a) produtividade/custo: modificando o modelo proposto, a fim de atender a
análise comparativa, foi incluso o item produtividade na categoria funcionalidade, onde
Sebesta (2003) alega que de todos os fatores que contribuem para os custos da
linguagem, três são os mais importantes: desenvolvimento do programa, manutenção e
confiabilidade – uma vez que essas são funções da capacidade de escrita e da
legibilidade;
b) usabilidade: nas linguagens de programação pode-se avaliar a dificuldade de
entendimento (inteligibilidade) dos padrões utilizados nela, assim como o custo de
aprendizado (apreensibilidade) dos programadores que estão ingressando na mesma;
c) eficiência: através de programas gerados pela linguagem de programação, é
possível medir o tempo de execução de determinado rotina ou caso de uso e quanto
recurso de hardware foi utilizado para essa execução;
d) manutenibilidade: o quanto a estrutura da linguagem auxilia na detecção de
falhas (analisabilidade), assim como na alteração de códigos existentes
(modificabilidade);
e) confiabilidade: capacidade do programa em executar de acordo com as suas
especificações sob todas as condições.
A definição por estas características da qualidade e o entendimento de cada uma
delas guiou a seleção das características das LPS a serem empregadas na comparação.
3. Características das Linguagens de Programação

Para se tratar cientificamente a programação, deve ser possível especificar
precisamente as propriedades necessárias dos programas. O formalismo não é
necessariamente um fim por si só. A importância das especificações formais deve, no
final, se justificar pela sua utilidade – sejam elas usadas ou não para melhorar a
qualidade do software ou reduzir os custos de produção e manutenção de software (J.
HORNING apud TUCKER; NOONAN, 2008).
_______________________________________________
20
As características de linguagens de programação avaliadas neste trabalho são:

a) ortogonalidade: uma linguagem é dita ortogonal se os seus comandos e
recursos são construídos sobre um conjunto pequeno e mutuamente independente de
operações primitivas. Quanto mais ortogonal uma linguagem, menos regras
excepcionais são necessárias para escrever programas corretos. Assim, programas
ortogonais tendem a ser mais simples e claros (TUCKER; NOONAN, 2008). Portanto,
ortogonalidade é um número reduzido de construções primitivas e um conjunto
consistente de regras para combiná-las. A ortogonalidade está estreitamente relacionada
à simplicidade, pois quanto mais ortogonal é a linguagem, menos exceções as regras das
linguagens exigirão, significando assim, um grau mais elevado de regularidade na
mesma, tornando-a mais fácil de ser aprendida, lida e entendida (SEBESTA, 2003). Por
outro lado, demasiada ortogonalidade pode resultar em prejuízo para a capacidade de
escrita, devido a pouca quantidade de construções primitivas;
b) simplicidade global: é o resultado de uma combinação de um número
relativamente pequeno de construções primitivas e uso limitado do conceito de
ortogonalidade (SEBESTA, 2003). A simplicidade global afeta fortemente a
legibilidade de uma linguagem. Uma linguagem com um grande número de
componentes básicos é mais difícil de ser aprendida. Os programadores que precisam
usar uma linguagem grande tendem a aprender um subconjunto dele e ignorar seus
demais recursos, porém linguagens muito simples tornam os programas menos legíveis
(TUCKER; NOONAN, 2008);
c) legibilidade: é a facilidade que os programas podem ser lidos e
compreendidos. Um grande exemplo de uma estrutura de controle que afeta diretamente
a legibilidade é o comando GO TO, pois determina onde o fluxo de instruções irá
continuar. Logo, um programa que pode ser lido de cima a baixo é muito mais fácil de
ser entendido do que um programa que exige o leitor pular de uma instrução a outra
não-adjacente para seguir a ordem de execução (SEBESTA, 2003);
d) tipo de dados e estrutura: uma variável que represente verdadeiro ou falso é
muito mais legível se puder atribuir true/false do que 1/0. Quanto mais próximo da
realidade for a estrutura, mais fácil dela ser entendida e representada corretamente;
e) sintaxe: é um conjunto de regras que define a forma de uma linguagem,
estabelecendo como são compostas as suas estruturas básicas. Para Sebesta (2003), a
sintaxe afeta diretamente a legibilidade da linguagem de programação. Restrições, como
o limite de caracteres na definição de identificadores, prejudicam a interpretação do
código escrito, porém recursos como palavras reservadas e identificação de início e fim
de blocos, auxiliam para uma maior legibilidade;
f) capacidade de escrita: é uma medida de quão facilmente uma linguagem pode
ser usada para criar programas para um domínio de problema escolhido. Comparar a
capacidade de escrita de uma linguagem não é fácil, varia de acordo com o propósito de
cada linguagem (SEBESTA, 2003);
g) abstração: significa a capacidade de definir e, depois, de usar estruturas ou
operações complexas de uma maneira que permita ignorar muitos dos detalhes. A
abstração é um aspecto fundamental do processo de projeto de programas. Os
programadores gastam muito tempo construindo abstrações, tanto de dados quanto
_______________________________________________
21
procedurais, para explorar a reutilização de código e evitar reinventá-lo (TUCKER;

NOONAN, 2008). Bibliotecas que acompanham linguagens modernas de programação
comprovam a experiência acumulada de programadores na construção de abstrações;
h) expressividade: é a função entre a computação realizada e a quantidade de
comandos utilizados, ou seja, quanto maior for a computação realizada e menor seja o
programa, maior será a expressividade da linguagem (SEBESTA, 2003);
i) verificação de tipos: característica que a linguagem possui para testar se
existem erros de tipagem de dados em determinado programa, seja pelo compilador ou
durante a execução do programa (SEBESTA, 2003);
j) tratamento de exceção: capacidade de uma linguagem constatar que ocorreu
algo inesperado e permitir tratar tal situação (SEBESTA, 2003);
k) confiabilidade: capacidade do programa de se comportar de acordo com as
suas especificações sob todas as condições. É a necessidade de se projetar mecanismos
apropriados de manipulação de exceções na linguagem. Além disso, linguagens que
restrinjam o uso de aliases e vazamento de memória, que suportem tipagem forte,
tenham sintaxe e semântica bem definidas e que suportem a verificação e validação de
programas têm uma vantagem nessa categoria (TUCKER; NOONAN, 2008). Tanto a
legibilidade como a capacidade de escrita influenciam a confiabilidade. Um programa
escrito em uma linguagem que não suporta maneiras naturais de expressar os algoritmos
exigidos usará, necessariamente, métodos não-naturais. Estes últimos têm menos
probabilidade de estarem corretos para todas as situações possíveis (SEBESTA, 2003).
4. Meio de Avaliação dos Critérios

Com o intuito de quantificar os critérios determinados pela NBR ISO/IEC 9126-
1, pode-se correlacionar estes com as principais características das linguagens de
programação. Assim sugere-se as seguintes correlações apresentadas no quadro 1.
Quadro 1 – Correlação dos critérios com as características
Custo Usabilidade Eficiência Manutenibilidade Confiabilidade

Ortogonalidade X X X X
Simplicidade global X X
Legibilidade X X X
Tipo de dados e estrutura X
Sintaxe X
Capacidade de escrita X X X
Abstração X X X X
Expressividade X X X
Verificação de tipos X X
Tratamento de exceção X X X
Desta forma, ao concluir que determinada característica em uma linguagem é

mais relevante do que em outra, estarão sendo aplicados os critérios de avaliação
estabelecidos pela norma NBR ISO/IEC 9126-1.
Estabelecidas as características das linguagens de programação a serem
avaliadas, foi proposto o seguinte meio de avaliação para cada critério, onde se
_______________________________________________
22
classificou as características em dois grupos distintos, no qual foram denominados pelos

autores de “estático” e “dinâmico”.
O grupo “estático” engloba as características que dispensam implementações
para efetuar a comparação, onde analisando as linguagens e suas estruturas pode-se
estipular uma métrica e verificar qual linguagem possui mais características que
auxiliam a produtividade no desenvolvimento do software. Neste grupo estão atribuídos
os seguintes critérios: usabilidade, manutenibilidade e confiabilidade. Estes critérios
foram classificados como “estáticos”, pois estão diretamente relacionados a itens das
linguagens, tais como: sintaxe, semântica, padrões, estrutura e documentação. Assim
estes foram analisados através de um questionário para avaliar cada linguagem, obtendo
um valor final para distingui-las.
Quanto aos critérios “dinâmicos”, diferentemente dos “estáticos”, necessitam da
implementação do estudo de caso, para que os mesmos possam ser mensurados.
Portanto os itens eficiência e produtividade estão inclusos neste grupo.
Para avaliar a produtividade de cada linguagem, é calculado o Use Case Point
(UCP) por caso de uso e mensurado o tempo de desenvolvimento destes. Assim, a
produtividade está em razão da seguinte função:
Quadro 2. Função estipulada para medir a produtividade.
Produtividade = (tempo de desenvolvimento) / UCP
Ao término do desenvolvimento, são obtidos os valores por caso de uso em cada

linguagem, podendo assim compará-las. Além disto, é possível analisar a eficiência de
cada linguagem, o tempo gasto e o hardware consumido em cada rotina executada.
5. Diferenças entre Groovy e Java

Para Doederlein (2006), a semântica da linguagem Groovy foi planejada para ser
familiar aos programadores Java, pela sua similaridade com os fontes escritos em Java,
reduzindo assim a curva de aprendizagem, porém há diferenças entre as linguagens, tais
como (exemplificadas na Figura 1):
a) objetos: todas as variáveis são instâncias de java.lang.Object - ao contrário
do Java em que há tipos primitivos e não primitivos, em Groovy tudo é considerado
objeto;
b) tipagem dinâmica: ao definir uma variável em Groovy, declarar o tipo dela é
opcional, pois Groovy utiliza duck typing para definir os tipos das variáveis. A definição
de duck typing é: se age como um pato, é um pato. No caso do Groovy, se uma variável
age como um determinado objeto (integer, string), ela será definida como tal;
c) ponto-e-vírgula: se houver apenas um comando na linha, o ponto-e-vírgula,
como delimitador de fim de comando, torna-se opcional;
d) return: dada uma função, o valor de retorno do último comando corresponde
ao valor de retorno da mesma;
e) igualdade: o símbolo == significa igualdade para tudo, diferentemente do
Java, onde == é utilizado para tipos primitivos e .equals() para objetos. Em Groovy é
sempre utilizado == para verificar igualdade;
_______________________________________________
23
f) conceito de verdade: Groovy considera verdadeiro qualquer valor que seja

diferente de null, assim qualquer variável, quando testada, irá retornar true ou false,
desta forma o famoso NullPointerException do Java, deixa de existir no Groovy.
g) concatenação de string: em Java, qualquer objeto para ser concatenado com
string, antes deve ser convertido para string, já em Groovy isto não é necessário, basta
utilizar a seguinte sintaxe: O resultado é ${nome_da_variavel};
Figure 1. Código Groovy
h) laços de repetição: assim como no Java, em Groovy há várias maneiras de

criar laços de repetições, onde o comando while é idênticos nas linguagens, porém o
comando for possui variações.
i) Groovy Beans: para ganhar produtividade no desenvolvimento do código, o
Groovy gera dinamicamente os métodos assessores (getters & setters).
j) GORM: Segundo DICKINSON (2008), Groovy abstrai o mapeamento objeto
relacional e a persistência com o banco de dados através do framework GORM, o qual
gera um ganho de produtividade no desenvolvimento, pois possui métodos padrões de
acesso ao banco de dados, tais como: save, delele, update, get e findBy.
6. Estudo de Caso
Estabelecido o crivo de avaliação, realizou-se a análise do estudo de caso, com o
objetivo de implementar as rotinas deste, tanto em Java quanto em Groovy, tendo como
finalidade a comparação do desenvolvimento entre as linguagens supracitadas.
A análise deste foi modelada através de diagramas UML. Assim foram
desenvolvidos os seguintes diagramas de caso de uso (figura 2).
_______________________________________________
24
Figura 2. Casos de uso do aplicativo exemplo
A figura 3 apresenta o digrama de classes desenvolvido para o estudo de caso.

Para cada classe no diagrama há métodos acessores (getters & setters), porém apenas os
demais métodos serão exibidos, por questão de legibilidade do diagrama. Mais detalhes
podem ser conhecidos em Rezende (2011).
Figura 3. Diagrama de classes do aplicativo exemplo
7. Implementação
7.1. Java
O desenvolvimento do estudo de caso na linguagem Java foi realizado através do
framework jCompany, tendo em vista que Groovy utiliza-se do seu framework para
desenvolvimento web (Grails). Então, para equiparar as linguagens, o autor optou por
este framework nacional e open-source, que traz uma arquitetura de software de alto
nível, reutilizável e extensível (ALVIM, 2011).
Tendo os casos de uso estabelecidos e respectivamente seus diagramas de
classes codificados (classes da camada de modelo), o desenvolvedor utiliza-se dos
wizards disponibilizados pelo jCompany, para configurar e mapear os objetos
relacionais, assim como para gerar a camada de visão, configurando a geração das telas
de consultas e edição.
_______________________________________________
25
Contudo, mesmo observando-se que o jCompany aumenta a produtividade,

comparado ao desenvolvimento totalmente manual, o código gerado necessita de ajustes
para o pleno funcionamento do caso de uso. Outro fato são as configurações persistidas
em arquivos XML, no qual posteriormente podem dificultar a manutenção dos casos de
uso.
7.2. Groovy
Para desenvolver os estudos de caso em Groovy, utilizou-se o framework Grails,
no qual Rudolph (2009) cita que a marcante característica do Grails em apoiar o
desenvolvimento ágil, vem da filosofia de convenção sobre configuração, no qual em
poucos passos é possível configurar o ambiente de desenvolvimento e criar um projeto
web. Assim, efetuado o download do framework, disponível na página (grails.org),
basta descompactar em uma pasta, que será a base deste, e seguir os demais passos:
a) variável de ambiente: criar a variável GRAILS_HOME, e informar o caminho
da pasta onde foi descompactado o framework;
b) path: adicionar o caminho GRAILS_HOME/bin na variável de ambiente
PATH do sistema operacional;
c) testar ambiente: acessar o sistema operacional via linha de comando e
executar o seguinte comando: grails –version.
Com o ambiente de desenvolvimento configurado, o framework está pronto para
criar um novo projeto web, através dos seguintes passos executados via linha de
comando:
a) criar projeto: para criar um projeto execute grails create-app
nome_projeto, o Grails irá criar um projeto com na estrutura MVC;
b) acessar projeto: cd nome_projeto;

c) mapear caso de uso: grails create-domain-class
br.furb.NomeClasse;
d) definir atributos: editar a classe gerada, adicionando os seus devidos
atributos;
e) gerar classe de controle: grails create-controller
br.furb.NomeClasse;
f) scaffolding: após gerada a classe de controle, deve-se editá-la e adicionar o
seguinte comando, static scaffold = true. Este comando irá gerar
todos os eventos padrões da classe de controle, tais como: criar, listar, editar
e excluir (CRUD);
g) gerar a camada de visão: grails generate-views br.furb.NomeClasse;
h) iniciar o aplicativo: grails run-app, este comando irá iniciar o servidor
Jetty, que acompanha o Grails, agora basta acessar o projeto pelo browser,
disponível em: <http://localhost:8080/nome_projeto>
_______________________________________________
26
Ao término destes passos, pode-se observar o quão é produtivo o framework

Grails, devido às suas configurações por convenção, que simplificam o processo e
permitem o desenvolvedor se preocupar apenas com as regras de negócio.
8. Questionário de Avaliação
Para realizar a análise comparativa das linguagens de programação, Groovy e
Java, foi preenchido o questionário apresentado no quadro 3, com o intuito de
evidenciar as diferenças entre as características “estáticas” das linguagens. O
questionário foi respondido pelo autor, baseado nas pesquisas realizadas e em seu
conhecimento e experiência com as linguagens (eventualmente outro desenvolvedor
poderia alcançar resultados um pouco diferentes em função de sua experiência). As
respostas 0, 5 e 10 significam respectivamente “Não”, “Parcial” e “Sim”.
Quadro 3. Questionário comparativo preenchido
CARACTERISTICA PERGUNTA GROOVY JAVA
0 5 10 0 5 10
Há uma única forma para cada construção, ou cada construção pode ser
Ortogonalidade X X
representada por diversas formas?
Existe um padrão na formação de expressões, ou há exceções? X X
A LP possui uma grande quantidade de recursos nativos? X X
Simplicidade Global
É fácil dominar todos os recursos disponibilizados pela LP? X X
A codificação se aproxima da linguagem natural? X X
Existe alguma representação para dados booleanos próximos da
Legibilidade realidade? X X
Há identificação na abertura e fechamento de blocos de comandos? X X
É possível utilizar o comando GOTO? Ou alguma derivação do
comando? X X
Existe limite de caracteres ao definir uma variável? X X
Tipo de dados e estrutura As variáveis necessitam de um tipo? X X
A LP o desenvolvedor criar seus próprios tipos de dados? X X
A LP possui uma documentação completa e de fácil acesso? X X
A LP possui uma padronização para definir atributos, métodos e classes? X X
Sintaxe Existem atualizações da linguagem, adicionados novos recursos ou é
uma LP consolidada e sem alteração? X X
A LP possui palavras reservadas? É possível utilizá-las como nome de
variáveis? X X
Há um conjunto de configurações iniciais pré-estabelecidas? X X
A LP é facilmente adaptável para o desenvolvimento do que se
Capacidade de escrita X X
propõem?
A LP é totalmente orientada objetos ou a LP possui tipos primitivos? X X
A LP é totalmente orientada objetos ou a LP possui tipos primitivos? X X
A LP permite a aplicação das técnicas de abstração como Herança e
polimorfismo? X X
Abstração
A LP possui herança múltipla? X X
A LP sugere a utilização de padrões de projetos? X X
A LP disponibilidade uma grande quantidade de bibliotecas prontas ao
programador? X X
Expressividade
A LP possui facilidades para codificação que geram grande resultado
computacional? X X
Confiabilidade Existe o conceito de ponteiros na LP? X X
Existe um gerenciamento de memória na LP? É necessário informar a
quantidade de memória a ser alocada e desalocá-la manualmente? X X
_______________________________________________
27
Os programas gerados podem executar em qualquer plataforma? X X

Há a verificação de tipo dinamicamente? Antes de compilar ou ao
Verificação de tipos compilar? X X
A LP é fortemente tipada? X X
Existe o tratamento de exceção na LP? X X
Tratamento de exceção
A LP permite tratar diferentes tipos de exceções de formas distintas? X X
As questões que obtiveram respostas distintas foram destacadas para facilitar a

análise. Porém em grande parte do questionário, as linguagens comparadas tiveram
respostas iguais, isto ocorre devido ao fato que Groovy é uma linguagem estendida do
Java, e conseqüentemente herda muitas das suas características.
Baseado no questionário, foi possível concluir que algumas características se
destacam mais em determinada linguagem (quadro 4).
Quadro 4. Características destacadas de cada linguagem.
CARACTERÍSTICA GROOVY JAVA
Ortogonalidade X
Simplicidade global X
Legibilidade X
Tipos de dados e estrutura X
Sintaxe X
Capacidade de escrita X
Abstração X
Expressividade X
Confiabilidade X
Verificação de tipos X
Tratamento de exceção X
Ao responder o questionário, notou-se grande semelhança entre as linguagens,

porém no quadro 4 pode-se observar que Groovy evoluiu sua linguagem aprimorando
recursos em busca de produtividade. Logo, a linguagem conta com uma expressividade
e abstração maior do que o Java. Em contrapartida, fica evidente que o Java é uma
linguagem mais madura e estabelecida, destacando-se características como
confiabilidade e ortogonalidade.
9. Resultados Obtidos
Durante o desenvolvimento dos casos de uso, mensurou-se o tempo gasto em
cada linguagem (Groovy e Java). Obtendo o valor das UCPs de cada caso de uso, o
quadro 5 apresenta o resultado da função de produtividade de cada linguagem.
Quadro 5. Comparativo de produtividade
GROOVY JAVA G-J
CASO DE USO (min) (min) UCP F(GROOVY) f(JAVA) (min) %
UC001 - Manter sprint 80 135 13,6 5,88 9,93 -55 40,74
UC002 - Manter fase 40 75 13,6 2,94 5,51 -35 46,67
UC003 - Manter tarefa 180 265 19,7 9,14 13,45 -85 32,08
UC004 - Manter usuário 130 210 19,7 6,60 10,66 -80 38,10
UC005 - Extrair relatório 240 45 25,9 9,27 1,74 195 -433,33
UC006 - Manter trâmite 150 210 19,7 7,61 10,66 -60 28,57
_______________________________________________
28
UC007 - Manter lançamento 235 360 25,9 9,07 13,90 -125 34,72
Total 815 1255 112,20 41,24 64,11 -440 -
Média 137,83 209,17 18,70 6,87 10,64 -73,33 36,81
Ao analisar os resultados obtidos (quadro 5), pode-se concluir que para

desenvolver em Groovy, o mesmo caso de uso desenvolvido em Java/jCompany, leva-
se aproximadamente 35% do tempo a menos. A opção por outro framework em Java
poderia afetar os resultados do comparativo em termos de produtividade (tanto para
mais quanto para menos).
Com o objetivo de comparar o desempenho dos aplicativos, desenvolvidos em
cada linguagem, com uma massa de dados de aproximadamente 500 registros por
tabela, foram efetuados testes em todos os casos de uso, avaliando as rotinas de
inserção, listagem e exclusão. Para medir a performance dos aplicativos, foi utilizado o
plugin para desenvolvimento web YSlow, o qual calcula o tempo que a requisição
demorou para ser processada. O processamento de ambos foi realizado no mesmo
computador (cliente e servidor), usando a mesma máquina virtual Java.
Quadro 6. Comparativo de desempenho.

Groovy (ms) Java (ms)
CASO DE USO %
Gerar Listar Apagar Média Gerar Listar Apagar Média
UC001 – Manter sprint 1078 674 669 799,67 972 610 595 714,33 10,07
UC002 – Manter fase 809 552 521 622,00 744 516 479 570,20 7,70
UC003 – Manter tarefa 956 224 263 478,67 887 218 242 444,59 6,65
UC004 – Manter usuário 847 235 279 451,33 779 249 247 420,33 6,32
UC005 – Extrair relatório 1843 416 - 1129,50 1807 398 - 1102,50 2,39
UC006 – Manter trâmite 417 241 398 347,67 379 216 356 313,01 9,51
UC007 – Manter
lançamento 389 215 364 320,00 338 198 315 280,00 12,08
Total 6334 2419 2494 4202 5906 2428 2234 3894 -
Média 904,86 374,14 415,67 600,31 843,71 346,87 372,33 556,28 7,82
Com base no quadro 6, pode-se concluir que a linguagem Java possui,

aproximadamente, um processamento de dados 10% mais rápido que o Groovy.
Considerando que Groovy é uma camada acima de Java, este resultado leva a crer que
há rotinas de controle com baixa performance.
Este trabalho não utilizou técnicas de estudos empíricos em engenharia de
software1, as quais podem aprimorar os resultados obtidos. Fica a sugestão para futuras
pesquisas.
10. Considerações Finais

Ao iniciar um projeto com o intuito de desenvolver um software voltado para
web, uma das questões a serem estabelecidas é: qual linguagem de programação
utilizar? Pois esta decisão irá influenciar muitos fatores, dentre eles, a produtividade no
desenvolvimento.
1
Evidence-Based Software Engineering - http://www.dur.ac.uk/ebse/
_______________________________________________
29
Ao término do desenvolvimento do estudo de caso em ambas as linguagens, foi

possível extrair algumas conclusões, tais como: Groovy através de seu framework para
web (Grails) é 35% mais produtivo que Java/jCompany; Java é aproximadamente 10%
mais veloz no processamento das páginas web; Java consome menos de 50% da
memória utilizada pelo Groovy, para executar os mesmos casos de uso; Groovy aloca
cerca de 2500 classes a mais que Java.
Estes foram os principais resultados das características “dinâmicas”. Quanto às
“estáticas” foi possível concluir que a linguagem Groovy se destaca no item
produtividade, pois a mesma conta com características marcantes como: expressividade,
abstração e capacidade de escrita. Percebe-se claramente que Groovy foi projetada para
ser uma linguagem de desenvolvimento ágil, pois conta com inúmeras facilidades e
abstrações. Em contrapartida, ao avaliar a linguagem Java notou-se uma linguagem
mais madura em relação ao Groovy, onde características como ortogonalidade,
legibilidade e confiabilidade destacam o quão Java é estabelecido.
Portanto, tendo os resultados da análise comparativa, resta aos arquitetos e/ou
projetistas decidirem por uma linguagem mais produtiva (Groovy) ou uma linguagem
com mais performance (Java).
Referências
ASSOCIACAO BRASILEIRA DE NORMAS TECNICAS. NBR ISO/IEC 9126-1:
Engenharia de software – Qualidade de produto. Parte 1: Modelo de qualidade. Rio
de Janeiro: ABNT, 2003.
ALVIM, Paulo. Aplicações corporativas com jCompany. Belo Horizonte, 2011.
Disponível em: <http://jcompany.sourceforge.net>. Acesso em: 15 abr. 2011.
DOEDORLEIN, Osvaldo P. Aprendendo Groovy. Java Magazine, São Paulo, ano IV, n.
32, p. 30-44, jan. 2006.
DICKINSON, Jon. Grails 1.1 web application development. Olton: Packt Publishing,
2009.
JAVA. Independent tests demonstrate write once run anywhere capacibilities of java.
Disponível em: <http://www.sun.com/smi/Press/sunflash/1997-
09/sunflash.970918.2.xml>. Acesso em: 20 set. 2010.
JUDD, Christopher M.; NUSAIRAT, Joseph F.; SHINGLER, James. Beginning Groovy
and Grails. New York: Apress, 2008.
OLIVEIRA, Eric. O Universo dos frameworks Java. [S.l.], 2009. Disponível em:
<http://www.linhadecodigo.com.br/artigo/758/O-Universo-dos-Frameworks-
Java.aspx>. Acesso em: 20 set. 2010.
PETERSON, Ronny. Introdução ao Grails. [S.l.], 2010. Disponível em:
<http://speedydev.wordpress.com/category/desenvolvimento-agil>. Acesso em: 21
set. 2010.
REZENDE, Vandir F. Análise comparativa entre Groovy e Java, aplicado no
desenvolvimento web. Trabalho de Conclusão de Curso de Ciências da Computação.
Universidade Regional de Blumenau – FURB. Blumenau, 2011.
_______________________________________________
30
RUDOLPH, Jason. InfoQ: getting started with Grails. [S.l.], 2007. Disponível em:
<http://www.infoq.com/minibooks/grails>. Acesso em: 27 mar. 2010.
SAMPAIO, Antônio B. C. Introdução à ciência da computação. Belém: [s.n.], 1999.
SEBESTA, Robert W. Conceitos de linguagens de programação. 5. ed. Porto Alegre:
Bookman, 2003.
TUCKER, Allen B.; NOOMAN, Robert E. Linguagens de programação: princípios e
paradigmas. 2. ed. São Paulo: McGraw-Hill, 2008.
_______________________________________________
31
Desenvolvimento de um Protótipo para Ensaios de Calibração

do Sistema de Dados Aéreos usando Técnicas de
Processamento de Imagens
Luiz Eduardo Guarino Vasconcelos1,2, Dr. Nelson Paiva Oliveira Leite1, Dr. Carlos
Alberto Murari Pinheiro2, Dr. Otávio Augusto Salgado Carpinteiro2
1: Instituto de Pesquisas e Ensaios em Voo (IPEV), São José dos Campos, SP, Brasil
2: Universidade Federal de Itajubá (UNIFEI), Itajubá, MG, Brasil
du.guarino@gmail.com, pd@ipev.cta.br, {pinheiro, otavio}@unifei.edu.br
Resumo. A primeira Campanha de Ensaios em Voo realizada em uma
aeronave experimental é a calibração do Sistema de Dados Aéreos. Esta
calibração tem o objetivo de aferir duas medidas: altitude e velocidade da
aeronave. Estas informações são primordiais para segurança do voo e são
providas pelo sistema anemométrico da aeronave através da Instrumentação
de Ensaios em Voo. Este método gera erros que corrompem as medidas do
sistema anemométrico. Para minimizar esses erros, um protótipo foi
desenvolvido usando câmera digital de vídeo e técnicas de processamento de
imagens. A avaliação deste protótipo foi realizada com as aeronaves
HELIBRAS H-55 e EMBRAER XAT-26. Os resultados preliminares foram
satisfatórios ao compará-los com o método atual.
1. Introdução
A Campanha de Ensaios em Voo (FTC) é uma atividade da Engenharia Aeronáutica que
tem por finalidade determinar as reais características de uma aeronave e/ou de um
sistema qualquer.
A primeira Campanha de Ensaios em Voo a ser realizada em uma aeronave
experimental é a calibração do Sistema de Dados Aéreos (i.e. Calibração Anemométrica
ou ADS). Neste caso, a aeronave tem as medidas de altitude e velocidade providas pelo
sistema anemométrico [ARANTES 2003] através da Instrumentação de Ensaios em
Voo (FTI) que, naturalmente, corrompem as medidas devido à instalação de erros
inerentes a esta técnica. Estes erros devem ser corrigidos comparando-os com medidas
de referência que podem ser providas por múltiplos sensores, tais como: um sistema de
referência de base de tempo (WRS); um sistema de telemetria (GTS) e/ou sistema de
posicionamento global diferencial (DGPS).
O método mais usado nessa Campanha de Ensaios em Voo é o tower fly-by
[EDWARDS 1966] que necessita do conhecimento exato da altitude de referência da
aeronave. Este método compara a altitude indicada pelo pitot-estático da aeronave com
a pressão da altitude atual para determinar o erro de pressão estática. A determinação
desta diferença de pressão (geralmente conhecida como erro de posição do sistema
estático) através do envelope de voo da aeronave pode ser complexa, consumir tempo
de planejamento e execução, e ser extremamente custosa.
Durante as campanhas de ensaio, os dados da Instrumentação de Ensaio são
recebidos em tempo-real pela telemetria e relacionados com medidas complementares
oriundas de outros sensores (e.g. WRS). A telemetria é uma estação de monitoramento
_______________________________________________
32
onde os dados recebidos são apresentados para que sejam observadas violações dos
parâmetros críticos para a segurança de voo do ensaio. O ruído do sinal e a perda de
informação, que são características inerentes à telemetria, limitam a confiabilidade da
telemetria prejudicando a segurança do voo. Além disso, toda redução de dados requer
um longo tempo de processamento, e desta forma, são realizadas em operações após o
término da Campanha de Ensaios em Voo. Assim, em geral, a eficiência da
Instrumentação de Ensaios não é ótima.
Para aumentar a eficiência e reduzir os custos neste tipo de Campanha de
Ensaios em Voo, foi desenvolvido um protótipo usando técnicas de processamento de
imagem e câmera digital de vídeo. O protótipo foi desenvolvido com apoio do Instituto
de Pesquisas e Ensaios em Voo (IPEV) e da Universidade Federal de Itajubá (UNIFEI).
O protótipo processa todos os dados requeridos durante a realização do voo, calcula a
altitude e a velocidade da aeronave durante a realização da Campanha de Ensaios em
Voo e determina a validade de cada ponto de ensaio em quase real-time. Isto permite
que os resultados e relatórios de ensaios estejam prontos ao final de cada ponto de
ensaio da Campanha.
Este artigo está organizado da seguinte maneira. Na Seção 2, os conceitos e o
cenário da Campanha de Ensaios em Voo estão presentes. Na Seção 3, o protótipo
desenvolvido é apresentado. Experimentos e resultados estão na Seção 4. Por último, o
artigo é concluído.
2. Visão Geral da Calibração do Sistema de Dados Aéreos

A velocidade e a altitude da aeronave são informações essenciais para segurança do
voo. A altitude e velocidade da aeronave são derivadas das pressões dinâmica e estática
da aeronave providas pelo sistema anemométrico de pitot-estático. Em condições ideais,
a Velocidade Verdadeira (Vt) e a Altitude (Zp) [FORNI 1995] são computados com o
conhecimento da Pressão de Pitot (pp), da Pressão estática básica da aeronave (pb), da
medida de temperatura de impacto (Ti) e dos coeficientes calculados dos erros de
posição das pressões estática (∆∆pb) e pitot (∆
∆pp) bem como do fator de recuperação
associado (K) ao sensor (Ti) [ARANTES 2003] (Figura 1).
Deve ser observado que o cálculo da densidade do ar (σ
σ) requer o conhecimento
da pressão estática (pa), de Ti e de K.
Em síntese, o cálculo da altitude e velocidade da aeronave necessita da execução
da calibração em laboratório e da execução de campanhas de ensaio em voo.
2.1. Calibração do Sistema de Dados Aéreos

A calibração do sistema anemométrico consiste de vários pontos de ensaio (TP)
variando de 1.2 vezes a velocidade de stall da aeronave (i.e. Vs) até a velocidade
máxima na horizontal da aeronave (i.e. Vh). De acordo com [PINTO 2007], cada ponto
de ensaio deve ser realizado com altitude básica (Zpb) e velocidade básica (Vb)
estabilizadas como segue:
V bi ≤ Vti ± 5kts eq. 1

∆Zpbi ≤ ±20 ft eq. 2
∆Vbi ≤ ±2kts eq. 3
_______________________________________________
33
Onde:
• ∆Vbi é o desvio máximo da velocidade básica da aeronave no ponto de
ensaio ith (kts);
• Vb i é a média da velocidade básica no ponto de ensaio ith (kts);
• Vti é a velocidade básica programada para o ponto de ensaio ith (kts);
• ∆Zpbi é o desvio máximo da altitude da aeronave no ponto de ensaio ith (ft);
Figura 1. Diagrama de Bloco da Calibração Anemométrica,

adaptado de [LEITE 2009]
A determinação da altitude exata da aeronave a partir de um frame requer que a
aeronave realize o voo em um caminho conhecido, dentro do campo de visão da câmera
passando por pontos de referência (PR). Para cada ponto de ensaio, o piloto de ensaio
deve manter a trajetória da aeronave alinhada com o eixo central da pista.
A Figura 2 mostra um frame da execução de um ponto de ensaio deste tipo de
Campanha de Ensaios em Voo com o helicóptero HELIBRAS H-55 (Esquilo). A
aeronave realiza o voo passando pela Área Válida de ensaio (ARV) indicada pelo
quadrilátero vermelho sobre o eixo central da pista.
A câmera digital é estática e está em local previamente conhecido. Os pontos de
referência estão localizados nos cantos inferiores da Área Válida e são utilizados para
definir a base para cálculo da altitude da aeronave. Estes pontos de referência são placas
metálicas estáticas de 1m2 posicionadas em locais previamente conhecidos, localizadas
próximos à pista.
A distância entre os pontos de referência é de 112.6m ± 0.4m @ 1σ, a partir da
qual são realizadas todas as medições. Pode-se visualizar o local apropriado para este
tipo de ensaio na Figura 3, bem como a disposição da câmera e dos pontos de referência
no local.
_______________________________________________
34
A validade do ponto de ensaio é obtida através da conformidade de todos os

dados adquiridos em relação aos requisitos apresentados no início desta seção. A
ocorrência de qualquer ponto de ensaio inválido requer sua repetição. Portanto, o uso de
aplicações em tempo real permite a aquisição dos dados necessários enquanto a
aeronave realiza o voo, provendo maior segurança no voo, aumentando a eficiência do
ensaio e evitando a repetição de voos, que é uma atividade onerosa financeiramente.
Figura 2. Ponto de Ensaio Válido com Figura 3. Local da FTC

o Helicóptero H-55
3. Desenvolvimento do Protótipo
No desenvolvimento deste protótipo, foi levado em consideração que:
1. As condições metereológicas podem variar rapidamente, de um ponto de
ensaio para outro na mesma Campanha de Ensaios. Desta forma, a imagem de fundo
(i.e. background) a partir do qual o alvo (i.e. a aeronave) é reconhecido, pode ter
mudanças significativas (Figura 4).
2. Embora o centro de cada ponto de referência (PR) seja bem definido
(Figura 5a), a localização deste ponto na imagem resultante (Figura 5b) pode afetar a
exatidão devido à resolução da imagem. Neste exemplo, o ponto de referência capturado
pela câmera é apenas um quadrado de 6x6 pixels.
Figura 5a. Ponto de

Referência Original (PR)
Figura 4. TP Válido com contraste de background Figura 5b. PR provido

diferente pela Câmera
_______________________________________________
35
Para o desenvolvimento deste protótipo todos os vídeos são providos por uma
câmera digital convencional estática em posição previamente conhecida que gera frames
em escala de cinza (i.e. grayscale) ou colorida (i.e. no padrão RGB – Red Green Blue) a
30 frames per second (fps).
Neste protótipo, é considerado que a trajetória da aeronave está alinhada ao eixo
central da pista e que os erros de distorção das lentes da câmera foram previamente
modelados e minimizados usando técnicas tradicionais como em [FU 1987].
Devido às particularidades do local para realização dos pontos de ensaio na
Campanha, não é necessário detectar obstáculos no campo de visão da câmera ou
nuvens durante o ensaio. Além disso, este tipo de ensaio não é realizado em condições
chuvosas.
Cada ponto de ensaio (TP) tem as imagens (vídeos) armazenadas no buffer da
câmera. Ao final de cada ponto de ensaio, o vídeo armazenado é transferido para o
computador através da interface USB (Universal Serial Bus). Depois disso, o buffer da
câmera deve ser limpo para o próximo ponto de ensaio.
Com o vídeo no computador, o protótipo realiza o processamento dos frames
(imagens do vídeo); extrai as coordenadas do alvo de cada frame; corrige as
coordenadas do alvo para minimizar os erros de distorção das lentes da câmera; realiza
o cálculo do TSPI (Time Speed Positioning Information) (i.e. altitude e velocidade);
determina a validade do ponto de ensaio e permite a visualização dos resultados.
O detalhamento desses algoritmos para processamento das imagens e obtenção
dos resultados é mostrado a seguir:
• Detecção dos Pontos de Referência;
• Detecção do Eixo Central da Pista;
• Detecção da Aeronave;
• Cálculo do TSPI; e
• Validação do Ponto de Ensaio
3.1. Detecção dos Pontos de Referência

Inicialmente, uma área na imagem é selecionada pelo usuário ao redor do ponto de
referência (PR). A imagem original é cortada (i.e. cropped) na área selecionada. Na
imagem resultante é aplicado ajuste de contraste usando mapeamento linear, e depois
binarização [KOVASZNAY, 1955].
Depois disso, foi desenvolvido um algoritmo que realiza a busca do centro do
ponto de referência. O centro de referência de cada ponto de referência é usado como
base para o cálculo da altitude e também para delimitar a Área Válida.
Uma vez encontrado o centro do ponto de referência, o ponto de referência é
destacado na imagem original. Caso contrário, uma nova área deverá ser selecionada
pelo usuário.
Este procedimento deve ser realizado para os dois pontos de referência (PR).
_______________________________________________
36
3.2. Detecção do Eixo Central da Pista

Para a detecção do eixo central da pista, deve ser detectada a localização da pista na
imagem, que provê a linha base de referência para cálculo da altitude. Para esta
aplicação em particular, esta referência está localizada a 2 (dois) pixels abaixo do centro
de cada ponto de referência.
3.3. Detecção da Aeronave

Para detectar a aeronave é usado o processo de segmentação [FU 1981] onde cada frame
é dividido em subconjuntos exclusivos, denominados de regiões ou segmentos. Cada
região é homogênea e uniforme, de acordo com algumas propriedades, como textura ou
tom, cujos valores diferem em alguns aspectos e significados das propriedades de cada
região vizinha.
A sequência de frames (It(t)) adquirida pela câmera pode ser colorida (i.e. no
formato RGB) ou em tons de cinza (i.e. grayscale). Caso a imagem seja colorida, ela
deve ser transformada para tons de cinza (Figura 6). Uma imagem colorida no formato
RGB (Red, Green, Blue) possui 3 planos de imagem independente, uma para cada cor
primária. Algumas técnicas de processamento de imagem (e.g. equalização de
histograma) trabalham apenas em um plano de imagem. Ao fazer a conversão de
qualquer plano de imagem colorida para tons de cinza, não há perda de conteúdo e
forma, sendo extremament recomendado para aplicações em tempo-real, pois a
quantidade de informações a ser processada será cerca de 33% da imagem colorida
(WALSH, 1958 e KIVER, 1965). Considerando que a câmera é fixa durante toda a
sequência, o fundo da imagem permanece estático durante o ponto de ensaio, com
algumas mudanças de iluminação.
Deste modo, o primeiro frame do ponto de ensaio pode ser usado como
referência para a imagem de fundo (i.e. background) (IB) do ponto de ensaio todo
(Figura 7).
Figura 6. Imagem de um TP Figura 7. Exemplo de Imagem de

Fundo de um TP
Subtraindo a imagem de fundo (IB) por cada frame subsequente (It) no ponto de
ensaio, tem-se a imagem residual (Irt), que, provavelmente, contém o alvo (i.e. a
aeronave) e mais alguns ruídos.
_______________________________________________
37
Irt xi y j = It xi y j − IBxi y j eq. 4
O próximo passo é detectar as bordas da imagem residual que correspondem às

regiões com mudanças de intensidade. Isso corresponde às regiões de maior intensidade
da função f (x, y) que expressa a intensidade dos pixels da imagem. Desde que a
intensidade de luz da aeronave seja menor que a imagem de fundo, a imagem residual é
computada como:
255, if ( Ibxi y j − It xi y j ) > µ

Irt x, y =  eq. 5
0, if ( Ibxi y j − It xi y j ) ≤ µ
Onde:
• x i y j é a coordenada da imagem;
• µ é a detecção do threshold (i.e. limiar).
O resultado da imagem residual após detectar as bordas na imagem usando o

método de Sobel [GONZALES 2002] é mostrado na Figura 8.
Figura 8. Imagem Residual com Método de Sobel
Depois disso, é realizada a conexão de Componentes Conectados (Connected

Component Labeling ou CCL) [GONZALES 2002] para detectar a aeronave.
Inicialmente, os ruídos (i.e. pepper noises) são removidos. Para isto, são usados
operadores morfológicos (primeiro erosão, depois dilatação) na imagem residual
[SERRA 1988]. Então o CCL pode ser usado. Os CCLs são classificados em ordem
crescente de acordo com o tamanho.
O protótipo verifica a quantidade de CCLs existentes no frame. Normalmente,
deve ter apenas um (01) CCL, que deve ser a aeronave (Figura 9). Entretanto, outros
_______________________________________________
38
objetos podem produzir mais de um componente (CCL) com tamanho semelhante ao do

alvo (e.g. passagem de um caminhão) e, neste caso, o frame é descartado.
Após isto, apenas os pixels do perímetro da aeronave são usados (Figura 10).
Para determinar os pixels do perímetro do componente selecionado (Ca), é usado:
Ca = Vxk yl eq. 6
Onde:
• V é o componente detectado;
• xk é a localização do pixel do perímetro do eixo x;
• yl é a localização do pixel do perímetro do eixo y.
Finalmente, a posição do alvo é considerada a média dos valores da localização
dos pixels de Ca, estimada como:
 1 N
 T N ∑ xk
x =

k =1
N eq. 7
1
 yT = ∑ yl
 N l =1
Figura 9. Exemplo de CCL da Figura 10. Pixels do Perímetro da

aeronave Aeronave
3.4. Cálculo do TSPI

Neste momento, o requisito é encontrar um ponto fixo de referência na aeronave para o
cálculo da altitude e velocidade. Vários testes foram realizados com os seguintes pontos
da aeronave:
• Centróide;
• Bico;
• Cauda; e
• Trem-de-pouso.
_______________________________________________
39
Os melhores resultados foram:

• Centróide para cálculo de altitude em helicópteros.
• A cauda para cálculo de velocidade em helicópteros.
• A cauda ou bico para cálculo de altitude e velocidade para aeronaves de
asa fixa.
Em helicópteros ocorre a mudança da área do helicóptero causada pelo
movimento das pás do rotor principal, inviabilizando o uso do centróide para cálculo da
velocidade e do bico para qualquer cálculo. O trem-de-pouso também não foi
considerado satisfatório devido a ruídos (i.e. pepper noises) próximos a essa região.
Em aeronaves de asa fixa, o trem-de-pouso é usado apenas para velocidades
próximas da stall e, desta forma, foi desconsiderado; além disso, o centróide não teve
bons resultados.
Para aeronaves de asa fixa com hélices no bico, o resultado deve ser semelhante
aos helicópteros em função dos movimentos das pás da hélice, e desta forma, apenas a
cauda deve ser considerada para cálculo.
Assim, com o conhecimento da exata posição dos pontos de referência e do
ponto de referência da aeronave, a altitude pode ser calculada em relação ao eixo central
da pista usando geometria espacial Euclidiana.
A Velocidade Verdadeira ( Vt ) é calculada por:
k∆S
Vt = (m/s) eq. 6
∆t
Onde:
• k é o fator de calibração da imagem, que neste caso é (m/pixel);
• ∆S é o deslocamento em pixel entre dois frames consecutivos (pixels); e
• ∆t é a taxa de aquisição da câmera (i.e. frame rate) (frames/s).
O fator de calibração da imagem é calculado da distância real entre os pontos de
referência (i.e. 112.6m±0.4m@1σ) dividida pelo número de pixels entre eles.
Opcionalmente, esta informação pode ser determinada do tamanho real do ponto
de referência (1m±0.04m @1σ) dividido pela quantidade de pixels referente a esse
tamanho.
3.5. Validação do Ponto de Ensaio

A altitude e a velocidade da aeronave são computadas e armazenadas para cada frame
válido.
Portanto, no final de cada ponto de ensaio, o protótipo verifica a conformidade
dessas medidas com os requisitos apresentados na Seção 2.1 para validar ou rejeitar o
ponto de ensaio.
_______________________________________________
40
Notas:
1. Em função da câmera estar em posição fixa, as etapas 3.1 e 3.2 são
executadas automaticamente no primeiro frame do vídeo para cada ponto
de ensaio;
2. As demais etapas (i.e. 3.3 a 3.5) são executadas em todos os frames
subseqüentes do vídeo no ponto de ensaio corrente.
4. Experimentos e Resultados
Este protótipo foi avaliado com as aeronaves HELIBRAS H-55 (Esquilo) e EMBRAER
XAT-26 completamente instrumentadas durante a campanha de ensaio de calibração
anemométrica do Curso de Ensaios em Voo nos anos de 2010 e 2011.
O protótipo foi avaliado com a execução de 28 pontos de ensaio e um total de
5581 frames.
O protótipo foi desenvolvido em MatLab® e testado com notebook
Intel®Pentium IV Core™ 2 Duo CPU T5800 2.00 GHz, 4 Gb RAM e Microsoft
Windows 7 Professional.
O protótipo executa a 8.5 fps ± 1 fps @1σ. Portanto, os resultados são
produzidos em quase real-time. Considerando as características da aplicação de
calibração anemométrica, este protótipo teve resultados considerados satisfatórios e
todos os pontos de ensaio produziram resultados adequados.
A câmera usada nos testes é uma Sony DSC-HX1 CMOS com aquisição de
vídeos a 30 fps. Vários testes foram realizados com diferentes configurações. O melhor
resultado foi com a resolução de aquisição a 640 x 480 pixels junto com o recurso de
estabilização habilitado, produzindo silhuetas da aeronave melhor definidas.
Para cada frame do ponto de ensaio algumas características são destacadas
(Figura 11):
• A posição do centróide da aeronave (ponto azul);
• A posição como ponto de referência na cauda da aeronave (ponto vermelho);
• A altitude de segurança mínima para realização do ponto de ensaio (linha
vermelha);
• A velocidade (V) e a altitude Zpb (H) calculadas;
• Os pontos de referência (ponto verde); e
• O eixo central da pista (linha branca tracejada)
_______________________________________________
41
Figura 11. Exemplo de TP com aeronave EMBRAER XAT-26
Como exemplo de um ponto de ensaio é apresentada a altitude calculada (Figura

12) e a incerteza associada (Figura 14) que é ±0.0255m @1σ. Na Figura 13 pode ser
visualiza a altitude calculada pelo protótipo e altitude armazenada pelo sistema de
Telemetria (GTS). Observe que há uma oscilação maior que 2 metros na altitude que
pode comprometer o ponto de ensaio e sua segurança.
Figura 12. ‘Medida de Referência e Figura 13. Altitude Calculada e

Altitude Calculada Altitude da Telemetria
Devido a resolução do pixel (i.e. 22.2 x10-02m) e a taxa de aquisição da câmera

(i.e. 30 fps) o deslocamento de um único pixel/frame é equivalente a 24.2 km/h. Na
figura 15 pode ser visualizada a velocidade medida pelo software e a velocidade medida
pela telemetria.
_______________________________________________
42
Figura 14. Incerteza da Altitude Figura 15. Velocidade Calculada

e Velocidade da Telemetria
5. Conclusão
O Desenvolvimento do Protótipo para Ensaios de Calibração de Sistemas de Dados
Aéreos usando Técnicas de Processamento de Imagens produz resultados em quase
real-time o que permite aumentar a segurança do voo e a eficiência do ensaio. Os testes
foram realizados com sucesso já que todos os pontos de ensaio produziram resultados
adequados.
Este protótipo integra várias técnicas de visão computacional e processamento
de imagens e mostrou-se eficiente. O protótipo pode ser customizado para diferentes
modelos de aeronaves. Como resultado, o sistema é flexível e confiável e pode ser
usado para diversos tipos de aplicações. O uso de câmeras digitais e de hardware
convencionais, além da determinação da validade do ponto de ensaio em quase real-
time permite reduzir os custos deste tipo de ensaio.
Os próximos trabalhos são:
• Avaliar o protótipo com outras aeronaves;
• Aumentar o desempenho do sistema usando:
a. Técnicas de Processamento Paralelo; e
b. GPU (Graphics Processor Unit);
• Recuperar imagens diretamente do buffer da câmera; e
• Integrar este protótipo com GPS e GTS para aumentar a segurança dos ensaios
e exatidão das medidas.
6. Referências
ARANTES, R. M., “Introdução a Aerodinâmica Técnicas de Ensaios em Vôo -
Calibração, Documento nº E-B11”, Chapter 2.3, Grupo Especial de Ensaios em Vôo,
2003.
FORNI, A. L. C., “Manual de Aerodinâmica, Documento nº 20-R-AH”, Chapter 3,
Divisão de Ensaios em Vôo, 1995.
EDWARDS, A.F.B., “Flight Test Engineering Handbook – Air Force Technical Report
nº 6273”, Chapter 1, Edwards Air Force Base, 1966.
FU, K. S.; GONZALES, R. C.; LEE, C. S. G.; “Robotics: Control, Sensing, Vision, and
Intelligence”, McGraw-Hill, New York, 1987.
_______________________________________________
43
FU, K. S., e MUI, J. K.. “A Survey of Image Segmentation”. Pattern Recog., vol. 13,
no. 1, pp. 3-16, 1981
GONZALEZ, R.C.; WOODS, R.E.; “Digital Image Processing”, Prentice-Hall, Inc.,
2002.
KIVER, M. S.; COLOR TELEVISION FUNDAMENTALS, MCGRAW-HILL, NEW
YORK, 1965.
KOVASZNAY, L. S. G.; JOSEPH, H. M.; “Image Processing”. Proc. IRE, vol. 43, pp.
560-570, 1955.
LEITE, N. P. O. ; LOPES, L. M. F. ; LIMA, W. O. ; ROBERTO, L. . “The
Development of a Quasi-Real Time Data Processing Tool for the Calibration Flight
Test Campaign of an Air Data System”. In: European Test & Telemetry Conference,
2009, Toulouse. European Test and Telemetry Conference Proceedings. Paris : The
Association Aéronautique and Astronautique de France, 2009. p. 130-135.
PINTO, F. H. L., RODRIGUES, F. W., “Ordem de Ensaio - Calibração Anemométrica
Document nº B11(A)/EFEV”, Grupo Especial de Ensaios em Vôo, 2007.
SERRA, J.; “Image Analysis and Mathematical Morphology”, vol. 2, Academic Press,
New York, 1988.
WALSH, J. W. T.; PHOTOMETRY, DOVER, NEW YORK, 1958.
_______________________________________________
44
Extensão Swarm Intelligence para o Simulador Robocup

Rescue
Alessandro A. Ostetto1, Fernando dos Santos1
1
Universidade Regional de Blumenau (FURB) – Blumenau, SC – Brazil
alessandro@inf.furb.br, fds@furb.br
Resumo. Swarm Intelligence é uma das áreas de estudo da Inteligência
Artificial, que adota conceitos baseados na forma de organização de uma
colônia de insetos para definir as ações de um programa, denominado agente.
Um destes conceitos é o de comunicação pelo ambiente. Este trabalho aplica
este conceito de comunicação pelo ambiente no desenvolvimento de uma
extensão para o simulador de catástrofe RoboCup Rescue. Experimentos
realizados comprovam que o desempenho do sistema multiagente no RoboCup
Rescue é superior quando os agentes coordenam-se utilizando a comunicação
pelo ambiente.
1. Introdução
A área de sistemas multiagentes (SMA) visa o estudo de sistemas onde vários agentes
devem atuar em conjunto buscando atingir um objetivo. Quando este objetivo é
complexo e abrangente, ele pode estar fora da capacidade de um único agente. Então a
solução é a construção de um maior número de agentes, para trabalharem em conjunto e
alcançarem o objetivo, sendo este o conceito de um SMA (WOOLDRIDGE, 2002, p. 3).
Um dos simuladores usados para testar técnicas em SMA é o RoboCup Rescue
(RCR) (ROBOCUP RESCUE, 2010), que trabalha a idéia de programação de SMA para
resolver um problema de resgate de vitimas em catástrofes. O RCR é um simulador de
SMA que apresenta uma situação de catástrofe (causada por um terremoto) com várias
restrições, como bloqueio de ruas, falta de água, falta de energia elétrica e com
limitações quanto ao número de mensagens enviadas entre os agentes. Neste cenário,
vários agentes devem trabalhar em conjunto para efetuar, com a maior eficiência
possível, o resgate das vítimas deste desastre. Cada classe de agente (como exemplo
cita-se: bombeiros e policiais) tem sua função e sua inteligência é programável. Sua
forma de comunicação atualmente é limitada a troca de mensagens.
Swarm Intelligence (SI) é uma abordagem que descreve um comportamento de
integração coletivo-cooperativa entre os agentes de um SMA inspirado no
comportamento das colônias de insetos. Insetos são criaturas simples, com pouca
capacidade de comunicação direta entre si. Para contornar esta limitação e atingir o
comportamento integrado da colônia, os insetos utilizam comunicação indireta, que
ocorre através de feromônios depositados no ambiente e detectados pelos outros insetos.
É interessante notar que, mesmo utilizando a simples comunicação indireta, a colônia de
insetos é capaz de produzir um comportamento integrado bastante complexo, como a
construção de ninhos (formigas) ou colméias (abelhas) (BONABEAU; THERAULAZ;
DORIGO, 1999, p. 26).
_______________________________________________
45
Este trabalho apresenta o desenvolvimento de uma extensão do simulador RCR

que possibilita desenvolver um SMA que utiliza conceitos de comunicação pelo
ambiente definidos pela SI. Para isto foi realizado um estudo aprofundado sobre a
arquitetura do RCR, e alteradas as suas classes responsáveis por gerenciar os objetos do
mundo, permitindo assim o depósito e leitura de feromônios. Além destas alterações, foi
desenvolvido um novo componente para o RCR, responsável por gerenciar os
feromônios.
Para testar a extensão foi desenvolvido um time de agentes que utilizam a
comunicação pelo ambiente disponibilizada pela extensão. O desempenho deste time foi
comparado com um time de agentes que não utilizam comunicação pelo ambiente. Os
resultados dos experimentos demonstraram que a extensão proposta é funcional, e que o
uso da comunicação pelo ambiente aumenta o desempenho dos agentes.
A seção 2 apresenta os assuntos de funcionamento do simulador RCR e na seção
3 o conceito de SI utilizado no trabalho desenvolvido. Os trabalhos relacionados são
citados na seção 4. O desenvolvimento do trabalho é descrito na seção 5 e os resultados
dos testes na seção 6.
2. Simulador RoboCup Rescue

O simulador Robocup Rescue (RCR) (SKINNER; BARLEY, 2006, p. 633) é uma
iniciativa da Robocup Rescue Simulation League (RRSL, 2010) no intuito de fomentar o
desenvolvimento de um sistema que possa criar planos robustos, dinâmicos e
inteligentes para busca e resgate que auxilie o esforço humano em situações
catastróficas (KITANO; TADOKORO, 2001, p. 40). O RCR é um simulador de
desastres (terremotos) e operações de resgate, onde é possível avaliar a qualidade e
eficiência de abordagens multiagente no que tange ao salvamento de pessoas e
minimização de danos.
O RCR trabalha recebendo como entrada dados geográficos (mapas, ruas,
construções, etc.) e informações sobre o terremoto. Com estas informações o simulador
constrói um cenário imediatamente após a catástrofe acontecer, em termos de estruturas
de construções, bloqueio de ruas e vítimas feridas. Após esta fase, o simulador reproduz
a evolução da catástrofe ao longo do tempo. Esta evolução inclui, por exemplo,
propagação de incêndios para construções inicialmente intactas e agravamentos no
estado de saúde dos civis.
Para lidar com o problema da catástrofe, o simulador incorpora agentes de
campo, que percebem e atuam no ambiente. Os agentes de campo são: brigada de
incêndio, agentes responsáveis pelo combate a focos de incêndio; força policial,
responsável por remover escombros e bloqueios nas ruas e o time da ambulância,
encarregado do resgate de soterrados e/ou feridos. O modo mais rápido para que os
agentes possam cumprir sua missão de resgate é que eles trabalhem em conjunto,
coordenando-se para agir de modo cooperativo. Um exemplo é a ação de um agente
bombeiro em tentar apagar um incêndio. Se a construção for muito grande ele terá
dificuldades para combater este incêndio, mas se vários bombeiros estiverem apagando
o mesmo grande incêndio será muito mais fácil obter sucesso.
O RCR suporta interação entre os agentes através de comunicação por voz ou
por rádio. Em ambos os casos há severas restrições de quantidade e tamanho das
mensagens enviadas, como limite e tamanho das mensagens em 256 bytes, somente
_______________________________________________
46
agentes de campo do mesmo tipo podem enviar mensagens entre si e os agentes só

recebem mensagens enviadas em um raio máximo de 30 metros. Além disso, outro fator
que dificulta muito a comunicação é o fato da ocorrência de ruídos, fazendo com que
em alguns momentos, as mensagens não sejam transmitidas corretamente.
Para avaliar o desempenho dos agentes, o RCR define um score. Este score leva
em consideração vários quesitos, como a quantidade de civis resgatados e também a
quantidade de dano causado pelo fogo às construções. A fórmula utilizada para o
cálculo do score é apresentada no Quadro 1, onde P é quantidade total de agentes
vivos; H é a soma dos níveis de saúde dos agentes; Hinicial é a soma dos níveis de saúde
dos agentes no início da simulação; B é a soma da área construída preservada; e Binicial é
a soma da área construída no início da simulação.
2.1. Especificação do Simulador RCR

O simulador é desenvolvido na linguagem Java e totalmente baseado em orientação à
objetos. A fim de detalhar a implementação e o funcionamento do simulador, a Figura 1
apresenta um diagrama de componentes, com os componentes que formam o RCR.
cmp Component Model
Simulator
TrafficSimulator
H B
Simulator score = P + ∗
H B
Simulator
Kernel FireSimulatorWrapper
Fonte: adaptado de (RRSL, 2010, p. 9)

Simulator
IgnitionSimulator Quadro 1. Fórmula de cálculo
do score
CollapseSimulator
Simulator
ClearSimulator
Simulator
Figura 1. Diagrama dos componentes

que formam o simulador RCR
O RCR é formando por um kernel e por outros simuladores. O kernel é o
componente principal do simulador responsável por gerenciar a simulação. Ele
determina a percepção dos agentes, recebe os comandos dos agentes, e transmite estes
comandos aos outros simuladores para que interpretem e executem o que foi
requisitado. Após a execução dos simuladores, o kernel efetiva as alterações no mundo,
atualiza o score e inicia um novo ciclo atualizando a percepção dos agentes.
Cada simulador tem uma função no RCR sendo responsável por interpretar
comandos ligados a sua simulação. O simulador de tráfego (TrafficSimulator) é
responsável por gerenciar a movimentação dos agentes recebendo comandos de
deslocamentos com o caminho escolhido pelo agente. O ClearSimulator é responsável
por executar os comandos de limpeza de bloqueios. Já o simulador de colapso
(CollapseSimulator) é responsável por gerar os bloqueios e os incêndios iniciais. O
IgnitionSimulator tem a função de gerar novos incêndios. O simulador
FireSimulatorWrapper é responsável por gerenciar os incêndios no mapa, causando
dano às edificações e também por interpretar os comandos para apagar estes incêndios.
Por uma limitação de espaço, mas sem comprometer o entendimento, omitiu-se neste
artigo a enumeração e descrição destas classes. O leitor interessado poderá encontrar a
enumeração e descrição destas classes em (Ostetto, 2011).
_______________________________________________
47
3. Swarm Intelligence
Existem na natureza espécies de insetos que vivem em colônias, denominados de
insetos sociais (por exemplo, formigas, cupins, abelhas). Estes insetos, apesar de
simples são capazes de desenvolver tarefas complexas, por exemplo: a construção de
formigueiros e colméias; busca diária de alimentos para sobrevivência da colônia.
Nestas colônias cada indivíduo tem uma classe e cada classe tem funções específicas
dentro da colônia. Todas estas funções são necessárias para o objetivo da colônia que é
a sobrevivência (BONABEAU, THERAULAZ, DORIGO, 1999, p. 1).
É deste princípio que parte a área de estudo da SI, onde são aplicados os
conceitos dos insetos sociais na área de SMA. Um destes conceitos é o de comunicação
pelo ambiente1. Este termo se refere à utilização do ambiente para comunicação entre
indivíduos onde não ocorre troca de mensagens diretamente, mas sim pelo ambiente,
através de feromônios. Feromônio é uma substância química, que um indivíduo deposita
no ambiente, e que é sentido por outros indivíduos. O feromônio depositado no
ambiente evapora com o passar do tempo. O tipo de feromônio e também a quantidade
existente transmitem a informação desejada, estabelecendo desta forma a comunicação
(BONABEAU, THERAULAZ, DORIGO, 1999, p. 14).
A comunicação através do ambiente é verificada, por exemplo, nas formigas,
quando se coloca uma fonte de comida separada do ninho das formigas por uma ponte
de dois galhos aparentemente iguais. Inicialmente não há feromônio em nenhum dos
dois galhos que têm a mesma probabilidade de serem selecionados pelas formigas.
Eventualmente fatores aleatórios fazem com que algumas formigas a mais passem por
um determinado galho, por exemplo, o galho “A” em vez do outro. Por haver mais
formigas depositando feromônio enquanto andam no galho “A” as outras formigas
sentirão mais estimuladas a passarem também pelo galho “A”. Ao se colocar galhos de
comprimentos diferentes, como mostra a Figura 3 (a), as formigas escolhem
inicialmente o caminho do mesmo modo que antes, aleatoriamente. Porém, após um
tempo há uma diferença na escolha de um único caminho, Figura 3 (b). As formigas que
escolheram o caminho mais curto são as que chegam antes ao outro lado e que voltam
antes ao ninho, marcando o caminho percorrido com seus feromônios. Após estas
formigas retornarem há mais concentração de feromônio no caminho mais curto do que
no outro galho mais longo, pois ocorreu evaporação dos feromônios previamente
depositados. Desta forma, as outras formigas são estimuladas a escolherem o galho mais
curto também.
Após diversas análises neste experimento Deneubourg et al. (1990, p. 159-168)
desenvolveu um modelo matemático para representar este fenômeno, tendo por base que
a quantidade de feromônio em um galho é proporcional ao número de formigas que
passaram por ele (assumindo que cada formiga deposita uma unidade de feromônio).
Assim, seus autores concluíram que a escolha de um caminho na ponte depende
diretamente do número de formigas que passaram por este caminho.
Mais precisamente, tem-se 𝐹 e 𝐹 como a quantidade de feromônio depositada
nos ramos A e B após i formigas usarem a ponte. A probabilidade PA que a formiga (i +
1) escolha ramo A é modelada conforme a equação apresentada no Quadro 2. O
1
Em inglês o termo utilizado para definir este conceito é "stigmergy". Não existe termo equivalente em
português.
_______________________________________________
48
parâmetro n determina o grau de não linearidade da função de escolha: quando n é

grande, se um ramo tem apenas um pouco mais de feromônio do que a outro, a formiga
que passa ali terá uma alta probabilidade de escolhê-lo. O parâmetro k quantifica o grau
de atração de um ramo sem marcação: quanto maior k, maior será a quantidade de
feromônio para fazer a escolha não aleatória. Esta equação pode ser adaptada para
denotar situações onde existem várias opções para o caminho escolhido pela formiga,
bastando que o divisor da fração seja composto pelo somatório dos feromônios de todos
os caminhos possíveis que seguem a partir de um determinado ponto.
𝑘+𝐹
𝑃 =
𝑘+𝐹 + 𝑘 + 𝐹
Fonte: Bonabeau, Theraulaz e Dorigo (1999,
p. 27).
Quadro 2. Equação da probabilidade de
escolha da formiga em relação aos
feromônios nos caminhos.
Fonte: adaptado de Bonabeau, Theraulaz e

Dorigo (1999, p. 29).
Figura 2. Evolução do experimento com
relação à escolha das formigas por meio
de feromônios.
Em situações onde a quantidade de feromônio depositada por cada formiga no

caminho é diferente de 1 unidade, Bonabeau, Theraulaz e Dorigo (1999, p. 43) afirmam
que as quantidades depositadas por cada formiga devem ser somadas e adicionadas à
quantidade existente no caminho, conforme apresenta a equação do Quadro 3. Nesta
equação, m é a quantidade de formigas que passaram pelo caminho R, e ∆(𝐹 ) é a
quantidade de feromônio depositada pela formiga i no caminho.
Nesta equação, m é a quantidade de formigas que passaram pelo caminho R, e
∆(F ) é a quantidade de feromônio depositada pela formiga i no caminho.
F =F + ∆(F ) F = (1 − p) ∗ F
Fonte: Bonabeau, Theraulaz e Dorigo
Fonte: Bonabeau, Theraulaz e Dorigo (1999, p. 43).
(1999, p. 43).
Quadro 4. Equação para a
Quadro 3. Equação para adição de evaporação de feromônio.
feromônio em unidades maiores que 1.
Para modelar a evaporação de feromônio, Bonabeau, Theraulaz e Dorigo (1999,

p. 43) propõem o uso de um coeficiente de evaporação, que seria responsável por
determinar a quantidade de feromônio a ser evaporada do ambiente. A sua importância
se deve ao fato de que através da evaporação do feromônio as formigas deixam de
serem atraídas para um caminho que não é mais importante para a colônia. Por
exemplo: uma rota para busca por alimento que deixou de ser usada, pois o alimento ali
contido acabou. A evaporação feromônio 𝐹 existente em um caminho R qualquer, é
_______________________________________________
49
sugerida por Bonabeau, Theraulaz e Dorigo (1999, p. 43) conforme a equação no

Quadro 4. Nesta equação, p é o coeficiente de evaporação, um número real que pode
variar entre 0,1 e 1,0 e 𝐹 a quantidade de feromônio presente no caminho.
4. Trabalhos Relacionados
Em seu trabalho, Kassabalidis et al. (2001), desenvolve uma pesquisa sobre um
algoritmo de roteamento para redes baseado no conceito de SI de comunicação entre os
agentes pelo ambiente. Esta idéia é baseada na forma de exploração do ambiente pelas
formigas, que marcam o caminho com feromônio. Em seu algoritmo, chamado AntNet,
este principio é utilizado para a construção da tabela de roteamento. Esta tabela é gerada
por agentes que exploram a rede decidindo sua rota de forma aleatória com a influência
de feromônio presente nela.
Outro trabalho relacionado é o de Santos (2009), onde é apresentado um
algoritmo de alocação de tarefas entre agentes baseado em SI. Este conceito é baseado
na divisão de trabalho e no processo de recrutamento para transporte presente em
algumas espécies de insetos sociais. Este algoritmo foi desenvolvido para ter eficiência
até mesmo em situações com restrições no ambiente para comunicação e tempo. Um
dos ambientes utilizados para testes é o do simulador RCR, onde foi comprovada a
eficiência do algoritmo. Ainda é sugerida pelo autor a incorporação da comunicação
pelo ambiente em seu algoritmo, eliminando assim a comunicação direta.
5. Desenvolvimento da Extensão
A extensão SI deve incorporar no RCR o conceito de comunicação pelo ambiente, ou
seja, comunicação entre os agentes através de feromônios. Para tanto a extensão deve
oferecer um modo para que o agente possa depositar e ler os feromônios, de acordo com
as equações descritas na seção 3. Se for possível para o agente depositar feromônios,
será possível desenvolver um SMA que utilize estes conceitos para sua movimentação e
assim realizar a comunicação pelo ambiente. Além da possibilidade de depositar e ler os
feromônios a extensão deve possuir um mecanismo para realizar a evaporação do
feromônio, para que o caminho marcado perca a influencia do feromônio com o passar
do tempo, conforme descrito na seção 3.
5.1. Especificação da comunicação

Optou-se por escolher o simulador de tráfego para realizar o depósito de feromônio.
Este simulador é responsável pela movimentação dos agentes no mapa, assim quando o
agente envia um comando de movimentação, será indicado se é preciso ou não marcar
as ruas depositando o feromônio, de acordo com a equação apresentada no Quadro 3.
A Figura 5 apresenta o diagrama com as classes do RCR que necessitam ser
complementadas para possibilitar o processo da comunicação pelo ambiente. Estas
alterações são necessárias para permitir ao agente o depósito e leitura da quantidade de
feromônio presente nas ruas. A quantidade a ser depositada por cada agente na rua é
definida através do parâmetro pherormone.charge_coef do arquivo de configuração
traffic.cfg lido pelo TrafficSimulator.
_______________________________________________
50
class Class Model
ChangeSet
+ addChange(Entity, Property) : void

Config
+ merge(ChangeSet) : void
StandardSimulator
TrafficSimulator
- CHARGE: String = pherormone.char... {readOnly}

- pherormone: double
- handleMove(AKMove, ChangeSet) : void

+ postConnect(Connection, int, Collection<Entity>, Config) : void
# processCommands(KSCommands, ChangeSet) : void
StandardPerception
+ addRoadProperties(Road, ChangeSet) : void

+ getVisibleEntities(AgentProxy) : void
Road
- pherormone: DoubleProperty
+ chargePherormone() : void AKMov e

+ getPherormone() : double
+ getPherormoneProperty() : DoubleProperty - mark: BooleanComponent
+ getProperty(String) : Property
+ isPherormoneDefined() : boolean + AKMove(EntityID, int, List<EntityID>)
+ Road(EntityID) + AKMove(EntityID, int, List<EntityID>, boolean)
+ Road(Road)
+ setPherormone(double) : void
+ undefinePherormone() : void
LineOfSightPerception
StandardAgent
+ addRoadPropertiest(Road, ChangeSet) : void
+ sendMove(int, List<EntityID>) : void + getVisibleEntities(AgentProxy) : void
+ sendMove(int, List<EntityID>, boolean) : void
AbstractAgent
+ processSense(KASense) : void
«interface»
Perception
AgentProxy
+ sendPerceptionUpdate(int, ChangeSet, Collection<? extends Command>) : void

+ think(int, ChangeSet, Collection<Command>) : void
Figura 3. Diagrama de classes com as classes alteradas no simulador
5.2. Especificação da Evaporação de Feromônio

Para possibilitar a evaporação da quantidade de feromônio de todas as ruas é necessária
a especificação de um simulador que fique responsável por esta tarefa. Este simulador
será chamado de PheromoneSimulator e será um componente associado ao Kernel da
mesma forma que os outros simuladores, como apresentado no diagrama de
componentes da Figura 5. A evaporação de feromônio é necessária para que, quando
uma rua não for marcada por certo tempo ela não terá mais a influencia do feromônio na
escolha do caminho pelo agente.
A Figura 5 apresenta o digrama de classes do componente
PherormoneSimulator. A classe PheromoneSimulator estende o AbstractSimulator
que se relaciona com o WorldModel dando acesso ao mundo para alterar a propriedade
de feromônio presente nas ruas. O processo de evaporação de feromônio executado pelo
simulador depende exclusivamente da existência das ruas, representadas pela classe
Road, com o atributo que representa o feromônio.
O simulador PherormoneSimulator é responsável por gerenciar a evaporação do
feromônio contido nas ruas, de acordo com a equação apresentada no Quadro 4 . Para
executar isto o simulador varre todas as ruas e diminui uma porcentagem do feromônio
contido na rua. Esta porcentagem é pré-definida através de um arquivo de configuração,
denominado pherormone.cfg, e que deve ser informado como parâmetro para o
_______________________________________________
51
PherormoneSimulator. O valor a ser estipulado para a evaporação é indicado pelo

parâmetro pherormone.evaporation_coef
cmp Component Model
dentro do arquivo de configuração.
Simulator
TrafficSimulator
Simulator
Simulator FireSimulatorWrapper
Kernel
Simulator
IgnitionSimulator
CollapseSimulator
Simulator
Simulator
PherormoneSimulator Simulator ClearSimulator
Figura 4. Diagrama de classes com as classes alteradas no simulador

class Class Model
WorldModel
AbstractSimulator Config
PherormoneSimulator
- evaporacao: double = 0
- EVAPORATION: String = pherormone.evap...
Road
- doEvaporation(double) : double
+ getName() : String
# handleUpdate(KSUpdate) : void
# postConnect() : void
# processCommands(KSCommands, ChangeSet) : void
Figura 5. Especificação do componente PherormoneSimulator
6. Resultados e Discussão
Para avaliar extensão, foi implementado um SMA formado apenas por agentes
bombeiros que devem combater incêndios. Este tipo de agente foi utilizado por ter mais
semelhança em sua tarefa com a de uma formiga, já que ele vaga pelo mapa em busca
de um incêndio e quando sua água acaba volta ao seu refúgio para se encher de água e
continuar apagando incêndios. Para comunicação, os agentes utilizam apenas a
comunicação pelo ambiente fornecida pela extensão. A estratégia utilizada para a
implementação do agente foi baseada no sentido de que o agente bombeiro, que será
chamado de SwarmFireBrigade, necessita primeiramente de água para apagar algum
incêndio. Tendo que todos os agentes iniciam com o tanque cheio de água, se o agente
estiver sem água em seu taque, é porque ele estava apagando um incêndio. Então o
SwarmFireBrigade se move para o refúgio mais próximo para reabastecer, sem buscar o
caminho através de feromônios (já que o agente tem registrado a localização de todos os
refúgios no mapa, não precisando assim, procurar pelo local). Enquanto se desloca para
o refúgio, o agente faz a marcação com feromônio do caminho que percorre. Com isto,
_______________________________________________
52
os agentes que estiverem saindo do refúgio, não tendo nenhum incêndio por perto para
apagar, poderão encontrar o incêndio cujo caminho foi marcado. Ao terminar de encher
o tanque, o agente verifica se não há nenhum incêndio em seu campo de visão. Se
perceber um incêndio próximo o SwarmFireBrigade vai em direção a ele para apagá-lo.
Caso contrário, utiliza a estratégia de movimentação a partir da comunicação pelo
ambiente, verificando os feromônios na rua para calcular o caminho a ser seguido de
acordo com a equação de probabilidade mostrada no Quadro 2.
Os experimentos com o SwarmFireBrigade foram realizados utilizando o mapa
Kobe4, (SOURCE FOURGE, 2003), usado na última competição da RRSL,
apresentado na Figura 6. A simulação não possui civis a serem resgatados, já que não
haverá agentes do time de ambulância. Foram realizados experimentos com 20 e 40
agentes bombeiros, sendo que no caso de 40 agentes, os 20 agentes adicionais tiveram
como posição inicial a mesma dos 20 primeiros. Os experimentos avaliaram o efeito no
score de diferentes quantidades de feromônios sendo depositados pelos agentes em cada
rua a medida que se movem pelo ambiente (a saber, 1, 5 e 10 unidades de feromônio).
Também foi avaliado o efeito de diferentes percentuais de evaporação (mostrado no
quadro XX), sendo testados os seguintes percentuais: 0% (nenhuma evaporação), 25%,
50%, 75% e 100% (evaporação total). Os resultados (scores) apresentados a seguir
representam uma média de 3 execuções.
A Tabela 1 apresenta o score obtido quando os agentes depositaram 1 (uma)
unidade de feromônio em cada rua. A coluna Qtd. de Bombeiros se refere ao número de
agentes bombeiros utilizados nas simulações. A coluna % de Evap. diz respeito ao
coeficiente de evaporação adotado. O fato de o score ser maior significa que o time de
agentes teve um desempenho melhor, conseguindo salvar uma área maior de
construções no mapa. Em negrito é destacado o melhor resultado para cada quantidade
de bombeiros.
Para efeito de comparação, foram executados experimentos no mesmo mapa, e
com as mesmas quantidades de agentes, mas com um time de agentes que não utiliza a
marcação de caminho por feromônio. A estratégia destes agentes é a de, se estiver com
água, procura por incêndio próximo, se estiver sem água vai até o refúgio. Se estiver
com água e achar um incêndio, vai apagar o incêndio através do trajeto mais curto. Se
não achar o incêndio vaga pelo mapa aleatoriamente até encontrar um incêndio. Este
agente é distribuído junto com o código fonte do simulador, e chama-se
SampleFireBrigade. A Tabela 2 apresenta os resultados obtidos com o
SampleFireBrigade.
Mediante os resultados apresentados observa-se que com o depósito de 1
unidade de feromônio para um time de 20 agentes SwarmFireBrigade (com
comunicação pelo ambiente) os resultados obtidos se aproximam com os de um time de
mesmo número de agentes SampleFireBrigade (sem comunicação pelo ambiente). Isto
se deve ao fato de que as ruas, no inicio da simulação, não estavam marcadas com
feromônios indicando a direção dos incêndios. Assim os agentes vagaram de forma
aleatória até encontrarem um incêndio e o apagarem. Com relação aos experimentos
realizados com 40 agentes SwarmFireBrigade, os resultados obtidos demonstram que
houve maior score em relação ao time de agentes SampleFireBrigade. O fato pode ser
justificado devido a existência de maior número de agentes no mapa agindo na tarefa de
combater os incêndios, levando a maior depósito de feromônio nas ruas devido à
_______________________________________________
53
movimentação destes agentes em direção aos refúgios. Assim o caminho para os

incêndios permanece marcado por mais tempo e sua marcação tem maior influência na
decisão dos demais agentes.
Figura 6. Imagem com a posição inicial dos agentes no mapa utilizado para
experimentos.
Tabela 1. Resultados das Tabela 2. Resultados Resultados das
simulações com os agentes simulações com os agentes
SwarmFireBrigade depositando SampleFireBrigade.
1 (uma) unidade de feromônio.
Qtd. de Score
Qtd. de % de Score Bombeiros
Bombeiros Evap. 20 0,226364196
20 0% 0,205543138 40 0,239583061
20 25% 0,196124823
20 50% 0,206619558
20 75% 0,223827752
20 100% 0,193934737
40 0% 0,356805741
40 25% 0,263814039
40 50% 0,286295404
40 75% 0,269387903
40 100% 0,258381419
A Tabela 3 apresenta o score obtido quando os agentes depositaram 5 unidades

de feromônio em cada rua, e a Tabela 4 quando depositaram 10 unidades.
Ao depositarem 5 unidades de feromônio, ainda pode-se notar o melhor
desempenho obtido pelo time com 40 agentes, mas sua pontuação geral diminuiu. A
justificativa para isto ter ocorrido pode ser o fato de que com uma quantidade maior de
feromônio sendo depositada, a rua continua marcada por mais tempo, podendo assim
continuar marcada mesmo quando perder sua importância (no caso, o incêndio ser
apagado ou a construção completamente destruída) No entanto, o time de 40 agentes
ainda tem seu desempenho superior em relação ao time com somente 20 agentes. Já no
caso com 10 unidades de feromônio sendo depositada por cada agente na rua, a
probabilidade de escolha é elevada rapidamente. Assim, as ruas marcadas terão maior
probabilidade de serem escolhidas em muito menos tempo.
_______________________________________________
54
Tabela 3. Resultados das Tabela 4. Resultados das

simulações com os agentes simulações com os agentes
SwarmFireBrigade depositando 5 SwarmFireBrigade depositando
(cinco) unidades de feromônio. 10 (dez) unidades de feromônio.
Qtd. de % de Score Qtd. de % de Score
Bombeiros Evap. Bombeiros Evap.
20 0% 0,206738148 20 0% 0,203687695
20 25% 0,217581256 20 25% 0,190899442
20 50% 0,213188776 20 50% 0,212238217
20 75% 0,204559179 20 75% 0,195587738
20 100% 0,185567313 20 100% 0,218182847
40 0% 0,236505086 40 0% 0,317462211
40 25% 0,275826638 40 25% 0,284331181
40 50% 0,334192962 40 50% 0,323702942
40 75% 0,306718365 40 75% 0,355580613
40 100% 0,309240701 40 100% 0,262838562
A partir dos experimentos realizados pôde-se construir um comparativo dos

melhores resultados obtidos em todos os experimentos, conforme mostra o Quadro 5.
Sampefirebrigade 1 (uma) unidade de 5 (cinco) unidades de 10 (dez) unidades de
feromônio feromônio depositado feromônio depositado
depositado
40 agentes 40 agentes 40 agentes 40 agentes
sem evaporação 0% de evaporação 50% de evaporação 75% de evaporação
0,239583061 0,356805741 0,334192962 0,355580613
Quadro 5. Comparativos entre os melhores resultados
Observa-se que o time de 40 agentes obteve maior pontuação em todos os
experimentos. Isto se deve ao fato de que há um maior número de agentes percorrendo o
mapa durante a simulação. Ainda observou-se que o coeficiente de evaporação tem
relação com a quantidade de feromônio depositado pelos agentes. Quanto maior a
quantidade depositada, maior foi necessário ser o coeficiente de evaporação para que o
desempenho dos agentes não diminuísse. Como há maior quantidade de feromônio
sendo depositada nas ruas pelos agentes a cada ciclo, é necessário que uma maior
quantidade de feromônio seja evaporada para que um caminho que não tem mais
importância deixe de ter influencia na escolha pelo agente durante a simulação.
7. Conclusão
O simulador RCR tem como seu objetivo realizar competições para o
aprimoramento de estudos na área da IA e de desenvolvimento de SMA´s. No entanto, o
simulador não oferecia nenhum recurso em SI tendo somente como opção de
comunicação a troca de mensagens através de rádio. Para eliminar esta limitação, este
trabalho desenvolveu uma extensão SI, que permite desenvolver agentes que utilizam
comunicação pelo ambiente. Os experimentos realizados em um time de agentes que
utiliza comunicação pelo ambiente demonstraram que seu uso é promissor,
proporcionando melhor score do que times de agentes que não utilizam comunicação
pelo ambiente.
Durante o trabalho foi desenvolvido um estudo sobre a área de SMA, principais
conceitos de SI especialmente no que tange a comunicação através do ambiente, neste
caso feromônios. Também foi realizado um profundo estudo no funcionamento e
_______________________________________________
55
estrutura do simulador RCR. Como o simulador RCR é um projeto de dimensões muito

complexas levou-se certo tempo para o entendimento de seu funcionamento e operação,
pois não há documentação disponível referente ao seu projeto e arquitetura.
Para utilizar o simulador com os recurso de SI disponibilizados neste trabalho, é
necessário que o usuário tenha todo o simulador modificado. Outra limitação é em
relação aos cenários utilizados para testes e análises.
Com este trabalho pode-se concluir também que o desenvolvimento de uma
extensão para disponibilizar recursos de SI no simulador RCR é viável, porém torna-se
complexa quando é preciso apenas adicionar códigos ao simulador sem alterar suas
funcionalidades já presentes.
8. Referências
BONABEAU, Eric; THERAULAZ, Guy; DORIGO, Marco. Swarm intelligence: from
natural to artificial systems. New York: Oxford University Press, 1999. 307 p.
DENEUBOURG, Jean-L et al. The self-organizing exploratory pattern of the argentine
ant. Journal of Insect Behavior, United States, v. 3, p. 159-168, 1990.
KITANO, Hiroaki; TADOKORO, Satoshi. RoboCup rescue, a grand challenge for
multiagent and intelligent systems. AI Magazine, [S.l.], v. 22, n. 1, p. 39-52, 2001.
Disponível em:
<http://www.aaai.org/ojs/index.php/aimagazine/article/view/1542/1441>. Acesso
em: 27 mar. 2011.
KASSABALIDIS, Ikas et al. Swarm intelligence for routing in communication
networks. In: GLOBAL TELECOMMUNICATIONS CONFERENCE, 2. , 2001,
San Antonio. Proceedings... Seattle: Washigton University, 2001. p. 3613–3617.
Disponível em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.28.8398&rep=rep1&type
=pdf>. Acesso em: 27 mar. 2011.
OSTETTO, Alessandro A. Extensão swarm intelligence para o simulador robocup
rescue. 2011. 62 f. Dissertação (Trabalho de Conclusão de Curso em Ciência da
Computação), Universidade Regional De Blumenau, Blumenau.
ROBOCUP RESCUE. Tokio, 2006. Disponível em: <http://www.robocuprescue.org/>.
Acesso em: 17 mar. 2011.
ROBOCUP RESCUE SIMULATION LEAGUE. Rules and setup. [S.l.], 2010. 21 p.
Disponível em<http://www.aaai.org/AITopics/assets/PDF/AIMag19-02-2-
article.pdf>. Acesso em: 24 maio 2011.
SANTOS, Fernando. eXtreme-Ants: algoritmo inspirado em formigas para alocação de
tarefas em extreme teams. 2009. 69 f. Dissertação (Mestrado em Ciência da
Computação) – Programa de Pós-Graduação em Computação, Universidade Federal
do Rio Grande do Sul, Porto Alegre.
SOURCE FORGE. Robocup rescue simulation project. [S.l.], 2003. Disponível em:
<http://sourceforge.net/projects/roborescue/>. Acesso em: 18 fev. 2011.
WOOLDRIDGE, Michael J. An introduction to multiagent systems. New York: John
Wiley, 2002. 348p.
_______________________________________________
56
Utilização de Processamento Digital de Imagens e Redes

Neurais Artificiais para Diagnosticar Doenças Fúngicas na
Cultura do Tomate
Felipe S.Vieira1, Rafael Paz1, Clavison M. Zapelini1,2, Adriana S. Zanini 1,2, Eros
Comunello2, Anita M.R.Fernandes2.
1
Curso Graduação em Sistemas de Informação – UNISUL
Tubarão - SC, Brasil.
2
Mestrado em Computação Aplicada – Universidade do Vale do Itajai (UNIVALI)
Itajaí, SC – Brasil
{felipe.vieira,rafael.paz,clavison.zapelini,adriana.zanini}@unisul.br,
{anita.fernandes,eros.com}@univali.br
Resumo: A cultura do tomate é acometida por diversas doenças fúngicas. Na

região sul de Santa Catarina, as de maior incidência são a pinta preta, a
septoriose e a requeima. Estas doenças possuem características e padrões
distintos, e conforme a evolução da doença pode ser confundida, inclusive
pelos especialistas agrônomos. Este artigo aborda o desenvolvimento de um
sistema informatizado que utiliza o processamento digital das imagens da
folhas do tomate, de forma semi-automática, e Redes Neurais Artificiais para
identificar qual doença, dentre as três mencionadas, está atacando uma
determinada plantação. Foram coletadas amostras de cada doença para o
processamento e treinamento da Rede Neural e para a realização dos testes.
Com a realização de testes cruzados e generalizados, foi obtida uma taxa de
acerto superior a 90%.
1. Introdução
O tomate (Lycopersicon Esculentum Mill) é a hortaliça mais popular na refeição do

brasileiro sendo cultivado em todas as regiões do Brasil. São mais de 58 mil hectares
anuais. Somados o tomate de mesa e o tomate para processamento industrial, a
produção anual está em torno de três milhões de toneladas (LOPES; ÁVILA, 2005).
Uma das preocupações dos produtores é o ataque das doenças fúngicas nas plantações,
que podem diminuir significativamente o lucro. O custo de produção do tomate é um
dos maiores em toda a atividade agrícola, justamente pelas pragas que atingem as
plantações e a demora do correto diagnóstico antes da contaminação total da área
plantada (ABCSEM, 2010).
A região Sul de Santa Catarina possui um clima favorável para o cultivo de
tomates, e estima-se um crescimento nos próximos anos em virtude da duplicação da
BR-101. Porém, apesar do clima favorável, as plantações não estão livres das doenças
fúngica. As mais comuns nesta região são a pinta preta, septoriose e requeima.
Para diagnosticar as doenças, em geral, é necessário um técnico agrícola ou
engenheiro agrônomo. Mas, conforme o estágio da doença, nem sempre é fácil fazer o
diagnóstico com precisão, em visitas às plantações, devido a similaridade entre as
_______________________________________________
57
doenças. É importante frisar que o diagnóstico tardio de uma doença pode causar até a
perda total da plantação, ocasionando prejuízos financeiros de grandes proporções
(LOPES e AVILA, 2005).
Os tomaticultores, temendo o aparecimento de doenças, fazem o uso, muitas vezes
desnecessário, de agrotóxicos. O cultivo do tomate é muito suscetível ao aparecimento
de doenças, então, quando o tomaticultor percebe que algo está afetando a plantação, ele
faz a aplicação do agrotóxico sem identificar se realmente é adequado para aquele tipo
de patógeno. Quando, depois da aplicação, o resultado alcançado não foi o esperado, há
uma nova aplicação com outro tipo de agrotóxico. Isso ocorre porque o agricultor não
consegue identificar corretamente a doença, além do fato de que a identificação pode
demorar e, dependendo do fungo que está afetando a lavoura, os danos de produção e
financeiros podem ser muito altos ou, em alguns casos até irreversíveis (LOURENÇO,
2008).
Lourenço (2008) aponta ainda que o aumento da contaminação do tomate, que
cresceu 42% em relação a 2006, se deve ao "uso pouco criterioso" dos agrotóxicos pelos
produtores. “Eles aplicam [agrotóxicos] sem muito critério. Os resíduos permanecem
por causa da frequência com que o produtor aplica, não obedecendo o período de
carência”.
Considerando-se estes fatos e a importância da cultura do tomate, foi constatado,
por especialista da área, a importância do desenvolvimento de uma ferramenta que
pudesse colaborar com os tomaticultores da região sul de Santa Catarina.
De acordo com Khatchatourian e Padilha (2008), técnicas de processamento digital
de imagens aliado a técnicas de reconhecimento de padrões, utilizando inteligência
artificial, vem sendo utilizadas nas mais diversas áreas da agricultura, meteorologia,
médica e astronômica. Uma técnica de reconhecimento de padrões que já é bastante
difundida no reconhecimento de padrões em imagens é a utilização de Redes Neurais
Artificiais, que de modo geral, após um período de aprendizagem (treinamento) passam
a inferir novas situações. Essa dinâmica procura modelar justamente o funcionamento
do cérebro humano.
A partir da extração das características das imagens das folhas contaminadas, as
quais já foram classificadas previamente, é possível treinar uma Rede Neural para que
se possam classificar novas amostras, com base no aprendizado recebido.
Este artigo apresenta uma ferramenta que utiliza os recursos de processamento
digital de imagens e redes neurais para a identificação de doenças fúngicas do tomate,
mais especificamente, a pinta preta, a septoriose e a requeima. Inicialmente é feita uma
breve explanação sobre as características das doenças que são mais frequentes no Sul de
Santa Catarina, além das técnicas de processamento de imagem e reconhecimento de
padrão que podem ser aplicadas em análises similares. Por fim, a metodologia é
descrita e os resultados referente à análise são apresentados.
2. Referencial Teórico
O referencial teórico apresenta alguns conceitos sobre doenças fúngicas, redes neurais
artificiais e processamento de imagens
_______________________________________________
58
2.1. Doenças Fúngicas do Tomate
Um dos maiores problemas da cultura do tomate são os microorganismos causadores de

doenças. Geralmente a produção de esporos por parte dos fungos causa a disseminação
e sobrevivência das diversas espécies de doenças que atacam as plantações de tomate
(LOURENÇO, 2008).
Na região sul de Santa Catarina, dentre as diversas doenças fúngicas existentes na
cultura do tomate, há uma maior incidência da pinta preta, septoriose e requeima. Por
esse motivo, essas doenças foram escolhidas para o desenvolvimento do trabalho.
2.1.1 Pinta Preta
Uma das principais doenças do tomateiro, a pinta preta (alternaria solani), ocorre com
mais frequência quando cultivados em campo aberto (LOPES; AVILA, 2005). A
doença é transmitida pela semente, e seus esporos são conduzidos pelo vento. O fungo
pode permanecer no solo por um período próximo a três anos. A folha apresenta
pequenas manchas circulares de cor marrom-escura (pinta preta). Nessa mancha são
formados os esporos do fungo. Com o aumento das lesões são formados anéis
concêntricos na área atingida. Ataques severos resultam em secagem das folhas mais
velhas, pela coalescência das lesões, que pode expor os frutos à queima pelo sol. A
Figura 1 exibe uma folha do tomateiro que está contaminado com a pinta preta:
Figura 1. Folha contaminada com a pinta preta.

Fonte: Elaboração dos autores (2011).
2.1.2 Requeima
A requeima (phytophthora infestans) é uma doença muito comum e temida pelos

tomaticultores, pois pode danificar totalmente a lavoura em um intervalo curto de dias.
A alta umidade relativa e temperaturas entre 16 e 24°C, favorecem o aparecimento da
doença, sendo que em temperaturas acima de 30°C ela dificilmente ocorre (REIS,
2010). A infecção tem como principal fonte plantas já infectadas, sejam de plantações
de tomate vizinhas, restos de plantações antigas ou outros tipos de plantas que carregam
a doença. Os sintomas mais típicos da doença são observados nas folhas e iniciam-se
com uma lesão aquosa que cresce rapidamente, fica necrosada e com as bordas de um
verde mais claro que o dos tecidos sadios. Sob condições de alta umidade, na face
inferior das lesões, surge um mofo esbranquiçado, formado por esporangióforos e
esporângios do patógeno. A esporulação do fungo é mais freqüente nas bordas das
lesões, onde se encontra o tecido afetado, porém ainda não morto. Quando o ataque é
severo, pode haver coalescência das lesões, com a destruição rápida da folhagem, dando
3
_______________________________________________
59
a ela um aspecto de que foi queimada por geada, daí o nome de “requeima” (REIS,
2010). A requeima pode ser constatada através da Figura 2:
Figura 2. Folha contaminada com a requeima.

2.1.3 Septoriose
Observada com mais frequência em períodos quentes e chuvosos, a septoriose (septoria

iycopersici) raramente afeta os frutos, porém pode diminuir a produtividade, pois reduz
a área foliar responsável pela fotossíntese. Além disso, os frutos são mais expostos a
queimaduras do sol, ficando impróprios para consumo (LOPES e AVILA, 2005). As
maiores fontes de disseminação da doença são as sementes, estacas utilizadas em
lavouras anteriores, soqueiras, restos de plantações e outras plantas infectadas. Os
sintomas iniciais são manchas mais ou menos circulares, com as bordas escurecidas e o
centro na cor de palha, concentradas nas folhas inferiores da planta (LOPES e AVILA,
2005). A Figura 3 exibe a característica da septoriose:
Figura 3. Folha contaminada com a septoriose.

2.2 Redes Neurais Artificiais
Um processador fascinante, composto por neurônios interconectados para permitir a

troca de informações, capaz de realizar processamento matemático, armazenar
informações, reconhecer padrões e aprender: esse é o cérebro humano. Com a intenção
de simular a capacidade cognitiva de um ser humano, foram criadas as Redes Neurais
Artificiais (RNA) (BARRETO, 2002).
Uma rede neural é uma máquina que é projetada para modelar a maneira como o
cérebro realiza uma tarefa particular ou função de interesse. A rede é normalmente
_______________________________________________
60
implementada utilizando componentes eletrônicos ou é simulada por programação em

um computador digital (HAYKIN, 2001).
Basicamente, a projeção de uma RNA implica em duas fases: a arquitetura
(topologia) e o algoritmo de aprendizagem (HAYKIN, 2001).
2.2.1 Arquitetura de Redes

Os neurônios que compõem uma rede neural podem ser estruturados de diferentes
formas, de modo que a organização dessa estrutura classifica as redes em diferentes
arquiteturas. A arquitetura das redes pode ser classificada de acordo com alguns
parâmetros, como número de camadas da rede, número de nodos em cada camada, tipo
de conexão entre os nodos e topologia da rede (BRAGA, CARVALHO e LUDEMIR,
2000) e está diretamente relacionada com o algoritmo de aprendizagem utilizado para
treiná-la (HAYKIN, 2001). Três topologias são utilizadas:
- Redes de camada única: nesta arquitetura as entradas se projetam sobre uma única
camada de neurônios. As saídas destes, por sua vez, não retornam para as entradas
sendo alimentadas somente adiante, sendo assim somente um nó existe entre as entradas
e as saídas.
- Redes de múltiplas camadas: nesta arquitetura várias camadas de neurônios podem ser
configuradas. As entradas se comunicam com a primeira camada de neurônios e a saída
desses, por sua vez, constitui os sinais de entrada aplicados à segunda camada e assim
por diante.
- Redes recorrentes: esta arquitetura comporta tanto redes de única camada quanto redes
de múltiplas camadas. O que diferencia das arquiteturas anteriores é que ela possibilita a
realimentação, ou seja, o sinal de saída de um neurônio pode voltar para a entrada de
todos os outros neurônios.
2.2.2 Processo de aprendizagem em redes Neurais

Da mesma forma que o cérebro humano é capaz de aprender, uma rede neural artificial
também implementa essa funcionalidade, sendo capaz de aprender por exemplos e
posteriormente utilizar este aprendizado para comparar, generalizar e inferir
possibilidades e hipóteses. A implementação da funcionalidade de aprender consiste em
um conjunto de procedimentos bem definidos chamados de algoritmos de
aprendizagem. Mais de um algoritmo de aprendizagem pode ser utilizado para treinar
uma RNA e o que difere um de outro é a maneira pela qual os ajustes dos pesos são
feitos.
De modo geral os algoritmos de aprendizagem estão divididos em dois grandes
paradigmas: Aprendizado supervisionado e não-supervisionado:
- Aprendizado supervisionado: neste método de aprendizado uma entrada e uma saída
desejada para a rede são fornecidas por um supervisor externo que é caracterizado
“professor”, daí advém o nome aprendizado supervisionado que é o mais comum no
treinamento das RNAs.
5
_______________________________________________
61
- Aprendizado não-supervisionado: como o próprio nome sugere, no aprendizado não

supervisionado não há professor ou supervisor para acompanhar o processo de
aprendizagem da rede neural.
Algoritmo comumente utilizado para treinar redes neurais de múltiplas camadas.
Na primeira etapa do treinamento, um padrão é apresentado à camada de entrada da
rede, sendo seu efeito propagado de camada em camada até ser produzida a resposta da
rede pela camada de saída. Na segunda etapa, a saída obtida é comparada com o
resultado esperado. Se o resultado não estiver correto, é feito o cálculo do erro
subtraindo a resposta da rede pela resposta desejada. Com o resultado do erro, é feito o
caminho inverso, a retropropagação, onde os sinais são alterados desde a camada de
saída até a camada de entrada(Mendes e Oliveira,2010)
2.3 Processamento Digital de Imagens

Pode-se considerar uma imagem digital como uma matriz de pontos elementares, de
forma que cada ponto recebe o nome de pixel. A resolução da imagem e seu tamanho
variam conforme a quantidade de pixels da imagem. Seus pixels são representados
individualmente por valores que indicam a intensidade de brilho, denominado níveis de
cinza, e a quantidade de níveis de cinza depende da quantidade de bits usada na
representação de cada pixel (CORREIA e SOUZA, 2007).
O tratamento de imagens é uma forma de modificar ou manipular objetos gráficos
através de um tratamento químico ou óptico, porém, quando se utiliza o computador
denomina-se tratamento ou processamento de imagens digitais (GOYA, 2011).
O processamento de imagens pode ser classificado em cinco tipos básicos de
operações: representação, realce, restauração, análise e compressão (SILVA, 2008).
Na representação de imagens, cada pixel pode ser mensurado em termos de
quantidade e qualidade. Uma imagem pode representar a luminosidade refletida por
objetos em uma cena ou pode indicar a temperatura de uma determinada região.A
restauração da imagem visa minimizar ou remover imperfeições. Ferramentas para
correção de imagens são denominadas filtros. Gerar uma descrição de uma imagem fica
a cargo da análise de imagem. Ao analisar uma imagem, a saída não precisa
necessariamente ser outra imagem, igual ocorre nas operações de representação, realce e
restauração. A saída da análise pode ser um gráfico ou um arquivo contendo
informações das propriedades que se deseja extrair. A compressão da imagem é
necessária devido ao grande número de dados associados às imagens, as técnicas de
redução do tamanho da imagem devem manter a qualidade das informações contidas.
O tratamento de imagens normalmente utiliza funções matemáticas que, modificam
uma imagem original em uma imagem tratada através de equações conhecidas, usando
algoritmos predeterminados (AMARAL, 2010).
2.3.1 Mumford & Shah

O algoritmo de segmentação Mumford & Shah realiza a segmentação da imagem
verificando as regiões que podem se unir através da variação dos pixels. Caso seja
utilizado apenas duas regiões como parâmetro, a imagem ficará dividida de acordo as
_______________________________________________
62
duas cores predominantes. Os pixels assumem o valor da cor predominante mais

próxima (WANGENHEIM, 1998).
2.3.2 Cinza Ponderado

Para converter um pixel para cinza utiliza-se a média dos valores RGB. No cinza
ponderado é utilizado a conversão dos valores RGB para tons de cinza multiplicando o
novo valor de cada pixel (em tons de cinza) por um parâmetro definido anteriormente,
sendo possível atribuir diferentes valores para o vermelho, verde e o azul (RIBEIRO,
2010).
2.3.3 Negativa
O filtro de negativa faz a inversão da ordem do preto e do branco, de modo que
conforme a intensidade de entrada aumente, a intensidade de saída diminua (NETO,
RIBEIRO e VALERI, 2004).
2.3.4 Limiarização
A limiarização é um processo que separa os pixels de uma imagem utilizando a função
threshold, que consiste em receber um valor limiar e o pixel inferior a esse valor
converte para preto e o superior converte para branco (DUTRA, ERTHA e NETA,
2008).
2.3.5 Dilatação
A dilatação faz com que os objetos aumentem, causando um alongamento do elemento
estruturante dentro da imagem (OLIVEIRA, 2003).
3. Trabalhos Correlatos
Metodologias computacionais para processamento e análise de imagens médicas têm

sido utilizadas em diversas pesquisas na área, provendo soluções que auxiliam no
diagnóstico e acompanhamento de doenças e tratamento a partir de imagens.
Trabalhos como de Araujo et al (2011) mostram métodos para detectar e extrair
contornos de lesões de pele, pois através das bordas e da região interna das lesões pode-
se fazer um diagnóstico inicial e visual das lesões.
Há também estudos de lesões em mamografia, buscando classificá-las como lesões
malignas ou benignas, um destes estudos é apresentado por Glingani e Ambrósio
(2009). Neste trabalho são utilizadas imagens segmentadas por um software
especialista, e utilizado dois tipos de rede neural artificial para fazer a classificação das
lesões.
Para abstrair as informações das imagens, a utilização de um conjunto de métodos e
técnicas é necessária para amenizar os ruídos e manter características originais dessas
imagens.
Para auxiliar no diagnóstico são utilizadas diversas técnicas, dentre elas a rede
neural artificial, que é uma técnica que tenta simular o comportamento do cérebro
7
_______________________________________________
63
humano, podendo ser muito eficiente em situações em que se busca classificação, ou

seja, o reconhecimento de padrões.
4. Diagnóstico das Doenças Fúngicas na Cultura do Tomate
A captura das imagens das folhas infectadas na plantação de tomates se deu a partir da
coleta das amostras na própria plantação e a digitalização fotográfica em laboratório.
Uma vez que a folha pode alterar as características em função do tempo da coleta, todas
as imagens foram digitalizadas em um período de no máximo uma hora após a coleta. A
imagem foi capturada com a folha do tomate sobre uma superfície branca porosa para
evitar reflexos na lente da câmera.
Foram coletadas para treinamento da Rede Neural 20 amostras de cada doença, que
já haviam sido diagnosticadas previamente por especialistas agrônomos. A partir da
catalogação das imagens no sistema, as etapas consistem em pré-processamento,
processamento e classificação.
4.1 Pré-processamento
O pré-processamento consiste em uma etapa semi-manual em que o usuário irá
delimitar as manchas mais relevantes na folha da imagem original. Essas marcações são
necessárias uma vez que a variância entre os pixels da cor verde e marrom é muito
pequena, de forma que nenhuma técnica linear de processamento de imagem estudada
foi suficiente para fazer a separação de forma automática.
Após a marcação, o sistema faz a interseção e união dos conjuntos para minimizar a
falha humana na marcação, considerando a média ponderada dos pixels marcados. A
Figura 4 exibe a imagem original (esquerda) e a imagem com a marcação do usuário
(direita). Eventuais falhas na marcação são corrigidas automaticamente nas próximas
etapas.
Figura 4. Pré-processamento semi-manual.

4.2 Processamento
O processamento consiste em etapas de aplicação de filtros e cálculos para extrair as
características da imagem. São seis etapas de processamento, e todas são feitas de forma
automática:
1 – Separação da área da folha: primeiramente, foi utilizado o algoritmo de segmentação
Mumford & Shah. A primeira aplicação do filtro teve o objetivo de separar a área da
folha (tons de verde) do fundo (tons de branco). Utilizando apenas duas regiões, as
pintas são ignoradas, uma vez que a predominância maior na imagem é verde e branco.
A partir da segmentação foi possível rastrear os pixels verdes para calcular a área total
_______________________________________________
64
da folha. A Figura 5 exibe a imagem original (esquerda) e a imagem segmentada

(direita)através do algoritmo utilizando como parâmetros duas regiões.
Figura 5. Separação da área da folha.

2 – Segmentação a partir da marcação do usuário: para reduzir a imagem e tornar o
processamento mais rápido, foi utilizada a segmentação sobre a imagem marcada. Essa
segmentação utiliza duas mil regiões também com o algoritmo Mumford & Shah. O
resultado pode ser visto na Figura 6. Com duas mil regiões, há uma redução nos
detalhes da imagem sem perder sua característica.
Figura 6. Segmentação a partir da marcação do usuário.

3 – Cinza Ponderado: continuando o processamento, foi aplicada a conversão da
imagem para tons de cinza. Para esse tipo de conversão foi utilizada a média ponderada
com os valores 0.299 para os pixels vermelhos (R), 0.587 para os pixels verdes (G) e
0.114 para os pixels azuis (B). Percebe-se que o maior valor é para o verde, uma vez
que é a maior predominância nas imagens analisadas. A conversão para tons de cinza
permite a limiarização mais precisa que será outra etapa. A figura 7 exibe a imagem
segmentada (esquerda) e processada (direita) nesta etapa.
Figura 7. Cinza Ponderado.

4 – Negativa: após as etapas anteriores, a imagem convertida para tons de cinza é
submetida ao filtro de negativa, realçando suas manchas como mostra a imagem da
Figura 8. Essa etapa é necessária para preparar a imagem para ser limiarizada.
9
_______________________________________________
65
Figura 8. Negativa.
5 – Limiarização: O valor limiar utilizado nesta sequência de processamento foi 220,
assim apenas as marcações feitas pelo usuário assumem o valor branco. A Figura 9
exibe a imagem processada com a limiarização.
Figura 9. Limiarização.
6 – Dilatação: após a limiarização, a imagem passa pela dilatação, visando preencher
eventuais falhas de marcação feita pelo usuário e suavizar as bordas da imagem como
mostra a figura 10.
Figura 10. Dilatação.

A extração das características da imagem agora já pode ser feita de forma linear,
selecionando os pixels brancos e seus vizinhos. Para isso se faz a união e interseção dos
pixels marcados e processados, com os pixels da imagem original. A comparação da
média ponderada e mediana é utilizada para reduzir as falhas de marcação dos usuários
e os ruídos da limiarização. Uma função recursiva seleciona os pixels vizinhos para
determinar as coordenadas semelhantes na matriz.
4.3 Classificação
Após o processamento têm-se os valores de entrada da rede neural, que representam as
características extraídas da imagem: área da folha, quantidade de pintas na folha, área
total dos pixels que foram identificados como pinta, percentual das pintas em relação à
folha, média dos pixels RGB de cada pinta. Um arquivo é gerado com as características
extraídas, que por sua vez pode ser utilizado no treinamento da RNA como também no
processo de análise de amostra.
A Rede Neural utilizada para classificação é uma rede de arquitetura de múltiplas
camadas com 7 neurônios na camada de entrada, representando as características
extraídas, 4 neurônios na camada intermediária e dois neurônios de saída, que informam
_______________________________________________
66
qual o tipo de doença encontrado. O algoritmo de treinamento utilizado é o de

retropropagação. A Figura 11 exibe a topologia da rede.
Figura 11. Topologia da Rede Neural.

5. Resultados e Discussões
O teste da rede neural foi realizado de duas formas: teste cruzado e teste generalizado.
No teste cruzado foram utilizadas as amostras do conjunto de treinamento, ou seja, as
amostras utilizadas para o treinamento da rede neural também foram utilizadas para o
teste da rede. No teste generalizado foram utilizadas todas as amostras que não estavam
no conjunto de treinamento, sendo possível nesse caso testar a capacidade de
generalização da rede neural.
A Rede atingiu uma porcentagem de acerto maior que 90% na maioria das
categorias. A Pinta Preta foi a doença que apresentou a menor porcentagem de acerto no
teste cruzado, com 2 de 20 amostras apresentando um resultado incorreto, ainda assim
manteve um nível satisfatório de acerto, com 90% das amostras reconhecidas. A
requeima foi a única categoria de doença a atingir 100% de acerto no teste cruzado.
Para o teste generalizado foram submetidas à rede 32 amostras de Pinta Preta, 24
amostras de Septoriose e 9 amostras de Requeima. A Rede atingiu uma porcentagem
total de acerto de 90,8 %. Desses, 100% de acerto no teste de Pinta Preta. Na Requeima,
atingiu o menor índice de acerto, 77,8%. O número reduzido de amostras da requeima
para o teste generalizado influenciou negativamente no resultado. As Figuras 12 e 13
ilustram os resultados obtidos nos testes:
Teste Generalizado
100
90,8
77,8 83,3
% Acerto
Pinta Preta Requeima Septoriose TOTAL

(32/32) (7/9) (20/24) (59/65)
Figura 12. Teste generalizado.

11
_______________________________________________
67
Teste Cruzado
100
95 95
% Acerto
90
Pinta Preta Requeima Septoriose TOTAL

(18/20) (20/20) (19/20) (57/60)
Figura 13. Teste Cruzado.

Mesmo com o número reduzido de amostras utilizadas no conjunto de treinamento,
a rede neural apresentou uma taxa de acerto acima de 90%. O resultado obtido mostra
que o uso do sistema pode auxiliar na identificação das doenças fúngicas no tomate
como Pinta Preta, Requeima e Septoriose.
Outras doenças que afetam as lavouras de tomate também podem ser incluídas no
sistema informatizado, com o processamento para extração das características e
treinamento da Rede Neural. Também sugere-se como estudo futuro uma forma
automatizada se separação das manchas relevantes, sem que seja necessária a interação
com o usuário na etapa de pré-processamento.
6. Conclusões
A ferramenta não chegou a um produto acabado, mas com certeza pode e deve
servir de caminho para outros projetos, de preferência ainda maiores, que possam
contribuir cada vez mais com a melhoria dos produtos envolvidos no agronegócio. O
desenvolvimento desta ferramenta apresentou algumas dificuldades as quais tentou-se
superar da melhor maneira possível. A quantidade de amostras foi uma das dificuldades
encontradas. Não foi possível encontrar amostras em sites, mesmo consultando
empresas especializadas como a EPAGRI. Então foi realizada a coleta em plantações na
cidade de São Ludgero, onde se conseguiu encontrar as amostras, sendo pinta preta (90),
septoriose (64) e requeima (27). Mesmo com o número reduzido de amostras da
requeima, conseguiu-se treinar a rede neural.
O tempo de processamento das imagens foi, sem dúvida, a maior dificuldade
encontrada. Identificou-se que quanto maior a região afetada da amostra, maior o tempo
de processamento necessário. Algumas amostras chegaram a levar dois dias para serem
processadas (amostras de requeima, que contém praticamente toda a folha afetada). Isto
ocorreu devido ao tamanho da imagem, sendo que quanto maior o tamanho, maior o
número de pixels e inevitavelmente se tem uma maior quantidade de dados a serem
analisados para a extração de características da folha. Uma melhora no algoritmo
utilizado para a verificação das manchas é necessária para viabilizar a utilização de
imagens com tamanho maiores. A marcação da área afetada da amostra foi necessária
devido à dificuldade que se encontrou para separar a cor marrom da cor verde presente
nas imagens. Mesmo com as dificuldades encontradas e o reduzido número de amostras
de requeima, os resultados obtidos foram suficientes para comprovar que o uso do
sistema traz como resposta um resultado satisfatório.
_______________________________________________
68
7. Referências
ABCSEM. Tomate lidera crescimento e lucratividade no setor de hortaliças.
Disponível em: <http://www.abcsem.com.br/noticia.php?cod=284>. Acesso em: 07 set.
2010.
AMARAL, P. M. J. Projecto: nº 08 2010: Análise de imagem: Medição de Área

Florestal. Disponível em: < http://www.di.ubi.pt/~hugomcp/doc/PauloAmaral.pdf>.
Acesso em: 05 fev. 2011.
ARAUJO, A. F.; et al. Uma metodologia híbrida para segmentação de lesões de

pele. WVC 2011 – VII Workshop de Visão Computacional. Disponível em:
<http://HDL.handle.net/10216/55805>. Acesso em: 05 fev. 2011.
BARRETO, J. M. Introdução as redes neurais artificiais. 2002. Disponível em:

<http://www.inf.ufsc.br/.barreto/tutoriais/Survey.pdf>. Acesso em: 01 set. 2010.
BRAGA, A. P., CARVALHO, A. C. P. L. F., LUDEMIR, T. B. Redes Neurais

Artificiais:Teoria e Aplicações. Rio de Janeiro: LTC, 2000.
CORREIA, S.; SOUZA, T. Estudo de técnicas de realce de imagens digitais e suas

aplicações. Disponível em:
<http://www.redenet.edu.br/publicacoes/arquivos/20080127_131848_INFO-022.pdf>.
Acesso em: 12 maio 2011.
DUTRA, L. V.; ERTHA, G. J.; NETA, S. R. A. Limiarização automática em

histogramas multimodais. 2008. 6 f. Instituto Nacional de Pesquisas
Espaciais.Universidade Estadual Paulista de Presidente Prudente, São Paulo, 2008.
GLINGANI, F. A.; AMBRÓSIO P.E.Sistema de Análise Computadorizada para

Auxílio à Detecção de Lesões de Mama Baseado em Redes Neurais Artificiais. In
XXIX Congresso da Sociedade Brasileira de Computação. Jul 2009. Bento Gonçalves –
RS. Disponível em: <http://www.sbis.org.br/cbis9/arquivos/553.pdf>. Acesso em: 05
fev. 2011.
GOYA, E. Introdução ao processamento de imagem. Disponível em:

<http://www.goya.pro.br/aula/dwnload/webdesign/Introd_proc_img.pdf>. Acesso em:
16 maio 2011.
HAYKIN, Simon. Redes Neurais: Princípios e prática. 2.ed. Porto Alegre: Bookman,
2001.
KHATCHATOURIAN, O.; PADILHA, F. R. R. Reconhecimento de variedades de soja

por meio do processamento de imagens digitais usando redes neurais artificiais.
Engenharia agrícola, Jaboticabal, v. 28, n. 4, out./dez. 2008. Disponível em:
<http://www.scielo.br/scielo.php?pid=S0100-
69162008000400016&script=sci_arttext&tlng=e!n>. Acesso em: 18 maio 2011.
13
_______________________________________________
69
LOPES, C. A.; AVILA, A. C. Doenças do tomateiro. Brasília: Embrapa Hortaliças,

2005.
LOURENÇO, L. Tomate, alface e morango são os produtos mais contaminados por

agrotóxicos. 2008. Disponível em: <http://www.brasildefato.com.br/node/1142>.
Acesso em: 25 ago. 2010.
MENDES, D. Q.; OLIVEIRA, M. F. S. Tutorial de redes neurais aplicações em

bioinformática. Disponível em: <http://www.lncc.br/~labinfo/tutorialRN/>. Acesso
em: 12 out. 2010
NETO, G. H.; RIBEIRO, G. C.; VALERI, F.V. Processamento e segmentação de

mamogramas digitais. Disponível em:
<http://www.sbis.org.br/cbis9/arquivos/763.pdf>. Acesso em: 11 maio 2011.
OLIVEIRA, F. M. Ferramentas de pré-processamento de imagens. Disponível em:

<http://bdm.bce.unb.br/bitstream/10483/801/1/2003_Fabr%C3%ADcioMendesdeOlivei
ra.PDF>. Acesso em: 17 maio 2011.
REIS, E.M. et al. Requeima - ameaça à batata e ao tomate. Disponível em:

<http://www.grupocultivar.com.br/site/content/artigos/artigos.php?id=152>. Acesso em:
26 ago. 2010.
RIBEIRO, M. Modelos e modos de cor. Disponível em:

<http://www.est.ipcb.pt/tecnologias/tec_DCG/Teorica/Sebenta%202004%20-
%20Cap%20VI.pdf>. Acesso em: 17 maio 2011.
SILVA, F. C. Um estudo sobre algoritmos genéticos, lógica fuzzy e técnicas para

segmentação e classificação em imagens médicas. Disponível em:
<http://ppginf.ucpel.tche.br/TI-arquivos/2008/PPGINF-UCPel-TI-2008-1-01.pdf>.
Acesso em: 12 de maio 2011.
WANGENHEIM, A. V. Segmentação por crescimento de regiões. Disponível em:

<http://www.inf.ufsc.br/~visao/regiongrow.pdf>. Acesso em: 10 maio 2011.
_______________________________________________
70
Sistema Especialista para Indicação de Medicamentos

Fitoterápicos
Leonardo Veronese Soletti, Sidnei Renato Silveira
baldeco@gmail.com, sidnei@uniritter.edu.br
Centro Universitário Ritter dos Reis (UniRitter) – Curso de Sistemas de Informação

– Porto Alegre
Rua Orfanotrófio, 555 – Bairro Alto Teresópolis – CEP 90840-440 – Porto Alegre – RS
Resumo. Os sistemas especialistas são sistemas que propõem a resolução de

problemas através de uma base de conhecimento, podendo ser aplicados em
diferentes áreas do conhecimento. Com o uso da inteligência artificial, a
utilização de sistemas de apoio à decisão médica tem se tornando cada vez mais
frequente. Neste sentido, este trabalho apresenta o estudo e o desenvolvimento
de um protótipo de Sistema Especialista para a área da Fitoterapia, que utiliza o
conhecimento de um especialista neste domínio, inserido em um sistema
computacional, a fim de oferecer apoio à decisão aos profissionais da área e
proporcionar mais agilidade e segurança às suas tarefas.
Palavras-chaves: Sistemas Especialistas, Inteligência Artificial, Fitoterapia.
1 INTRODUÇÃO
Segundo Kandel (apud Fernandes, 2003), os Sistemas Especialistas (SE) podem ser
caracterizados como sistemas que reproduzem o conhecimento de um especialista adquirido
ao longo de anos de trabalho, devendo ser construídos com o auxílio de um especialista
humano, o qual fornecerá a base de informações através de seu conhecimento e
experiências adquiridas. Dessa forma, pode-se afirmar que os SE são ferramentas que
facilitam o trabalho do especialista humano, visto que não há perda ou esquecimento de
informações, o tempo de resposta é menor e a quantidade de erros diminui em razão da
inferência de informações.
Diante deste cenário, este artigo apresenta um protótipo de Sistema Especialista que
demonstra a prescrição do medicamento fitoterápico mais adequado ao sintoma
diagnosticado a partir da base de conhecimento fornecida pelo especialista da área. Para a
construção da base de conhecimento e definição da inferência do sistema, o
desenvolvimento do mesmo foi acompanhado por um especialista da área de Fitoterapia.
Neste sentido, este artigo inicia apresentando a fundamentação teórica das áreas
envolvidas neste trabalho – seção 2, através de estudos sobre Inteligência Artificial e o
desenvolvimento de sistemas especialistas, bem como informações sobre a Fitoterapia. A
seção 3 apresenta o estado da arte, por meio do estudo de Sistemas Especialistas
desenvolvidos para a área de saúde, além de um comparativo entre os sistemas estudados e
a proposta aqui apresentada. A seção 4 detalha o protótipo implementado, apresentando a
modelagem do SE, as tecnologias empregadas, suas principais funcionalidades e a
validação do mesmo. Finalizando o artigo são apresentadas as considerações finais, bem
como as referências bibliográficas utilizadas.
_______________________________________________
71
2 REFERENCIAL TEÓRICO
Esta seção apresenta uma breve revisão teórica da literatura, com o objetivo de obter
fundamentos para justificar a proposta deste artigo. São apresentados conceitos de
Inteligência Artificial, abrangendo principalmente as técnicas dos Sistemas Especialistas e
noções sobre medicamentos fitoterápicos, foco do trabalho desenvolvido.
2.1 Inteligência Artificial
O desenvolvimento de sistemas especialistas constitui-se em uma das áreas de pesquisa
ligadas à Inteligência Artificial. Estes sistemas são baseados em conhecimento, construídos,
principalmente, com regras que reproduzem o conhecimento de um especialista, sendo
utilizados para solucionar determinados problemas em domínios específicos, como é o caso
dos medicamentos fitoterápicos (Nilson, 1982).
A pesquisa na área de inteligência artificial é cada vez mais abrangente, visando a
criação de sistemas inteligentes baseados em modelos pré-definidos. Um dos caminhos
seguidos pela Inteligência Artificial relaciona-se aos Sistemas Especialistas, que é
desenvolvido em conjunto com especialista da área a ser trabalhada (Weiss e Kulikowski,
1988).
Para alcançar os objetivos propostos, a inteligência artificial, fornece diferentes
técnicas que permitem a construção de sistemas que exibam alguma forma de
comportamento inteligente (Luger e Stubblefield, 1993).
Entre as diferentes técnicas de Inteligência Artificial existentes, este artigo
apresenta, com maiores detalhes, os Sistemas Especialistas, que constituem o foco deste
trabalho.
2.2 Sistemas Especialistas (SE)

Um Sistema Especialista (SE) é projetado com o intuito de auxiliar o especialista humano
na resolução de aplicações em uma determinada área do conhecimento humano. Esses
sistemas usam representação deste conhecimento em um domínio particular de forma a
executar funções semelhantes às de um especialista (Abel, 1998).
Diante deste contexto, pode-se dizer que uma das principais aplicações para os
sistemas especialistas são os sistemas de diagnóstico (Santos e Fernandes, 2004). Estes
sistemas de diagnósticos são capazes de deduzir possíveis problemas a partir de
observações ou sintomas e são muito utilizados na área da saúde, que é o foco do trabalho
proposto.
Uma das etapas na construção desses sistemas que apresenta maior dificuldade é a
aquisição do conhecimento. O fato que ocorre com a grande parte das áreas de aplicação
dos SE é que não há mais um profissional que conheça tudo em sua área de trabalho; por
exemplo, na medicina há várias áreas de especialização: um neurologista estuda e trabalha
com problemas no cérebro humano, um cardiologista com problemas no coração, um
ginecologista com o aparelho reprodutor feminino.
O especialista é aquele profissional que possui um conhecimento profundo e
específico em determinado assunto. Esses sistemas podem, em algumas tarefas, não
substituírem o especialista humano, como em um diagnóstico médico, mas auxiliá-lo,
aumentando assim a eficácia no diagnóstico e tratamento de doenças.
_______________________________________________
72
3 ESTADO DA ARTE
Esta seção apresenta um estudo sobre sistemas computacionais semelhantes ao proposto
neste trabalho, a fim de avaliar o que esses sistemas oferecem como são desenvolvidos e
que ensinamentos podem ser retirados desta comparação. Foram estudadas as ferramentas
DXplain, Iliad e Mycin, sistemas especialista no auxílio ao diagnóstico clínico.
3.1 DXplain
Desenvolvido pelo Massachusetts General Hospital, o DXplain é utilizado para ajudar nos
diagnósticos associados às manifestações clínicas. É um sistema de apoio à decisão clínica
que utiliza um rol de manifestações clínicas como sinais, sintomas e informações
laboratoriais para produzir uma lista de diagnósticos prováveis, fornecendo explicações e
sugestões para novas investigações (DXPLAIN, 2010).
Este software possui uma grande base de dados sobre 5000 manifestações clínicas
associadas com mais de 2000 diferentes doenças em um banco de dados Oracle. O
Laboratório de Ciência da Computação do Hospital Geral de Massachusetts vem
desenvolvendo o DXplain há dez anos.
O sistema tem sido utilizado principalmente para educação clínica, através de casos
clínicos, mas também pode ser usado para consultas médicas. O banco de dados e o sistema
estão sendo continuamente aperfeiçoados e atualizados. O DXplain vem sendo utilizado em
vários hospitais e escolas de medicina para educação clínica e como um auxílio educacional
na solução de problemas clínicos. Ele assume o papel de um livro-texto eletrônico em
medicina, pois correlaciona manifestações e doenças e também fornece referências
bibliográficas relevantes.
3.2 ILIAD
O ILIAD foi desenvolvido na Universidade de Utah, em Salt Lake City. O sistema auxilia
na busca por diagnósticos na área de Medicina Interna (especialidade médica que trata de
pacientes adultos, atuando principalmente em ambiente hospitalar) a partir de uma base de
conhecimento que contém 908 doenças, 1.509 síndromes e 11.900 sinais, sintomas e
exames subsidiários, cobrindo atualmente 1500 diagnósticos neste domínio, baseado em
diversos achados (Widmann, 1998).
Um diferencial deste sistema, que vale ser considerado, é a sua máquina de
inferência. Além da lógica implementada no seu motor de inferência, o sistema faz uso
também de uma abordagem probabilística de apoio à decisão (Teorema de Bayes)
fornecendo orientação terapêutica, depois de realizar o diagnóstico.
3.3 MYCIN
O Mycin foi desenvolvido por uma equipe de médicos e especialistas em IA na
Universidade de Stanford. Contém o conhecimento dos mais destacados especialistas no
campo de doenças infecciosas. Foi projetado para auxiliar no diagnóstico e tratamento de
meningite (inflamação das membranas que envolvem o cérebro e a medula espinhal) e
bacteriemia (infecção bacteriana no sangue) (Widmann, 1998).
O MYCIN utiliza o tipo de raciocínio “backward chaining”. Dando-se um conjunto
de sintomas para diagnóstico, o MYCIN utiliza seus conhecimentos para conduzir às
conclusões e então recomendar o apropriado tratamento.
_______________________________________________
73
A base de regras do sistema contém 450 regras, que lhe permitem diagnosticar e
prescrever tratamentos para bacteremia (infecção no sangue), meningite e cistite infecciosa.
O conhecimento clínico é representado como um conjunto de regras IF-THEN.
3.4 Comparativo entre os Sistemas Estudados

Dentre os sistemas estudados observaram-se algumas semelhanças entre seus aspectos e as
técnicas de desenvolvimento utilizadas, como mostra o quadro 1. A finalidade inicial destes
trabalhos foi para o uso em ambiente acadêmico, para serem utilizados como ferramenta de
apoio ao aprendizado de futuros profissionais da área da saúde, mais especificamente da
fitoterapia.
Para ser utilizado no ambiente profissional o processo deve ser feito de maneira
lenta e cuidadosa, devido ao grande grau de complexidade e responsabilidade a que estes
sistemas se aplicam.
No trabalho aqui apresentado, desenvolveu-se um protótipo de sistema especialista
sem o uso de nenhum framework ou módulo já construído, possibilitando a alteração da
base de conhecimento pelo especialista do domínio. Além disso, pretendeu-se desenvolver
um sistema de fácil utilização para os seus usuários. O Quadro 1 têm a finalidade de traçar
um comparativo entre os sistemas estudados e a solução implementada, demonstrando suas
principais características.
Quadro 1 – Comparativo entre os Sistemas estudados e o Sistema Implementado

DXPlain Illiad Mycin Sistema
Implementado
Forma de representação Regras de Regras Frames
do conhecimento produção Probabilísticas Regras de produção
Redes bayesianas
Finalidade do Sistema Usado para Fornecer Diagnosticar e Auxiliar na
auxiliar na busca orientação medicar infecções por indicação de
por diagnósticos terapêutica após bactérias medicamentos
realizar fitoterápicos
diagnóstico
Base de Conhecimento Oracle MySql Não identificado na MySQL
literatura estudada
Linguagem de PHP Delphi Não identificado na PHP
Programação literatura estudada
Permite a manutenção da Sim Sim Sim Sim
base de conhecimento
De acordo com o estudo comparativo realizado entre os sistemas estudados na seção

Estado da Arte, constatou-se que algumas funcionalidades desses sistemas podem ser
aplicadas também ao sistema apresentado neste trabalho.
4 DESCRIÇÃO DO SISTEMA
A presente seção apresenta a descrição do protótipo de Sistema Especialista implementado.
Para a modelagem e representação do sistema utilizou-se a UML (Unified Modeling
Language). A base de conhecimento é representada através de técnicas de modelagem de
banco de dados relacionais. Além da modelagem do sistema, também se apresenta a forma
de aquisição de conhecimento junto ao especialista, bem como as tecnologias que foram
_______________________________________________
74
empregadas no seu desenvolvimento e as funcionalidades implementadas nas seções

seguintes.
4.1 Aquisição de Conhecimento
A fase de obtenção do conhecimento é considerada por muitos autores, como Rezende
(2003), a parte mais complexa no desenvolvimento de um sistema especialista, pois
envolve a extração do conhecimento para a base do sistema (o que consiste em construir,
entender e atualizar uma base de conhecimento).
A aquisição do conhecimento foi realizada a partir de entrevistas com um
Especialista em Fitoterapia. Estas entrevistas permitiram que fossem levantados os
requisitos necessários para a implementação do Sistema Especialista aqui apresentado,
além do entendimento de como o conhecimento é processado por estes profissionais, para
que o mesmo pudesse ser armazenado na base de conhecimento.
4.2 Modelagem do Sistema

Nesta seção são apresentados os diagramas que orientaram o desenvolvimento do protótipo.
Para a modelagem e representação do sistema utilizou-se a UML (Unified Modeling
Language). A base de conhecimento é representada através de técnicas de modelagem de
banco de dados relacionais (diagrama E-R). A Figura 1 apresenta o diagrama de entidade-
relacionamento para o SE implementado.
Figura 1 - Modelo ER (Entidade-Relacionamento)
As tabelas apresentadas na Figura 1 armazenam os dados necessários para cadastro

dos pacientes, bem como o conhecimento que permitirá a indicação de medicamentos
fitoterápicos (sintomas, contra-indicações, medicamentos, entre outras informações).
Analisando-se a Figura 1, observa-se a entidade “produto” que será responsável por
armazenar todas as informações relativas aos medicamentos.
_______________________________________________
75
A Figura 2 apresenta o diagrama de casos de uso para o sistema especialista

implementado, mostrando as principais funcionalidades do sistema.
Figura 2 – Diagrama de Casos de Uso
4.3 Implementação do Sistema

Como gerenciador de banco de dados, foi utilizado o MySQL, devido a sua
compatibilidade com a linguagem de programação PHP e por ser de distribuição gratuita.
As interfaces foram desenvolvidas em HTML (HyperText Markup Language),
utilizando-se o recurso CSS (Cascading Style Sheets), linguagem desenvolvida pela W3C
(World Wide Web Consortium) que oferece um controle visual nas apresentações de
páginas web. Para edição das páginas HTML utilizou-se o software Adobe Dreamweaver
CS5.5.
A escolha da linguagem de programação PHP e do banco de dados MySQL deve-se
ao fato de serem tecnologias livres, facilmente encontradas nos planos de hospedagem de
sites. Desta maneira, o sistema tem plenas condições de ser hospedado em um servidor web
pago, caso o usuário assim deseje optar por um sistema web. Outra característica
importante é que, ambas as tecnologias são multiplataforma, ou seja, um programa escrito
nessas plataformas pode ser executado em qualquer sistema operacional sem a necessidade
de alterações no código-fonte.
O menu “Cadastro” contém o submenu “Cadastrar Medicamento” que exibe a tela
do cadastramento (Figura 3) de todos os medicamentos que irão compor a lista de sugestões
do tratamento mais indicado ao paciente em consulta. Na tela “Cadastrar Medicamentos”
_______________________________________________
76
(Figura 3), no quadro “Novo Medicamento”, o especialista informa: nome - nome do

medicamento; descrição - algum comentário referente ao medicamento cadastrado; contém
- informa os componentes deste produto; propriedades - informa para qual finalidade é este
medicamento; imagem - adiciona a imagem do medicamento; sintomas - seleciona o
sintoma e o grau de eficiência do medicamento; contraindicação - seleciona as
contraindicações do medicamento; status - define as opções de ação, permitindo ativar ou
desativar o medicamento do sistema sem excluí-lo.
A tela da “Indicação”, no submenu “Indicar”, inicia a primeira etapa do processo da
anamnese, que envolve o processo de inferência do sistema especialista, exibindo o
questionário de consulta ao paciente.
Figura 3 – Tela Cadastrar Medicamentos
_______________________________________________
77
O questionário apresentado na Figura 4 contém as perguntas cadastradas pelo

especialista na base de conhecimento, relacionadas ao nível de estresse do paciente.
Figura 4 – Tela da primeira etapa do processo da anamnese
No quadro “Paciente” (Figura 4) deve-se escolher o paciente no caixa Combo e

clicar em seu nome. No quadro “Questionário sobre Estresse” deve-se selecionar os
“Sintomas Físicos” e os “Sintomas Mentais”, marcando a opção de acordo com o relato do
paciente. Após, o especialista deve clicar no botão “Próxima Etapa”. A Figura 5 apresenta a
tela da segunda etapa da anamnese.
No quadro “Grau de Estresse” (Figura 5) é informado o nome do paciente em
consulta e o grau de estresse obtido no questionário da primeira etapa da anamnese. Este
grau de estresse é obtido a partir de um algoritmo que diagnostica o grau de estresse do
paciente em consulta.
O quadro “Sintomas” (Figura 5) exibe todos os sintomas cadastrados pelo
especialista relacionados ao estresse. O paciente informa ao terapeuta os sintomas e este os
marca no sistema. Para cada sintoma marcado, o sistema lista no quadro “Recomendações”
todos os medicamentos que são recomendados, cada um com o seu grau de eficiência. A
inferência é realizada com base na associação entre os sintomas, medicamentos cadastrados
e grau de eficiência dos mesmos.
_______________________________________________
78
Figura 5 – Tela da segunda etapa do processo da anamnese
Caso o terapeuta queira indicar algum medicamento que não foi listado, ele tem a
opção de adicionar, por meio do ícone “+” do quadro, o medicamento que considera
relevante para o tratamento do paciente, e que não foi listado. Com base nos percentuais de
eficiência indicados para cada medicamento, o terapeuta clica na seta (verde) do campo
“Ação”, a opção escolhida como indicado para o diagnóstico e automaticamente este é
enviado para o quadro “Indicações” armazenando assim todos os medicamentos indicados
pelo terapeuta para os sintomas relatados pelo paciente em questão. Caso ocorra de algum
medicamento ser enviado para este quadro por engano, o terapeuta tem a opção de removê-
lo clicando na seta (vermelha) ao lado do mesmo.
O quadro “Exercício” lista os todos os exercícios cadastrados, sendo que a
intensidade dos mesmos é sugerida de acordo com as informações armazenadas na base de
conhecimento referente ao paciente.
No quadro “Observação” o terapeuta tem a opção de relatar algum comentário sobre
o paciente. Após deve clicar no botão “Gerar Indicação”.
A Figura 6 resume o processo de inferência do sistema. O mecanismo de inferência
tem início com a chegada do paciente ao consultório do terapeuta. A seguir, na segunda
etapa do processo, é realizado o cadastro do paciente com seus dados pessoais e suas
restrições a alguns tipos de medicamentos e compostos.
_______________________________________________
79
Figura 6 – Mecanismo de Inferência
A terceira etapa do processo de inferência é onde o sistema, por meio de um

questionário respondido pelo paciente, sugere um diagnóstico ao especialista, apresentando
o grau de estresse deste paciente, se o mesmo possui ou não algum tipo de estresse físico ou
mental.
A quarta etapa tem início ao processo de indicação do medicamento sendo listados
todos os medicamentos sugeridos pelo sistema de acordo com as informações obtidas do
paciente em consulta, relacionando as contraindicações informadas por ele com as
contraindicações cadastradas nos medicamentos pelo especialista.
O sistema exibe a listagem dos medicamentos indicados e o especialista
(fitoterapeuta) irá selecionar todos que farão parte do tratamento deste paciente. Nesta
mesma lista é gerada uma relação de exercícios. A intensidade destes exercícios é sugerida
de acordo com a idade do paciente, existindo a possibilidade de alteração das intensidades
caso o terapeuta julgue necessário.
Por último, o sistema disponibiliza um campo livre de texto onde o terapeuta pode
escrever alguma recomendação ou forma de uso dos medicamentos indicados caso seja
necessário para completar o tratamento.
4.4 Validação
Durante a implementação do Sistema Especialista foram realizados testes em vários
módulos do sistema, para verificar o funcionamento adequado de suas funcionalidades.
Além disso, o especialista (fitoterapeuta) acompanhou todo o desenvolvimento do projeto e
realizou testes finais, para validação do sistema. Após a simulação de cada consulta, o
terapeuta analisou todos os tratamentos gerados, considerando que o sistema responde de
maneira satisfatória aos seus resultados.
_______________________________________________
80
Deixou-se claro, ainda, que as indicações geradas devem obrigatoriamente passar

pela aprovação de um profissional da área, sendo atribuição deste sistema a sugestão de
tratamentos, como forma de auxílio aos profissionais ou estudantes da área de Fitoterapia, e
que o mesmo não visa de forma alguma substituir o profissional. Pelo mesmo motivo, foi
esclarecido também que o sistema foi projetado para ser operado apenas por profissionais
habilitados na área.
Os resultados obtidos do sistema foram satisfatórios, tanto em sua utilização, bem
como na qualidade e veracidade das informações recuperadas durante a busca do
tratamento mais indicado, de acordo com as informações assinaladas nas etapas do
questionário da anamnese.
5 CONSIDERAÇÕES FINAIS
O estudo para realização deste trabalho permitiu constatar que o tema escolhido tem como
um de seus objetivos o desenvolvimento de sistemas computacionais na área da Inteligência
Artificial, que sejam capazes de representar de forma precisa no raciocínio e conhecimento
dos seres humanos. A partir deste estudo foi possível chegar à arquitetura e definir os
métodos e técnicas de inferência do sistema implementado.
As informações prestadas pelo especialista consultado deram um caráter de
veracidade ao projeto, garantindo a sensibilidade e especificidade do tratamento que será
gerado. Através destas informações também foi possível modelar a base de conhecimento.
O ambiente de desenvolvimento PHP, integrado ao sistema de gerenciamento de
banco de dados MySQL, mostrou-se adequado para o desenvolvimento do sistema. A
conexão com o banco de dados demonstrou a eficiente integração entre as ferramentas
utilizadas, auxiliando e agilizando as várias conexões realizadas durante todo o aplicativo.
Dentre as dificuldades encontradas, a principal delas foi encontrar a melhor forma
de representação do conhecimento para armazenamento no banco de dados – tendo-se
optado pelo modelo de frames. Conforme citado no referencial teórico, esta é realmente
uma das tarefas mais complexas de um Sistema Especialista. A formalização desse
conhecimento através de um sistema especialista torna-se uma tarefa árdua, visto que os
profissionais da área de Fitoterapia, além do seu conhecimento, levam em consideração seu
senso comum e intuição para realizar a indicação dos medicamentos e tratamentos mais
adequados a cada paciente.
O objetivo específico de auxiliar a definição do tratamento mais indicado ao qual o
sistema se propôs, foi contemplado, auxiliando o terapeuta na definição de diagnósticos de
acordo com as informações registradas na base de conhecimento.
Para trabalhos futuros sugere-se a implementação de mais funcionalidades
relacionadas ao uso do sistema, como por exemplo, gráficos para acompanhar a evolução
do tratamento do paciente, disponibilizar impressão dos resultados das indicações de
tratamentos e possibilidade de aprendizagem do sistema, para que o sistema possa gerar
indicações de tratamentos e medicamentos com base em alterações realizadas pelo
especialista, a partir das indicações geradas automaticamente.
Considera-se que todos os objetivos propostos no trabalho foram alcançados de
forma adequada, implementando-se um sistema que permitiu o aprendizado científico e
tecnológico, aprofundando temas que não foram estudados durante o curso de graduação.
Além disso, é inovador já que até o presente momento não se viu nenhum outro com o foco
apresentado. Considera-se ainda que, após melhorias e acréscimo de mais funcionalidades,
_______________________________________________
81
o sistema especialista proposto neste trabalho, possui grandes chances de aplicação no

mercado.
REFERÊNCIAS
ABEL, M.: Sistemas Especialistas. Universidade Federal do Rio Grande do Sul, Instituto
de Informática, 1998.
DXPLAIN. :Diagnostic Decision Support. Disponível em:
http://lcs.mgh.harvard.edu/projects/dxplain.html. Acesso em: 01 nov. 2010.
FERNANDES, A. M. R., da.: Inteligência artificial: noções gerais. Santa Catarina: Visual
Books, 2003.
LUGER, F. G. e STUBBLEFIELD, A. W. Atificial Intelligence: Structures ans
Strategies for Complex Problem Solving. The Benjamin/Cumming Publishing Company,
Inc., Redwood City, California, 1993.
NILSON, N. S.: Principles of Artificial Intelligence, Springer Verlag, Berlin, 1982.
REZENDE, S. O. et.al.: Sistemas Inteligentes: fundamentos e Aplicações. Manole, 2003.
SANTOS, D.; FERNANDES, A.: Sistema Especialista para Diagnóstico de Doenças
Periodontais. Inteligência Artificial Aplicada a Saúde. Ed. Visual Books, 2004.
WEISS, S. M.; KULIKOWSKI, C. A.: Guia Prático para projetar Sistemas
Especialistas. Rio de Janeiro: LTC, 1988.
WIDMANN, L. E.: Sistemas especialistas em medicina. Revista Informática Médica,
Campinas. 1998. Disponível em:
<http://www.informaticamedica.org.br/informaticamedica/n0105/widman.htm>. Acesso
em: 28 nov. 2010.
_______________________________________________
82
Sistema Gerenciador de Regras de Negócio aplicado à

gestão de recursos de telecom: estudo de caso
Celly de Siqueira Martins, Mauricio Amorim da Silva, Sindo Vasquez Dias, André
Lara Temple de Antonio
Diretoria de Soluções em Billing

Fundação Centro de Pesquisa e Desenvolvimento em Telecomunicações (CPqD) –
Campinas, SP – Brasil
{celly, masilva, sindo, andret}@cpqd.com.br
Resumo. O Sistema Gerenciador de Regras de Negócio é uma técnica que

surgiu para facilitar o processo de desenvolvimento de aplicações de software,
tornando-o mais ágil, rápido e barato. A técnica está fundamentada em uma
arquitetura cuja lógica de negócio da aplicação fica isolada da lógica de
processamento e validação dos dados, facilitando a introdução e a alteração
de regras sem a necessidade de alterações no código-fonte. Este artigo
descreve um estudo de caso no qual essa técnica foi aplicada a um sistema de
gestão de recursos de telecom cujos requisitos frequentemente sofrem
mudanças. O objetivo é disponibilizar atualizações e evoluções do produto
aos usuários mais rapidamente e com um baixo custo.
1. Introdução
Os recursos de telecom tornaram-se imprescindíveis às organizações dos mais diversos
domínios de atuação. Seus custos geralmente são elevados e podem consumir uma
parcela significativa de recursos financeiros.
Um Sistema de Informação (SI) para a Gestão de Recursos de Telecom (GRT)
tem o propósito de melhor gerenciar, organizar e controlar os ativos de telecom das
organizações – comunicação de dados, voz e celulares –, contribuindo para a redução de
gastos. O seu principal objetivo é ratear entre os centros de custo de uma organização os
valores gastos em ocorrências de telecom. Esse SI caracteriza-se por mudanças
frequentes nos requisitos para atender a diferentes usuários, resultando em um custo
adicional para as atualizações e evoluções [CPqD 2010].
As Regras de Negócio (RNs) são declarações que definem ou restringem algum
aspecto do negócio [The Business Rules Group 2010b]. O Sistema Gerenciador de
Regras de Negócio (SGRN) pertence a uma nova geração de técnicas e ferramentas que
surgiram para aprimorar o processo de desenvolvimento de sistemas e é responsável pelo
gerenciamento e processamento de RNs. A especificação dos requisitos de negócio é
feita por meio de RNs que são gerenciadas e executadas por uma máquina de RNs
[Browne 2009].
Este trabalho tem como objetivo aplicar um SGRN a um sistema GRT, existente
e implementado em linguagem PL / SQL, para comprovar a sua validade e agilizar as
suas atualizações quando necessárias. Será feita uma engenharia reversa no código de
forma a entender o negócio e a partir desse entendimento especificar as RNs.
_______________________________________________
83
Na Seção 2 são apresentados os desafios na especificação dos requisitos de um

SI; na Seção 3 são descritos os principais conceitos de RNs e SGRN; na Seção 4 é
apresentado o estudo de caso em que a ferramenta Drools JBoss Rules é aplicada a um
sistema GRT; na Seção 5 são mostrados os resultados alcançados e uma tabela de
decisão contendo RNs; na Seção 6 são feitas sugestões para futuros trabalhos; e, por fim,
é apresentada uma conclusão em que são definidos benefícios e recomendações para a
utilização de um SGRN.
2. Desafios na especificação dos requisitos de um SI

Um dos fatores-chave para o sucesso na criação de um SI é uma boa definição dos
requisitos do negócio e, considerando a sua característica abstrata, especificar esses
requisitos não é uma tarefa trivial. A especificação de requisitos é um dos principais
tópicos na indústria de software e cada vez mais as organizações estão percebendo que
só conseguem atingir o sucesso se os requisitos forem bem especificados [Wiegers
2006].
No mundo moderno, as organizações estão lidando com um mercado cada vez
mais competitivo e em constantes mudanças. Nesse contexto, são necessárias frequentes
reformulações e inovações nos processos e requisitos de negócio [Azevedo 2003].
Sendo assim, um desafio em definir requisitos de negócio é lidar com a característica de
estar em constante evolução e mudanças.
Considerando-se, ainda, o trabalho contínuo das organizações para redução dos
custos, é necessário planejar uma forma rápida e barata para mudar os requisitos de
negócio.
Além disso, as organizações demandam a construção de sistemas cada vez mais
complexos, para os diversos processos de negócio de vários domínios do conhecimento
e com suas complexas decisões de negócio. Entretanto, esses processos e decisões não
são tão bem representados quando são empregadas linguagens tradicionais de
programação, em decorrência da dificuldade em serem entendidas por especialistas no
negócio [Bali 2009].
Sendo assim, um desafio dos fornecedores de software é especificar os requisitos
de negócio em constantes mudanças, seguindo um processo de desenvolvimento de
sistemas, para atender às necessidades dos seus usuários.
Um processo de desenvolvimento de software define quem faz o quê, quando e
como para alcançar um determinado objetivo — a construção do software propriamente
dito. As atividades básicas do processo de desenvolvimento de software são — análise e
especificação dos requisitos de negócio; definição da arquitetura do sistema; projeto do
sistema; implementação do código-fonte; e testes do código executável implementado
[Jacobson, Booch e Rumbaugh 1998].
A análise e a especificação dos requisitos de negócio são definidas por
especialistas no negócio e analistas de requisitos; a definição da arquitetura é feita pelos
arquitetos; o projeto do sistema é executado por projetistas; a implementação do código-
fonte é realizada por implementadores; e os testes do sistema são elaborados e
executados por analistas de testes. Os artefatos produzidos pelos envolvidos nesse
_______________________________________________
84
processo são diferentes e, portanto, cada um pode ter uma visão diferente do
entendimento do negócio.
O processo de desenvolver software pode ser demorado devido à dificuldade em
se traduzir os requisitos de negócio para códigos-fonte. Além disso, existe a
possibilidade de alguma informação ser perdida entre o que os especialistas no negócio
definem, os analistas de requisitos interpretam e os implementadores codificam.
Geralmente, isso requer muitas revisões e correções até que o sistema esteja inteiramente
correto e aderente aos requisitos de negócio.
A existência de um mecanismo que garanta aos envolvidos uma visão unificada
do negócio pode contribuir para uma melhor qualidade e rapidez na definição e na
mudança dos requisitos de negócio de um SI. As RNs podem representar um importante
conceito na fase de definição de requisitos organizacionais, facilitando modificações nos
SIs quando essas regras mudam e proporcionando oportunidade para as pessoas de
negócio avaliarem a execução de cada processo [Gottesdiener 1997 apud Dallavalle e
Cazarini 2010].
3. Conceitos das técnicas de RNs e SGRN

O principal objetivo das técnicas de RNs e SGRN é oferecer às organizações a melhor
abordagem possível para o desenvolvimento de soluções de negócio envolvendo sistemas
automatizados [Ross 2003]. A seguir, são mostrados os principais conceitos, vantagens e
considerações sobre o uso de RNs e SGRN.
3.1. RNs
As RNs definem, restringem ou validam algum aspecto – estrutural ou comportamental –
do negócio de uma organização, em uma linguagem compreensível tanto aos técnicos da
área de Tecnologia da Informação (TI) como aos especialistas no negócio [Debevoise
2005; The Business Rules Group 2010b].
Aplicadas a um SI, as RNs controlam os dados, definindo se eles podem ou não
ser criados ou modificados, por meio de condições específicas e de ações a serem
tomadas quando essas condições forem satisfeitas [Debevoise 2005].
Além disso, as linguagens tradicionais de programação são imperativas enquanto
as RNs são declarativas. Um tratamento das ligações telefônicas efetuadas a partir de um
aparelho fixo de voz está exemplificado em linguagem tradicional de programação na
Figura 1 e em RNs na Tabela 1 – supondo-se uma organização na qual as chamadas a
serviço são cobradas dos centros de custo e as chamadas particulares de seus
funcionários são identificadas e cobradas por meio de uma senha ou de uma aprovação
prévia do funcionário.
A seguir, são especificadas as principais características e as respectivas
justificativas de como devem ser as RNs [Morgan 2002; The Business Rules Group
2010a].
 Atômica: as RNs devem ser representadas na menor unidade possível, desde que
não ocorra perda de informação ou de semântica;
_______________________________________________
85
 Uma descrição do negócio: as RNs devem descrever a lógica do negócio e não

a tecnologia a implementar as RNs;
 Declarativa: as RNs devem contribuir para o objetivo do negócio ao invés de
descrever como o objetivo do negócio deve ser alcançado;
 Restritiva: as RNs devem limitar as ações a serem aplicadas ao contexto do
negócio;
 Representada em linguagem natural: as RNs devem ser expressas em
linguagem natural, por meio de um idioma, pois isso dispensa treinamentos
específicos e o uso de ferramentas;
 Rastreável: é preciso saber como as RNs se encaixam dentro de um SI e rastreá-
las desde a sua origem até as suas execuções, para manter o acompanhamento de
todo o ciclo de vida do sistema;
 Estruturada: as RNs devem ser escritas de forma a facilitar a leitura e o
entendimento dos envolvidos no negócio. Porém, é necessário restringir o
número de opções para se escrever as RNs e determinar padrões estruturais para
a sua representação. Essa prática pode apoiar o processo de automatização do
SI.
Além disso, para definir uma RN, é preciso especificar detalhes operacionais, tais
como: quem invoca a RN; quando e onde a RN é executada; e como a RN é
implementada [Alvarenga 2007].
Os principais benefícios oferecidos pelas RNs são: rapidez no desenvolvimento
de um SI, requisitos de negócio com mais qualidade, facilidade para se realizar mudanças
e equilíbrio entre flexibilidade e controle centralizado do SI [Gottesdiener 1997 apud
Dallavalle e Cazarini 2010].
O potencial de aplicações para RNs é muito vasto. Atualmente tem sido
amplamente utilizado nas áreas de Telecomunicações e Bancária [Lin e Zhang 2007],
mas também pode ser aplicado em diversas outras áreas, tais como: Finanças, Energia
Elétrica, Automobilística, Saúde, Educação, entre outras. Alguns exemplos são — testes
de componentes eletrônicos de automóveis [Syldatke, Chen, Angele et al. 2007],
controle de vistos, definir seguro saúde a partir do perfil do cliente, controle de estoques
em supermercados, entre outros.
3.2. SGRN
Um SGRN pode gerenciar todas as RNs definidas por especialistas no negócio e torná-
las útil ao próprio negócio [Fischer 2010]. Quando se utiliza um SGRN, a
responsabilidade pelo controle da lógica do negócio deixa de ser dos técnicos da área de
TI e passa a ser dos especialistas no negócio [Owen 2004].
As principais vantagens de um SGRN são as seguintes: a especificação dos
requisitos de negócio é simplificada; os envolvidos no processo de desenvolvimento do
sistema têm uma visão unificada do entendimento do negócio; e o desenvolvimento e a
manutenção do sistema se dão de forma mais ágil, rápida e barata em comparação aos
desenvolvimentos tradicionais [Bali 2009; BPM-Focus 2006].
_______________________________________________
86
As RNs são facilmente construídas por serem semelhantes a uma linguagem

natural e por utilizarem um conjunto de sentenças tais como “se-então” ou “quando-
então”. A máquina de RNs avalia um conjunto de condições e executa uma lista de ações
para as RNs que tiverem as suas condições identificadas como verdadeiras.
A lógica do negócio fica separada da lógica da aplicação, na qual os dados são
validados e processados. A criação e a manutenção das RNs são responsabilidade dos
especialistas no negócio, enquanto a lógica da aplicação para executá-las e armazená-las
em um repositório é dos técnicos da área de TI [Owen 2010].
As alterações feitas nas RNs mudam dinamicamente o comportamento do
sistema, sem necessitar do envolvimento da área de TI, possibilitando uma redução do
tempo de desenvolvimento ou manutenção do sistema e uma significativa redução em
seus custos.
A arquitetura de uma aplicação convencional geralmente é composta por três
camadas: servidor Web, servidor de aplicações e base de dados. A arquitetura baseada
em RNs contém uma quarta camada – o SGRN. A Figura 2 ilustra uma representação
gráfica de uma arquitetura contendo um SGRN [Owen 2010].
Alguns itens devem ser considerados antes de se optar pelo uso de um SGRN
[Bali 2009; Browne 2009]:
 Um SGRN não deve ser utilizado em aplicações de baixa complexidade, como,
por exemplo, as de páginas na Internet, nas quais as informações são apenas
armazenadas em bases de dados e apresentadas ao usuário em um formato
predefinido.
 Como qualquer nova tecnologia, um SGRN não deve ser usado em um projeto
com prazo de entrega muito rígido ou de grande porte. É mais prudente que se
adquira experiência no uso da ferramenta, aplicando-a inicialmente a um projeto
de pequeno porte.
 Um SGRN não deve ser usado quando não for a tecnologia mais adequada para a
aplicação. Por exemplo, o uso da tecnologia workflow pode ser mais adequado
para uma aplicação que necessita de um controle sequencial bem definido.
Um SGRN pode ser amplamente utilizado quando:
 A lógica do negócio muda freqüentemente.
 Há pessoas com entendimento profundo sobre o negócio, mas sem habilidade
técnica em TI.
 O problema é inoportuno ou complexo para outras soluções.
 Quando é necessário utilizar uma solução ágil.
4. Estudo de caso
Para investigar as características de um SGRN aplicado a um sistema GRT, é proposta
uma metodologia constituída de quatro etapas: entendimento do negócio, definição da
arquitetura da solução, criação de RNs e execução de testes sistêmicos.
_______________________________________________
87
Na primeira etapa, busca-se o entendimento do negócio, o que pode ser feito por
meio de estudos e pesquisas sobre o assunto e consultas aos especialistas no negócio. Na
segunda etapa, define-se a arquitetura considerando o SGRN como uma quarta camada
da solução. Na terceira etapa, criam-se as RNs respeitando as suas principais
características e o formato de suas sentenças. E, por fim, na quarta etapa executam-se os
testes sistêmicos para validação do sistema construído com as RNs.
Figura 1. Tratamento de ligações telefônicas em linguagem tradicional de

programação
Tabela 1. Tratamento de ligações telefônicas em RNs
CONDIÇÕES AÇÃO
Tipo da ligação Utilizou senha Aprovada pelo Estratégia de
funcionário cobrança
Particular Não Não Unidade de
estrutura
Particular Não Sim Funcionário
Particular Sim Funcionário
Serviço Sim Funcionário
Serviço Não Unidade de
estrutura
_______________________________________________
88
Figura 2. Arquitetura contendo um SGRN
A seguir é apresentada a aplicação da metodologia em um estudo de caso a partir

de um sistema GRT previamente existente desenvolvido em uma tradicional linguagem
de programação.
4.1. Entendimento do negócio

O entendimento do negócio deu-se por uma engenharia reversa aplicada ao código-fonte
implementado em linguagem PL / SQL e contendo 8.248 linhas. A interpretação do
código-fonte foi feita por um especialista em banco de dados e linguagem PL / SQL.
Esse especialista identificou as ações executadas pelo código após a obtenção dos dados.
A partir dessa identificação, um analista de requisitos especificou o negócio e validou
com um especialista.
4.2. Definição da arquitetura da solução

O SGRN foi incluído como uma quarta camada na arquitetura do sistema GRT. A
ferramenta utilizada para a inclusão dessa nova camada é o Drools JBoss Rules,
desenvolvida em linguagem Java. Essa ferramenta utiliza uma linguagem específica para
a execução das RNs – DRL (Drools Rule Language).
A DRL é caracterizada por ser extensível e oferecer, via arquivo de mapeamento
de propriedades, suporte à linguagem natural [Drools 2010]. Uma definição básica de
uma RN na linguagem DRL pode ser observada na Figura 3.
_______________________________________________
89
Figura 3. Arquitetura contendo um SGRN
Os registros utilizados como entrada para a execução das RNs são denominados fatos.
Uma aplicação, em linguagem Java, executa a extração, a transformação e a carga dos
registros da base de dados do sistema GRT para uma base de fatos.
A definição das RNs é feita em tabelas de decisão e podem ser armazenadas em
planilhas eletrônicas. Devem ser criadas tantas RNs quanto forem os distintos fatos a
serem tratados no SGRN.
As RNs são identificadas automaticamente por meio da DRL quando são
armazenadas em planilhas. A ferramenta Drools JBoss Rules obtém os fatos e identifica
as respectivas RNs, armazenando-as em uma base de dados denominada RNs
identificadas.
Uma segunda aplicação, em linguagem Java, obtém as RNs identificadas, executa
as respectivas ações e armazena ou atualiza os resultados na base de dados do sistema
GRT ou na base de fatos, conforme determinar a ação.
Uma representação gráfica da arquitetura do sistema GRT utilizando um SGRN é
apresentada na Figura 4.
4.3. Criação de RNs

As RNs são construídas a partir do entendimento do negócio adquirido na etapa 4.1.
Os objetivos primários do processo de criar RNs são: garantir que haja uma única
RN para cada fato e que nenhum fato deixe de ser atendido por uma das RNs. Esse
processo é iterativo e pode ser necessário executá-lo várias vezes até se atingir um
resultado satisfatório.
As correções nos atributos de condições, na maioria das vezes, são feitas sem a
participação do implementador do sistema. A vantagem é a agilidade no
desenvolvimento do sistema, diferentemente das implementações tradicionais em que as
alterações são feitas diretamente no código-fonte, necessitando, obrigatoriamente, da
intervenção de implementadores do sistema.
Pode haver a necessidade de um fato ser processado por duas ou mais RNs.
Considerando que a DRL gera um novo fato e o executa para cada fato atualizado
durante o seu processamento, a estratégia para um fato ser processado por duas ou mais
RNs é criar intencionalmente uma alteração em seus atributos de condições.
Para a obtenção de resultados satisfatórios das RNs é indispensável um profundo
conhecimento do negócio que está sendo tratado, bem como dos objetivos a serem
atingidos.
_______________________________________________
90
Figura 4. Arquitetura do sistema GRT utilizando um SGRN
4.4. Execução de testes sistêmicos

A base de dados utilizada no teste sistêmico era volumosa, e foi identificada a
necessidade de melhoria no desempenho da execução das RNs, pois a tabela de decisão
era acessada a cada fato. A solução adotada para esse problema foi salvar em memória a
identificação das RNs para cada diferente tipo de fato, e o acesso à tabela de decisão
passou a ser feito apenas para novos fatos identificados.
5. Resultados
O sistema foi migrado, em um período de dois meses, para uma nova arquitetura
contendo um SGRN. As 8.248 linhas existentes de código-fonte foram transformadas em
38 RNs, constituídas de 12 condições e 4 ações para atender os distintos tratamentos do
GRT — cobrança por funcionário, rateio de produto, rateio de tronco e centro de custo
prioritário.
As condições identificadas foram — possui empresa prioritária, possui centro de
custo, possui DDR, cobrar particular, rateio de tronco, tipo de item, tipo de ligação,
utilizou senha, aprovada, é chamada, é tronco e classe do produto.
As ações definidas foram — fórmula, estratégia, alterar para não consolidado e
regra. Os objetivos dessas ações foram, respectivamente, definir os valores a serem
persistidos; definir como persistir os valores; possibilitar um fato ser processado por duas
_______________________________________________
91
ou mais RNs, conforme citado no item 4.3; e determinar um identificador único para
cada RN. As ações foram implementadas em linguagem Java.
Na Figura 5 é apresentada uma tabela de decisão de RNs construídas para a
cobrança das ligações telefônicas por funcionário. Para simplificar a ilustração, são
exibidas apenas três condições e duas ações.
Nas linhas 2 a 5, RuleSet identifica o pacote onde serão agrupadas as RNs;
Sequential indica se a forma de analisar as RNs é sequencial; Import define a lista de
classes Java a serem importadas; e Notes é utilizado para comentários.
Na linha 7, é apresentada a identificação da tabela de decisão; e na linha 8, cada
Condition define uma condição e Action indica uma ação a ser executada.
Figura 5. Tabela de decisão com RNs de cobrança de ligações telefônicas por

funcionário.
Nas linhas de 12 a 14, os conteúdos P e S, do atributo “Tipo de ligação”,

significam, respectivamente, “Particular” e “Serviço”; e, da mesma forma, os conteúdos
“S” e “N” dos atributos “Utilizou senha” e “Aprovada” significam “Sim” e “Não”.
A tabela de decisão é um instrumento facilitador da comunicação entre os
integrantes da equipe em relação ao conhecimento do negócio, ao funcionamento do
sistema e aos seus objetivos.
Os resultados obtidos foram: rapidez no entendimento e na definição dos
requisitos de negócio e na implementação do código-fonte, e maior integração dos
participantes da equipe.
_______________________________________________
92
6. Conclusão
Um SGRN aplicado a um sistema GRT demonstrou ser uma técnica eficiente para
agilizar as atualizações no sistema, tanto na definição de novos requisitos de negócio
como na implementação do código-fonte, gerando rapidez na solução e na redução de
custos, além de facilitar a definição dos requisitos de negócio e gerar melhor
entendimento entre técnicos da área de TI e especialistas no negócio.
Os seguintes itens são recomendados para a utilização da técnica SGRN:
 Na criação das RNs:
o Todos os fatos devem ser satisfeitos por exclusivamente uma das RNs. Se
existir um fato sendo atendido por mais de uma RN, ocorrerá um conflito,
causando um erro no sistema.
o Cada diferente tipo de fato deve ser identificado por uma única RN.
 Se for preciso executar um fato duas ou mais vezes, deve-se utilizar o recurso de
criar uma ação para alterar um ou mais atributos de um fato.
 O acesso à tabela de decisão deve ser feito de forma criteriosa, no menor número
de vezes possível, para evitar problemas de desempenho, sobretudo se a base de
fatos for volumosa.
7. Trabalhos futuros
O potencial de aplicações das técnicas de RNs e SGRN é muito vasto e conforme sugere
a literatura, pode ser aplicado em diversos domínios do conhecimento.
Vários outros trabalhos podem ser desenvolvidos para um melhor entendimento e
aplicação dessas técnicas, entre eles pode-se destacar:
 Utilização da ferramenta Drools JBoss Rules integrada ao processo jBPM (Java
Business Process Management) de forma a criar um ambiente unificado
integrando a combinação de paradigmas de regras, processos e eventos na lógica
de negócio da aplicação. O jBPM é um processo que permite modelar os
objetivos do negócio, por meio de um workflow, descrevendo os passos a serem
executados e em que ordem para alcançar um determinado objetivo [JBPM
2011]. Enquanto as regras de negócio são especificadas por meio da ferramenta
Drools JBoss Rules, os processos e eventos são especificados por meio do jBPM.
 Estudo de metodologias para se empregar nas técnicas RNs e SGRN.
 Desenvolvimento de um aplicativo para transformar a planilha em outras
linguagens de programação diferentes da DRL utilizada nesse trabalho, por
exemplo: Java.
 Estudo comparativo das ferramentas de RNs e SGRN existentes no mercado.
 Aplicação em outros SIs, tais como: Billing de telecom ou energia elétrica tendo
os seus processos de entrada de dados, faturamento, arrecadação e cobrança
baseados em RNs; detecção de fraudes; e controle de fluxo de tráfego utilizando
RNs para melhor gerenciar horários de pico.
_______________________________________________
93
Referências
Alvarenga, G. G. (2007) Uma Abordagem para Tratamento de Regras de Negócio
em Sistemas de Informação. Goiânia. 149 p. Dissertação (Mestrado em Ciência da
Computação) – Universidade Federal de Goiás (Instituto de Informática), Goiânia, 27
de julho de 2007.
Azevedo, D. e Campos, R. (2003). Sistematização do Levantamento de Requisitos
em Processos de Desenvolvimento de Software a Partir de uma Arquitetura de
Modelagem de Negócios. Disponível em
<http://www.abepro.org.br/biblioteca/ENEGEP2003_TR0905_1093.pdf>. Acesso
em: 15 ago. 2011.
Bali, M. (2009) Drools JBoss Rules 5.0 Developer's Guide. Birmingham: Packt
Publishing. 320 p.
BPM-Focus. (2006) Business Rules are from Mars & Processes from Venus.
Disponível em
<http://www.waria.com/Documents/Rules_are_from_Mars_&_Processes_from_Venu
s.pdf>. Acesso em: 16 ago. 2011.
Browne, Paul. (2009) JBoss Drools Business Rules. Birmingham: Packt Publishing. 304
p.
Centro de Pesquisa e Desenvolvimento em Telecomunicações (CPqD). (2010) Gestão
de Recursos de Telecomunicações. Disponível em
<http://gestaodetelecom.cpqd.com.br/>. Acesso em: 20 out. 2010.
Debevoise, Tom. (2005) Business Process Management with a Business Rules
Approach. Roanoke, Virginia 24019: Business Knowledge Architects. 224 p.
Drools. (2010) Drools Documentation. Disponível em
<http://downloads.jboss.com/drools/docs/4.0.7.19894.GA/html_single/index.html#d0
e2995>. Acesso em: 20 out. 2010.
Fischer, Layna. (2010) BPM and Workflow Handbook. Lighthouse Point FL 33064
USA: Future Strategies. 284 p.
Gottesdiener, E. (1997) Business Rule Show Power, Promise. Application
Development Trends, v. 4, n. 3, apud Dallavalle, S. I. e Cazarini, E. W. (2010)
Regras do Negócio, um Fator Chave de Sucesso no Processo de Desenvolvimento de
Sistemas de Informação. Disponível em
<http://www.abepro.org.br/biblioteca/ENEGEP2000_E0237.PDF>. Acesso em: 08
jun. 2011.
Jacobson, I., Booch, G. e Rumbaugh, J. (1998) The Unified Software Development
Process. Reading, Massachusetts 01867: Addison-Wesley. 463 p.
JBPM. (2011) jBPM. Disponível em <http://www.jboss.org/jbpm>. Acesso em: 15 ago.
2011.
Lin, B. e Zhang, Y. (2007) The Management and Validation of Business Rules in
Telecom Operator's Settlement and Apportion System. In: 8th ACIS International
Conference on Software Engineering, Artifical Intelligence, Networking, and
_______________________________________________
94
Parallel/Distributed Computing, Qingdao, China. Proceedings… California: IEEE

Computer Society. Disponível em:
<http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?reload=true&punumber=4287452
>. Acesso em: 31 mai. 2011.
Morgan, T. (2002) Business Rules and Information Systems: Aligning IT with
Business Goals. Boston, USA: Addison-Wesley Professional. 348 p.
Owen, J. (2010) Business Rules Management Systems. Disponível em
<http://www.infoworld.com/pdf/special_report/2004/26SRrules.pdf>. Acesso em: 20
out. 2010.
Owen, J. (2004) Putting Rules Engines to Work. Disponível em
<http://www.infoworld.com/t/business/business-rules-management-systems-548>.
Acesso em: 15 ago. 2011.
Ross, Ronald G. (2003) Principles of the Business Rule Approach. Boston, USA:
Addison-Wesley Professional. 372 p.
Syldatke, T., Chen, W., Angele, J. et al. (2007) How Ontologies and Rules Help to
Advance Automobile Development. In: Paschke. A. Biletskiy, Y. Advances in Rule
Interchange and Applications: International Symposium. Orlando, Florida.
Proceedings… Germany: Springer Berlin Heidelberg.
The Business Rules Group. (2010a) Business Rules Manifesto – The Principles of
Rule Independence. Disponível em:
<http://www.businessrulesgroup.org/brmanifesto.htm>. Acesso em: 20 out. 2010.
The Business Rules Group. (2010b) Defining Business Rules – What are They
Really? Disponível em:
<http://www.businessrulesgroup.org/first_paper/br01c0.htm>. Acesso em: 20 out.
2010.
Wiegers, Karl E. (2006) More About Software Requirements. Redmond, Washington
98052-6399: Microsoft Press.
_______________________________________________
95
Gestão da informação em biblioteca universitária: uma

proposta utilizando regras de associação na disseminação das
informações de novas aquisições bibliográficas
Maciel F. da Silva1, Cláudio Ratke2
1
Bacharel em Sistemas de Informação
2
maciel.f@gmail.com, ratke@inf.ufsc.br
Resumo. Este trabalho foi desenvolvido utilizando mineração de dados na

disseminação de informação sobre novas aquisições do acervo bibliográfico
de uma biblioteca universitária. O sistema proposto permite enviar, por e-
mail, informações sobre as novas aquisições de acordo com ás áreas
selecionadas pelo usuário em seu perfil. A técnica de regras de associação foi
empregada como um diferencial, objetivando enviar também informações de
novas aquisições de outras áreas que podem interessar ao usuário, a partir
das correlações detectadas pelo emprego desta. O sistema pode auxiliar nos
serviços oferecidos pelas bibliotecas universitárias principalmente em relação
às necessidades informacionais de seus usuários.
1. Introdução
Na sociedade contemporânea a informação assume um valor estratégico e as
organizações focam na gestão da informação, utilizando as tecnologias, ferramentas e
técnicas mais avançadas para obter, selecionar, mapear, organizar e disseminar a
informação. Por isso, os sistemas de informação e de banco de dados atrelados aos
rápidos avanços tecnológicos e as exigências competitivas do mercado tornam-se
indispensáveis nas atividades das organizações.
As bibliotecas são organizações que tem a informação como foco de suas
atividades e possuem um importante papel dentro das universidades. Na biblioteca
universitária a disseminação da informação contribui para a produção do conhecimento
no meio acadêmico, incentivando o uso adequado das informações e dos conhecimentos
e minimizando os esforços dos usuários (DIAS, 2005).
A disseminação da informação é um importante veículo de comunicação entre a
biblioteca e seus usuários, que têm necessidades informacionais distintas de acordo com
o perfil e área de atuação. É papel da biblioteca fornecer ao seu usuário o produto
informacional que supra a suas necessidades específicas, quer seja para estudo, para
pesquisa ou para a tomada de decisão (TARAPANOFF; ARAÚJO JÚNIOR;
CORMIER, 2000).
As tecnologias de informação são aliadas na disponibilização dos serviços de
informação. Os usuários necessitam obter informações mais selecionadas em menor
_______________________________________________
96
tempo e para atendê-los com maior agilidade e eficiência as bibliotecas precisam utilizar
as tecnologias disponíveis, tanto para a divulgação dos serviços oferecidos como para
disponibilização de informações de acordo com o interesse dos seus usuários.
Ainda com o intuito de agregar valor na disseminação das informações sobre as
novas aquisições de uma biblioteca universitária foram utilizadas tecnologias como a
mineração de dados, em especial a técnica de regras de associação. Tal técnica é
empregada para detectar informações de correlações ou tendências entre dados de
transações em bases de dados, de modo que possam ser úteis na disponibilização de
serviços de informação.
O principal objetivo neste trabalho foi promover a disseminação de informações
referentes às novas aquisições de livros em uma biblioteca universitária. Em geral as
bibliotecas adotam padrões internacionais de catalogação e classificação para os
materiais bibliográficos, como por exemplo, a classificação Decimal de Dewey (CDD)
que divide o conhecimento em áreas onde cada assunto é representado por um número
que é atribuído as obras de acordo com o assunto destas.
O sistema proposto permite enviar periodicamente informações de livros para os
usuários a partir de um perfil previamente definido com áreas de interesse, incluindo
sugestões de livros de outras áreas, detectadas pelo uso das regras de associação, que
também possam interessar.
2. Gestão e Disseminação da Informação Associada à Mineração de Dados

A informação está inserida em todos os ambientes e em todas as atividades humanas,
sociais, científicas, tecnológicas, culturais, políticas e econômicas, assumindo um novo
status e importância na sociedade atual. Tais informações são variadas e produzidas de
forma contínua, necessitando ser recuperadas, classificadas, organizadas, processadas,
analisadas e difundidas pelas organizações no menor tempo possível (STAREC, 2005).
Por isso gerenciar a informação é primordial, e pode se tornar uma vantagem
competitiva. Silva e Tomaél (2007, p. 1) afirmam que “para ser utilizada
estrategicamente, é fundamental que a informação seja gerida em favor da sobrevivência
e competitividade organizacional.”
A gestão da informação engloba a prospecção, seleção e obtenção da
informação; o mapeamento e reconhecimento dos fluxos formais de informação; o
tratamento, análise e armazenamento da informação utilizando tecnologias de
informação; a disseminação e mediação da informação ao público interessado, e a
criação e disponibilização de produtos e serviços de informação (VALENTIM, 2002).
No contexto acadêmico as bibliotecas são as principais responsáveis pela gestão
da informação e possuem um papel importante dentro da universidade ao disponibilizar
diversos tipos de materiais bibliográficos que proporcionam informações aos seus
usuários. As bibliotecas universitárias “têm como missão oferecer aos seus usuários
informações relevantes para a realização de pesquisas e para o ensino, procurando tornar
o acesso, a recuperação e a localização das informações compatíveis com as suas
necessidades.” (LUCAS; SOUZA, 2007, p. 2).
_______________________________________________
97
A disseminação da informação é uma importante etapa da gestão da informação,

completando o processo de seleção, tratamento e análise da informação. Disseminar
significa difundir, propagar, semear ou espalhar por muitas partes (MICHAELIS, 1998).
As bibliotecas universitárias devem oferecer serviços de informação que
satisfaçam as expectativas e as necessidades dos usuários (CORTES; LOPES, 2008).
Com um volume cada vez maior de informações disponíveis é fundamental que a
informação enviada a um usuário seja o mais próximo daquilo que ele necessita.
Por isso, oferecer um serviço de Disseminação Seletiva da Informação (DSI),
que fornece ao usuário uma relação periódica de fontes informacionais, relacionadas
com sua área e detectadas a partir do preenchimento de um perfil de interesse (SOUTO;
PORTELA, 2003/2004) torna-se um diferencial para as bibliotecas.
No caso específico das bibliotecas universitárias os usuários têm necessidades
informacionais distintas de acordo com o perfil de cada um e de sua área de atuação.
Esses usuários também necessitam estar sintonizados com as publicações de seu
interesse e, principalmente, com as novas aquisições efetuadas pela biblioteca.
No cenário atual, em que as pessoas têm cada vez menos tempo, os serviços
online são os aliados para atender essas demandas, pois com o uso da Internet não
existem barreiras de tempo e espaço, e o serviço é amplamente acessível. Os usuários
“para atender às exigências da sociedade atual, estão cada vez mais à procura de
praticidade e rapidez, vantagens estas, que as inovações tecnológicas proporcionam.”
(CORTES; LOPES, 2008, p.117). E a “[...] Internet trouxe um aumento considerável
quanto à oferta de informações e às possibilidades de sua disseminação.” (DIAS, 2005,
p.86).
Além disso, com a necessidade de obter informações cada vez mais rápidas
surgem novas metodologias utilizadas para a análise qualitativa e quantitativa, como a
mineração de dados, que é uma tecnologia muito útil no gerenciamento de informação.
A mineração de dados ou a extração de dados específicos de enormes campos de
informação é um conceito em moda na gestão da informação (FERAUD, 2004).
2.1. Descoberta de Conhecimentos em Banco de Dados

Nos últimos anos, os avanços tecnológicos têm proporcionado a retenção de grandes
volumes de dados para as empresas, atraindo a atenção para a mineração de dados,
devido à necessidade de transformar esses dados em conhecimentos úteis (HAN;
KAMBER, 2006). Da necessidade de técnicas e ferramentas específicas para análise e
extração de conhecimento surge o Knowledge Discovery in Databases (KDD) ou
descoberta de conhecimento em base de dados, visto como “um processo não trivial de
identificação de padrões válidos, novos (desconhecidos até então), potencialmente úteis,
e compreensíveis.” (FAYYAD; PIATETSKY-SHAPIRO; SMYTH, 1996, p. 6, tradução
nossa).
Assim, o processo de descoberta de conhecimento envolve várias etapas não
lineares, onde o processo envolve interação e a iteração significativa, que pode conter
loops entre duas etapas ou mais, sendo a mineração de dados uma das etapas do KDD
(FAYYAD; PIATETSKY-SHAPIRO; SMYTH, 1996). A Figura 1 apresenta as etapas
do KDD.
_______________________________________________
98
Fonte: adaptado de Fayyad, Piatetsky-Shapiro e Smyth (1996, p.10).

Figura 1. Etapas do Processo da Descoberta de Conhecimento em Banco de
Dados.
Resumidamente as etapas do KDD são definidas em:

a) dados: compreender o domínio da aplicação e os objetivos do usuário final;
b) seleção: selecionar o conjunto de dados para análise na qual a descoberta deve
ser realizada;
c) pré-processamento: tratar ruídos, como campos de dados faltantes, nulos ou
repetidos, corrigir prováveis erros relevantes para a mineração dos dados;
d) transformação: formatar os dados conforme o objetivo da tarefa, utilizando
redução de dimensionalidade ou métodos de transformação para reduzir o
número de variáveis em consideração;
e) mineração de dados: definir o método e a técnica a ser utilizada para a
descoberta de padrões, bem como o algoritmo que irá realizar a extração desses
padrões de interesse, ajustando-o se necessário;
f) interpretação e avaliação: analisar os resultados obtidos através da mineração,
com possibilidade de retorno aos passos anteriores;
g) conhecimento: incorporar o conhecimento obtido ao sistema, documentar e
reportar os resultados às partes interessadas (FAYYAD; PIATETSKY-
SHAPIRO; SMYTH, 1996).
2.2. Regras de Associação

Dentre as técnicas da mineração de dados, a regra de associação se destaca por ser uma
técnica que permite encontrar padrões, associações ou correlações em conjuntos de itens
frequentes de uma base de dados transacional, relacional ou de outros tipos de
repositórios de informação (NEVES, 2002).
Um exemplo comum da utilização de regras de associação para mineração na
descoberta de padrões através das compras realizadas, transações feitas, por clientes em
supermercados ou lojas, na qual uma mercadoria está relacionada a outra, “[...]
conhecida também como transações de cestas de compras.” (TAN; STEINBACH;
KUMAR, 2009, p. 389). A partir desses padrões encontrados, o estabelecimento poderia
realizar promoções de vendas em determinados produtos ou também conhecer o perfil
de seus consumidores.
_______________________________________________
99
Regras de associação basicamente têm duas medidas utilizadas para análise, o

suporte e a confiança. “O suporte determina a freqüência na qual uma regra é aplicável a
um determinado conjunto de dados, e a confiança determina a freqüência na qual os
itens em Y aparecem em transações que contenham X.” (TAN; STEINBACH; KUMAR,
2009, p. 392).
Formalizando o problema para mineração de regras de associação conforme
Agrawal et al (1996), seja I = {i1, i2,...,im} um conjunto de itens e D um conjunto de
transações, onde cada transação T é um conjunto de itens (itemset) tal que T ⊂ I.
Associado a cada transação está um único identificador, chamado identificador único de
transação (TID). Assim, uma regra de associação é uma implicação na forma expressa
por X=>Y (X então Y), sendo X denominado de antecedente e Y consequente da regra,
onde X e Y são itemsets distintos, representados na expressão X ⊂ I, Y ⊂ I e X ∩ Y =
∅.
O suporte da regra X=>Y é definido na expressão como
sup(X=>Y) = σ (X ∪ Y) /D, ou seja, é a razão entre o contador de suporte contendo X e Y
e o total de transações. E a confiança da regra X=>Y é definida na expressão como
conf(X=>Y) = σ (X ∪ Y) / σ (X), é a razão entre o contador do suporte contendo X e Y e o
contador do suporte contendo X (TAN; STEINBACH; KUMAR, 2009).
Para que uma regra seja interessante, ou dita forte, deve atender os critérios,
tenha suporte ≥ minsup e a confiança ≥ minconf, sendo minsup e minconf os limites de
suporte e confiança respectivamente definidos (TAN; STEINBACH; KUMAR, 2009).
Então, a estratégia utilizada é decompor o problema em duas etapas, encontrar
todos os conjuntos de itens que tenham o seu suporte maior que o suporte mínimo
estabelecido, estes conjuntos são chamados de conjuntos de itens frequentes. Após
encontrar os conjuntos de itens frequentes, gerar as regras que atendam a um mínimo de
confiança (AGRAWAL et al., 1996).
O algoritmo Apriori, muito conhecido por encontrar regras de associação, foi um
dos primeiros a adotar a abordagem de suporte mínimo estabelecido para gerar
conjuntos de itens candidatos (TAN; STEINBACH; KUMAR, 2009). Basicamente é
dividido em duas fases e funciona iterativamente de modo a encontrar conjuntos de itens
frequentes em uma determinada base de dados para que posteriormente sejam extraídas
as regras de associação.
Na primeira fase, inicia com todos os itens da base como sendo um conjunto de
um item, é feito a contagem do suporte para cada conjunto, são eliminados os conjuntos
que não atendem ao suporte mínimo definido, restando somente os conjuntos de um
item ditos frequentes. A partir desse conjunto, são gerados novos conjuntos candidatos,
contendo agora dois itens cada conjunto, verifica-se novamente o suporte e em seguida
são eliminados novamente aqueles, cujo suporte é inferior ao mínimo definido. Assim, o
processo é repetido n vezes até não haver mais conjuntos de itens candidatos, resultando
nos conjuntos contendo os itens mais frequentes da base de dados (TAN; STEINBACH;
KUMAR, 2009).
Encontrados então os conjuntos de itens frequentes, na segunda fase são geradas
as regras de associação candidatas e extraídas as regras fortes que atendam a um suporte
mínimo de confiança utilizado como parâmetro.
_______________________________________________
100
Sendo assim, seja uma base de dados de transações qualquer, onde os itens são
algumas áreas (Quadro 1), deseja-se encontrar itens frequentes para extrair regras, cujo
valor do suporte mínimo deve ser de 50% ou mais, (contador do suporte maior ou igual
a 3), e a confiança mínima da regra 70% ou superior.
Quadro 1. Exemplo de uma base de dados com transações
TID Itens
1 Administração, Contabilidade
2 Direito, Administração, Contabilidade
3 Administração, Economia, Direito
4 Administração, Contabilidade
5 Direito, Ciência política
São gerados os conjuntos candidatos e encontrados os conjuntos de itens

frequentes dessa base, conforme Quadro 2.
Quadro 2. Geração dos conjuntos de itens frequentes
Com base nos conjuntos de itens frequentes gerados, são extraídas então as
regras de associação que possuem relação com outros itens e que satisfaçam a confiança
mínima definida para o problema em questão, de acordo com o Quadro 3.
Quadro 3. Exemplo da extração de regras de associação com base no algoritmo
Apriori.
Das duas regras de associação geradas, podemos verificar que com relação à
base de dados mencionada, a primeira regra mostra que 75% das transações onde há
Administração, encontramos Contabilidade. Já na outra regra, o nível da confiança é
ainda maior, pois 100% das transações contendo Contabilidade também há
Administração.
_______________________________________________
101
Assim podemos perceber a correlação entre os itens de uma determinada base de

dados contendo dados de transações, e a incidência em que um item pode apresentar em
relação a outro, sugerindo então informações de tendências que podem ser aproveitadas
nas organizações de diversas formas.
3. Desenvolvimento do Sistema
O sistema proposto compreende em um portal disponibilizado na internet, desenvolvido
em linguagem de programação PHP com HTML e CSS, hospedado em um servidor
Apache. E ainda um módulo gerencial para promover a disseminação das informações
aos usuários, desenvolvido em ambiente de programação Delphi, e alocado em um
servidor com plataforma Windows Server. O gerenciador de banco de dados utilizado foi
o Oracle 10g e PL/SQL para criação de funções auxiliares do banco.
4. Implementações e Resultados
Para o usuário acessar ou configurar seu perfil no portal, deve-se efetuar o login com
seu nome de usuário e sua senha. Ao se autenticar é apresentado ao usuário o seu perfil,
no qual ele irá selecionar as suas preferências. No topo da página são mostradas
algumas opções, como por exemplo, alteração do e-mail, menu de ajuda ou sair da
página. No centro da página encontram-se as áreas ou assuntos de interesse,
disponibilizadas em um total de cem áreas, na qual o usuário pode optar selecionando
cada uma delas. A Figura 2 apresenta parte da página principal do perfil do usuário.
Figura 2. Parte da página principal de preferências do usuário
Após o usuário selecionar as áreas de sua preferência, mais ao final da página o

usuário decide por autorizar ou não o recebimento de informações em seu e-mail. Por
fim, irá clicar no botão “Salvar” para gravar as suas informações, conforme Figura 3.
Figura 3. Parte da página principal para autorização e salvar preferências
_______________________________________________
102
A disseminação das informações é feita por um aplicativo que é acessado

somente pelo administrador, e é executada periodicamente de forma automatizada,
permitindo a geração e o envio dos relatórios personalizados para cada usuário. O
administrador ainda poderá efetuar a execução manual do aplicativo caso seja
necessário, e também efetuar alterações de parâmetros, consultas e relatórios estatísticos
de utilização do sistema. Entretanto, a maior importância desse módulo encontra-se nas
sub-rotinas de processamento das informações que serão encaminhadas aos usuários e
juntamente com a mineração das regras de associação.
Basicamente a ferramenta efetua a busca por novas aquisições, correspondente a
cada área que o usuário selecionou em seu perfil. Em seguida, são extraídas as áreas
correlatas do perfil do usuário, geradas a partir das regras de associação, e então é feita
uma nova busca por novas aquisições conforme cada área correlata gerando as sugestões
que possam ser de interesse ao usuário.
É importante ressaltar que as áreas correlatas que geram as sugestões podem
diferir das áreas compreendidas no site, visto que estariam disponíveis apenas as
principais áreas, já previamente estipuladas pela instituição, entretanto o usuário não
ficaria privado de estar recebendo informações de outras áreas e que poderiam ser de
relevância.
Por fim, se houver alguma informação de nova aquisição no relatório gerado,
tanto informações conforme as áreas selecionadas no perfil, como sugestões detectadas
a partir das áreas correlatas, são enviadas para o e-mail do respectivo usuário, a exemplo
da Figura 4.
Figura 4. Parte do e-mail com relatório personalizado conforme perfil
Para gerar as sugestões foi feita uma adaptação de Apriori no caso específico da
biblioteca. Enquanto Apriori encontra primeiramente os conjuntos de itens frequentes na
base de transações e posteriormente gera as regras a partir dos itens freqüentes, neste
trabalho, foi necessário encontrar as áreas correlatas a partir de cada área disponibilizada
no perfil do usuário. Assim, as áreas do perfil foram tratadas como itens frequentes e
consideradas antecedentes da regra.
Depois de calculado o suporte da área que antecede a regra, são encontradas as
áreas correlatas, os consequentes da regra, que satisfazem o suporte de confiança
mínimo definido previamente pelo administrador. Devido à grande quantidade de áreas
_______________________________________________
103
na qual os livros estão classificados, percebeu-se que os percentuais de confiança na

grande maioria das regras geradas não ultrapassaram os 50%. Já para um percentual
abaixo de 20% muitas regras são encontradas nas quais muitas informações de livros
são geradas, podendo conter informações em excesso ao usuário. Assim, a sugestão de
um percentual mínimo ideal no contexto verificado estaria compreendida entre 20% e
45% para a geração de regras, definido a critério do administrador.
O modelo de regra de associação adotada para este trabalho diz-se do primeiro
nível, sendo apenas uma área para o antecedente e uma área para o consequente da regra
gerada, por exemplo, a área X do perfil possui a área Y como consequente.
O identificador único de transação (TID) utilizado para a extração das regras, a
partir das transações de livros emprestados, é o código do usuário. E é importante
ressaltar que o foco deste trabalho está na área que o livro pertence, conforme o número
de classificação da CDD. Assim, independente da quantidade de livros ou títulos
emprestados pelo usuário, cada área é contabilizada uma única vez por usuário. Um
exemplo dessa abordagem está representado no Quadro 4.
Quadro 4. Exemplo da base de dados de transações da abordagem adotada
TID Áreas (cód. área da CDD)
(cód. usuário) 005.1 342.1 630 658 370 813
001 1 0 0 1 0 1
002 0 1 0 0 1 0
003 0 1 1 0 0 1
004 1 1 0 1 0 1
005 0 1 1 1 0 1
Contador 2 4 2 3 1 4
Para encontrar as áreas correlatas e gerar as regras de associação, utilizou-se

dados reais de uma biblioteca universitária, baseando-se nos registros das transações do
histórico de empréstimos realizados em um período de aproximadamente um ano. Foi
necessário ainda efetuar um pré-processamento, removendo ruídos e reunindo somente
os dados de interesse, e posteriormente alocando esses dados em uma nova tabela, do
tipo view materializada, para então aplicar a mineração, pois havia mais de um milhão e
meio de registros.
A tabela visão foi criada no intuito de agilizar e facilitar a extração das regras de
associação, uma vez que os dados reunidos eram de várias tabelas incluindo a tabela de
histórico de empréstimos, sendo assim a view deve ser atualizada periodicamente para
que as regras estejam sempre em conformidade com a demanda mais atual dos
empréstimos realizados. O Quadro 5 apresenta um fragmento da instrução que gera a
view.
Quadro 5. Fragmento da instrução que gera a view
_______________________________________________
104
Assim, a partir de uma área selecionada no perfil do usuário, busca-se na view

quais são os usuários que fizeram empréstimos de livros daquela mesma área, e depois
verifica-se quais são as outras áreas relacionadas por esses mesmos usuários, por
exemplo, usuários que emprestam livros da área X, também emprestam livros da área Y,
digamos que esta seja uma regra gerada X=>Y, dessa maneira, um usuário que
selecionou a área X em seu perfil, estaria recebendo informações da área X e também
informações livros da área Y sob a forma de sugestões.
No Quadro 6, é apresentado um fragmento de código que gera as regras de
associação ou áreas correlatas em relação às áreas selecionadas pelo usuário em seu
perfil.
Quadro 6. Fragmento de código para gerar as regras de associação
A utilização da técnica para minerar as áreas correlatas a partir do perfil do

usuário gerou resultados interessantes, revelando relações que até então eram
desconhecidas entre algumas áreas. Dentre os casos de regras geradas para um
percentual mínimo de confiança de 30%, podemos mencionar as áreas “Artes” e
“Literatura Inglesa” como sendo os antecedentes das regras, por exemplo, teríamos as
seguintes regras geradas pelo sistema, conforme o Quadro 7.
Quadro 7. Exemplo de regras geradas pelo sistema
Regras geradas Confiança
Artes (700) => História da Moda (391) 42%
Artes (700) => Arte e sociedade (701) 37%
Artes (700) => Desenho industrial (745.2) 37%
Literatura Inglesa (823) => Literatura Americana (813) 58%
Literatura Inglesa (823) => Literatura Brasileira (869.93) 32%
Assim, o usuário que tivesse selecionado “Artes” e “Literatura Inglesa” em seu

perfil, estaria recebendo além de livros dessas áreas, também receberia como sugestões
livros classificados nas áreas, conforme a CDD, “História da Moda”, “Arte e
Sociedade”, “Desenho industrial”, “Literatura Americana” e “Literatura Brasileira”.
_______________________________________________
105
5. Conclusão
Gerenciar a informação em uma biblioteca universitária, especificamente a
disseminação da informação sobre novas aquisições do acervo bibliográfico, mostrou-se
importante para a criação de um canal de comunicação eficaz com seus usuários,
possibilitando a disseminação de informações sobre o acervo diretamente para o e-mail
deles, minimizando tempo gasto com buscas e maximizando o uso dos recursos
tecnológicos.
A utilização da tecnologia de mineração de dados para extração de informações
em base de dados, especificamente da técnica de regra de associação, foi útil também
como ferramenta gerencial, pois permitiu encontrar correlações entre algumas áreas que
ainda eram desconhecidas e em outros casos possibilitou constatar associações que se
acreditava existir.
O emprego das regras de associação para o desenvolvimento do sistema
possibilitou prever possíveis necessidades de informação ao verificar que quem
empresta obras de uma área também empresta de outra determinada área. Isto permitiu
criar um sistema mais elaborado que além de enviar por e-mail as informações de
interesse do usuário, conforme a seleção feita previamente por este, também envia
informações de obras que podem interessar a estes usuários, detectadas pelo uso das
regras de associação.
Entretanto, foram encontradas algumas limitações durante o desenvolvimento do
sistema, como por exemplo, a quantidade restrita de áreas disponível na interface web
para o usuário, áreas estas que já estavam predefinidas pela biblioteca como sendo as
áreas mais gerais da CDD relacionadas aos cursos da universidade, e desconsiderando as
mais específicas.
Por fim, o sistema proposto irá proporcionar que a biblioteca disponibilize um
serviço de disseminação da informação mais condizente com as necessidades dos
usuários. E o usuário se beneficia com a disponibilização do serviço, pois terá um
instrumento de atualização na sua área de atuação.
Referências
AGRAWAL, Rakesh et al. Fast discovery of association rules. In: FAYYAD, Usama M.
et al. Advances in knowledge discovery and data mining. Menlo Park: AAAI:
MIT, 1996. p. 307-328.
CORTES, Márcia Della Flora; LOPES, Marilisa Leite. As bibliotecas universitárias
federais brasileiras e a acessibilidade das informações em seus websites. Revista
ACB: Biblioteconomia em Santa Catarina, Florianópolis, v. 13, n.1, p.117-129,
2008. Disponível em:
<http://revista.acbsc.org.br/index.php/racb/article/viewArticle/552>. Acesso em: 01
jun. 2010.
DIAS, Simone Lopes. A disseminação da informação mediada por novas tecnologias
e a educação do usuário na Biblioteca Universitária. 2005. 138 f. Dissertação
(Mestrado em Ciência da Informação) – Faculdade de Filosofia e Ciências,
Universidade Estadual Paulista, Marília, 2005. Disponível em:
_______________________________________________
106
<http://polo1.marilia.unesp.br/Home/Pos-
Graduacao/CienciadaInformacao/Dissertacoes/dias_sl_me_mar.pdf>. Acesso em 01
jun. 2010.
FAYYAD, Usama M.; PIATETSKY-SHAPIRO, Gregory; SMYTH, Padhraic. From
data mining to knowledge discovery: an overview. In: FAYYAD, Usama M. et al.
Advances in knowledge discovery and data mining. Menlo Park: AAAI: MIT,
1996. p. 1-34.
FERAUD, Genevière. Um século de gestão da informação. In: DAVENPORT, Thomas
H.; MARCHAND, Donald A.; DICKSON, TIM. Dominando a gestão da
informação. Porto Alegre: Bookman, 2004. p. 39-44.
HAN, Jiawei; KAMBER, Micheline. Data Mining: concepts and techniques. 2nd ed.
Amsterdan: Elsevier, 2006.
LUCAS, Elaine R. de Oliveira; SOUZA, Nicole Amboni de. Disseminação seletiva da
informação em Bibliotecas Universitárias sob o prisma do Customer Relationship
Managment. Informação & Informação, Londrina, v. 12, n. 1, p. 1- 17, 2007.
Disponível em:
<http://www.uel.br/revistas/uel/index.php/informacao/article/viewArticle/1745>.
Acesso em: 01 jun. 2010.
MICHAELIS: moderno dicionário da língua portuguesa. 4. ed. São Paulo :
Melhoramentos, 1998.
NEVES, João Manuel Poças Marques das. Ambiente de pós-processamento para
regras de associação. 2002. 118 f. Dissertação (Mestrado em Análise de Dados e
Sistemas de Apoio à Decisão) - Faculdade de Economia, Universidade do Porto,
Porto, 2002. Disponível em:
<http://www.fep.up.pt/cursos/mestrados/madsad/teses/tese_mestrado_joao_pocas_po
s_processamento_ra.pdf>. Acesso em: 30 maio 2010.
SILVA, Terezinha Elisabeth da; TOMAÉL, Maria Inês. A gestão da informação nas
organizações. Informação e Informação, Londrina, v. 12, n. 2, p. 1-2, jul./dez.
2007. Disponível em:
<http://www.uel.br/revistas/uel/index.php/informacao/article/viewFile/1806/1540>.
Acesso em: 01 jun. 2010.
SOUTO, Leonardo Fernandes; PORTELA, Patrícia de Oliveira. O SDI como
instrumento de educação continuada: a responsabilidade das universidades no
treinamento dos usuários. Revista da ACB: Biblioteconomia em Santa Catarina,
Florianópolis, v. 8/9, p. 123-133, 2003/2004. Disponível em: <
http://revista.acbsc.org.br/index.php/racb/article/view/411>. Acesso em 05 mar.
2010.
STAREC, Claudio. A dinâmica da informação: a gestão estratégica da informação para
a tomada de decisão nas organizações. In: STAREC, Claudio; GOMES, Elisabeth;
BEZERRA, Jorge. Gestão estratégica da informação e inteligência competitiva.
São Paulo: Saraíva, 2005. p. 47-64.
TAN, Pang-Ning; STEINBACH, Michael; KUMAR, Vipin. Introdução ao data
mining: mineração de dados. Rio de Janeiro: Ciência Moderna, 2009.
_______________________________________________
107
TARAPANOFF, Kira; ARAÚJO JÚNIOR, Rogério Henrique de; CORMIER, Patricia

Marie Jeanne. Sociedade da informação e inteligência em unidades de
informação. Ciência da Informação, Brasília, v. 29, n.3, p. 91-100, set./dez. 2000.
Disponível em: <http://www.scielo.br/scielo.php?pid=S0100-
19652000000300009&script=sci_arttext&tlng=es>. Acesso em: 30 maio 2010.
VALENTIM, Marta Ligia Pomim. Inteligência Competitiva em Organizações: dado,
informação e conhecimento. DataGramaZero: Revista de Ciência da Informação,
Rio de Janeiro,- v.3, n.4, p.1-13, ago. 2002. Disponível em:
<http://www.dgz.org.br/ago02/Art_02.htm.>. Acesso em: 16 maio 2010.
_______________________________________________
108
Índice de Autores
Adriana Ariati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Adriana S. Zanini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Alessandro A. Ostetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
André Lara Temple de Antonio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Anita M.R.Fernandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Beatriz T. Borsoi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Carlos Alberto Murari Pinheiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Celly de Siqueira Martins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Cláudio Ratke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Clavison M. Zapelini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Eliane M. de B. Fávero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Eros Comunello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Felipe S.Vieira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Fernando dos Santos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Leonardo Veronese Soletti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Luiz Eduardo Guarino Vasconcelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Maciel F. da Silva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Marcel Hugo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Mauricio Amorim da Silva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Nelson Paiva Oliveira Leite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Otávio Augusto Salgado Carpinteiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Rafael Paz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Renato Silva Belazi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Rúbia E. O. Schultz Ascari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Sidnei Renato Silveira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Sindo Vasquez Dias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Vandir Fernando Rezende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
_______________________________________________
XX SEMINCO - SEMINÁRIO DE COMPUTAÇÃO
XX
SEMINCO
XBr
yrj = mi
yrj >n0
{ Xy {
Bi
ji
SEMINÁRIO DE COMPUTAÇÃO
FUNDAÇÃO UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CIÊNCIAS EXATAS E NATURAIS
DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
CURSO DE SISTEMAS DE INFORMAÇÃO
CENTRO ACADÊMICO LIVRE DE COMPUTAÇÃO
CENTRO ACADÊMICO DE SISTEMAS DE INFORMAÇÃO
APOIO
FURB CCEN CENTRO DE COMUNICAÇÃO E MARKETING
PROJETO ACREDITO SOCIEDADE BRASILEIRA DE COMPUTAÇÃO

Idioma

XX Seminco

Enviado por

Dados do documento

Descrição:

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Descrição:

Direitos autorais:

XX Seminco

Enviado por

Descrição:

Direitos autorais:

XX SEMINCO - SEMINÁRIO DE COMPUTAÇÃO

Seminário de Computação (20.: 2011 : Blumenau, SC)

Anais do XX SEMINCO / promoção Universidade Regional de Blumenau, Departamento de Sistemas

Universidade Regional de Blumenau

Análise Comparativa entre Groovy e Java, Aplicado no Desenvolvimento Web 18

Vandir Fernando Rezende, Marcel Hugo

Integração Hardware / Software

Alessandro A. Ostetto, Fernando dos Santos

Utilização de Processamento Digital de Imagens e Redes Neurais Artificiais para 56

Sistema Especialista para Indicação de Medicamentos Fitoterápicos 70

Leonardo Veronese Soletti, Sidnei Renato Silveira

Gestão da Informação em Biblioteca Universitária: uma Proposta Utilizando Regras 95

Uma Proposta de Modelo Conceitual para Repositório de

Resumo. O reuso de artefatos de software ainda é um desafio. Isso porque é

2. Reuso e Repositório de Artefatos

recentemente devido à possibilidade de desenvolvimento distribuído de software [Shiva e

2.1 Métodos de Classificação e Recuperação de Artefatos

seguintes formas: classificação por palavras-chave, por enumeração e classificação em

Desta forma, a partir dos estudos realizados sobre classificação e recuperação de

referem-se ao armazenamento e recuperação de componentes de código, a fim de oferecer

4. Modelo Conceitual de Repositório de Artefatos Visando Reuso

Produção Software Produção Armazenamento

Figura 1. Processos para produção de software com e para reuso

componentes de software em sete grupos: identificação, uso, maturidade, documentação,

Figura 2. Visão geral do repositório de artefatos

no repositório visando identificar artefatos que possam estar relacionados e os sugere ao

Figura 3. Visão geral da busca no repositório de artefatos

Frakes, W. B. and Pole, T. P. (1994). An empirical study of representation methods for

Neighbours, J. M. (1984), The draco approach to constructing software from reusable

Análise comparativa entre Groovy e Java, aplicado no

Departamento de Sistemas e Computação

Resumo. Este artigo apresenta uma análise comparativa, no desenvolvimento

Neste cenário, foi desenvolvido um aplicativo de gestão de projetos, sendo ele

2. NBR ISO/IEC 9126-1

3. Características das Linguagens de Programação

As características de linguagens de programação avaliadas neste trabalho são:

procedurais, para explorar a reutilização de código e evitar reinventá-lo (TUCKER;

4. Meio de Avaliação dos Critérios

Custo Usabilidade Eficiência Manutenibilidade Confiabilidade

Desta forma, ao concluir que determinada característica em uma linguagem é

classificou as características em dois grupos distintos, no qual foram denominados pelos

Ao término do desenvolvimento, são obtidos os valores por caso de uso em cada

5. Diferenças entre Groovy e Java

f) conceito de verdade: Groovy considera verdadeiro qualquer valor que seja

Figure 1. Código Groovy

h) laços de repetição: assim como no Java, em Groovy há várias maneiras de

Figura 2. Casos de uso do aplicativo exemplo

A figura 3 apresenta o digrama de classes desenvolvido para o estudo de caso.

Figura 3. Diagrama de classes do aplicativo exemplo

Contudo, mesmo observando-se que o jCompany aumenta a produtividade,

b) acessar projeto: cd nome_projeto;

Ao término destes passos, pode-se observar o quão é produtivo o framework

Os programas gerados podem executar em qualquer plataforma? X X

As questões que obtiveram respostas distintas foram destacadas para facilitar a

Ao responder o questionário, notou-se grande semelhança entre as linguagens,

Ao analisar os resultados obtidos (quadro 5), pode-se concluir que para

Quadro 6. Comparativo de desempenho.

Com base no quadro 6, pode-se concluir que a linguagem Java possui,

10. Considerações Finais

Ao término do desenvolvimento do estudo de caso em ambas as linguagens, foi

Desenvolvimento de um Protótipo para Ensaios de Calibração

2. Visão Geral da Calibração do Sistema de Dados Aéreos

2.1. Calibração do Sistema de Dados Aéreos