PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL

FACULDADE DE INFORMÁTICA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
CURSO DE MESTRADO

Sabrina dos Santos Marczak

AMIGO
Um Agente para MonItorar e Gerenciar infOrmações

Porto Alegre, 2003

 SABRINA DOS SANTOS MARCZAK

AMIGO - Um Agente para MonItorar e Gerenciar infOrmações

Dissertação apresentada como requisito parcial

à obtenção do grau de Mestre, pelo Programa
de Pós-Graduação em Ciência da Computação
da Pontifícia Universidade Católica do Rio
Grande do Sul.

Orientadora: Profª. Drª. Lucia Maria Martins

Giraffa

Porto Alegre, 2003

 A todos aqueles que ainda acreditam que a Educação é a única forma de mudarmos este
nosso país. Também àqueles que acreditam que a educação (especialmente aquela advinda
da estrutura familiar) é a melhor forma de criarmos cidadãos com a capacidade de
respeitarem seus semelhantes e viverem em sociedade.
 AGRADECIMENTOS

À minha estimada e eterna orientadora, amiga e “quase” mãe Lucia Giraffa, pela
orientação dispensada no desenvolvimento deste trabalho e na minha formação profissional e
pessoal. Por ter proporcionado a criação de uma “equipe” de pesquisa com a disponibilização
de dois bolsistas. Por sua ética profissional e pessoal, que serviram (e continuarão servindo)
de modelo para as minhas atitudes. Pelo exemplo de dignidade e responsabilidade com os
compromissos que assume. Pelas conversas e palavras de incentivo. Pelas críticas e apoio nos
momentos de dificuldade. Pelo carinho demonstrado em diversas situações e contextos.

Ao Prof. Dr. Marcelo Blois, pelas revisões técnicas feitas e todas as sugestões
realizadas, as quais contribuíram consideravelmente para a definição e andamento deste
trabalho. Por ter aceitado o convite de fazer parte da nossa equipe de pesquisa, como prof. Co-
Orientador.

Aos incansáveis e dedicados bolsistas (e amigos) Gláucio Almeida e Luana

Bernardino. Pelas suas iniciativas e vontade de aprender. Por todas as vezes que esperaram
com paciência a demanda de uma nova atividade e assunto para estudar e pesquisar. Por terem
entendido o que é trabalhar em equipe e terem atuado como integrantes de uma.

Ao Prof. Dr. Crediné Menezes e sua equipe (GAIA), em especial ao seu aluno Hylson
Netto, pela ajuda e atenção dispensadas durante o estudo do ambiente AmCorA e inspiração
do PROOGRAMA. Também ao Prof. Dr. Sérgio Crespo, pela disponibilidade e auxílio
prestado. Pelas idéias, apoio e incentivo à continuidade deste projeto.

Aos demais especialistas, amigos e colegas de curso consultados – Alberto Chemale,

Claudia Pedroso, Leandro Lopes e Rafael Prikladnicki, pelas críticas feitas e alterações
propostas. Pelas dicas de recursos e soluções que poderiam ser adotadas. Pelas revisões e
leituras nos diversos textos redigidos no contexto deste trabalho.
 À minha estimada família – Ricardo, Maria Luisa, Samuel (e Sam, o cachorro), pelo
incondicional apoio prestado, cada um a sua maneira. Por terem sido, mais uma vez, minha
sustentação quando eu estava prestes a desmoronar. Por estarem sempre dispostos a me
escutar e conversar. Por terem compartilhado as angústias e as alegrias relacionadas a mais
esta etapa da minha vida (assim como em todas as outras). Pelo amor incondicional que
possuem por mim.

Aos meus estimados amigos – Alberto Chemale, Eduardo Gomes, Gabriela Cristina da
Rosa e Patrícia Gomes, que mesmo tendo os convites para os momentos de lazer negados
constantemente não se cansaram de realizá-los, dia após dia. Por terem me escutado “divagar”
sobre meu trabalho, sem nem sequer (em alguns casos) fazerem parte do “mundo” da Ciência
da Computação e terem entendido o contexto da pesquisa.

À PUCRS, pelo seu exemplo de Universidade. Pelo respeito apresentado às pessoas

que constituem a comunidade universitária. Pela ótima estrutura física e recursos
disponibilizados. Por seu corpo docente qualificado, em especial ao Prof. Dr. Jorge Audy, que
me mostrou durante os meses de trabalho em conjunto no Convênio Dell/PUCRS que o
essencial para ser um bom pesquisador é querer descobrir ou solucionar algo, não importando
quanto se saiba previamente sobre o assunto. Por sua eficiente equipe de funcionários,
especialmente ao secretário Leandro Oliveira, o qual foi sempre muito prestativo e paciente
quando excedi o horário de encerrar o expediente. Por todos aqueles que garantiram um
agradável ambiente de trabalho.

Ao Projeto MASP – Multi-Agent Systems development, coordenado pelo Prof. Dr.

Ricardo Bastos, o qual disponibilizou sua infra-estrutura (servidor, computadores pessoais e
sala de pesquisa). A utilização destes recursos contribui em diversos aspectos no
desenvolvimento deste trabalho.

Por fim, e não menos importante, aos patrocinadores do projeto – Convênio

Dell/PUCRS, Centro de Tecnologia XML Microsoft/PUCRS, MEC/SESu e FAPERGS, pelo
suporte financeiro oferecido. Sem este suporte nosso projeto não teria deixado de ser uma
idéia e se tornado real.

A todos, meus sinceros agradecimentos!

“Quando a gente pensa que sabe todas as respostas, vem a vida e muda todas as perguntas”

(Autor desconhecido)
 RESUMO

Programar um computador pode ser simples se você tem o conhecimento de como

identificar, organizar e modelar uma solução. Ou seja, se você sabe como escrever um
algoritmo. Não é fácil se você é um iniciante. Os alunos precisam aprender como eles podem
solucionar e organizar um problema usando um computador. Para isto, é necessário criar
situações baseadas em atividades de diferentes níveis de complexidade. Desenvolvemos uma
metodologia para organizar estas idéias, que foi aplicada por oito semestres. A idéia central da
metodologia é envolver os alunos em atividades em salas de laboratório. Esta abordagem é
boa para o aluno, mas causa sobrecarga de trabalho ao professor. O professor tem muitas
atividades durante as aulas. Seu tempo não é o suficiente para verificar as informações dos
alunos. As aulas possuem um período fixo durante a semana. Assim, os alunos precisam
trocar e-mails com o professor porque o tempo na sala de aula não é suficiente para discutir
todas as dúvidas dos alunos. O volume de informações gerado pelo processo de avaliação
cresce muito quando se usa uma metodologia baseada em aquisição de conhecimento como
fizemos. O número de exercícios e tarefas enviadas pelos alunos devem ser organizadas,
classificadas e avaliadas em um pequeno período de tempo. Isto exige muito tempo do
professor. Buscando superar estas restrições, desenvolvemos um ambiente para suportar
nossas aulas. Este trabalho apresenta o ambiente modelado para dar suporte às aulas de
Algoritmos e Programação de alunos iniciantes. Inicialmente criamos a metodologia e depois
selecionamos as ferramentas para suportá-la. Durante os quatro anos que usamos esta
metodologia, os recursos não estavam organizados em um ambiente formalizado. Assim,
decidimos juntar estas ferramentas em um ambiente virtual, tendo a metodologia como aporte.
As metodologias foram testadas em um ambiente sem apoio à gerência automática das
informações geradas. O ambiente PROOGRAMA tem por objetivo dar suporte às atividades
de ensino-aprendizagem baseado nas ferramentas e funcionalidades que permitem aos alunos
e professores trocarem informações, ampliar o processo de avaliação e aumentar as
possibilidades relacionadas as aulas presenciais, utilizando a abordagem de aulas virtuais. O
ambiente oferece diferentes áreas de trabalho, de acordo com o perfil do usuário, e um agente
para monitorar e gerenciar informações, denominado AMIGO. O agente informa o
desempenho do aluno ao professor em relação ao processo de avaliação. O agente irá fornecer
um conjunto de relatórios ao professor sobre os alunos. No momento, o AMIGO apenas
verifica se as respostas das atividades foram enviadas e se os arquivos recebidos não estão
vazios ou corrompidos. Poderemos organizar uma série de informações geradas pela nossa
metodologia através do ambiente, mas precisamos especificar como lidar com as preferências
e particularidades de cada aluno e ampliar o processo de avaliação. Para tal, iremos incluir
outros agentes na arquitetura do ambiente que irão nos auxiliar a tratar as informações para
termos um modelo de aluno funcionando como um assistente pessoal para os alunos e
professores. Um sistema multiagente possui esta característica, a qual nos permite especificar
outros agentes, de acordo com os objetivos e necessidades do usuário.

Palavras-chave: Algoritmos e Programação, ambientes virtuais de ensino-

aprendizagem, processo de desenvolvimento de software, agentes de software.
 ABSTRACT

To program a computer can be simple if you have the knowledge about how to
identify, to organise, and to model the solution. It means you know how to write an algorithm.
Nothing is simple if you are a beginner. The students need to learn how they can solve and
organise a problem solution using computer as a tool. So, it is important to create learning
situations based on tasks associated with different exercises complexity level. We developed a
methodology to organise these ideas. The methodology was applied during four years in a
row. The central process in our methodology is to involve the students in laboratory classes'
activities. This approach is good for the student, but it causes teachers' overwork. The teacher
has many activities during the classes. The time is not enough to check all students'
information. The classes occur in fixed periods during the week. So, the students have to
exchange e-mails with the teacher because classes' timetable are not enough to handle with
the student's doubts. The volume generated by the evaluation process increase a lot when we
use a methodology based on incremental knowledge acquisition like we do. The number of
exercises and tasks sent for the students must be organised, classified, and evaluated in a short
period of time. It demands much time by the teacher. Due to overcome those restrictions we
developed an environment to support our classes. This work presents our environment
designed to support our classes concerning Algorithms and Programming novice's
undergraduate students. We first created the methodology, and after that we selected the tools
need to supported it. During four years we use the methodology, the resources embedded into
a framework that was not formalised. After several experiences we decided to join the
resources into a virtual environment, having the methodology principles as uphold. We have
tested those tools without an environment that helps to handle automatically with the amount
information generated by students and the teacher. The PROOGRAMA environment aims to
support teaching/learning activities based on a set of resources and functionalities that allow
students and teacher to exchange information, about results from evaluating process, and
enlarge the possibilities related to the classes done by students and teacher in the same place
at the same time, by using the Virtual Classes approach. The PROOGRAMA offers different
working areas, according to the user that is performing tasks into the environment. The
AMIGO agent also informs the teacher about the student performance related to the
evaluation process. The AMIGO agent will provide a set of reports about each student and all
the class. At this moment, the AMIGO just has conditions to check if the task was attended, if
the file sent by the students contains the type of file expected by the teacher. We can organize
the set of information generated by our methodology into the framework. But we need to
improve the way we handle with the students' preferences and particularities, and improve the
support for the teacher evaluation process. So, if we include more agents into the
PROGRAMA architecture these new agents can helps us to handle with the set of information
that will allow us to have a student model working like personal assistants for students, and
teachers. A Multiagent System has this propriety that able us to include more agents or take it
out according the designer goals, and users necessities.

Key-words: Algorithms and Programming classes, virtual learning environments,

software process development, software agents.
 LISTA DE FIGURAS

Figura 2.1 - Ferramenta Configurador para um grupo específico [NET03] ........................... 26

Figura 2.2 - Menu de opções do ambiente Sala Individual [NET03] ..................................... 27
Figura 2.3 - Interface do aprendiz com destaque ao menu de funcionalidades [FUK01] ....... 31
Figura 2.4 - Interface do módulo Schedule [LOT99] ............................................................ 36
Figura 2.5 - Ferramentas do ambiente WebCT [BAC00] ...................................................... 39
Figura 2.6 - Arquitetura de um agente reativo [RUS95]........................................................ 52
Figura 2.7 - Arquitetura de um agente cognitivo [RUS95] .................................................... 54
Figura 2.8 - Camadas (ou níveis) da plataforma J2EE ....................................................... 58
Figura 2.9 - Exemplo Hello World: código-fonte da página HTML [COP03] ....................... 61
Figura 2.10 - Exemplo Hello World: código-fonte da classe servlet [COP03] ....................... 61
Figura 2.11 - Exemplo Contador: código-fonte da página JSP [COP03] ............................... 63

Figura 3.1 – Exemplo de mapa conceitual parcial dos conceitos da disciplina Lapro ............ 68

Figura 4.1 - Tela de acesso à funcionalidade de formação de uma turma .............................. 74

Figura 4.2 - Tela de acesso ao ambiente PROOGRAMA...................................................... 76
Figura 4.3 - Tela principal de acesso a área de trabalho do aluno .......................................... 78
Figura 4.4 - Organização das ferramentas do PROOGRAMA em módulos .......................... 79
Figura 4.5 - Visualização de um compromisso ..................................................................... 82
Figura 4.6 – Entrega da resposta de uma atividade por um aluno integrante de um grupo ..... 89

Figura 5.1 – Opções de configuração de monitoramento da ferramenta Agenda de

compromissos............................................................................................................... 93
Figura 5.2 – Local para especificação do prazo de notificação de um compromisso ............. 95
Figura 5.3 - Opções de configuração de monitoramento da ferramenta Atividades ............... 96
Figura 5.4 – Arquitetura interna do agente AMIGO ............................................................. 97
Figura 5.5 - Diagrama de Casos de Uso do AMIGO ............................................................. 99
Figura 5.6 - Diagrama de Atividades do requisito Monitorar compromissos ....................... 100
Figura 5.7 - Diagrama de Atividades do requisito Comunicar resultado do monitoramento de
compromisso .............................................................................................................. 100

Figura 6.1 - Fluxo de execução das atividades da fase Visão .............................................. 104
Figura 6.2 - Fluxo de execução das atividades da Etapa 1 da fase Planejamento................. 109
Figura 6.3 - Diagrama de Pacotes do ambiente PROOGRAMA ......................................... 111
Figura 6.4 - Diagrama de Casos de Uso da ferramenta Agenda de compromissos ............... 112
Figura 6.5 - Arquitetura preliminar do ambiente PROOGRAMA ....................................... 113
Figura 6.6 - Arquitetura interna preliminar do agente AMIGO ........................................... 113
Figura 6.7- Exemplo de interface prototipada em forma de imagem ................................... 115
Figura 6.8 - Arquitetura do ambiente PROOGRAMA: visão simplificada dos componentes
................................................................................................................................... 118
Figura 6.9 - Artefatos a serem produzidos pelo projeto....................................................... 119
Figura 6.10 - Diagrama de atividades do requisito Incluir compromisso ............................. 120
Figura 6.11 – Fluxo de execução das atividades da Etapa 2 da fase Planejamento .............. 121
Figura 6.12 - Diagrama de classes conceituais do ambiente ................................................ 122
Figura 6.13 - Tabelas do banco de dados do ambiente ........................................................ 123
Figura 6.14 - Fluxo de execução das atividades da fase Desenvolvimento........................... 125
Figura 6.15 - Atividade realizada durante a fase Estabilização ........................................... 127
Figura 6.16 - Fluxo de execução das atividades da fase Implantação .................................. 128

Figura 7.1 - Arquitetura de integração proposta .................................................................. 136

 LISTA DE QUADROS

Quadro 2.I - Principais características dos ambientes estudados ........................................... 43

Quadro 4.I - Relação das funcionalidades para criação da infra-estrutura do ambiente.......... 75

Quadro 4.II - Relação das funcionalidades disponibilizadas na tela de acesso ao ambiente ... 77
Quadro 4.III - Funcionalidades das ferramentas do módulo Informações dos Alunos ............ 80
Quadro 4.IV - Funcionalidades das ferramentas do módulo Comunicação Pública .............. 84
Quadro 4.V - Funcionalidades das ferramentas do módulo Comunicação Direta.................. 86
Quadro 4.VI - Funcionalidades das ferramentas do módulo Material do Curso .................... 90
Quadro 4.VII - Funcionalidades da ferramenta AMBAP ...................................................... 91

Quadro 6.I – Exemplos de requisitos não-funcionais especificados .................................... 110

Quadro 6.II – Comparação entre as características oferecidas pelos ambientes e o
PROOGRAMA .......................................................................................................... 114
Quadro 6.III – Principais resultados da reunião de fechamento desta etapa do projeto ........ 129
 LISTA DE SIGLAS

AMBAP AMBiente de Aprendizado de Programação

AmCorA Ambiente Cooperativo de Aprendizagem

AMIGO Agente para MonItorar e Gerenciar infOrmações

API Application Programming Interface

ASD Agile Software Development

BD Banco de Dados

CC Ciência da Computação

CGIs Common Gateway Interfaces

CNPq Conselho Nacional de Desenvolvimento Científico e Tecnológico

CTXML Centro de Tecnologia XML Microsoft/PUCRS

EAD Ensino a Distância

ES Engenharia de Software

FAQ Frequently Asked Questions

FTP File Transfer Protocol

GAIA Grupo de Aplicação da Informática na Aprendizagem /

Grupo de Aplicação da Inteligência Artificial

GIE/FACIN Grupo de Informática na Educação da Faculdade de Informática

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

HTTPS HyperText Transfer Protocol Security

IA Inteligência Artificial

IAD Inteligência Artificial Distribuída

IC Iniciação Científica

IE Informática na Educação

IHMC Institute for Human and Machine Cognition

ILA Interpretador de Linguagem Algorítmica

IRC Internet Relay Chat

IIS Internet Information Server

J2EE Java 2 Platform Enterprise Edition

J2SE Java 2 Platform Standard Edition

JSP Java Server Pages

JVM Java Virtual Machine

LN Lotus Notes

MCs Mapas Conceituais

Moonline Monitoria On-Line

MSF Microsoft Solutions Framework

ODBC Open-DataBase-Connectivity

PDS Processo de Desenvolvimento de Software

PEP Plano de Estudo e Pesquisa

POP Post Office Protocol

PUC-Rio Pontifícia Universidade Católica do Rio de Janeiro

PUCRS Pontifícia Universidade Católica do Rio Grande do Sul

RMI Remote Method Invocation

RUP Rational Unified Process

SA Seminário de Andamento

SGBD Sistema de Gerenciamento de Banco de Dados

SMAs Sistemas Multiagentes

SMTP Simple Mail Transfer Protocol

SQL Structured Query Language

TCP/IP Transfer Control Protocol / Internet Protocol

TI-II Trabalho Individual II

UFES Universidade Federal do Espírito Santo

UML Unified Modeling Language

URLs Uniform Resource Locations

WebCT Web Course Tools

WWW World Wide Web

XML eXtensible Markup Language

XP Extreme Programming
 SUMÁRIO

1 INTRODUÇÃO .......................................................................................................... 16
1.1 Problema e motivação .......................................................................................... 17
1.2 Questão de pesquisa e objetivos ............................................................................ 18
1.3 Estrutura do texto ................................................................................................. 20

2 APORTE TEÓRICO E TECNOLÓGICO ................................................................... 22

2.1 Ambientes virtuais de ensino-aprendizagem ......................................................... 22
2.1.1 AmCorA ....................................................................................................... 24
2.1.2 AulaNet ........................................................................................................ 29
2.1.3 LearningSpace .............................................................................................. 34
2.1.4 WebCT ......................................................................................................... 38
2.1.5 Uma breve análise comparativa dos ambientes .............................................. 41
2.2 Processo de desenvolvimento de software............................................................. 45
2.2.1 Microsoft Solutions Framework .................................................................. 47
2.2.2 Processo de desenvolvimento de software educacional.................................. 50
2.3 Agentes de software ............................................................................................. 51
2.4 Recursos tecnológicos .......................................................................................... 55
2.4.1 Java .............................................................................................................. 56
2.4.2 Servlets ......................................................................................................... 59
2.4.3 Java Server Pages......................................................................................... 62
2.4.4 Tomcat ......................................................................................................... 63
2.4.5 MySQL......................................................................................................... 64

3 A METODOLOGIA UTILIZADA PARA SUPORTE AO PROCESSO DE ENSINO-

APRENDIZAGEM ............................................................................................................. 67

4 O AMBIENTE PROOGRAMA .................................................................................. 73

4.1 Módulo Informações dos Alunos........................................................................... 79
4.2 Módulo Comunicação Pública ............................................................................. 81
4.3 Módulo Comunicação Direta ............................................................................... 85
4.4 Módulo Material do Curso ................................................................................... 87
4.5 Módulo Teste de Algoritmos ................................................................................. 91

5 O AGENTE AMIGO .................................................................................................. 92

5.1 As funcionalidades do agente ............................................................................... 92
 5.2 A modelagem e funcionamento do agente ............................................................. 97

6 O PROCESSO DE DESENVOLVIMENTO DO AMBIENTE PROOGRAMA E DO

AGENTE AMIGO ............................................................................................................ 102
6.1 Visão (Envisioning) ............................................................................................ 103
6.2 Planejamento (Planning) .................................................................................... 109
6.3 Desenvolvimento (Developing) .......................................................................... 124
6.4 Estabilização (Stabilizing) .................................................................................. 127
6.5 Implantação (Deploying) .................................................................................... 128

7 CONSIDERAÇÕES FINAIS .................................................................................... 130

7.1 Contribuições ..................................................................................................... 131
7.2 Limitações e restrições ....................................................................................... 133
7.3 Trabalhos futuros................................................................................................ 135

REFERÊNCIAS BIBLIOGRÁFICAS............................................................................... 138

APÊNDICE A – Manual do usuário: Professor ................................................................. 150

APÊNDICE B – Visão e Escopo do Projeto PROOGRAMA ............................................ 185
APÊNDICE C – Estrutura e Plano do Projeto PROOGRAMA .......................................... 199
APÊNDICE D – Especificação Funcional do Projeto PROOGRAMA............................... 217
APÊNDICE E – Especificação da Interface Gráfica do Projeto PROOGRAMA................ 263
APÊNDICE F – Inconsistências identificadas nos protótipos ............................................ 284
APÊNDICE G – Guia de configuração do ambiente PROOGRAMA ................................ 287
APÊNDICE H – Publicações do Projeto PROOGRAMA .................................................. 290
 16

1 INTRODUÇÃO

O aprendizado de programação é um desafio para muitos professores e alunos

principiantes de vários cursos de graduação. As disciplinas de Algoritmos e Laboratório de
Programação formam o binômio central do ensino de programação de principiantes. Os
nomes das disciplinas e a seriação das mesmas variam (ambas no primeiro semestre,
Algoritmos no primeiro, Laboratório de Programação no segundo, etc.), porém a idéia geral
permanece, a de desenvolver habilidades de resolver problemas com o uso do computador e
desenvolver habilidades cognitivas amplas, tais como análise, síntese e aplicação. Ambas
habilidades são necessárias ao processo de abstração que permite ao aluno receber um
problema e propor uma alternativa de solução.

Muito se tem feito para estimular os estudantes a aprenderem e manterem o interesse,

procurando não deixá-los desanimar, apesar das dificuldades [CHA01]. No entanto, mesmo
com todo o esforço, muitas questões permanecem em aberto, especialmente a questão
envolvendo a heterogeneidade da formação dos alunos e a dedicação extraclasse necessária
para a fixação dos conteúdos trabalhados em aula.

Segundo [TOB01], os estudantes encontram dificuldades no aprendizado de

programação por razões diversas, dentre estas se destaca a preocupação excessiva com
detalhes de sintaxe da linguagem usada, a falta de uma visão daquilo que se quer solucionar, a
idealização de soluções adequadas ao problema proposto, a organização dessas soluções em
passos seqüenciais e a abstração do funcionamento dos mecanismos escolhidos.

As dificuldades encontradas podem ser associadas ao alto grau de repetência nas

disciplinas introdutórias. Relatos de professores e alunos apontam as dificuldades
demonstradas nestas disciplinas, onde se destaca o domínio do raciocínio lógico e a resolução
de problemas. Conforme [GIR02], outro aspecto apontado como causa das repetências e
evasão, principalmente nos alunos de cursos noturnos, é o alto envolvimento com o trabalho,
a impossibilidade de comparecimento às atividades presenciais da disciplina e o pouco
 17

envolvimento com as tarefas complementares extraclasse (trabalhos e exercícios). Geralmente

a reprovação está ligada diretamente ao fato dos alunos não se envolverem nas tarefas
necessárias para o bom entendimento e fixação dos conteúdos destas disciplinas.

Segundo [MUS01], diferentes pesquisas apontam como alternativa para auxiliar na

resolução deste problema o desenvolvimento de ambientes computadorizados de apoio ao
ensino-aprendizagem de programação. A tendência observada nestes ambientes é utilizar
técnicas de Inteligência Artificial (IA), a fim de prover a estes sistemas capacidade de
adaptação ao contexto e de personalização do ambiente de acordo com as características dos
alunos, além de permitir um alto grau de interatividade entre o ambiente e os usuários. A
introdução de técnicas de IA nestes ambientes tem, também, a finalidade de propiciar
mecanismos de modelagem do processo de ensino, assim como ter a possibilidade de inferir o
provável estado cognitivo corrente do estudante. É neste contexto que este projeto de pesquisa
se enquadra.

1.1 Problema e motivação

Ao longo dos últimos oito semestres a professora orientadora deste trabalho vêm
utilizando recursos computacionais, tais como e-mail, FTP (File Transfer Protocol) e páginas
Web, como elementos de extensão e mediação das atividades da sala de aula presencial,
inseridos no contexto de sua metodologia de ensino-aprendizagem. O uso destes recursos
gera um volume de informações que necessitam ser gerenciadas manualmente pela
professora, levando em conta que os recursos são independentes uns dos outros e não há um
controle automático das informações recebidas dos alunos. A demanda aumenta, em especial,
em épocas próximas a entregas de trabalhos e exercícios, em função da professora utilizar o e-
mail como canal de comunicação para entrega dos resultados das atividades e esclarecimento
de dúvidas. Segundo [DRU03], esta sobrecarga de trabalho dos professores é inerente a
utilização de um ambiente de Ensino a Distância (EAD) como apoio às atividades de ensino,
tanto em situações presenciais como não-presenciais, devido a grande quantidade de
informações a serem acompanhadas no decorrer do andamento da disciplina.

Pela necessidade de ter um ambiente centralizador dos recursos computacionais

usados e que lhe provesse os mecanismos de gerência desejados, a professora orientadora
 18

adotou o ambiente de EAD disponibilizado na Universidade ao qual este trabalho está

vinculado (PUCRS – Pontifícia Universidade Católica do Rio Grande do Sul), o WebCT
(Web Course Tools) [WEB00]. A professora utilizou o ambiente por seis meses, com seus
alunos da turma de Algoritmos e Estruturas de Dados I, do segundo semestre letivo de 2002.
Os resultados da experiência foram satisfatórios: a professora conseguiu reunir em um único
local todas as informações relacionadas à disciplina e, com isto, reduzir sua carga de trabalho
gerencial dos materiais; e os alunos usufruíram os recursos consultando constantemente a área
disponibilizada para a disciplina. Apesar da satisfação com WebCT, a professora sentiu a
necessidade de poder incluir às funcionalidades e recursos já disponibilizados por este
ambiente outros mecanismos que permitam auxiliar no processo de avaliação dos seus alunos.
Por ser um ambiente proprietário, o WebCT não atende esta necessidade.

Neste cenário, identificou-se a oportunidade de prover uma solução própria que

centralize os recursos utilizados pela professora e gerencie as informações geradas da
interação da professora com os alunos (e vice-versa) durante a utilização deste ambiente.
Inicialmente, estas informações deveriam dizer respeito, em especial, aquelas relacionadas a
disponibilização e envio de respostas às atividades disponibilizadas no contexto da disciplina
que está sendo ministrada. Quanto à gerência destas informações, a professora expressou seu
desejo de possuir a sua disposição um agente de software, passível de configuração, buscando
oferecer-lhe mecanismos que lhe permitam acompanhar o envolvimento dos alunos com a
disciplina.

Com a adoção desta solução, a professora visa reduzir sua carga de trabalho
operacional, no que tange a organização das materiais enviados pelos alunos, bem como
automatizar o processo de notificação aos alunos de compromissos vinculados à disciplina,
buscando lembrá-los de seus comprometimentos com a mesma.

1.2 Questão de pesquisa e objetivos

Para solucionar o problema descrito, definiu-se o objetivo principal desta dissertação,

de definir e apresentar o protótipo de um agente para monitorar e gerenciar informações
referentes aos compromissos e às atividades de uma disciplina que utiliza o ambiente
PROOGRAMA como recurso de apoio às atividades do processo de ensino-aprendizagem.
 19

Este agente foi denominado AMIGO, Agente para MonItorar e Gerenciar infOrmações. O
ambiente PROOGRAMA foi proposto e definido neste trabalho, buscando fornecer subsídios
para a criação de um ambiente de apoio ao processo de ensino-aprendizagem próprio que
permita a inclusão de outros agentes de software para auxiliar no processo de avaliação dos
alunos. A definição do PROOGRAMA se deu baseada nas características e funcionalidade de
maior relevância providas pelos trabalhos correlatos analisados. O desenvolvimento do
ambiente está relacionado a um projeto de pesquisa de mesmo nome que o ambiente. Este
projeto será elaborado em parceria com grupos de pesquisa em Inteligência Artificial
Aplicada a Educação parceiros do grupo ao qual este trabalho está vinculado, o Grupo de
Informática na Educação1 da Faculdade de Informática (GIE/FACIN), da PUCRS.

A fim de apoiar o objetivo principal e responder a questão de pesquisa levantada,

quais funcionalidades e características deve ter um agente para fazer a gerência e
monitoramento de informações através de um ambiente de EAD tendo como base o ambiente
PROOGRAMA, um conjunto de objetivos específicos foram estipulados, quais sejam:

• Especificar os requisitos e funcionalidades do agente;

• Especificar as mensagens que o agente deverá enviar ao aluno e ao professor em

função da proposta pedagógica do ambiente;

• Definir o ambiente de atuação do agente;

• Definir como o agente será percebido pelo usuário em seu ambiente de trabalho;

• Definir o agente de tal forma que seja possível ser configurado, de acordo com as
preferências do usuário;

• Elaborar um protótipo para testar as definições do agente;

• Contribuir com o Projeto PROOGRAMA, propondo a arquitetura, as ferramentas e

funcionalidades que irão compô-lo futuramente.

1
Consulte a página do grupo (http://www.inf.pucrs.br/~giraffa/gie/index.html) para maiores informações.
 20

1.3 Estrutura do texto

Neste trabalho está descrito todo o processo de pesquisa, desde o levantamento do

referencial teórico e estudo dos trabalhos correlatos até a finalização do desenvolvimento dos
protótipos do ambiente PROOGRAMA e do agente AMIGO, dividido em sete capítulos,
organizados logicamente facilitando a compreensão da pesquisa como um todo.

No Capítulo 2 fornece-se subsídios para a compreensão dos conceitos que serviram de

aporte para o desenvolvimento desta pesquisa. Na primeira seção apresenta-se alguns aspectos
gerais sobre ambientes virtuais de ensino-aprendizagem e os trabalhos correlatos estudados:
AmCorA (Ambiente Cooperativo de Aprendizagem) [MEN99], AulaNet [FUK00],
LearningSpace [LOT99] e WebCT [WEB00], encerrando com uma breve análise comparativa
entre as principais características destes ambientes. Na próxima seção, discorre-se sobre o
processo de desenvolvimento de um software e apresenta-se o framework para
desenvolvimento de projetos de tecnologia proposto pela Microsoft, o Microsoft Solutions
Framework (MSF), adotado como referência para o desenvolvimento do ambiente e do
agente. Também se destaca algumas questões relevantes em relação ao desenvolvimento de
softwares educacionais. Na terceira seção define-se o conceito de agente de software e
descreve-se suas principais características. Na última seção deste capítulo apresenta-se as
características dos recursos tecnológicos adotados para a implementação dos protótipos do
ambiente e do agente.

A metodologia utilizada para suporte ao processo de ensino-aprendizagem que foi

usada como referência para a modelagem e definição do ambiente e do agente é apresentada
no Capítulo 3.

No Capítulo 4 apresenta-se o ambiente proposto, descrevendo-se as características

gerais, os perfis de usuário e as ferramentas e funcionalidades do mesmo. Cada uma das cinco
seções do capítulo apresenta um conjunto de ferramentas, as quais foram conceitualmente
agrupadas de acordo com seus objetivos e finalidades.
 21

No Capítulo 5 apresenta-se o agente AMIGO, que constitui a proposta em si deste

trabalho. Na primeira seção descreve-se as funcionalidades oferecidas pelo agente e na
segunda, os aspectos relacionados à sua modelagem e implementação.

O processo de desenvolvimento do ambiente e do agente é descrito no Capítulo 6. Em

cada uma das cinco seções do capítulo descreve-se as atividades relacionadas à respectiva fase
de projeto, as quais seguiram as sugestões propostas pelo MSF. Também são descritas as
decisões de projeto tomadas e suas justificativas.

No Capítulo 7 estão as considerações finais relativas a este trabalho. Também são

apresentadas as limitações e restrições identificadas, bem como os trabalhos futuros que
podem vir a ser desenvolvidos para dar continuidade a esta pesquisa.

Ao final deste volume estão listadas as referências bibliográficas utilizadas nesta

dissertação e, na seqüência, o conjunto de apêndices que organizam detalhadamente as
especificações do projeto e os resultados obtidos.
 22

2 APORTE TEÓRICO E TECNOLÓGICO

O levantamento do referencial teórico e tecnológico representa uma importante etapa

de uma pesquisa [YIN01], uma vez que é nesta etapa que muitos conceitos são esclarecidos e
compreendidos, bem como tecnologias são conhecidas. Como resultado, em geral, elegem-se
os conceitos e tecnologias que servirão de referência para a condução da pesquisa, bem como
de apoio para as tomadas de decisão. Desta forma, este capítulo apresenta o referencial teórico
e tecnológico utilizado como aporte para a pesquisa realizada.

2.1 Ambientes virtuais de ensino-aprendizagem

Os ambientes virtuais de ensino-aprendizagem têm por objetivo, essencialmente,

servir de apoio às aulas presenciais e/ou dar suporte a cursos a distância, oferecendo a
professores e alunos um conjunto de funcionalidades e ferramentas que lhes proporcionem e
facilitem a comunicação, acesso ao material de apoio, avaliação e acompanhamento das
atividades realizadas [MAR02], entre outras características. Os vários ambientes virtuais de
ensino-aprendizagem disponíveis podem ser classificados segundo diversas modalidades,
conforme o objetivo de seu uso. Segundo [SAN99], as modalidades são as seguintes:

• Aplicações hipermídia, que abordam cursos multimídia com objetivos

educacionais definidos, tarefas a serem realizadas pelos alunos, formas de
avaliação e suporte para comunicação com os pares e com o professor, e cursos no
formato hipertexto, composto de páginas Web, seguindo o modelo de livro-texto,
normalmente sem tutoria;

• Sites educacionais, que reúnem um conjunto de funcionalidades, tais como

biblioteca de software educacional, espaços para comunicação, software para
download, links para outras páginas Web e jornais. Como exemplo, pode-se citar os
sites Study Web [STU03], Kidlink-Br [KID03] e Escolanet [ESC03];
 23

• Sistemas de autoria para cursos a distância, os quais permitem a criação de

recursos utilizando a Internet como ferramenta de autoria, como exemplo tem-se o
LearningSpace [LOT99] e o WebCT [WEB00];

• Salas de aula virtuais, as quais estendem o conceito dos sistemas de autoria, pois
ampliam a interatividade e cooperação, por exemplo, tem-se o AulaNet [FUK00] e
o ClasseVirtual [MEL98];

• Frameworks para aprendizagens cooperativas, que permitem o

desenvolvimento de ambientes customizáveis integrando ferramentas
disponíveis. Cita-se como exemplo Habanero [NCS03] e Belvedere [BEL03];

• Ambientes distribuídos para aprendizagem cooperativa, tal como o AmCorA

[MEN99].

Estes ambientes utilizam diferentes tipos de recursos, desenvolvidos em diversas

linguagens e adotando diferentes tecnologias, o que muitas vezes pode impedir um grupo de
usuários de conseguir usufruir os mesmos por não ter recursos compatíveis a sua disposição.
Desta forma, um professor precisa conhecer os requisitos de hardware e software do ambiente
virtual de ensino-aprendizagem que pretende adotar antes de decidir pelo seu uso. Além disto,
o ambiente precisa prover um conjunto de funcionalidades que permitam a aplicação da
metodologia escolhida pelo professor para desenvolver o trabalho junto com os alunos, bem
como o gerenciamento e análise de todos os aspectos envolvidos no ciclo ensino-
aprendizagem [MAC99].

Segundo [HAC99], ainda se considera importante que as funcionalidades oferecidas

sejam de fácil manipulação e que não exijam do professor e dos alunos grandes
conhecimentos sobre tecnologia, a não ser sobre a utilização de um navegador e princípios
básicos de uso de um computador. Também se espera que a execução das atividades através
dos ambientes não exija muito investimento de tempo.

Neste contexto, estudou-se quatro ambientes, AmCorA, AulaNet, LearningSpace e

WebCT, com o objetivo de identificar suas características e as formas de monitoramento e
 24

gerenciamento de informação que oferecem. A escolha destes ambientes se deu devido ao fato
de existir cultura e experiência no GIE/FACIN da PUCRS com estas ferramentas. Também,
em razão da possibilidade de se explorar aspectos que vão ao encontro da proposta
construtivista de trabalhar a produção e aquisição de conhecimento, proposta esta adotada
pela professora orientadora deste trabalho na condução de suas aulas (Detalhes sobre a
metodologia de ensino-aprendizagem adotada pela professora são apresentados no Capítulo
3). Apresenta-se a seguir as principais características e funcionalidades dos ambientes
estudados e, em seguida, uma breve análise comparativa dos mesmos.

2.1.1 AmCorA

O AmCorA2, proposto por [MEN99], é um conjunto de sistemas idealizados para

apoiar a aprendizagem em ambiente cooperativo utilizando a Internet. Suas características,
bem como a implementação das mesmas está em constante processo de atualização. A
proposta segue a abordagem construtivista e pretende prover ao aluno condições para que este
resolva problemas de forma cooperativa.

O sistema, disponível em nova versão desde maio de 2003, possibilita a organização

de grupos envolvidos no processo de aprendizagem, os quais podem se desdobrar em
subgrupos, com um número ilimitado de subdivisões [NET03]. Isto implica que, por exemplo,
para estudar um determinado assunto, podem ser criados grupos de trabalho formados por um
conjunto de pessoas interessadas neste assunto. Sendo que cada grupo pode ainda ser
subdividido em subgrupos de modo a contemplar a divisão de tarefas [GAI02]. Os grupos
podem discutir os assuntos conforme melhor lhes convêm.

O ambiente oferece os seguintes perfis de usuário:

• Administrador: registra o ambiente e configura sua instalação, bem como cria os
perfis dos usuários, baseado nos direitos de acesso aos recursos do ambiente;

2
Em sua nova versão, o AmCorA está disponível em três instâncias, instaladas em diferentes servidores e
funcionando de forma independente uma da outra. Apesar do código binário do sistema ser o mesmo para ambas
as instâncias, as interfaces e funcionalidades disponibilizadas diferem entre si, bem como também se difere o
público-alvo destas instâncias. Neste contexto, as informações apresentadas nesta seção dizem respeito à
instância que possui como público quase que exclusivamente usuários vinculados a disciplinas oferecidas pela
Universidade Federal do Espírito Santo (UFES). Isto se deve ao fato de se ter acesso apenas a esta instância, a
qual está disponível em http://www.gaia.ufes.br/amcora.
 25

• Coordenador: gerencia os participantes de um determinado grupo, e organiza e

mantém o conteúdo e atividades deste mesmo grupo;

• Membro: usufrui os recursos do sistema, sendo considerado “aluno” das

atividades dos grupos.

Os usuários ainda podem assumir o papel denominado Anônimo, o qual solicita a

criação de um grupo ou a participação em um grupo já existente. No caso de solicitar a
criação de um grupo, este usuário também é denominado Fundador do grupo. Em geral, o
Fundador é o primeiro Coordenador do grupo.

Segundo [GAI02; MENEZ02], o AmCorA apresenta quatro áreas distintas: a Pública,

a individual, a de grupo e a do Administrador. Como é usado o conceito de sala de aula para
diferenciar a área individual de um usuário da área de um grupo que este pertence, estas serão
chamadas, respectivamente, de área Sala Individual e Sala do Grupo, para facilitar suas
identificações. Para todas as áreas, exceto a Pública, existe um controle de acesso, baseado na
identificação do usuário através do seu e-mail e da senha fornecida. Sobre a área Pública, é
através desta área que ocorre a solicitação de criação de um novo grupo, bem como acréscimo
de um novo membro no grupo.

Para cada perfil de usuário, existe um conjunto de funcionalidades e ferramentas

previamente disponibilizadas e outras que podem ser configuradas, caso o usuário assim
deseje. Ou seja, o AmCorA possui um menu de ferramentas configuráveis. Através da
ferramenta Configurador (Vide Figura 2.1) o usuário pode escolher quais ferramentas deseja
incluir no seu menu e a seqüência que estas ferramentas devem ser dispostas. Além da
possibilidade destas ferramentas poderem ser configuradas, ainda é possível atribuir diferentes
nomes às mesmas e às funcionalidades. Isto se deve ao fato do AmCorA poder ser
configurado para diferentes domínios de atuação [NET03]. Por exemplo, a funcionalidade que
permite a disponibilização de informações pessoais sobre o usuário é chamada Perfil, mas
pode ter seu nome configurado para Identidade Pessoal, Ficha de Apresentação ou outro a
escolha do Administrador, conforme melhor se adequar ao contexto que será usada. Cabe
ressaltar que, para os grupos, o Coordenador é o responsável por configurar o menu de
ferramentas, selecionando aquelas eleitas importantes para os objetivos estabelecidos.
 26

Figura 2.1 - Ferramenta Configurador para um grupo específico [NET03]

A área Sala Individual, cujo menu de opções é apresentado na Figura 2.2, é a área
particular de um usuário. Segundo [NET03], esta área oferece as seguintes funcionalidades e
ferramentas:

• Identificação Pessoal: disponibiliza as informações do usuário, como, por

exemplo, nome, e-mail, áreas de interesse, entre outras. Estas informações só serão
divulgadas caso sejam editadas pelo usuário.

• Webliografia: permite que o usuário crie um cadastro de links particulares.

• Estante: permite a criação de um repositório de arquivos particulares. É possível

criar pastas para organizar os arquivos.

• Escaninho: possibilita acesso aos documentos enviados ou compartilhados por

outros usuários.
 27

Figura 2.2 - Menu de opções do ambiente Sala Individual [NET03]

• Leitor de E-mails: utilizada para verificar e enviar e-mails. Pode-se configurar

qualquer endereço de e-mail, desde que o servidor provenha o serviço POP3. Ou
seja, que dê suporte ao Post Office Protocol (POP).

• BigBrother: é o serviço de mensagens instantâneas, no qual o usuário pode

visualizar quem está conectado, enviar e ler estas mensagens. Para saber que existe
uma nova mensagem, existe um mecanismo (aparecimento de um mensagem que
aparece e desaparece de tempo em tempos) disponível no canto superior do menu,
o qual indica que há uma nova mensagem.

• Meus Grupos: permite ao usuário navegar entre os grupos ao qual está

cadastrado, acessando o menu de opções do grupo selecionado. Caso o usuário seja
o Coordenador do grupo, este também pode criar ou excluir subgrupos.

• Configurador: permite a configuração dos itens que serão exibidos no menu. É

possível incluir, excluir ou mudar a ordem das opções escolhidas.

• Sair: encerra o uso do AmCorA, retornando a área Pública.

A área Sala do Grupo provê algumas funcionalidades semelhantes às da área Sala

Individual, quais sejam: (i) Perfil do Grupo, onde somente o coordenador do grupo possui
permissão para editar este perfil; (ii) Webliografia; (iii) Estante, repositório de arquivos do
 28

grupo, para a qual qualquer usuário pode submeter um arquivo para divulgação, mas somente
o Coordenador é quem pode excluí-los; (iv) Escaninho, que pode ser visto como um local
para entrega de trabalhos no contexto de uma aula ou curso [NET03]; (v) BigBrother; (vi)
Meus Grupos; (vii) Configurador; (viii) Minha Sala, permitindo que o usuário retorne a sua
área particular; e (ix) Sair. Estas funcionalidades e ferramentas diferenciam-se por atender a
um grupo específico e não apenas a um único usuário.

As demais funcionalidades oferecidas por esta área são as seguintes [NET03]:

• Participantes: é a área de trabalho do coordenador do grupo. Nesta área, ele pode

gerenciar os participantes e os subgrupos do seu grupo, ativando-os ou
suspendendo-os e até mesmo promovê-los a coordenadores dos subgrupos.

• Correspondência: permite enviar mensagens via e-mail para os participantes do

grupo.

• Mural: apresenta os últimos anúncios (avisos e recados) disponibilizados. Permite

a busca a um anúncio específico através de palavras-chave e temas. O mural tem a
função de ser o meio de divulgação das notícias que interessam a um grupo
específico. Para saber se há novidades no mural, o usuário deve consultá-lo
periodicamente, pois não há nenhum tipo de mecanismo que os comunique da
disponibilidade de novidades.

• Fórum: possibilita a discussão de temas específicos, de maneira a encadear

mensagens em forma de árvore.

• Chat: disponibiliza salas de bate-papo para os participantes de um grupo

conversarem síncronamente (Segundo [NET03], o registro destas conversas esta
sendo armazenado no servidor da aplicação, mas ainda não pode ser salvo pelos
usuários).
 29

A última área, a do Administrador, permite que o responsável pelo sistema tenha

acesso às solicitações de novos grupos assim como dados que lhe permitam analisar o
desempenho do sistema. Segundo [MENEZ02], no momento encontra-se implementada
somente a funcionalidade para autorização da criação de novos grupos, que engloba o
recebimento do pedido de criação deste grupo, sua criação em si e a notificação para os
interessados de que já possuem acesso ao ambiente. O Administrador ainda tem acesso aos
diversos módulos de instalação e configuração das ferramentas que compõem o AmCorA. Ele
é o responsável por configurar as ferramentas para disponibilizá-las aos usuários, permitindo
assim, que estes apenas as escolham através da ferramenta Configurador.

Segundo [NOB02], por se tratar de um facilitador de aprendizagem, o AmCorA

também possui algumas ferramentas inteligentes incorporadas ao ambiente. Dentre estas,
destaca-se: Sábia, para apoio à revisão bibliográfica, onde a principal funcionalidade é a
indexação de documentos; Moonline (Monitoria On-Line) [GAV98; GAV00], que é uma
ferramenta de apoio ao esclarecimento de dúvidas relacionadas ou não a um conteúdo
específico através de perguntas e respostas; e QSabe [MEN98; PES00], ferramenta que
gerencia a troca cooperativa de informações, incentivando a divulgação e troca de
conhecimento. Também é possível configurar a ferramenta Agenda de Tarefas, a qual
permite a organização de compromissos particulares do usuário, e acessar uma breve
descrição das funcionalidades do ambiente, semelhante a um help on-line.

2.1.2 AulaNet

O AulaNet3 é um ambiente para a criação, aplicação e administração de cursos

baseado na Web. Seu desenvolvimento iniciou-se em 1997, no Laboratório de Engenharia de
Software da Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). Baseia-se nas
relações de trabalho cooperativo que se manifestam nas interações dos aprendizes com seus
instrutores, com outros aprendizes e com os conteúdos didáticos [FUK01]. Possui uma
abordagem groupware4 e auxilia o docente na tarefa de disponibilizar o conteúdo de seu curso
na Internet. Segundo [FUK01], o conteúdo é separado da navegação, fazendo com que os
docentes só se preocupem com a produção dos conteúdos didáticos usando suas ferramentas

3
Estudou-se a versão 2.0. Maiores informações em http://www.les.inf.puc-rio.br/groupware.
4
Segundo [FUK02], groupware pode ser entendido como a tecnologia baseada em mídia digital que dá suporte
às atividades de pessoas organizadas em grupos que podem variar em tamanho, composição e local de trabalho.
 30

habituais, como o editor de textos, e deixem por conta do ambiente a gerência e a navegação
dos aprendizes.

Em cursos do AulaNet, os docentes podem assumir basicamente três papéis:

• Coordenador: responsável por estruturar o curso, selecionando e configurando

quais serviços serão disponibilizados, definindo a ementa, a metodologia e outras
informações relacionadas ao curso;

• Docente co-autor: responsável por produzir e inserir os conteúdos didáticos nos

serviços selecionados pelo coordenador;

• Instrutor (ou Mediador): é o facilitador do grupo, responsável por manter a

ordem, motivar e avaliar os aprendizes.

Segundo [LUC99], também são previstos outros dois papéis no processo de ensino-
aprendizagem proporcionado pelo ambiente, quais sejam:

• Administrador: facilita a integração docente/curso/aprendiz e lida com as

questões de natureza predominantemente operacionais, como a matrícula de alunos
e outras tarefas de secretaria;

• Aprendiz: usuário final do curso, quem representa seu público-alvo.

Quanto aos serviços do AulaNet, que possuem seus acessos controlados através da
identificação do usuário por um nome e uma senha, são divididos baseados no princípio que
para aprender em grupo um indivíduo tem que compartilhar idéias (se comunicar), estar em
sintonia com os outros participantes do grupo (se coordenar) e realizar as tarefas
satisfatoriamente (cooperar). Os serviços são colocados à disposição do docente durante a
criação e atualização de um curso, permitindo a este selecionar quais vão se tornar disponíveis
aos aprendizes. A Figura 2.3 apresenta a área de trabalho do ambiente, composta de uma
janela principal e de um menu representado graficamente através da figura de um controle
remoto.
 31

Figura 2.3 - Interface do aprendiz com destaque ao menu de funcionalidades [FUK01]

Segundo [KIS02], além de permitir a seleção dos serviços desejados, o ambiente ainda
oferece a opção de configuração da interface gráfica, permitindo a adaptação de padrões e
estilos conforme as preferências da Instituição que mantém o servidor do AulaNet. Por
exemplo, podem ser modificadas as cores, fontes, logotipo e imagem de fundo da aplicação,
entre outras características gráficas.

Os serviços de comunicação fornecem as facilidades que permitem a troca e o envio

de informações entre docentes e alunos. Segundo [AUL02; FUK00; FUK01], os serviços
oferecidos são os seguintes:

• Mensagem ao docente: é um canal para contatar os docentes do curso. As

mensagens são enviadas através do correio eletrônico interno do ambiente para os
instrutores ou coordenadores, dependendo da escolha do autor.

• Mensagem para participantes: permite que os participantes vejam a lista de

membros da turma, saibam quem está conectado e participando do curso naquele
momento, e troquem mensagens entre si. As mensagens podem ser enviadas por
correio eletrônico (somente aos participantes do curso) ou por mensagens
instantâneas.
 32

• Grupo de discussão: também conhecido como fórum de discussão, é utilizado

para comunicação com toda a turma. Quando uma mensagem é postada, além de
armazenada no ambiente, esta é enviada à caixa de correio eletrônico de todos os
membros do grupo, permitindo que tomem ciência das atividades do Grupo de
discussão, mesmo sem acessar o ambiente.

• Grupo de interesse (ou Conferências): é possível colocar mensagens

respondendo, comentando ou criticando outra mensagem, e estas ficam aninhadas
abaixo da mensagem referenciada, semelhantemente ao funcionamento de um
fórum. Esta estruturação permite organizar a discussão por tópicos, que são criados
pelo docente. Diferentemente do que ocorre no Grupo de discussão, as mensagens
postadas no Grupo de interesse não são enviadas para a caixa de correio dos
participantes do curso, somente ficam armazenadas no ambiente para posteriores
consultas.

• Debate: é uma conversa em tempo real entre os participantes através de um chat

textual. Esta conversa pode ser salva caso o usuário assim deseje. Por ser uma
ferramenta de comunicação síncrona, todos devem estar conectados no momento
do debate. Por isto, em geral, as datas para realização dos debates são previamente
estabelecidas. Os aprendizes podem ser informados previamente, através do envio
de um e-mail, qual é o horário reservado para o debate, de forma que possam se
organizar para estarem presentes. Salienta-se que a iniciativa de enviar este e-mail
deve ser do instrutor do curso. Ou seja, deve ser enviado manualmente pelo
mesmo.

Os serviços de coordenação fornecem os meios para minimizar os problemas

decorrentes do trabalho em grupo e maximizar a cooperação entre seus membros. Desta
forma, segundo [AUL02; FUK00], a coordenação é baseada no agendamento de eventos e na
competência dos aprendizes, oferecendo os seguintes serviços:

• Avisos: é o serviço de notificação do AulaNet, que possibilita a criação de avisos

sobre o curso ou agendamento de eventos através de informes que ficam
 33

disponíveis para consulta. Geralmente é usado para orientar os aprendizes com

relação aos eventos do curso.

• Plano de aulas: é utilizado pelo docente para estruturar os conteúdos didáticos do

curso, separando-os em aulas, que seguem uma ordem sugerida, mas não imposta
para que o aprendiz acompanhe o curso.

• Tarefas: é utilizado para designar trabalho aos aprendizes. O ambiente gerencia a

submissão de arquivos de resolução das tarefas (upload) desabilitando a opção de
recebimento após a data estabelecida e permite ao instrutor avaliá-los e comentá-
los. Caso o instrutor deseje comunicar que há uma nova tarefa a ser realizada, este
deve enviar um e-mail aos aprendizes.

• Avaliação: possibilita a criação de exames para a (auto-) avaliação dos aprendizes

do curso. O docente pode criar provas on-line para fazer a avaliação formativa do
processo de aprendizagem, objetivando fornecer um feedback aos aprendizes. Estes
podem, depois de avaliadas as provas, consultarem os conceitos e notas obtidas.

• Relatórios de participação: facilitam o acompanhamento, por parte do docente,

da participação e da qualidade das contribuições feitas pelos aprendizes nos
diversos eventos do curso.

Quanto aos serviços de cooperação, estes fornecem os meios para a aprendizagem

cooperativa, a realização de atividades e a resolução de problemas. Segundo [AUL02;
FUK00], os serviços oferecidos são:

• Bibliografia e Webliografia: possibilitam, respectivamente, a criação de

referências bibliográficas e a indicação de referências externas (URLs - Uniform
Resource Locations) ao site do curso. A validade da disponibilidade destas
referências externas é dependente da verificação feita pelo instrutor.

• Documentação: permite a disposição de conteúdos ligados ao curso como um

todo, não ligados diretamente a uma determinada aula do plano de aulas.
 34

• Download: possibilita que o aprendiz veja uma lista de todos os arquivos que
compõem os conteúdos do curso e faça a transferência para um disco na sua
máquina ou rede local.

• Co-autoria de docente e Co-autoria de aprendiz: permitem que o docente

convide outros docentes ou aprendizes para compartilharem de sua área de trabalho
a fim de juntos construírem o material a ser disponibilizado.

Segundo [KIS02], além dos serviços apresentados, o usuário ainda tem a sua
disposição uma ajuda on-line, denominada “Dicas”. Este serviço está presente em quase todas
as janelas do ambiente, permitindo que o usuário acione-o para visualizar uma explicação
referente ao tópico em questão, esclarecendo suas dúvidas.

Como os serviços oferecidos pelo AulaNet são considerados como componentes que
podem ser adicionados ou não para um curso específico, a critério do coordenador deste
curso, eliminando deste a necessidade de conhecer e dominar alguma tecnologia específica
para divulgação do curso na Internet, considera-se que o ambiente facilita consideravelmente
a tarefa dos docentes [FUK00].

2.1.3 LearningSpace

O LearningSpace5 é um ambiente para gerência de cursos a distância, desenvolvido

pela Lotus Development Corporation. Este ambiente utiliza um sistema de groupware para
gerência de informações distribuídas, conhecido como Lotus Notes (LN). Para permitir o
trabalho em grupo, através da colaboração e contribuição de idéias, fornece uma série de
características. Também permite que o instrutor controle o desempenho dos participantes no
decorrer do curso e observe se os objetivos estabelecidos estão sendo atingidos.

Segundo [BAC00], o LN é baseado numa arquitetura cliente/servidor, onde usuários

do servidor, conhecido como Domino, podem fazer acesso às bases de dados lá depositadas
através de estações cliente ou ainda através de um navegador Web. Este sistema de gerência

5
Estudou-se as versões 2.5, 3.0 e 5.01 como um todo, uma vez que as bases que compõem o ambiente possuem
versões diferenciadas. Home page do produto: http://www.lotus.com/products/learnspace.nsf/wdocs/homepage.
 35

de informações dá suporte ao LearningSpace na geração de cursos pelos usuários, bem como

na distribuição e manutenção de informações. As características mencionadas nesta seção
dizem respeito à versão acessível através de um navegador Web.

Os usuários do LearningSpace são classificados em dois grandes grupos [BOW02]:

• Estudantes: podem acessar somente as atividades e funcionalidades relacionadas

aos cursos que estão inscritos, bem como disponibilizar aos demais informações
sobre seus perfis;

• Administradores: possuem acesso a funcionalidades específicas de acordo com as

diferentes funções que podem assumir - administrador do sistema, gerente do
curso, autor de materiais ou instrutor.

Independente do papel que um usuário possua, para acessar o ambiente do

LearningSpace através da Web terá que especificar a URL de acesso e fornecer os dados
solicitados na página de logon apresentada (nome do usuário e senha).

A aplicação LearningSpace é composta de cinco bases de dados do LN, sendo que as

características providas por cada um destas bases, bem como a interface gráfica do curso,
podem ser configuradas e/ou estendidas, conforme desejar seu criador, geralmente o gerente.
A seguir são descritas as funções de cada das bases de dados ou módulos, segundo [BAC00;
BOW02; WOR02].

A base Schedule apresenta a estrutura do curso criada pelo gerente e/ou instrutor em
termos do que deve ser feito e quando. No Schedule são apresentados os objetivos do curso e
guias de navegação para acesso a materiais do curso, exercícios, testes de reforço e
avaliações. O Schedule é projetado em módulos que devem ser desenvolvidos pelo estudante,
dentro de uma estrutura pré-definida pelo gerente e/ou instrutor. A Figura 2.4 apresenta a
interface do módulo Schedule, onde se pode observar à direita a listagem dos módulos
projetados para um curso de “Introdução a HTML”, o qual é identificado no canto esquerdo
superior. Logo abaixo desta identificação é possível observar quatro ícones, os quais provêem
acesso às bases de dados oferecidas para o aluno pelo LearningSpace. A tarja abaixo destaca
em qual base de dados o usuário está conectado no momento.
 36

Figura 2.4 - Interface do módulo Schedule [LOT99]

A base MediaCenter é a base de conhecimento de um curso, contendo todos os

conteúdos relacionados ou considerados interessantes de serem disponibilizados, bem como
acesso a páginas na Web ou outros repositórios de conteúdos (ex. outras bases de dados no
LN). Ou seja, este módulo pode ser visto como a biblioteca do curso. Todo o material
disponível nesta base de dados pode ser consultado através de palavras-chave, título ou autor,
e obtido pelos alunos através de download. O MediaCenter tem como objetivo apresentar ao
aluno um leque de opções em termos de conteúdo para viabilizar e estimular seu processo de
aprendizagem.

Quanto à base CourseRoom, esta é um ambiente interativo no qual estudantes fazem

discussões com os colegas e instrutor (es) sobre os conteúdos do curso. Este ambiente
possibilita discussões assíncronas, através de uma base de dados do LN, onde são
disponibilizadas mensagens sobre um determinado assunto sugerido pelo instrutor e todos
devem respondê-las. Em sua última versão (5.01), lançada em outubro de 2002, também
passou a permitir discussões síncronas, através de videoconferência, chat e quadro-branco
cooperativo. Estas interações podem ser feitas de forma privada ou pública em relação ao
restante do grupo, mas o instrutor sempre terá acesso a todo o material gerado. Segundo
[BOW02], o LearningSpace também provê um serviço de e-mail, o qual é considerado
limitado, pois os estudantes podem enviar mensagens para colegas e instrutores, até mesmo
para pessoas que não participem do curso, mas não podem receber e-mail de alguém que não
seja usuário do ambiente. Também segundo [BOW02], este módulo apresenta como vantagem
 37

a característica de permitir a gravação de uma sessão de discussão síncrona, proporcionando

ao aluno ou instrutor a opção de reproduzi-la novamente conforme julgue necessário.

Já a base Profiles é uma coleção das descrições de estudantes e instrutor(es) do curso,

contendo informações do tipo: fotografia, dados pessoais e residenciais, informações de sua
formação acadêmica, experiências e interesses. Esta função assemelha-se a criação de uma
home page por cada um dos participantes do curso. Segundo [WOR02], os usuários têm a
opção de esconder algumas informações pessoais específicas (telefone e/ou endereço
residencial) se assim o desejarem dos demais participantes. Isto garante que o instrutor possa
saber todos os dados necessários mantendo-os confidenciais aos demais. Este módulo também
permite que o aluno acompanhe o grau atribuído pelo instrutor às atividades propostas como
forma de avaliação, através da opção Portofolio. Segundo [LOT99], uma outra forma do
aluno ser informado do grau que foi atribuído ao seu trabalho é receber a nota através de um
e-mail enviado pelo instrutor. Esta forma só ocorrerá se a opção de notificação por e-mail
tiver sido habilitada durante o projeto do curso. Caso tenha sido, as demais notificações
eventualmente necessárias também serão feitas através de e-mail.

Por fim, a base Assessment Manager é uma ferramenta de avaliação, disponibilizada

somente aos instrutores dos cursos para que estes examinem o rendimento da participação dos
estudantes. Os resultados dos testes ou tarefas são enviados ao Assessment Manager para que
o instrutor possa avaliá-los. Estes testes podem ser criados fora do ambiente LearningSpace e
importados para o mesmo [BOW02]. Os estudantes poderão recebê-los por e-mail ou acessá-
los através da base de dados CourseRoom. Segundo [KIS02], enquanto estão envolvidos com
alguma tarefa específica, os estudantes podem indicar diferentes status para a mesma,
permitindo, desta forma, que o instrutor saiba como proceder. Os seguintes status são
disponibilizados: “em andamento”, “pedido de revisão” e “submeter à correção”. Os
estudantes ainda podem consultar os resultados das avaliações na Grade de Notas.

Segundo [WOR02], uma das grandes vantagens do LearningSpace é a flexibilidade de

permitir aos instrutores a atualização ou acréscimo do material utilizado no curso. Para tal,
basta o instrutor estabelecer um documento de atualizações para que a cada vez que o
estudante entre no curso ele possa identificar facilmente as novidades.
 38

2.1.4 WebCT

O WebCT6 foi desenvolvido originalmente pela University of British Columbia,

Vancouver no Canadá, em 1997, e adquirido, em 1999, pela empresa Universal Learning
Technology. É um gerenciador de cursos a distância baseado em uma arquitetura
cliente/servidor que utiliza a Internet como tecnologia de apoio à comunicação. Pode,
também, ser utilizado simplesmente como repositório de material instrucional para cursos
presenciais.

Segundo [NOB02], o WebCT prevê quatro tipos de usuários:

• Administrador: há apenas um administrador. Cabe a este iniciar um curso e abrir

um curso vazio para um projetista, cancelar cursos e controlar as senhas dos
usuários;

• Professor (ou Projetista): é quem, geralmente, projeta e desenvolve o curso, além

de desempenhar o papel de professor como este é tradicionalmente conhecido. O
professor pode criar perguntas, verificar o progresso dos alunos, estabelecer grupos
de trabalho entre alunos, entre outros. Cabe ao projetista criar as contas dos alunos
e adicionar ou eliminar componentes no seu curso, tendo em vista as características
metodológicas do mesmo;

• Instrutor (ou Monitor): podem ser cadastrados vários instrutores para um curso.
O instrutor dentro do sistema tem os mesmos privilégios dos estudantes, porém
pode corrigir provas, uma vez que sua função é auxiliar o professor no decorrer do
curso;

• Alunos: não há limite quanto ao número de alunos em um curso, nem quantos

cursos estes se matriculam. Possuem acesso somente ao material instrucional, às
ferramentas de comunicação e à área de apresentação dos trabalhos. Caso seja
necessário para atender sua metodologia de ensino, o professor pode organizar os
alunos em diversos grupos, conforme critérios a serem definidos pelo próprio
professor [KIS02].
6
Estudou-se a versão 3.0. Maiores informações podem ser obtidas na home page do produto: http://www.webct.com.
 39

No WebCT, cada curso possui um conjunto de páginas HTML (HyperText Markup

Language), as quais podem ser acessadas somente pelos alunos clientes do mesmo através de
senha de acesso. Para criar um curso, o instrutor pode utilizar as ferramentas disponíveis no
servidor. Estas ferramentas permitem a comunicação e colaboração entre os participantes do
curso, bem como a administração de diversos aspectos por parte do professor. Além disto, o
professor também tem a possibilidade de configurar o ambiente através da escolha de cores e
ícones que serão apresentados e da disposição dos elementos na interface.

Figura 2.5 - Ferramentas do ambiente WebCT [BAC00]

A Figura 2.5 apresenta os ícones das ferramentas oferecidas pelo WebCT. Somente as
mais relevantes no contexto deste trabalho serão descritas a seguir, segundo [GOL98; KIS02;
WEB00]:

• Calendário: permite informar as datas dos eventos previstos para o

desenvolvimento do curso. Tanto professor quanto alunos podem acrescentar itens
neste calendário, sendo que eles podem ser visualizados por todo o grupo ou
apenas por quem o criou. Quando se acessa o ambiente, os novos itens presentes
no calendário são prontamente identificados e apresentados para o aluno.

• Quadro de avisos: permite a comunicação entre os participantes do curso, seja

através de discussões e questões relacionadas ao curso ou da divulgação de avisos.
Apresenta sempre o aviso mais recente no topo da lista.

• Material instrucional: disponibilizado através de links para textos, imagens ou

qualquer outro material a ser oferecido para download durante a realização do
curso. Este material deve ser criado fora do ambiente e importado para o mesmo. O
 40

professor também pode criar referências para URLs externas ao ambiente, que
podem ser acessadas diretamente após um clique sobre as mesmas.

• Chat: realização de conversas em tempo real. Para cada curso existem quatro salas
para discussão de assuntos gerais, uma para discussão sobre o curso e uma última
com acesso liberado para todos os cursos, totalizando seis salas por curso. O
conteúdo discutido nas quatro primeiras salas fica registrado e disponível para o
professor consultar quando desejar e utilizar como apoio à avaliação da
participação e contribuição dos alunos.

• Fórum: discussão de assuntos, de forma assíncrona, propostos pelo professor. As

mensagens podem ser disponibilizadas para um grupo específico ou para todos os
participantes. Ou seja, podem ser públicas ou privadas. O ambiente oferece um
mecanismo de controle para o aluno saber se existe alguma mensagem não lida: é
apresentada uma imagem ao lado das novas mensagens.

• Correio eletrônico: só é permitido o envio de mensagens para endereços de

usuários matriculados no curso.

• Quadro-branco: possibilita a criação de documentos gráficos de forma

cooperativa e síncrona. Assim, qualquer usuário que estiver conectado no
momento pode editar a imagem que está sendo desenvolvida em conjunto.

• Página pessoal: cada participante do curso possui um link que lhe permite
disponibilizar sua página pessoal. Além disto, é disponibilizado um pequeno
espaço para o aluno apresentar aos seus colegas links sobre outros assuntos.

• Testes: são respondidos pelos alunos como forma de avaliação do seu rendimento
no decorrer do curso e também para observar sua compreensão dos assuntos
estudados. Também podem ser disponibilizados pelo professor testes sem caráter
avaliativo, apenas para que o próprio aluno verifique seu desempenho e
conhecimento sobre os assuntos tratados. Para elaborar os testes, o professor conta
 41

com uma série de formatos de questões pré-definidas (relacionar colunas, múltipla-

escolha, cálculo, resposta curta e parágrafo).

• Expositor de notas: local onde são disponibilizadas as notas e médias obtidas

pelos alunos no decorrer do curso. Cada nota está relacionada a uma tarefa
realizada (e enviada ao professor pelo sistema) e/ou teste.

Com as demais ferramentas que o ambiente oferece, aqui não elencadas, é possível
realizar as seguintes atividades: criar um índice do conteúdo, criar um glossário de palavras,
buscar por um conteúdo específico, acessar o material instrucional através de um CD-ROM,
gerenciar usuários do curso, enviar a resolução de tarefas ao professor, acompanhar o
desempenho dos alunos (em todos os acessos ao ambiente e desenvolvimento das tarefas
designadas) e gerar relatórios estatísticos e gráficos de acompanhamento dos alunos (ex.
quanto tempo um aluno permaneceu utilizando o ambiente, quais links consultou, que
materiais foram acessados, entre outros). Estas duas últimas funcionalidades, em específico,
caracterizam um aspecto bastante importante do WebCT, o de prover apoio à gerência do
andamento dos cursos e desempenho dos alunos. São estas características que permitem ao
professor expandir e complementar o processo de avaliação dos alunos durante o andamento
de uma disciplina ou curso (e, em especial, foram investigadas para serem contempladas no
ambiente proposto no Capítulo 4).

Segundo [BAC00], o WebCT não possibilita que o professor configure os outros

recursos (e-mail, chat, etc.) de acordo com as características de seu grupo de alunos. Sendo
assim, o WebCT exige que a metodologia do curso se adapte aos recursos tecnológicos
disponibilizados. Além disto, como cada usuário criado no WebCT está vinculado a um único
curso, para que um aluno participe de mais de um curso seu cadastro precisa ser feito tantas
vezes quantos forem os cursos do qual ele participará.

2.1.5 Uma breve análise comparativa dos ambientes

Após o estudo dos ambientes apresentados, percebeu-se que ambos diferenciam-se

consideravelmente em suas organizações, serviços disponibilizados e praticidade de uso.
Percebeu-se uma clara organização da disposição das funcionalidades no AmCorA, no
 42

AulaNet e no LearningSpace, sendo as mesmas agrupadas por semelhança, enquanto no

WebCT elas são listadas seqüencialmente sem critério algum de organização, sob o ponto de
vista do aluno. Sob o ponto de vista do professor, as ferramentas estão disponibilizadas
agrupadas segundo suas similaridades. Destaca-se a importância desta organização, pois se
acredita que isto facilita a utilização do ambiente por parte do usuário. Deve-se lembrar
sempre que um professor busca, com a adoção de um ambiente deste gênero, um auxílio para
suas atividades, um facilitador e não um fator complicador, que lhe traga dificuldades durante
a organização do curso. O principal foco do professor deve ser a preparação do material de
apoio e o desenvolvimento da metodologia de ensino que irá utilizar, e não como irá aprender
a dominar a tecnologia que lhe servirá como auxílio.

Acredita-se que estas características, em parte, se devem ao fato das diferentes origens
dos ambientes – acadêmica e comercial, também de seus diferentes propósitos e até mesmo
tempo de desenvolvimento, pois um ambiente disponível há mais tempo para a comunidade
tem maiores chances de ter recebido feedbacks dos seus usuários e melhorado os aspectos
indicados pelos mesmos. Um ambiente de origem acadêmica agrega os conhecimentos que
circulam dentro do grupo de pesquisa onde está inserido, beneficiando-se de resultados
paralelos (pesquisas que ocorrem simultaneamente ao projeto) e, pode utilizar uma equipe
interdisciplinar para ampliar as discussões e contribuições que permitem garantir qualidade
tanto sob o ponto de vista pedagógico, como tecnológico. Ambientes mais tradicionais e
abertos à comunidade permitem maior número de usuários testando e refinando as
funcionalidades. Outro aspecto importante é a questão de proposta pedagógica, geralmente
ligada ao projeto de ensino-aprendizagem do grupo ou instituição, o qual possui prós e
contras. O maior benefício é uma modelagem bem definida em função de objetivos
educacionais condizentes com a proposta da instituição, ao passo que ambientes comerciais
tendem a ser mais genéricos e flexíveis para permitir a adequação a diferentes tipos de
objetivos educacionais, fato este que, muitas vezes, acaba por deixar o ambiente muito
descaracterizado, necessitando do usuário grande experiência para poder tirar partida de suas
potencialidades.

O Quadro 2.I destaca as principais características identificadas após o estudo dos

ambientes (A descrição completa da análise feita pode ser encontrada no Trabalho Individual
II (TI-II) da autora [MAR02]). As características foram agrupadas por afinidade de suas
funcionalidades. No quadro, apresenta-se as palavras “Sim” e “Não” indicando,
 43

respectivamente, a presença ou a ausência de uma característica. Àquelas características que

não dizem respeito a um determinado ambiente, apresenta-se “N/A” (Não se aplica) e para
aquelas que não se conseguiu identificar sua presença no ambiente, tem-se o caractere “?”.

Quadro 2.I - Principais características dos ambientes estudados

CARACTERÍSTICAS AMCORA AULANET LEARNINGSPACE WEBCT
Características gerais

Administrador Sim Sim Sim Sim

Professor Sim Sim Sim Sim
Usuário

Instrutor/Monitor Não Sim Sim Sim

Aluno Sim Sim Sim Sim
Controle de acesso e diferentes visões conforme o perfil Sim Sim Sim Sim
Ajuda/Help on-line Sim Sim Não ?
Glossário de termos Não Não Não Sim
Mensagens instantâneas Sim Sim Não Não
Síncr.

Sala para bate-papo (chat) Sim Sim Sim Sim

Registro das salas de bate-papo Não Sim Sim Sim
Ferramentas de
comunicação

E-mail interno ao curso Não Sim Sim Sim

Assínc.

Envio de e-mail a usuários externos ao curso Sim Não Sim Não

Recebimento de e-mail de usuários externos ao curso Sim Não Não Não
Lista/Fórum de discussão Sim Sim Sim Sim
Publicação de avisos Sim Sim Não Sim
Agenda/Cronograma de atividades Não Sim Sim Sim
Dados sobre os participantes Sim Não Sim Sim
Elaboração de plano de aula N/A Sim Sim Sim
Ferramentas de

Publicação de material de apoio Sim Sim Sim Sim

professor
apoio ao

Envio de tarefas aos alunos N/A Sim ? ?

Identificação de novas tarefas a serem corrigidas N/A Não Não Não
Manutenção de notas N/A Sim Sim Sim
Geração de relatórios de participação Não Sim ? Sim
Agendamento de compromissos Sim Não Não Sim
Ferramentas de
apoio ao aluno

Download de material Sim Sim Sim Sim

Entrega de material por upload Sim Sim Sim Sim
Consulta a resultados de tarefas N/A Sim Sim Sim
Atribuição de status a uma tarefa N/A Não Sim Não
Esclarecimento de dúvidas on-line Sim Não Não Não

Quanto às características gerais dos ambientes, todos os ambientes preocupam-se com

a questão de restrição de acesso e segurança das informações, por esta razão, ambos possuem
controle de acesso, através da solicitação de um nome de usuário e senha (no caso do
AmCorA, o nome do usuário é substituído pelo seu e-mail). Após o usuário ter sido
identificado, são disponibilizadas somente funcionalidades permitidas para seu perfil.

Os ambientes variam bastante as ferramentas e as funcionalidades que disponibilizam

para comunicação entre os integrantes de um curso, e para a troca de informações sobre o
andamento deste curso. Como exemplo, pode-se citar a comunicação síncrona através das
salas de bate-papo. Todos os ambientes oferecem este meio de comunicação, mas apenas o
AmCorA e o WebCT apresentam salas para conversa livre. Uma forma distinta de
 44

comunicação diz respeito aos avisos sobre atividades do curso, novidades ou notícias que
devem ser informadas aos participantes. Os avisos são, de forma geral, disponibilizados no
ambiente, do mais recente ao mais antigo, e o aluno deve estar atento e verificando
constantemente o espaço destinado para identificar novidades. Não existe um mecanismo de
notificação automático sobre a existência de um novo aviso.

Outra forma de comunicação identificada foi a disponibilização de informações

pessoais sobre os participantes. Considerando que os participantes podem não estar
localizados fisicamente em um mesmo lugar, onde não haverá um contato face-a-face, é
importante que eles se apresentem uns aos outros através da breve informação de alguns
dados pessoais. Apesar do AulaNet não oferecer esta funcionalidade, os demais se
diferenciam pela forma de controle da mesma. O AmCorA e o WebCT não permitem controle
de divulgação das informações, todos podem visualizar a totalidade do que consta nesta
sessão (o AmCorA tem como atividade planejada para ser implementada em breve este
controle). Já o LearningSpace permite que os usuários escondam dos demais participantes
algumas informações pessoais específicas (telefone e/ou endereço residencial), se assim o
desejarem.

Quanto às ferramentas de apoio ao professor, no decorrer do curso, de acordo com sua

metodologia de ensino, este pode propor aos alunos uma série de tarefas, com caráter
avaliativo ou não. O envio destas tarefas aos alunos através do ambiente foi explicitado
apenas no AulaNet. Desta forma, não se pode afirmar que o procedimento é o mesmo nos
demais. As tarefas devem ser finalizadas no prazo estipulado e enviadas ao professor através
do próprio ambiente. O AulaNet e o WebCT possuem controle automático da data limite de
recebimento de uma tarefa, ou seja, depois de encerrado o prazo de entrega, é impossível
realizar upload do material a ser corrigido. Em nenhum dos ambientes, exceto no AmCorA,
onde não ocorre a especificação de tarefas, é oferecido um mecanismo de notificação ao
professor de que há novos materiais disponíveis para correção. Assim, o professor deve
verificar, de tempos em tempos, se existem novas tarefas a serem corrigidas e avaliadas.

No que concerne as ferramentas de apoio ao aluno, uma das principais características

diz respeito ao calendário de atividades e compromissos. Somente os ambientes AmCorA e
WebCT permitem que os alunos organizem o seu calendário e agendem compromissos tanto
individuais como para toda a turma. Em relação às solicitações de pedidos de ajuda e
 45

esclarecimento de dúvidas, somente o AmCorA oferece uma ferramenta destinada a este fim,
chamada Moonline. Esta ferramenta dá apoio ao esclarecimento de dúvidas através de
perguntas e respostas, conforme mencionado anteriormente.

O estudo destes ambientes permitiu-nos identificar uma série de características que

foram observadas e consideradas na elaboração e desenvolvimento do ambiente
PROOGRAMA e do agente AMIGO.

2.2 Processo de desenvolvimento de software

Com o aumento da complexidade dos softwares educacionais em relação aos sistemas

produzidos anos atrás, da diversidade de tecnologias adotadas e do número de pessoas
envolvidas, tornou-se inadequado projetar um programa educacional sem utilizar-se um
processo bem definido para orientar o seu desenvolvimento. As equipes interdisciplinares
integrantes dos projetos de software educacional agora necessitam de especialistas de
Engenharia de Software (ES). Estes contribuem para organização e definição de todos
aspectos relacionados à produção do software. Existem três aspectos fundamentais envolvidos
na ES: métodos, que proporcionam os detalhes de “como fazer” para construir o software
através da definição de um conjunto de tarefas; ferramentas, que proporcionam apoio
automatizado ou semi-automatizado aos métodos; e processos, que constituem o elo de
ligação que mantém juntos as ferramentas e os métodos [PRE01]. O último aspecto é
considerado o mais importante da ES.

Encontra-se, na literatura, diferentes definições para Processo de Desenvolvimento de

Software (PDS). [PAU99] define PDS como sendo um conjunto de atividades, métodos e
práticas que pessoas usam para desenvolver e manter produtos de software. Para [SOM03],
PDS é um conjunto de atividades e resultados associados que levam à produção de um
produto de software. Esse processo pode envolver o desenvolvimento de software desde o
início ou a evolução de versões já existentes. [PRE01] afirma que um PDS define a seqüência
em que métodos de ES serão aplicados, como os produtos serão entregues, os controles que
ajudam a assegurar a qualidade e a coordenar as mudanças, e os marcos de referência que
possibilitam aos gerentes de software avaliar o processo do desenvolvimento.
 46

Existem diversos PDSs disponíveis no mercado, sendo que se diferenciam

especialmente pela forma que definem a relação com o cliente (durante todo o processo ou
somente até o final da definição dos requisitos); tratam as mudanças de requisitos (mudanças
caracterizam um novo projeto, conforme sua natureza; ou podem ocorrer a qualquer
momento, sendo acatadas pela equipe sem interferir no desenvolvimento); e formalizam as
decisões e definições através das documentações propostas [PRI02]. Entre os PDSs mais
conhecidos atualmente, pode-se citar o Agile Software Development (ASD) [COC02], o
Extreme Programming (XP) [BEC00], o Rational Unified Process (RUP) [KRU01], e
MSF [MIC02a].

O ASD surgiu a partir de um manifesto resultante de um encontro entre dezessete

grandes pesquisadores da área de ES, em Utah nos Estados Unidos, no início de 2001.
Motivados pela observação de equipes de desenvolvimento de software em diversas empresas
em todo o mundo, estes pesquisadores reuniram-se para discutir os valores e os princípios que
permitiam estas equipes desenvolver software de forma rápida e ao mesmo tempo responder
às mudanças [PRI02]. Desta forma, o ASD é um conjunto de idéias que visa um objetivo
comum: melhorar o processo de desenvolvimento de software e sempre trazer novas idéias
[COC02]. Defende que devem existir práticas de modelagem, documentação e planejamento
do software, mas estas práticas devem ser realizadas de forma ágil e mais simplificada
possível, evitando burocracias e documentações desnecessárias. Neste contexto, não existem
fases de projeto bem definidas, indicando artefatos7 de entrada e saída por cada fase. Segundo
[COC02], cada projeto é configurado de uma forma diferente, de acordo com seu escopo e
contexto. O contato com o cliente é fundamental, uma vez que, por não ter um grande
rigorismo na especificação e identificação dos requisitos, pode-se precisar esclarecer dúvidas
a qualquer momento.

O XP surgiu em 1996, a partir da carência identificada por Kent Beck, funcionário da

DaimlerChrysler8, de processos de desenvolvimento de software que facilitassem a criação de
software em geral. Baseado nesta necessidade, Beck especificou o XP, o qual visa um
objetivo principal: entregar o software que o cliente desejar quando este assim o desejar. Para

7
Artefato é um termo geral para qualquer tipo de informação criada, produzida, alterada ou utilizada por
participantes do projeto de um sistema [JAC99]. Por exemplo, diagramas de caso de uso especificando os
requisitos e os códigos-fonte de um software são considerados artefatos de um projeto de software.
8
Multinacional da área de transporte e serviços automotivos.
 47

tal, é dado ênfase em quatro aspectos considerados fundamentais: comunicação, simplicidade,

feedback e coragem [XTP02]. Além disto, segundo [PRI02], o trabalho em equipe também é
enfatizado, no qual gerentes, clientes e desenvolvedores devem formar uma equipe única e
comprometida a entregar um software com qualidade. O XP é composto por quatro fases,
quais sejam: Planejamento (Planning), Projeto (Designing), Codificação (Coding) e Teste
(Testing), sendo que a mudança de um requisito pode acorrer a qualquer momento. Segundo
[XTP02], tem-se esta visão por se acreditar que o cliente nem sempre tem uma idéia concreta
do que o sistema deve fazer, sendo permitido ao mesmo alterar indefinidamente as
especificações.

Diferentemente dos anteriores, o RUP é um framework para PDS, que propõe um

conjunto de atividades e artefatos relacionados às quatro fases de projeto definidas. Estas
fases são denominadas Concepção (Inception), Elaboração (Elaboration), Construção
(Construction) e Transição (Transition) [POL01]. O processo pode ser instanciado para
diferentes projetos, através da combinação das atividades e artefatos propostos, de acordo
com as características e porte do mesmo. Em essência, o RUP define o processo de
desenvolvimento de forma interativa e incremental, orientada a objetos, com foco na criação
de uma arquitetura robusta e análise dos riscos para o projeto [POL01; PRI02]. Apesar de
encontrar-se na literatura uma boa documentação discutindo as fases, os papéis dos
integrantes da equipe de desenvolvimento, as atividades e mencionando os artefatos
estipulados, estes últimos não estão disponíveis de forma gratuita. Isto dificulta o estudo e
análise daqueles que não possuem acesso ao templates dos documentos adotados durante o
processo de desenvolvimento. Por ter sido o modelo de PDS adotado, o MSF será descrito
mais detalhadamente em uma seção específica.

2.2.1 Microsoft Solutions Framework

O MSF é um framework para projetos de tecnologia proposto pela Microsoft.

Segundo [MIC02a; MIC02b], este framework é composto por dois modelos e três disciplinas.
O Modelo de processo (Process Model) organiza em fases de projeto as atividades a serem
realizadas para se desenvolver uma solução para o problema do cliente, e o Modelo de
equipes (Team Model) trata como estruturar pessoas e suas atividades. Quanto às disciplinas,
a de Gerência de projeto orienta a aplicação de conhecimento, habilidades, ferramentas e
 48

técnicas às atividades do projeto, buscando atender as especificações do mesmo; a de

Gerência de riscos trata o gerenciamento de riscos, os quais são inerentes a qualquer tipo de
projeto; e a de Aprendizagem propõe uma forma de identificar conhecimentos e habilidades
a serem usufruídas nos projetos.

O framework da Microsoft foi criado em meados de 1994, baseado nas melhores

práticas (best practices) coletadas do desenvolvimento de produtos da empresa. Conforme
mencionado acima, o MSF Process Model estabelece um conjunto de atividades para a
realização de um projeto de software, as quais estão organizadas em fases finalizadas por
marcos (milestones). Não é proposto um workflow para a realização destas atividades em cada
uma das fases. Dependendo do tamanho e do tipo do projeto, bem como do número de
pessoas envolvidas, uma empresa ou grupo pode instanciar algumas atividades e práticas
propostas no framework e estabelecer um processo particular para orientar seu
desenvolvimento de software [MIC02a]. Segundo [MIC02b], este modelo combina os
melhores princípios do ciclo de vida espiral com o ciclo de vida em cascata.

As fases de projeto propostas pela Microsoft para o PDS são: Visão (Envisioning),
Planejamento (Planning), Desenvolvimento (Developing), Estabilização (Stabilizing) e
Implantação (Deploying). Cada uma destas fases possui objetivos específicos e, além das
respectivas atividades, também definem documentos a serem adotados visando registrar as
especificações e decisões tomadas [MIC02a; MIC02b]. A fase de Visão tem como principal
objetivo estabelecer entre a equipe do projeto, que é organizada neste momento, uma visão
comum do problema que está sendo proposto. Neste sentido, é delineada uma visão geral de
solução para o problema e identificado o escopo que será atendido naquele momento. Sugere-
se fazer um levantamento preliminar dos riscos relacionados ao desenvolvimento do projeto e
dos recursos (humanos e físicos) que serão necessários para desenvolvê-lo. É neste momento
que se deve estabelecer a forma de trabalho da equipe, como, por exemplo, pode-se
mencionar a freqüência das reuniões, os meios de comunicação entre cliente e equipe e a
gerência de configuração9 (ou de versões) dos artefatos gerados.

Na fase de Planejamento é preparada a especificação funcional do software, baseada

nos requisitos identificados, e modelada a solução. Segundo [MIC02b], os requisitos podem

9
Do original em Inglês, Configuration Management.
 49

ser organizados nas seguintes categorias: de negócio, os quais definem as necessidades do

cliente; de usuário, os quais especificam os aspectos não-funcionais do software, tais como
interface gráfica e performance desejada; operacionais, que descrevem como o software deve
interagir com os demais sistemas já disponíveis; e de sistema, que descreve a infra-estrutura
(cabos, roteadores, entre outros) necessária para colocar o software em funcionamento para os
usuários. Também são detalhados os produtos a serem entregues, estimados os custos e
elaborado o cronograma de realização das atividades.

A fase de Desenvolvimento não diz respeito apenas à codificação, também são

realizados testes dos produtos e preparada a infra-estrutura para utilização do software em
caráter experimental (teste do usuário) e ambiente de produção. Ou seja, onde será utilizado
pelo usuário final. As mudanças de requisitos solicitadas pelo cliente nesta fase devem ser
analisadas pela equipe e avaliadas se serão aceitas [MIC02a]. Conforme o porte da alteração,
pode-se caracterizar um novo projeto. A questão deve ser acordada com o cliente. Aquelas
mudanças de requisitos feitas devem ser documentadas, visando formar um histórico do
projeto e garantir que o cliente está ciente das conseqüências destas alterações.

Durante a fase de Estabilização a equipe corrige eventuais erros encontrados pelo

usuário, que estará usando o software em caráter experimental. Os documentos do usuário,
tais como guia de instalação e manual do usuário, devem ser verificados pelo cliente neste
momento [MIC02a]. Depois de corrigidos estes erros, os usuários devem repetir os testes.
Como é difícil caracterizar se um software está livre de erros, esta fase irá se encerrar quando
forem atingidos os critérios de aceitação dos produtos, definidos inicialmente na fase de
Visão. Finalizando o processo, tem-se a fase de Implantação, na qual a equipe coloca o
software em produção, oferece um período de suporte e o cliente dá sua aprovação final
quanto ao produto entregue. Devem ser entregues ao cliente todas as versões finais de
artefatos necessários para a utilização e manutenção do software. A equipe deve se reunir logo
após a implantação do sistema para fazer uma análise do projeto, visando identificar pontos
positivos e negativos, bem como lições aprendidas. Também deve ser conduzida uma
pesquisa de satisfação com o usuário final sobre o produto entregue [MIC02b].
 50

2.2.2 Processo de desenvolvimento de software educacional

Em relação a ambientes educacionais de uma forma geral, o PDS exige atenção

especial. Segundo [AND01], é preciso levar-se em consideração que este tipo de software
pressupõe uma rede de articulações de estratégias e táticas pedagógicas, as quais são definidas
a partir dos objetivos e pressupostos pedagógicos do professor que irá utilizá-lo. Neste
sentido, é necessário primeiramente definir uma arquitetura pedagógica para o ambiente para
posteriormente se partir às decisões computacionais (definição da estrutura, escolha das
tecnologias, etc.) e ao desenvolvimento do ambiente como um todo. [PIN02] reforça esta
visão afirmando que: “um bom projeto de ambiente virtual de aprendizagem preocupa-se com
a proposta pedagógica que o seu sistema deve suportar, para que os processos de ensino e
aprendizagem desenvolvam-se de maneira satisfatória”.

Para que tais preocupações possam ser atendidas, [GOM03] destaca a importância da
elicitação de requisitos para projetos de software educativos. O autor defende que o conjunto
de requisitos especificados deve atender não só aspectos do processo de aprendizagem dos
alunos, mas também aspectos do processo de mediação a ser promovida pelo professor, o qual
pode beneficiar-se de funcionalidades específicas do sistema, como, por exemplo, o registro
de passos realizados pelos alunos ou a prévia organização de seqüência de problemas.

Encontra-se na literatura diversos relatos, tais como [MCC96; PRE01; SAW99], que
apontam que a tarefa de elicitação de requisitos em domínios muito específicos não é trivial,
mesmo para profissionais da área de ES. Segundo [GOM03], esta tarefa ainda tem sido
bastante desenvolvida de forma não-sistemática. Ou seja, utiliza-se a abordagem tradicional
de questionar o cliente e o usuário sobre o que desejam que seja contemplado no software
através de conversas informais ou entrevistas semi-estruturadas. Uma tentativa de formalizar
este processo é proposta por [NIE00]. O autor propõe que a prototipação e validação da
interface gráfica do software é uma forma organizada de expressar e complementar a
identificação dos requisitos. Tal procedimento busca garantir que os requisitos estarão
atendendo os aspectos cognitivos esperados para uma boa aprendizagem. [PRE01] destaca o
uso desta prática, em especial, para aplicações desenvolvidas para funcionarem na Web.

Em sua dissertação, [NET03] destaca a importância da prototipação da interface

gráfica, a qual constituiu uma das etapas do desenvolvimento da nova versão do ambiente
 51

AmCorA. Com isto, observa-se que a afirmação inicial desta seção, da necessidade de seguir-
se um processo de desenvolvimento formal, deixou de ser uma preocupação única dos
desenvolvedores de aplicações comerciais e de grande porte. A comunidade de Informática na
Educação (IE) necessita integrar-se com profissionais da área de ES para buscar subsídios
para o desenvolvimento dos programas educacionais.

2.3 Agentes de software

Por ser uma área de pesquisa relativamente recente, a Inteligência Artificial

Distribuída (IAD), cujo objeto de estudo está baseado na inteligência advinda do
comportamento social caracterizado pela interação de agentes [SIC92], ainda não apresenta
uma definição única do conceito de agentes que seja aceita por todos os pesquisadores da área
[ALV97; SIL01]. Desta forma, encontra-se na literatura diversos conceitos para o termo
agente. Pode-se citar como exemplo as seguintes definições:

Um agente é uma entidade real ou virtual, imersa em um ambiente sobre o qual ela é
capaz de agir, que dispõe de uma capacidade de percepção e de representação
parcial deste ambiente, que pode se comunicar com outros agentes e que possui um
comportamento autônomo, conseqüência de suas observações, de seu conhecimento
e das suas interações com os outros agentes [FER91].

Um agente é uma entidade à qual nós podemos associar uma identidade única, e que
é capaz de executar um processamento de cálculo. Um agente pode ser considerado
como um meio que produz um certo numero de ações, a partir de seu conhecimento
e dos mecanismos internos que lhe são próprios [GAS92].

Um agente é uma entidade que percebe seu ambiente através de sensores, e age
sobre o mesmo utilizando-se dos executores [RUS95].

Um agente é um sistema de computador que está situado em algum ambiente e que é

capaz de executar ações autônomas de forma flexível neste ambiente, a fim de
satisfazer seus objetivos de projeto [WOO99].

O termo agente originou-se a partir da abstração de ator proposta por [HEW77] em

seus trabalhos, os quais descreviam modelos de atores concorrentes. Nestes modelos era
proposto o conceito de um objeto autocontido, interativo e com execução concorrente,
chamado de ator. Este ator deveria encapsular estados e ter a capacidade de responder a
mensagens de outros objetos similares. No decorrer dos anos, o conceito de agente passou a
ser aprimorado e bastante difundido. Na segunda metade da década de 90 foi tão amplamente
difundido na área de Ciência da Computação (CC) que se criou o termo agente de software
 52

[GEN94], em que praticamente qualquer processo comunicante passou a ser denominado

agente. Por fins de praticidade, neste trabalho, usar-se-á apenas o termo agente.

Para ser considerado um agente, esta entidade precisa possuir determinadas

propriedades. Entre elas, são indispensáveis a autonomia e a reatividade [HÜB03; WEI96], as
quais podem ser observadas nos conceitos de agente apresentados acima. A autonomia, neste
caso, significa que o agente tem sua existência independente dos demais agentes e pode
executar suas ações sem a necessidade do auxílio humano [BRI02; WEI99; WOO99]. A
reatividade diz respeito aos agentes perceberem o ambiente e responderem a mudanças que ali
ocorrem [WEI96]. Outras propriedades desejadas são a pró-atividade, que significa a
capacidade de tomar iniciativas, exibindo comportamento dirigido pelo objetivo e não
simplesmente por mudanças no seu ambiente; e a habilidade social, que significa ter a
capacidade de interagir com outros agentes [JEN98].

Segundo [MENEG02], os agentes podem ser classificados segundo diversos critérios,

como, por exemplo, propósito/objetivo do agente ou sua arquitetura. [FRA96; NWA96;
WOO99] apresentam tipologias específicas para a classificação de agentes, mas se abordará
as categorias propostas por [FER99], quais sejam: agentes em reativos e agentes deliberativos.

Os agentes reativos reagem às mudanças do ambiente ou às mensagens provenientes

de outros agentes, porém não são capazes de raciocinar sobre suas intenções [MOU96]. As
suas reações são provenientes de regras pré-definidas e sensíveis a estes estímulos. A Figura
2.6 apresenta uma possível arquitetura para este tipo de agente, proposta por [RUS95].
Também, não possuem capacidade de planejar, porém comunicam-se enviando, recebendo e
interpretando mensagens.

Figura 2.6 - Arquitetura de um agente reativo [RUS95]

 53

Esta abordagem reativa foi introduzida por [BRO86] no domínio da robótica. Ante a
fala de resultados satisfatórios dos robôs baseados em sistemas cognitivos, principalmente em
ambientes dinâmicos e desconhecidos, ele propôs robôs bem mais simples, baseados em ações
elementares ativadas diretamente em resposta a determinados estímulos (percepção), segundo
uma prioridade pré-definida [ALV97]. Neste sentido, segundo [ALV97; HÜB03], as
principais características dos agentes reativos são:

• Não há representação explícita de conhecimento: o conhecimento dos agentes é

implícito (no código) e se manifesta através do seu comportamento;

• Não há representação do ambiente: o seu comportamento se baseia no que é

percebido a cada instante do ambiente, mas sem uma representação explícita deste;

• Não há memória das ações: os agentes reativos não mantêm um histórico de suas
ações, de forma que o resultado de uma ação passada não exerce nenhuma
influência sobre as suas ações futuras.

Em função das suas simplicidades, os agentes reativos geralmente possuem um

conjunto específico e limitado de capacidades [BOR01]. Desta forma, em alguns casos, para
solucionar-se um problema, é necessário definir um conjunto de agentes reativos, os quais
formam uma sociedade. Os sistemas que possuem mais de um agente especificado
denominam-se Sistemas Multiagentes (SMAs). Estas sociedades podem ser formadas por
agentes reativos ou cognitivos, ou mesmo uma combinação de ambos os tipos de agentes
[WOO95]. Segundo [ALV97; HÜB03], os SMAs reativos têm, em geral, um grande número
de agentes, da ordem de dezenas, centenas ou mesmo milhões de agentes, dependendo a
complexidade do problema a ser resolvido. Quanto às sociedades formadas por agentes
cognitivos, estas são tipicamente compostas por poucos agentes, na ordem de uma dezena
[ALV97; BOR01].

Sobre os agentes cognitivos, estes são capazes de raciocinar a partir de suas intenções
e crenças, criar planos de ações, executá-los e revisá-los, caso seja necessário [MOU96].
Esses agentes são considerados como sistemas de planejamento, pois podem selecionar seus
objetivos, de acordo com sua motivação e raciocinar sobre eles (detecção e resolução de
conflitos entre seus planos). Segundo [ALV97; FER91], suas principais características são:
 54

• Mantêm uma representação explícita (no código) de seu ambiente e dos outros
agentes que interagem consigo;

• Podem manter um histórico das interações e ações passadas, isto é, têm memória
do passado;

• A comunicação entre os agentes do ambiente é feita de modo direto, através do

envio e recebimento de mensagens;

• O mecanismo de controle entre os agentes do ambiente é deliberativo, ou seja, os

agentes raciocinam e decidem sobre quais objetivos devem alcançar, que planos
seguir e quais ações devem ser executadas em um determinado momento.

Da mesma forma que propôs uma arquitetura para os agentes reativos, [RUS95]
também apresentou uma definição de arquitetura para os agentes classificados como
cognitivos (Vide Figura 2.7).

Figura 2.7 - Arquitetura de um agente cognitivo [RUS95]

Para manterem o funcionamento de uma sociedade (ou SMA), os agentes precisam

desempenhar funções de cooperação, negociação, coordenação, comunicação e planejamento.
A cooperação diz respeito à iniciativa dos agentes de buscarem atingir seus objetivos de
forma conjunta, uma vez que mais de um agente pode ter objetivos em comum [WOO01].
Para que esta cooperação possa ser planejada, é necessário que haja uma coordenação entre
 55

os agentes. Segundo [HUH99], coordenação é a capacidade que um SMA possui de realizar

atividades em um ambiente compartilhado de maneira ordenada, evitando conflitos entre os
objetivos a serem atingidos pelos agentes. A negociação é outro recurso adotado pelos
agentes para buscar resolver conflitos de objetivos. Dando suporte à coordenação entre os
agentes e propiciando a negociação entre os mesmos, tem-se a comunicação. Esta é uma
forma de interação através de ações lingüísticas explícitas, na qual os agentes trocam
informações entre si [MOU96]. Outra forma de interação é através de ações não lingüísticas,
na qual os agentes modificam o ambiente no qual estão atuando. Por fim, para que possam
atuar em conjunto em busca de atingir seus objetivos, os agentes devem estabelecer planos. O
planejamento é fundamental para que os agentes organizem a realização de suas atividades
em uma determinada ordem e estabeleçam a conseqüência das mesmas [MOU96].

Segundo [ALV97; HÜB03], a especificação dos agentes em reativos e cognitivos

reflete duas abordagens do estudo da inteligência: a IA baseada em conhecimento e a IA
baseada em comportamento. Esta última enfatiza a modelagem e a construção de sistemas que
se comportam em algum domínio. O agente AMIGO apresentado neste trabalho (vide
Capítulo 5) caracteriza-se como reativo, uma vez que este está estruturado de forma que
detecte e responda a estímulo do ambiente, o que caracteriza a definição do seu
comportamento no ambiente que está atuando.

2.4 Recursos tecnológicos

Levando-se em consideração o contexto desta pesquisa, a qual tem como objetivo

apresentar um mecanismo de monitoramento e gerenciamento de informações geradas através
do uso de um ambiente virtual (disponível na Web) de apoio ao processo de ensino-
aprendizagem, fez-se uma análise inicial sobre as opções de linguagem de programação que
dão suporte ao desenvolvimento de aplicação para a Web. Dentre as mais conhecidas e usadas
recentemente, tinha-se a oportunidade de adotar a linguagem Java [SUN03a] ou a ASPx
[ASP03], da Microsoft. Como o grupo de pesquisa ao qual este projeto está vinculado
(GIE/FACIN da PUCRS) possui como premissa disponibilizar todos os resultados das
pesquisas desenvolvidas para a comunidade acadêmica e interessados (incluindo códigos-
fonte), um dos critérios para a seleção da linguagem de programação foi a isenção de custo
para o desenvolvimento (ferramentas) e utilização. Outro critério levado em consideração foi
 56

a possibilidade da aplicação funcionar no sistema operacional Linux, por ser este o sistema
instalado no servidor Web que o grupo tem a sua disposição. Sendo assim, optou-se pela
linguagem Java. Outras características desta linguagem, as quais contribuíram para a escolha
da mesma, são apresentadas na Seção 2.4.1.

A partir da opção pela linguagem Java, possíveis formas de desenvolvimento com a

mesma foram estudadas e, como resultado, adotou-se as tecnologias denominadas Servlets
[SUN03b] e Java Server Pages (JSP) [SUN03c], por estas serem específicas para o
desenvolvimento para a Web. Para a escolha do Banco de Dados (BD) utilizou-se o mesmo
princípio que norteou a escolha da linguagem de programação, o de não apresentar custo para
sua utilização, bem como o critério de suportar um grande volume de dados, visando o uso do
ambiente em caráter experimental em situação real de sala de aula (mesmo sabendo à priori
que, como resultado no escopo deste trabalho de Mestrado, apresentar-se-ia apenas um
protótipo do ambiente e do agente10.). Sendo assim, identificou-se a possibilidade de utilizar
ou o BD Oracle [ORA03] ou o MySQL [MYS02]. Apesar do primeiro ser disponibilizado
nas dependências da FACIN, este exige licença de uso, o que nos inviabiliza de colocar à
disposição o software para os demais parceiros de pesquisa ou interessados que não possuam
também esta licença. Desta forma, adotou-se o bando de dados MySQL, o qual é distribuído
gratuitamente. Por terem sido adotadas no desenvolvimento dos protótipos do ambiente
PROOGRAMA e do agente AMIGO, as tecnologias mencionadas são brevemente
apresentadas nas seções a seguir.

2.4.1 Java

Java é uma linguagem robusta, independente de plataforma ou sistema operacional e

totalmente orientada a objetos, permitindo a modularização e reuso do código implementado
[BIG01]. Originalmente, foi desenvolvida para atender sistemas de tempo real que atendem o
mercado de eletrônicos em geral, tal como provedores de canais de televisão a cabo. Seus
desenvolvedores usavam a linguagem C e/ou C++ e desejavam ter à disposição uma
linguagem independente do hardware, para poder atender os diferentes recursos usados no
mercado de eletrônicos. Entretanto, como o retorno neste mercado não foi o esperado e a

10
Salienta-se que, com a continuidade do projeto e aumento da complexidade das funcionalidades e ferramentas
disponibilizadas, talvez esta decisão deva ser reavaliada, uma vez que o MySQL não suporta uma série de
recursos mais avançados (Vide último parágrafo da Seção 2.4.5).
 57

popularidade da Internet estava no seu auge, os esforços foram direcionados para aplicações
disponibilizadas através da Web.

Diferentemente das tradicionais linguagens de programação, o código em Java não é

traduzido para uma linguagem de máquina de uma plataforma particular. Segundo [BIG01;
DEI00], seu código-fonte (arquivo .java) é compilado para um código intermediário, próximo
às instruções de máquina, chamado byte-code (arquivo .class). Estes byte-codes podem ser
executados por qualquer sistema operacional onde a Máquina Virtual Java (JVM – Java
Virtual Machine) esteja instalada. A JVM é a responsável pela execução dos byte-codes,
interpretando-os para a linguagem do sistema operacional onde está instalada. É este sistema
de compilação e execução que torna Java uma linguagem portável. Ou seja, independente de
sistema operacional.

Segundo [BIG01; NEW97], outras características desta linguagem são:

• É uma linguagem tipada;

• Exceto por alguns tipos primitivos, tais como números inteiros e flutuantes, quase
tudo na linguagem é tratado como um objeto, sendo que as referências a estes
objetos não são ponteiros como em C e sim vetores. O uso destes vetores traz
benefícios em termos de segurança;

• Possui mecanismos de tratamento de exceções, o qual evita que as aplicações

parem seu funcionamento em condições anormais;

• Possui um mecanismo, denominado garbage collector, de gerência dos objetos, o

qual controla a memória e descarta aqueles objetos que não mais necessários ao
funcionamento do programa;

• Fornece suporte à programação multi-thread, isto é, permite a criação de várias

linhas (threads) de execução simultaneamente;
 58

• Oferece suporte à programação de sistemas distribuídos, através dos recursos de

programação com sockets, RMI (Remote Method Invocation), TCP/IP (Transfer
Control Protocol/Internet Protocol), BD, entre outros.

A linguagem se popularizou com pequenos aplicativos chamados applets. Estes

aplicativos são incluídos em páginas HTML e executam, geralmente, dentro dos navegadores
para a Internet [KUR02]. Com a sua popularização, a linguagem evoluiu para aplicações que
funcionam de forma independente, organizadas em diferentes plataformas, as quais atendem
campos específicos de desenvolvimento. Como exemplo, pode-se citar as plataformas J2SE
(Java 2 Platform Standard Edition), para aplicações que trabalham isoladamente
(standalone); e J2EE (Java 2 Platform Enterprise Edition), para aplicações Web.

Segundo [COP03; SUN03d], a plataforma J2EE oferece um modelo de aplicação

distribuída com vários níveis, capacidade para reusar componentes, integração com XML
(eXtensible Markup Language) para troca de dados, modelo de segurança unificado e um
controle de transações flexível. Os níveis são organizados da seguinte forma: camada do
cliente; camada de negócios e camada de gerenciamento de informações. A Figura 2.8
apresenta a organização destas camadas e as tecnologias podem ser usadas em cada uma das
mesmas.

Java Applet HTML JSP

Dinâmico

Camada cliente

Enterprise
Servlets
Beans

Camada de negócios

Banco de
dados
Camada de informações


Figura 2.8 - Camadas (ou níveis) da plataforma J2EE
 59

A camada do cliente é responsável por apresentar a interface de interação com o

usuário final. Para implementá-la, pode-se usar Java, applets, HTML dinâmico ou JSP. Esta
camada deve resolver apenas aspectos relativos à interface gráfica com o usuário, deixando
para a camada de negócios a implementação das regras do negócio em questão, bem como o
acesso à camada de informações. Cabe ainda a camada de negócios analisar as solicitações
oriundas da camada cliente e responder a estas solicitações, acessando ou não a camada de
informações. Para a camada de negócios, tem-se servlets e Enterprise Beans como opção. Por
fim, a camada de informações, em geral, é representada por um BD [COP03].

Ainda segundo [COP03], normalmente, os componentes da camada de interface

executam na máquina cliente, exceto o JSP; a camada de negócios executa na máquina que
está servindo a plataforma J2EE; e a camada de informações, na máquina servidora de BD.
Pode ocorrer destas camadas estarem concentradas em uma única máquina.

2.4.2 Servlets

Servlet é uma das mais importantes tecnologias Java e a base para o desenvolvimento
de aplicações para a Web usando esta linguagem de programação. Surgiu em 1996,
desenvolvido pela Sun Microsystems11, a partir da necessidade de sanar a deficiência dos
CGIs (Common Gateway Interfaces) em tratar grandes quantidades de informações
dinâmicas12 associadas a páginas HTML [KUR02]. Segundo [HOR 00; HUN 02 apud LIC03;
SUN03b], algumas de suas principais características são:

• Geração dinâmica de páginas HTML: Os servlets podem ser instalados em

servidores Web para processar informações transmitidas via HTTP (HyperText
Transfer Protocol), como, por exemplo, a partir de formulários HTML. As suas
aplicações podem incluir acesso a BD, comunicação com outros servlets ou
sistemas legados e até mesmo o envio de e-mail;

• Modularização do código: Um servlet pode executar outro servlet, mesmo que

remotamente. Desta forma, é possível executá-los em corrente. Esta característica
11
http://www.sun.com
12
As chamadas páginas dinâmicas consistem em porções de código (scripts) inseridos em páginas HTML e
processados pelo servidor Web antes de serem enviadas para os usuários [LIC03]
 60

possibilita modularização dos aplicativos, criando servlets com funções bastante

específicas;

• Eficiência e durabilidade: Ao ser carregado, um servlet permanece na memória do

servidor, como uma única instância do objeto, mantendo automaticamente seu
estado e podendo manter os recursos externos, tal como uma conexão a um BD.
Desta forma, não precisam ser executados a cada nova consulta, exceto se for
detectada uma nova versão do mesmo. Neste caso, esta nova versão é executada e
carregada novamente na memória do servidor;

• Independência de servidor e plataforma: Por serem implementados em Java, os

servlets herdam todas as características desta linguagem, entre elas, a
portabilidade.

Segundo [COP03; NET02], servlet é um programa simples implementado em Java que

estende a capacidade dos servidores de aplicação acessados através de um modelo de
programação do tipo “requisição-resposta”. Para tal, deve usar algum protocolo de
comunicação. Apesar de implementar uma classe específica para o HTTP, o servlet dá suporte
aos protocolos SMTP (Simple Mail Transfer Protocol), HTTPS (HTTP Security) e IRC
(Internet Relay Chat) [HUN02].

Toda classe servlet deve implementar a interface Servlet, utilizando-se dos pacotes
javax.servlet e javax.servlet.http [KUR02]. Nesta interface estão definidos todos os
métodos para estabelecer a comunicação com clientes. A comunicação entre uma classe
servlet e um cliente se dá por meio de dois objetos instanciados das classes: ServletRequest e
o ServletResponse. A primeira encapsula as funções de comunicação do cliente para o
servidor, permitindo que a servlet receba dados, tais como os oriundos de formulários HTML,
conforme mencionado. A segunda, por sua vez, permite que os dados sejam transmitidos para
a máquina cliente [LIC03]. As Figuras 2.9 e 2.10 apresentam, respectivamente, os códigos-
fonte da página HTML e da classe servlet de um exemplo tradicionalmente encontrado em
livros para iniciantes em programação de computadores, denominado “Hello World”. Este
exemplo tem como objetivo apresentar na tela do usuário a frase “Hello World!” após o botão
disponível ser apertado.
 61

Outra característica de um programa servlet é que este possui um ciclo de vida pré-
estabelecido, determinado por três métodos da interface Servlet, quais sejam: init, service e
destroy [DEI00; KUR02]. O init() é o primeiro método executado no momento em que o
servlet está sendo carregado. É através deste método que ocorre a leitura das configurações
estabelecidas pelo sistema e a inicialização das estruturas de dados. Caso um servlet precise se
conectar a uma base de dados durante sua execução, é através deste método que esta conexão
será estabelecida. O método service() é o responsável por receber a requisição e retornar a
resposta ao cliente. Para tal, o método recebe um objeto do tipo ServletRequest e devolve um
do tipo ServletResponse. Para remover o servlet da memória do servidor, o método deploy()
deve ser invocado. Caso necessite de memória e seja detectado que o servlet não está sendo
utilizado no momento, o método será ativado automaticamente, liberando espaço [KUR02].

<HTML>
<HEAD>
<TITLE>Exemplo de servlet usando o metodo GET</TITLE >
</HEAD>
<BODY>
<FORM
ACTION=”http://localhost:8000/HelloApp/servlet/MeuHelloWorldExample”
METHOD=”GET”>
<P>Clique o botão para acionar a servlet!</P>
<INPUT TYPE="submit" VALUE="Buscar página">
</FORM>
</BODY>
</HTML>

Figura 2.9 - Exemplo Hello World: código-fonte da página HTML [COP03]

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;

public class MeuHelloWorldExample extends HttpServlet {

public void doGet (HttpServletRequest request, HttpServletResponse response)
throws IOException, servletException
{
response.setContentType(“text/html”);
PrintWriter out = response.getWriter();

out.println(“<HTML>”);
out.println(“<HEAD>”);
out.println(“<TITLE> PAGINA TESTE </TITLE>”);
out.println(“</HEAD>”);
out.println(“<BODY>”);
out.println(“<H1> Hello World! </H1>”);
out.println(“</BODY>”);
out.println(“</HTML>”);
out.close();
}
}

Figura 2.10 - Exemplo Hello World: código-fonte da classe servlet [COP03]

 62

A grande desvantagem de usar puramente servlets é a sua manutenção. Cada alteração

no HTML que compõe a interface gráfica é necessária a intervenção do programador para
alterá-lo. Isto não permite uma independência do projetista de interfaces, a menos que este
domine esta tecnologia. Para evitar esta dependência e modularizar as camadas do cliente e a
de negócios, a Sun Microsystems propôs a tecnologia denominada JSP como solução.

2.4.3 Java Server Pages

De acordo com a própria Sun [SUN03c], “JSP é uma extensão da tecnologia servlet,
criada para dar suporte à geração de páginas HTML e XML, sendo possível combinar dados
estáticos com dinâmicos de forma bastante simples”. Em outras palavras, uma página JSP é
um documento texto que contém dois tipos de texto: o estático, que pode ser expresso em
HTML ou XML, entre outros; e o dinâmico, expresso através de elementos JSP, responsáveis
por construir as informações dinâmicas [COP03]. Com esta solução, passou a ser possível
alterar a interface de uma página sem a necessidade de alterar o seu conteúdo.

Segundo [KUR02; NET02], ao ser chamada por um usuário pela primeira vez, uma
página JSP é compilada gerando um servlet que, posteriormente, constrói de forma dinâmica
esta página e retorna o resultado ao cliente, para apresentação no seu navegador. Esta
compilação só ocorre no caso do servlet associado à página JSP não existir ou a versão desta
página ser mais atual que a versão do servlet existente. Isto evita que chamadas posteriores a
página JSP gerem novas compilações, aumentando assim o rendimento do sistema.

A Figura 2.11 apresenta o código-fonte de uma página JSP. Este simples exemplo
apresenta na interface para o usuário dois botões, SomaGlobal e ZeraGlobal, os quais
implementam um contador e zeram o valor deste contador, respectivamente, dependendo o
botão que for acionado. Os trechos limitados entre os caracteres “<%” e “%>” indicam
elementos JSP. Uma vez que a tecnologia JSP faz parte do pacote J2EE, esta também utiliza
a linguagem Java, o que lhe proporciona independência de plataforma e servidor. Informações
sobre a sintaxe proposta podem ser encontradas em [SUN03c].
 63

<%@ page import=”javax.ejb.*, javax.naming.*, javax.rmi.*, java.util.*” %>

<%!
Private int contGlobal = 0;
%>
<HTML>
<HEAD>
<TITLE>Contador Demo</TITLE >
</HEAD>
<BODY>
<H1>CONTADOR</H1>
<P><P>
<FORM METHOD=”GET” ACTION=”Contador.jsp”>
<INPUT TYPE="submit" NAME=”botao” VALUE="SomaGlobal">
<INPUT TYPE="submit" NAME=”botao” VALUE="ZeraGlobal">
</FORM>
<%
String acao = request.getParameter(“botao”);
%>
<P> Ação: <%=acao%>
<%
if (scao != null) {
if (acao.equals(“SomaGlobal”)) {
contGlobal++;
}
if (acao.equals(“ZeraGlobal”)) {
contGlobal = 0;
}
}
%>
<P> Contador global: <%=contGlobal%>
</BODY>
</HTML>

Figura 2.11 - Exemplo Contador: código-fonte da página JSP [COP03]

2.4.4 Tomcat

Para compilar os códigos desenvolvidos nas tecnologias servlet e JSP, a plataforma

J2EE utiliza uma interface que especifica a comunicação de cada uma destas tecnologias
(também denominadas componentes J2EE) com a plataforma. A esta interface, que integra
o componente com uma funcionalidade de baixo nível dependente de plataforma que suporta
o próprio componente, dá-se o nome de contêiner13 [COP03]. O contêiner que dá suporte
tanto à tecnologia servlet como a JSP mais conhecido e utilizado atualmente é o Tomcat
[KUR02]. Outro exemplo de contêiner deste tipo é o JRun [ALL03], da Allaire Corporation,
sendo que apenas a sua versão classificada como Developer é de distribuição gratuita para

13
Do original em Inglês, Container.
 64

fins de estudo. O Tomcat é o contêiner oficialmente reconhecido pela Sun, apesar de ser
mantido pelo Projeto Jakarta14, da Apache Software Foundation desde 1999.

Por ser uma implementação de código aberto, o Tomcat tem sido incorporado a
diversos servidores de aplicação, permitindo a melhoria de suas versões por diferentes grupos.
Segundo [JAM 03 apud LIC03], é composto por três componentes principais:

• Catalina: tem a função de gerenciar o ciclo de vida dos servlets, decidindo quando
gerar novas instâncias ou quando descartá-las para a liberação de memória, bem
como é o responsável pelo mapeamento de URLs para os servlets, fazendo a
devolução do documento gerado, em geral uma página HTML;

• Jasper: é um servlet padrão que fornece o suporte à execução de páginas JSP,

gerando e compilando o servlet correspondente a cada página;

• Coyote: é o conector responsável por tornar o Tomcat um servidor Web, podendo

ser configurado para suportar outros recursos de um servidor padrão deste tipo,
como, por exemplo, a execução de programas CGI.

Em função do componente Coyote, o Tomcat também pode ser utilizado como um

servidor Web. Ou seja, pode ser usado para prover serviços de requisição aos servlets e
páginas estáticas, entre outros. Apesar desta facilidade, o Tomcat não oferece o mesmo
desempenho de servidores Web específicos, tais como o Apache ou o Internet Information
Server (IIS) da Microsoft, uma vez que foi otimizado para atender servlets e páginas JSP. É
ideal para trabalhar-se em ambiente de desenvolvimento.

2.4.5 MySQL

O MySQL é um Sistema de Gerenciamento de Banco de Dados (SGBD) relacional

com código aberto [MYS02], desenvolvido e distribuído gratuitamente pela empresa MySQL
AB. Esta empresa é formada por desenvolvedores do próprio SGBD, os quais geraram esta

14
A Sun cedeu o código-fonte inacabado deste contêiner para a Apache, a qual o incluiu no Projeto Jakarta,
dedicado ao estudo de tecnologias servlet e JSP. Este projeto agrega outros dois grandes subprojetos, o
Watchdog (ferramenta para validar servlets e páginas JSP) e o Taglibs (um repositório de tags JSP) [SUN03e].
 65

versão baseada no mSQL, em função do mesmo não estar mais atendendo as necessidades de
velocidade e flexibilidade esperadas pelo grupo para o desenvolvimento de suas aplicações.

Por ter sido concebido para manipular uma base de dados com maior rapidez e isto ter
se confirmado após um conjunto de testes, o MySQL é um servidor de BD ideal para a
Internet [MYS02]. Além disto, também oferece segurança no tratamento de requisições e uma
gama de opções de conexão com o servidor do BD, entre elas, sockets TCP/IP e ODBC
(Open-DataBase-Connectivity).

O MySQL consiste de um servidor SQL (Structured Query Language) multi-thread

que suporta diferentes backends, vários programas clientes e bibliotecas, ferramentas
administrativas e uma interface de programação. Como principais características, pode-se
citar: (i) Implementa a mais comum das linguagens de consulta a dados, a SQL; (ii) Suporta
grandes bases de dados (o número de registros estimados esta na ordem dos cinqüenta
milhões); (iii) Pode ser utilizado por várias linguagens de programação, tais como C e Java;
(iv) Oferece suporte a várias línguas e seus caracteres especiais, entre elas, a inglesa, a
polonesa e a tcheca; (v) Funciona em diversas plataformas (ex. Windows e Linux [MYS02]).

Este gerenciador é um dos servidores mais rápidos do mercado. Isto ocorre,

principalmente, em função da equipe que compõe a empresa MySQL AB ter tomado como
objetivo principal a otimização do código e operações em detrimento ao desenvolvimento de
recursos mais complexos. Desta forma, entre as principais desvantagens, [RUS00 apud
DRU03] aponta a falta de recursos mais avançados. Ao contrário de outros sistemas de BD
mais evoluídos, o MySQL não tem muitos recursos importantes e imprescindíveis para o
desenvolvimento de projetos de grande complexidade, como, por exemplo, suporte à
transações, à stored procedures e a triggers. Uma vez que estes recursos não se fazem
necessários nesta etapa do projeto, esta desvantagem não influenciou a decisão pela adoção
deste BD. Maiores detalhes sobre o MySQL podem ser encontrados no manual técnico
disponibilizado pelos próprios criadores do gerenciador em [MYS02].

Conforme mencionado anteriormente, as tecnologias apresentadas foram utilizadas no

desenvolvimento dos protótipos do ambiente PROOGRAMA e do agente AMIGO. Para
prover a interface gráfica com o usuário, utilizou-se JSP. Inicialmente, gerou-se o código
estático das páginas (HTML), através do editor HTML da Microsoft, o FrontPage, e depois
 66

se acrescentou o código relativo à parte dinâmica (elementos JSP). Logo em seguida,

desenvolveu-se o código equivalente a lógica da aplicação (camada de negócio), utilizando-se
a tecnologia Servlet, a qual consulta os dados disponibilizados no BD. A modelagem e a
estrutura física do BD, implementada através do SGBD MySQL, foram desenvolvidas
concomitantemente à definição e elaboração da interface gráfica, sendo que quando da
elaboração dos servlets já foi possível realizar as consultas no BD. Para disponibilizar os
códigos-fonte no servidor que se encontra disponível para o grupo de pesquisa e validar os
servlets, utilizou-se o Tomcat. A linguagem Java foi utilizada para desenvolver a
comunicação entre os servlets e JSP com o BD, através da definição de uma API (Application
Programming Interface). Ou seja, isolou-se a camada de informações das demais através da
API implementada em Java. Detalhes sobre a modelagem do ambiente e do agente, bem como
da implementação de ambos são apresentadas no Capítulo 6.
 67

3 A METODOLOGIA UTILIZADA PARA SUPORTE AO

PROCESSO DE ENSINO-APRENDIZAGEM

A metodologia de suporte ao processo de ensino-aprendizagem utilizada como aporte

para definição do ambiente PROOGRAMA e do agente AMIGO usa como passo inicial a
organização do conteúdo a ser trabalhado de forma que os pré-requisitos, co-requisitos e as
inter-relações entre eles sejam explicitadas. Permitindo, assim, um melhor planejamento das
aulas das disciplinas de Algoritmos e Estruturas de Dados e Laboratório de Programação de
Computadores, doravante apenas denominadas Algoritmos e Lapro. Esta organização é feita
através da utilização de Mapas Conceituais (MCs) dos conteúdos a serem ministrados. Os
MCs são representações gráficas que indicam relações entre conceitos [AUS80]. Os
conteúdos são colocados em nodos e as ligações expressam as relações entre estes nodos.
Podem ser utilizados para organizar conceitos mais abrangentes até os menos inclusivos. São
utilizados para auxiliar a ordenação e o seqüenciamento hierarquizado dos conteúdos de
ensino, de forma a auxiliar a oferecer estímulos ao aluno. O mapa pode ser feito diretamente
no papel, de forma rascunhada, ou com o auxílio de uma ferramenta específica para
elaboração de MCs, como o caso da CmapTool, do IHMC – Institute for Human and
Machine Cognition [IHM01]. A elaboração do mapa auxilia o professor a organizar os
conteúdos da sua disciplina de forma a explicitar as suas inter-relações. Ou seja, qual
conteúdo depende de outro, qual conteúdo deve ser apresentado antes, quais são os pré-
requisitos que o aluno deve ter para entender este conteúdo e que outros tópicos da disciplina
vão utilizar este conteúdo. Um exemplo, elaborado através da ferramenta citada, abrangendo
parte dos conceitos abordados na disciplina de Lapro é apresentado na Figura 3.1. Depois dos
conteúdos organizados nos MCs, faz-se a organização das aulas em função do cronograma do
semestre.
 68

Figura 3.1 – Exemplo de mapa conceitual parcial dos conceitos da disciplina Lapro

A partir da organização do conteúdo, parte-se para a elaboração dos materiais a serem

utilizados nas aulas e a identificação dos recursos de apoio (listas de exercícios, exemplos,
sistemas de ajuda, etc.). Os tipos de recursos até então utilizados para suporte às atividades
não presenciais baseiam-se nos seguintes serviços:

• Página WWW – World Wide Web (incluso FTP): local onde são
disponibilizados os materiais das disciplinas, o que inclui conteúdos, agenda das
atividades mês-a-mês, registro das interações, descrição das atividades de aula ou
extraclasse, materiais complementares e uma biblioteca virtual e digital, dentre
outros;

• E-mail: utilizado para envio e recebimento de tarefas complementares,

esclarecimento de dúvidas e comunicação privada do professor com seus alunos e
vice-versa;

• Lista de discussão: criada para complementar o trabalho desenvolvido nos

encontros síncronos e servir de espaço para as contribuições dos alunos, e envio de
informações do professor para o grupo e entre seus participantes.

A metodologia utilizada na condução das disciplinas baseia-se na resolução de

problemas organizados em ordem crescente de complexidade. Toda a questão da leitura da
teoria referente aos conteúdos fica por conta do aluno. Em geral, quando estes possuem
 69

alguma dúvida sobre algum termo novo descoberto durante a leitura (ou mesmo no decorrer
das aulas), a professora solicita que os alunos investiguem seu significado e enviem o
resultado da pesquisa para ser disponibilizado aos demais colegas. Desta forma, a leitura e
pesquisa são incentivadas. Quando da adoção de algum livro, a seqüência de leitura para este
recurso é indicada na página da disciplina. A agenda, também disponibilizada na página,
permite ao aluno conhecer o cronograma da disciplina.

Cada aula inicia com um resumo dos principais pontos indicados para leitura e depois
são desenvolvidas atividades práticas relacionadas com a lista de exercícios disponibilizada
previamente na página (Esta lista também é entregue durante a aula).

A capacidade de resolver um problema e expressar a solução, via um algoritmo, vai

requerer que o aluno saiba analisar o problema que recebeu e seja capaz de situá-lo dentro de
um contexto onde existem diversas classes de problema. Depois disto, o aluno deve ser capaz
de perceber os componentes que constituem aquele problema, ter ciência da solução esperada,
identificar os dados disponíveis para serem computados e, finalmente, organizar uma
estratégia de solução baseada nos seus pré-requisitos. Podendo, também, complementar os
dados iniciais fornecidos pelo enunciado, caso seja necessário. Esta etapa de pré-análise do
problema pode ser feita de forma mais informal, motivando o aluno a explorar de forma mais
livre o enunciado do problema, fazer conjecturas a respeito de sua interpretação, verificar se
os colegas possuem a mesma percepção do problema e outras. Logo, é importante que se crie
hábitos de leitura crítica dos enunciados. Isto é, os alunos invistam tempo em uma leitura
criteriosa do enunciado que receberam. Para tal, a professora conduz esta atividade lendo o
enunciado ou solicitando a um dos alunos que o faça.

Evita-se a resolução dos exercícios por parte da professora e busca-se uma postura
menos diretiva por parte desta. O problema será resolvido utilizando as contribuições dos
alunos. Neste caso, a professora funciona como elemento mediador que coloca as informações
no quadro e as disponibiliza para todos os alunos. Ou seja, pode ser vista como facilitador e
não um guia que apresenta uma solução passo-a-passo. A professora incentiva os alunos a
colocarem suas soluções (corretas ou não) para serem compartilhadas com os colegas. Desta
forma, a turma pode constatar que não existe um modelo único de solução. Cada pessoa é um
ser único no sentido de processar as informações. Cada um pode perceber os problemas de
forma diferente. Logo, cada um elabora soluções diferentes e todas estas soluções podem estar
 70

atendendo ao problema. O que vai ocorrer é que algumas soluções são mais otimizadas
(melhor elaboradas) do que outras. Não se pode exigir que um aluno, em uma fase inicial de
construção de conhecimento, além de conseguir elaborar o algoritmo, desenvolva-o de forma
otimizada. A etapa de otimizar (melhorar o algoritmo já elaborado) é subseqüente ao processo
de elaboração da primeira versão. Esta etapa é muito mais complexa e difícil para o aluno
iniciante.

A fim de reforçar o processo de construção de diferentes soluções para um mesmo

problema, disponibiliza-se na página da disciplina (link devidamente etiquetado) vários
exemplos de soluções construídas por outros alunos (até de turmas anteriores) e monitores. A
monitoria desempenha um papel importante neste contexto. Os alunos têm oportunidade de
conversar sobre suas dúvidas com outro colega mais experiente. Em muitas situações, outro
colega com faixa etária próxima e mesmo curso (ou curso de mesma área do conhecimento)
consegue promover a mediação melhor que a professora. Mas, caso deseje, o aluno pode
procurar esclarecer suas dúvidas diretamente com a professora. Para tal, esta organiza um
sistema de atendimento através do e-mail. O aluno deve enviar sua solicitação de ajuda
acompanhada do código-fonte do programa, a tela capturada com a mensagem de erro e a
justificativa pela qual não conseguiu resolver e/ou depurar o problema. Desta forma, a
professora induz os alunos a pensarem e refletirem sobre o problema, recorrendo a ela e,
conseqüentemente ao monitor, somente depois de terem buscado a solução para o problema
em questão. Todas as atividades da monitoria são supervisionadas pela professora.
Eventualmente a mesma delega ao monitor a atualização da página da disciplina (com
materiais elaborados pela professora, alunos e/ou o próprio monitor) e a organização das
discussões que ocorrem na lista de discussões. Esta prática aproxima o monitor da realidade
da disciplina, fazendo-o sentir-se parte da turma.

Esta experiência com uso destes espaços virtuais como elementos de extensão e
mediação das atividades da sala de aula presencial resultou em vários pontos positivos na
condução da disciplina e no aproveitamento dos alunos. Esta abordagem vem sendo utilizada
pela professora orientadora deste trabalho há oito semestres. A cada semestre foi-se refinando
aspectos operacionais relativos ao uso dos recursos de apoio, distribuição das informações
sobre a disciplina e outros. Os pontos onde foram feitas as maiores alterações são:
 71

• Apresentação de um cronograma geral de atividades para todo o semestre. Para o

aluno ter idéia do volume de trabalho (leituras, exercícios, pesquisas, tarefas
práticas, etc.) a ser realizado;
• Disponibilização dos materiais de forma antecipada (no mínimo duas aulas à
frente);

• Disponibilização das notas das avaliações através do site da Universidade como

fonte de consulta principal15, sendo que a divulgação ocorre complementarmente
em sala de aula ou nos expositores disponibilizados nos corredores das
dependências da Universidade;

• Adequação da tecnologia associada aos recursos para encontros síncronos e

assíncronos. Algumas delas foram se mostrando inadequadas ou obsoletas. Outras
tiveram problemas com os provedores privados utilizados pelos alunos fora da
universidade que este projeto está vinculado (PUCRS);

• Participação do monitor nas atividades da disciplina como se fosse um dos alunos

da turma. Isto permite que ele vivencie as experiências dos alunos e tenha acesso
às listas de discussões.

Pode-se ressaltar como aspectos positivos desta metodologia o envolvimento dos

alunos nas atividades de aula presencial; a mudança de postura dos mesmos no que concerne
o processo de busca e gestão das informações da disciplina; a melhoria das notas nas
avaliações (que passaram a se constituir em pontos de verificação de etapas e não
simplesmente encaradas como provas); e a participação dos alunos enviando materiais e
soluções para serem compartilhadas com os colegas. Em contra-partida, pode-se considerar
como aspecto negativo desta metodologia o enorme volume de informações que o professor e
o aluno têm de gerenciar, como, por exemplo, a grande quantidade de e-mails e documentos
que o professor precisa verificar diariamente. A demanda aumenta, em específico, em datas
próximas a entrega de exercícios e trabalhos solicitados pela professora, uma vez que a
mesma se coloca a disposição de discutir e avaliar versões intermediárias dos trabalhos e,
15
Este serviço vem sendo prestado pela PUCRS desde 2002 a todos os alunos matriculados em cursos de
graduação na Universidade. Os alunos podem consultar as notas das disciplinas que estão matriculados no
semestre letivo corrente através da opção Graus Publicados disponibilizada no link Informações Acadêmico
Administrativas do Aluno do site da Universidade. O acesso a estas informações é restrito a cada um dos alunos.
 72

estes são enviados via e-mail. Este volume de trabalho se dá em função de não existir um
ambiente integrador dos recursos adotados, exigindo que as informações sejam gerenciadas de
forma manual pela professora. Ou seja, a mesma precisa identificar a qual exercício ou
trabalho da turma o e-mail está relacionado, salvar o arquivo anexado, localizá-lo em seu
computador e verificar se corresponde ao tipo de arquivo solicitado, para somente após este
processo tomar conhecimento do conteúdo do arquivo.

Neste contexto, emergiu a necessidade da adoção ou desenvolvimento de um ambiente

para suportar as atividades das disciplinas ministradas (Algoritmos e Lapro) e integrar os
recursos utilizados, atendendo os aspectos metodológicos apresentados. Este ambiente precisa
permitir o monitoramento e a gerência das informações trocadas entre a professora e os alunos
(e destes com a professora) no decorrer da disciplina no que diz respeito ao envio e
recebimento de materiais. Apesar da Universidade disponibilizar um ambiente de autoria de
cursos a distância, este é proprietário e tem seu período de licença limitado na entidade. Desta
forma, resolveu-se criar o ambiente PROOGRAMA e o agente AMIGO, detalhados nos
Capítulos 4 e 5, respectivamente.
 73

4 O AMBIENTE PROOGRAMA

O ambiente PROOGRAMA tem como objetivo dar suporte às atividades de ensino-

aprendizagem relacionadas às disciplinas de Algoritmos e Lapro. Para tal, o ambiente oferece,
através da Web, um conjunto de ferramentas, denominadas ferramentas virtuais, e
funcionalidades que provêem este suporte. Estas funcionalidades e ferramentas são
disponibilizadas aos usuários de acordo com o papel que desempenham no processo de
ensino-aprendizagem. Ou seja, o ambiente oferece diferentes áreas de trabalho conforme o
perfil do usuário. Os perfis definidos são os seguintes:

• Professor: é o responsável pela organização e disponibilização de todo o material

e informações relacionadas a uma disciplina. É quem organiza os fóruns de
discussão, informa a turma dos compromissos relacionados à disciplina e
acompanha a submissão das respostas das atividades solicitadas, para tomar
conhecimento da dedicação e desempenho dos alunos.

• Monitor: é o auxiliar do professor para o esclarecimento de dúvidas dos alunos, de

forma on-line. Alternativamente, o professor pode delegar algumas de suas tarefas
ao monitor e supervisionar suas execuções. O monitor pode receber as tarefas de
manter atualizado os materiais, as bibliografias, a lista de perguntas mais
freqüentemente feitas pelos alunos e as informações gerais sobre a disciplina, bem
como organizar os fóruns de discussão.

• Aluno: é o público-alvo para o qual uma disciplina é organizada. Possui como

responsabilidades consultar os materiais disponibilizados e responder as atividades
solicitadas pelo professor, bem como participar das discussões propostas.

• Administrador: existe apenas um administrador no ambiente. Este é o

responsável por questões operacionais. Ou seja, tem como responsabilidade prover
 74

a infra-estrutura para funcionamento do ambiente (criar acesso aos usuários,

gerenciar suas contas, cadastrar os cursos, as disciplinas e as turmas solicitadas
pelos professores, entre outros). Também é de sua responsabilidade manter o
servidor do ambiente ativo para que este possa ser utilizado.

Cada disciplina pode ser oferecida para diversos cursos e possuir mais de uma turma.
Da mesma forma, o número de uma turma pode ser disponibilizado para mais de uma
disciplina, de diferentes cursos16. Desta forma, o professor deve fornecer os dados do curso,
da unidade acadêmica a que este curso pertence, do nome da disciplina que irá ministrar e do
número da turma quando solicitar ao administrador a formação de uma turma em específico.
Além destes dados, também deve informar o nome, o número da matrícula e o e-mail de cada
um dos alunos que irá cursar esta disciplina na turma indicada. A informação destes dados
pode ocorrer pessoalmente (o professor entrega os dados ao administrador em um encontro
face-a-face) ou através de e-mail.

Figura 4.1 - Tela de acesso à funcionalidade de formação de uma turma

16
Apesar desta definição ter se baseado nas regras estabelecidas pela Universidade a qual este projeto de
pesquisa está vinculado (PUCRS), tomou-se o cuidado de especificar a relação entre os conceitos da forma mais
genérica possível, para permitir a utilização por outras instituições de ensino. A utilização do ambiente também é
possível nas demais Unidades Acadêmicas da Universidade, caso desejado.
 75

Tendo recebido do professor a solicitação de formação de uma turma, o administrador

deve verificar quais informações (unidade acadêmica, curso, disciplina, turma, usuários –
professor, monitor e alunos) já constam registradas no BD do ambiente e cadastrar as que
ainda não constam no mesmo. Após esta verificação e registro dos dados inéditos no BD, o
administrador pode partir para a formação da turma solicitada. A Figura 4.1 ilustra a tela na
qual o administrador possui acesso à funcionalidade de formação de uma turma, bem como
apresenta as demais funcionalidades disponíveis em relação aos inscritos de uma turma (à
esquerda).

Quadro 4.I - Relação das funcionalidades para criação da infra-estrutura do ambiente

FERRAMENTA/ PERFIL DE USUÁRIO

FUNCIONALIDADE PROFESSOR MONITOR ALUNO ADMIN.
INFRA-ESTRUTURA
Criar unidade acadêmica x
Editar unidade acadêmica x
Excluir unidade acadêmica x
Visualizar unidade acadêmica x
Criar curso x
Editar curso x
Excluir curso x
Visualizar curso x
Criar disciplina x
Editar disciplina x
Excluir disciplina x
Visualizar disciplina x
Criar turma x
Editar turma x
Excluir turma x
Visualizar turma x
Criar usuário x
Editar usuário x
Excluir usuário x
Visualizar usuário x
Formar inscritos turma x
Editar turma formada x
Excluir turma formada x
Visualizar turma formada x
Salvar registro andamento x x
disciplina
Excluir registro andamento x x
disciplina
 76

Em relação ao registro das informações sobre as unidades acadêmicas, cursos,

disciplinas, turmas e usuários, é importante que eles ocorram desvinculados da formação de
uma turma em específico, pois isto permite a reutilização dos registros em diferentes
situações. Por exemplo, para uma pessoa que será aluna de uma disciplina e monitora em
outra, basta registrá-la apenas uma vez no ambiente e associá-la com os respectivos perfis às
duas turmas distintas que fará parte. Além de ser responsável por realizar os registros
mencionados, provendo a infra-estrutura para funcionamento do ambiente, o administrador
ainda pode salvar e/ou excluir, a pedido do professor, todo o material e informações
relacionadas ao andamento de uma disciplina. Caso deseje, o próprio professor pode realizar
tais tarefas. Ao salvar estes dados o professor terá um backup de todo o material e poderá
acessá-lo quando desejar, mesmo após ter sido excluído do servidor. O Quadro 4.I relaciona
todas as funcionalidades que dizem respeito à criação da infra-estrutura do ambiente,
apontando quais perfis de usuário possuem permissão para acessá-las.

Figura 4.2 - Tela de acesso ao ambiente PROOGRAMA

Depois de formada uma turma de uma disciplina, os usuários podem dar início a
utilização do PROOGRAMA. Para acessar suas respectivas áreas de trabalho, os usuários
devem utilizar o número da sua matrícula (fornecido pela Universidade); uma senha de
 77

acesso, atribuída quando do registro do usuário pelo administrador do ambiente; e identificar

o curso, a disciplina e a turma que estão vinculados (Vide Figura 4.2). A senha de acesso ao
ambiente é unificada por usuário. Isto é, mesmo que o usuário esteja vinculado a mais de uma
disciplina, este possui uma senha única. Ao acessar o ambiente pela primeira vez, o usuário
deve alterar sua senha, uma vez que esta foi definida pelo administrador (e pode ser um valor
único para toda a turma). O administrador deve fornecer apenas seu número de identificação,
o qual substitui o número da matrícula utilizada no caso dos demais usuários, e sua senha.

Caso o usuário esqueça sua senha de acesso ao ambiente, este pode solicitar que a
mesma seja enviada para sua conta de e-mail. Basta acessar a opção “Esqueci minha senha”
na tela de acesso ao ambiente e informar sua matrícula, e-mail e palavra-secreta. Esta palavra,
a qual o próprio usuário especifica em Informações Pessoais (ferramenta descrita a seguir
neste capítulo), é um mecanismo de segurança caso o usuário necessite solicitar o envio de
sua senha para uma conta de e-mail. Somente o próprio usuário deve saber qual é esta palavra.
Os usuários ainda podem visualizar as informações sobre a equipe responsável e a versão
atual do ambiente, ou enviar um e-mail com sugestões ou comentários gerais sobre o
ambiente, também a partir da tela de acesso do mesmo. O Quadro 4.II apresenta a relação de
funcionalidades disponibilizadas na tela de acesso ao ambiente, bem como relaciona estas
funcionalidades aos perfis de usuário que possuem acesso a cada uma das mesmas.

Quadro 4.II - Relação das funcionalidades disponibilizadas na tela de acesso ao ambiente

FERRAMENTA/ PERFIL DE USUÁRIO

FUNCIONALIDADE PROFESSOR MONITOR ALUNO ADMIN.
LOGIN
Acessar o ambiente x x x x
Lembrar senha x x x
GERAL
Visualizar informações gerais x x x x
sobre o ambiente
Enviar e-mail para a x x x x
coordenação do ambiente

A tela principal da área de trabalho de um usuário apresenta as ferramentas que este

possui acesso, através dos links disponibilizados abaixo de cada figura ou sobre as mesmas,
 78

conforme pode ser observado na Figura 4.3 para a área de trabalho do aluno17 (A tela da área
de trabalho do perfil de usuário Professor pode ser vista no Apêndice A).

Figura 4.3 - Tela principal de acesso a área de trabalho do aluno

As ferramentas estão agrupadas segundo os módulos conceitualmente definidos para a

arquitetura do ambiente, quais sejam: (i) Informações dos Alunos; (ii) Comunicação Pública;
(iii) Comunicação Direta; (iv) Material do Curso; e (v) Teste de Algoritmos. Ainda tem-se o
agente AMIGO, o qual compõe o módulo Monitoramento e Gerência de Informações. A
Figura 4.4 apresenta as ferramentas definidas para cada um dos módulos, bem como o
relacionamento entre os mesmos para o escopo deste trabalho. Esta organização conceitual em
módulos se deu com o objetivo de agrupar as ferramentas com características e afinidades de
objetivo em comum e, assim, facilitar a compreensão dos recursos oferecidos pelo
PROOGRAMA (Quanto à arquitetura física do ambiente, esta é apresentada no Capítulo 6).
Apesar da organização por módulos não existir fisicamente, as ferramentas serão descritas em
diferentes seções, seguindo esta organização.

17
Exceto pelas ferramentas Agenda, Atividades, E-mail e pelo agente AMIGO, as demais possuem apenas caráter
ilustrativo. Isto se deve ao fato deste trabalho de Mestrado ter um escopo de desenvolvimento restrito em relação
a todas as ferramentas definidas para comporem o ambiente.
 79

AMBAP Glossário de termos Material de apoio

ILA
Bibliografia Atividades
Teste de Algoritmos
Material do Curso

Plano de aulas
AMIGO E-mail
Agenda de comprom.

Monitor. e Gerência de Informações

Chat
Mural
Informações pessoais
Moonline Fórum
Expositor de notas

Comunicação Pública Informações dos Alunos Comunicação Direta

Figura 4.4 - Organização das ferramentas do PROOGRAMA em módulos

4.1 Módulo Informações dos Alunos

O módulo Informações dos Alunos disponibiliza duas ferramentas: Informações

Pessoais e Expositor de Notas. A ferramenta Informações pessoais permite a divulgação de
dados pessoais de um usuário para os demais integrantes da turma. O preenchimento destas
informações (data de nascimento, endereço residencial ou profissional, telefone residencial e
celular, endereço da página pessoal, entre outras) e posterior divulgação para os demais
usuários é opcional. Fica a critério de cada usuário decidir se deseja divulgar ou não estes
dados. Assim como [DRU03], acredita-se que as informações complementares sobre o perfil
do aluno podem auxiliar o professor a realizar uma avaliação mais abrangente sobre o
desempenho do aluno no decorrer da disciplina. Além disto, também proporciona que os
alunos busquem informações sobre os colegas, o que pode não ocorrer pessoalmente em
função de diversas razões, tal como a timidez. É ainda através desta ferramenta que os
usuários podem alterar sua senha de acesso e palavra-secreta, bem como qualquer outra
informação pessoal.

Conforme mencionado no Capítulo 3, a PUCRS possui um serviço de disponibilização

das notas referentes às avaliações das disciplinas através do site da Universidade na Intranet.
O ambiente disponibilizará um link para este endereço. Apesar do professor ter este serviço à
sua disposição, opcionalmente este poderá divulgar as notas das avaliações através da
 80

ferramenta Expositor de Notas do ambiente. Esta ferramenta é um mecanismo alternativo e

complementar àquele oferecido pela Universidade, uma vez que o professor pode
disponibilizar não somente as notas de avaliações formais (provas, trabalhos e outras), mas
também daqueles exercícios ou tarefas extras (denominadas avaliações informais) propostas
que não fazem parte do calendário oficial de avaliação da Universidade. Além disto, o
resultado destas avaliações informais também podem ser expressos através de conceitos
qualitativos e não quantitativos, conforme o regimento da Universidade. Para divulgar o
resultado de uma avaliação, o professor deve registrar a mesma no ambiente e logo após
atribuir os respectivos graus ou conceitos a cada um dos alunos. Opcionalmente, o professor
pode incluir uma breve descrição do objetivo da avaliação, o conteúdo abordado e a data de
aplicação, para que os alunos identifiquem mais facilmente a que avaliação se refere a nota a
ele atribuída. O Quadro 4.III apresenta as funcionalidades disponibilizadas pelas ferramentas
do módulo Informações dos alunos, bem como relaciona quais perfis de usuário possuem o
direito de acessar tais funcionalidades.

Quadro 4.III - Funcionalidades das ferramentas do módulo Informações dos Alunos

FERRAMENTA/ PERFIL DE USUÁRIO

FUNCIONALIDADE PROFESSOR MONITOR ALUNO ADMIN.
INFORMAÇÕES PESSOAIS
Incluir informações pessoais x x x
Editar informações pessoais x x x
Excluir informações pessoais x x x
Pesquisar informações pessoais x x x
Visualizar informações pessoais x x x
EXPOSITOR DE NOTAS
Acessar site de notas da PUCRS x x
Especificar avaliação x
Editar avaliação x
Excluir avaliação x
Visualizar avaliação x
Registrar nota x
Editar nota x
Excluir nota x
Visualizar nota x x x
 81

4.2 Módulo Comunicação Pública

Quanto à comunicação entre os integrantes de uma disciplina, esta pode se dar de

forma geral ou direta. A comunicação pública diz respeito à divulgação de informações
relacionadas à disciplina como um todo (compromissos, avisos, objetivos e conteúdos das
aulas, etc.) e esclarecimento de dúvidas sobre os conteúdos estudados. Esta comunicação
caracteriza-se por ser genérica. Ou seja, parte de um usuário para todos os demais. Pode se dar
através das seguintes ferramentas do módulo Comunicação Públical: Plano de aulas,
Agenda de compromissos, Mural de notícias, Moonline (Monitoria On-line) e FAQ
(Frequently Asked Questions – Lista de perguntas mais freqüentemente realizadas). Segundo
[AUL02; FUK00], estas ferramentas fornecem meios para minimizar os problemas
decorrentes do trabalho em grupo e maximizar o compartilhamento de conhecimento entre os
membros deste grupo (no contexto deste trabalho, um grupo diz respeito a uma turma de uma
disciplina). Já a comunicação direta caracteriza-se pela troca de informações direta entre dois
ou mais usuários sobre assuntos diversos e a discussão, entre no mínimo dois integrantes da
disciplina, de assuntos específicos, propostos pelo professor. Esta comunicação pode ocorrer
através das ferramentas E-mail, Chat e Fórum, disponibilizadas no módulo Comunicação
Direta (estas ferramentas são apresentadas na próxima seção). Apesar destas ferramentas
proporcionarem a comunicação de todos para todos, bastando haver uma lista específica para
tal fim, suas concepções foram baseadas na troca de correspondência tradicional [ALM03;
LON97], na qual existe um remetente da informação e um destinatário da mesma. Por esta
razão, atribuiu-se o nome Comunicação direta para este módulo.

Os conteúdos a serem estudados e os conteúdos a serem utilizados durante uma

disciplina podem ser estruturados, por aulas, pelo professor através da ferramenta Plano de
aulas. Para tal, o professor deve especificar o título e o objetivo de uma aula e associar o(s)
documento(s) que será (ão) utilizado(s). Estes documentos podem ser consultados diretamente
pela ferramenta Material de Apoio (descrita na Seção 6.4). O plano assemelha-se ao
cronograma da disciplina, uma vez que, se apresentado inicialmente para o aluno, permite que
o mesmo tenha uma noção geral das atividades que irá desenvolver no contexto da disciplina
e do volume de trabalho a ser realizado. Caso deseje, o professor pode ir atualizando o Plano
de aulas durante o andamento da disciplina.
 82

A ferramenta Agenda de compromissos permite a comunicação de datas, atividades e

eventos relacionados à disciplina, bem como qualquer outro compromisso. Como a agenda é
individual, alternativamente, um usuário pode registrar algum compromisso de ordem pessoal,
pois o mesmo só será visualizado pelo usuário que o inseriu na sua Agenda. O professor é o
único que possui o direito de agendar compromissos para todos os demais integrantes da
turma. Ao especificar um compromisso, o usuário pode solicitar que o ambiente lhe notifique
antecipadamente a proximidade deste compromisso, desde que tenha configurado o agente
AMIGO para fazer tal verificação (Detalhes sobre o objetivo e as possíveis configurações
deste agente são apresentados no Capítulo 5). Neste caso, o usuário poderá definir quanto
tempo antes deseja ser notificado e de que forma, se através do ambiente ou por e-mail. Sendo
assim, é possível definir para cada compromisso um período diferente. Quanto aos
compromissos para toda a turma, agendados pelo professor, cabe a este especificar o período
de notificação deste tipo de compromisso quando da sua definição. A Figura 4.5 apresenta a
visualização de um compromisso individual.

Figura 4.5 - Visualização de um compromisso

 83

Permitindo a divulgação de notícias relacionadas à disciplina (avisos, recados,

novidades, etc.), tem-se a ferramenta Mural de notícias. Com o objetivo semelhante a um
mural tradicional, esta ferramenta proporciona que o professor ou o monitor disponibilize
anúncios de interesse geral e avisos ou recados para os integrantes da turma, podendo associar
um tema à notícia, para posteriormente servir como critério de pesquisa. As notícias podem
ser apresentadas da mais recente para a mais antiga ou pelos temas relacionados. Pode-se
especificar quanto tempo deseja-se que a notícia fique disponível.

Para auxiliar no suporte ao esclarecimento das dúvidas dos alunos, tem-se a ferramenta
Moonline. Conforme já apresentado no Capítulo 2, seu principal objetivo é permitir que os
indivíduos pertencentes a um mesmo ambiente de interação virtual possam interagir entre si, a
fim de esclarecer dúvidas [GAV98; GAV00]. Apesar de dar suporte ao esclarecimento de
dúvidas genéricas, a ferramenta será usada para esclarecer apenas dúvidas relacionadas ao
material de apoio disponibilizado pelo professor (somente no formato HTML, conforme
definição original da ferramenta), uma vez que relaciona a dúvida à uma seção ou tópico do
material disponibilizado. A vantagem desta ferramenta é que a pergunta para a dúvida pode
ser formulada no momento que o aluno estiver estudando o material, considerando a leitura
on-line do mesmo, através do link “Moonline”, disponível junto a cada página do material de
apoio. O autor da dúvida não é identificado, buscando deixar os alunos à vontade para
questionar. Intencionalmente as dúvidas são enviadas direto ao monitor da disciplina, caso
este não saiba respondê-la, o mesmo pode redirecionar a dúvida para o professor. No caso de
não haver um monitor para a disciplina, as dúvidas são diretamente enviadas ao professor.

Alternativamente à ferramenta Moonline, os alunos possuem outra forma de esclarecer

suas dúvidas através do ambiente. As mesmas podem ser enviadas à ferramenta FAQ, que
reúne um conjunto de perguntas relacionadas à disciplina, não precisando ser,
necessariamente, atreladas a conteúdos específicos. De forma análoga ao que ocorre na
ferramenta Moonline, as dúvidas são direcionadas ao monitor e, posteriormente ao professor,
caso o monitor não saiba respondê-las ou não exista um monitor registrado na disciplina.
Além de divulgar as dúvidas recebidas, esta lista pode apresentar perguntas elaboradas pelo
próprio professor. Ao perceber ou prever uma situação que necessite esclarecimentos, o
professor pode redigir as perguntas e suas respectivas respostas, buscando esclarecer as
dúvidas mesmo antes destas terem sido questionadas pelos alunos. Assim como na ferramenta
Moonline, o autor da pergunta não é identificado.
 84

Quadro 4.IV - Funcionalidades das ferramentas do módulo Comunicação Pública

FERRAMENTA/ PERFIL DE USUÁRIO

FUNCIONALIDADE PROFESSOR MONITOR ALUNO ADMIN.
PLANO DE AULAS
Criar plano de aulas x
Editar plano de aulas x
Excluir plano de aulas x
Visualizar plano de aulas x x x
AGENDA DE COMPROMISSOS
Incluir compromisso x x x
Editar compromisso x x x
Excluir compromisso x x x
Visualizar compromisso x x x
MURAL DE NOTÍCIAS
Criar tema de notícia x x
Editar tema de notícia x x
Excluir tema de notícia x x
Visualizar temas de notícia x x x
Incluir notícia x x
Editar notícia x x
Excluir notícia x x
Visualizar notícia x x x
MOONLINE
Incluir dúvida x x
Excluir dúvida x x
Responder dúvida x x
Redirecionar dúvida ao professor x
Editar resposta dúvida x x
Excluir resposta dúvida x x
Visualizar dúvida x x x
FAQ
Incluir pergunta x x x
Editar pergunta x x x
Excluir pergunta x x x
Responder pergunta x x
Editar resposta pergunta x x
Excluir resposta pergunta x x
Visualizar pergunta x x x
Pesquisar pergunta x x x
 85

A vantagem de armazenar-se as dúvidas questionadas pelos alunos no ambiente,

independente se feitas através da ferramenta Moonline ou FAQ, é que as mesmas ficam
registradas para futuras consultas pelos demais alunos. Segundo [GAV98], isto evita a perda
de informações importantes, como acontece no esquema tradicional de atendimento
extraclasse, no qual o monitor ou o professor atende o aluno, individualmente ou em grupo,
mas não se tem o registro da discussão e explicação fornecida. Quanto à organização da FAQ,
as perguntas estarão dispostas em ordem alfabética, buscando facilitar a busca e a consulta por
uma determinada pergunta. A busca pode ser realizada por palavras específicas, retornando ao
usuário as perguntas que contêm as palavras solicitadas. O Quadro 4.IV relaciona as
funcionalidades das ferramentas do módulo Comunicação Pública e os perfis de usuário que
podem acessá-las.

4.3 Módulo Comunicação Direta

Este módulo oferece ferramentas para comunicação direta entre os integrantes de uma
turma, quais sejam: E-mail, Chat e Fórum. A ferramenta E-mail favorece a comunicação
privada entre os participantes da turma ou mesmo com pessoas externas a mesma.
Considerando que o PROOGRAMA tem como objetivo dar suporte às atividades de ensino-
aprendizagem das disciplinas de Algoritmos e Lapro, oferecidas pela FACIN da PUCRS18, e
visto que todos os alunos dos cursos desta Faculdade possuem uma conta de e-mail vinculada
ao seu servidor de e-mails, definiu-se este servidor como o padrão para leitura
(pop3.inf.pucrs.br) e envio (smtp.inf.pucrs.br) de e-mails. O usuário pode configurar qualquer
outro servidor, desde que o mesmo tenha endereços para os protocolos POP e SMTP, de
recebimento e envio de e-mails, respectivamente. É importante observar que as mensagens
lidas através do ambiente não serão mantidas no servidor originário, mas porém serão
armazenadas no ambiente, podendo ser acessadas sempre que desejado.

Os usuários podem realizar conversas em tempo real (ou seja, síncronamente). Para
tal, basta estarem conectados ao ambiente. Estas conversas são suportadas pela ferramenta
Chat. Os textos gerados durante a conversa (chat) podem ser salvos a qualquer momento
desta conversa. As salas para ocorrência das conversas seguem os padrões dos demais
recursos desta natureza. Isto é, possuem um nome e uma lista das pessoas que estão utilizando

18
Isto não impede que o ambiente seja usado por outros departamentos da Universidade ou instituições de países
que tenham o Português como língua oficial.
 86

aquele espaço virtual. Existe uma sala padrão, habilitada constantemente no ambiente. Caso o
professor ou o monitor deseje discutir sobre um determinado assunto, pode ser criada uma
sala específica. Aconselha-se que o nome atribuído a esta sala faça relação ao assunto a ser
conversado, como, por exemplo, sala de discussão ou sala de revisão. O professor ou o
monitor ainda pode restringir o acesso a estas salas, caso desejem conversar com um grupo
restrito de alunos, selecionando o nome dos alunos que terão acesso ao definir a sala.

Quadro 4.V - Funcionalidades das ferramentas do módulo Comunicação Direta

FERRAMENTA/ PERFIL DE USUÁRIO

FUNCIONALIDADE PROFESSOR MONITOR ALUNO ADMIN.
E- MAIL
Configurar conta de e-mail x x x
Ler e-mail recebido x x x
Apagar e-mail recebido x x x
Enviar novo e-mail x x x
Visualizar e-mail enviado x x x
Apagar e-mail enviado x x x
Incluir contato x x x
Editar contato x x x
Excluir contato x x x
Visualizar contato x x x
Pesquisar contato x x x
Criar assinatura x x x
Editar assinatura x x x
Excluir assinatura x x x
CHAT
Criar sala de conversa x x
Editar sala de conversa x x
Excluir sala de conversa x x
Utilizar sala de conversa x x x
Salvar texto da conversa x x x
FÓRUM DE DISCUSSÃO
Definir assunto x
Disponibilizar fórum de x x
discussão
Encerrar fórum de discussão x x
Enviar colocação x x x
Editar colocação x x x
Excluir colocação x x x
Visualizar colocações x x x
 87

Para discussão de assuntos diversos, de forma assíncrona, disponibiliza-se a

ferramenta Fórum de discussão [LAU01]. Estes assuntos devem ser previamente definidos
pelo professor ou monitor. Todas as colocações feitas durante a discussão serão visualizadas
por todos os integrantes da turma. O ambiente indica que existe uma colocação ainda não lida
disponibilizando uma figura ao lado da colocação. Este mecanismo permite que o usuário
perceba rapidamente uma novidade no fórum de discussão. A duração do fórum é
determinada e divulgada ou pelo professor ou pelo monitor, dependendo do objetivo da
discussão. A divulgação do período (no caso de ser previamente definido) é suportada pela
ferramenta. O Quadro 4.V apresenta as funcionalidades das ferramentas disponibilizadas no
módulo Comunicação Direta, bem como os perfis de usuário que possuem acesso às mesmas.

4.4 Módulo Material do Curso

O módulo Material do Curso oferece quatro ferramentas, quais sejam: Glossário de

termos, Bibliografia, Material de apoio e Atividades. Atendendo a metodologia utilizada
como referência para a especificação do PROOGRAMA (apresentada no Capítulo 3), o
ambiente disponibiliza uma ferramenta para definição de termos utilizados no contexto de
uma disciplina, denominada Glossário de termos. A definição dos termos é criada a partir do
resultado das pesquisas do significado de palavras solicitadas pelo professor aos alunos. Cada
termo pode possuir um ou mais significados, de forma similar a um dicionário de vocábulos,
referenciando diferentes fontes de consulta. O professor é o responsável por determinar se o
significado de um termo submetido por um aluno deve ser aceito e disponibilizado para os
demais colegas. Junto de cada significado é possível encontrar a identificação do aluno que o
submeteu e a referência da fonte consultada. As definições dos termos (de um único ou de
todos definidos) podem ser impressas e salvas, facilitando a consulta e utilização
independente do usuário estar conectado ao ambiente. Estas duas últimas opções também
podem ser executadas através do navegador Web utilizado pelo usuário.

As bibliografias recomendadas pelo professor, sejam referências bibliográficas, links

para documentos ou sites a serem visitados, ou outro tipo de referência especificada, podem
ser visualizadas através da ferramenta Bibliografia. Além do professor, o monitor também
pode incluir bibliografias nesta ferramenta. Estas bibliografias são apresentadas agrupadas
pelo seu tipo, buscando facilitar a consulta feita pelo usuário. A validade da disponibilidade
 88

dos links indicados depende da conferência manual do professor ou do monitor, uma vez que
o ambiente não confere automaticamente se os links estão disponíveis. De forma semelhante
como ocorre na ferramenta Glossário de termos, as bibliografias também podem ser impressas
e salvas.

O professor pode disponibilizar o material de apoio para ser utilizado durante o

andamento da disciplina através da ferramenta Material de apoio. Basta o professor fazer o
upload do documento para o servidor do ambiente e, opcionalmente, informar o título e uma
breve descrição do material, para facilitar a posterior consulta dos alunos. Podem ser
colocados à disposição materiais de diversos tipos (textos, imagens, apresentações, entre
outros). Salienta-se que o ambiente não dá suporte ao desenvolvimento de materiais de apoio.
Ou seja, qualquer material disponibilizado deve ser criado fora do ambiente e importado (feito
upload) para o mesmo.

Para designar atividades (exercícios, trabalhos ou avaliações) a serem desenvolvidas

pelos alunos, tem-se a ferramenta Atividades. O professor deve editar externamente ao
ambiente a descrição da atividade e disponibilizar o documento através do PROOGRAMA.
Tendo desenvolvido a solução para a atividade proposta, os alunos devem enviar suas
respostas pelo ambiente. Considerando que o professor pode solicitar que os alunos trabalhem
em grupo, o ambiente permite que sejam identificados os alunos que participaram da
elaboração da solução. Ou seja, o nome dos integrantes do grupo (Vide Figura 4.6). Nesta
situação, apenas um aluno deve enviar o(s) arquivo(s)-resposta. Caso a atividade tenha sido
desenvolvida individualmente, basta o aluno não selecionar os nomes de outros integrantes.
Quando o aluno fizer o upload do documento para o servidor do ambiente, o mesmo se
encarrega de verificar se o tipo do arquivo corresponde ao tipo solicitado pelo professor.
Enquanto o professor não tiver avaliado a resposta ou o prazo final para sua submissão não
tiver se esgotado, o aluno pode alterar o arquivo-resposta. Assim que o professor corrigir a
resposta, o aluno pode consultar o conceito ou a nota atribuída a sua solução.
 89

Figura 4.6 – Entrega da resposta de uma atividade por um aluno integrante de um grupo

As atividades definidas e o envio das respostas por parte dos alunos podem ser
monitorados, visando manter o professor informado sobre a submissão das resoluções, bem
como notificar os alunos da proximidade de encerramento do prazo de desenvolvimento de
uma atividade. Este monitoramento é realizado pelo agente AMIGO e pode ser configurado
pelo professor. (Vide Capítulo 5 para detalhes sobre o agente). Os resultados deste
monitoramento podem ser consultado através dos relatórios que podem ser gerados, quais
sejam: (i) total de alunos que responderam uma determinada atividade e (ii) total de atividades
respondidas por um determinado aluno. Para estes dois tipos de relatórios, tem-se duas
alternativas: por porcentagem, indicando a porcentagem que atende a pergunta solicitada em
relação ao total de alunos registrados em uma turma; ou detalhada, listando os nomes dos
alunos que atenderam a pergunta. O Quadro 4.VI apresenta todas as funcionalidades da
ferramenta Atividades, bem como as demais ferramentas do módulo Material do Curso, com
suas respectivas permissões de acesso.
 90

Quadro 4.VI - Funcionalidades das ferramentas do módulo Material do Curso

FERRAMENTA/ PERFIL DE USUÁRIO

FUNCIONALIDADE PROFESSOR MONITOR ALUNO ADMIN.
GLOSSÁRIO DE TERMOS
Solicitar definição de termo x
Editar solicitação de termo x
Excluir solicitação de termo x
Especificar definição do termo x x x
Editar definição do termo x x x
Excluir definição do termo x x x
Visualizar termo x x x
Pesquisar termo x x x
Imprimir definição de termo x x x
Salvar definição de termo x x x
BIBLIOGRAFIA
Criar tipo de bibliografia x
Editar tipo de bibliografia x
Excluir tipo de bibliografia x
Incluir bibliografia x x
Editar bibliografia x x
Excluir bibliografia x x
Visualizar bibliografia x x x
Pesquisar bibliografia x x x
Imprimir bibliografia x x x
Salvar bibliografia x x x
MATERIAL DE APOIO
Incluir material de apoio x
Editar material de apoio x
Excluir material de apoio x
Visualizar material de apoio x x x
ATIVIDADES
Incluir atividade x
Editar atividade x
Excluir atividade x
Visualizar atividade x x x
Encaminhar resposta atividade x
Atualizar resposta atividade x
Corrigir material por atividade x
Corrigir material por aluno x
Visualizar correção da resposta x x
Configurar relatório x
Gerar relatório por estatística x
Gerar relatório detalhado x
 91

4.5 Módulo Teste de Algoritmos

Quanto ao módulo Teste de Algoritmos, este oferece apenas uma ferramenta, a

AMBAP (AMBiente de Aprendizado de Programação) [ALM02]. Esta ferramenta tem como
objetivo auxiliar o aluno a identificar e entender os passos relacionados à elaboração de uma
solução através de um algoritmo. A AMBAP foi desenvolvida por um grupo de pesquisa
parceiro e está disponível em versões implementadas em linguagem Java e C++. Permite a
edição, simulação, depuração e tradução do algoritmo em quatro diferentes linguagens, quais
sejam: fluxograma, pseudocódigo, assembly e linguagem de microprogramação. Para a
geração da linguagem em pseudocódigo, foi usada como base a linguagem especificada na
ferramenta ILA (Interpretador de Linguagem Algorítmica) [EVA00], proposta e desenvolvida
por [PIN91]. Observe o Quadro 4.VII para saber as funcionalidades oferecidas por esta
ferramenta e as restrições de acesso às mesmas.

Quadro 4.VII - Funcionalidades da ferramenta AMBAP

FERRAMENTA/ PERFIL DE USUÁRIO

FUNCIONALIDADE PROFESSOR MONITOR ALUNO ADMIN.
AMBAP
Escrever algoritmo x
Editar algoritmo x
Salvar algoritmo
Simular algoritmo x
Alterar parâmetros simulação x x x
Depurar algoritmo x x x
Traduzir algoritmo x x x

O último módulo definido, denominado Monitoramento e Gerência de Informações,

tem por objetivo prover as funcionalidades referentes à monitoração e gerência das
informações geradas quando do uso do ambiente. Nesta versão, este módulo possui
especificado apenas o agente AMIGO, mas pretende-se especificar outros agentes, visando
dar suporte à gerência das informações e ao processo de avaliação dos alunos. Desta forma,
ter-se-á um SMA definido no ambiente PROOGRAMA. As funcionalidades que caracterizam
este módulo são descritas no Capítulo 5. Ou seja, conforme já mencionado, o agente AMIGO
é apresentado separadamente no Capítulo 5.
 92

5 O AGENTE AMIGO

Ao utilizar alguns recursos computacionais (e-mail, FTP, entre outros) como apoio à
prática da sua metodologia de ensino, a professora orientadora deste trabalho deparou-se com
uma dificuldade, o grande tempo investido para gerenciar o volume de informações geradas a
partir da sua interação com os alunos através destes recursos. Isto se dá em função dos
recursos funcionarem independentes uns dos outros. Ou seja, não estarem centralizados em
um único ambiente e as informações geradas serem gerenciadas manualmente pela professora.
O volume destas informações aumenta, em especial, em épocas próximas a entregas de
trabalhos e exercícios, em função da professora utilizar o e-mail como canal de comunicação
para entrega dos resultados das atividades e esclarecimento de dúvidas.

Neste contexto, apresenta-se o agente AMIGO, o qual tem como objetivo monitorar e
gerenciar informações relacionadas a uma disciplina que utiliza o ambiente PROOGRAMA
como suporte às atividades do processo de ensino-aprendizagem. Os resultados apresentados
do monitoramento visam auxiliar e ampliar o processo de avaliação dos alunos pelo professor.
Esta avaliação é possível em razão do professor poder acompanhar o andamento das entregas
das respostas das atividades pelos alunos e, assim, inferir o comprometimento destes alunos
com os compromissos da disciplina.

Este capítulo apresenta as funcionalidades que o agente oferece para realizar tal
monitoramento e gerência e suas opções de configuração, a arquitetura interna do agente, e
detalhes de como o mesmo foi modelado e implementado em um protótipo para validar a
idéia proposta.

5.1 As funcionalidades do agente

As informações monitoradas pelo agente dizem respeito àquelas geradas através do

uso das ferramentas Agenda de compromissos e Atividades do ambiente PROOGRAMA. Ou
seja, são as informações referentes à realização de um compromisso agendado e/ou de uma
 93

atividade solicitada pelo professor, bem como as respostas destas atividades enviadas pelos
alunos. As informações a serem monitoradas e a forma de notificação dos resultados deste
monitoramento podem ser configuradas, para cada uma das ferramentas, conforme desejado.
A Figura 5.1 apresenta as opções de configuração para a ferramenta Agenda de
compromissos. Por definição padrão, estas opções já estão configuradas ao professor acessar o
ambiente, devendo ser desmarcadas caso não se deseje ter o agente em funcionamento.

Figura 5.1 – Opções de configuração de monitoramento da ferramenta Agenda de compromissos

O professor pode escolher se deseja que a inserção, a alteração e a exclusão dos

compromissos agendados devem ser monitoradas e notificadas a seus alunos. Caso configure
que a notificação se dê pelo ambiente, ao acessá-lo ou através da atualização da página
(refresh), os alunos visualizarão uma mensagem de comunicação, avisando-lhes sobre a
definição de um novo compromisso, a alteração ou a exclusão de algum já existente,
conforme tiver sido configurado. No caso de ter selecionado a notificação pelo e-mail, os
alunos receberão através dos seus endereços de e-mail registrados no ambiente a mensagem
comunicando-lhes a respectiva notificação. A escolha da forma de notificação não é
mutuamente exclusiva, isto é, o professor pode selecionar as duas formas de notificação para
uma mesma opção de monitoramento. A vantagem da forma de notificação ser configurável é
 94

que o professor pode eleger aquela(s) que melhor lhe convém. Por exemplo, se por alguma
razão um usuário não pode acessar freqüentemente o ambiente para saber os compromissos
agendados pelo professor, este usuário pode tomar conhecimento das novidades através da sua
conta de e-mail. Ainda em relação às opções de configuração apresentadas, para a opção de
notificação por e-mail, o professor pode redigir um texto padrão para a identificação e o
conteúdo do e-mail que será enviado, preenchendo os campos Cabeçalho e Rodapé
disponíveis, respectivamente.

Além das opções de monitoramento da inserção, alteração e exclusão de um

compromisso, ainda existe a opção de monitoramento e notificação de compromissos
pessoais. Esta alternativa, disponível tanto para o professor como para os alunos, diz respeito
exclusivamente ao monitoramento do prazo de ocorrência dos compromissos pessoais do
usuário que a está configurando. Assim, ao ser selecionada, o AMIGO passa a monitorar os
prazos dos compromissos e a notificar o respectivo usuário com o prazo de antecedência
especificado pelo mesmo. Para aqueles compromissos especificados pelo professor para toda
a turma, este monitoramento do prazo também ocorre. Este é disparado implicitamente
quando o professor seleciona a opção de monitoramento da inserção de um compromisso.

Uma vez tendo sido configurada as opções de monitoramento para a Agenda de

compromissos, o usuário terá disponível nesta ferramenta um campo para especificar qual o
prazo de antecedência que deseja que o agente comece a notificar a existência de um
compromisso (Vide Figura 5.2). Para cada compromisso pode ser especificado um período
diferenciado. Este período é definido em dias.

Quanto à ferramenta Atividades, as opções de monitoramento possuem o mesmo

princípio das oferecidas para a ferramenta Agenda de compromissos, podem ser configuradas
para notificar o usuário através do ambiente ou da sua conta de e-mail, bem como o resultado
de algumas dessas opções são apresentados apenas para os alunos e outros para o professor.
Mas, diferentemente da configuração da ferramenta Agenda de compromissos, esta
funcionalidade está disponível apenas para o professor, uma vez que este é o responsável por
definir e propor as atividades aos alunos.
 95

Figura 5.2 – Local para especificação do prazo de notificação de um compromisso

Sendo assim, o professor pode configurar se a inserção, a alteração e a exclusão da

definição de uma atividade serão monitoradas e notificadas aos alunos. Também se deseja ser
notificado quanto ao recebimento da resposta de alguma atividade enviada por algum aluno, à
alteração ou à exclusão da resposta enviada. A Figura 5.3 apresenta estas opções de
configuração para a ferramenta Atividades. Ao escolher alguma destas três últimas opções de
configuração, o professor poderá gerar relatórios para saber quais alunos já responderam uma
determinada atividade e quais atividades já foram respondias por um determinado aluno.

Além destas opções, no caso de detectar que alguma resposta de atividade foi
recebida ou teve seu conteúdo alterado, o agente verifica se o arquivo entregue pelo aluno (ou
grupo de alunos) não se encontra corrompido ou vazio. Ou seja, o agente é o responsável por
gerenciar o estado do material recebido dos alunos. Se identificar alguma das duas situações
citadas, o remetente do material é comunicado por e-mail ou pelo ambiente, conforme estiver
configurada a opção Recebimento de atividade ou Alteração de atividade recebida, que houve
problema e que deve reenviar o documento contendo a resposta da atividade.
 96

Figura 5.3 - Opções de configuração de monitoramento da ferramenta Atividades

Quanto aos relatórios, estes encerram as funcionalidades oferecidas pelo agente.

Apesar da solicitação de geração dos relatórios estar disponível ao professor através da
ferramenta Atividades, o agente é o responsável por gerá-los e informá-los ao solicitante. O
professor deve escolher se deseja saber o total de alunos que responderam uma determinada
atividade ou o total de atividades respondidas por um determinado aluno. Cada tipo de
relatório pode ser visto de forma simplificada, ou seja, apenas a porcentagem que atende à
pergunta solicitada em relação ao total de alunos registrados de uma turma; ou detalhada,
listando os nomes dos alunos que atenderam a pergunta. Cabe ao professor definir qual tipo
de retorno deseja visualizar. As informações que compõem o relatório são apresentadas na
tela e podem ser impressas (através da funcionalidade de impressão do navegador que está
sendo utilizado). Sempre que solicita um relatório, o retorno representa o estado corrente da
turma, não ficando registrado para posterior consulta o conjunto de informações apresentadas.
Eventualmente as informações serão as mesmas caso nenhum novo dado tenha sido registrado
no BD do ambiente. De posse das informações apresentadas nos relatórios gerados, o
professor pode, por exemplo, tomar decisões quanto manter ou prorrogar o prazo de entrega
 97

de uma atividade ou usar estas informações como elemento complementar para a avaliação de
um aluno.

5.2 A modelagem e funcionamento do agente

Para chegar-se às funcionalidades especificadas, a primeira atividade realizada no que

diz respeito à especificação do agente foi definir a sua arquitetura interna. Como o AMIGO
desempenha suas funções baseadas nas mudanças que percebe no ambiente, como, por
exemplo, se detectar a inclusão de um compromisso ou o recebimento de uma resposta para
uma atividade (caso estas opções de monitoramento estejam configuradas), e responde as
mesmas de acordo com um conjunto de ações pré-estabelecidas, este é considerado um agente
reativo. A arquitetura é apresentada na Figura 5.4.

Configuração de
monitoramento de ferramentas

Verificação de compromissos
e atividades

Verificação de arquivos
enviados

Geração de Mensagens para os

relatórios usuários

Figura 5.4 – Arquitetura interna do agente AMIGO

O módulo Configuração de monitoramento de ferramentas é responsável por

oferecer as opções de monitoramento aos usuários e identificar àquelas escolhidas pelos
mesmos. O módulo Verificação de compromissos e atividades é ativado para verificar a
ocorrência das opções configuradas. Quanto ao módulo Verificação de arquivos enviados,
este só é ativado caso a(s) opção(ões) de monitoramento de recebimento de resposta de
atividade, alteração ou exclusão desta resposta tenha(m) sido configurada(s). Neste caso, este
módulo se encarregará de verificar se os arquivos recebidos não estão corrompidos ou vazios,
 98

conforme mencionado anteriormente. Responsável pela notificação dos resultados dos

monitoramentos, tem-se o módulo Mensagens para os usuários, e fornecendo os dados para
a geração dos relatórios, tem-se o módulo Geração de relatórios.

As atividades desempenhadas por estes módulos expressam os requisitos identificados

para serem atendidos pelo agente. Estes requisitos foram especificados utilizando-se o
Diagrama de Casos de Uso da UML (Unified Modeling Language) [BOO99] e detalhados
através do Diagrama de Atividades da mesma linguagem. Segundo [BOO99; FOW00], a
UML é uma linguagem de modelagem de sistemas computacionais, composta por nove tipos
de diagramas, quais sejam: (i) Casos de Uso; (ii) Pacotes; (iii) Implantação; (iv) Classes; (v)
Objetos; (vi) Seqüência; (vii) Colaboração; (viii) Estados; e (ix) Atividades. Cada diagrama
representa uma diferente dimensão do sistema, seja a arquitetural, a estrutural ou a
comportamental. Por ser uma linguagem de notação gráfica e independente de linguagem de
programação, a UML permite uma fácil comunicação entre clientes, projetistas e
desenvolvedores [FOW00]. Em específico, os diagramas de Caso de Uso possuem como
objetivo descrever os diferentes cenários de uso de um sistema sob o ponto de vista de um
determinado usuário. Estes cenários são organizados por objetivos, o que permite a
elaboração de mais de um diagrama de Caso de Uso para um mesmo sistema. Quanto aos
diagramas de Atividades, estes são úteis para detalhar casos de uso, enfatizar o fluxo de
atividades (workflow) ou mesmo para representar o comportamento de aplicações com um
grande volume de processamento em paralelo.

A Figura 5.5 apresenta o diagrama de Casos de uso do agente, isto é, neste diagrama
são representados os requisitos do AMIGO. Estes requisitos são representados pelas elipses,
enquanto os bonecos representam os usuários que possuem a permissão de acesso a estas
funcionalidades. Na UML, estes usuários são denominados atores. Por fim, o agente é
representado pelo elemento gráfico que indica uma classe ou um objeto na linguagem de
modelagem adotada. Cabe salientar que se adotou este elemento gráfico para representar o
agente uma vez que a UML não dá suporte à modelagem de SMAs em específico, sendo
assim, não existe um elemento próprio para representação do conceito de agente. Apesar desta
representação dar margens para uma interpretação semântica errônea, uma vez que se pode
interpretar que o AMIGO é uma classe e não um agente, [PAR99; SIL01] argumentam que é
possível representar agentes de software através de classes do paradigma orientado a objetos.
Esta utilização, segundo os autores, é aceitável em função da proximidade de algumas
 99

características destes dois paradigmas, como, por exemplo, o fato de um agente de software,
em geral, ser implementado através de uma thread. Caso este trabalho estivesse apresentando
um SMA, esta notação teria sido inviabilizada, pois não seria possível representar as
estruturas organizacionais (diagrama de sociedade) do SMA.

AMIGO: Reune as funcionalidades

disponibilizadas pelo agente AMIGO.

Gerar relatorio por estatistica

Gerar relatorio
Monitorar compromissos
<<agent>>
Amigo Gerar relatorio detalhado

Monitorar material resposta

Professor
atividade
(from Use Case View)

Comunicar resultado do
Usuario
monitoramento de compromissos
(from Use Case View)

Comunicar resultado do
Aluno
monitoramento do material
(from Use Case View)

Figura 5.5 - Diagrama de Casos de Uso do AMIGO

O detalhamento dos requisitos da ferramenta Agenda de compromisso é apresentado

nas Figuras 5.6 e 5.7, através dos diagramas de Atividades. Além de indicarem o fluxo de
execução das atividades a serem realizadas, estes diagramas ainda podem definir (fica a
critério do projetista do sistema) quem é o responsável por solicitá-las, através das chamadas
swinlames (linhas de execução). Estas linhas de execução são indicadas por um traço vertical
e um cabeçalho na parte superior do diagrama, indicando o responsável pela solicitação da
atividade. As elipses retangulares representam as atividades e os losangos, uma tomada de
decisão condicional. A condição é indicada pelo conteúdo entre os caracteres “[ ]” e o
conteúdo a ser analisado (variável) é indicada pelo conteúdo entre os caracteres “( )”. Por
exemplo, na Figura 5.6 o agente verifica o período de notificação de um compromisso. Se os
dias que faltam para a ocorrência deste compromisso for menor ou igual ao período de
notificação solicitado pelo usuário, então o agente irá invocar o método de comunicação ao
usuário (detalhado na Figura 5.7). Pode-se dizer que estes diagramas de Atividades
 100

expressam, em linhas gerais, o algoritmo de implementação das funcionalidades que estão

detalhando. Os demais diagramas de Atividades do agente podem ser encontrados na Seção
2.2. do Apêndice D.

Professor AgenteAMIGO

Monitorar compromissos: Verifica, de tempos em tempos,

a proximidade da data dos compromissos existentes na
Agenda de Compromissos buscando notificar os
respectivos usuarios associados a estes compromissos.

Solicitar monitoramento da Analisar compromisso para

Agenda de Compromissos verificar proximidade da data

( Periodo aviso )

[ dCompr-dAtual<=PeriodoAviso ]

[ dCompr-dAtual>PeriodoAviso ]

<<use case>>
Comunicar resultado do
monitoramento de compromissos

Figura 5.6 - Diagrama de Atividades do requisito Monitorar compromissos

AgenteAMIGO Usuario

Comunicar resultado do monitoramento

de compromissos: Comunica ao
usuario, atraves de um e-mail, a
proximidade de um compromisso.

( Dados compromisso )

Formatar texto comunicando a ( Texto formatado )

proximidade da atividade
[Pelo ambiente]

[Por e-mail]

Receber e-mail com o texto que

foi preparado pelo e-mail

Receber e-mail com o texto que

foi preparado pelo ambiente

Figura 5.7 - Diagrama de Atividades do requisito Comunicar resultado do monitoramento de compromisso

 101

Como se utilizou o paradigma orientado a objetos para a implementação dos

protótipos do ambiente e do agente, ao ser configurada qualquer opção de monitoramento do
agente, este é ativado. Isto se dá através da instanciação de um objeto da classe amigo, tratado
como uma thread, para permitir que várias instâncias desta classe sejam manipuladas
simultaneamente. Este tratamento é realizado pois, cada novo usuário que acessa o
PROOGRAMA possui uma instância do agente AMIGO associada a sua sessão de utilização
do ambiente, caracterizando um sistema multi-threads. Para evitar a sobrecarga do servidor da
aplicação, uma vez que estas threads exigem memória de processamento para sua gerência,
estas instâncias estarão sendo ativadas e desativadas. São ativadas quando o agente detecta
que necessita executar alguma ação, através dos seus sensores, e desativadas, quando encerra
de executar esta ação. Desta forma, a thread do agente nem sempre está ativa.

Os sensores estão distribuídos nas diferentes classes que implementam as

funcionalidades de troca de dados entre as páginas JSP (interface com o usuário) e os servlets
(mecanismo para invocar e receber respostas do servidor) com as tabelas do BD. Estas classes
foram denominadas APIs (Detalhes sobre a arquitetura e implementação do PROOGRAMA
podem ser encontrados adiante, na Seção 6.2). Cada tabela do BD possui uma API
correspondente. Para representar os sensores, foram definidas variáveis do tipo texto (String)
que são enviadas à instância da classe AMIGO ao serem identificadas no código em
execução. Por exemplo, quando o professor insere um compromisso em sua agenda, a função
inserir() da API Compromisso submete ao agente do professor a string
professorInsereCompromisso, representando o sensor para esta situação. Ao executar uma
funcionalidade que possui um sensor associado, a instância correspondente do agente é
ativada e executa a ação necessária para cumprir sua tarefa. Ou seja, o atuador correspondente
do agente é colocado em ação no ambiente em que o agente está atuando.

Ainda foi especificada uma outra forma do AMIGO ser ativado, caso os sensores não
tenham detectado mudanças no ambiente. A cada vinte e quatro horas o agente é ativado e
realiza uma verificação completa de todas as opções de configurações definidas para cada um
dos usuários. Esta verificação foi programada para ocorrer todos os dias à meia-noite,
viabilizando identificar as atividades e os compromissos relativos ao dia corrente assim que o
dia se inicia. De maneira bastante simples esta definição pode ser alterada, mudando-se no
código-fonte o horário ou mesmo a freqüência de verificação por dia.
 102

6 O PROCESSO DE DESENVOLVIMENTO DO AMBIENTE

PROOGRAMA E DO AGENTE AMIGO

Para orientar o processo de desenvolvimento do ambiente PROOGRAMA (e,

conseqüentemente, do agente AMIGO), optou-se pelo framework proposto pela Microsoft, o
MSF. A escolha foi baseada no conhecimento prévio da equipe e na facilidade de acesso à
documentação relacionada, uma vez que a descrição do modelo e os templates propostos para
elaboração dos documentos de projeto estão disponíveis gratuitamente na Internet19. Outro
motivo que nos levou a escolher o MSF como referência foi o fato deste dar suporte ao
desenvolvimento incremental de um software. O desenvolvimento do ambiente
PROOGRAMA possui esta característica, já que para fins de atingir-se o objetivo maior deste
trabalho (o desenvolvimento do agente AMIGO) optou-se por implementar apenas parte do
software especificado, tendo como resultado um protótipo envolvendo o escopo definido.
Previu-se que o restante do projeto será desenvolvido em outros trabalhos de pesquisa sob
orientação da professora orientadora deste trabalho, a serem definidos a critério da mesma. A
submissão de uma proposta de continuação deste projeto, em conjunto com um professor
parceiro do GIE/FACIN, ao CNPq (Conselho Nacional de Desenvolvimento Científico e
Tecnológico), expressa o desejo de continuidade imediata do mesmo.

A adoção de uma proposta de processo de desenvolvimento de software teve como

objetivo agregar formalismo à metodologia de desenvolvimento de software educacional
seguida pela professora orientadora e adotar o conhecimento oriundo de toda a sua
experiência pedagógica, a qual foi formalizada através da metodologia de ensino-
aprendizagem descrita no Capítulo 3. O registro formal do processo de desenvolvimento do
ambiente também visou a disseminação das decisões e informações a todos os integrantes do
projeto, bem como formar um histórico do projeto para consulta da eventual nova equipe.
Também, é importante destacar que as práticas e documentos propostos pelos dois processos e
três disciplinas que compõem o MSF não foram adotados em sua totalidade, em função do

19
Para obtenção destes templates ou maiores informações, consulte http: //www.microsoft.com/msf.
 103

porte e tipo de projeto, e do tamanho da equipe20. Pode-se citar como exemplo a atividade de
análise de custo e preço do software a ser desenvolvido prevista pelo MSF. Esta prática não
foi abordada em razão deste grupo de pesquisa ter como premissa a divulgação gratuita dos
resultados de seus projetos para a comunidade acadêmica.

Este capítulo apresenta o processo de desenvolvimento do ambiente PROOGRAMA,

desde sua concepção, especificação e planejamento, até a implementação e teste do escopo
definido para este trabalho, o qual aborda o agente AMIGO. Este processo está descrito em
cinco seções, sendo que cada um destas diz respeito a uma das fases de projeto de software
definidas pelo MSF, conforme apresentado na Seção 2.2.1. Salienta-se que, em função do
volume de informação gerada nos documentos de projeto desenvolvidos, optou-se por
apresentá-los como Apêndices (devidamente referenciados) deste texto. As informações mais
relevantes ou aquelas com caráter demonstrativo foram descritas e apresentadas no corpo do
texto desta Dissertação.

6.1 Visão (Envisioning)

Conforme mencionado na Seção 2.1.1, por ser um framework e propor um conjunto de

atividades e documentos que podem ser adaptados, o MSF não prevê um fluxo para
execução das atividades de cada fase. Ou seja, não é estabelecida uma seqüência de realização
das atividades, salvo aquelas que, para serem desenvolvidas, necessitam de resultados
providos por outras atividades. Neste contexto, com o objetivo de auxiliar na identificação e
compreensão das atividades realizadas pela equipe de pesquisa durante esta fase, apresenta-se
na Figura 6.1 o fluxo de execução das mesmas. Utilizou-se a notação do Diagrama de
Atividades proposto pela UML para representar este fluxo. Optou-se por esta notação em
função da UML ter sido a linguagem utilizada para a modelagem do sistema e a equipe ter
domínio sobre a mesma, bem como por este tipo de diagrama oferecer suporte à representação
de fluxos de atividades, conforme já apresentado.

20
A própria Microsoft sugere a adaptação dos documentos propostos pelo MSF, conforme descrito na Seção
2.1.1, desde que respeite e preserve as características do framework [MIC02a]. A adaptação feita pelo grupo foi
apresentada e aprovada por um dos consultores da Microsoft, durante a participação de parte dos integrantes da
equipe de projeto no curso MSF Essentials, oferecido pelo CTXML Microsoft/PUCRS.
 104

R elatado no TI- II,

Identificaçã o
entregue em Nov/02.
do problem a

E studo de trabal hos

correlatos
P roposta defendida
P roposta de solução no PE P , em Dez/02.
baseada no Am CorA

E studo detalhado do
am biente AmCorA

P ropo sta de c ri ação d o

ambiente PROOGRA MA

Definição da visão
S eleção dos bolsistas integrantes
da solução
da equipe de pesquisa

Identific ação dos

Definição dos papéis e
requisitos de negócio
responsabilidades dos integrantes

Identific ação dos

perfis de usuário
Organização da form a
de trabalh o da equipe
Definição do
escopo do projeto

E scolha da linguagem de
pro gramação

E laboração da estratégia de
estudo das tecnologias

Figura 6.1 - Fluxo de execução das atividades da fase Visão

A fase Visão teve seu início durante a realização do TI-II desta autora, em setembro de
2002, e encerrou-se no mês de abril de 2003. Durante o desenvolvimento do TI-II, estudou-se
quatro ambientes virtuais de ensino-aprendizagem com o objetivo de identificar se algum
destes atendia a necessidade da professora orientadora deste trabalho de ter um ambiente que
desse suporte a sua metodologia de ensino e gerenciasse as informações recebidas dos alunos.
Estar praticando sua metodologia por oito semestres permitiu à professora adquirir uma certa
experiência com o uso de espaços virtuais como elementos de extensão e mediação das
atividades da sala de aula presencial. Sendo assim, naquele momento, tinha-se um problema
claramente caracterizado: “A professora desejava não ter mais que dedicar parte de seu tempo
realizando manualmente atividades operacionais de organização dos arquivos e informações
recebidas dos seus alunos através dos recursos computacionais utilizados no contexto de sua
metodologia. Tinha a necessidade de ter um mecanismo que gerenciasse automaticamente
estas informações e arquivos, em um ambiente único e centralizador dos recursos adotados”.
A existência deste problema foi o fator motivador do estudo dos ambientes.
 105

Neste contexto, estudou-se os ambientes AmCorA [MEN99], AulaNet [FUK00],

LearningSpace [LOT99] e WebCT [WEB00]. A escolha destes ambientes se deu baseada no
conhecimento originado da experiência do grupo de IE ao qual se está vinculado
(GIE/FACIN), o de saber que estes ambientes oferecem a possibilidade de se explorar
aspectos que vão ao encontro da proposta construtivista de trabalhar a produção e aquisição
de conhecimento. Após a seleção dos ambientes, os mesmos foram analisados.

Como resultado da análise feita e baseados na metodologia da professora, definiu-se

um conjunto de características desejadas e que deveriam ser atendidas pelo ambiente a ser
selecionado. Definiu-se que o ambiente deveria permitir:

• A criação, organização e apresentação do plano de aulas e cronograma de

disciplinas;

• A criação e manutenção do acervo das mesmas (banco de exercícios e atividades,

banco de exemplos, biblioteca virtual e digital, entre outros);

• A comunicação entre os integrantes de uma turma;

• A disponibilização de um sistema de ajuda on-line;

• A resolução e teste de algoritmos em alto nível;

• O envio de material correspondente à solução de atividades propostas;

• A resolução destas atividades em grupo;

• A gerência destes materiais entregues pelos alunos.

Em função da proximidade da proposta de ensino, baseada em uma abordagem

construtivista, e da parceria de trabalho entre os grupos GIE/FACIN e GAIA21 (UFES),

21
Grupo de Aplicação da Informática na Aprendizagem/Grupo de Aplicação da Inteligência Artificial. O GAIA
está vinculado ao Departamento de Informática da universidade mencionada. Maiores detalhes podem ser
obtidos em http://www.gaia.ufes.br.
 106

responsável pelo desenvolvimento do ambiente AmCorA, decidiu-se adotar este ambiente e

desenvolver aqueles requisitos especificados e não atendidos pelo mesmo. A escolha também
foi reforçada pelo fato da professora orientadora estar usando, naquele semestre letivo, o
ambiente WebCT com sua turma de Algoritmos e, apesar de estar satisfeita com os resultados
alcançados durante sua utilização, não ter a possibilidade de acrescentar à arquitetura do
mesmo outras características. Isto se deve em função do WebCT ser um ambiente proprietário
(de “código fechado”). Sendo assim, propôs-se, em especial, o desenvolvimento de um
agente, denominado AMIGO, para monitorar e gerenciar as informações trocadas entre
professor-aluno (e vice-versa), buscando atender a necessidade da professora de ter um
mecanismo automático para organizar as informações e arquivos recebidos dos alunos e,
conseqüentemente, auxiliar no processo de avaliação da aprendizagem dos alunos. Este agente
seria desenvolvido baseado no ambiente AmCorA. Esta proposta foi defendida em dezembro
de 2002 e aprovada pela banca do PEP22 (Plano de Estudo e Pesquisa). Desta forma, a mesma
passou a ser o projeto de pesquisa de Mestrado desta autora.

Quanto à utilização do ambiente AmCorA, como esta foi estabelecida de comum

acordo entre os dois professores orientadores dos grupos de pesquisa envolvidos, o orientador
do GAIA colocou sua equipe à disposição para consulta e auxílio no estudo deste ambiente.
Assim, a partir daquele momento iniciou-se um período de estudo e conhecimento da
arquitetura, soluções e tecnologias adotadas pelo AmCorA. Este momento coincidiu com a
migração do ambiente para outro sistema operacional, bem como da reformulação da sua
arquitetura base, o que exigiu atenção e dedicação dos principais responsáveis pela equipe.
Sabendo-se da restrição de tempo para a finalização deste estudo, solicitou-se a liberação para
reproduzir o ambiente no servidor do GIE/FACIN, com a intenção de minimizar as interações
com os pesquisadores do GAIA em função da demanda de trabalho dos mesmos. A estratégia
adotada não obteve êxito. Visto que o AmCorA é um ambiente de origem acadêmica, ou seja,
desenvolvido em um contexto de pesquisa, com diversos alunos de graduação e pós-
graduação envolvidos, deparou-se com uma dificuldade: a inexistência de uma documentação
formal que pudesse descrever o histórico de desenvolvimento do ambiente e permitir a
compreensão do mesmo por parte da autora. Também se teve a dificuldade de receber a

22
O PEP é apresentado a uma banca avaliadora que julga se a proposta apresentada caracteriza uma pesquisa de
mestrado. O aluno passa a ser considerado mestrando caso tenha um parecer favorável. No caso contrário, é
designado um novo prazo para apresentação da proposta reformulada. Em geral, a defesa ocorre no final do
primeiro ano do curso.
 107

estrutura completa do ambiente, uma vez que algumas funcionalidades estavam sendo
alteradas naquele momento.

Neste cenário, desistiu-se da proposta inicial de adotar o AmCorA como ambiente

base e definiu-se que seria desenvolvido um ambiente próprio, denominado PROOGRAMA,
adotando a abordagem de agentes. Com a proposta de desenvolvimento do AMIGO, o grupo
já tinha previamente a intenção de usar esta abordagem, levando-se em consideração a área de
pesquisa ao qual este projeto está vinculado, a IA. Além disto, esta decisão permite ao grupo
definir, futuramente, outros agentes para atuarem no ambiente, de acordo com as necessidades
identificadas, transformando o ambiente em um SMA. Também, que sejam acrescidas ao
ambiente quantas funcionalidades forem necessárias para atender a proposta metodológica da
professora orientadora. Sendo assim, ficou estabelecido que todas as características definidas
inicialmente seriam atendidas no contexto do Mestrado da autora deste trabalho. Estas
características podem ser entendidas como os requisitos de negócio, os quais constituíram, em
um primeiro momento, tanto a visão quanto o escopo definidos para o projeto (Vide detalhes
no Apêndice B23). Para auxiliar a definição deste escopo, fez-se uma breve análise dos
possíveis cenários e situações em que o ambiente poderia ser usado, bem como das pessoas
envolvidas neste uso. Inicialmente, esta análise tinha como objetivo apenas verificar se todas
as características desejadas haviam sido definidas, mas após terem sido descritas, puderam ser
usadas como referência para a especificação dos requisitos do sistema. Também baseados
nesta análise, estipulou-se que, como resultado, seria gerado um protótipo do ambiente, no
qual o agente AMIGO atuaria. Este protótipo deveria prover diferentes visões, conforme os
perfis de usuário a serem definidos.

Tendo o escopo definido, previu-se que haveria um volume de trabalho superior ao

definido inicialmente (apresentado no PEP) e que, em função da restrição de tempo, havia o
risco do objetivo não ser cumprido. Buscando evitar que este risco se tornasse real, decidiu-se
pela estruturação de uma equipe de desenvolvimento. Selecionou-se, então, dois bolsistas de
Iniciação Científica (IC), um deles responsável pelo desenvolvimento e estudo de tecnologias
a serem adotadas, e outro pela interface gráfica, realização de testes e apoio à redação dos
documentos do projeto, além de atender eventuais demandas, tais como auxiliar no
desenvolvimento do site de divulgação do projeto. Complementam a equipe a professora

23
O documento retrata a versão final do escopo definido. Este escopo foi alterado após a apresentação do
Seminário de Andamento. A alteração e sua justificativa são apresentadas na Seção 6.2.
 108

orientadora deste trabalho, atuando como cliente e usuária, e a mestranda, como responsável
pela definição, modelagem e especificação do projeto, bem como pela condução do mesmo
(Maiores detalhes sobre a definição dos papéis e responsabilidades de cada integrante da
equipe podem ser consultados no Apêndice C).

Com a equipe estruturada, estabeleceu-se a forma de trabalho, comunicação e

armazenamento dos artefatos (artigos, relatórios, códigos-fonte, entre outros) produzidos.
Quanto às decisões, ficou estabelecido que estas deveriam ser revisadas e aprovadas pela
orientadora. Também, que a professora deveria tomar conhecimento do andamento do projeto
e desenvolvimento das atividades dos integrantes através da mestranda, em reuniões
semanais. Sobre a forma de comunicação, o e-mail foi a ferramenta eleita como oficial pela
equipe. Avisos, recados e solicitações de reuniões passaram a ser registradas por este recurso,
agilizando o contato entre os integrantes. Em relação ao armazenamento dos artefatos, criou-
se uma área pública, em um servidor gratuito disponível na Internet, e passou-se a utilizá-la
como meio de disponibilização das versões mais atuais dos artefatos. Esta área também pode
ser vista como uma cópia backup do material produzido. Para facilitar a organização desta
área e evitar a perda das versões mais atualizadas dos artefatos, definiu-se um conjunto de
padrões para nomenclatura e numeração dos mesmos. Estes padrões substituíram um controle
de versões automático, já que a equipe não possuía uma ferramenta para tal tipo de controle
(Consulte o Apêndice C para verificar o detalhamento destes procedimentos).

Outro risco identificado estava relacionado com as tecnologias que seriam adotadas,
uma vez que se levou em consideração que o ambiente pode ser utilizado fora da PUCRS e é
importante que funcione em diferentes sistemas operacionais. Apesar desta necessidade,
definiu-se como restrição para o desenvolvimento do protótipo o funcionamento no sistema
operacional Windows, utilizando o navegador Internet Explorer 5.0 ou superior. Para atender,
futuramente, este aspecto de portabilidade, optou-se por utilizar a linguagem de
desenvolvimento Java. Esta linguagem também foi escolhida por não oferecer custo para o
desenvolvimento ou uso da aplicação. Apesar de Java ser considerada portável, não se tinha
certeza se esta iria dar suporte a todas as necessidades identificadas, bem como não se sabia
como seria estruturada a comunicação entre a interface gráfica e o servidor. Para sanar estas
questões, elaborou-se uma estratégia de estudo de possíveis recursos para buscar garantir a
opção tecnológica feita. Esta estratégia de viabilização das tecnologias e técnicas foi colocada
em prática na fase Planejamento, conforme previsto pelo MSF. O Apêndice C apresenta a
 109

lista completa dos riscos identificados, bem como as conseqüências, planos de mitigação e
contingência elaborados para os mesmos.

6.2 Planejamento (Planning)

A fase Planejamento caracteriza-se em duas grandes etapas. A primeira etapa ocorreu

entre os meses de abril e agosto de 2003, quando da apresentação do Seminário de
Andamento24 (SA); e a segunda, nos vinte dias consecutivos a esta apresentação. Estas etapas
serão denominadas, respectivamente, Etapa 1 e Etapa 2. Sendo assim, a Figura 6.2 apresenta
o fluxo de execução das atividades correspondente a Etapa 1 desta fase.

E s pecific aç ão M odelagem UM L:
dos requis itos Cas os de us o

Definiç ão da E s tudo s obre

arqu itetura prelim inar as tecn ologias

P rototipação da
interface gráfic a Des envolvim ento de
aplicações -teste
V alidaç ão c om
a professora

A tualiz aç ão da S eleç ão das

espec ificação dos requisitos te cnolo gias

Detalham ento
da arqu itetura

P l anejamen to
do proj eto

Figura 6.2 - Fluxo de execução das atividades da Etapa 1 da fase Planejamento

24
O Seminário de Andamento (descrito em um artigo) permite que seja apresentado a uma banca examinadora o
estado corrente da pesquisa, permitindo também a divulgação do trabalho aos demais pesquisadores vinculados
ao Programa de Pós-Graduação em Ciência da Computação (PPGCC) da FACIN/PUCRS.
 110

A primeira atividade da Etapa 1 constituiu-se em detalhar o escopo definido para o

projeto e identificar os requisitos do sistema. Estes requisitos foram compostos por requisitos
de negócio, de usuário e de sistema. Em relação ao primeiro tipo, este diz respeito às
necessidades pedagógicas e tecnológicas da professora orientadora, as quais já haviam sido
identificadas na fase Visão, como resultado do estudo dos ambientes (trabalhos correlatos) e
da análise de sua metodologia de ensino. Portanto, estes requisitos foram apenas revisados,
uma vez que já haviam sido descritos. Quanto aos requisitos de usuário, estes dizem respeito
aos aspectos não-funcionais do sistema, tais como questões de interface gráfica e aspectos de
segurança do ambiente. Estes requisitos foram descritos de forma textual e a organização dos
mesmos, por categorias, seguiu a abordagem proposta por [SOM03]. Desta forma, definiu-se
requisitos não-funcionais para o seguinte subgrupo de categorias: (i) Interface com o usuário e
facilidade de uso; (ii) Documentação; (iii) Portabilidade; (iv) Implementação e padrões de
desenvolvimento; e (v) Segurança. O Quadro 6.I apresenta alguns exemplos dos requisitos
não-funcionais especificados, de acordo com as categorias mencionadas. A listagem completa
destes requisitos pode ser vista na Seção 2.3 do Apêndice D.

Quadro 6.I – Exemplos de requisitos não-funcionais especificados

CATEGORIA ESPECIFICAÇÃO DO REQUISITO
As alternativas na interface gráfica que indiquem a seleção de
mais de uma opção simultaneamente devem ser indicada pelo
Interface com o usuário e elemento gráfico HTML denominado checkbox.
facilidade de uso A indicação da ferramenta que está sendo usada pelo usuário,
bem como as funcionalidades que esta oferece deve ser de fácil
identificação.
Os manuais de usuário devem ser específicos para cada um dos
perfis definidos.
Documentação Toda a documentação relativa ao desenvolvimento do ambiente
(modelagem, código-fonte, entre outras) deve ser entregue a
cliente (professora), incluindo não só a versão impressa, mas
também os arquivos com as versões finais.
O protótipo do sistema deve funcionar no sistema operacional
Portabilidade Windows.
O protótipo do sistema deve ser compatível como navegador
Internet Explorer 5.0 ou superior.
As ferramentas desenvolvidas devem funcionar
Implementação e padrões independentemente umas das outras.
de desenvolvimento O código-fonte deve ser comentado, bem como as variáveis e
nomes de funções devem identificar facilmente seus respectivos
objetivos, visando facilitar a manutenção do código.
O acesso ao ambiente deve ser restrito aos usuários registrados.
Segurança As funcionalidades devem ser acessadas de acordo com o perfil
do usuário (restrição de acesso por perfil).
 111

Encerrando a definição dos requisitos, detalhou-se os requisitos de negócio

(necessidades pedagógicas e tecnológicas agregadas) e chegou-se aos requisitos do sistema,
também denominados requisitos funcionais, os quais serviram como base para a
implementação do ambiente e do agente. Estes requisitos foram especificados utilizando-se o
diagrama de Casos de Uso da UML. Como se utilizou a ferramenta Rational Rose25 para
especificar estes requisitos (e desenvolver todo o restante da modelagem do sistema), os
diagramas foram organizados em diferentes pacotes, de acordo com as ferramentas que se
desejava especificar. Esta organização pode ser observada na Figura 6.3, a qual representa um
diagrama de Pacotes da UML. Este tipo de diagrama tem como objetivo mostrar a
dependência entre diferentes grupos de classes ou componentes de um sistema [FOW00]. A
Figura 6.3 apresenta apenas as relações definidas entre os pacotes implementados no escopo
deste trabalho de Mestrado.

Inform aç ões Ge ren cia do r de

A gendam ento de A tividades
P ess oais In fraEs tru tura
Com prom is s os

E x pos itor de E -m ai ls A M IGO

Notas

Pla n o d e Aula s M ural de Lis ta d e Perg u nta s Chat

Noticias Freq u en tes

Glos s ario de B ibl iogra fia M aterial de

Term os A poio

Figura 6.3 - Diagrama de Pacotes do ambiente PROOGRAMA

Para exemplificar um conjunto de requisitos funcionais especificados, apresenta-se na

Figura 6.4 os requisitos definidos para a ferramenta Agenda de compromissos. O diagrama
indica que os perfis de usuário do tipo professor, monitor e aluno podem incluir, editar,
excluir e visualizar compromissos em suas agendas. Os demais requisitos especificados
podem ser verificados na Seção 2.2 do Apêndice D. Cabe mencionar que, neste momento, o

25
Ferramenta desenvolvida pela Rational Software Corporation.
 112

diagrama de Casos de Uso do agente AMIGO ainda não havia sido definido. Ou seja, as
funcionalidades do agente ainda não haviam sido especificadas. Esta definição ocorreu
somente após a redução do escopo do desenvolvimento, em seguida da apresentação do SA
(Descrito na Etapa 2 desta fase, mais adiante nesta seção).

Agenda de Compromissos: proporciona que

os usuarios agendem seus compromissos,
estando estes vinculados ou nao a disciplina
que estao cursando/ministrando.

Incluir compromisso Editar compromisso

<<include>>
<<include>>

Professor
(from Use Case View) <<include>>

Gerenciar compromisso
Usuario Excluir compromisso
(from Use Case Vi ew)
<<include>>

Monitor
(from Use Case Vi ew)
Visualizar compromisso

Aluno
(from Use Case Vi ew)

Figura 6.4 - Diagrama de Casos de Uso da ferramenta Agenda de compromissos

A definição das ferramentas em diferentes pacotes refletiu a especificação de um

requisito não-funcional de implementação (o qual representa uma decisão de projeto): das
ferramentas funcionarem de forma independente uma das outras. A partir deste diagrama,
definiu-se uma visão geral da arquitetura do sistema e a estrutura interna preliminar do agente
(Vide Figuras 6.5 e 6.6, respectivamente) pois, segundo [SOM03], esboçar a arquitetura do
sistema auxilia na compreensão do mesmo. Neste momento, ainda não se tinha uma visão
geral de quais componentes iriam compor as ferramentas e nem como seria a integração e a
comunicação entre as mesmas. Também não se sabia exatamente sob quais ferramentas o
agente atuaria.
 113

Ferramenta x Ferramenta y

Requisição
Navegador
(browser)
AMIGO
Resposta
Máquina cliente

BD
Máquina servidora

Figura 6.5 - Arquitetura preliminar do ambiente PROOGRAMA

Módulo Configuração de
Gerência de Tarefas

Verificação de Tarefas

Organização dos
Arquivos dos Alunos

Módulo Atualização de
Informações dos Alunos

Módulo Relatórios Módulo Mensagens

para o Professor para os Alunos

Figura 6.6 - Arquitetura interna preliminar do agente AMIGO

Tendo definido as arquiteturas apresentadas em conjunto com a professora

orientadora, era necessário verificar se todos os aspectos desejados para constarem no
ambiente haviam sido contemplados na especificação dos requisitos. Desta forma, fez-se uma
análise comparativa entre os requisitos especificados e as principais características
identificadas quando da análise dos trabalhos correlatos (estas se referem às características
relacionadas na Seção 2.1.5). O resultado desta comparação é apresentado no Quadro 6.II.
 114

Quadro 6.II – Comparação entre as características oferecidas pelos ambientes e o PROOGRAMA

CARACTERÍSTICAS AMCORA AULANET LEARN. WEBCT PROOGRAMA
Características gerais

Administrador Sim Sim Sim Sim Sim

Professor
Usuário Sim Sim Sim Sim Sim
Instrutor/Monitor Não Sim Sim Sim Sim
Aluno Sim Sim Sim Sim Sim
Controle de acesso e diferentes visões conforme o perfil Sim Sim Sim Sim Sim
Ajuda/Help on-line Sim Sim Não ? Sim
Glossário de termos Não Não Não Sim Sim
Mensagens instantâneas Sim Sim Não Não Não
Síncr.

Sala para bate-papo (chat) Sim Sim Sim Sim Sim

Registro das salas de bate-papo Não Sim Sim Sim Sim
Ferramentas de
comunicação

E-mail interno ao curso Não Sim Sim Sim Não

Assínc.

Envio de e-mail a usuários externos ao curso Sim Não Sim Não Sim
Recebimento de e-mail de usuários externos Sim Não Não Não Sim
Lista/Fórum de discussão Sim Sim Sim Sim Sim
Publicação de avisos Sim Sim Não Sim Sim
Agenda/Cronograma de atividades Não Sim Sim Sim Sim
Dados sobre os participantes Sim Não Sim Sim Sim
Elaboração de plano de aula N/A Sim Sim Sim Sim
Ferramentas de

Publicação de material de apoio Sim Sim Sim Sim Sim

professor
apoio ao

Envio de tarefas aos alunos N/A Sim ? ? Sim

Identificação de novas tarefas a serem corrigidas N/A Não Não Não Sim
Manutenção de notas N/A Sim Sim Sim Sim
Geração de relatórios de participação Não Sim ? Sim Não
Agendamento de compromissos Sim Não Não Sim Sim
Ferramentas de
apoio ao aluno

Download de material Sim Sim Sim Sim Sim

Entrega de material por upload Sim Sim Sim Sim Sim
Consulta a resultados de tarefas N/A Sim Sim Sim Sim
Atribuição de status a uma tarefa N/A Não Sim Não Sim
Esclarecimento de dúvidas on-line Sim Não Não Não Sim

Uma segunda forma de validar a especificação dos requisitos, tanto os funcionais

quanto alguns não-funcionais (da categoria Interface com o usuário e facilidade de uso), foi
realizando a prototipação da interface gráfica. Conforme já foi mencionado na Seção 2.2.2, a
prototipação da interface gráfica é um recurso comumente utilizado para a validação e até
mesmo definição dos requisitos de um sistema. Inicialmente, foi feito o storyboard de parte
do sistema no papel. Ou seja, fez-se o esboço especificando a disponibilização dos elementos
nas telas e definindo a seqüência de apresentação destas telas. A partir destes esboços,
algumas telas foram prototipadas em um editor de imagens com recursos bastante simples (o
Paint, da Microsoft) e geradas imagens do tipo bitmap (.bmp), conforme exemplo
apresentado na Figura 6.7. A geração destas imagens teve como objetivo validar com a
professora os elementos usados e suas disposições nas telas, bem como as cores, fontes e
elementos gráficos propostos para serem adotados. Esta validação foi feita em uma reunião da
mestranda com a professora. Como resultado, foram feitas algumas sugestões de alteração de
tipo e tamanho da fonte usada e dos formatos dos botões.
 115

Figura 6.7- Exemplo de interface prototipada em forma de imagem

Após esta primeira validação da interface gráfica com a professora e algumas

discussões sobre os requisitos especificados, alguns destes requisitos foram alterados, como,
por exemplo, permitir que o professor visualize o título de todas as atividades definidas na
ferramenta Atividades em uma listagem única. Dando continuidade a prototipação das
interfaces, gerou-se uma versão preliminar de algumas telas em HTML, através do editor de
HTML FrontPage, também da Microsoft, visando estudar e tomar conhecimento de recursos
até então desconhecidos da ferramenta, uma vez que a única experiência de utilização da
mesma por ambos os integrantes da equipe havia sido na elaboração do site do projeto, um
pequeno período antes da prototipação com o FrontPage (apenas parte da equipe tinha
conhecimento prévio sobre HTML). As duas ferramentas utilizadas para a prototipação, e
posterior desenvolvimento das interfaces, foram adotadas por já estarem disponibilizadas nos
laboratórios da FACIN e não oferecerem custo algum para seus respectivos usos. Neste
momento, a equipe sentiu a necessidade de descrever os padrões que seriam adotados para o
desenvolvimento da interface gráfica, uma vez que os requisitos de Interface com o usuário
estavam descritos apenas de forma textual, o que não foi considerado o suficiente pela equipe
para desenvolver as páginas HTML. Neste contexto, detalhou-se os requisitos de interface,
estabelecendo formalmente os padrões em um documento específico para servir de guia à
equipe. Estes padrões são apresentados no Apêndice E.
 116

Em paralelo à etapa de especificação e validação dos requisitos, em especial através da

prototipação da interface gráfica, parte da equipe estava colocando em prática o estudo
planejado sobre tecnologias (paradigma de desenvolvimento, recursos da linguagem de
programação escolhida, ferramentas para desenvolvimento, entre outros). Foram estudadas
diversas ferramentas que suportam o desenvolvimento em linguagem Java, tais como JBuilder
e Sun ONE Studio, sendo que apenas a segunda dá suporte ao desenvolvimento para a Web,
bem como recursos desta linguagem, em especial, os específicos para este tipo de aplicação
(servlets e JSP). Para melhor compreender estes recursos (ex. como utilizar o protoloco de
envio de e-mails POP), foram desenvolvidas duas aplicações-teste, chat e e-mail, em
diferentes versões. A aplicação-teste e-mail foi futuramente utilizada como base para o
desenvolvimento da ferramenta E-mail do ambiente. Também foi analisada a linguagem
XML, uma vez que se tinha cogitado a adoção desta para o desenvolvimento da interface e
especificação das informações a serem monitoradas e gerenciadas pelo agente.

Outro assunto estudado disse respeito à modelagem e implementação do BD. Estudou-

se os SGBD Oracle e MySQL. Um último assunto estudado, em especial pelos bolsistas, por
se tratar de novidade para ambos, foi a técnica de agentes. Foram realizadas leituras e
discussões sobre os conceitos básicos, algumas metodologias de modelagem e protocolos de
comunicação sobre este assunto. Os resultados destes estudos, descrevendo as vantagens e
desvantagens das ferramentas e dos recursos e técnicas estudadas, foram descritos em um
relatório técnico, parcialmente revisado e ainda não publicado. Após este período de estudos,
as tecnologias e ferramentas escolhidas para o desenvolvimento dos protótipos foram as
seguintes:

• Servlets e JSP: por serem tecnologias específicas para o desenvolvimento para a

Web, conforme já mencionado, e permitirem a organização das diferentes camadas
de uma aplicação (cliente e de negócios);

• Sun ONE Studio 4: para desenvolver o código-fonte. Esta ferramenta, integrada à

plataforma J2EE versão 1.4, disponibiliza tanto um ambiente de
desenvolvimento quanto diferentes contêineres para teste e execução das páginas
JSP e dos servlets, entre eles, Tomcat e J2EE Reference Implementation. Além
disto, pode funcionar como servidor Web, desde que seja configurado para tal;
 117

• MySQL Server e MySQL Control Center: para armazenar os dados da

aplicação e estruturar o BD, respectivamente. Suas distribuições também são
gratuitas.

Além destas, também foram adotadas as ferramentas FrontPage, para elaboração da

interface gráfica; e Rational Rose, para modelar o ambiente (utilizando a UML); ambas já
mencionadas anteriomente. Apesar da ferramenta Rational Rose ter sua licença de uso provida
pela FACIN, levou-se em consideração a utilização da ferramenta de modelagem de
distribuição gratuita ArgoUML [TIG03], para que, posteriormente, a modelagem pudesse ser
disponibilizada e usada por eventuais parceiros que não possuam esta licença. Como a
ferramenta ArgoUML ainda está em desenvolvimento e oferece um conjunto restrito de
diagramas, bem como se mostrou instável durante o pequeno período de uso em
experimentação, decidiu-se pela adoção da Rational Rose. O SGBD MySQL Server foi outra
escolha realizada baseada na distribuição gratuita, entre outras características já descritas na
Seção 2.4.5. Desta forma, mesmo já estando disponível na rede da FACIN, o SGBD Oracle
não foi adotado, pois este precisa de licença para utilização. O critério de seleção das
ferramentas “distribuição gratuita” tem sido bastante enfatizado por este aspecto propiciar
que, futuramente, o ambiente possa ser disponibilizado aos demais parceiros de pesquisa sem
que o fator custo inviabilize a utilização do mesmo por estes parceiros ou demais interessados.
Por fim, uma última opção tecnológica disse respeito à escolha feita para a elaboração da
interface gráfica. Apesar da tecnologia JSP dar suporte à utilização de XML, foi opção da
equipe usar HTML, em função da praticidade e rapidez de desenvolvimento das interfaces
com a utilização do FrontPage, levando em consideração que ambos os integrantes da equipe
precisariam estudar detalhadamente XML para usufruir a mesma.

Com o conhecimento adquirido durante o estudo das tecnologias e levando em

consideração o requisito de implementação que definiu que as ferramentas deveriam ser
desenvolvidas de forma independente umas das outras, elaborou-se uma versão mais
detalhada da arquitetura do ambiente (Vide Figura 6.8), abrangendo a definição dos
componentes que iriam compor o mesmo. O cliente possui a sua disposição a interface
gráfica, através de um navegador Web. Ao executar alguma funcionalidade de uma
ferramenta, um elemento JSP dispara uma requisição ao servidor. Neste momento, o servlet
equivalente é executado e, caso necessite consultar algum dado no BD, a API da ferramenta
 118

em questão é ativada. A API é um mecanismo de tradução e codificação para troca de dados

com o BD. Caso a ferramenta seja uma daquelas que o agente AMIGO atua, este é
comunicado que deve realizar alguma ação. Esta ação pode ser uma resposta a API ou uma
consulta ao BD. No caso de ser qualquer outra ferramenta, a comunicação da API é direta
com o BD. Os dados retornados da consulta ao BD são passados a API que, por sua vez, os
repassa ao servlet que os solicitou. O servlet informa os dados à página JSP , que organiza o
conteúdo dinâmico junto ao estático na página a ser apresentada ao cliente. Em seguida, todas
estas informações são repassadas para a máquina cliente e apresentadas na interface gráfica do
usuário. A Figura 6.8 apresenta uma visão simplificada de todo o sistema, uma vez que existe
uma “caixa” referente para cada uma das ferramentas definidas. Sobre o agente AMIGO,
neste momento, fez-se um avanço quanto à sua especificação: a sua interação com os demais
componentes do ambiente foi definida.

Ferramenta
Servlet

Requisição
Navegador API BD
(browser)

Resposta JSP
Máquina cliente

AMIGO
Máquina servidora

Figura 6.8 - Arquitetura do ambiente PROOGRAMA: visão simplificada dos componentes

Tendo especificado os requisitos, estudado as tecnologias e apresentado uma proposta

de solução ao detalhar a arquitetura do ambiente, faltava ainda planejar o desenvolvimento do
ambiente e do agente. Sendo assim, primeiramente, identificou-se quais seriam os artefatos
(produtos e documentos em geral) a serem entregues ao final do projeto (vide esquema
apresentado na Figura 6.9), e a partir desta lista identificou-se as atividades a serem
realizadas. Após, estimou-se um prazo para realização de cada das atividades e gerou-se o
cronograma do projeto. As atividades e o cronograma de realização das mesmas foram
registrados no mesmo documento que descreve a estrutura da equipe, seus papéis e forma de
trabalho, o qual organiza a estrutura e o plano do projeto (Vide Apêndice C), diferentemente
do que propõe o MSF (um documento específico para cada um dos aspectos abordados no
 119

plano do projeto). Decidiu-se redigir estas informações em um único documento por

considerar-se desnecessário criar documentos distintos, uma vez que o porte do projeto não
aborda todos os aspectos definidos, como, por exemplo, o aspecto treinamento de uso da
ferramenta.

Figura 6.9 - Artefatos a serem produzidos pelo projeto

O término desta atividade coincidiu com a entrega do artigo do SA e sua posterior

apresentação. Levando em consideração as colocações e sugestões da banca examinadora,
analisou-se o estado corrente da pesquisa e redefiniu-se o escopo do desenvolvimento a ser
abordado no contexto deste trabalho de Mestrado. Estabeleceu-se que seriam desenvolvidas
apenas as ferramentas Agenda de compromissos, Atividades e E-mail, que oferecem
informações sobre as quais se desejava que agente atuasse ou que seriam necessárias para o
funcionamento do mesmo. A equipe certificou-se da atuação do agente ao refinar a definição
dos requisitos especificados para cada uma destas ferramentas apontadas como parte do novo
escopo de desenvolvimento do trabalho. O refinamento dos requisitos se deu através da
elaboração dos diagramas de Atividades da UML, os quais foram revisados por um
especialista em ES. Após esta revisão, este especialista foi convidado a fazer do projeto,
colaborando em relação aos aspectos técnicos ao realizar revisões e discutir as soluções
adotadas pela equipe. O refinamento do requisito Incluir compromisso, da ferramenta Agenda
de compromissos, é apresentado na Figura 6.10. Pode-se observar na Figura dois
“requisitantes” de execução das atividades, o usuário e o próprio sistema. Os diagramas de
Atividades elaborados para os demais requisitos refinados encontram-se na Seção 2.2 do
Apêndice D. A redução do escopo de desenvolvimento e o refinamento dos requisitos
caracterizaram o início da Etapa 2 da fase Planejamento.
 120

Usuario Sistema

Incluir compromisso: Regista os dados de um novo

compromisso na Agenda de Compromissos. Caso o
usuario seja o professor, este podera disponibilizar
compromissos para todos os demais participantes da
disciplina.

Escolher data

( Dia, mes, ano )

( Titulo, descricao )
Descrever Registrar
compromisso compromisso

Visualizar icone indicando Incluir ícone compromisso

compromisso incluido definido na interface grafica

Figura 6.10 - Diagrama de atividades do requisito Incluir compromisso

Ao encerrar o refinamento dos requisitos, tendo-se uma visão mais detalhada e precisa
das funcionalidades e dados relacionados a cada uma das ferramentas, definiu-se as
funcionalidades do AMIGO, já descritas no Capítulo 5, através do diagrama de Casos de Uso
do mesmo. Sendo assim, estavam definidas quais informações o agente estaria monitorando e
gerenciando, restava ainda definir como estas informações seriam detectadas e como o agente
iria reagir e tomar decisões. Ou seja, faltava definir o seu algoritmo de funcionamento.

Baseada nos resultados alcançados até aquele momento, a equipe dividiu-se em duas
frentes de trabalho, uma responsável pela elaboração da interface gráfica; e outra, pela
modelagem das classes e tabelas do BD, conforme pode ser visto na Figura 6.11, que
apresenta o fluxo de execução das atividades da Etapa 2. Quanto à primeira frente, esta usou
como referência para a elaboração das páginas HTML os diagramas de Casos Uso e
Atividades definidos para as ferramentas e o documento descrevendo os padrões estabelecidos
para a interface gráfica. A elaboração das páginas se deu organizadas por ferramentas. Cada
conjunto de páginas desenvolvido era validado com a professora e os resultados das
considerações que impactavam os requisitos definidos eram atualizados nos diagramas. Foram
feitas três interações até obter-se as versões finais das interfaces.
 121

Red ução do es copo

de desenvolvimento

Refinam ento
dos re quis itos

Definição dos
requisi tos do AMIG O

Elaboraç ão da M odelagem do
interface gráfic a diagram a de cl ass es

Va lidaç ão com
a profes sora

At ual iza ção M odelagem do

dos requisitos banc o de dados

Defini ção do funcionament o

d o A MIG O

Replanejam ent
o do projeto

Figura 6.11 – Fluxo de execução das atividades da Etapa 2 da fase Planejamento

Em paralelo, identificou-se quais os conceitos que compunham o escopo em questão e

elaborou-se um diagrama de Classes do sistema (Vide Figura 6.12), conforme proposto pela
UML. Este tipo de diagrama tem como objetivo organizar os possíveis objetos que irão
compor o sistema, bem como apresentar a relação entre eles. Segundo [FOW00], existem
divergências quanto à concepção deste diagrama, podendo ser definido sob três perspectivas:
conceitual, que expressa os conceitos do domínio, os quais irão ser, futuramente, associados
às classes do sistema; de especificação, que define as interfaces do software; e de
implementação (física), que detalha os atributos e métodos das classes. Adotou-se a visão
conceitual, que foi se tornando mais clara à medida que se avançava na elaboração das
interfaces gráficas.

A modelagem do BD constituiu a próxima atividade desta fase. As tabelas que

compõem o BD foram definidas a partir dos diagramas de Atividades (que refinaram os
requisitos) e do diagrama de Classes, que expressou os principais conceitos existentes no
sistema. Teve-se bastante dificuldade de definir as restrições de integridade entre as tabelas do
 122

BD pelo fato de ter-se apenas um conhecimento abrangente sobre o assunto. Sendo assim,
pediu-se auxílio a um especialista em BD, o qual é ex-aluno do mesmo programa de pós
graduação que este projeto está vinculado. Este especialista nos ajudou, em especial, a
modelar as relações entre as tabelas que implementam os conceitos relacionados à infra-
estrutura para criação de uma disciplina no ambiente (unidade acadêmica, curso, disciplina,
turma e usuários).

dis c i pl ina unidadeAc adem ic a curs o

grupo

respos t aA tividade
turma ins cri to us uario

ativida de

opcoes A m igo perfi l

c om promis s o

Co ntat oE mai l Ms gEm ailEnviada

Figura 6.12 - Diagrama de classes conceituais do ambiente

A totalidade das tabelas definidas é apresentada na Figura 6.13, sendo que a flecha que
relaciona duas tabelas representa a existência de dependência entre as mesmas. O sentido da
flecha indica qual tabela está recebendo uma chave estrangeira da outra tabela. Para cada uma
das tabelas apresentadas é indicado apenas o nome e o tipo dos atributos que as constituem.
 123

Di ag ra ma si mu l a n do as ta b e l as d o ba n co
de d ado s do a m bi e nte P RO O GRA M A

u nida d eAcad em ica

d is cip lina
i d Di sci p l i n a : In te g e r
no m e Di sci p l i n a : S tri n g
nu m e roCr ed i to s : In te ge r
i dUn i d a d eA ca d em i ca : Inte ge r curs o
si g l a Un i da d e Aca d e m i ca : Stri n g
n u m e ro Cu rso : In te g e r
n o m e Un i da d e Aca d e m i ca : Stri n g
n o m e Cu rso : Stri n g a rq uivoR es po s ta Ativid a de
i d A rq u i vo Re sp o staA ti vi d a d e : In te g e r
n om eA rq u i vo : S tri n g
d ata In se rca o : S tri n g

u su a rio
i d Usua ri o : In teg e r
no m e Co m p l e to : S tri n g
m a tri cu l a : S tri n g
se nh a : S tri n g
turm a pa l avra Se cre ta : Stri n g
i n s crito
i d T u rm a : In te g e r em ai l : S tri n g re s p o s taAti vid ad e
i d Inscri to : In te g e r da taNa sci m en to : Stri n g
n u m e ro T u rm a : Inte ge r i d Respo sta Ati vi d a d e : In te g e r
en d e re co : S tri n g
sta tus : Stri ng
te l e fo n e Re si d en ci al : S tri n g
co nce i to : S tri n g
te l e fo n e Ce l ul a r : S tri n g
co m e nta ri o : S tri n g
ou tra In fo rm a cao : S tri n g

p erfil
i d Pe rfi l : In teg e r
no m e P e rfi l : S tri n g
de scri ca o Pe rfi l : S tri n g

com p rom is s o gru p o

i d Co m p rom i sso : In te g er i dG r up o : In te ge r
de scri ca o Co m p rom i sso : S tri ng
ti p o Com pro m i sso : Stri n g
a tivida d e
aca o : S tri n g
da taCri a cao : S tri n g i d A ti vi d ad e : I nte ge r
da t aA ca o : Stri ng ti tu l o : S tri n g
pe ri o d oA vi soCo m p ro m i sso : In teg e r a ssu n to : S tri n g
fl a g V i su a l i za : Stri n g o bj e ti vo : S tri n g
a ti vi d a de ti po A ti vi d a de : S tri ng
ti po Do cum en to : Stri n g
T urm a
n um ero Pa rti ci pa nt e s : Stri n g
d ata De fi ni ca o : Stri ng
d ata Di sp on i bi l i zaca o : S tri n g
d ata En tre ga : S tri n g
co n fig u raca oAm ig o p eri o d o Avi so Ati vi d a d e : Stri ng
ca b eca l h oCo m p ro mi sso Em a il : S tri ng
r o d ap e Co m p ro m i sso Em ail : S tri ng
n o ti fi ca Inserca oCo m pro m isso P el oA m bi e n te : S tr i ng
n oti fi ca In se rca oCo m p ro m i sso Pe loE m a il : Stri ng
n oti fi ca A l t e rac ao Co m pro m issoP el o A m bi e n te : S tri ng
n otifi caA l t e rac a oCo m pro m i ssoP e lo E m a il : Stri ng
n oti fi ca E xcl u sao Co m prom issoP el o Am bi e n te : St ri ng
a rqu ivo Ativida d e
n oti fi ca E x cl u sa oCo m p rom i sso P elo Em a il : S tri ng
n oti fi ca In se rca oA ti v i da d eP el o Am bi e nte : Stri ng i d Arqu i voA ti vi d a d e : In te g e r
n otifi caIn se rca o A tiv i da d e P e lo Em ail : S tri ng n o m e A rq u i vo : S tri n g
n otifi caA l t e rac a oA ti v i da d eP el o Am bi en te : Stri ng d a ta Inserca o : Stri n g
n oti fi ca A lt e raca o A tiv i da d e P el o Em a i l : S tri n g
n oti fi ca E x cl u sa oAti v i da d eP el o A m bi e n te : S tri ng
n oti fi caE x cl u sa o Ativ i da d e Pe lo E m a il : Stri ng
n oti fi ca Re sp o staAl u n oP el o Am bi e n te : Stri ng
n otifi caRe sp o sta Alu n o P elo Em a il : S tri ng
n oti fi ca A l t e ra c ao Re sp o staAl u n oP el o Am bi e n te : Stri ng
n otifi caA l t e rac a oRe sp o sta Alu n o P elo Em a il : S tri ng
n oti fi ca E xcl u sao Re sp o staA l u n oP el oA m bi e n te : S t ri ng
n oti fi ca E x cl u sa oRe sp o sta A lu n o Pe loE m a il : Stri ng

Figura 6.13 - Tabelas do banco de dados do ambiente

Tendo concluído a modelagem do sistema, já era possível finalizar a especificação do

agente AMIGO. Assim, a próxima atividade disse respeito ao detalhamento dos requisitos do
agente, a identificação dos seus sensores e suas respectivas ações em resposta aos dados
identificados (características estas já mencionadas na Seção 5.2). De posse de todas as
definições necessárias para o desenvolvimento do ambiente e do agente, analisou-se o prazo
disponível e replanejou-se as atividades das demais fases do processo de desenvolvimento.
 124

6.3 Desenvolvimento (Developing)

Uma vez tendo modelado todo o ambiente e o agente, e tomado todas as decisões para
o desenvolvimento de ambos, a fase Desenvolvimento teve como principal atividade a
codificação das especificações feitas na fase anterior. Para iniciar a implementação, portanto,
foi necessário preparar o ambiente de implementação. Solicitou-se a liberação do coordenador
da rede de computadores da FACIN para instalar a versão gratuita da ferramenta Sun ONE
Studio 4.026 e a liberação das portas de comunicação do servidor, quais sejam: de acesso à
Web; de envio e recebimento de e-mails; e de transferência de arquivos. O segundo pedido
não foi atendido até o término da redação deste trabalho, o que nos impediu de instalar a
aplicação no servidor. Desta forma, os testes foram todos realizados nas máquinas locais do
laboratório de trabalho da equipe.

Outra atividade necessária para a codificação das ferramentas, foi a criação da

estrutura física das tabelas do BD. Esta criação foi feita através da ferramenta MySQL
Control Center 0.9, da MySQL AB. A ferramenta não oferece suporte à modelagem do BD,
apenas à criação física das tabelas. Isto justifica, para fins de ilustração, a utilização dos
recursos do diagrama de Classes da UML para representação das tabelas do BD (diagrama já
apresentado na Figura 6.13). Para colocar-se o BD em funcionamento, utilizou-se a versão 4.0
do servidor MySQL Server. A Figura 6.14 apresenta o fluxo de execução de todas as
atividades desta fase.

Tendo a infra-estrutura de desenvolvimento preparada, iniciou-se a codificação das

ferramentas em si. As primeiras funcionalidades desenvolvidas foram àquelas disponíveis
para o Administrador gerenciar a infra-estrutura do curso (criar, editar, excluir e visualizar
cursos, disciplinas, usuários, entre outros). Logo em seguida, foram implementadas as
funcionalidades, sob o ponto de vista do perfil Professor, das ferramentas Atividades e Agenda
de compromissos, nesta ordem. Os dois conjuntos de funcionalidades recém desenvolvidos,
em acréscimo àquelas já implementadas para o Administrador, foram disponibilizados pelo
desenvolvedor e testados pelos demais integrantes da equipe. Pequenas correções na interface
gráfica foram sugeridas e corrigidas após estes testes, denominados Teste de unidade.

26
Esta versão tem uma licença de trinta dias para uso sem custo.
 125

Ins ta laç ã o da in fra-es tr utura

de desenvolvim ento

Criaç ão da estrutura
fís ic a do BD

Im plem entaç ão func ionalidades

infra-es trutura

Im plem entaç ão e tes t e

A tividades (vis ão P rofes s or)

Im plem entaç ão e teste A genda de

c om prom is s os (vis ão P rofes sor)

Im p lem ent aç ão dem ais funcio nalidade s A t ividad es

e A genda (vis ão A luno)

Im plem entação e
t este E -m ai l

Teste de integracão das

ferr ame ntas

Imp lem ent aç ão Redaç ão dos

agente A M IGO M anua is do usuár io

Teste integração Redaç ão do Guia

agente A M IGO de ins talaç ão

Figura 6.14 - Fluxo de execução das atividades da fase Desenvolvimento

Para garantir a restrição de acesso àquelas páginas que são específicas de um perfil de
usuário, adotou-se um mecanismo de filtragem do perfil. Em cada página disponibilizada para
o usuário (arquivo .jsp) é feita a chamada a um arquivo que verifica se o perfil que está
tentando acessar a página é o mesmo liberado na sessão de utilização do ambiente. Caso o
perfil não tenha direito de acesso a esta página, o filtro27 redireciona o comando da aplicação
para a página de login do ambiente. Ao usar este mecanismo provido pelas classes originárias
dos servlets, evita-se que um usuário, ao identificar o endereço de uma página na barra de
endereços do navegador ou burlar os diretórios do servidor, consiga acesso a esta página sem
ter a permissão para tal.

27
Segundo [KUR02], o filtro (do original, servlet filter) permite que se tenha acesso aos objetos enviados e
recebidos quando das requisições ou respostas dos servlets (HttpServletRequest e HttpServletResponse)
antes mesmo que este tome conhecimento destas. Ou seja, é possível interceptar o servlet.
 126

Dando continuidade ao desenvolvimento, implementou-se as funcionalidades restantes

das ferramentas Atividades e Agenda de compromissos, as quais correspondem ao perfil
Aluno. Logo após, a ferramenta E-mail foi desenvolvida na sua totalidade e a integração de
ambas as ferramentas e suas respectivas visões, de acordo com os perfis de usuário, foram
organizadas e testadas pela equipe, caracterizando um Teste de integração. Neste momento,
as inconsistências identificadas durante este teste de integração foram apenas registradas
(Vide Apêndice F). Após uma breve análise, tendo certificado-se que as inconsistências não
iriam interferir no funcionamento do agente ou mesmo prejudicar os objetivos deste trabalho,
optou-se por não corrigi-las. A correção poderá ser realizada posteriormente tomando como
referência o registro feito. Esta decisão foi tomada em função do pouco tempo que se tinha
para o término da implementação dos protótipos.

Neste momento, novamente, organizou-se duas frentes de trabalho, uma focada no

desenvolvimento do agente e outra na redação dos documentos a serem entregues para o
usuário, quais sejam: os Manuais do usuário (um para cada perfil definido para este escopo
do trabalho) e o Guia de configuração do ambiente. Estes documentos podem ser vistos nos
Apêndices A e G, respectivamente. O Guia de instalação foi redigido segundo os passos
necessários para a configuração do ambiente nas máquinas locais da rede da FACIN. Sabe-se
que é necessário ter um guia para a configuração do mesmo no servidor, mas isto não foi
possível em função da restrição das portas de comunicação mencionadas anteriormente.
Quanto ao help on-line, previsto inicialmente para constar no ambiente, não foi desenvolvido.
Em função do tempo, a equipe optou por abrir mão da elaboração deste help, uma vez que os
manuais do usuário suprem, temporariamente, seu objetivo de auxiliar o usuário na utilização
do protótipo do ambiente. Para a versão a ser disponibilizada aos usuários finais, este help on-
line faz-se necessário.

Com a implementação do agente AMIGO, havia-se encerrado o desenvolvimento das

ferramentas definidas para o escopo deste trabalho de Mestrado. Sendo assim, fez-se o
tratamento dos possíveis erros de conexão entre a aplicação e o BD (denominado tratamento
de exceção na linguagem Java), para que se possa identificar qual é a origem dos erros quando
estes ocorrerem. Estas notificações são armazenadas no console de gerência da ferramenta
Sun ONE. Futuramente, pode-se organizar uma forma deste registro ser armazenado, caso
considere-se interessante.
 127

Encerrando esta fase, a equipe realizou um teste mais extensivo da ferramenta e do

ambiente e, mais uma vez, identificou algumas restrições e inconsistências em relação ao que
havia sido modelado. As anotações feitas também se encontram no Apêndice F (e, da mesma
forma que as anteriores, não interferem nos objetivos deste trabalho).

6.4 Estabilização (Stabilizing)

Esta fase foi composta de uma única atividade, apresentada na Figura 6.15, conduzida
pela mestranda e realizada pela professora orientadora deste trabalho. Para revisar os
protótipos desenvolvidos (do ambiente e do agente) e verificar se os mesmos estavam
atendendo as solicitações feitas, a professora utilizou o ambiente em caráter experimental,
realizando uma simulação de uso. Durante esta breve utilização foram observados tanto os
aspectos de usabilidade e interface (ex. fácil compreensão, padronização das cores, nomes e
elementos definidos, entre outros) e os aspectos pedagógicos, tais como o suporte ao
desenvolvimento de uma atividade em grupo, através da permissão do envio do arquivo
correspondente à resposta da atividade identificando o grupo que a desenvolveu. A professora
também consultou o Manual do usuário do Professor. As considerações apontadas foram
apenas registradas, da mesma forma que nos testes feitos anteriormente pela equipe (Vide
Apêndice F). Todas as considerações apontadas no Apêndice F serão atendidas quando do
desenvolvimento da versão a ser disponibilizada aos alunos, para uso experimental em
ambiente real de sala de aula. Este desenvolvimento está previsto para um período
consecutivo à entrega e apresentação deste trabalho.

Teste experimental dos

protótipos com a profes sora

Figura 6.15 - Atividade realizada durante a fase Estabilização

Os testes previstos com os alunos da professora ocorrerão no próximo semestre letivo

à entrega deste trabalho. Estes testes não foram realizados em função do tempo, uma vez que
os protótipos ficaram prontos em um prazo muito próximo da entrega do texto da dissertação,
 128

e pela professora não estar ministrando na graduação nenhuma disciplina de Algoritmos ou

Lapro. Sabe-se que esta questão, caso os protótipos estivesses prontos antes, teria sido
viabilizada pela disposição de um outro professor colega da orientadora. Este professor havia
se colocado à disposição para realizar tal experimento. Por não ter realizado o processo de
teste, correção e reavaliação dos produtos entregues, sabe-se que esta fase não chegou a
constituir completamente o objetivo proposto pelo MSF para a fase Estabilização. Apesar
disto, esta equipe de pesquisa comprometeu-se com a professora de dar continuidade ao
projeto, no mínimo, até ter uma versão estável para utilização em sala de aula, conforme
situação mencionada acima.

6.5 Implantação (Deploying)

A fase Implantação tem dois importantes objetivos, a instalação do software em

ambiente de produção, ou seja, disponibilizá-lo aos usuários finais; e a análise do projeto,
tanto por parte da equipe como dos usuários, sendo que estes avaliam o projeto através da
pesquisa de satisfação quanto ao produto entregue. Apesar destas serem as principais
atividades propostas para esta fase, estas não foram realizadas em sua totalidade. A Figura
6.16 apresenta as atividades realizadas pela equipe.

Dis c us são das

lições aprendidas

P reparação da infra-estrutura para a apresentaç ão

dos protótipos durante a defesa da dis s ertaç ão

Figura 6.16 - Fluxo de execução das atividades da fase Implantação

Uma vez que os protótipos não foram disponibilizados aos alunos, a única análise
realizada foi feita pela equipe de pesquisa. Os integrantes discutiram em uma reunião de
finalização desta etapa do projeto, denominada pelo MSF de Lessons Learned Meeting,
quais aspectos poderiam ser melhorados e destacaram os conhecimentos adquiridos, bem
como manifestaram suas impressões gerais quanto suas participações no projeto. O Quadro
 129

6.III apresenta as principais colocações da equipe sobre os aspectos melhorias e

aprendizados.

Quadro 6.III – Principais resultados da reunião de fechamento desta etapa do projeto

Identificar o quanto antes durante a realização de um projeto o que será desenvolvido
MELHORIAS SUGERIDAS

(por exemplo, quais os objetivos e as funcionalidades)

Estudar previamente as tecnologias
Fazer reuniões mais freqüentes para discutir os assuntos que não são previamente de
domínio da equipe, buscando formalizar e verificar a compreensão dos conhecimentos
adquiridos durante os estudos individuais
Possuir um canal de viabilização das solicitações requisitadas quanto à configuração
do servidor mais ágil para não inviabilizar os testes e desenvolvimentos das aplicações
Melhor compreensão da linguagem de modelagem de sistemas UML
Conhecimento de HTML, bem como de um editor gráfico de páginas para a Internet
Conhecimento da linguagem de programação Java e das tecnologias Servlet e JSP
Melhor conhecimento e aprendizado dos conceitos relacionados ao armazenamento de
APRENDIZADOS DESTACADOS

dados em um banco de dados relacional

Constatação e entendimento de que existe um ciclo de desenvolvimento de um
software, iniciando com a compreensão do problema, passando pela concepção da
solução até chegar a entrega do produto ao cliente
Compreensão da complexidade de desenvolver um software em equipe e das questões
relacionadas
Importância de documentar as decisões de projeto
Importância de respeitar as idéias dos demais integrantes da equipe, proporcionar a
oportunidade de todos colaborarem e incentivar as iniciativas, mesmo que os
resultados apresentados não sejam os mais otimizados ou adequados para a situação
Necessidade de leitura dos assuntos e tópicos abordados
Oportunidade de praticar e aprender a língua inglesa, através da leitura do material de
apoio (livros, tutoriais e artigos)

A segunda e última atividade disse respeito à configuração da máquina a ser utilizada

durante a defesa da dissertação. Esta preparação teve como objetivo, além de ter à disposição
o protótipo para a apresentação, verificar se o Guia de configuração havia sido devidamente
redigido. Por esta razão, a configuração da infra-estrutura foi realizada pela mestranda, sob
orientação do responsável pela implementação. Como se obteve sucesso na configuração,
considera-se que o guia, para os fins que se propõe e a situação de configuração em uma
máquina local à rede da FACIN, está adequadamente redigido. Com esta atividade, a equipe
encerrou o processo de desenvolvimento do PROOGRAMA e do AMIGO no que diz respeito
aos objetivos estabelecidos para esta dissertação de Mestrado.
 130

7 CONSIDERAÇÕES FINAIS

Com o aumento da popularidade da Internet e disponibilização de ferramentas para

criar páginas HTML os professores sentiram-se entusiasmados a gerar seus materiais
digitalmente e disponibilizá-los através destas páginas aos alunos. No decorrer do tempo,
percebeu-se que apenas as páginas estáticas não eram suficientes para dar suporte às
atividades do processo de ensino-aprendizagem. Sendo assim, da necessidade de possuir
recursos de comunicação e de auxílio ao trabalho cooperativo, bem como de ter mecanismos
de gerência das informações geradas da interação dos professores e alunos, surgiram os
ambientes de EAD e, seqüencialmente, as ferramentas de autoria destes ambientes.

Como parte deste grupo de professores e vindo adotando um conjunto de recursos

computacionais para apoio a sua metodologia de ensino-aprendizagem há oito semestres, a
professora orientadora deste trabalho sentiu a necessidade de usufruir um mecanismo
centralizador e gerenciador das informações geradas através da utilização dos recursos
utilizados. Neste contexto, surgiu a idéia originária do Projeto PROOGRAMA, ao qual esta
pesquisa de Mestrado está vinculada.

Inicialmente, esta pesquisa tinha como objetivo propor um agente para gerenciar as
informações oriundas da utilização de um ambiente de suporte ao processo de ensino-
aprendizagem, tanto em situações presenciais como não-presenciais, sendo o AmCorA o
ambiente escolhido, conforme já apresentado. A escolha deste ambiente se deu baseada no
estudo feito sobre alguns ambientes de suporte ao ensino e na metodologia utilizada pela
professora orientadora como apoio ao processo de ensino-aprendizagem. Pelas dificuldades
encontradas para atingir o objetivo mencionado, optou-se por especificar e desenvolver um
ambiente próprio, onde o agente poderia passar a atuar. Desta forma, definiu-se o ambiente
PROOGRAMA, que reúne as melhores características dos ambientes estudados identificadas
pela equipe de pesquisa. A alteração do ambiente base para atuação do agente não trouxe
prejuízos à pesquisa, uma vez que, em sua essência, ambos os ambientes possuem uma
proximidade nos princípios pedagógicos que guiaram suas concepções.
 131

Durante o período da pesquisa, a equipe precisou estudar novos assuntos, aprofundar

tópicos de conhecimento superficial e pôr em prática conhecimentos que se possuíam
previamente para poder modelar, especificar e desenvolver os protótipos do ambiente e do
agente. Após as análises feitas e discussões com a professora e o restante da equipe,
confirmou-se a hipótese de que o agente deveria ser modelado para permitir a sua
configuração e parametrização de acordo com as preferências do usuário, uma vez que os
próprios integrantes manifestaram opiniões diversas quanto à forma que gostariam de
perceber o agente no ambiente. Desta forma, esta foi a hipótese modelada e implementada
neste protótipo do agente.

Espera-se, com os resultados deste trabalho, atender as expectativas da professora

sanando suas necessidades de ter um ambiente centralizador de diversas ferramentas e
gerenciador das informações geradas da utilização deste ambiente e, reduzindo assim, seu
tempo de trabalho gerencial em relação as disciplinas de Algoritmos e Lapro que ministra nos
cursos de graduação da PUCRS.

7.1 Contribuições

As duas grandes contribuições desta pesquisa dizem respeito à definição de um agente

para monitorar e gerenciar informações oriundas da utilização de um ambiente de suporte ao
processo de ensino-aprendizagem e de um ambiente desta natureza em si, bem como a
implementação de um protótipo para validar as definições propostas. A partir destas
definições e protótipos, o Projeto PROOGRAMA possui subsídios suficientes para iniciar o
desenvolvimento de uma versão a ser disponibilizada em caráter real de sala de aula. Outra
contribuição importante é que os responsáveis e parceiros do projeto poderão definir tantas
funcionalidades e agentes quanto desejarem em versões futuras. Isto será possível em função
da arquitetura do ambiente ter sido projetada intencionalmente para receber novas
funcionalidades e ferramentas, bem como agentes de software.

Os documentos elaborados também contribuirão para a continuidade do projeto. Os

novos integrantes da equipe poderão consultar o histórico do projeto gerado através da
documentação e compreender as decisões tomadas e suas justificativas, o que se considera
 132

fundamental para o entendimento da existência de determinadas características e

funcionalidades na arquitetura do ambiente e do agente.

De maneira geral, a descrição da adoção de um PDS para o desenvolvimento de um

software educativo vem a contribuir com a área de IE, uma vez que não se encontra relatos
semelhantes, que auxiliem os profissionais de Educação a modelar e definir seus softwares
educacionais. Esta contribuição pode ser constatada através da publicação de um artigo
discutindo a importância da formalização do processo de desenvolvimento de um software
educacional, no maior e mais importante simpósio brasileiro da área de IE, o Simpósio
Brasileiro de Informática na Educação, oficialmente reconhecido e patrocinado pela
Sociedade Brasileira de Computação (Vide a listagem das demais publicações relacionadas a
este trabalho no Apêndice H).

Em específico, a adoção do MSF trouxe para a equipe o formalismo praticado por

muitas das grandes empresas de desenvolvimento de software nacionais e mundiais, e a
oportunidade de compreender-se na prática as diferentes etapas do desenvolvimento de
softwares em geral, ficando claro a importância das fases de concepção e especificação da
solução (segundo o MSF, denominadas Visão e Planejamento, respectivamente), bem como
que a fase de implementação é dependente das decisões tomadas nestas duas fases anteriores.
A equipe deu-se conta da importância de seguir um formalismo no momento que se iniciou a
especificação dos requisitos do PROOGRAMA e as alterações nem sempre se tornavam
conhecimento de todos, causando o retrabalho de algumas atividades. Sendo assim, decidiu-se
que todas as definições e decisões deveriam ser registradas, para que confusões desta natureza
fossem evitadas. O benefício foi evidente. A partir do momento que os documentos estavam
disponíveis de forma digital, e não mais de forma manuscrita como até então, tornou-se
possível trabalhar de maneira distribuída. Ou seja, os integrantes passaram a ter a
oportunidade de cumprir suas tarefas e atingir seus objetivos individuais no local e horários
desejados, não ficando restritos ao laboratório disponível ao GIE/FACIN e nem ao seu horário
de funcionamento. No caso dos bolsistas, a liberação foi acordada com a professora
orientadora. Esta situação contribuiu para que a equipe agendasse reuniões periódicas de
verificação dos resultados de suas atividades e estes prazos fossem cumpridos. Acredita-se
que se as atividades não tivessem sido bem definidas e organizadas não teria sido possível
atingir os objetivos determinados para esta pesquisa. Para a mestranda, a utilização do MSF
 133

representou, ainda, a oportunidade de colocar em prática no contexto de sua pesquisa de

Mestrado parte do conhecimento adquirido durante seu estágio no convênio que suporta sua
bolsa de pesquisa (Convênio Dell/PUCRS).

Em relação aos protótipos, o fato de ter-se tomado o cuidado de escolher ferramentas

de distribuição gratuita permite a utilização dos mesmos pelos grupos parceiros ou outros
eventuais interessados, uma vez que o custo de adquirir estas ferramentas é nulo. Desta forma,
será possível contribuir com os parceiros através da disponibilização das soluções adotadas e
do conhecimento gerado e, a partir disto, unificar forças para a geração de um ambiente de
suporte ao ensino (presencial ou não) consistente e gratuito, que atenda as necessidades
pedagógicas destes grupos. Ao atuar neste sentido, estar-se-á retribuindo as ajudas e auxílios
recebidos dos demais grupos e atendendo uma das premissas do GIE/FACIN, de trabalhar
integrado a outros profissionais, independentes do caráter da integração: disciplinar ou
interdisciplinar, ficando a critério da natureza de cada pesquisa.

7.2 Limitações e restrições

Em função da restrição de tempo, inerente a qualquer projeto de pesquisa, reduziu-se o

escopo de desenvolvimento pretendido quando da definição do ambiente PROOGRAMA.
Com esta alteração, especificou-se que seriam desenvolvidas no protótipo do ambiente apenas
as ferramentas necessárias para a atuação do agente, a fim de poder atender ao tempo
disponibilizado para um trabalho de porte para o Mestrado.

Quanto às ferramentas, definiu-se como um dos requisitos do projeto que estas devem
ser implementadas de forma independente umas das outras. Ou seja, as ferramentas devem
poder funcionar isoladamente. Este requisito não foi totalmente atendido. Levando-se em
consideração que apenas parte da equipe tinha conhecimento superficial sobre os conceitos
relacionados à organização e utilização de um BD relacional, bem como nenhum dos
integrantes conhecia previamente o SGBD MySQL e que a complexidade de projetar o BD
para que as ferramentas ficassem isoladas seria aumentada, sendo necessário criar uma
linguagem de comunicação entre as diferentes tabelas, a equipe optou por criar um único BD.
Desta forma, existe dependência entre as ferramentas no que diz respeito ao armazenamento
dos dados nas tabelas do BD. Caso a equipe tivesse um maior tempo para o estudo de uma
 134

solução alternativa, esta decisão teria sido evitada. Fato este que não compromete o resultado
obtido, servindo apenas como uma restrição a ser destacada. Para minimizar o futuro trabalho
necessário para realizar este isolamento entre as tabelas, definiu-se uma API de comunicação
entre os servlets e JSPs com o BD, conforme apresentado na Seção 6.2. Todas as funções que
realizam alguma consulta ao BD estão inseridas nas APIs, permitindo uma fácil remoção ou
manutenção no código relativo às tabelas. Por este motivo, considera-se que o requisito foi
atendido parcialmente.

Uma outra limitação foi imposta pela falta de liberação de recursos. O ambiente não
pode ser instalado no servidor da equipe por não terem sido liberadas as portas de
comunicação necessárias. Sabe-se que esta questão é passível de ser resolvida, sem causar
danos ao funcionamento do ambiente. Ao ter estas portas liberadas, o ambiente poderá ser
acessado de qualquer máquina localizada nas diversas redes internas da PUCRS. Ou seja,
computadores cadastrados e reconhecidos pelas Intranets da Universidade. Para acesso
externo, será necessária a liberação da porta de proteção e acesso externo (o firewall), questão
esta a ser discutida e justificada pela professora orientadora deste trabalho. A equipe não
possui autonomia para requisitar tal pedido. Ao ter esta porta liberada, o PROOGRAMA
estará disponível para qualquer usuário que possua uma máquina com acesso à Internet.
Novamente, esta é uma restrição operacional que se salienta e não interfere nos resultados.

No que diz respeito ao AMIGO, no contexto deste protótipo, este tem seus relatórios
retratando informações bastante simples. Isto se deve ao escopo restrito selecionado para esta
pesquisa de Mestrado. As definições feitas para o agente atendem as necessidades da
professora e solucionam a questão do tempo que esta investe na gerência das informações
recebidas dos alunos no que se refere às atividades propostas (trabalhos, exercícios, entre
outras).

Ainda quanto aos protótipos, algumas funcionalidades de gerenciamento da infra-

estrutura não foram implementadas, tal como a exclusão de todo o material relacionado a uma
disciplina em específico, uma vez que, para o funcionamento do AMIGO elas não se faziam
necessárias. Neste mesmo sentido, não se implementou o envio e recebimento de e-mails
para/de usuários com contas externas àquela fornecida pela FACIN. Também não foi
elaborado o help on-line. Sabe-se ainda que os protótipos possuem algumas inconsistências
quanto ao que foi modelado e implementado, conforme descrito nas Seções 6.3 e 6.4. Por
 135

exemplo, ao digitar sua senha errada, o usuário não recebe notificação de que digitou um
valor inconsistente. Os dados informados são simplesmente apagados, exigindo que o usuário
perceba por si mesmo o erro cometido. Tanto estas inconsistências como as funcionalidades
que não foram implementadas neste momento serão atendidas ainda antes dos protótipos
serem disponibilizados em caráter experimental para alunos da turma de Algoritmos da
professora no próximo semestre letivo. A disponibilização para esta turma de Algoritmos virá
a atender outra restrição deste trabalho, a de não ter utilizado experimentalmente o protótipo
em ambiente real de sala de aula. Esta utilização foi apenas simulada com a professora,
durante sua validação dos protótipos.

7.3 Trabalhos futuros

Tendo atendido as questões mencionadas acima, um primeiro trabalho proposto é

disponibilizar os protótipos aos alunos e analisar suas considerações, para tal, devem ser
preparados instrumentos de avaliação. Além das correções inicialmente necessárias nos
protótipos, tem-se uma série de aspectos que podem ser investigados para melhorar e
complementar o ambiente e o agente. A primeira questão a ser estudada é aquela relacionada
à estruturação do BD. Atendendo a especificação das ferramentas funcionarem isoladamente
dar-se-á a opção de, futuramente, definir um mecanismo de configuração das ferramentas a
serem adotadas pelo professor, sendo este o aspecto inicial para transformar o PROOGRAMA
em um ambiente de autoria de cursos.

Considerando que foram selecionadas várias ferramentas de pesquisadores parceiros

para serem disponibilizadas no ambiente, como, por exemplo, a Moonline, para
esclarecimento de dúvidas on-line, é necessário integrá-las ao PROOGRAMA. Neste sentido,
para suprir a necessidade de definir como fazer esta integração, uma vez que nem todas foram
desenvolvidas usando as mesmas tecnologias adotadas neste trabalho, propõe-se uma
arquitetura de integração entre o ambiente PROOGRAMA e as demais ferramentas. Esta
arquitetura foi definida em conjunto com um dos professores parceiros do GIE/FACIN e
submetida como projeto de pesquisa conjunto entre os dois grupos orientados pelos
professores ao CNPq.
 136

A arquitetura de integração do PROOGRAMA irá agregar as ferramentas através da

tecnologia de Web Services, permitindo a troca de dados e informações entre o ambiente e as
ferramentas, localizadas em seus servidores originais. Isto é, não será necessário integrar
fisicamente as ferramentas ao PROOGRAMA. Segundo [HAN03a; HAN03b], Web Services
são aplicações modulares que podem ser descritas, publicadas e invocadas sobre uma rede,
geralmente a Web. Ou seja, é uma interface que descreve uma coleção de operações que são
acessíveis pela rede através de mensagens em formato XML padronizadas. Permitem uma
integração de serviços de maneira rápida e eficiente. Um Web Service é um componente de
software independente de implementação e plataforma. É descrito utilizando uma linguagem
de descrição de serviços, publicado em um registro e descoberto através de um mecanismo
padrão. Desta forma, propõe-se que as ferramentas externas ao PROOGRAMA sejam
excluídas de sua atual arquitetura e encapsuladas em uma estrutura do tipo Adapter. Segundo
[GAM95], este tipo de estrutura permite converter a interface de uma classe em outra
interface, esperada pelos clientes e, desta forma, possibilita que classes com interfaces
distintas e incompatíveis possam trabalhar juntas. O mesmo deve ocorrer para as ferramentas
que estarão sendo invocadas. Esta solução permitirá que outras ferramentas também sejam
endereçadas pelo PROOGRAMA. A Figura 7.1 apresenta a arquitetura de integração
proposta.

Adapter_PROOGRAMA
Camada de composição em Web-
Services
Glossário de termos Material de apoio

Bibliografia Atividades

Material do Curso
Adapter_Fórum

AMIGO E-mail
Fórum
Adapter_Moonline
Chat
Monitor. e Gerência de Informações
Moonline Comunicação Direta

Adapter_ILA Plano de aulas

Informações pessoais
AMBAP Agenda de comprom.

ILA Expositor de notas

Mural
Informações dos Alunos
Comunicação Pública

Figura 7.1 - Arquitetura de integração proposta

 137

Para manter uma única tecnologia no que diz respeito à interface com o usuário,
também se propõe como trabalho futuro a migração da interface gráfica para XML, uma vez
que esta tecnologia é suportada pelos servlets. Sendo assim, será necessário apenas mudar a
interface atual de HTML e JSP para XML. Esta alteração irá permitir uma flexibilização na
interface do usuário, sendo possível alterar mais facilmente características tais como cores de
fundo, tipo e tamanho de fontes, entre outras.

Uma vez que a arquitetura do PROOGRAMA foi intencionalmente projetada para

incluir novos agentes, será possível definir outros agentes para ampliarem a atuação do
AMIGO no que tange a gestão das informações do ambiente, visando auxiliar no processo de
avaliação da aprendizagem dos alunos suportada pelo ambiente virtual. Como, por exemplo,
especificar agentes para auxiliarem na definição de um modelo de aluno; para gerenciarem os
materiais e bibliografias disponibilizadas, notificando os alunos das novidades; e para
analisarem o conteúdo dos arquivos enviados pelos alunos, buscando identificar se o conteúdo
enviado está relacionado ao assunto em questão.

Ainda pode-se apontar como trabalhos futuros o estudo e tratamento nas próximas
versões do ambiente aspectos relacionados à performance e portabilidade do ambiente, no que
diz respeito aos elementos que constituem a interface gráfica (ao adotar-se Java, os aspectos
de portabilidade da implementação como um todo já está garantido).
 138

REFERÊNCIAS BIBLIOGRÁFICAS

[ALL03] ALLAIRE Corporation. JRun. Disponível em: <http://commerce.allaire.

com>. Acesso em: 27 out. 2003.

[ALM02] ALMEIDA, Eliana et al, AMBAP: Um AMBiente de Apoio ao

aprendizado de Programação, In: CONGRESSO NACIONAL DA
SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 22, 2002,
Florianópolis. Anais... Florianópolis: SBC, 2002.

[ALM03] ALMEIDA, Maria Elizabeth. Educação a distância e tecnologia:

contribuições dos ambientes virtuais de aprendizado. In:
CONGRESSO NACIONAL DA SOCIEDADE BRASILEIRA DE
COMPUTAÇÃO, 23., 2003, Campinas. Anais... Campinas:
UNICAMP, 2003.

[ALV97] ALVARES, Luis; SICHMAN, Jaime. Introdução aos Sistemas

Multiagentes. In: JORNADA DE ATUALIZAÇÃO EM
INFORMÁTICA, 16., 1997, Brasília. Anais... Brasília: UnB, 1997.

[AND01] ANDRADE, Adja et al. Requisitos para a modelagem de ambientes de

aprendizagem a distância: Uma proposta da PUCRS Virtual. In:
INTERNATIONAL CONFERENCE ON NEW TECHNOLOGIES IN
SCIENCE EDUCATION, 2001, Aveiro/Portugal. Disponível em:
<http://www.ead.pucrs.br/biblioteca/pesquisas_portal/index.php>.
Acesso em: 04 mar. 2003.

[ASP03] ASP 101: The place where developers go! Disponível em: <http://www.
asp101.com>. Acesso em: 29 out. 2003

[AUL02] AULANET. Manual do Aprendiz. 2. e.d Rio de Janeiro: PUC-Rio, 2002.

Disponível em: <http://www.eduweb.com.br/frame_produto.asp>.
Acesso em: 30 out. 2002.

[AUS80] AUSUBEL, David. Psicologia Educacional. Interamericana: New York,

1980.
 139

[BAC00] BACELO, Ana P. Estudo de Taxonomias de CSCW e Tecnologia de

Framework para Ambientes de Ensino Colaborativo. Trabalho
Individual I (Doutorado em Ciência da Computação) – PPGCC,
Faculdade de Informática, PUCRS, Porto Alegre, 2000.

[BEC00] BECK, Kent. Extreme Programming explained: Embrace change.

Boston: Addison-Wesley, 2000.

[BEL03] BELVEDERE. Disponível em: <http://advlearn.lrdc.pitt.edu/belvedere>.

Acesso em: 12 jun. 2003.

[BIG01] BIGUS, Joseph; BIGUS, Jennifer. Constructiong Intelligent Agents

Using Java. New York: John Wiley and Sons, 2001.

[BOO99] BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The Unified

Modeling Language User Guide. [S.l.]: Addison-Wesley, 1999.

[BOR01] BORDINI, Rafael; VIEIRA, Renata; MOREIRA, Álvaro. Fundamentos de

Sistemas Multiagentes. In: JORNADA DE ATUALIZAÇÃO EM
INFORMÁTICA, 20., 2001, Fortaleza. Anais... Fortaleza, UFC, 2001.

[BOW02] BOWLING, Elizabeth. Understanding the architecture of

LearningSpace. Disponível em: <http://www-10.lotus.com/ldd/ today.
nsf/displayForm/44040B437D06021185256B9C006193F5?OpenDocu
ment>. Acesso em: 04 out. 2002.

[BRI02] BRIOT, Jean-Pierre; DEMAZEAU, Yves. Principes et architecture des

systèmes multi-agents. Paris: Hermes, 2002.

[BRO86] BROOKS, Richard. A robust layered control system for a mobile robot.
IEEE Journal of Robotics and Automation, [S.l.], v. 2, n. 1, mar.
1986.

[CHA01] CHAVES, Thais et al. Um Ambiente para Apoio à Aprendizagem de

Programação, In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA
EDUCAÇÃO, 12., 2001, Vitória. Anais... Vitória: UFES, 2001.

[COC02] COCKBURN, Alistair. Agile Software Development. Boston: Addison-

Wesley, 2002.
 140

[COP03] COPSTEIN, Bernardo. J2EE: Criando Aplicações para Web. Disponível

em: <http://www.inf.pucrs.br/~copstein/LinguagemJavaUML>.
Acesso em: 26 jun. 2003.

[DEI00] DEITEL, Harvey. Java: How to Program. New Jersey: Prentice Hall, 2000.

[DRU03] DRUZIANI, Cássio; LIMA, José. Monitoramento personalizado de

hiperdocumentos como apoio à avaliação em uma ambiente de
ensino-aprendizagem na Web. Dissertação (Mestrado em Ciência da
Computação) – Instituto de Informática, UFRGS, Porto Alegre, 2003.

[ESC03] ESCOL@NET. Disponível em: <http://www.escolanet.com.br/>. Acesso

em: 12 jun. 2003.

[EVA00] EVARISTO, Jaime; CRESPO, Sérgio. Aprendendo a programar:

Programando numa Linguagem Algorítmica Executável (ILA), Porto
Alegre, Book Express, 2000.

[FER91] FERBER, Jacques; GASSER, Les. Intelligence artificielle distribuée. In:

INTERNATIONAL WORKSHOP ON EXPERT SYSTEMS &
THEIR APPLICATIONS, 11., 1991, Avignon/France. Proceedings…
Avignon: [S.n.], 1991.

[FER99] FERBER, Jacques. Multi-Agent Systems: An Introduction to Distributed

Artifical Intelligence. [S.l.]: Addison-Wesley, 1999.

[FOW00] FOWLER, Martin; SCOTT, Kendall. UML Essencial: Um breve guia para
a linguagem-padrão de modelagem de objetos. Porto Alegre:
Bookman, 2000.

[FRA96] FRANKLIN, S.; GRAESSER, A. Is it na Agent, or Just a Program?: A

Taxonomy of Autonomous Agents. International Workshop on Agent
Theories, Architectures and Languages, 1996, Alemanha.
Proceedings… Alemanha: Springer-Verlag, 1996.

[FUK00] FUKS, Hugo. Aprendizagem e Trabalho Cooperativo no Ambiente

AulaNet. Revista Brasileira de Informática na Educação, [S.l.], n.
6, abr. 2002. Disponível em: <http://www.les.inf.puc-rio.br/
groupware>. Acesso em: 19 set. 2002.
 141

[FUK01] FUKS, Hugo; GEROSA, Marco; LUCENA, Carlos. Sobre o

Desenvolvimento e Aplicação de Cursos Totalmente a Distância na
Internet. Revista Brasileira de Informática na Educação, [S.l.], n. 9,
set. 2001. Disponível em: <http://www.les.inf.puc-rio.br/groupware>.
Acesso em: 19 set. 2002.

[FUK02] FUKS, Hugo; RAPOSO, Alberto; GEROSA, Marco. Engenharia de

Groupware: Desenvolvimento de Aplicações Colaborativas. In:
JORNADA DE ATUALIZAÇÃO EM INFORMÁTICA, 21., 2002,
Florianópolis. Anais... Florianópolis: SBC, 2002.

[GAI02] GAIA. Help on-line do ambiente AmCorA. Disponível em: <http://www.

gaia.ufes.br/~helpamcora/amcora.htm>. Acesso em: 11 out. 2002.

[GAM95] GAMMA, Erich et al. Design Patterns: elements of reusable object-

oriented software. Boston: Addison-Wesley,1995.

[GAS92] GASSER, Les. Boundinaries, identity and aggregation: plurality issues

in multi-agent systems. Amsterdam: Elsevier Science, 1992.

[GAV98] GAVA, Tânia. Monitoria On-line: Um ambiente na Internet para apoio ao

atendimento extra-classe. Dissertação (Mestrado em Informática) –
Centro Tecnológico, UFES, Vitória, 1998.

[GAV00] GAVA, Tânia; MENEZES, Crediné. Moonline: Um Sistema Multiagentes

Baseado na Web para Apoio a Aprendizagem, In: SIMPÓSIO
BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 11., 2000,
Maceió. Anais... Maceió: UFAL, 2000.

[GEN94] GENESERETH, M; KETCHPEL, S. Software Agents. Communications

of the ACM, [S.l.], v. 37, n. 7, 1994.

[GIR02] GIRAFFA, Lucia; PINTO, Sérgio; OLIVEIRA, João Batista,

PROOGRAMA: Ambiente Cooperativo de Suporte a Aprendizagem
de Algoritmo e Programação. Relatório Técnico n. 024 – PPGCC,
Faculdade de Informática, PUCRS, Porto Alegre, 2002.

[GOL98] GOLDBERG, Murray. WebCT: A Web-Based Course Authoring Tool.

Disponível em: <http://duff-5.ucs.ualberta.ca/CNS/PUBS/webct-intro.
html>. Acesso em: 04 out. 2002.
 142

[GOM03] GOMES, Alex; WANDERLEY, Eduardo. Elicitando requisitos em projetos

de software educativo. In: CONGRESSO NACIONAL DA
SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 23., 2003,
Campinas. Anais... Campinas: UNICAMP, 2003.

[HAC99] HACK, Luciana. Mecanismos complementares para a avaliação do

aluno na Educação a Distância. Dissertação (Mestrado em Ciência
da Computação) – Instituto de Informática, UFRGS, Porto Alegre,
1999.

[HAN03a] HANSEN, Roseli; PINTO, Sergio. Construindo Ambientes de Educação

Baseada na Web através de Web Services Educacionais. In:
SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO,
14., 2003, Rio de Janeiro. Anais... UFRJ: Rio de Janeiro, 2003.

[HAN03b] HANSEN, Roseli; PINTO, Sergio. GlueScript: Uma Linguagem

Específica de domínio para Composição de Web Services. Dissertação
(Mestrado em Computação Aplicada) – Centro de Ciências Exatas e
Tecnológicas, Unisinos, Porto Alegre, 2003.

[HEW77] HEWITT, C. Viewing Control Structures as Patterns of Passing Messages.

Artificial Intelligence, Holanda: Elsevier Science, v. 3, 1977.

[HÜB03] HÜBNER, Jomi; SICHMAN, Jaime. Organização de Sistemas

Multiagentes. In: ENCONTRO NACIONAL DE INTELIGÊNCIA
ARTIFICIAL, 4., 2003, Campinas. Anais... Campinas: UNICAMP,
2003.

[HUH99] HUHNS, Michael; STEPHENS, Larry. Multiagent system and societies

of agents. In: WEISS, Gehard. (Org.). Multiagent Systems – A
Modern Approach. [S.l.]: MIT Press, 1999. cap. 2.

[HUN02] HUNTER, Jason; CRAWFORD, William. Java Servlet: Programação. Rio

de Janeiro: Ciência Moderna, 2002.

[IHM01] IHMC. Concept Map Software: A Knowledge Construction Toolkit.

Disponível em: <http://cmap.coginst.uwf.edu/>. Acesso em: 16 mai.
2003.
 143

[JAC99] JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James The Unified

Software Development Process. Workinghan: Addison-Wesley
Longman, 1999.

[JEN98] JENNINGS, Nicholas; SYCARA, Katia; WOOLDRIDGE, Michael. A

Roadmap of Agent Research and Development. [S.l.]: [S.n.], 1998.

[KID03] KIDLINK BRASIL. Disponível em: <http://venus.rdc.puc-rio.br/kids/

kidlink>. Acessado em: 12 jun. 2003.

[KIS02] KIST, Tânia. Ambientes de Gerenciamento de Cursos a Distância.

Relatório de Pesquisa nº 314 (Mestrado em Ciência da Computação) -
Instituto de Informática, UFRGS, Porto Alegre, 2002.

[KRU01] KRUCHTEN, Philippe The Rational Unified Process: An introduction.

Boston: Addison-Wesley, 2001.

[KUR02] KURNIAWAN, Budi. Java for the Web with Servlets, JSP, and EJB.
Indianapolis: New Kiders, 2002.

[LAU01] LAUFER, Carlos; BLOIS, Marcelo; CHOREN, Ricardo. Practice on the

Web: A Tool for Learning From Cases. In: SOCIETY FOR
INFORMATION TECHNOLOGY & TEACHER EDUCATION,
2001, Orlando. Proceedings… AACE: [S.n.], 2001.

[LIC03] LICKS; VIEIRA JR.; DE AZEVEDO. TestM@ker: Uma Ferramenta de

Avaliação do Aprendizado à Distância. Relatório de Trabalho de
Conclusão II (Graduação em Ciência da Computação) – Faculdade de
Informática, PUCRS, Porto Alegre, 2003.

[LON97] LONG, Byron; BAECKER, Ronald. A Taxonomy of Internet

Communication Tools. In: WEBNET, AACE, 1997, Toronto.
Proceedings… Toronto: [S.n.], 1997. Disponível em: <http://citeseer.
nj.nec.com/558859.html>. Acesso em: 27 set. 2002.

[LOT99] LOTUS Corporation. Lotus LearningSpace Forum: Student’s Guide. 3th.

ed. Cambridge: Lotus Press, 1999. Disponível em: <http://www-12.
lotus.com/ldd/doc/uafiles.nsf/docs/lsf36/$File/fstudent.pdf>. Acesso
em: 04 out. 2002.
 144

[LUC99] LUCENA, Carlos et al. AulaNet: Ajudando Professores a Fazerem seu

Dever de Casa. In: CONGRESSO NACIONAL DA SOCIEDADE
BRASILEIRA DE COMPUTAÇÃO, 19., 1999, Rio de Janeiro.
Anais... Rio de Janeiro: EntreLugar, 1999. Disponível em:
<http://www.les.inf. puc-rio.br/groupware>. Acesso em: 19 set. 2002.

[MAC99] MACHADO, Julio H.; MENEZES, Paulo. Sistemas de Gerenciamento

para Ensino a Distância. Trabalho Individual (Mestrado em Ciência
da Computação) – Instituto de Informática, UFRGS, Porto Alegre,
1999.

[MAR02] MARCZAK, Sabrina. A Gerência de Informação em Ambientes de

Ensino a Distância: Um Estudo Comparativo. Trabalho Individual II
(Mestrado em Ciência da Computação) – PPGCC, Faculdade de
Informática, PUCRS, Porto Alegre, 2002.

[MCC96] MCCONNELL, Steve. Rapid Development: Taming Wild Software

Schedules. [S.l.]: Microsoft, 1996.

[MEL98] MELO, Washington. Sala de Aula Virtual Cooperativa. Dissertação.

(Mestrado em Ciências) – PESC/COPPE, UFRJ, Rio de Janeiro, 1998.

[MEN98] MENEZES, Crediné et al. QSabe: Trocando Experiências sobre

Informática Educativa em uma Rede de Educadores. Revista
Brasileira de Informática na Educação, [S.l.], n. 2, abr. 1998.
Disponível em: <http://www.inf.ufsc.br/sbc-ie/revista/nr2/ Menezes02.
htm>. Acesso em: 15 jan. 2002.

[MEN99] MENEZES, Crediné; CURY, Davidson. AmCorA: Um Ambiente

Cooperativo para a Aprendizagem Construtivista Utilizando a Internet.
In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA
EDUCAÇÃO, 10., 1999, Curitiba, PR. Anais... Curitiba: UFPR, 1999.

[MENEG02] MENEGUZZI, Felipe. Raciocínio BDI. Trabalho Individual I (Mestrado

em Ciência da Computação) – PPGCC, Faculdade de Informática,
PUCRS, Porto Alegre, 2002.

[MENEZ02] MENEZES, Crediné et al. Educação a distância no Ensino Superior – Uma

proposta baseada em Comunidades... In: SIMPOSIO BRASILEIRO
DE INFORMÁTICA NA EDUCAÇÃO, 13., 2002, São Leopoldo.
Anais... São Leopoldo: UNISINOS, 2002.
 145

[MIC02a] MICROSOFT. Microsoft Solutions Frameworks Essentials: Student

workbook. Microsoft Training & Certification Series, Course number
1846. [S.l.]: Microsoft Press, 2002.

[MIC02b] MICROSOFT. MSF Process Model v. 3.1. White paper, 2002. Disponível
em: <http: //www.microsoft.com/msf>. Acesso em: 20 jun. de 2003.

[MOU96] MOULIN, Bernard; CHAIB-DRAA, Brahim. An Overview of Distributed

Artificial Intelligence. In: O’HARE, Greg; JENNINGS, Nicholas
(Org.). Foundations of Distributed Artificial Intelligence. New York:
John Wiley and Sons, 1996.

[MUS01] MUSA, Daniela et al. Agente para auxílio à avaliação de aprendizagem em

ambientes de ensino na Web. In: SIMPÓSIO BRASILEIRO DE
INFORMÁTICA NA EDUCAÇÃO, 12., 2001, Vitória, ES. Anais...
Vitória: UFES, 2001.

[MYS02] MYSQL. MySQL: Reference Manual, 2002. Disponível em: <http://www.

mysql.com>. Acesso em: 27 jun. 2003.

[NCS03] NCSA. Habanero. Disponível em: <http://www.isrl.uiuc.edu/isaac/

Habanero/>. Acesso em: 12 jun. 2003

[NET02] NETO, Roberto. Curso de JSP. Relatório Técnico (Grupo PET – Programa
Especial de Treinamento) – Ciência da Computação, UFSC,
Florianópolis, 2002. Disponível em: <http://monica.inf.ufsc.br/
Apostilas/jsp.pdf>. Acesso em: 15 ago. 2003.

[NET03] NETTO, Hylson. Agregando Flexibilidade e Configurabilidade ao

Ambiente AmCorA. Dissertação (Mestrado em Engenharia Elétrica)
– PPGEE, Centro Tecnológico, UFES, Vitória, 2003. Disponível em:
<http://www.gaia.ufes.br/amcora>. Acesso em: 25 out. 2003.

[NEW97] NEWMAN, Alexander. Usando Java GRMC. Rio de Janeiro: Campus,

1997.

[NIE00] NIELSEN, Jakob. Desigining Web Usability: the Practice og Simplicity.

Indianapolis: New Riders, 2000.
 146

[NOB02] NOBRE, Isaura. Suporte à Cooperação em um Ambiente de

aprendizagem para Programação (SAmbA). Dissertação (Mestrado
em Informática) – Departamento de Informática, UFES, Vitória, 2002.

[NWA96] NWANA, H. Software Agents: An Overview. In: The Knowledge

Engineering Review. [S.l]: [S.n.], 1996.

[ORA03] ORACLE. Disponível em: <http://www.oracle.com>. Acesso em: 03 jul.

2003.

[PAR99] PARUNAK, V.; ODELL, J. Engineering artifacts for multi-agent

systems. In: Proceedings of MAAMAW Conference in Madrid, Spain,
1999.

[PAU99] PAULK, Mark. et al, The Capability Maturity Model: Guidelines for
Improving the Software Process. Berkley: Addison-Wesley, 1999.

[PES00] PESSOA, José M.; MENEZES, Crediné. QSabe II: A Cooperative Service
for Knowledge Appropriation and Diffusion Using the Internet. In:
INTERNATIONAL CONFERENCE ON ENGINEERING AND
COMPUTER EDUCATION, 2000, São Paulo. Proceedings… São
Paulo: [S.n.], 2000.

[PIN91] PINTO, Sergio; SILVA, João L.; COUTINHO, Hamilton. Construção de

um interpretador de linguagem algorítmica. In: SALÃO DE
INICIAÇÃO CIENTÍFICA DA UFRGS, 3., 1991, Porto Alegre.
Proceedings... Porto Alegre: UFRGS, 1991.

[PIN02] PINTO, Sérgio et al. AVA – Um Ambiente Virtual Baseado em

Comunidades. In: SIMPOSIO BRASILEIRO DE INFORMÁTICA
NA EDUCAÇÃO, 13., 2002, São Leopoldo. Anais... São Leopoldo:
UNISINOS, 2002.

[POL01] POLLICE, Gary. Using the Rational Unified Process for Small Projects:
Expanding Upon eXterme Programming. White Paper, 2001.
Disponível em: <http://www.rational.com/media/products/rup/
tp183.pdf>. Acessado em: 25 jun. 2003.
[PRE01] PRESSMAN, Roger, Software Engineering: A Practioner's Approach.
New York: McGraw-Hill, 2001.
 147

[PRI02] PRIKLADNICKI, Rafael. Desenvolvimento Distribuído de Software e

Processos de Desenvolvimento de Software. Trabalho Individual II
(Mestrado em Ciência da Computação) – PPGCC, Faculdade de
Informática, PUCRS, Porto Alegre, 2002.

[RUS95] RUSSEL, Stuart. Artificial Intelligence: A Modern Approach. New

Jersey: Prentice-Hall, 1995.

[SAN99] SANTOS, Neide. Estado da arte em espaços virtuais de ensino e

aprendizagem. Revista Brasileira de Informática na Educação,
[S.l.], n. 4, abr. 1999. Disponível em: <http://www.inf.ufsc.br/sbc-
ie/revista/nr4/ 070TU-santos.htm>. Acesso em: 12 jun. 2003.

[SAW99] SAWYER, Pete; SOMMERVILLE, Ian; VILLER, Stephen. Capturing the

Benefits of Requirements Engineering. IEEE Software, [S.l.], v. 16, n.
2, Feb. 1999.

[SIC92] SICHMAN, Jaime et al. When can knowledge-based systems be called

agents? In: SIMPÓSIO BRASILEIRO DE INTELIGÊNCIA
ARTIFICIAL, 9., 1992, Rio de Janeiro. Anais… Rio de Janeiro:
UFRJ, 1992.

[SIL01] SILVA, Flávio; MENESES, Eudenia. Integração de Agentes de

Informação. In: In: JORNADA DE ATUALIZAÇÃO EM
INTELIGÊNCIA ARTIFICIAL, 1., 2001, Fortaleza. Anais...
Fortaleza: UFC, 2001.

[SOM03] SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Addison-

Wesley, 2003.

[SUN03a] SUN MICROSYSTEMS. Java. Disponível em: <http://www.java.sun.

com>. Acesso em: 29 jun. 2003.

[SUN03b] SUN MICROSYSTEMS. Servlets. Disponível em:

<http://www.java.sun.com/products/servlets>. Acesso em: 29 jun.
2003.

[SUN03c] SUN MICROSYSTEMS. Java Server Pages. Disponível em:

<http://www.java.sun.com/products/jsp>. Acesso em: 29 jun. 2003.
 148

[SUN03d] SUN MICROSYSTEMS. Java  2 Platform Enterprise Edition.

Disponível em: <http://www.java.sun.com/products/j2ee>. Acesso em:
29 jun. 2003.

[SUN03e] SUN MICROSYSTEMS. Tomcat @ Jakarta. Disponível em:

<http://www. java.sun.com/products/jsp/tomcat>. Acesso em: 17 set.
2003.

[STU03] STUDY WEB. Disponível em: <http://www.studyweb.com>. Acesso em:

12 jun. 2003.

[TIG03] TIGRIS.ORG: Open Source Software Engineering. ArgoUML. Disponível

em: <http://argouml.tigris.org>. Acesso em: 23 jun. 2003.

[TOB01] TOBAR, Carlos et al. Uma Arquitetura de Ambiente Colaborativo para o

Aprendizado de Programação. In: SIMPÓSIO BRASILEIRO DE
INFORMÁTICA NA EDUCAÇÃO, 12., 2001, Vitória, ES. Anais...
Vitória: UFES, 2001.

[WEB00] WEBCT. WebCT 3.0: Getting Started Tutorial. 2000. Disponível em:
<http://www.webct.com>. Acesso em: 17 set. 2002.

[WEI96] WEISS, Gehard; SEN, Sandip. Adaptation and learning in multi-agent

systems. Berlin: Spring-Verlag, 1996

[WEI99] WEIB, Gabriel. Multi-Agent Systems: A modern approach to distributed

artifical intelligence. London: MIT Press, 1999.

[WOO95] WOOLDRIDGE, Michael; JENNINGS, Nicholas. Intelligent Agents:

Theory and Practice. In: The Knowledge Engineering Review. [S.l]:
[S.n.], 1995.

[WOO99] WOOLDRIDGE, Michael. Intelligent Agents. In: WEISS, Gehard. (Org.).

Multiagent Systems: A Modern Approach to Distributed Artificial
Intelligence. Cambridge: MIT Press, 1999.

[WOO01] WOOLDRIDGE, Michael. An Introduction to Multi-Agent Systems.

West Sussex: John Wiley Sons, 2002.
 149

[WOR02] WORLD Bank Learning Network. LearnigSpace Style Guide. Disponível

em: <http://www.worldbank.org/distancelearning/Resource/Lsg/lsg.
htm>. Acesso em: 04 out. 2002.

[XTP02] EXTREME PROGRAMMING. Extreme Programming: A Gentle

Introduction. White Paper, 1999. Disponível em: <http://www.
extremeprogramming.org>. Acesso em: 25 jun. 2003.

[YIN01] YIN, Robert. Estudo de Caso: planejamento e métodos. São Paulo:

Bookman, 2001.
 150

APÊNDICE A – Manual do usuário: Professor

 185

APÊNDICE B – Visão e Escopo do Projeto PROOGRAMA

 199

APÊNDICE C – Estrutura e Plano do Projeto PROOGRAMA

 217

APÊNDICE D – Especificação Funcional do Projeto

PROOGRAMA
 263

APÊNDICE E – Especificação da Interface Gráfica do Projeto

PROOGRAMA
 284

APÊNDICE F – Inconsistências identificadas nos protótipos

 287

APÊNDICE G – Guia de configuração do ambiente

PROOGRAMA
 290

APÊNDICE H – Publicações do Projeto PROOGRAMA

 O Projeto PROOGRAMA na Internet

http://www.inf.pucrs.br/~giraffa/proograma

Esta pesquisa foi parcialmente financiada pelo Convênio Dell/PUCRS, através da Lei de
Informática Brasileira (Lei nº. 8.248/91). Também financiada pelo Centro de Tecnologia XML
Microsoft/PUCRS e pelos órgãos de fomento MEC/SESu e FAPERGS.

Este trabalho foi digitado conforme o Guia para Apresentação de Trabalhos Acadêmicos, Teses e
Dissertações da Biblioteca Central Irmão José Otão da PUCRS, segundo a NBR 14724 proposta
pela ABNT, atualizado em 06 de agosto de 2003.
 AMIGO - Um Agente para MonIItorar e Gerenciar infO
Ormações
no ambiente PROOGRAMA
Espaço reservado para anotações dos membros da Comissão Examinadora
 AMIGO - Um Agente para MonIItorar e Gerenciar infO
Ormações
no ambiente PROOGRAMA
Espaço reservado para anotações dos membros da Comissão Examinadora