Sinforme2012
57
S.I.nforme
-
Upload
rodrigo-lira -
Category
Documents
-
view
237 -
download
12
description
Â
Transcript of Sinforme2012
S.I.nforme
ISSN 2316-5804
S.I.NFORME
Revista de Tecnologia da Informação do Curso de Sistemas de
Informação
Faculdade Escritor Osman da Costa Lins - FACOL
Vitória de Santo Antão, PE – ANO 1, Nº. 1 – dez.2012
S.I.nforme
Publicação anual
Revista do Curso de Sistemas de Informação – Bacharelado da Faculdade Escritor Osman da Costa
Lins – Facol
Diretor da FACOL: Dr. Paulo Roberto de Leite Arruda
Vice-Diretor da FACOL: Túlio Albuquerque Duarte
Diretor Pedagógico: Prof. Péricles Tavares Austregésilo Filho
Coordenadora Geral Acadêmica: Profª. Nancy Farias Martins Leite
Coordenador do Curso de Sistemas de
Informação Prof. MSc. Cleyton Mário de Oliveira
Rodrigues
Conselho Editorial: Cleyton Mario de Oliveira Rodrigues
Elcias Ferreira da Costa
Péricles Tavares Austregésilo Filho
José Procópio da Silveira
Gleibson Rodrigo Silva de Oliveira
Conselho Científico: Prof. MSc. Cleyton Mário de Oliveira
Rodrigues
Prof. MSc. Ryan Ribeiro de Azevedo
Profª. MSc. Ana Cristina Freitas CesarStefano
Toscano
Profª. Esp. Audrey Bezerra de Vasconcelos
Prof. Esp. Iuri Santos Souza
Profª. Msc. Jailze de Oliveira Santos
Profº. Esp. Gleibson Rodrigo Silva de Oliveira
Diagramação: Evandro Bonifácio de Andrade – Departamento
de Web Design.
Publicação: Associação Vitoriense de Educação, Ciências e
Cultura, entidade mantenedora da Faculdade
Escritor Osman da Costa Lins – FACOL.
CNPJ: 03.391.726/0001-90.
Endereço:
Rua do Estudante, 85, Bairro Universitário, Vitória de Santo Antão/PE. CEP 55612-650. Tel. (81)
3114-1200 www.facol.com - e-mail: [email protected]
IMPRESSÃO:
Luci Artes Gráficas Ltda
REVISTA DE TECNOLOGIA DA INFORMAÇÃO DO CURSO DE SISTEMAS DE
INFORMAÇÃO: S.I.nforme
Vitória de Santo Antão, PE: Facol, a. 1, n.1 ___. 2012, ____p.
ISSN 2316-5804
1
SUMÁRIO
SEVAC: Um Estudo de Caso do Uso de Sistemas Especialistas na Educação Básica _ 3
Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao
FireScrum ___________________________________________________________ 12
LSVF: A heuristic search to reduce the backtracking calls when solving Constraint
Satisfaction Problems __________________________________________________ 19
O Lixo eletrônico no Brasil: Leis e Impactos Ambientais ______________________ 28
An Experimental Research on the Relationships between Preferences for
TechnicalActivities and Behavioural Profile in Software Development ___________ 34
CHRr f ∨: A Logic Inference Engine to Resolution Leveraged by Heuristics _______ 51
2
EDITORIAL
3
SEVAC: Um Estudo de Caso do Uso de Sistemas Especialistas
na Educação Básica
Maria José dos Santos Takeshita1, Cleyton Mário de Oliveira Rodrigues2
1 Sistemas de Informação– Faculdade Escritor Osman da Costa Lins (FACOL)
Vitória de Santo Antão – PE – Brasil
2Centro de Informática – Universidade Federal de Pernambuco, (CIn/UFPE) Código
Postal 7851 – RECIFE – PE – Brasil
[email protected], [email protected]
Abstract. To evaluate the knowledge acquired by students of Elementary
Education is a subject that involves areas of cognitive psychology, approaches
and styles of teaching/learning process and, more recently, the use of
techniques that concern the field of Artificial Intelligence. This article, in this
context, presents a proposal using the I. A. to assess and diagnose the learning
of elementary school students based on an Expert System. This proposal was
substantiated through a case study within a context of knowledge in
particular; it also presents the questionnaires through which we sought to
assess the acceptability of the system developed by both the teachers as the
student body.
Resumo. Avaliar o conhecimento adquirido pelos alunos da Educação
Elementar é um tema que envolve áreas da Psicologia Cognitiva, das
abordagens e estilos do processo Ensino/Aprendizagem e, mais recentemente,
do uso de técnicas que tangem o domínio da Inteligência Artificial. Este
artigo, neste contexto, apresenta uma proposta utilizando a I. A. para avaliar
e diagnosticar o aprendizado de alunos do Ensino Fundamental baseado em
um Sistema Especialista. Tal proposta foi fundamentada através de um estudo
de caso, dentro de um contexto de conhecimento em particular; ela também
apresenta questionários através do qual se pretendeu avaliar a aceitação do
sistema desenvolvido tanto pelo corpo docente, como pelo corpo discente.
1. Introdução
De acordo com [Valente 2009] “o termo Informática na Educação significa a inserção
do computador no processo de aprendizagem dos conteúdos curriculares em todos os
níveis e modalidades de educação. Para tanto, o professor da disciplina curricular deve
ter conhecimento e domínio sobre o potencial educacional do computador e ser capaz de
alternar adequadamente atividades tradicionais de ensino-aprendizagem e atividades que
usam o computador” para que dessa forma a apropriação do conhecimento transmitido
seja bem adquirida pelo aluno.
Os computadores são vistos como um importante recurso para auxiliar o
processo de ensino-aprendizagem, aprimorando os conceitos básicos já conhecidos
[Andrade e Lima 1996], e “possibilitando a busca e compreensão de novas idéias e
valores; quando utilizado como máquina de ensinar aborda os métodos de ensino
tradicional ou instrucionista” [Valente 2009]. Vale salientar, contudo, que mesmo o
aluno construindo seu conhecimento através de ambientes de aprendizagem
4
informatizados, a máquina não deve ser usada exclusivamente e isoladamente, pelo
contrário, como ferramenta não é capaz de trazer sozinha, avanços educacionais.
Paralelamente ao desenvolvimento do Construtivismo-Interacionista de Piaget
[Piaget 1972], sistemas computacionais como a Inteligência Artificial, e, em particular,
subáreas de atuação, como os Sistemas Especialistas [Giarratano e Riley 1998] e os
Sistemas Tutores Inteligentes [Wenger 1987] surgiram, permitindo novas formas para
buscar, construir e manter conhecimentos, porém mais adaptáveis às características
cognitivas dos alunos. Tais avanços fomentaram a criação e o desenvolvimento de
novas idéias que pudessem auxiliar todo o processo de ensino-aprendizagem,
vivenciado nas escolas afora.
Este presente trabalho, contudo, delimita-se ao estudo/avaliação das técnicas
atuais usadas em sala para avaliar o nível de aprendizado dos alunos. Enquanto pelo
lado discente, há recorrentes reclamações acerca das provas elaboradas (tediosas e
estáticas), pelo lado do corpo docente, há a necessidade de poder criar provas mais ricas
de detalhes, há um baixo custo de tempo e, sobretudo, que não acarrete sobrecargas de
trabalhos durante a correção, podendo prejudicar, sobretudo, a imparcialidade na
avaliação dos alunos. É neste contexto, que este trabalho apresenta o SEVAC, uma
ferramenta desenvolvida durante o trabalho de graduação, que incorpora características
da Inteligência Artificial, particularmente de Sistemas especialistas, e que serve como
uma proposta de avaliação rápida, dinâmica, e imparcial ao nível de assimilação dos
alunos.
Este trabalho está estruturado como se segue. Na seção 2, revisitaremos as
principais características dos Sistemas Especialistas. De forma a poder avaliar bem o
SEVAC, a seção 3 explica os métodos comuns utilizados nas redes de ensino como
formas de avaliação do aprendizado. Em seguida, a seção 4 apresenta o SINTA, o
framework básico através do qual o SEVAC, discutido na seção 5, foi desenvolvido. Por
fim, a seção 6 resume os principais resultados alcançados até então, e a seção 7 encerra
este trabalho com as conclusões e as perspectivas de trabalhos futuros.
2. Sistemas Especialistas
Os sistemas especialistas fazem parte da área de interesse da Inteligência Artificial (IA),
podendo ser considerado, inclusive, como um ramo da I.A., [Giarratano e Riley 1998],
como pode ser observado na figura 1.
5
Figura 1: Áreas da Inteligência Artificial [Giarratano & Riley. 1998]
Um sistema especialista é um programa de computador que usa o conhecimento
e inferências para resolver problemas muito difíceis e que requerem a expertise humana,
ou seja, habilidades intelectuais que uma pessoa tenha em uma determinada área do
conhecimento para solucioná-los [Harmon, Maus e Morrisey 1988] [Metaxiotics,
Askounis e Nikolopoulos 2006].
Figura 2: Arquitetura de um Sistema Especialista [Nikolopoulos 1997]
Os Sistemas Especialistas possuem uma arquitetura composta de (figura 2)
[Nikolopoulos 1997]: uma base de conhecimento responsável por estruturar todo o
conhecimento sobre o domínio da aplicação, um motor de inferência contendo os
algoritmos com regras que serão satisfeitas pelos fatos ou objetos implantados, um
módulo para aquisição do conhecimento o qual é constantemente refinado aumentando
o conhecimento adquirido do especialista, módulo de explanação responsável por
justificar os passos utilizados para chegar ao resultado final e uma interface, através da
qual o sistema especialista interage com o usuário.
Parafraseando [Mendes 1997], os resultados obtidos através da utilização da técnica
de sistema especialista são diferentes daqueles encontrados por meio de sistemas
tradicionais, por tratar-se de sistemas dotados de inteligência e conhecimento. Podemos
destacar alguns exemplos, tais como:
6
O sistema habilita tanto um especialista, bem como leigos a serem capazes de
tomar decisões mais coerentes;
Melhora a produtividade e desempenho, uma vez que o conhecimento está
armazenado em uma base de dados e pode ser usado de forma distribuída, tantas
vezes quantas necessárias forem, mantendo sempre a integridade nas decisões
tomadas; e
Podem servir de instrumento para coleta de informações sobre o desempenho
dos usuários, permitindo que o próprio sistema possa ser reformulado para
adequar-se cognitivamente a este grupo de usuários.
Este trabalho, portanto, explora mais largamente o terceiro item acima; a partir do
diagnóstico do nível de aprendizado dos alunos em uma área de conhecimento em
particular, é possível que o sistema evolua continuamente até atingir um nível adequado
de avaliação.
3. Métodos Tradicionais de Avaliação de Aprendizado
De acordo com [Kraemer 2005], “avaliar é atribuir um valor sobre a propriedade de um
processo para a aferição da qualidade do seu resultado está associada a medir
conhecimentos adquiridos pelos alunos”. A avaliação da aprendizagem é marcada pelo
desenvolvimento de testes padronizados para medir quais aptidões e habilidades foram
adquiridas pelos alunos. No âmbito escolar, tal informação é necessária para que o
professor encontre meios e estratégias que possam ajudar os alunos a absorver da
melhor forma possível os conteúdos estudados. Os tipos de avaliação são enquadrados
em três grandes tipos [Haydt 1997]:
A Avaliação Diagnóstica é aquela em que é verificada a posição do aluno face
às novas aprendizagens que lhe vão ser propostas e a aprendizagens anteriores
que servem de base àquelas, no sentido de identificar as dificuldades futuras e,
em certos casos, de resolver situações presentes.
A Avaliação Formativa permite constatar se os alunos estão, de fato, atingindo
os objetivos pretendidos, verificando a compatibilidade entre tais objetivos e os
resultados efetivamente alcançados durante o desenvolvimento das atividades
propostas.
A Avaliação Somativa busca traduzir o quão distante o avaliado ficou de atingir
uma meta estipulada inicialmente. Esse tipo de avaliação deve ser aplicado em
momentos específicos ao longo de um curso, como por exemplo, no final de um
período ou ano letivo.
Atualmente é notória a necessidade da inserção dos novos recursos tecnológicos na
área escolar, uma vez que a sociedade busca por profissionais qualificados, capazes de
enfrentar situações diversas, e o uso dessas novas tecnologias visam adequá-los a esse
meio fazendo com que alunos e professores façam parte dessas mudanças sociais,
culturais e profissionais que o terceiro milênio visa proporcionar.
Tais avanços tecnológicos, em destaque o computador, assim como os softwares
educativos, emergem como o artefato principal, oferecendo suporte na aprendizagem.
Pois é através dele que se expande o raciocínio e a criatividade dos alunos. É grande a
necessidade no uso dos recursos computacionais em salas e/ou laboratórios de
7
informática, sejam eles utilizados como instrumento para auxiliar na aprendizagem do
conteúdo, ou para avaliação da aprendizagem servindo como suporte ao professor.
4. SINTA O Sistema Especialista Expert SINTA [LIA 2010] é um software desenvolvido na
Universidade Federal do Ceará – UFC que utiliza linguagem Shell, um projeto da
UFC/UECE, criado pelo Grupo SINTA - Sistemas Inteligentes Aplicados, o qual utiliza
em sua criação técnicas de Inteligência Artificial.
Seu conjunto de instruções utiliza um modelo de representação do
conhecimento, através de regras de produção e probabilidades, objetivando reduzir o
trabalho de implantação na construção de sistemas especialistas. Adicionalmente, utiliza
uma máquina de inferência compartilhada, com suporte à construção automática de telas
e menus, modelando dessa forma uma base de conhecimento, ao mesmo passo que já
provê para o usuário a GUI – Guide User Interface.
Sendo assim, é bastante viável a utilização desse sistema para classificação de
problemas, uma vez que o usuário responde a uma seqüência de perguntas e o sistema
fica encarregado de fornecer respostas que sejam adequadas às solicitações feitas pelo
usuário. Este foi um dos motivos que levou à escolha desta ferramenta neste projeto de
pesquisa. Saliente-se também que é uma ferramenta grátis, diferente de outras
pesquisadas.
5. SEVAC
O SEVAC - Sistema Especialista Voltado a Avaliação do Conhecimento, visa priorizar
e analisar o nível de aquisição do conhecimento do aluno no domínio do Reino Animal,
uma vez que o computador deve ser utilizado também, na construção do conhecimento
do mesmo. A criação de um Sistema voltado ao domínio do Reino animal visa explorar
de forma contínua os conceitos vistos em sala de aula, como também fazer uma
avaliação do nível de aprendizagem do aluno relativo ao conteúdo estudado. No caso, o
domínio proposto para estruturação desse software visa explorar os animais vertebrados
onde o aluno deverá identificar tanto sua classificação, quanto as características, habitat
e reprodução dos mesmos.
A escolha por esse tipo de domínio para desenvolvimento do software está
diretamente relacionada à necessidade da professora de ciências da escola analisada,
uma vez que o conteúdo apresentado faz parte da grade curricular da disciplina para a
unidade vigente. Dessa forma, essa aplicação apresenta uma metodologia onde se
possibilita a utilização de Sistema Especialista na aula de ciências, promovendo assim
melhor assimilação e aprendizagem do conteúdo apresentado. Pretende-se com esta
proposta atingir os objetivos e validar o uso do Sistema Especialista SEVAC como um
recurso didático.
A arquitetura desenvolvida para o SEVAC é composta pela Base de
conhecimentos, a qual possui informações que um especialista utiliza. Ela é armazenada
em diversas estruturas de árvore binária, onde a interface do programa armazena
diretamente as regras encontradas nas estruturas. A Máquina de Inferência é a parte do
sistema especialista responsável pelas deduções sobre a base do conhecimento. Por fim,
o Banco de Dados Global tem a função de representar as evidências apontadas pelos
usuários do sistema especialista durante a consulta.
8
Figura 3: Exemplo de Tela do SEVAC
A consulta se desenvolve por meio de menus de múltipla (ou única) escolha, tal
como a figura 3. Até então foram criadas 26 perguntas com respostas.
Figura 4: Tela de Resultados
A tela de resultados (figura 04) exibe, ao final, os conhecimentos corretos
obtidos através das respostas assinaladas pelo usuário. Pode aparecer em uma consulta
tantas vezes quanto for o número de objetivos a serem alcançados. Sendo assim as
janelas são dividas e exibidas por classe (mamíferos, peixes, répteis, anfíbios e aves)
onde cada classe tem uma quantidade de perguntas e respostas, capazes de suprir a
necessidade de uma avaliação sobre a mesma, as questões assinaladas erroneamente são
descartadas pelo sistema apresentando assim apenas às opções corretas, dando
sequência à consulta das demais classes; o professor nesse caso soma os acertos e
atribui uma nota ao aluno.
6. Resultados
A fim de avaliar a ferramenta desenvolvida, foi selecionado um grupo de alunos e
professores que fizeram uso do sistema e, em seguida, responderam a um
miniquestionário ressaltando seus pontos positivos e negativos. Todos os alunos
entrevistados fazem parte da 6ª série do ciclo fundamental, de uma escola pública
municipal.
9
No intuito de comparar as visões do corpo docente e discente, foram criados, de
fato, dois questionários, um para cada grupo. O objetivo era investigar como cada grupo
via o sistema: pelo lado discente era importante investigar se a ferramenta era mais
atrativa e de simples uso; já pelo lado docente, era necessário investigar se ela poderia
ser utilizada como recurso pedagógico.
A aplicação da ferramenta junto ao corpo discente foi de grande valia, pois foi
possível avaliar através da mesma, a assimilação do conteúdo estudado durante a
unidade, de forma interativa e nova. Ficou constatado que tal ferramenta é de fato capaz
de dinamizar o processo avaliativo, deixando-o de ser monótono e cansativo tanto para
os alunos quanto para os professores. Este questionário foi realizado durante 1 semana.
Inicialmente, todos os alunos responderam uma prova tradicional. Em seguida, houve
um pequeno curso para explicar o uso do SEVAC para, só então, aplicar uma nova
prova por intermédio deste sistema.
Tabela 1: Resultado Parcial do Questionário Aplicado ao Corpo Discente
10
Tabela 2: Resultado Parcial do Questionário Aplicado ao Corpo Docente
Analisando os dados obtidos através do questionário aplicado ao corpo discente,
observou-se que a grande maioria dos alunos mostrou-se receptível ao sistema
desenvolvido. Foram questionados tanto os pontos fortes (interatividade, dinamismo e
praticidade) quanto os pontos fracos da ferramenta. O motivo de tal análise foi averiguar
principalmente o que falta ser adicionado à ferramenta para deixá-la mais completa. No
caso, os itens mais relatados foram: (i) manter um histórico das avaliações, (ii) projetar
uma interface com mais recursos visuais.
Ao analisar os dados encontrados na aplicação do questionário junto aos
professores, observou-se que a maioria dos docentes está disposta a utilizar o Sistema
Especialista como uma ferramenta de avaliação em suas aulas. Uma minoria mostrou
alguma reserva e resistência ao sistema e, conseqüentemente, às mudanças necessárias
quando se busca uma educação de qualidade.
7. Conclusão
Foi analisada através de questionários a carência de um sistema automatizado e digital,
sendo este capaz de tornar a avaliação do ensino elementar mais dinâmica. A partir das
análises feitas, foi proposta uma ferramenta capaz de suprir tal necessidade: a utilização
de um Sistema Especialista implantado com uma base de conhecimentos capaz de
avaliar os conteúdos estudados pelo usuário a partir de suas respostas.
Surge, então, a oportunidade de pensar na aplicação desse sistema como uma
forma avaliativa, compreendendo-o como um recurso didático de auxílio pedagógico.
Analisando se o conteúdo estudado foi assimilado de forma eficiente, o sistema
permitirá ao aluno tomar consciência do seu limite e das suas necessidades de avanço.
Considerando que a missão da escola é a auto-formação assistida, visando o pleno
desenvolvimento do educando, então a avaliação da aprendizagem, focalizada apenas
em conteúdos, não é suficiente. É necessário agregar à avaliação escolar, ao nível do
indivíduo, indicadores de avaliação, como este sistema especialista, que permite
acompanhar o domínio de competências e habilidades.
11
Saliente-se também que esta pesquisa foi enriquecida através das pesquisas de
campo e bibliográficas, entendendo melhor como funciona os Sistemas Especialistas e
aplicando-o como uma ferramenta de avaliação no âmbito escolar, trazendo-o como
instrumento construtivista na prática docente, podendo assim melhorar a qualidade do
ensino-aprendizagem entre professor e aluno.
O sistema especialista desenvolvido nesse trabalho é apenas um protótipo,
servindo como base para os trabalhos futuros, uma vez que se faz necessário um
aplicativo que disponibilize uma interface mais atrativa ao usuário, com figuras, help
on-line, que seja mais flexível e adequada à realidade dos alunos.
Referências
Andrade, P. F. and Lima, M. C. M. (1996). Programa nacional de informática educativa:
A utilização da informática na escola pública brasileira (1970-2004). Technical
report, MEC: Secretaria de Educacão à Distância.
Giarratano, J. C. and Riley, G. D. (1998). Expert Systems: Principles and Programming,
Third Edition. Course Technology, 3 edition.
Harmon, P., Maus, R., and Morrissey, W. (1988). Expert systems: tools and
applications. John Wiley & Sons, Inc., New York, NY, USA.
Haydt, R. (1997). Avaliacão do Processo Ensino Aprendizagem. São Paulo, SP, 6
edition.
Kraemer, M. E. P. (2005). A avaliação da aprendizagem como processo construtivo de
um novo fazer. http://www.gestiopolis.com/Canales4/rrhh/aprendizagem.htm.
LIA (2010). Expert synta: Manual do usuário. http://www.lia.ufc.br.
Mendes, R. D. (1997). Inteligência artificial: sistemas especialistas no gerenciamento da
informação. Ciência da Informação, 26.
Metaxiotis, K. S., Askounis, D., and Nikolopoulos, K. (2006). Identifying the
characteristics of successful expert systems: an empirical evaluation. IJITM, pages
21–36.
Nikolopoulos, C. (1997). Expert Systems: Introduction to First and Second Generation
and Hybrid Knowledge Based Systems. Marcel Dekker, Inc., New York, NY, USA,
1st edition.
Nilsson, N. J. (1998). Artificial Intelligence: A New Synthesis. Morgan Kaufmann
Publishers Inc., San Francisco, CA, USA, 1st edition.
Piaget, J. (1972). Desenvolvimento e aprendizagem.
Valente, J. A. (2009). Diferentes usos do computador.
http://www.educacaopublica.rj.gob.br/biblioteca/educacao/edu2007.ghtm.
Wenger, E. (1987). Artificial intelligence and tutoring systems: computational and
cognitive approaches to the communication of knowledge. Morgan Kaufmann
Publishers Inc., San Francisco, CA, USA.
12
Test-Module: uma ferramenta para gerenciamento de testes
de software integrada ao FireScrum
Audrey B. Vasconcelos, Iuri Santos Souza, Ivonei F. da Silva, Keldjan Alves
Centro de Informática – Universidade Federal de Pernambuco, (CIn/UFPE) Código
Postal 7851 – RECIFE – PE – Brasil
{abv,iss2,ifs3,kao}@cin.ufpe.br
Abstract. The increasing demand for software development with higher quality
increases its competitiveness and turns critical the creation of a software
testing process in parallel with the development’s, including projects that
adopt agile methodologies. In this context, the use of tools that support the
management of testing activities is essential to project success. This paper
presents an open source tool integrated to the FireScrum – a tool for projects
management using Scrum - that allows the management of these activities.
Resumo. Com o aumento da competitividade e complexidade no âmbito
dodesenvolvimento de software, e a conseqüente exigência por produtos com
qualidade assegurada, torna-se imprescindível a realização do processo de
testes de software em paralelo ao processo de desenvolvimento, inclusive em
projetos que adotam metodologias ágeis. Neste contexto, o uso de ferramentas
de suporte à gestão das atividades de testes é essencial para o sucesso dos
projetos. Este trabalho apresenta uma ferramenta de código aberto integrada
ao FireScrum – ferramenta para gestão de projetos ágeis utilizando Scrum – a
qual permite gerenciar as principais atividades de testes.
1. Introdução
É notável a crescente necessidade do uso de produtos de software pelas organizações,
sendo muitas vezes essencial à sua sobrevivência. O crescimento da indústria de
desenvolvimento de software acarretou um aumento significativo na competitividade
entre as organizações provedoras desse serviço. Os usuários de software, consumidores
desse serviço, estão cada vez mais exigentes quanto aos atributos de qualidade do
software, tais como: desempenho, confiabilidade e usabilidade.
Uma técnica de verificação e validação para certificar artefatos de software,
como testes de software, é uma abordagem que contribui para o aumento da qualidade
ao longo do processo de desenvolvimento de software [Sommerville 2007]. Todavia,
testar software não é uma tarefa trivial, pois envolve pessoas, processos, ferramentas,
aplicações, releases (conjunto de artefatos), grupos de scripts (roteiros de testes), dentre
outros. Além disso, o uso de planilhas ou documentos de textos não é eficaz para uma
gestão de testes produtiva e com baixo custo.
Na literatura da engenharia de software, observa-se que um projeto típico de
desenvolvimento de software tem 30% a 50% do custo total do projeto referente aos
testes [Myers 1979], [Pressman 2006], [Sommerville 2007] e este número ainda pode
ser mais alto para sistemas críticos [Harrold 2000].
13
Dessa forma, para que o custo da atividade de testes não seja um fator limitador
para a sua aplicação, usar uma ferramenta adequada para auxiliar na execução dessas
atividades otimiza a produtividade.
Neste contexto, ferramentas para gestão de testes em um âmbito de
desenvolvimento ágil de software devem auxiliar os desenvolvedores nas tarefas de
planejamento e execução dos testes [Beizer 1990]. A partir da execução dos ciclos de
testes é possível extrair métricas sobre os casos de testes que obtiveram sucesso ou falha
em sua execução. Outras características desejáveis para essas ferramentas de gestão de
testes consistem no relacionamento entre casos de testes e requisitos, além do
mapeamento e monitoramento dos defeitos detectados.
2. Uma Ferramenta para Gerenciamento de Testes
Esta seção apresenta a ferramenta Test-Module, desenvolvida com o objetivo de auxiliar
a especificação e gestão das atividades de teste em projetos de desenvolvimento de
software que adotam metodologias ágeis, em particular Scrum, integrada à ferramenta
FireScrum [FireScrum 2010]. A Test-Module permite criar casos de testes, associá-los
aos requisitos, organizá-los em bibliotecas, gerenciar planos para as execuções de testes
em projeto de software e gerenciar ciclos de testes que serão executados, além de captar
resultados das execuções, coletar métricas, registrar e monitorar defeitos.
2.1. Visão Geral da Test Module
A Test-Module possui um fluxo lógico de execução. Primeiramente, é necessário criar a
biblioteca de casos de teste (Test Suite), que consiste em um agrupamento de casos de
testes relacionados. A Figura 1 apresenta a tela de cadastro de bibliotecas, na qual se
observa como exemplo a biblioteca “Test Suite Cadastro Evento”.
A Figura 2 apresenta a tela de cadastro de casos de teste (Test Cases), na qual se
observa o caso de teste “Test Case – Validar Campos Cadastro Eventos”. Durante o
cadastro de casos de testes, a ferramenta permite associá-los a requisitos do projeto
(Backlog Item), além de cadastrar o tipo de execução do teste (manual, automático,
semi-automático), a prioridade, o cenário e os passos para execução do teste.
Após criar um conjunto de casos de testes, cria-se o plano de testes para o
projeto. A Figura 3 apresenta a tela de cadastro de planos de testes (Test Plan), na qual
se observa um plano de testes “Test Plan – Validação Cadastros Sistema de Eventos”.
Durante o cadastro do plano de testes, o usuário seleciona os casos de testes,
além de inserir o objetivo, a estratégia, a agenda e outros dados importantes para um
planejamento de testes.
14
Figura 1: Cadastro de bibliotecas de casos de teste (Test Suites)
Figura 2: Cadastro de casos de teste (Test Cases)
Na última etapa desse fluxo de gerenciamento de testes, o usuário define o ciclo de
execução dos testes. A Figura 4 apresenta a tela para a criação de ciclo de testes (Test
Cycle) para o plano de testes selecionado. O fluxo lógico apresentado acima segue a
seqüencia de agrupamento, criação e planejamento de testes, podendo ser realizado em
outra ordem, a critério do usuário. Além desse, ainda há o fluxo de execução, coleta de
resultados e coleta de métricas, também contemplados na ferramenta.
15
Figura 3: Cadastro de planos de teste (Test Plans)
2.2. Arquitetura da Teste-Module
A arquitetura geral da ferramenta Test-Module compreende o uso de Adoble Flex
[Adobe Flex 2010] como camada de apresentação (front-end) e JAVA [Java 2010] com
BlazeDS [BlazeDS 2010] como camada de processamento (back-end). A Figura 5
apresenta uma visão simplificada, porém completa, da arquitetura utilizada. A camada
de visão foi desenvolvida através de uma interface RIA (Rich Internet Applications)
[RIA 2010]. A camada de negócios empregou o uso de JAVA com o uso de padrões de
projeto. O acesso aos dados é realizado através do framework Hibernate [Hibernate
2010], o qual fornece a característica de independência do banco de dados. A seguir, são
explanados mais detalhes sobre os elementos presentes na arquitetura.
16
Figura 4: Cadastro de ciclos de execução (Test Cycles)
Figura 5: Arquitetura geral da Test-Module no FireScrum
2.2.1 Camada de Apresentação
A camada de apresentação fornece ao usuário experiência de uso otimizado dos
componentes e menus do sistema construídos com o Adobe Flex – um framework multi-
plataforma para desenvolvimento de aplicações RIA. Assim, a aplicação cliente
processa algumas informações do sistema no terminal cliente e o processamento
complexo fica a cargo do servidor da aplicação no Back-end.
2.2.2 Camada de Processamento
Esta camada utiliza diversas tecnologias para prover todas as funcionalidades desejadas.
A linguagem JAVA foi utilizada como plataforma de desenvolvimento e controle dos
objetos necessários à Test-Module. O BlazeDS foi utilizado para conectar os dados do
back-end com o front-end em Adobe Flex, e a persistência dos dados foi realizada
através do framework Hibernate. Mais detalhes sobre a ferramenta Test-Module
encontra-se na página do FireScrum [FireScrum 2010].
17
3. Trabalhos Relacionados
Geralmente as ferramentas comerciais para gestão de teste de software limitam-se a
oferecer suporte para as principais atividades de teste de software, como criação e
gestão de planos, casos e roteiros de testes, além do registro dos resultados e elaboração
de relatórios [Beizer 1990]. Um exemplo é o software HP TestDirector, produzido e
comercializado pela Hewlett-Packard [HP 2010], que adicionalmente tem suporte a
gerenciamento de defeitos. Cobrindo todas as etapas de testes definidas pelo processo
unificado da Rational, há o software fabricado e comercializado pela IBM Rational: o
Rational TestManager [Rational 2010]. Oferecendo, além das principais atividades de
teste, suporte ao desenvolvimento distribuído com gestão ágil de projetos de software, a
Borland produziu e comercializa a SilkCentral Test Manager [Borland 2010].
Dentre as ferramentas de código aberto com licença GPL destaca-se a QaTraq
[Traq Software 2010a], desenvolvido pela Traq Software, que atualmente também
oferece versão comercial [Traq Software 2010b]. A QaTraq oferece suporte para as
principais atividades de testes de software, além de modelos de relatórios para
resultados de execuções de teste. Outra ferramenta popular de gestão das atividades de
testes de software é a TestLink [TestLink 2010], que foi desenvolvida colaborativamente
por uma comunidade composta por engenheiros de testes. Esta ferramenta oferece
recursos adicionais, tais como priorização e atribuição de tarefas e suporte para
integração com ferramentas de gerenciamento de defeitos.
A FireScrum Test-Module destaca-se, em relação a essas ferramentas, por
centralizar em uma única aplicação as seguintes características: possui código aberto;
está integrada a uma ferramenta de gestão ágil de processo de software; organiza os
casos de testes em bibliotecas autônomas, facilitando o reuso destes; gestão dos ciclos
execução; interface rica na camada de apresentação web; possui integração direta com
ferramenta de gerenciamento de defeitos; e ainda possibilita o monitoramento dos
passos que não alcançarem os resultados esperados durante a execução de um caso de
teste.
4. Conclusões e Trabalhos Futuros
Neste trabalho foi apresentada uma ferramenta que auxilia os desenvolvedores de
software, em contexto ágil, a fazer gestão de testes do projeto de software. A ferramenta
Test-Module permite aos usuários definir planos e bibliotecas de testes, casos de testes,
ciclos de execução e associá-los aos requisitos. Além disso, a ferramenta permite a
integração com ferramenta de gerenciamento de defeitos rastreando a execução ao
defeito identificado.
Para trabalhos futuros, a ferramenta deverá evoluir para atender a necessidade de
relatórios mais elaborados, ampliar a coleta de métricas e permitir a integração com
outras ferramentas de gerenciamento de defeitos consolidadas na comunidade, a
exemplo do Bugzilla [Bugzilla 2010] e do Mantis [Mantis 2010]. Por ser um ferramenta
de código aberto, e originalmente idealizada dentro do projeto FireScrum, a Test-
Module também terá uma evolução associada ao progresso das necessidades oriundas da
comunidade de software livre que estiver interessada em gestão ágil de projetos e gestão
de testes.
18
5. Referências
Adobe Flex. (2010). http://www.adobe.com/products/flex/, Maio.
Beizer, B. (1990). Software Testing Techniques, John Wiley & Sons, Inc., New York,
NY, USA.
BlazeDS. (2010). http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/, Maio.
Borland. (2010). “SilkCentral Test Manager”, http://www.borland.com/us/products/silk/
silkcentral_test/index.html, Maio.
Bugzilla. (2010). http://www.bugzilla.org/, Maio.
FireScrum. (2010). “FireScrum ...the open source Scrum Tool”,
http://www.firescrum.com/, Maio.
GPL. (2010). http://www.gnu.org/licenses/gpl.html, Maio.
Harrold, M. J. (2000). "Testing: A Roadmap." Em International Conference on Software
Engineering.
Hibernate. (2010). http://www.hibernate.org/, Maio.
HP. (2010). “HP Quality Center”,
https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp
=1-11-127-24_4000_100__, Maio.
Java. (2010). http://www.java.com/en/download/faq/whatis_java.xml, Maio.
Mantis. (2010). http://www.mantisbt.org/, Maio.
Myers, G. J. (1979). Art of Software Testing, John Wiley & Sons, Inc.
Pressman, R. S. (2006). Engenharia de Software, McGraw Hill, 6ª Edição.
Rational. (2010). “Rational TestManager”, http://www-
01.ibm.com/software/awdtools/test/manager/, Maio.
RIA. (2010). http://en.wikipedia.org/wiki/Rich_Internet_application, Maio.
Sommerville, I. (2007). Engenharia de Software, Addison Wesley, 8ª Edição.
TestLink. (2010). http://testlink.sourceforge.net/docs/testLink.php, Maio.
Traq Software. (2010a). “QaTraq - Open Source”,
http://sourceforge.net/projects/qatraq/, Maio.
Traq Software. (2010b). “QaTraq Software”, http://www.testmanagement.com/, Maio.
19
LSVF: A heuristic search to reduce the backtracking calls
when solving Constraint Satisfaction Problems
Cleyton Rodrigues1, Eric Galvão1, Ryan Azevedo1
¹ Centro de Informática, Universidade Federal de Pernambuco, Av. Professor Luís
Freire 50740-540, Recife, Pernambuco, Brasil
{cmor, ergd, rra2}@cin.ufpe.br
Abstract. Along the years, many researches in the Artificial Intelligence (AI)
field seek for new algorithms to reduce the amount of memory and time
consumed for general searches in the family of constraint satisfaction
problems. Normally, these improvements are reached with the use of some
heuristics which either prune useless tree search branches or even “indicate”
the path to reach the solution (many times, the optimal solution) more easily.
Many heuristics were proposed in the literature, like Static/ Dynamic Highest
Degree heuristic (SHD/DHD), Most Constraint Variable (MCV), Least
Constraining Value (LCV), and while some can be used at the pre-processing
time, others just at running time. In this paper we propose a new pre-
processing search heuristic to reduce the amount of backtracking calls,
namely the Least Suggested Value First (LSVF). LSVF emerges as a practical
solution whenever the LCV can not distinguish how much a value is
constrained. We present a pedagogical example to introduce the heuristics,
realized through the general Constraint Logic Programming CHRv, as well as
the preliminary results.
Keywords: Constraint, Satisfaction Problem, Heuristics, Constraint Logic
Programming.
1 Introduction
Constraint Satisfaction Problems (CSP) remains as one of the most prominent AI
research fields. Having a wide range of applicability, such as planning, resource
allocation, traffic air routing, scheduling [Brailsford, Potts and Smith 1999], CSP has
been largely used either for toys or even for real large complex applications.
Furthermore, in general, CSP are NPcomplete and they are combinatorial in nature.
Amongst the various methods developed to handle this sort of problems, in this
paper, our focus concerns the search tree approach coupled with the backtracking
operation. In particular, we address some of the several heuristics used so far to reduce
(without guaranties) the amount of time need to find an solution, namely: Static/
Dynamic Highest Degree heuristic (SHD/DHD), Most Constraint Variable (MCV) and
Least Constraining Value (LCV) [Russel and Norvig 2003].
Some problems, however, like the ones common referred as instances of the
Four Color Map Theorem [Robertson et al 1997], present the same domain for each
entity, making the LCV heuristic impossible to decide the best value to the asserted
first.
20
For these cases, we propose a new pre-processing heuristic, namely Least
Constraint Value First (LCVF), which can bring significant gains by a simple domain
value sorting, respecting an order made by the following question “Which is the least
used value to be suggested now?”. Additionally, we enumerate some assumptions to
improve the ordering. Along the paper, we show some preliminary results with
remarkable reduce of backtracking calls.
This paper is organized as follows: Section 2 explains briefly the formal
definition of CSP and the most common heuristics used in the class of CSP; following,
Section 3 details what is CHRv and why we have chosen it to our examples; Section 4
introduces the LCVF heuristic with a pedagogical example, highlighting some
preliminary results, and finally, Section 5 presents the final remakes and the future
works.
2 CSP and Heuristics
Roughly speaking, CSP are problems defined by a set of variables X = {X1, X2,…, Xn},
where each one (Xi) ranges in a known domain (D), and a set of Constraints C = {C1,
C2,…, Cn} which restricts specifically one or a group of variables with the values they
can assume. A consistent complete solution corresponds to a full variable valuation,
which is further in accordance with the constraints imposed. Along the paper, we refer
to the variables as entities. Figure 1 depicts a pedagogical problem.
Figure 1 - A pedagogical Constraint Satisfaction Problem.
In the above figure, the entities are {X1, X2, X3, X4, X5, X6, X7} and each one can assume
one of the following value: D = {r,g,b}, referring to the colors, red, green, and blue,
respectively. The only constraint imposed restricts the neighboring places (that is, each
pair of nodes linked by an arc) to have different colors. As usual, this problem can be
reformulated into a search tree problem, where the branches represent all the possible
paths to a consistent solution. By definition, each branch not in accordance with C, must
be pruned. The backtracking algorithm, a special case of depth-first, is neither complete
nor optimal, in case of infinite branches [Vilain, Kautz and Beek 1989]. As we have not
established an optimal solution to the problem, our worries rely only upon the
completeness of the algorithm. However, we only take into account problems in which
search does not lead to infinite branches, and thus, the completeness of the problem is
ensured.
21
2.2 Search Heuristics
Basically, the backtracking search is used for this sort of problems. Roughly, in a depth-
first manner, a value from the domain is assigned, and whenever na inconsistency is
detected, the algorithm backtracks to choose another color (another resource). Although
simple in conception, the search results are far to be satisfactory. Further, this algorithm
lacks for not being intelligent, in the sense to re-compute partial valuations already
prove to be consistent. A blind search, like the backtracking, is improved in efficiency
employing some heuristics. Regarding CSP, general heuristics (that is, problem-
independent, opposite to domain-specific heuristics, as the ones in A* search [Dechter
and Pearl 1985]) methods speed up the search while removing some sources of random
choice, as:
Which next unassigned variable should be taken?
Which next value should be assigned?
The answer for the questions above arises by a variable and value ordering. The
most famous heuristics are highlighted below. Note that the two first methods concern
the variable choice, and the later refers to the value ordering:
Most Constrained Variable avoids useless computations when an assignment
will eventually lead the search to an inconsistent valuation. The idea is to try
first the variables more prone to error;
When the later method is useless, the Degree Heuristic serves as a tie-breaker,
once it calculates the degree (number of conflicts) of each entity;
The Least Constraining-Value, in turn, sorts decreasingly the values in a domain
respecting how much the value conflicts with the related entities (that is, the
values less shared are tried first).
As said before, we have restricted our scope of research to the class of problems
similar to the family of the four color theorem, where the domain is the same for each
variable. In this sense, the LCV heuristic is pointless since the “level” of constraining
for each value is the same. This drawback force us to search alternatives for sort the
values of CSP in similar situations, but also improving the efficiency. However, before
to present the solution, it is worth to explain why we have used the logic constraint
programming CHRv to carry out the tests.
3 CHRV
Constraint Handling Rules with Disjunction (CHRV) [Abdennadher and Schütz 1985] is
a general concurrent logic programming language, rule-based, which have been adapted
to a wide set of applications as: constraint satisfaction [Wolf 2005], abduction
[Gavanelli, Alberti and Lamma 1985], component-development engineering [Fages,
Rodrigues and Martinez 2008], and son on. It is designed for creation of constraint
solvers.
CHRV is a fully accepted logic programming language, since it subsumes the
main types of reasoning systems [Frühwirth 2008]: the production system, the term
rewriting system, besides Prolog rules. Additionally, the language is syntactically and
semantically well-defined [Abdennadher and Schütz 1985].
22
Concerning the syntax, a CHRv program is a set of rules defined as:
rule_name@ 𝐻𝑘 ⁄ 𝐻𝑟 ⇔ G | B
Rule_name is the non-compulsory name of the rule. The head is defined by the
predicates represented by Hk and Hr, with which an engine tries to match with the
constraints in the store. Further, G stands for the set of guard predicates, that is, a
condition imposed to be verified to fire any rule. Finally, B is the disjunctive body,
corresponding to a set of constraints added within the store, whenever the rule fires. The
logical conjunction and disjunction of predicates are syntactically expressed by the
symbols ‘,’ and ‘;’, respectively. Logically, the interpretation of the rule is as follows:
∀𝑉𝐺𝐻 ( 𝐺 → ((𝐻𝑘 ∧ 𝐻𝑟) ↔ (∃𝑉𝐵 𝐺𝐻⁄ 𝐵 ∧ 𝐻𝑘))) , 𝑤ℎ𝑒𝑟𝑒 𝑉𝐺𝐻 =
𝑣𝑎𝑟𝑠(𝐺) ∪ 𝑣𝑎𝑟𝑠(𝐻𝑘) ∪ 𝑣𝑎𝑟𝑠(𝐻𝑟), 𝑉𝐵 𝐺𝐻⁄ = 𝑣𝑎𝑟𝑠(𝐵) 𝑉𝐺𝐻⁄
(1)
For the sake of space, we ask the reader to check the bibliography for further
reference to the declarative semantics.
The problem depicted in figure 1 is represented by the logical conjunction of the
following rules:
𝑓@ 𝑓𝑎𝑐𝑡𝑠 ==> 𝑚, 𝑑(𝑥1, 𝐶1), 𝑑(𝑥7, 𝐶7), 𝑑(𝑥4, 𝐶4), 𝑑(𝑥3, 𝐶3), 𝑑(𝑥2, 𝐶2), 𝑑(𝑥5, 𝐶5), 𝑑(𝑥6, 𝐶6)
𝑑1@ 𝑑(𝑥1, 𝐶) ==> 𝐶 = 𝑟𝑒𝑑; 𝐶 = 𝑔𝑟𝑒𝑒𝑛; 𝐶 = 𝑏𝑙𝑢𝑒. 𝑑7@ 𝑑(𝑥7, 𝐶) ==> 𝐶 = 𝑟𝑒𝑑; 𝐶 = 𝑔𝑟𝑒𝑒𝑛; 𝐶 = 𝑏𝑙𝑢𝑒. 𝑑4@ 𝑑(𝑥4, 𝐶) ==> 𝐶 = 𝑟𝑒𝑑; 𝐶 = 𝑔𝑟𝑒𝑒𝑛; 𝐶 = 𝑏𝑙𝑢𝑒. 𝑑3@ 𝑑(𝑥3, 𝐶) ==> 𝐶 = 𝑟𝑒𝑑; 𝐶 = 𝑔𝑟𝑒𝑒𝑛; 𝐶 = 𝑏𝑙𝑢𝑒. 𝑑2@ 𝑑(𝑥2, 𝐶) ==> 𝐶 = 𝑟𝑒𝑑; 𝐶 = 𝑔𝑟𝑒𝑒𝑛; 𝐶 = 𝑏𝑙𝑢𝑒. 𝑑5@ 𝑑(𝑥5, 𝐶) ==> 𝐶 = 𝑟𝑒𝑑; 𝐶 = 𝑔𝑟𝑒𝑒𝑛; 𝐶 = 𝑏𝑙𝑢𝑒. 𝑑6@ 𝑑(𝑥6, 𝐶) ==> 𝐶 = 𝑟𝑒𝑑; 𝐶 = 𝑔𝑟𝑒𝑒𝑛; 𝐶 = 𝑏𝑙𝑢𝑒. 𝑚@ 𝑚 ≤> 𝑛(𝑥1, 𝑥2), 𝑛, 𝑛(𝑥1, 𝑥4), 𝑛(𝑥1, 𝑥7), 𝑛(𝑥2, 𝑥6), 𝑛(𝑥3, 𝑥7), 𝑛(𝑥4, 𝑥7), 𝑛(𝑥4, 𝑥5), 𝑛(𝑥5, 𝑥7), 𝑛(𝑥5, 𝑥6). 𝑛1@ 𝑛(𝑅𝑖, 𝑅𝑗), 𝑑(𝑅𝑖, 𝐶𝑖), 𝑑(𝑅𝑗, 𝐶𝐽) <=> 𝐶𝑖 = 𝐶𝑗 | 𝑓𝑎𝑖𝑙
The first rule ‘f’ introduces the constraints into the store, which is a set of
predicates with functor d and two arguments: the entity and a variable to store the
valuation of the entity. The seven following rules relate the entity with the respective
domain. Additionally, rule ‘m’ adds all the conceptual constraints, in the following
sense: n(Ri,Rj) means there is an arc linking Ri to Rj, thus, both entities could not share
the same color. Finally, the last rule is a sort of integrity constraint. It fires/ whenever
the constraints imposed is violated. Logically, it says that if two linked entities n(Ri,Rj)
shares the same color (condition ensured by the guard), then the engine needs to
backtrack to a new (consistent) valuation.
In the literature, many operational semantics was proposed, as [Abdennadher,
Frühwirth and Meuss 1999]. However, the ones most used in CHRv implementations are
based on the refined semantics [Duck at al 2004] (as the SWI-Prolog version 5.6.52
[SWI-Prolog 2010] used in the examples carried out along this paper). According the
refined operational semantics, when more than one rule is possible to fire, it takes into
23
account the order in which the rules were written in a program. Hence, as SHD heuristic
orders the entities to be valued in accordance with the level of constraining, this pre-
analysis help us to write the rules based on this sort. Thus, we could concentrate our
effort on the order of the values in the domain.
4 Least Suggested Value First – LSVF
The last section has introduces the rule-based constraint language, CHRv. Many aspects
of the operational semantics were left unexplained, and we encourage the reader to
check the references for additional information. However, some points need be
discussed to clarify the technique developed to improve the search, decreasing the
amount of backtracking calls. The first point, “which rule will trigger”, was discussed
before. The second important subject of discussion is the order of which the values are
taken from the domain in the search. We have already said that the logical disjunction is
denoted in the body of a CHRV rule, syntactically expressed by ‘;’. In order to maintain
consistency with the declarative semantics, CHRV engine tries all the alternatives since
the user tell the engine to do so. A disjunctive body is always evaluated from left-to-
right.
𝑑1@ 𝑑(𝑥1, 𝐶) ==> 𝐶 = 𝑟𝑒𝑑; 𝐶 = 𝑔𝑟𝑒𝑒𝑛; 𝐶 = 𝑏𝑙𝑢𝑒
Taking a rule from the example (as stated above), the engine tries the following
order of valuation for X1: (1) red, (2) green and, (3) blue. All the rules were created
respecting the same valuation order.
At first glance, we can note a relevant problem: if all the entities try first the
same color, and we know that these entities are related, a second evaluated entity always
needs to backtrack. Furthermore, since the entities shares the same domain, LCV is
pointless: each value has the same level of constraining. In order to make our idea clear,
we introduce a second example.
Figure 2 - An example regarding the order of the colors.
The Figure 2 shows the motivation problem for the new heuristics discussed. There are
3 entities {X1,X3,X7}, each one sharing the same domain. Let us respect the order of
valuation from left to right, and the order of variable chosen based on the numerical
order. Thus, the engine works as follows:
I. X1 is chosen, and the color red is taken;
II. X3 is chosen, and the color red is taken;
III. Inconsistency found: backtracking;
24
IV. X3 is chosen, and the color blue is taken;
V. X7 is chosen, and the color red is taken;
VI. Inconsistency found: backtracking;
VII. X7 is chosen, and the color blue is taken;
VIII. Inconsistency found: backtracking;
IX. X7 is chosen, and the green is taken.
Following, in the figure 3, the values order is changed to avoid, as much as possible,
the conflicts.
Figure 3 - The same example with domain reordered.
The engine now works as stated below:
I. X1 is chosen, and the color red is taken;
II. X3 is chosen, and the color blue is taken;
III. X7 is chosen, and the color green is taken.
The above modification prevented the backtracking calls, and the solution was
reached just with three steps, unlike the last example, which did the same, in 9 steps.
Evidently, in practice, we can not avoid all backtracking calls, but each reduction is
well-suited for the overall search time-consumption.
4.1 How the heuristic works?
Our propose is to enjoy the operational semantics addressed by the CHRV
implementation to sort the order in which the values from the domain is asserted,
decreasing the amount of backtracking calls. We believe this reduction can be well
appreciated in large and complex problems, where the time is a relevant factor.
The approach does not yield only the first color, but the entire domain. In our
case, the focus is in problems with three or four colors. In this context, the members of
the set of entities are categorized in accordance with the level of corresponding
restriction:
Soft Entities, that is, less constrained;
Middle Entities, that is, half constrained;
Hard Entities, that is, more constrained.
25
Hence, instead of proposing a solution of random sorting, we have taken the
following assumptions:
Usually, the entities less constrained are likely linked to others more
constrained, and, further, the entities less restricted are not connected to each
other (if this were the case, the entities owned other restrictions than those that
connect them, and they would be deemed more constrained). Thus, the domain
of these entities are sorted in the same manner;
Normally, hard entities are linked to middle ones, and thus the order of valuation
must be in conformance to this fact, example, if a hard entities domain is ordered
like (1)red, (2)green, (3)blue, the middle should be sorted like (1)blue, (2) green
(3)red, that is, the less suggested value first.
The first value assumed by the hard entities should be the last for the soft and
middle entities, since potentially both are linked to the former (this is why they
were classified as hard).
In order to exemplify this approach, we are going to show the reformulation of the
example used along this paper, illustrating gradually the gains obtained.
With respect the problem, we divided the set of entities as follows: (i) soft entities:
{X2,X3,X6}, (ii) middle entities: {X4,X5}, and (iii) hard entities {X1,X7}, with 6, 9 and 12
conflicts, respectively. What was considered for division was precisely the amount of
conflict in relation to other variables, done according the Static Highest Degree (SHD)
heuristic.
Table 1 summarizes the amount of inferences made and the number of backtracking
calls. The time is a relevant aspect only when evaluated to large problems.
Table 1 - First Results with the LSVF Heuristic
Sorting Level Inferences Backtracking Calls
I 4,897 8
II 4,694 7
III 4,415 6
IV 4,208 5
Not accidentally, the table was populated according to the level of values sorted
in respect to the assumptions raised earlier. Each level corresponds to a different CHRV
program. The Sorting Levels are the following:
Table 2 - Domain used for Entities
Level Soft Midle Hard
I red, green blue red, green blue red, green blue
II red, green blue blue, red, green red, green blue
III green, red blue blue, red, green red, green blue
IV green, blue, red blue, green, red red, green blue
In the Level I, the heuristic was not used. It is worth to keep their results in the
table to compare with the other levels, where the assumptions (which define the LSVF)
26
were gradually applied. Level II has changed the first suggested color of the Middle
entities with respect the hard. Following, the level III has changed the first color of
domain of soft entities with respect the others (middle and hard). There has been a
reduction of 25% of backtrack calls in accordance with the level I. Finally, the level IV
has used all assumptions talked, and both measures were visibly reduced. In this latter
case, the engine backtracks 5 times, three calls less than the original program. Note that
level IV obeys all the assumptions discussed, and the results obtained were remarkable.
5 Final Remakes and Future Work
The preliminary results obtained were very satisfactory. We might see that, as we
organize the values of the domain of the entities, gradually the search has been getting
more efficient with respect to the number of inferences necessary to reach a solution. A
small comparison between the level I and level IV, the program without the heuristic
and the program totally in accordance with LSVF, respectively, shows a significant
reduction in the amount of backtrackings and inferences realized.
It was important to mention that we are neither worried with optimal solutions
nor with all the solutions for the problem. We only focus on our overall effort to reach a
solution, and nothing else.
In order to validate completely the LSVF heuristics, our next step is to analyze
the approach with more complex problems. Additionally, our aim is to check the time
resource allocated for this kind of problem, since this was not possible due to the size of
the example discussed (all instances executed in less than one second).
Acknowledgments. We acknowledge REUNI for financial support and the Center of
Informatics of Federal University of Pernambuco – CIn/UFPE – Brazil for support in
this research.
References
Brailsford, S., Potts, C., Smith, B. (1999) Constraint satisfaction problems: Algorithms
and applications. European J. Operat. Res. 119, 557—581.
Russel, S., Norvig, P. (2003) Artificial Intelligence: A Modern Approach. New Jersey:
Prentice-Hall, 2nd edition, 143—144.
Robertson, N., Sanders, D. P., Seymour, P. D., Thomas, R. (1997) The four colour
theorem, J. Combin. Theory Ser. B., 2--44
Vilain, M., Kautz, H., Beek, P. (1989) Constraint propagation algorithms for temporal
reasoning: A revised report. In D. S. Weld and J. de Kleer, editors, Readings in
Qualitative Reasoning about Physical Systems, 373--381.
Dechter, R., Pearl, J. (1985) Generalized best-first search strategies and the optimality
of A*. J. ACM 32, 505—536.
Abdennadher, S., Schütz, H. (1985) CHRv: A Flexible Query Language, In Proceedings
of the Third International Conference on Flexible Query Answering Systems, pp.1--
14, May 13-15.
27
Wolf, A. (2005) Intelligent search strategies based on adaptive Constraint Handling
Rules. Theory Pract. Log. Program. 5, 4-5 (Jul. 2005), 567—594.
Gavanelli, M., Alberti, M., Lamma, E. (1985) Integrating Abduction and Constraint
Optimization in Constraint Handling Rules. In Proceeding of the 2008 Conference on
ECAI 2008: 18th European Conference on Artificial intelligence. M. Ghallab, C. D.
Spyropoulos, N. Fakotakis, and N. Avouris, Eds. Frontiers in Artificial Intelligence
and Applications, vol.178. IOS Press, Amsterdam, The Netherlands, 903—904.
Fages, F., Rodrigues, C. M. O., Martinez, T. (2008). Modular CHR with ask and tell. In
T. Schrijvers, F. Raiser, and T. Frühwirth, editors, CHR '08: Proc. 5th Workshop on
Constraint Handling Rules, Hagenberg, Austria, 95--110, 2008. RISC Report Series
08-10, University of Linz, Austria.
Frühwirth, T. (2008) Welcome to Constraint Handling Rules. In Constraint Handling
Rules: Current Research Topics, T. Schrijvers and T. Frühwirth, Eds. Lecture Notes
In Artificial Intelligence, vol. 5388. Springer-Verlag, Berlin, Heidelberg, 1—15.
Abdennadher, S., Frühwirth, T., Meuss, H. (1999) Confluence and Semantics of
Constraint Simplification Rules.Constraints 4, 2 (May. 1999), 133-165.
Duck, G. J., Stuckey, P. J., De la Banda, M. G., Holzbaur, C. (2004) The Refined
Operational Semantics of Constraint Handling Rules. In Proceedings of the 20th
International Conference on Logic Programming, B. Demoen and V. Lifschitz, Eds.,
90-104.
SWI-Prolog (2010) Reference Manual. Avaliable in http://
gollem.science.uva.nl/SWIProlog/Manual/ Contents.html. Last access in 15th March
2010.
28
O Lixo eletrônico no Brasil: Leis e Impactos Ambientais
Rodrigo Diego Gonçalves Ferreira1, Cleyton Mário de Oliveira Rodrigues2
1 FACOL – Faculdade Osman da Costa Lins, Vitória de Santo Antão – PE – Brasil
2 Centro de Informática – Universidade Federal de Pernambuco, (CIn/UFPE) Código
Postal 7851 – RECIFE – PE – Brasil
[email protected], [email protected]
Resumo: Uma preocupação mundial e com forte impacto social, econômico e,
principalmente, ecológico é o desenvolvimento sustentável. Muito se fala sobre
degradação do meio ambiente, contudo, pouco se faz para conter esse
problema que ameaça as futuras gerações do planeta. Este artigo informativo
denota, neste âmbito, uma visibilidade aos fatores que levaram o Brasil a ser
criticado por instituições não-governamentais de diversos lugares do mundo
por não ter uma legislação vigente sobre os aspectos do lixo eletrônico, bem
como a falta de regulamentação de práticas sustentáveis de recolhimento das
sucatas eletroeletrônicas pelos seus respectivos fabricantes. Também são
motivos de debate e questionamento as metas do poder executivo e legislativo
do país, com respeito às ações dos fabricantes de eletroeletrônicos.
1. Introdução
Com o grande avanço das tecnologias e das suas inovações em meio ao consumismo na
busca da comodidade e do conforto, a população sente a necessidade de sempre estar
atenta às novas tendências do mercado, ou seja, equipamentos mais modernos e
poderosos, com novas funções e serviços integrados. Com o aumento do poder de
compra do consumidor brasileiro, tornou-se comum a constante troca de seus
equipamentos tecnológicos, como: celulares, computadores, notebooks, TVs, geladeiras,
entre outros. Neste contexto, observa-se que a velocidade com que os consumidores
passam a procurar por novos produtos, é bem superior ao que acontecia há tempos atrás
[Planeta Sustentável 2008].
O ciclo de vida destes produtos é curto, aumentando conseqüentemente, o
descarte irregular de materiais eletrônicos no meio-ambiente. A poluição ambiental,
gerada pela poluição eletrônica através de seus metais pesados, ocasiona danos não só
ao meio ambiente, mas também à saúde humana. Grande parte desse lixo tóxico
proveniente das sucatas eletrônicas é jogado em terrenos baldios, queimado a céu aberto
ou recolhido pela coleta de lixo fornecida pelos governos municipais, mas sem que
exista nenhum tipo de seleção ou tratamento destes materiais tóxicos.
Instituições mundiais voltadas à preservação do meio ambiente apontaram, nos
últimos meses, o Brasil como um dos maiores produtores de lixo eletrônico entre os
países emergentes: Brasil, México, Índia e China. O país foi apontado por abandonar
aproximadamente 96,8 mil toneladas de componentes utilizados em computadores e
mais de 35 milhões de toneladas de sucatas eletrônicas por ano, uma produção de lixo
maior que a média dos outros países [Ecodebate 2010]. Mesmo com a grande produção
de lixo eletrônico, não houve nenhuma mudança legislativa com a formulação de
normas nacionais, impossibilitando uma fiscalização adequada de combate ao
desperdício irracional de eletroeletrônicos.
29
Este artigo toma o aspecto técnico-ambiental, objetivando a conscientização dos
consumidores e mostrando o posicionamento político, legislativo, de Organizações Não
Governamentais (ONGs) e de fabricantes que atuam no mercado Brasileiro.
2. Brasil: atual situação e legislação
É chamado de lixo eletrônico, também conhecido como e-lixo ou sucata eletrônica, todo
material que é descartado e compõe os eletroeletrônicos, como resíduos sólidos,
componentes tóxicos e metais pesados. O Greenpeace [GREENPEACE] e a
Organização das Nações Unidas (ONU) [ONU] consideram o Brasil como o país
emergente que gera maior volume de lixo eletrônico, além de maior produtor de e-lixo
per capita por ano. Também, o país tem o maior número de toneladas de geladeiras
abandonadas a cada ano por pessoa, e é um dos líderes em descartar celulares, TVs e
impressoras, entre os países emergentes. Na composição de um computador, por
exemplo, são utilizados diversos produtos considerados tóxicos ao ser humano, como:
sílica, plástico, ferro, alumínio, cobre e chumbo. A tabela 1 relaciona alguns destes
metais com os problemas que podem causar à saúde das pessoas.
Tabela 1 - Danos causados por metais pesados
METAL PESADO DANOS À SAÚDE
Chumbo Atinge o sistema nervoso, a medula óssea e os rins, gerando
lesão renal e cerebral e fraqueza muscular.
Mercúrio Concentra-se em diversas partes do corpo como pele, cabelo,
glândulas sudoríparas e salivares, tireóide, sistema digestivo,
pulmões, pâncreas, fígado, rins, aparelho reprodutivo e
cérebro, provocando inúmeros problemas de saúde.
(Intoxicação do sistema nervoso central).
Manganês Causa problemas respiratórios e efeitos neurotóxicos.
Sílica Causa problemas respiratorios, provocando o endurecimento
dos pulmões, podendo assim ser fatal.
Alumínio A ingestão pode causar: demência, danos ao sistema nervoso
central, perda de memória e dores musculares.
Com as políticas de incentivo e marketing pela compra de computadores por
todos os segmentos da sociedade, o computador está cada vez mais barato e conseguir
um destino ecológico e socialmente correto para a máquina antiga torna-se complicado.
Seu destino acaba sendo, dessa forma, o lixo comum. As autoridades brasileiras devem
criar e fazer valer o cumprimento das leis e regimentos estaduais de combate a
degradação da natureza causada pelo e-lixo. Cabe também aos órgãos ligados ao meio
ambiente a fiscalização e autuação aos fabricantes que descumprirem o normativo
nacional. Existe em tramitação, a Política Nacional de Resíduos Sólidos (PNRS) [PNRS
2010]. Aprovado depois de 19 anos pala Câmara dos Deputados, o projeto ainda passará
pelo senado e, por último, pelo executivo. Os eletroeletrônicos estão inseridos no artigo
33 do plano, sendo divididos em três categorias: eletrodomésticos, bens de informática e
eletrônicos em geral.
30
Constam no PNRS penalidades previstas na Lei 13576, que trata de crimes
ambientais. As leis que atualmente regem as ações no Plano Nacional Ambiental
Brasileiro não são específicas aos resíduos eletrônicos, e sim, aos resíduos sólidos de
forma geral. Alguns estados, como Minas Gerais, Paraná, Rio de Janeiro, Piauí, Espírito
Santo e Pernambuco contam com uma legislação direcionada apenas aos resíduos
sólidos (de uma forma geral), incluindo a poluição por metais pesados, entretanto, não
existe citação sobre o recolhimento de produtos eletrônicos pelos respectivos
fabricantes, exceto quando há punições.
No estado de São Paulo existe a lei 13.576/09, da autoria do Deputado Estadual
Paulo Alexandre Barbosa (PSDB), a qual instituiu que os fabricantes de eletrônicos são
responsáveis pela reciclagem, gerenciamento e destino final do lixo tecnológico. Essa é
a única lei específica sobre elixo. O Brasil ainda é, de uma forma geral, carente de um
normativo relacionado à poluição eletrônica. A lei 3.968 de 31 de agosto de 1981, que
estabelece a PNMA [PNMA], seus fins e mecanismos de formulação e aplicação,
constituiu o Sistema Nacional do Meio Ambiente (SISNAMA) [SISNAMA] e instituiu
o Cadastro de Defesa Ambiental. A PNMA tem como principais objetivos a melhoria e
preservação da qualidade ambiental, defendendo o desenvolvimento socioeconômico do
país, bem como a segurança e a vida humana.
Como abordado ao longo do artigo, o Brasil tem um normativo regido por
órgãos estaduais e nacionais de preservação do meio ambiente, baseado numa legislação
interna a cada departamento ambiental. Nestes últimos anos, existe uma preocupação
parlamentar nacional para formulação de um plano de reciclagem e reaproveitamento de
resíduos eletroeletrônicos, onde torna o fabrincante responsável pelo recolhimento dos
produtos gerados em suas unidades fabris, incluídos nas leis de resíduos sólidos.
3. Legislação internacional do e-lixo
A União Européia (UE) possui a diretiva ROSH [Lei Lixo Eletrônico] que restringe em
seis substâncias tóxicas a produção de eletroeletrônicos, onde responsabiliza também os
produtores pela redução destas substâncias: chumbo, mercúrio, cádmio, crómio
hexavalente, polibromatos (PBB e PBDE). Esta legislação foi implantada e adaptada
pela China em 2006, três anos após a implantação da UE. A Eletronic Equipament
Collection dos Estados Unidos (EUA) impõe as responsabilidades da reciclagem e
reaproveitamento ao fabricante. A legislação foi criada em 2008 e estima que até 2015
aproximadamente 25% de todo lixo eletrônico produzido pelo país será reaproveitado,
além de deixar claro que os fabricantes devem submeter um plano de tratamento às
prefeituras, tornando-se proibido descatar lixo eletrônico junto ao lixo comum, isto é,
deve-se destiná-los a aterros sanitários.
No Canadá e nos EUA, além da obrigação do recolhimento de produtos ser dos
fabricantes, a legislação ajudou a definir as reponsabilidades do consumidor (exemplo,
mandar o produto para reciclagem), do fabricante (criação da rede coletora) e do estado
(mantenedora da reciclagem e dos recursos utilizados). No Japão, o governo é o
responsável pelo processo de coleta e logística reversa, os fabricantes são responsáveis
pela reciclagem e neutralização adequada dos componentes tóxicos (a legislação Home
Appliance Recycling Law). Com base nessa legislação, muitas empresas se adaptaram as
regras estabelecidas internacionalmente, mas outras não.
31
4. Como as grandes empresas comportam-se hoje em dia?
A maioria dos fabricantes de eletroeletrônicos, eletrodomésticos e empresas de
tecnologia não anexam nos seus produtos informações suficientes sobre o recolhimento
dos equipamentos descartados, como: Apple, CCE, Le novo, LG, Positivo e Samsung.
Mais grave ainda, empresas como Acer, Dell, Philips, Siemens, TIM e Semp Toshiba
não dispõem de nenhuma informação sobre a devolução de seus produtos.
As seis primeiras empresas citadas, nos dias de hoje, procuram realizar ações
sustentáveis na fabricação de seus produtos, como exemplo, os equipamentos levam em
sua composição matériasprimas recicladas, como o plástico. Além disso, em seus
componentes, os metais pesados são utilizados em quantidades menores, assim as
fabricantes integram um rank no programa do Guia de Eletrônicos Verdes do
Greenpeace [Baixaki 2010].
As grandes empresas mundiais estão seguindo um padrão de reutilização e
mudança de matéria-prima na fabricação de produtos eletroeletrônicos integrando assim
a corrente da TI VERDE (Tecnologia da Informação Verde). Empresas como Samsung,
Toshiba, Nokia, Sony, Lenovo e Dell estudam políticas internas de reciclagem com a
participação e adesão de ações sugeridas pelas instituições voltadas à defesa e à
preservação do meio ambiente, como o Greenpeace. A instituição mostra para o mundo
um rank de empresas que realizam atividades em favor do meio ambiente, o chamado
Guia de Eletrônicos Verdes. O guia é publicado trimestralmente, como forma de fazer
com que a indústria de eletrônicos encare o problema do lixo que produz. A intenção é
fazer que os fabricantes parem de usar produtos tóxicos em seus produtos.
5. Reciclagem: Um caminho aberto a novas oportunidades
O setor de reciclagem de Resíduos de Aparelhos Elétricos e Eletrônicos, ou
simplesmente RAEE, é um nicho do mercado cheio de potencial e que já começou a ser
trabalhado. O ramo ganha espaço à medida que aumenta o consumo de eletroeletrônicos
em geral. Desmontar, triturar e transformar diversos equipamentos é o que as empresas
de remanufatura fazem, e ao mesmo tempo evitam a contaminação do ambiente por
materiais tóxicos. Com o crescimento do mercado brasileiro, existem empresas que
encontraram a partir das sucatas uma oportunidade de oferecer reciclagem para grandes
fabricantes. Uma delas é a Oxil (lixo ao contrário), de Paulínia no Estado de São Paulo
[OXIL].
A companhia tem nove grandes clientes, dos quais não revela os nomes por
motivos contratuais, e processa 2 mil toneladas de produtos por ano. A empresa
conseguiu reciclar 99,7% do material enviado. O ato de transformar equipamentos fora
de uso em matéria-prima é chamado de “manufatura reversa”. Na Universidade de São
Paulo (USP) foi criado, em 2009, o primeiro centro de descarte e reciclagem de
equipamentos eletrônicos, criação pioneira de um órgão público no Brasil. O projeto
visa recuperar computadores, notebooks e equipamentos de telefonia móvel e fixa. Os
equipamentos podem ter dois destinos: são encaminhados para reciclagem ou destinados
a ONGs e projetos sociais, caso possam ainda ser usados. O projeto cria a oportunidade
de reutilização gerando a inclusão digital em comunidades carentes administradas por
instituições não governamentais.
As grandes empresas também garantem a reutilização de seus produtos, como a
IBM que encontrou uma saída criativa para o descarte de seus monitores. Até o ano
32
2000, o destino dos resíduos descartados era o aterro. A partir daquele ano, o processo
foi interrompido e os monitores foram armazenados até que uma solução ambiental
fosse encontrada. Em 2008, 180 toneladas de monitores foram para a reciclagem. Um
parceiro da IBM coletou o vidro e o transformou em bolinhas de gude, que hoje estão
por aí, no mercado, à venda. Quanto à Dell, seus equipamentos usados podem ter dois
destinos, ou são mandados para a reciclagem ou são recondicionados e doados para
projetos sociais (mais de 46 milhões de toneladas de equipamentos). No Brasil, algumas
das empresas acima citadas não desenvolvem estas atividades de
recuperação/reciclagem, por ausência de ações repressivas por parte do cumprimento de
leis e normas dos órgãos ambientais, levando em consideração que nosso país ainda não
tem uma legislação específica sobre o e-lixo.
6. Concluindo
O lixo eletrônico aumenta a cada dia, pois com o constante crescimento das inovações
tecnológicas o consumidor segue a mudança de equipamentos com a mesma frequência.
O Brasil ainda hoje é alvo de críticas por parte das instituições internacionais, pela
grande quantidade de sucata gerada e pela carência de políticas ambientais relacionadas
ao assunto. Neste ano de 2010, depois de um 2009 de críticas, a Câmara dos Deputados
resolveu aprovar um projeto de lei engavetado há 19 anos.
Além das ações de grandes fabricantes e do surgimento de empresas voltadas
para reciclagem das sucatas eletrônicas, em algumas cidades, projetos de recuperação de
sucatas tecnológicas são desenvolvidos por grupos de amigos, que recolhem
equipamentos computacionais descartados para serem recuperados e, posteriormente,
destinados a crianças carentes e entidades sociais, como forma de inclusão digital. O
problema do lixo eletrônico no Brasil será resolvido (amenizado, pelo menos) quando
houver efetivamente as devidas leis criadas, e os órgãos de defesa possam fiscalizar e
punir os fabricantes que infringirem as resoluções contidas no normativo nacional. Por
fim, é importante destacar que cada consumidor pode atuar como um elemento ativo
nesse processo, seja conscientizando os menos informados, seja procurando empresas
que preguem a sustentabilidade, ou até atuando criativamente na transformação do e-
lixo em algo novo, que possa ser usado por aqueles menos afortunados.
Recursos
Planeta Sustentável (2008) Consumismo Gera Lixo -
http://planetasustentavel.abril.com.br/noticia/atitude/conteudo_278998.shtml
Ecodebate (2010) Estudo mostra Brasil no topo do ranking de produção per capita de
lixo eletrônico vindo de computadores -
http://www.ecodebate.com.br/2010/03/25/estudo-mostra-brasil-no-topo-do-
rankingde-producao-per-capita-de-lixo-eletronico-vindo-de-computadores/
GREENPEACE BRASIL - http://www.greenpeace.org/brasil/
ONU – Organização das Nações Unidas - http://www.onu-brasil.org.br/
PNRS (2010) http://www.revistasustentabilidade.com.br/documentos-de-
referencia/pnrs-textoaprovado-na-camara-10-03-2010
PNMA - http://www.semarh.al.gov.br/programas/programa-nacional-do-meio-ambiente
33
SISNAMA - www.mma.gov.br/port/conama/estr1.cfm
Lei Lixo Eletrônico. LEI ROSH DA UNIÃO EUROPÉIA -
http://www.lixoeletronico.org/system/files/UE_ROHS_PT.pdf
Baixaki (2010) Ranking de Empresas Verdes - http://www.baixaki.com.br/info/3634-
ranking-de-empresasverdes.htm
OXIL MANUFATURA REVERSA - http://oxil.com.br/
Revista Sustentabilidade (2010) LEI BRASILEIRA DO E-LIXO -
http://www.revistasustentabilidade.com.br/documentos-dereferencia/pnrs-texto-
aprovado-na-camara-10-03-2010
34
An Experimental Research on the Relationships between
Preferences for TechnicalActivities and Behavioural Profile in
Software Development
Fabio Q. B. da Silva, Ana Cristina F. César
Centro de Informática – UFPE Recife, Brasil
{fabio, acfc}@cin.ufpe.br
Resumo - Este artigo descreve uma pesquisa de campo conduzida a fim de identificar
as correlações entre preferência por atividades técnicas e o perfil de comportamento no
trabalho em equipe de engenheiros de software. O universo da pesquisa foram
estudantes de graduação em engenharia de software do Estado de Pernambuco. As
informações sobre preferências e comportamento, obtidas em uma pesquisa de campo
envolvendo 100 estudantes, receberam tratamento estatístico através do cálculo do
coeficiente de correlação por posto de Spearman. Os resultados contribuem para um
melhor entendimento da gestão de equipes de desenvolvimento de software.
Abstract - This article describes a survey conducted to identify correlations between
preferences for technical activities and behavioral profiles for work in a team of
software engineers. The context of the research was software engineering
undergraduate students at State University of Pernambuco, Brazil. The information
about preferences and behavior obtained in a field study involving 100 students
received a statistical treatment using the Spearman rank correlation coefficient. The
results contributed to a better understanding of the construction of effective software
development teams
Perfis de comportamento; perfis de equipe; engenharia de sofware.
1. INTRODUÇÃO
O gerenciamento de pessoas é uma atividade reconhecidamente complexa. Para
entender esta complexidade, o ponto de partida é a compreensão, já consolidada nos
estudos da psicologia humana, de que as pessoas são diferentes em diversos aspectos.
Por exemplo, na solução de problemas, na forma de obtenção de informação, na tomada
de decisão, na relação como o ambiente e as outras pessoas, no comportamento durante
o trabalho em equipe, entre vários outros. Estas diferenças influenciam motivação,
preferência por atividades profissionais, efetividade no trabalho em equipe e, em última
instância, desempenho individual e coletivo. Além disso, as diversas atividades técnicas
e gerenciais do desenvolvimento de software exigem diferentes níveis qualitativos e
quantitativos de processos mentais e sociais, tais como, criatividade, atenção a detalhes,
comunicabilidade, persistência, flexibilidade, liderança, etc.
A gestão de pessoas é especialmente importante para a indústria de software, por
três motivos: (1) o desenvolvimento de software é uma atividade mental e, portanto,
intensiva em pessoas; (2) é, quase sempre, desenvolvido em equipe; e (3) é composto de
diversas atividades técnicas cujo agrupamento define papéis funcionais distintos em
uma equipe de desenvolvimento. Estas características, de forma isolada e nas suas
interações, aumentam a complexidade e a importância da gestão de pessoas no
desenvolvimento de software quando comparada com setores menos intensivos em
atividades mentais.
35
Nos últimos anos, diversas pesquisas têm buscado aplicar teorias da psicologia à
engenharia de software com o objetivo de obter teorias, técnicas e ferramentas
específicas para projetos de software, em dois aspectos complementares: na alocação de
pessoas a papéis funcionais (técnicos e gerenciais) do desenvolvimento de software; e
na composição e gerenciamento das equipes de desenvolvimento.
Entre estas pesquisas, de forma geral, podem ser distinguidas duas vertentes:
Trabalhos que têm como foco o indivíduo, sua personalidade e seus traços de
omportamento, e como estes elementos influenciam o trabalho individual no
desenvolvimento de software [Acuna, Juristo e Moreno 2006],[Capretz 2002],[
Capretz 2003],[Cunha 2007].
E trabalhos que colocam o indivíduo no contexto do trabalho em equipe,
analisando as formas de interação e os papéis em equipe, e como estes elementos
influenciam o trabalho em equipe em software [Gorlae Lam 2004],[Karn e
Cowling 2006].
Certamente as duas vertentes são importantes e complementares, uma vez que cada
indivíduo isoladamente contribui para o trabalho em equipe e a equipe, por sua vez, cria
um contexto social e organizacional que pode moldar ou ajustar o comportamento
individual. Este trabalho busca contribuir com a interação destas duas vertentes. O
objetivo é estudar as relações entre a preferência individual por atividades técnicas e
gerenciais do desenvolvimento de software (foco no indivíduo) e os perfis de
comportamento individual no trabalho em equipe (foco no trabalho em equipe). E para
contemplar este objetivo, este artigo é guiado pelas seguintes perguntas de pesquisa:
Existem atividades técnicas ou gerenciais no desenvolvimento de software
preferidas pelos engenheiros de software?
Existem perfis de comportamento no trabalho em equipe com maior tendência
de ocorrência entre os engenheiros de software?
Finalmente, existem correlações entre a preferência por atividades técnicas e os
perfis de comportamento dentre os engenheiros de software?
Para responder a estas perguntas foi realizada uma pesquisa de campo (survey), de
natureza quantitativa, cuja unidade experimental foi o engenheiro de software, estudante
de cursos de graduação em engenharia de software. O universo da pesquisa é formado
341 estudantes do Centro de Informática da UFPE e foram coletados dados de uma
amostra de 100 estudantes (29% do universo) entre os meses de setembro de 2008 e março
de 2009.
O instrumento de coleta de informações de campo foi um questionário estruturado
com perguntas fechadas composto de três partes: (I) informações de controle; (II)
preferência por atividades; e (III) perfil de comportamento no trabalho em equipe. A
parte II foi desenvolvida neste trabalho tomando por base as atividades técnicas e
gerenciais descritas na norma ISO/IEC 12207 e no Rational Unified Process (RUP).
Para identificar os perfis de comportamento no trabalho em equipe foi utilizada a Teoria
de Papéis em Time de Belbin (Belbin’s Team Role Theory) apresentada em (BELBIN,
1981) e, desta forma, a parte III do questionário é o instrumento associado à esta teoria,
denominado Team Role Self-Perception Inventory (TRSPI), que é fornecido em [Belbin
1981].
36
Este artigo está organizado da seguinte forma: na Seção 2 é apresentado o referencial
teórico do trabalho composto pela Teoria Teoria de Papéis em Time de Belbin (Belbin’s
Tearm Role Theory) e pela descrição das atividades técnicas e gerenciais segundo a
norma ISO/IEC 12207 e o RUP. Na Seção 3, é apresentada a metodologia e os métodos
experimentais utilizados no trabalho. Na Seção 4, são apresentados e analisados os
resultados da pesquisa. Finalmente, na Seção 5, são apresentadas conclusões e direções
para pesquisas futuras.
2. REFERENCIAL TEÓRICO
Para responder às perguntas da pesquisa, é necessário selecionar uma teoria de papéis e
definir claramente as atividades técnicas e gerencias do desenvolvimento de software,
para então estudar as suas correlações. A literatura sobre teoria de papéis é ampla,
conforme apresentado em [Aritzeta, Swailes e Senior 2007], e uma avaliação teórica do
assunto está fora do escopo deste artigo. Neste trabalho, a teoria de papéis utilizada é a
Teoria de Papéis em Time de Meredith Belbin [Belbin 1981], escolhida por um
conjunto de razões:
A teoria é focada em papéis relacionados ao trabalho em equipe, atendendo a um requisito deste trabalho que é estudar o comportamento individual no trabalho em equipes de desenvolvimento de software.
A teoria e os instrumentos de avaliação (questionários e escalas de medição) passaram por um extenso trabalho de crítica teórica e testes experimentais, com a conclusão de que a teoria é consistente e os instrumentos são válidos conforme resumido em [Aritzeta, Swailes e Senior 2007], [Senior 1998].
A teoria e os instrumentos de avaliação não são oficialmente aceita pelos
conselhos de psicologia no rasil (assim como outros testes muito utilizados na prática, como o MBTI). Porém, os riscos da teoria não ser adequada ao contexto brasileiro é baixa uma vez que foi construída a partir de extensa pesquisa de campo envolvendo indivíduos de diversos países e culturas distintas, procurando eliminar um possível viés cultural.
Existem diversos trabalhos na área de engenharia de software que utilizam a
Teoria de Belbin, permitindo que os resultados deste trabalho possam ser
comparados, entre eles [Stevens 1998], [Henry e Stevens 1999],[Schoenhoff
2001],[Rajendran 2005],[França e Da Silva 2007],[Ferreira e Da Silva 2007].
Finalmente, apesar da Teoria de Belbin ter sido originalmente construída para
times de gerentes, existem estudos que demonstram sua utilização consistente
em times de quaisquer naturezas [Fisher, Hunter e Macrosson 2002] p. 15.
Para a identificação e descrição das atividades do desenvolvimento de software foi
utilizado como fundamento a norma ISO/IEC 12207 e o RUP. A primeira por ser uma
norma formalmente estabelecida e que possui ampla utilização prática. O segundo por
ser um modelo de processo largamente utilizado na prática e apresentar uma definição
precisa das atividades do desenvolvimento.
2.1 Teoria de Papéis de Time de Belbin
Durante os anos 70, Meredith Belbin e sua equipe de pesquisadores do Henley
Management College, na Inglaterra, estudaram vários comportamentos de gerentes de
várias nacionalidades, durante um período de nove anos. Neste estudo, os gerentes
37
foram submetidos a testes psicométricos para avaliar traços de personalidades, modos
de interação, preferências intelectuais e estilos de comportamento. Os testes usados
foram o 16 Personality Factors (16PF), o Watson-Glaser Critical Thinking Appraisal
(CTA) e o Personal Preference Questionnaire (PPQ). A partir deles, os gerentes foram
alocados em equipes de diversas composições, com o apoio de um grupo de
observadores que registravam todas as ações [Belbin 1981].
A partir dos resultados dos testes e da observação do comportamento dos indivíduos
em situações de trabalho em equipe, vários grupos de comportamento foram
identificados e consistentemente relacionados ao sucesso ou fracasso das equipes. Os
padrões de comportamento identificados foram classificados e nomeados,
originalmente, em oito tipos de papéis em times (team roles): Company Worker, Team
Worker, Monitor Evaluator, Chairman, Plant, Shaper, Resource Investigator e
Completer Finisher. Neste trabalho serão mantidos os nomes originais em inglês dos
papéis uma vez que uma tradução livre poderia causar distorções de significado e
prejudicar o entendimento dos resultados.
Na Teoria de Belbin, um papel em time é definido como “uma tendência para se
comportar, contribuir e se relacionar com outros de uma forma particular em um
trabalho em equipe”. A Teoria de Papéis em Time advoga que estes papéis quando
alocados de forma balanceada em uma mesma equipe melhoram as chances de sucesso
do trabalho coletivo uma vez que aumentam a coesão e sintonia entre os membros,
criando equilíbrio entre as forças e fraquezas inerentes a cada papel individual.
Belbin [Belbin 1993] apresenta uma extensão da Teoria de Papéis com a adição do
papel de Specialist. Além disso, foram alterados os nomes de dois papéis de time para
melhor representar seu significado: Chairman passou a ser chamado Co-ordinator e
Company Worker passou a Implementer. A utilização do papel Specialist possui críticas
na literatura por não possuir poder discriminatório suficiente [Aritzeta, Swailes e Senior
2007], [Senior 1998]. Por esta razão, este trabalho considera os oito papéis originais da
Teoria, mas com os novos nomes Co-ordinator e Implementer.
A Tabela 1 explica de forma resumida cada perfil de comportamento de Belbin,
especificando suas características, pontos fortes e fracos.
A Teoria de Papéis de Belbin é complementada por uma ferramenta de análise
chamada Team Role Self-Perception Inventory (TRSPI), apresentada em [Belbin 1981],
com o qual é possível identificar os papéis que um indivíduo tenderá a assumir em uma
situação de trabalho em equipe. O TRSPI é brevemente descrito na Seção 3.4.
2.2 Atividades Técnicas e Gerenciais
A Norma ISO/IEC NBR 12207 [NBR 1998] foi desenvolvida pela ISO (International
Organization for Standardization) e a IEC (International Electrotechnical Commission)
e tem como objetivo estabelecer uma estrutura comum para os processos de ciclo de
vida de software. O escopo da ISO/IEC 12207 abrange todo o ciclo de vida de software,
desde sua concepção até a descontinuidade do projeto de software, e os processos são
agrupados em três classes: Fundamentais, de Apoio e Organizacionais.
O Rational Unified Process© (RUP©), descrito em 15], é um processo genérico
para engenharia de software, que descreve atividades e papéis funcionais que servem de
38
base para implantação de processos de desenvolvimento em uma ampla variedade de
organizações que desenvolvem software.
Neste trabalho, foi realizado um estudo das atividades associadas aos processos
Fundamentais e de Apoio da Norma e dos 32 papéis funcionais descritos no RUP,
juntamente com as atividades a eles atribuídas, com o objetivo de consolidar um
conjunto pequeno de atividades técnicas que fosse capaz de cobrir a maioria das
atividades envolvidas em um processo genérico de desenvolvimento de software.
Tabela 1 - CARACTERIZAÇÃO DOS PAPÉIS EM TIME
Papel em
time (Título
Original)
Sigla Descritores Pontos Fortes Possíveis Fraquezas
Completer
Finisher
CF Ansioso,
consciencioso,
introvertido, tem
autocontrole, tem
autodisciplina,
submisso e
preocupado.
Meticuloso,
consciencioso, rocura por
erros e omissões, entrega
sem atraso.
Tendência a se preocupar
demais. Relutante a
delegar.
Implementer
(former
Company
Worker)
IMP Conservador,
controlado,
disciplinado, eficiente,
inflexível, metódico,
sincero, estável e
sistemático.
Disciplinado, confiável,
conservador e eficiente,
transforma idéias em
ações práticas.
Um tanto inflexível.
Lento para responder a
novas possibilidades.
Team Worker TW Extrovertido, amigável,
leal, estável, submisso,
confortante, não
assertivo e não
competitivo.
Cooperativo, suave, boa
percepção e diplomático,
escuta, constrói, evita
atritos, acalma o clima.
Indeciso em situações de
conflito.
Monitor
Evaluator
ME Seguro, fidedigno,
justo, introvertido,
aberto a mudanças,
sério, estável e sem
ambições.
Sóbrio, estratégico e
perspicaz, visualiza todas
as opções, julga com
precisão.
Não tem impulso e
habilidade para inspirar
outras pessoas.
Co-ordinator
(former
Chairman)
CO Dominante, confia nos
demais, extrovertido,
maduro, positivo, tem
autocontrole, tem
autodisciplina, estável.
Maduro, confiante, bom
diretor, esclarece
objetivos, promove a
tomada de decisão,
delega bem.
Pode ser visto como
manipulador.
Sobrecarregado com
trabalho.
Plant PL Dominante,
imaginativo,
introvertido, original,
pensamento radical,
cheio de confiança, não
se inibe.
Criativo, não ortodoxo,
soluciona problemas
difíceis.
Muito absorto em
pensamentos; dificuldade
para se comunicar
efetivamente.
Shaper SH Abrasivo, ansioso,
arrogante, competitivo,
dominante, irritável,
emocional,
extrovertido,
Desafiador, dinâmico,
prospera sob pressão,
tem impulso e coragem
para vencer obstáculos.
Suscetível a
provocações.
Ofende o sentimento das
pessoas.
39
impaciente, impulsivo,
autoconfiante.
Resource
Investigator
RI Diplomático,
dominante, entusiasta,
extrovertido, flexível,
inquisitivo, otimista,
persuasivo, positivo,
descontraído, social e
estável.
Extrovertido,
comunicativo, explora
oportunidades,
desenvolve contatos.
Excessivamente otimista.
Perde interesse depois do
entusiasmo inicial.
Esta consolidação é apresentada na Tabela 2 e teve como meta reduzir a quantidade
de valores para as variáveis da pesquisa. As características apresentadas na Tabela 2
foram utilizadas para construir o questionário de avaliação das preferências individuais
por atividades técnicas e gerenciais, que é discutido na Seção 3.4.
Tabela 3 - ATIVIDADES DO DESENVOLVIMENTO DE SOFTWARE CONSOLIDADAS
ATIVIDADES OBJETIVOS CARACTERÍSTICAS Análise Identificar as necessidades
dos usuários e avaliação e
concepção do sistema.
1. Identificação requisitos e modelagem de caso de
uso;
2. Especificar dados e avaliar resultados;
3. Detalhar as funcionalidades do sistema;
4. Entender o domínio da aplicação;
5. Investigar o que o cliente deseja.
Desenvolvimento Transformar especificações
em código.
1. Identificação dos componentes do software;
2. Definir abordagem de teste e assegurar sua
correta implementação;
3. Seguir padrões adotados para o projeto;
4. Seguir o projeto e a arquitetura definida;
5. Realizar testes unitários.
Teste Executar teste em programas
ou sistemas de programação
com a finalidade de
encontrar erros.
1. Buscar falhas no sistema;
2. Verificar os requisitos quanto a sua consistência,
completude e previsão;
3. Avaliar a qualidade global da interface;
4. Gerar relatório de teste;
5. Verificar os componentes gerados
Revisão Avaliar os artefatos de
planejamento e do projeto
nos pontos principais de
revisão do ciclo de vida do
projeto.
1. Planejar e conduzir as revisões;
2. Verificar código fonte;
3. Observar detalhes;
4. Revisar requisitos;
5. Revisar código.
Gerenciamento Planejar e gerenciar os riscos
do projeto.
1. Coordenar as interações com cliente e usuários;
2. Analisar decisões;
3. Manter a equipe de projeto concentrada na meta
certa.
4. Acompanhar atividades;
5. Procurar alternativas quando surge algum
problema.
3. METODOLOGIA
Esta pesquisa apóia-se no método de abordagem hipotético-dedutivo, onde a hipótese
geral é de que existem correlações entre preferências por atividades e perfis de Belbin.
Quantos aos meios, a pesquisa utiliza uma abordagem quantitativa apoiada no método
de procedimento estatístico. Os fenômenos observados são as preferências por
40
atividades técnicas e perfis de comportamento de Belbin entre engenheiros de software.
As variáveis têm natureza quantitativa. Quantos aos fins, a pesquisa é descritiva, pois
objetiva colher um conjunto de variáveis a partir de um estudo de campo e identificar
correlações existentes entre estas variáveis.
3.1 Fases da Pesquisa
Este trabalho foi estruturado em três fases:
Fase 1: esta pesquisa iniciou-se com uma revisão não sistemática da bibliografia
sobre equipes de desenvolvimento de software e comportamento do trabalho em
equipe. Ao final desta revisão, a norma ISO/IEC 12207 e o RUP foram
escolhidos como fundamento para descrição das atividades técnicas e gerenciais
no desenvolvimento de software e a Teoria de Belbin foi escolhida para
descrever o comportamento individual no trabalho em equipe. Estas escolhas
foramjustificadas na Seção 2
Fase 2: após o estudo e a seleção das teorias apropriadas, uma pesquisa de
campo foi cuidadosamente planejada e executada. A coleta de dados ocorreu
entre os meses de setembro de 2008 e março de 2009, em duas iterações, e
envolveu um total de 100 estudantes de graduação do Centro de Informática da
UFPE, em Recife, PE. Esta coleta foi realizada utilizando um questionário
objetivo, de questões fechadas, desenhado especificamente para este fim.
Fase 3: após a finalização da pesquisa de campo, os resultados foram gerados
utilizando-se o tratamento estatístico em duas fases. Primeiro houve a
identificação das preferências por atividades e dos perfis de comportamento de
Belbin. Em seguida, foram calculadas as correlações entre as atividades técnicas
e os perfis de comportamento através do coeficiente “_” de Spearman que mede
a intensidade destas relações. Uma vez com estes resultados, seguiu-se a análise
e elaboração de conclusões.
3.2 Unidade Experimental, Universo e Amostra da Pesquisa
A unidade experimental da pesquisa é o estudante de engenharia de software dos cursos
de graduação em Ciência e Engenharia de Computação do Centro de Informática da
UFPE, localizado em Recife – PE. Para caracterizar formalmente o universo, foram
considerados os estudantes que já haviam completado com sucesso (aprovação) a
disciplina de Engenharia de Software quando responderam ao questionário. Para validar
esta caracterização foi realizada uma verificação dos respondentes no sistema de
informação SIGA da UFPE.
De acordo com os dados fornecidos pela Coordenação de Graduação do CIn-
UFPE a população compreendia na época da coleta de dados 341 estudantes (135 de
Engenharia da Computação e 206 de Ciências da Computação). Esta população está
segmentada por gênero em ambos os cursos da seguinte forma: 91% de estudantes do
sexo masculino e 9% do sexo feminino.
A pesquisa utilizou uma amostra estratificada, proporcional à segmentação por
gênero da população. O tamanho da amostra, de 100 estudantes, correspondendo à 29%
do universo, foi calculado a priori para atingir um nível de confiança aceitável (95%),
com um intervalo de confiança de 8,25%.
41
3.3 Definição de Variáveis e Escalas
As variáveis desta pesquisa são a preferência por atividades técnicas extraídas da norma
ISO/IEC 12207 e do RUP e os papéis em time de Belbin, sumarizadas no Quadro 1.
Quadro 1 - Variáveis
Preferência por Atividades Papéis em Time de Belbin
AN Análise
DE Desenvolvimento
TE Teste
RE Revisão
GE Gerenciamento
IMP Implement
CO Co-ordinator
SH Shaper
PL Plant
RI Resource Investigator
ME Monitor Evaluator
TW Team Worker
CF Completer Finisher
Na Teoria de Tipos de Belbin, os papéis em time são medidos utilizando uma
escala razão com valores inteiros que variam entre 0 e 70. As pontuações são
convertidas para uma escala ordinal para refletir as tendências específicas de cada
experimento. Belbin (1981) utiliza uma conversão para uma escala ordinal de quatro
valores Baixo, Médio, Alto e Muito Alto, obtida a partir dos percentuais apresentados
no Quadro 2.
Quadro 2 - TABELA DE NORMAS DE BELBIN
Papel Baixo
0-33 %
Médio
33-66 %
Alto
66-85 %
Muito
Alto
85-100%
Média
IMP 0-6 7-11 12-16 17-23 10,0
CO 0-6 7-10 11-13 14-18 8,8
SH 0-8 9-13 14-17 18-36 11,6
PL 0-4 5-8 9-12 13-29 7,3
RI 0-6 7-9 10-11 12-21 7,2
ME 0-5 6-9 10-12 13-19 8,2
TW 0-8 9-12 13-16 17-25 10,9
CF 0-3 4-6 7-9 10-17 5,5
Esta conversão reflete as tendências específicas de determinadas amostras de
apresentarem ocorrências maiores ou menores de alguns perfis. Estas tendências
representam características sócio-culturais que não seriam capturadas na utilização
direta dos valores. A mesma conversão foi utilizada na amostra desta pesquisa e será
apresentada na Seção 4.
Para manter a compatibilidade com a variável Papel em Time, a variável
Preferência por atividade também é medida por uma escala razão com valores inteiros
entre 0 e 25. Os valores são obtidos através de um questionário semelhante ao TRSPI
(explicado abaixo), garantindo a possibilidade de correlacionar os valores das duas
variáveis. Da mesma forma que para os Papéis em Time, os valores da Preferência por
42
Atividades são convertidos para uma escala ordinal de valores Baixo, Médio, Alto e
Muito Alto, utilizando os mesmos percentuais no Quadro 2.
3.4 Instrumento da Pesquisa
O instrumento de coleta de informações de campo foi um questionário estruturado com
perguntas objetivas (fechadas) composto de três partes: (I) informações de controle; (II)
preferência por atividades; e (III) perfil de comportamento no trabalho em equipe. A
parte II foi desenvolvida neste trabalho tomando por base as atividades técnicas e
gerenciais descritas na norma ISO/IEC 12207 e no RUP. Esta parte é composta de cinco
questões, com cinco itens por questão. Cada questão descreve uma situação do
desenvolvimento de software e cada item descreve uma preferência dentro desta
situação e está relacionada a uma atividade técnica ou gerencial. A Figura 1 apresenta
uma das questões como exemplo.
O respondente deve atribuir cinco pontos (números inteiros) entre os cinco itens
em cada questão, de forma a refletir a sua preferência em cada situação. Assim, para
cada atividade do desenvolvimento de software a pontuação no questionário varia entre
o mínimo de 0 e o máximo de 25.
Para identificar os perfis de comportamento no trabalho em equipe foi utilizada a
Teoria de Papéis em Time de Belbin (Belbin’s Team Role Theory) e, desta forma, a
parte III do questionário é o instrumento associado à esta teoria, denominado Team Role
Self-Perception Inventory (TR-SPI), que é fornecido em [Belbin 1981]. O TRSPI
(versão original com oito papéis) é composto de sete questões, com oito itens por
questão. Cada item descreve um comportamento relativo a uma situação de trabalho em
equipe e está relacionada a um papel em time. A Figura 2 apresenta uma das questões
como exemplo.
O respondente deve atribuir 10 pontos (números inteiros) entre os oito itens em cada
questão, de forma a refletir a sua auto-percepção de como se comportaria em cada
situação descrita. Assim, para cada papel em time a pontuação no questionário varia
entre o mínimo de 0 e o máximo de 70.
Figura 1 - Questionário de Preferência por Atividades Técnicas e Gerenciais
Figura 2 - Questionário de Preferência por Atividades Técnicas e Gerenciais
43
3.5 Métodos e Ferramentas Estatísticas
Durante a coleta de dados, estes foram tabulados na ferramenta Microsoft Office Excel
2007. Ao final da coleta, as análises estatísticas foram realizadas com o pacote SPSS
(Statistical Package for Social Sciences) versão 13.0. Para verificar a existência de
correlação entre a por atividades e o papel em equipe na Teoria de Papéis de Time de
Belbin foi utilizado o coeficiente correlação de Posto de Spearman, normalmente
designado “rho” (_), e definido pela seguinte fórmula:
𝜌 = 1 − 𝜌 ∑ 𝑑𝑖
2𝑛𝑖=1
𝑛3 − 𝑛, 𝑜𝑛𝑑𝑒, −1 ≤ 𝜌 ≤ +1
Onde, n representa o número de pares (Xi, Yi) e d é diferença entre os postos
para as duas observações dentro de um par ((postos de Xi dentro os valores de X) –
(postos de Yi dentro os valores de Y)). O coeficiente _ de Spearman varia entre -1 e 1.
Quanto mais próximo estiver destes extremos, maior será a associação entre as
variáveis. O sinal negativo da correlação significa que as variáveis variam em sentido
contrário, isto é, as categorias mais elevadas de uma variável estão associadas a
categorias mais baixas da outra variável.
4. RESULTADOS E ANÁLISE
A PESQUISA ENVOLVEU UM TOTAL DE 100 ESTUDANTES DE
INFORMÁTICA, DOS CURSOS DE CIÊNCIAS DA COMPUTAÇÃO E
ENGENHARIA DE SOFTWARE DO CENTRO DE INFORMÁTICA – CIN DA
UNIVERSIDADE FEDERAL DE PERNAMBUCO - UFPE, CONSIDERANDO
APENAS OS RESPONDENTES VÁLIDOS.
Quadro 3 ilustra a amostra estratificada dos estudantes de informática em relação
ao sexo.
Quadro 3 - UNIVERSO E AMOSTRA DA PESQUISA
Curso Masculino % Feminino % Total
Universo
Ciência da Computação 215 91% 21 9% 236
Engenharia da Computação 123 91% 12 9% 135
Amostra
Ciência da Computação 61 91% 6 9% 67
Engenharia da Computação 30 91% 3 9% 33
4.1 Conversão das Escalas
Conforme explicado na Seção 3, os valores das variáveis devem ser convertidos para
uma escala ordinal para refletir as características específicas da amostra da pesquisa.
Assim, utilizando o procedimento definido em [Belbin 1981], duas tabelas de normas
foram construídas para as variáveis Preferência por Atividades e Papéis em Time e
estão apresentadas no Quadro 4 e no Quadro 5, respectivamente.
Quadro 4 - NORMAS PARA AS PREFERÊNCIAS POR ATIVIDADES
44
Papel Baixo
0-33 %
Médio
33-66 %
Alto
66-85 %
Muito
Alto
85-100%
Média
AN 0-7 8-10 11-13 14-19 9,2
DE 0-6 7-9 10-12 13-19 8,1
TE 0-4 5-8 9-10 11-18 7,0
RE 0-3 4-5 6-8 9-12 4,9
GE 0-3 4-7 8-10 11-17 5,9
Quadro 5 - NORMAS PARA OS PAPÉIS EM TIME
Papel Baixo
0-33 %
Médio
33-66 %
Alto
66-85 %
Muito
Alto
85-100%
Média
IMP 0-8 9-11 12-15 16-22 10,7
CO 0-6 7- 9 10-13 14-21 8,8
SH 0-7 8-11 12-14 15-22 8.5
PL 0-6 7-10 11-13 14-20 8,5
RI 0-5 6-8 9-11 12-18 7,2
ME 0-5 6-8 9-12 13-23 7,7
TW 0-7 8-11 12-15 16-36 10,7
CF 0-5 6-9 10-11 12-20 7,9
O Quadro 6 compara as médias apresentadas por Belbin (1981) e as obtidas neste
trabalho.
Quadro 6 - COMPARAÇÃO COM AS MÉDIAS DE BELBIN
Papel Baixo
0-33 %
Médio
33-66 %
Alto
66-85 %
Muito
Alto
85-100%
IMP 10,0 10,7 0,7 -7%
CO 8,8 8.8 0,0 0%
SH 11,6 8.5 -3,1 26%
PL 7,3 8.5 1,2 -16%
RI 7,8 7.2 -0,6 7%
ME 8,2 7.8 0,4 5%
TW 10,9 10.7 0,2 2%
CF 5,5 7.8 2,4 -43%
É importante ressaltar três diferenças significativas nos resultados acima. Primeiro,
existe uma diminuição nos valores para o papel SH, demonstrando que a amostra exibe
45
este papel associado à liderança em menor nível que no estudo original de Belbin, que é
consistente com o fato de que o estudo de Belbin utilizou somente gerentes atuantes no
mercado, para os quais se esperava um percentual alto de papéis de liderança. Segundo,
existe um aumento nos valores para o papel PL, que pode ser considerado consistente
com o fato da amostra desta pesquisa ser composta de sujeitos com perfil de criação e
solução de problemas complexos.
Finalmente, existe um considerável aumento nos valores do papel CF,
considerado um papel que possui baixa ocorrência na população em geral. Este perfil,
de acordo com [Ferreira e Da Silva 2007] está associado aos processos de garantia de
qualidade e aderência a processos. Neste caso, uma hipótese que pode ser levantada é
que a área de engenharia de software está atraindo indivíduos com tendências a exibir
este papel em time, pois este papel está sendo valorizado no mercado em função das
necessidades crescentes de aumento de qualidade e aderência a processos de
desenvolvimento bem definidos. No entanto, esta hipótese ainda precisa ser testada.
4.2 Tendências na Preferência por Atividades e pelos Papéis em Time
Uma tentativa inicial de responder às perguntas de pesquisa 1 e 2 (Seção 1) é através
da análise da freqüência de ocorrência de valores Alto e Muito Alto para as duas
variáveis. Porém, uma inspeção simples destas ocorrências não permite concluir se
existem tendências na amostra para determinadas preferências ou papéis. Para buscar
respostas mais conclusivas para as perguntas 1 e 2, foi analisada a uniformidade da
distribuição das médias dos valores numéricos dos variáveis, utilizando o teste de
Bonferroni. Os próximos quadros apresentam os resultados do teste.
O quadro 7. mostra que as médias mais elevadas registradas nas Preferências por
Atividades foram AN (9.2) e DE (8,1) e a menos elevada correspondeu à atividade RE
(4,9). Através do resultado do teste de Bonferroni (letras semelhantes entre parêntesis)
comprovam-se diferenças significantes entre o par AN-DE com cada uma das variáveis
TE, RE e GE. Portanto, mostrasse que a preferência por atividades técnicas e gerenciais
não é uniformes na amostra. Conclui-se que as atividades de análise e desenvolvimento
têm uma tendência a despertar maior interesse dos engenheiros de software, enquanto
revisão e gerenciamento despertam menor interesse.
Explicações para este resultado podem ser atribuídas a dois fatores. Primeiro, a
ênfase na formação dos engenheiros de software é nas atividades relacionadas à solução
de problemas e implementação de sistemas: análise e desenvolvimento. Portanto,
atividades como teste e revisão, são apresentadas com ênfase menor. Segundo, as
atividades de gerenciamento (GE) demandam maturidade pessoal e profissional que o
os participantes desta pesquisa não possuem. É, portanto, consistente a baixa preferência
por atividades de gerenciamento.
O quadro 8 mostra as maiores médias para os papéis TW e IMP com valores
idênticos (10,7) e a menor média para o perfil RI (7,2). O teste de Bonferroni agrupa os
papéis TW e IMP em uma categoria (letras iguais entre parêntesis), expressando uma
tendência da amostra nestes papéis. O teste também agrupa as médias de CO, SH, PL,
CF, ME e RI. Estes agrupamentos evidenciam que, também para os papéis em time,
existe uma tendência, respondendo à pergunta 2 da pesquisa.
46
Com os resultados acima é possível mostrar que existem tendências tanto para as
Preferências como para os Papéis. Porém, estes testes não permitem avaliar se existem
relações entre estas tendências, o que será realizado na próxima seção.
Quadro 7 - COMPARAÇÕES PAREADAS DE BONFERRONI DAS MÉDIAS DAS PREFERÊNCIAS
Preferência por Atividades AN DE TE GE RE
Média dos Valores Numéricos 9,2(4.1) 8,1(4.1) 7,0(4.2) 5,9(4.2) 4,9(4.2)
Quadro 8 - MÉDIA DOS PAPÉIS E COMPARAÇÕES PAREADAS DE BONFERRONI
Papeis
em Time
TW IMP CO SH PL CF ME RI
Média dos
Valores
Numéricos
10.7(4.1) 10.7(4.1) 8.8(4.1,4.2) 8.5(4.2) 8.5(4.2) 7.9(4.2) 7.8(4.2) 7.2(4.2)
4.3 Correlações entre Preferências por Atividades e Papéis em Time
Nesta seção serão estudas as possíveis correlações entre as duas variáveis, utilizando o
coeficiente de correlação _ de Spearman. No Fonte: Elaboração própria Quadro 9, os
valores grifados em negrito mostram as correlações significantes.
Quadro 9 - CORRELAÇÃO ENTRE PREFERÊNCIAS E PAPÉIS
IMP CO SH PL RI ME TW CF
AN -.149 .059 -.271(*) .133 177 .076 .080 -.033
DE .207(*) -.295(**) .164 .184(*) -.231(*) .013 -.065 -.028
TE .041 -.121 -.024 -.153 -.124 .161 .119 -.025
RE .073 .038 .069 .028 .078 -.104 -.210(*) .199(*)
GE -.199(*) .286(**) .122 -.119 .236(**) -.145 -.025 -.054
Tabela 3 - CORRELAÇÕES ENTRE AS VARIÁVEIS
Variáveis Correlação Explicação Preliminar
AN-SH (-) Esta correlação negativa era esperada. A análise envolve “investigar o que
o cliente deseja” enquanto o perfil Shaper é “abrasivo, ansioso, arrogante”
podendo “ofender o sentimento alheio. A necessidade de relacionamento
supostamente amigável com o cliente deve levar a pessoas que exibam o
papel de Shaper a não ter preferência por atividades de análise.
DE-IMP (+) Esta correlação positiva é esperada e corroborada por França e da Silva
(2007). Pessoas com papel Implementer apresentam o comportamento de
transformar planos em ação, e devem ter uma tendência a preferir
atividades de implementação.
DE-CO (-) Esta correlação negativa não é óbvia, mas é consistente com a correlação
negativa entre GE e IMP e a positiva entre DE-IMP.
47
DE-PL (+) A correlação positiva não é prevista em França e da Silva (2007), mas é
corroborada por Stevens (1998), Schoenhoff, (2001) e Rajendram (2005),
em particular quando existem problemas não triviais no desenvolvimento.
DE-RI (-) A correlação pode ser entendida uma vez que o Resource-Investigator
“perde interesse depois do entusiasmo inicial”, sendo um papel que deve
preferir atividades com maior desafio intelectual e menos características
operacionais.
RE-TW (-) Esta correlação negativa não é imediatamente decorrente do referencial
teórico nem da análise comparativa entre papéis e atividades. Novas
pesquisas devem aprofundar este achado experimental.
RE-CF (+) Esta correlação é esperada uma vez que a atividade de Revisão envolve
“observar detalhes” e o papel Completer-Finisher é “meticuloso,
consciencioso, procura por erros e omissões”.
Rajendram (2005) associa o papel CF com as atividades de Revisão e
Teste.
GE-IMP
GE-CO
GE-RI
(-)
(+)
(+)
As três correlações da atividade Gerenciamento estão previstas nos
trabalhos de França e da Silva (2007) e Fernandes e da Silva (2007). Em
particular, a correlação negativa também pode ser explicada pois o papel
Implementer tende a ter um comportamento “inflexível e lento para
responder a novas possibilidades”, características que não ser adéquam à
atividade de Gerenciamento.
É importante notar que não foi encontrada nenhuma correlação entre a Preferência
pela Atividade de Teste e os Papéis em Time. Uma explicação possível é que esta
preferência (alta ou baixa) está uniformemente espalhada entre os papéis fazendo com
que não existe uma correlação significativa com nenhum grupo em particular.
O teste estatístico de correlação não determina a relação de causa e efeito. Portanto,
não é possível concluir se é o papel que determina a preferência, apesar de que esta é
uma hipótese razoável. Além disso, não faz parte do escopo da análise quantitativa
explicar o porquê dos resultados, no caso, as correlações.
No entanto, utilizando resultados da literatura (principalmente [Stevens 1998],
[Schoenhoff 2001],[França e Da Silva 2007],[Ferreira e Da Silva 2007]) e a
caracterização dos papéis em time da tabela 1, é possível apresentar explicações
preliminares para estes resultados, que devem ser analisadas com mais profundidade em
um estudo qualitativo futuro. A Tabela 3 apresenta estas explicações.
5. CONSIDERAÇÕES FINAIS
Neste trabalho foram investigadas relações entre preferências individuais por atividades
técnicas e gerenciais do desenvolvimento de software e papéis que descrevem
comportamento pessoal no trabalho em equipe. Três perguntas centrais nortearam o
desenvolvimento da pesquisa: (1) existe tendência nas preferências por atividades; (2)
existe tendência na ocorrência de papéis em time; (3) existe correlação entre
preferências e papéis. Para as três perguntas, as respostas obtidas através de uma
pesquisa de campo foram positivas:
1. As atividades de Análise e Desenvolvimento são preferidas em relação às de
Teste, Revisão e Gerenciamento.
2. Os papéis Teamworker e Implementer tendem a ocorrer mais freqüentemente
na amostra do que os outros seis papéis.
48
3. Das 40 possíveis combinações entre Preferências e Papéis, 10 apresentam
correlação significativa de acordo com o coeficiente por Posto de Spearman.
A resposta para (1) evidencia que os estudantes de engenharia de software têm
uma tendência a preferir atividades diretamente relacionadas à solução de problemas e
construção de sistemas. Seria importante realizar um estudo qualitativo para saber se
esta preferência está relacionada a uma percepção dos estudantes de que estas atividades
são mais intelectualmente desafiadoras. Os resultados em (2) mostram que os papéis associados ao desenvolvimento (Implementer) e ao trabalho em equipe (Teamworker) ocorrem com mais frequência.
As correlações encontradas como resposta para (3) contribuem nos processos de
composição de equipes de desenvolvimento de software, principalmente quando
utilizadas em conjunto com os resultados da literatura e em particula [Fernandes e Fabio
2007], [Ferreira e Da Silva 2007], [França e Da Silva 2007]. Estes resultados podem ser
utilizados para auxiliar na alocação de pessoas aos papéis funcionais em uma equipe de
desenvolvimento levando em consideração suas características comportamentais e
pessoais.
Quanto à validade, a pesquisa possui validade de conclusão, uma vez que existe
correlação entre as variáveis, confirmada pela análise estatística, dentro dos limites do
nível de confiança (95%) e do intervalo de confiança (8,25%). Não é possível afirmar a
validade interna da pesquisa pois não foram estabelecidas relações de cause-efeito entre
as variáveis. Trabalhos futuros devem investigar estas relações. A generalização dos
resultados, validade externa, está restrita a populações com perfis comparáveis ao deste
trabalho: estudantes de cursos de ciência ou engenharia da computação que tenham
cursado disciplinas de engenharia de software. Estudos com populações distintas (por
exemplo, profissionais atuantes no mercado) estão sendo conduzidas com o objetivo de
ampliar a validade externa deste trabalho.
Como trabalho futuro propõe-se a investigação do impacto da formação de
equipes considerando características comportamentais e pessoais no desempenho das
equipes. Além disso, aspectos sociais e organizacionais serão acrescentados ao
problema de formação e desenvolvimento de equipes com o objetivo de se estabelecer
modelos e processos de suporte à gestão de equipes de melhor desempenho em
engenharia de software. Esta pesquisa tem o objetivo mais amplo de estudar os vários
aspectos relacionados ao ciclo de vida de equipes de desenvolvimento de software e este
trabalho é uma contribuição nesta direção.
REFERÊNCIAS
Acuna, S. T.; Juristo, N.; Moreno, A. M. (2006) Emphasizing human capabilities in
software development. IEEE Software, vol. 23:(2), 2006, pp. 94–101.
Aritzeta, A., Swailes, S., And Senior, B. (2007) "Belbin`s Team Role Model:
Development, Validity and Applications for Team Building". Journal of
Management Studies, vol. 44:(1), 2007, pp. 96-118.
Belbin, M. R. (1981) Management Teams: Why they succeed or Fail? Butterworth-
Heinemann Ltd., 1981.
Belbin, M. R. (1993) Team Roles at Work. Elsevier Butterworth-Heinemann Ltd., 1993.
49
Capretz, L. F. (2002) Implications of MBTI in Software Engineering Education.
SIGCSE Bulletin, vol. 34:(4), 2002.
Capretz, L. F. (2003) Personality types in software engineering. Int. J. Human-
Computer Studies vol. 8, 2003, pp. 207–214.
Cunha, A. D. (2007) Greathead, D. Does personality matter? : an analysis of code-
review ability. Communications of the ACM. New York, USA: Associatiom for
Computing Machinery, vol. 50:(5), 2007, pp. 109-112.
Fernandes, F.; Da Silva, Fabio Q. B. (2007) Relações entre competências pessoais e
tipos de personalidade do gerente de projetos. Anais do 2º Congresso Brasileiro em
Gerenciamento de Projetos, Salvador, BA, 2007.
Ferreira, P.G.; Da Silva, F. Q. B. (2008). Fatores que influenciam a utilização de
processos de software. Anais do VII Simpósio Brasileiro de Qualidade de Software,
Florianópolis, SC, 2008.
Fisher, S. G., Hunter, T. A. And Macrosson, W. D. (2002) ‘Belbin’s team role theory:
for non-managers also? ’. Journal of Managerial Psychology, vol. 17, 2002, pp. 14–
20.
França, A.C.; Da Silva, F. Q. B. (2007). Um estudo sobre Relações entre Papéis
Funcionais do RUP e o Comportamento Pessoal no Trabalho em Equipe em Fábricas
de Software. III WOSES -Workshop Um Olhar Sociotécnico sobre a Engenharia de
Software, 2007.
Gorla, N., And Lam, Y.W. (2004) Who should work with whom? Building effective
software project teams. Communication of the ACM, vol. 47:(6), 2004.
Henry, S. M.; Stevens, K. T. (1999) Using Belbin’s Leadership Role to Improve Team
Effectiveness: an empirical investigation, Journal of Systems and Software, vol.
44:(3), 1999, pp. 241-250.
Karn, J. And Cowling, T. (2006) A Follow up Study of the Effect of Personality on the
Performance of Software Engineering Teams. Proceedings of the 2006 ACM/IEEE
International Symposium on Empirical Software Engineering (ISESE’06), Rio de
Janeiro, Brazil, 2006, pp. 232-241.
Kruchten, P. (2003) Introdução ao RUP – Rational Unified Process, Rio de Janeiro:
Editora Ciência Moderna Ltda., 2003.
NBR ISO/IEC 12207. (1998) NBR ISO/IEC 12207 – tecnologia de informação:
processos de ciclo de vida de software. Rio de Janeiro: ABNT, 1998.
Rajendran, M. (2005) Analysis of team effectiveness in software development teams
working on hardware and software environments using Belbin Self-perception
Inventory, Journal of Management Development, vol. 24:(8), 2005, pp. 738-753,
Emerald Group Publishing Limited, 0262-1711, DOI 10.1108/02621710510613753.
Schoenhoff, P.K. (2001) Belbin's Company Worker, The Self-Perception Inventory, and
Their Application to Software Engineering Teams. Master Thesis, Virginia
Polytechnic Institute and State University, 2001.
50
Senior, B. (1998) An empirically-based assessment of Belbin s team roles Human
Resource Management. Human Resource Management Journal, vol. 8:(3), 1998, pp.
54-60.
Stevens, K.T. (1998) The Effects of Roles and Personality Characteristics on Software
Development Team Effectiveness. Doctoral Thesis, Virginia Polytechnic Institute
and State University, 1998.
Swailes, S. And Aritzeta, A. (2006) Scale Properties of the Team Role Self-Perception
Inventory. International Journal of Selection and Assessment, vol. 14:(3), 2006, pp.
292-298.
51
𝑪𝑯𝑹𝒓 𝒇∨ : A Logic Inference Engine to Resolution Leveraged by
Heuristics
Cleyton Rodrigues, Renata Maria de Souza
Federal University of Pernambuco, Informatics Center, CDU, 7851, Recife,
Pernambuco, Brazil.
{cmor,rms6}@cin.ufpe.br
Abstract. Automated Reasoning (AR) has been a traditional research area. In this
field, Theorem Proving (TP) concerns the deductive view of a problem solving. Many
theorem prover were created in the literature, however, while some of them are not
fully-automatic (requires human interaction along the proof calculus), others are not
clear-cut enough to work with the engine. Further, many of these are highly inflexible,
in other words, they do not allow to be extended with new heuristics. Thus, this work
proposes the 𝐶𝐻𝑅𝑟 𝑓∨ (Constraint Handling Rule Engine for Resolution/Factoring) a
resolution Classical First Order Logic (CFOL) inference engine built upon the general
declarative logic constraint language 𝐶𝐻𝑅∨. In this paper, we show how a 𝐶𝐻𝑅∨
inference engine can also support the following form of fully automated theorem
proving: entailment of a disjunction of conjunctions of atomic formulas by an arbitrary
first-order logic formula.
1. Introduction
Automated Reasoning is the Artificial Intelligence field which studies computational
knowledge representation and reasoning in terms of Decidability, “that is, there exists
an algorithm such that for every formula in the system the algorithm is capable of
deciding in finitely many steps whether the formula is valid in the system or not”
[NationMaster 2010], and others properties such as completeness, monotonicity and
consistency. Decidability can be reformulated as a task of logical consequence. In short,
it is the reasoning in which, given a formula H and a set of assumptions KB (in other
words, a domain-specific knowledge base for the representation and acquisition of
knowledge), H is a logical consequence of KB in a deduction system, if there is a proof
of H from KB, notated as: KB |= H. In this sense, this paper presents 𝐶𝐻𝑅𝑟 𝑓∨
, an
automatic resolution inference engine for theorem proving, which can also be easily
extend to addresses some heuristics, special maneuvers leading to a more skillful
theorem prover.
This paper is organized as follows: section 2 and 3 resumes, briefly, the main
concepts of Resolution and 𝐶𝐻𝑅∨ (the language used to implement the 𝐶𝐻𝑅𝑟 𝑓∨
system),
respectively; further, in section 4 the system is detailed and the first results are outlined,
and finally section 5 presents the conclusion and the future works.
2. Resolution
When working with theorem provers, completeness becomes a critical factor in
choosing the best logic inference engine. However, this is not possible in CFOL when
inferences as Modus Ponens is used. Therefore, there is the urgency of working with
Resolution. Coupled with Factoring, this procedure is complete for CFOL clauses.
Actually, Resolution is a refutation completeness [Russell and Norvig 2003]
52
inference procedure in the sense that, it can not derive from the the knowledge base all
the true sentences, but it can reason about the entailment of any one. Furthermore,
Refutation, or reduction ad absurdum is a proof by contradiction, where to check
whether KB entails H, is enough to check the unsatisfiability of KB ^ ¬H. In
Resolution, it is essential that all clauses assume the Conjunctive Normal Form (CNF)
notation. According to it, a clause is represented by a disjunction of literals. We say that
two literals can be resolved if they are complementary, in the sense that the positive
literal is unifiable with the negative one. Factoring, by other side, is an auxiliary
mechanism coupled with resolution, which removes copies of the same literals in the
consequent clause. A copy of one literal is not necessarily equivalent, but unifiable with
it.
3. CHRV in a Nutshell
Constraint Handling Rules with Disjunction (𝐶𝐻𝑅∨) [Abdennadher and Schtz 1998] is a
general concurrent logic programming language, rule-based, which have been adapted
to a wide set of applications as: constraint satisfaction [Wolf 2005], abduction
[Gavanelli, Alberti and Lamma 2008], componente-development engineering [Fages,
Rodrigues and Martinez 2008], and son on. It is designed for creation of constraint
solvers. 𝐶𝐻𝑅∨ is a fully accepted logic programming language, since it subsumes the
main types of reasoning systems: the production system, the term rewriting system,
besides Prolog rules. Additionally, the language is syntactically and semantically well-
defined (check the references for further details). Concerning the syntax, a
𝐶𝐻𝑅∨ program is a set of rules defined as:
rule_name@ 𝐻𝑘 ⁄ 𝐻𝑟 ⇔ G | B
Rule name is the non-compulsory name of the rule. The head is defined by the
predicates represented by Hk and Hr (user-defined predicates), with which na engine
tries to match with the constraints in the store. Further, G stands for the set of guard
predicates (built-in predicates), that is, a condition imposed to be verified to fire any
rule. Finally, B is the disjunctive body (a collection of user-defined and built-in
predicates), corresponding to a set of constraints added within the store, whenever the
rule fires. The logical conjunction and disjunction of predicates are syntactically
expressed by the symbols , and ;, respectively. Logically, the interpretation of the rule is
as follows:
∀𝑉𝐺𝐻 ( 𝐺 → ((𝐻𝑘 ∧ 𝐻𝑟) ↔ (∃𝑉𝐵 𝐺𝐻⁄ 𝐵 ∧ 𝐻𝑘))) , 𝑤ℎ𝑒𝑟𝑒 𝑉𝐺𝐻
= 𝑣𝑎𝑟𝑠(𝐺) ∪ 𝑣𝑎𝑟𝑠(𝐻𝑘) ∪ 𝑣𝑎𝑟𝑠(𝐻𝑟), 𝑉𝐵 𝐺𝐻⁄ = 𝑣𝑎𝑟𝑠(𝐵) 𝑉𝐺𝐻⁄
4. 𝑪𝑯𝑹𝒓 𝒇∨ : Experiments and Outcome
This sections addresses the reformulation of CNF clauses (the refutation rule, inclusive),
enjoying the ability of program user defined constraints in CHR_engine. Roughly
speaking, CHR_rf is a rule system capable to perform the basic inference rules presented
in the previous section, namely: resolution and factoring. Therefore, for each pair of
these user constraints, the engine tries to resolve based on the complementary literals.
Each new resolution is taken to resolve itself until no resolution is possible or the
CHR_engine derives a constraints with no parameters (logically, the empty-clause).
Initially, all CFOL clauses and the refutation rule are expressed in CNF notation. Then,
53
each conjunctive clause of the form: ¬𝜌1 ∨ ¬𝜌2 ∨ ¬𝜌3 ∨ ¬𝜌4 turns onto a implies/6
𝐶𝐻𝑅∨ user defined constraint:
𝑖𝑚𝑝𝑙𝑖𝑒𝑠(𝑎𝑛𝑑([ ], [𝜌1, 𝜌2]), 𝑜𝑟 ([ ], [𝜌3, 𝜌4]), 𝑆𝑡𝑎𝑔𝑒, 𝐼𝑑, 𝐼𝐷_𝐶𝑜𝑛𝑠𝑡𝑟𝑎𝑖𝑛𝑡, 𝑆𝑆)
where: [𝜌1, 𝜌2] represents a list with the negative literals, [𝜌3, 𝜌4] represents a list with
the positive literals, Stage corresponds to the current status of the constraint, thus
indicating which operation is possible to be realized (possible values are: toSort, toFactor, and toResolve); Id corresponds to a integer (unique) associated with the
constraint; ID Constraint corresponds to a list of identifiers of constraints, with which
the constraint has already tried to resolve (thus, before resolving the constraints, the
engine checks if this process had not tried yet, avoiding trivial non-termination); SS is a
enumeration type which can assume one of the values: n which says that the implies
token is not part of the Set of Support, or y, otherwise.
Once all clauses in CNF have been reformulated to implies/6 CHR_constraints, we
apply (manually) some additional steps to fix mismatches between both representations
(CFOL and 𝐶𝐻𝑅∨), they are: (i) universal vs. existential quantifiers and (ii) unification
vs. matching. In (i), we add additional variables in the head of 𝐶𝐻𝑅∨rules1 (for all the
local existential variables), which changes the variable semantics to be universally
quantified, as a skolemized CFOL formula, while for (ii) the engine uses a prolog
predicate which preforms a sound-unification unify with occurs check
(+Term1,+Term2), since, in nature, 𝐶𝐻𝑅∨ performs matching, that is, one-side
unification.
𝐶𝐻𝑅𝑟 𝑓∨ system operates in three well-defined phases: phase 1 (toSort)- both list of
constraints are sorted to help the resolution and factoring, phase 2 (to-Factor) - each list
from implies/6 constraint are revisited to delete equivalente terms2; phase 3 (toResolve)
- each pair of constraints is tried to resolve; if not possible, the identifier of each
constraint is added to the list of the partner, to avoid further futile attempts. On the other
hand, if the resolution occurs, a new constraint is created with status toSort and its id is
formed by junction of the parents identifiers. In order to improve the system, 𝐶𝐻𝑅∨ is
flexible enough to extend with some heuristics, like: Set of Support and Linear
Resolution. For the former case, as mentioned earlier, the field SS for the constraints
tells which constraint is part of the set (in our context, only the refutation clause and all
the clauses derived by resolution). For the Linear Resolution, in turn, we ensure that a
constraint from the SS may resolve with the others (not part of the set) or with any of its
ancestor (this is possible, since the id keeps a track of all the parents constraints). The
table below outlines some results with the engine. The problems and 𝐶𝐻𝑅𝑟 𝑓∨ can be
found at http://cin.ufpe.br/~cmor/JELIA/.
Table 1 - Results for the 𝑪𝑯𝑹𝒓 𝒇∨ system
Problem/Puzzle Nr. Implies Refutation Query Time(s)
Fido 4 die(Fido) 0,016
1 Variables in 𝐶𝐻𝑅∨
head rules are universally quantified, while the ones presented locally in 𝐶𝐻𝑅∨body
rules are existentially quantified 2 In this context, equivalents terms are a variant of each other, or in other word, they have the same
functor and the variables are renamed.
54
Lucky 7 happy(john) 0,062
Tuna 8 kill(curiosity,tuna) 2,403
Happy 11 loves(melinda,bill) 0,172
Marcus-Caesar 9 hate(marcus,caesar) 5,772
5. Final Remakes and Future Works
𝐶𝐻𝑅∨ is a very versatile constraint language to knowledge representation and
inference. This article showed briefly a resolution inference system coupled with some
heuristics deployed by the 𝐶𝐻𝑅∨ language. In order to validate the engine, some
benchmark tests will be carried out to compare with some research related. Further, we
will improve the engine to hold others inference algorithm, such as, forward chaining
and backward chaining.
References
NationMaster (2010) Encyclopedia-decidability
Russell, S., Norvig, P. (2003) Constraints Satisfaction Problems. In: Artificial
Intelligence: A Modern Approach. 2nd edition edn. Prentice-Hall, Englewood Cliffs,
NJ (2003) 214
Abdennadher, S., Schtz, H. (1998) Chrv: A flexible query language. In: In FQAS 98:
Proceedings of the Third International Conference on Flexible Query Answering
Systems, Springer-Verlag (1998) 1–14
Wolf, A. (2005) Intelligent search strategies based on adaptive constraint handling rules.
Theory Pract. Log. Program. 5(4-5) (2005) 567–594
Gavanelli, M., Alberti, M., Lamma, E. (2008) Integrating abduction and constraint opti-
mization in constraint handling rules. In: Proceeding of the 2008 conference on
ECAI 2008, Amsterdam, The Netherlands, The Netherlands, IOS Press (2008) 903–
904
Fages, F., Mário de Oliveira Rodrigues, C., Martinez, T. (2008). Modular CHR with
ask and tell. In: CHR ’08: Proc. 5th Workshop on Constraint Handling Rules, (Linz,
Austria) 95–110
