amigo

161
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

Upload: luciamgiraffa

Post on 06-Jun-2015

416 views

Category:

Documents


3 download

DESCRIPTION

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.

TRANSCRIPT

Page 1: AMIGO

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

AAMMIIGGOO Um AAgente para MMonIItorar e GGerenciar infOOrmações

Porto Alegre, 2003

Page 2: AMIGO

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

Page 3: AMIGO

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.

Page 4: AMIGO

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.

Page 5: AMIGO

À 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!

Page 6: AMIGO

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

(Autor desconhecido)

Page 7: AMIGO

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.

Page 8: AMIGO

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.

Page 9: AMIGO

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

Page 10: AMIGO

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

Page 11: AMIGO

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

Page 12: AMIGO

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

Page 13: AMIGO

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

Page 14: AMIGO

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

Page 15: AMIGO

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

Page 16: AMIGO

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

Page 17: AMIGO

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

Page 18: AMIGO

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

Page 19: AMIGO

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.

Page 20: AMIGO

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.

Page 21: AMIGO

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.

Page 22: AMIGO

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.

Page 23: AMIGO

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];

Page 24: AMIGO

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

Page 25: AMIGO

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.

Page 26: AMIGO

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.

Page 27: AMIGO

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.

Page 28: AMIGO

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

Page 29: AMIGO

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).

Page 30: AMIGO

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.

Page 31: AMIGO

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.

Page 32: AMIGO

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.

Page 33: AMIGO

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

Page 34: AMIGO

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.

Page 35: AMIGO

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.

Page 36: AMIGO

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.

Page 37: AMIGO

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

Page 38: AMIGO

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.

Page 39: AMIGO

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.

Page 40: AMIGO

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

Page 41: AMIGO

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

Page 42: AMIGO

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

Page 43: AMIGO

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,

Page 44: AMIGO

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

Car

acterísticas gerais CARACTERÍSTICAS AMCORA AULANET LEARNINGSPACE WEBCT

Usu

ário

Administrador Sim Sim Sim Sim

Professor Sim Sim Sim Sim

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

Fer

ramen

tas de

co

munica

ção

Síncr. Mensagens instantâneas Sim Sim Não Não

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

Registro das salas de bate-papo Não Sim Sim Sim

Assínc.

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

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

Fer

ramen

tas de

ap

oio ao

pro

fessor

Elaboração de plano de aula N/A Sim Sim Sim

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

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

Fer

ramen

tas de

ap

oio ao

aluno Agendamento de compromissos Sim Não Não Sim

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

Page 45: AMIGO

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

Page 46: AMIGO

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.

Page 47: AMIGO

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.

Page 48: AMIGO

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

Page 49: AMIGO

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.

Page 50: AMIGO

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].

Page 51: AMIGO

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

Page 52: AMIGO

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

Page 53: AMIGO

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]

Page 54: AMIGO

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:

Page 55: AMIGO

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

Page 56: AMIGO

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

Page 57: AMIGO

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).

Page 58: AMIGO

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;

Page 59: AMIGO

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.

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

Banco de dados

Enterprise

Beans Servlets

HTML Dinâmico

JSP Java Applet

Camada de informações

Camada de negócios

Camada cliente

Page 60: AMIGO

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]

Page 61: AMIGO

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.

Page 62: AMIGO

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].

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

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

<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>

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();

}

}

Page 63: AMIGO

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].

Page 64: AMIGO

63

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.

<%@ 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>

Page 65: AMIGO

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].

Page 66: AMIGO

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

Page 67: AMIGO

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.

Page 68: AMIGO

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.

Page 69: AMIGO

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

Page 70: AMIGO

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

Page 71: AMIGO

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:

Page 72: AMIGO

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.

Page 73: AMIGO

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.

Page 74: AMIGO

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

Page 75: AMIGO

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.

Page 76: AMIGO

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/ FUNCIONALIDADE

PERFIL DE USUÁRIO

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 disciplina

x x

Excluir registro andamento disciplina

x x

Page 77: AMIGO

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

Page 78: AMIGO

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/ FUNCIONALIDADE

PERFIL DE USUÁRIO

PROFESSOR MONITOR ALUNO ADMIN.

LOGIN

Acessar o ambiente x x x x

Lembrar senha x x x

GERAL

Visualizar informações gerais sobre o ambiente

x x x x

Enviar e-mail para a coordenação do ambiente

x x x x

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,

Page 79: AMIGO

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.

Page 80: AMIGO

79

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

Monitor. e Gerência de Informações

Comunicação Pública

ILA

AMBAP

Teste de Algoritmos

Informações dos Alunos

E-mail

Comunicação Direta

Material do Curso

Agenda de comprom.

Chat

Fórum

Mural

Glossário de termos

Bibliografia

Material de apoio

Atividades

Informações pessoais

Expositor de notas

AMIGO

Plano de aulas

Moonline

Page 81: AMIGO

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/ FUNCIONALIDADE

PERFIL DE USUÁRIO

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

Page 82: AMIGO

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.

Page 83: AMIGO

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

Page 84: AMIGO

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.

Page 85: AMIGO

84

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

FERRAMENTA/ FUNCIONALIDADE

PERFIL DE USUÁRIO

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

Page 86: AMIGO

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.

Page 87: AMIGO

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/ FUNCIONALIDADE

PERFIL DE USUÁRIO

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 discussão

x x

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

Page 88: AMIGO

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

Page 89: AMIGO

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.

Page 90: AMIGO

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.

Page 91: AMIGO

90

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

FERRAMENTA/ FUNCIONALIDADE

PERFIL DE USUÁRIO

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

Page 92: AMIGO

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/ FUNCIONALIDADE

PERFIL DE USUÁRIO

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.

Page 93: AMIGO

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

Page 94: AMIGO

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 é

Page 95: AMIGO

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.

Page 96: AMIGO

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.

Page 97: AMIGO

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

Page 98: AMIGO

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.

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,

Verificação de arquivos enviados

Mensagens para os usuários

Verificação de compromissos e atividades

Configuração de monitoramento de ferramentas

Geração de relatórios

Page 99: AMIGO

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

Page 100: AMIGO

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.

Gerar relatorio por estatistica

Gerar relatorio detalhado

AMIGO: Reune as funcionalidades

disponibilizadas pelo agente AMIGO.

Usuario

(from Use Case View)

Professor

(from Use Case View)

Comunicar resultado do

monitoramento de compromissos

Monitorar compromissos

Monitorar material resposta

atividade

Gerar relatorio

Amigo

<<agent>>

Comunicar resultado do

monitoramento do materialAluno

(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

Page 101: AMIGO

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.

Solicitar monitoramento da

Agenda de Compromissos

Analisar compromisso para

verificar proximidade da data

Comunicar resultado do

monitoramento de compromissos

<<use case>>

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.

( Periodo aviso )

[ dCompr-dAtual<=PeriodoAviso ]

[ dCompr-dAtual>PeriodoAviso ]

AgenteAMIGOProfessor

Figura 5.6 - Diagrama de Atividades do requisito Monitorar compromissos

Formatar texto comunicando a

proximidade da atividade

( Dados compromisso )

Comunicar resultado do monitoramento

de compromissos: Comunica ao

usuario, atraves de um e-mail, a

proximidade de um compromisso.

Receber e-mail com o texto que

foi preparado pelo e-mail

( Texto formatado )

[Por e-mail]

Receber e-mail com o texto que

foi preparado pelo ambiente

[Pelo ambiente]

UsuarioAgenteAMIGO

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

Page 102: AMIGO

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.

Page 103: AMIGO

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.

Page 104: AMIGO

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.

Page 105: AMIGO

104

Identificação

do problema

Estudo de trabalhos

correlatos

Proposta de solução

baseada no AmCorA

Estudo detalhado do

am biente AmCorA

Proposta de c riação do

ambiente PROOGRAMA

Definição da visão

da solução

Identificação dos

requis itos de negócio

Identificação dos

perfis de usuário

Definição do

escopo do projeto

Escolha da linguagem de

programação

Definição dos papéis e

responsabilidades dos integrantes

Seleção dos bols istas integrantes

da equipe de pesquisa

Proposta defendida

no PEP, em Dez/02.

Relatado no TI- II,

entregue em Nov/02.

Organização da forma

de trabalho da equipe

Elaboraçã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.

Page 106: AMIGO

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.

Page 107: AMIGO

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.

Page 108: AMIGO

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.

Page 109: AMIGO

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

Page 110: AMIGO

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.

Especificação

dos requis itos

Modelagem UML:

Casos de uso

Definição da

arqu itetura prelim inar

Prototipação da

interface gráfica

Validação com

a professora

Atualização da

espec ificação dos requis itos

Estudo sobre

as tecnologias

Seleção das

tecnologias

Desenvolvimento de

aplicações-teste

Detalhamento

da arqu itetura

Planejamen to

do projeto

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.

Page 111: AMIGO

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

Interface com o usuário e facilidade de uso

As alternativas na interface gráfica que indiquem a seleção de mais de uma opção simultaneamente devem ser indicada pelo elemento gráfico HTML denominado checkbox.

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.

Documentação

Os manuais de usuário devem ser específicos para cada um dos perfis definidos.

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.

Portabilidade

O protótipo do sistema deve funcionar no sistema operacional Windows.

O protótipo do sistema deve ser compatível como navegador Internet Explorer 5.0 ou superior.

Implementação e padrões

de desenvolvimento

As ferramentas desenvolvidas devem funcionar independentemente umas das outras.

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.

Segurança

O acesso ao ambiente deve ser restrito aos usuários registrados.

As funcionalidades devem ser acessadas de acordo com o perfil do usuário (restrição de acesso por perfil).

Page 112: AMIGO

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.

Agendamento de

Compromissos

Gerenciador de

InfraEs truturaAtividadesInformações

Pessoais

Glossario de

Termos

Material de

Apoio

Bibl iogra fia

Mural de

Noticias

ChatLis ta de Perguntas

Frequentes

E -mai lsExpositor de

Notas

Plano de Aulas

AMIGO

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.

Page 113: AMIGO

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

Visualizar compromisso

Aluno

(from Use Case View)

Usuario

(from Use Case View)

Gerenciar compromisso

Professor

(from Use Case View)

Excluir compromisso

Monitor

(from Use Case View)

<<include>>

<<include>>

<<include>>

<<include>>

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.

Page 114: AMIGO

113

Figura 6.5 - Arquitetura preliminar do ambiente PROOGRAMA

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.

Organização dos Arquivos dos Alunos

Módulo Mensagens para os Alunos

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

Verificação de Tarefas

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

Módulo Relatórios para o Professor

Máquina cliente

Navegador (browser)

Requisição

Resposta AMIGO

Ferramenta x

BD

Máquina servidora

Ferramenta y

Page 115: AMIGO

114

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

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

Usu

ário

Administrador Sim Sim Sim Sim Sim

Professor 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

Fer

ramen

tas de

co

munica

ção

Síncr. Mensagens instantâneas Sim Sim Não Não Não

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

Registro das salas de bate-papo Não Sim Sim Sim Sim

Assínc.

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

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

Fer

ramen

tas de

ap

oio ao

pro

fessor

Elaboração de plano de aula N/A Sim Sim Sim Sim

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

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

Fer

ramen

tas de

ap

oio ao

aluno Agendamento de compromissos Sim Não Não Sim Sim

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.

Page 116: AMIGO

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.

Page 117: AMIGO

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;

Page 118: AMIGO

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

Page 119: AMIGO

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.

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

Máquina cliente

Navegador (browser)

Requisição

Resposta

AMIGO

Servlet

JSP

API BD

Ferramenta

Máquina servidora

Page 120: AMIGO

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.

Page 121: AMIGO

120

Escolher data

Descrever

compromisso

( Dia, mes, ano )

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.

Registrar

compromisso

Incluir ícone compromisso

definido na interface grafica

Visualizar icone indicando

compromisso incluido

( Titulo, descricao )

SistemaUsuario

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.

Page 122: AMIGO

121

Redução do es copo

de desenvolvimento

Refinamento

dos requis itos

Definição dos

requisi tos do AMIGO

Elaboração da

interface gráfica

Va lidação com

a professora

Atual ização

dos requisitos

Modelagem do

diagram a de classes

Modelagem do

banco de dados

Defini ção do funcionamento

do AMIGO

Replanejament

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

Page 123: AMIGO

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).

compromisso

unidadeAcadem ica cursodiscipl ina

usuario

perfi lopcoesAmigo

respost aA tividade

grupo

turma

atividade

Contat oEmai l

inscri to

MsgEmailEnviada

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.

Page 124: AMIGO

123

Diag rama simul ando as tab e las d o ban co

de dado s do a m bie nte PRO OGRAM A

com prom iss o

idComprom isso : In teger

descricaoComprom isso : S tri ng

tipoCom prom isso : String

acao : S tring

dataCriacao : S tring

dat aAca o : Stri ng

periodoAvisoComprom isso : In teger

flagV isua l i za : String

arquivoAtividade

i dArqu ivoAti vidade : In teger

nomeArqu ivo : S tri ng

data Insercao : String

a ti vid ade

T urma

unidadeAcadem ica

i dUn idadeAcadem ica : Integer

sig laUnidadeAcadem ica : String

nomeUnidadeAcadem ica : String

turma

i dTurm a : In teger

numeroT urma : Integer

curso

numeroCurso : In teger

nomeCurso : String

dis cip lina

idDiscip l ina : In teger

nomeDiscip l ina : S tring

numeroCred i to s : In te ger

usuario

idUsuario : In teger

nomeComple to : S tring

matri cu la : S tri ng

senha : S tring

pa lavraSecre ta : String

em ai l : S tring

dataNascim ento : String

endereco : S tri ng

te le foneResidencial : S tri ng

te le foneCelula r : S tring

outra In formacao : S tring

perfil

idPerfi l : In teger

nomePerfi l : S tring

descricaoPerfi l : S tri ng

configuracaoAm igo

cab eca lhoCompro missoEm a il : S tri ng

rodap eComprom isso Em ail : S tring

noti fi ca InsercaoCom prom issoP eloAm bien te : S tr ing

n oti fi ca In serca oCom prom isso PeloEm ail : Stri ng

n oti fi caA lt e racaoCom prom issoP elo Ambie nte : S tri ng

n otifi caA lt e racaoCom prom issoPelo Email : String

n oti fi caExcl usaoCom prom issoP eloAm bien te : St ring

n oti fi caEx cl usaoCom prom issoPeloEm ail : S tring

n oti fi ca In serca oAti v idad eP elo Am bie nte : Stri ng

n otifi caIn serca oAtiv idad ePelo Em ail : S tring

n otifi caA lt e racaoAti v ida deP el oAmbi ente : String

n oti ficaA lt e racaoAtiv ida dePeloEmai l : S tring

n oti fi caEx cl usaoAtiv ida deP elo Ambie nte : S tring

n oti fi caEx cl usaoAtiv ida dePelo Email : Stri ng

n oti fi caRe sp ostaAlun oP elo Ambie nte : String

n otifi caRe sp ostaAlun oPelo Email : S tring

n oti fi caA lt e racaoResp ostaAlun oP elo Am bie nte : String

n otifi caA lt e racaoResp ostaAlun oPelo Em ail : S tring

n oti fi caExcl usaoRespo staA lun oP eloAm bien te : S t ring

n oti fi caEx cl usaoRespo staA lun oPeloEm ail : Stri ng

atividade

idA tividade : I nteger

ti tu lo : S tring

assunto : S tri ng

obje tivo : S tring

ti po Ati vid ade : S tring

ti poDocum ento : String

num eroPartici pant es : String

data Defini cao : Stri ng

dataDispon ibi l i zacao : S tring

dataEntrega : S tring

periodoAvisoAtividade : Stri ng

arquivoRespos taAtividade

idArqu ivoRespostaAti vidade : In teger

nom eArqu ivo : S tring

data Insercao : S tri ng

i nscrito

id Inscri to : In tegerrespos taAti vidade

idRespostaAtividade : In teger

sta tus : Stri ng

conce i to : S tri ng

comentario : S tring

grupo

i dGrupo : In te ger

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.

Page 125: AMIGO

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.

Page 126: AMIGO

125

Insta lação da in fra-es trutura

de desenvolvimento

Criação da estrutura

fís ica do BD

Implementação funcionalidades

infra-estrutura

Im plementação e test e

Atividades (visão Professor)

Implementação e teste Agenda de

compromissos (visão Professor)

Imp lementação dem ais funcionalidades At ividades

e Agenda (visão Aluno)

Implementação e

t este E-mai l

Imp lem entação

agente AMIGO

Teste de integracão das

ferramentas

Teste integração

agente AMIGO

Redação do Guia

de instalação

Redação dos

Manua is do usuár io

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.

Page 127: AMIGO

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.

Page 128: AMIGO

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 professora

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,

Page 129: AMIGO

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 cussão das

lições aprendidas

Preparação da infra-estrutura para a apresentação

dos protótipos durante a defesa da dissertaçã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

Page 130: AMIGO

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

MELHORIA

S SUGERID

AS Identificar o quanto antes durante a realização de um projeto o que será desenvolvido

(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

APRENDIZ

ADOS D

EST

ACADOS

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 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.

Page 131: AMIGO

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.

Page 132: AMIGO

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

Page 133: AMIGO

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

Page 134: AMIGO

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

Page 135: AMIGO

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

Page 136: AMIGO

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.

Page 137: AMIGO

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.

Figura 7.1 - Arquitetura de integração proposta

Adapter_Fórum

Fórum

Adapter_Moonline

Moonline

Monitor. e Gerência de Informações

Comunicação Pública

Informações dos Alunos

E-mail

Comunicação Direta

Material do Curso

Agenda de comprom.

Chat

Mural

Glossário de termos

Bibliografia

Material de apoio

Atividades

Informações pessoais

Expositor de notas

AMIGO

Plano de aulas

Adapter_PROOGRAMA

Adapter_ILA

AMBAP

ILA

Camada de composição em Web-

Services

Page 138: AMIGO

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).

Page 139: AMIGO

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.

Page 140: AMIGO

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?OpenDocument>. 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.

Page 141: AMIGO

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.

Page 142: AMIGO

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.

Page 143: AMIGO

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.

Page 144: AMIGO

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.

Page 145: AMIGO

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.

Page 146: AMIGO

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.

Page 147: AMIGO

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.

Page 148: AMIGO

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.

Page 149: AMIGO

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.

Page 150: AMIGO

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.

Page 151: AMIGO

150

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

Page 152: AMIGO

185

APÊNDICE B – Visão e Escopo do Projeto PROOGRAMA

Page 153: AMIGO

199

APÊNDICE C – Estrutura e Plano do Projeto PROOGRAMA

Page 154: AMIGO

217

APÊNDICE D – Especificação Funcional do Projeto

PROOGRAMA

Page 155: AMIGO

263

APÊNDICE E – Especificação da Interface Gráfica do Projeto

PROOGRAMA

Page 156: AMIGO

284

APÊNDICE F – Inconsistências identificadas nos protótipos

Page 157: AMIGO

287

APÊNDICE G – Guia de configuração do ambiente

PROOGRAMA

Page 158: AMIGO

290

APÊNDICE H – Publicações do Projeto PROOGRAMA

Page 159: AMIGO

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.

Page 160: AMIGO

AAMMIIGGOO - Um AAgente para MMonIItorar e GGerenciar infOOrmações

no ambiente PROOGRAMA

Espaço reservado para anotações dos membros da Comissão Examinadora

Page 161: AMIGO

AAMMIIGGOO - Um AAgente para MMonIItorar e GGerenciar infOOrmações

no ambiente PROOGRAMA

Espaço reservado para anotações dos membros da Comissão Examinadora