P. 1
AMIGO

AMIGO

|Views: 417|Likes:
Published by luciamgiraffa
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.
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.

More info:

Categories:Types, School Work
Published by: luciamgiraffa on Aug 08, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF or read online from Scribd
See more
See less

09/29/2012

pdf

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL FACULDADE DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CURSO DE MESTRADO

Sabrina dos Santos Marczak

AMIGO
Um Agente para MonItorar e Gerenciar infOrmações

Porto Alegre, 2003

SABRINA DOS SANTOS MARCZAK

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

Dissertação apresentada como requisito parcial à obtenção do grau de Mestre, pelo Programa de Pós-Graduação em Ciência da Computação da Pontifícia Universidade Católica do Rio Grande do Sul. Orientadora: Profª. Drª. Lucia Maria Martins Giraffa

Porto Alegre, 2003

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

AGRADECIMENTOS

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

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

Aos incansáveis e dedicados bolsistas (e amigos) Gláucio Almeida e Luana Bernardino. Pelas suas iniciativas e vontade de aprender. Por todas as vezes que esperaram com paciência a demanda de uma nova atividade e assunto para estudar e pesquisar. Por terem entendido o que é trabalhar em equipe e terem atuado como integrantes de uma.

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

Aos demais especialistas, amigos e colegas de curso consultados – Alberto Chemale, Claudia Pedroso, Leandro Lopes e Rafael Prikladnicki, pelas críticas feitas e alterações propostas. Pelas dicas de recursos e soluções que poderiam ser adotadas. Pelas revisões e leituras nos diversos textos redigidos no contexto deste trabalho.

À minha estimada família – Ricardo, Maria Luisa, Samuel (e Sam, o cachorro), pelo incondicional apoio prestado, cada um a sua maneira. Por terem sido, mais uma vez, minha sustentação quando eu estava prestes a desmoronar. Por estarem sempre dispostos a me escutar e conversar. Por terem compartilhado as angústias e as alegrias relacionadas a mais esta etapa da minha vida (assim como em todas as outras). Pelo amor incondicional que possuem por mim.

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

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

Ao Projeto MASP – Multi-Agent Systems development, coordenado pelo Prof. Dr. Ricardo Bastos, o qual disponibilizou sua infra-estrutura (servidor, computadores pessoais e sala de pesquisa). A utilização destes recursos contribui em diversos aspectos no desenvolvimento deste trabalho.

Por fim, e não menos importante, aos patrocinadores do projeto – Convênio Dell/PUCRS, Centro de Tecnologia XML Microsoft/PUCRS, MEC/SESu e FAPERGS, pelo suporte financeiro oferecido. Sem este suporte nosso projeto não teria deixado de ser uma idéia e se tornado real.

A todos, meus sinceros agradecimentos!

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

(Autor desconhecido)

RESUMO

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

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

LISTA DE FIGURAS

Figura 2.1 - Ferramenta Configurador para um grupo específico [NET03] ........................... 26 Figura 2.2 - Menu de opções do ambiente Sala Individual [NET03] ..................................... 27 Figura 2.3 - Interface do aprendiz com destaque ao menu de funcionalidades [FUK01] ....... 31 Figura 2.4 - Interface do módulo Schedule [LOT99] ............................................................ 36 Figura 2.5 - Ferramentas do ambiente WebCT [BAC00] ...................................................... 39 Figura 2.6 - Arquitetura de um agente reativo [RUS95]........................................................ 52 Figura 2.7 - Arquitetura de um agente cognitivo [RUS95] .................................................... 54 Figura 2.8 - Camadas (ou níveis) da plataforma J2EE™ ....................................................... 58 Figura 2.9 - Exemplo Hello World: código-fonte da página HTML [COP03] ....................... 61 Figura 2.10 - Exemplo Hello World: código-fonte da classe servlet [COP03] ....................... 61 Figura 2.11 - Exemplo Contador: código-fonte da página JSP [COP03] ............................... 63 Figura 3.1 – Exemplo de mapa conceitual parcial dos conceitos da disciplina Lapro ............ 68 Figura 4.1 - Tela de acesso à funcionalidade de formação de uma turma .............................. 74 Figura 4.2 - Tela de acesso ao ambiente PROOGRAMA...................................................... 76 Figura 4.3 - Tela principal de acesso a área de trabalho do aluno .......................................... 78 Figura 4.4 - Organização das ferramentas do PROOGRAMA em módulos .......................... 79 Figura 4.5 - Visualização de um compromisso ..................................................................... 82 Figura 4.6 – Entrega da resposta de uma atividade por um aluno integrante de um grupo ..... 89 Figura 5.1 – Opções de configuração de monitoramento da ferramenta Agenda de compromissos............................................................................................................... 93 Figura 5.2 – Local para especificação do prazo de notificação de um compromisso ............. 95 Figura 5.3 - Opções de configuração de monitoramento da ferramenta Atividades ............... 96 Figura 5.4 – Arquitetura interna do agente AMIGO ............................................................. 97 Figura 5.5 - Diagrama de Casos de Uso do AMIGO ............................................................. 99 Figura 5.6 - Diagrama de Atividades do requisito Monitorar compromissos ....................... 100 Figura 5.7 - Diagrama de Atividades do requisito Comunicar resultado do monitoramento de compromisso .............................................................................................................. 100 Figura 6.1 - Fluxo de execução das atividades da fase Visão .............................................. 104 Figura 6.2 - Fluxo de execução das atividades da Etapa 1 da fase Planejamento................. 109 Figura 6.3 - Diagrama de Pacotes do ambiente PROOGRAMA ......................................... 111 Figura 6.4 - Diagrama de Casos de Uso da ferramenta Agenda de compromissos ............... 112 Figura 6.5 - Arquitetura preliminar do ambiente PROOGRAMA ....................................... 113 Figura 6.6 - Arquitetura interna preliminar do agente AMIGO ........................................... 113 Figura 6.7- Exemplo de interface prototipada em forma de imagem ................................... 115 Figura 6.8 - Arquitetura do ambiente PROOGRAMA: visão simplificada dos componentes ................................................................................................................................... 118 Figura 6.9 - Artefatos a serem produzidos pelo projeto....................................................... 119

Figura 6.10 - Diagrama de atividades do requisito Incluir compromisso ............................. 120 Figura 6.11 – Fluxo de execução das atividades da Etapa 2 da fase Planejamento .............. 121 Figura 6.12 - Diagrama de classes conceituais do ambiente ................................................ 122 Figura 6.13 - Tabelas do banco de dados do ambiente ........................................................ 123 Figura 6.14 - Fluxo de execução das atividades da fase Desenvolvimento........................... 125 Figura 6.15 - Atividade realizada durante a fase Estabilização ........................................... 127 Figura 6.16 - Fluxo de execução das atividades da fase Implantação .................................. 128 Figura 7.1 - Arquitetura de integração proposta .................................................................. 136

LISTA DE QUADROS

Quadro 2.I - Principais características dos ambientes estudados ........................................... 43 Quadro 4.I - Relação das funcionalidades para criação da infra-estrutura do ambiente.......... 75 Quadro 4.II - Relação das funcionalidades disponibilizadas na tela de acesso ao ambiente ... 77 Quadro 4.III - Funcionalidades das ferramentas do módulo Informações dos Alunos ............ 80 Quadro 4.IV - Funcionalidades das ferramentas do módulo Comunicação Pública .............. 84 Quadro 4.V - Funcionalidades das ferramentas do módulo Comunicação Direta.................. 86 Quadro 4.VI - Funcionalidades das ferramentas do módulo Material do Curso .................... 90 Quadro 4.VII - Funcionalidades da ferramenta AMBAP ...................................................... 91 Quadro 6.I – Exemplos de requisitos não-funcionais especificados .................................... 110 Quadro 6.II – Comparação entre as características oferecidas pelos ambientes e o PROOGRAMA .......................................................................................................... 114 Quadro 6.III – Principais resultados da reunião de fechamento desta etapa do projeto ........ 129

LISTA DE SIGLAS

AMBAP AmCorA AMIGO API ASD BD CC CGIs CNPq CTXML EAD ES FAQ FTP GAIA

AMBiente de Aprendizado de Programação Ambiente Cooperativo de Aprendizagem Agente para MonItorar e Gerenciar infOrmações Application Programming Interface Agile Software Development Banco de Dados Ciência da Computação Common Gateway Interfaces Conselho Nacional de Desenvolvimento Científico e Tecnológico Centro de Tecnologia XML Microsoft/PUCRS Ensino a Distância Engenharia de Software Frequently Asked Questions File Transfer Protocol Grupo de Aplicação da Informática na Aprendizagem / Grupo de Aplicação da Inteligência Artificial

GIE/FACIN HTML HTTP HTTPS IA IAD

Grupo de Informática na Educação da Faculdade de Informática HyperText Markup Language HyperText Transfer Protocol HyperText Transfer Protocol Security Inteligência Artificial Inteligência Artificial Distribuída

IC IE IHMC ILA IRC IIS J2EE™ J2SE™ JSP JVM LN MCs Moonline MSF® ODBC PDS PEP POP PUC-Rio PUCRS RMI RUP® SA SGBD SMAs SMTP SQL

Iniciação Científica Informática na Educação Institute for Human and Machine Cognition Interpretador de Linguagem Algorítmica Internet Relay Chat Internet Information Server Java™ 2 Platform Enterprise Edition Java™ 2 Platform Standard Edition Java Server Pages Java Virtual Machine Lotus Notes Mapas Conceituais Monitoria On-Line Microsoft Solutions Framework® Open-DataBase-Connectivity Processo de Desenvolvimento de Software Plano de Estudo e Pesquisa Post Office Protocol Pontifícia Universidade Católica do Rio de Janeiro Pontifícia Universidade Católica do Rio Grande do Sul Remote Method Invocation Rational Unified Process® Seminário de Andamento Sistema de Gerenciamento de Banco de Dados Sistemas Multiagentes Simple Mail Transfer Protocol Structured Query Language

TCP/IP TI-II UFES UML URLs WebCT WWW XML XP

Transfer Control Protocol / Internet Protocol Trabalho Individual II Universidade Federal do Espírito Santo Unified Modeling Language Uniform Resource Locations Web Course Tools World Wide Web eXtensible Markup Language Extreme Programming

SUMÁRIO

1

INTRODUÇÃO .......................................................................................................... 16 1.1 1.2 1.3 Problema e motivação .......................................................................................... 17 Questão de pesquisa e objetivos ............................................................................ 18 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 ENSINOAPRENDIZAGEM ............................................................................................................. 67 4 O AMBIENTE PROOGRAMA .................................................................................. 73 4.1 4.2 4.3 4.4 4.5 5 Módulo Informações dos Alunos........................................................................... 79 Módulo Comunicação Pública ............................................................................. 81 Módulo Comunicação Direta ............................................................................... 85 Módulo Material do Curso ................................................................................... 87 Módulo Teste de Algoritmos ................................................................................. 91

O AGENTE AMIGO .................................................................................................. 92 5.1 As funcionalidades do agente ............................................................................... 92

5.2

A modelagem e funcionamento do agente ............................................................. 97

6 O PROCESSO DE DESENVOLVIMENTO DO AMBIENTE PROOGRAMA E DO AGENTE AMIGO ............................................................................................................ 102 6.1 6.2 6.3 6.4 6.5 7 Visão (Envisioning) ............................................................................................ 103 Planejamento (Planning) .................................................................................... 109 Desenvolvimento (Developing) .......................................................................... 124 Estabilização (Stabilizing) .................................................................................. 127 Implantação (Deploying) .................................................................................... 128

CONSIDERAÇÕES FINAIS .................................................................................... 130 7.1 7.2 7.3 Contribuições ..................................................................................................... 131 Limitações e restrições ....................................................................................... 133 Trabalhos futuros................................................................................................ 135

REFERÊNCIAS BIBLIOGRÁFICAS............................................................................... 138 APÊNDICE A – Manual do usuário: Professor ................................................................. 150 APÊNDICE B – Visão e Escopo do Projeto PROOGRAMA ............................................ 185 APÊNDICE C – Estrutura e Plano do Projeto PROOGRAMA .......................................... 199 APÊNDICE D – Especificação Funcional do Projeto PROOGRAMA............................... 217 APÊNDICE E – Especificação da Interface Gráfica do Projeto PROOGRAMA................ 263 APÊNDICE F – Inconsistências identificadas nos protótipos ............................................ 284 APÊNDICE G – Guia de configuração do ambiente PROOGRAMA ................................ 287 APÊNDICE H – Publicações do Projeto PROOGRAMA .................................................. 290

16

1 INTRODUÇÃO

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

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

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

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

17

envolvimento com as tarefas complementares extraclasse (trabalhos e exercícios). Geralmente a reprovação está ligada diretamente ao fato dos alunos não se envolverem nas tarefas necessárias para o bom entendimento e fixação dos conteúdos destas disciplinas.

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

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

Pela necessidade de ter um ambiente centralizador dos recursos computacionais usados e que lhe provesse os mecanismos de gerência desejados, a professora orientadora

18

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

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

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

1.2 Questão de pesquisa e objetivos
Para solucionar o problema descrito, definiu-se o objetivo principal desta dissertação, de definir e apresentar o protótipo de um agente para monitorar e gerenciar informações referentes aos compromissos e às atividades de uma disciplina que utiliza o ambiente PROOGRAMA como recurso de apoio às atividades do processo de ensino-aprendizagem.

19

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

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

Especificar os requisitos e funcionalidades do agente;

Especificar as mensagens que o agente deverá enviar ao aluno e ao professor em função da proposta pedagógica do ambiente;

Definir o ambiente de atuação do agente;

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

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

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

Contribuir com o Projeto PROOGRAMA, propondo a arquitetura, as ferramentas e funcionalidades que irão compô-lo futuramente.

1

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

20

1.3 Estrutura do texto
Neste trabalho está descrito todo o processo de pesquisa, desde o levantamento do referencial teórico e estudo dos trabalhos correlatos até a finalização do desenvolvimento dos protótipos do ambiente PROOGRAMA e do agente AMIGO, dividido em sete capítulos, organizados logicamente facilitando a compreensão da pesquisa como um todo.

No Capítulo 2 fornece-se subsídios para a compreensão dos conceitos que serviram de aporte para o desenvolvimento desta pesquisa. Na primeira seção apresenta-se alguns aspectos gerais sobre ambientes virtuais de ensino-aprendizagem e os trabalhos correlatos estudados: AmCorA (Ambiente Cooperativo de Aprendizagem) [MEN99], AulaNet [FUK00], LearningSpace [LOT99] e WebCT [WEB00], encerrando com uma breve análise comparativa entre as principais características destes ambientes. Na próxima seção, discorre-se sobre o processo de desenvolvimento de um software e apresenta-se o framework para

desenvolvimento de projetos de tecnologia proposto pela Microsoft, o Microsoft Solutions Framework® (MSF®), adotado como referência para o desenvolvimento do ambiente e do agente. Também se destaca algumas questões relevantes em relação ao desenvolvimento de softwares educacionais. Na terceira seção define-se o conceito de agente de software e descreve-se suas principais características. Na última seção deste capítulo apresenta-se as características dos recursos tecnológicos adotados para a implementação dos protótipos do ambiente e do agente.

A metodologia utilizada para suporte ao processo de ensino-aprendizagem que foi usada como referência para a modelagem e definição do ambiente e do agente é apresentada no Capítulo 3.

No Capítulo 4 apresenta-se o ambiente proposto, descrevendo-se as características gerais, os perfis de usuário e as ferramentas e funcionalidades do mesmo. Cada uma das cinco seções do capítulo apresenta um conjunto de ferramentas, as quais foram conceitualmente agrupadas de acordo com seus objetivos e finalidades.

21

No Capítulo 5 apresenta-se o agente AMIGO, que constitui a proposta em si deste trabalho. Na primeira seção descreve-se as funcionalidades oferecidas pelo agente e na segunda, os aspectos relacionados à sua modelagem e implementação.

O processo de desenvolvimento do ambiente e do agente é descrito no Capítulo 6. Em cada uma das cinco seções do capítulo descreve-se as atividades relacionadas à respectiva fase de projeto, as quais seguiram as sugestões propostas pelo MSF®. Também são descritas as decisões de projeto tomadas e suas justificativas.

No Capítulo 7 estão as considerações finais relativas a este trabalho. Também são apresentadas as limitações e restrições identificadas, bem como os trabalhos futuros que podem vir a ser desenvolvidos para dar continuidade a esta pesquisa.

Ao final deste volume estão listadas as referências bibliográficas utilizadas nesta dissertação e, na seqüência, o conjunto de apêndices que organizam detalhadamente as especificações do projeto e os resultados obtidos.

22

2 APORTE TEÓRICO E TECNOLÓGICO

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

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

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

Sites educacionais, que reúnem um conjunto de funcionalidades, tais como biblioteca de software educacional, espaços para comunicação, software para download, links para outras páginas Web e jornais. Como exemplo, pode-se citar os sites Study Web [STU03], Kidlink-Br [KID03] e Escolanet [ESC03];

23

Sistemas de autoria para cursos a distância, os quais permitem a criação de recursos utilizando a Internet como ferramenta de autoria, como exemplo tem-se o LearningSpace [LOT99] e o WebCT [WEB00];

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

Frameworks

para de

aprendizagens ambientes

cooperativas,

que

permitem

o

desenvolvimento

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 ensinoaprendizagem [MAC99].

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

Neste contexto, estudou-se quatro ambientes, AmCorA, AulaNet, LearningSpace e WebCT, com o objetivo de identificar suas características e as formas de monitoramento e

24

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

2.1.1

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

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

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

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

2

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

25

Coordenador: gerencia os participantes de um determinado grupo, e organiza e mantém o conteúdo e atividades deste mesmo grupo;

Membro: usufrui os recursos do sistema, sendo considerado “aluno” das atividades dos grupos.

Os usuários ainda podem assumir o papel denominado Anônimo, o qual solicita a criação de um grupo ou a participação em um grupo já existente. No caso de solicitar a criação de um grupo, este usuário também é denominado Fundador do grupo. Em geral, o Fundador é o primeiro Coordenador do grupo.

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

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

26

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

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

Identificação Pessoal: disponibiliza as informações do usuário, como, por exemplo, nome, e-mail, áreas de interesse, entre outras. Estas informações só serão divulgadas caso sejam editadas pelo usuário.

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

Estante: permite a criação de um repositório de arquivos particulares. É possível criar pastas para organizar os arquivos.

Escaninho: possibilita acesso aos documentos enviados ou compartilhados por outros usuários.

27

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

Leitor de E-mails: utilizada para verificar e enviar e-mails. Pode-se configurar qualquer endereço de e-mail, desde que o servidor provenha o serviço POP3. Ou seja, que dê suporte ao Post Office Protocol (POP).

BigBrother: é o serviço de mensagens instantâneas, no qual o usuário pode visualizar quem está conectado, enviar e ler estas mensagens. Para saber que existe uma nova mensagem, existe um mecanismo (aparecimento de um mensagem que aparece e desaparece de tempo em tempos) disponível no canto superior do menu, o qual indica que há uma nova mensagem.

Meus Grupos: permite ao usuário navegar entre os grupos ao qual está cadastrado, acessando o menu de opções do grupo selecionado. Caso o usuário seja o Coordenador do grupo, este também pode criar ou excluir subgrupos.

Configurador: permite a configuração dos itens que serão exibidos no menu. É possível incluir, excluir ou mudar a ordem das opções escolhidas.

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

A área Sala do Grupo provê algumas funcionalidades semelhantes às da área Sala Individual, quais sejam: (i) Perfil do Grupo, onde somente o coordenador do grupo possui permissão para editar este perfil; (ii) Webliografia; (iii) Estante, repositório de arquivos do

28

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

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

Participantes: é a área de trabalho do coordenador do grupo. Nesta área, ele pode gerenciar os participantes e os subgrupos do seu grupo, ativando-os ou suspendendo-os e até mesmo promovê-los a coordenadores dos subgrupos.

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

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

Fórum: possibilita a discussão de temas específicos, de maneira a encadear mensagens em forma de árvore.

Chat: disponibiliza salas de bate-papo para os participantes de um grupo conversarem síncronamente (Segundo [NET03], o registro destas conversas esta sendo armazenado no servidor da aplicação, mas ainda não pode ser salvo pelos usuários).

29

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

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

2.1.2

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

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

Estudou-se a versão 2.0. Maiores informações em http://www.les.inf.puc-rio.br/groupware.

Segundo [FUK02], groupware pode ser entendido como a tecnologia baseada em mídia digital que dá suporte às atividades de pessoas organizadas em grupos que podem variar em tamanho, composição e local de trabalho.

30

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

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

Coordenador: responsável por estruturar o curso, selecionando e configurando quais serviços serão disponibilizados, definindo a ementa, a metodologia e outras informações relacionadas ao curso;

Docente co-autor: responsável por produzir e inserir os conteúdos didáticos nos serviços selecionados pelo coordenador;

Instrutor (ou Mediador): é o facilitador do grupo, responsável por manter a ordem, motivar e avaliar os aprendizes.

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

Administrador: facilita a integração docente/curso/aprendiz e lida com as questões de natureza predominantemente operacionais, como a matrícula de alunos e outras tarefas de secretaria;

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

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

31

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

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

Os serviços de comunicação fornecem as facilidades que permitem a troca e o envio de informações entre docentes e alunos. Segundo [AUL02; FUK00; FUK01], os serviços oferecidos são os seguintes:

Mensagem ao docente: é um canal para contatar os docentes do curso. As mensagens são enviadas através do correio eletrônico interno do ambiente para os instrutores ou coordenadores, dependendo da escolha do autor.

Mensagem para participantes: permite que os participantes vejam a lista de membros da turma, saibam quem está conectado e participando do curso naquele momento, e troquem mensagens entre si. As mensagens podem ser enviadas por correio eletrônico (somente aos participantes do curso) ou por mensagens instantâneas.

32

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

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

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

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

Avisos: é o serviço de notificação do AulaNet, que possibilita a criação de avisos sobre o curso ou agendamento de eventos através de informes que ficam

33

disponíveis para consulta. Geralmente é usado para orientar os aprendizes com relação aos eventos do curso.

Plano de aulas: é utilizado pelo docente para estruturar os conteúdos didáticos do curso, separando-os em aulas, que seguem uma ordem sugerida, mas não imposta para que o aprendiz acompanhe o curso.

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

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

Relatórios de participação: facilitam o acompanhamento, por parte do docente, da participação e da qualidade das contribuições feitas pelos aprendizes nos diversos eventos do curso.

Quanto aos serviços de cooperação, estes fornecem os meios para a aprendizagem cooperativa, a realização de atividades e a resolução de problemas. Segundo [AUL02; FUK00], os serviços oferecidos são:

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

Documentação: permite a disposição de conteúdos ligados ao curso como um todo, não ligados diretamente a uma determinada aula do plano de aulas.

34

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

Co-autoria de docente e Co-autoria de aprendiz: permitem que o docente convide outros docentes ou aprendizes para compartilharem de sua área de trabalho a fim de juntos construírem o material a ser disponibilizado.

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

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

2.1.3

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

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

Segundo [BAC00], o LN é baseado numa arquitetura cliente/servidor, onde usuários do servidor, conhecido como Domino, podem fazer acesso às bases de dados lá depositadas através de estações cliente ou ainda através de um navegador Web. Este sistema de gerência

5

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

35

de informações dá suporte ao LearningSpace na geração de cursos pelos usuários, bem como na distribuição e manutenção de informações. As características mencionadas nesta seção dizem respeito à versão acessível através de um navegador Web.

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

Estudantes: podem acessar somente as atividades e funcionalidades relacionadas aos cursos que estão inscritos, bem como disponibilizar aos demais informações sobre seus perfis;

Administradores: possuem acesso a funcionalidades específicas de acordo com as diferentes funções que podem assumir - administrador do sistema, gerente do curso, autor de materiais ou instrutor.

Independente do papel que um usuário possua, para acessar o ambiente do LearningSpace através da Web terá que especificar a URL de acesso e fornecer os dados solicitados na página de logon apresentada (nome do usuário e senha).

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

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

36

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

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

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

37

a característica de permitir a gravação de uma sessão de discussão síncrona, proporcionando ao aluno ou instrutor a opção de reproduzi-la novamente conforme julgue necessário.

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

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

Segundo [WOR02], uma das grandes vantagens do LearningSpace é a flexibilidade de permitir aos instrutores a atualização ou acréscimo do material utilizado no curso. Para tal, basta o instrutor estabelecer um documento de atualizações para que a cada vez que o estudante entre no curso ele possa identificar facilmente as novidades.

38

2.1.4

WebCT O WebCT6 foi desenvolvido originalmente pela University of British Columbia,

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

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

Administrador: há apenas um administrador. Cabe a este iniciar um curso e abrir um curso vazio para um projetista, cancelar cursos e controlar as senhas dos usuários;

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

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

Alunos: não há limite quanto ao número de alunos em um curso, nem quantos cursos estes se matriculam. Possuem acesso somente ao material instrucional, às ferramentas de comunicação e à área de apresentação dos trabalhos. Caso seja necessário para atender sua metodologia de ensino, o professor pode organizar os alunos em diversos grupos, conforme critérios a serem definidos pelo próprio professor [KIS02].

6

Estudou-se a versão 3.0. Maiores informações podem ser obtidas na home page do produto: http://www.webct.com.

39

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

Figura 2.5 - Ferramentas do ambiente WebCT [BAC00]

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

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

Quadro de avisos: permite a comunicação entre os participantes do curso, seja através de discussões e questões relacionadas ao curso ou da divulgação de avisos. Apresenta sempre o aviso mais recente no topo da lista.

Material instrucional: disponibilizado através de links para textos, imagens ou qualquer outro material a ser oferecido para download durante a realização do curso. Este material deve ser criado fora do ambiente e importado para o mesmo. O

40

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

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

Fórum: discussão de assuntos, de forma assíncrona, propostos pelo professor. As mensagens podem ser disponibilizadas para um grupo específico ou para todos os participantes. Ou seja, podem ser públicas ou privadas. O ambiente oferece um mecanismo de controle para o aluno saber se existe alguma mensagem não lida: é apresentada uma imagem ao lado das novas mensagens.

Correio eletrônico: só é permitido o envio de mensagens para endereços de usuários matriculados no curso.

Quadro-branco: possibilita a criação de documentos gráficos de forma cooperativa e síncrona. Assim, qualquer usuário que estiver conectado no momento pode editar a imagem que está sendo desenvolvida em conjunto.

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

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

41

com uma série de formatos de questões pré-definidas (relacionar colunas, múltiplaescolha, cálculo, resposta curta e parágrafo).

Expositor de notas: local onde são disponibilizadas as notas e médias obtidas pelos alunos no decorrer do curso. Cada nota está relacionada a uma tarefa realizada (e enviada ao professor pelo sistema) e/ou teste.

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

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

2.1.5

Uma breve análise comparativa dos ambientes Após o estudo dos ambientes apresentados, percebeu-se que ambos diferenciam-se

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

42

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

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

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

43

respectivamente, a presença ou a ausência de uma característica. Àquelas características que não dizem respeito a um determinado ambiente, apresenta-se “N/A” (Não se aplica) e para aquelas que não se conseguiu identificar sua presença no ambiente, tem-se o caractere “?”.

Quadro 2.I - Principais características dos ambientes estudados
CARACTERÍSTICAS Administrador Professor Instrutor/Monitor Aluno Controle de acesso e diferentes visões conforme o perfil Ajuda/Help on-line Glossário de termos Mensagens instantâneas Sala para bate-papo (chat) Registro das salas de bate-papo E-mail interno ao curso Envio de e-mail a usuários externos ao curso Recebimento de e-mail de usuários externos ao curso Lista/Fórum de discussão Publicação de avisos Agenda/Cronograma de atividades Dados sobre os participantes Elaboração de plano de aula Publicação de material de apoio Envio de tarefas aos alunos Identificação de novas tarefas a serem corrigidas Manutenção de notas Geração de relatórios de participação Agendamento de compromissos Download de material Entrega de material por upload Consulta a resultados de tarefas Atribuição de status a uma tarefa Esclarecimento de dúvidas on-line
Assínc. Síncr.

AMCORA Sim Sim Não Sim Sim Sim Não Sim Sim Não Não Sim Sim Sim Sim Não Sim N/A Sim N/A N/A N/A Não Sim Sim Sim N/A N/A Sim

AULANET Sim Sim Sim Sim Sim Sim Não Sim Sim Sim Sim Não Não Sim Sim Sim Não Sim Sim Sim Não Sim Sim Não Sim Sim Sim Não Não

LEARNINGSPACE Sim Sim Sim Sim Sim Não Não Não Sim Sim Sim Sim Não Sim Não Sim Sim Sim Sim ? Não Sim ? Não Sim Sim Sim Sim Não

WEBCT Sim Sim Sim Sim Sim ? Sim Não Sim Sim Sim Não Não Sim Sim Sim Sim Sim Sim ? Não Sim Sim Sim Sim Sim Sim Não Não

Características gerais

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.

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

Ferramentas de apoio ao aluno

Ferramentas de apoio ao professor

Ferramentas de comunicação

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

Os ambientes variam bastante as ferramentas e as funcionalidades que disponibilizam

Usuário

44

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

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

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

No que concerne as ferramentas de apoio ao aluno, uma das principais características diz respeito ao calendário de atividades e compromissos. Somente os ambientes AmCorA e WebCT permitem que os alunos organizem o seu calendário e agendem compromissos tanto individuais como para toda a turma. Em relação às solicitações de pedidos de ajuda e

45

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

O estudo destes ambientes permitiu-nos identificar uma série de características que foram observadas e consideradas na elaboração e desenvolvimento do ambiente PROOGRAMA e do agente AMIGO.

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

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

46

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

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

O XP surgiu em 1996, a partir da carência identificada por Kent Beck, funcionário da DaimlerChrysler8, de processos de desenvolvimento de software que facilitassem a criação de software em geral. Baseado nesta necessidade, Beck especificou o XP, o qual visa um objetivo principal: entregar o software que o cliente desejar quando este assim o desejar. Para

7

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

Multinacional da área de transporte e serviços automotivos.

47

tal, é dado ênfase em quatro aspectos considerados fundamentais: comunicação, simplicidade, feedback e coragem [XTP02]. Além disto, segundo [PRI02], o trabalho em equipe também é enfatizado, no qual gerentes, clientes e desenvolvedores devem formar uma equipe única e comprometida a entregar um software com qualidade. O XP é composto por quatro fases, quais sejam: Planejamento (Planning), Projeto (Designing), Codificação (Coding) e Teste (Testing), sendo que a mudança de um requisito pode acorrer a qualquer momento. Segundo [XTP02], tem-se esta visão por se acreditar que o cliente nem sempre tem uma idéia concreta do que o sistema deve fazer, sendo permitido ao mesmo alterar indefinidamente as especificações. Diferentemente dos anteriores, o RUP® é um framework para PDS, que propõe um conjunto de atividades e artefatos relacionados às quatro fases de projeto definidas. Estas fases são denominadas Concepção (Inception), Elaboração (Elaboration), Construção (Construction) e Transição (Transition) [POL01]. O processo pode ser instanciado para diferentes projetos, através da combinação das atividades e artefatos propostos, de acordo com as características e porte do mesmo. Em essência, o RUP® define o processo de desenvolvimento de forma interativa e incremental, orientada a objetos, com foco na criação de uma arquitetura robusta e análise dos riscos para o projeto [POL01; PRI02]. Apesar de encontrar-se na literatura uma boa documentação discutindo as fases, os papéis dos integrantes da equipe de desenvolvimento, as atividades e mencionando os artefatos estipulados, estes últimos não estão disponíveis de forma gratuita. Isto dificulta o estudo e análise daqueles que não possuem acesso ao templates dos documentos adotados durante o processo de desenvolvimento. Por ter sido o modelo de PDS adotado, o MSF® será descrito mais detalhadamente em uma seção específica.

2.2.1

Microsoft Solutions Framework® O MSF® é um framework para projetos de tecnologia proposto pela Microsoft.

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

48

técnicas às atividades do projeto, buscando atender as especificações do mesmo; a de Gerência de riscos trata o gerenciamento de riscos, os quais são inerentes a qualquer tipo de projeto; e a de Aprendizagem propõe uma forma de identificar conhecimentos e habilidades a serem usufruídas nos projetos.

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

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

Na fase de Planejamento é preparada a especificação funcional do software, baseada nos requisitos identificados, e modelada a solução. Segundo [MIC02b], os requisitos podem

9

Do original em Inglês, Configuration Management.

49

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

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

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

50

2.2.2

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

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

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

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

Em sua dissertação, [NET03] destaca a importância da prototipação da interface gráfica, a qual constituiu uma das etapas do desenvolvimento da nova versão do ambiente

51

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

2.3 Agentes de software
Por ser uma área de pesquisa relativamente recente, a Inteligência Artificial Distribuída (IAD), cujo objeto de estudo está baseado na inteligência advinda do comportamento social caracterizado pela interação de agentes [SIC92], ainda não apresenta uma definição única do conceito de agentes que seja aceita por todos os pesquisadores da área [ALV97; SIL01]. Desta forma, encontra-se na literatura diversos conceitos para o termo agente. Pode-se citar como exemplo as seguintes definições:
Um agente é uma entidade real ou virtual, imersa em um ambiente sobre o qual ela é capaz de agir, que dispõe de uma capacidade de percepção e de representação parcial deste ambiente, que pode se comunicar com outros agentes e que possui um comportamento autônomo, conseqüência de suas observações, de seu conhecimento e das suas interações com os outros agentes [FER91]. Um agente é uma entidade à qual nós podemos associar uma identidade única, e que é capaz de executar um processamento de cálculo. Um agente pode ser considerado como um meio que produz um certo numero de ações, a partir de seu conhecimento e dos mecanismos internos que lhe são próprios [GAS92]. Um agente é uma entidade que percebe seu ambiente através de sensores, e age sobre o mesmo utilizando-se dos executores [RUS95]. Um agente é um sistema de computador que está situado em algum ambiente e que é capaz de executar ações autônomas de forma flexível neste ambiente, a fim de satisfazer seus objetivos de projeto [WOO99].

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

52

[GEN94], em que praticamente qualquer processo comunicante passou a ser denominado agente. Por fins de praticidade, neste trabalho, usar-se-á apenas o termo agente.

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

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

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

Figura 2.6 - Arquitetura de um agente reativo [RUS95]

53

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

Não há representação explícita de conhecimento: o conhecimento dos agentes é implícito (no código) e se manifesta através do seu comportamento;

Não há representação do ambiente: o seu comportamento se baseia no que é percebido a cada instante do ambiente, mas sem uma representação explícita deste;

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

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

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

54

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

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

A comunicação entre os agentes do ambiente é feita de modo direto, através do envio e recebimento de mensagens;

O mecanismo de controle entre os agentes do ambiente é deliberativo, ou seja, os agentes raciocinam e decidem sobre quais objetivos devem alcançar, que planos seguir e quais ações devem ser executadas em um determinado momento.

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

Figura 2.7 - Arquitetura de um agente cognitivo [RUS95]

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

55

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

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

2.4 Recursos tecnológicos
Levando-se em consideração o contexto desta pesquisa, a qual tem como objetivo apresentar um mecanismo de monitoramento e gerenciamento de informações geradas através do uso de um ambiente virtual (disponível na Web) de apoio ao processo de ensinoaprendizagem, 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ódigosfonte), um dos critérios para a seleção da linguagem de programação foi a isenção de custo para o desenvolvimento (ferramentas) e utilização. Outro critério levado em consideração foi

56

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

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

2.4.1

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

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

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

57

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

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

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

É uma linguagem tipada;

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

Possui mecanismos de tratamento de exceções, o qual evita que as aplicações parem seu funcionamento em condições anormais;

Possui um mecanismo, denominado garbage collector, de gerência dos objetos, o qual controla a memória e descarta aqueles objetos que não mais necessários ao funcionamento do programa;

Fornece suporte à programação multi-thread, isto é, permite a criação de várias linhas (threads) de execução simultaneamente;

58

Oferece suporte à programação de sistemas distribuídos, através dos recursos de programação com sockets, RMI (Remote Method Invocation), TCP/IP (Transfer Control Protocol/Internet Protocol), BD, entre outros.

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

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

Java

Applet

HTML Dinâmico

JSP

Camada cliente

Servlets

Enterprise Beans Camada de negócios

Banco de dados Camada de informações Figura 2.8 - Camadas (ou níveis) da plataforma J2EE™ ™

59

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

Ainda segundo [COP03], normalmente, os componentes da camada de interface executam na máquina cliente, exceto o JSP; a camada de negócios executa na máquina que está servindo a plataforma J2EE™; e a camada de informações, na máquina servidora de BD. Pode ocorrer destas camadas estarem concentradas em uma única máquina.

2.4.2

Servlets Servlet é uma das mais importantes tecnologias Java e a base para o desenvolvimento

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

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

Modularização do código: Um servlet pode executar outro servlet, mesmo que remotamente. Desta forma, é possível executá-los em corrente. Esta característica

11 12

http://www.sun.com

As chamadas páginas dinâmicas consistem em porções de código (scripts) inseridos em páginas HTML e processados pelo servidor Web antes de serem enviadas para os usuários [LIC03]

60

possibilita modularização dos aplicativos, criando servlets com funções bastante específicas;

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

Independência de servidor e plataforma: Por serem implementados em Java, os servlets herdam todas as características desta linguagem, entre elas, a portabilidade.

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

Toda classe servlet deve implementar a interface Servlet, utilizando-se dos pacotes
javax.servlet

e javax.servlet.http [KUR02]. Nesta interface estão definidos todos os

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

61

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

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

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

import javax.servlet.*; import javax.servlet.http.*; import java.io.*; public class MeuHelloWorldExample extends HttpServlet { public void doGet (HttpServletRequest request, HttpServletResponse response) throws IOException, servletException { response.setContentType(“text/html”); PrintWriter out = response.getWriter(); out.println(“<HTML>”); out.println(“<HEAD>”); out.println(“<TITLE> PAGINA TESTE </TITLE>”); out.println(“</HEAD>”); out.println(“<BODY>”); out.println(“<H1> Hello World! </H1>”); out.println(“</BODY>”); out.println(“</HTML>”); out.close(); } }

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

62

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

2.4.3

Java Server Pages De acordo com a própria Sun [SUN03c], “JSP é uma extensão da tecnologia servlet,

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

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

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

63

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

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

2.4.4

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

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

13

Do original em Inglês, Container.

64

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

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

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

Jasper: é um servlet padrão que fornece o suporte à execução de páginas JSP, gerando e compilando o servlet correspondente a cada página;

Coyote: é o conector responsável por tornar o Tomcat um servidor Web, podendo ser configurado para suportar outros recursos de um servidor padrão deste tipo, como, por exemplo, a execução de programas CGI.

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

2.4.5

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

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

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

65

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

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

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

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

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

66

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

67

3 A METODOLOGIA UTILIZADA PARA SUPORTE AO PROCESSO DE ENSINO-APRENDIZAGEM

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

68

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

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

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

E-mail: utilizado para envio e recebimento de tarefas complementares, esclarecimento de dúvidas e comunicação privada do professor com seus alunos e vice-versa;

Lista de discussão: criada para complementar o trabalho desenvolvido nos encontros síncronos e servir de espaço para as contribuições dos alunos, e envio de informações do professor para o grupo e entre seus participantes.

A metodologia utilizada na condução das disciplinas baseia-se na resolução de problemas organizados em ordem crescente de complexidade. Toda a questão da leitura da teoria referente aos conteúdos fica por conta do aluno. Em geral, quando estes possuem

69

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

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

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

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

70

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

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

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

71

Apresentação de um cronograma geral de atividades para todo o semestre. Para o aluno ter idéia do volume de trabalho (leituras, exercícios, pesquisas, tarefas práticas, etc.) a ser realizado;

Disponibilização dos materiais de forma antecipada (no mínimo duas aulas à frente);

Disponibilização das notas das avaliações através do site da Universidade como fonte de consulta principal15, sendo que a divulgação ocorre complementarmente em sala de aula ou nos expositores disponibilizados nos corredores das dependências da Universidade;

Adequação da tecnologia associada aos recursos para encontros síncronos e assíncronos. Algumas delas foram se mostrando inadequadas ou obsoletas. Outras tiveram problemas com os provedores privados utilizados pelos alunos fora da universidade que este projeto está vinculado (PUCRS);

Participação do monitor nas atividades da disciplina como se fosse um dos alunos da turma. Isto permite que ele vivencie as experiências dos alunos e tenha acesso às listas de discussões.

Pode-se ressaltar como aspectos positivos desta metodologia o envolvimento dos alunos nas atividades de aula presencial; a mudança de postura dos mesmos no que concerne o processo de busca e gestão das informações da disciplina; a melhoria das notas nas avaliações (que passaram a se constituir em pontos de verificação de etapas e não simplesmente encaradas como provas); e a participação dos alunos enviando materiais e soluções para serem compartilhadas com os colegas. Em contra-partida, pode-se considerar como aspecto negativo desta metodologia o enorme volume de informações que o professor e o aluno têm de gerenciar, como, por exemplo, a grande quantidade de e-mails e documentos que o professor precisa verificar diariamente. A demanda aumenta, em específico, em datas próximas a entrega de exercícios e trabalhos solicitados pela professora, uma vez que a mesma se coloca a disposição de discutir e avaliar versões intermediárias dos trabalhos e,
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.
15

72

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

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

73

4 O AMBIENTE PROOGRAMA

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

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

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

Aluno: é o público-alvo para o qual uma disciplina é organizada. Possui como responsabilidades consultar os materiais disponibilizados e responder as atividades solicitadas pelo professor, bem como participar das discussões propostas.

Administrador: existe apenas um administrador no ambiente. Este é o responsável por questões operacionais. Ou seja, tem como responsabilidade prover

74

a infra-estrutura para funcionamento do ambiente (criar acesso aos usuários, gerenciar suas contas, cadastrar os cursos, as disciplinas e as turmas solicitadas pelos professores, entre outros). Também é de sua responsabilidade manter o servidor do ambiente ativo para que este possa ser utilizado.

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

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

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

75

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

Quadro 4.I - Relação das funcionalidades para criação da infra-estrutura do ambiente FERRAMENTA/ FUNCIONALIDADE INFRA-ESTRUTURA Criar unidade acadêmica Editar unidade acadêmica Excluir unidade acadêmica Visualizar unidade acadêmica Criar curso Editar curso Excluir curso Visualizar curso Criar disciplina Editar disciplina Excluir disciplina Visualizar disciplina Criar turma Editar turma Excluir turma Visualizar turma Criar usuário Editar usuário Excluir usuário Visualizar usuário Formar inscritos turma Editar turma formada Excluir turma formada Visualizar turma formada Salvar registro andamento disciplina Excluir registro andamento disciplina x x x x x x x x x x x x x x x x x x x x x x x x x x x x PROFESSOR PERFIL DE USUÁRIO MONITOR ALUNO ADMIN.

76

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

Figura 4.2 - Tela de acesso ao ambiente PROOGRAMA

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

77

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

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

Quadro 4.II - Relação das funcionalidades disponibilizadas na tela de acesso ao ambiente FERRAMENTA/ FUNCIONALIDADE LOGIN Acessar o ambiente Lembrar senha GERAL Visualizar informações gerais sobre o ambiente Enviar e-mail para a coordenação do ambiente x x x x x x x x x x x x x x x PERFIL DE USUÁRIO PROFESSOR MONITOR ALUNO ADMIN.

A tela principal da área de trabalho de um usuário apresenta as ferramentas que este possui acesso, através dos links disponibilizados abaixo de cada figura ou sobre as mesmas,

78

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

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

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

17

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

79

AMBAP ILA Teste de Algoritmos

Glossário de termos Bibliografia Material do Curso

Material de apoio

Atividades

Plano de aulas AMIGO Agenda de comprom. Monitor. e Gerência de Informações Mural Informações pessoais Moonline Expositor de notas Comunicação Pública
Informações dos Alunos

E-mail

Chat

Fórum

Comunicação Direta

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

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

Conforme mencionado no Capítulo 3, a PUCRS possui um serviço de disponibilização das notas referentes às avaliações das disciplinas através do site da Universidade na Intranet. O ambiente disponibilizará um link para este endereço. Apesar do professor ter este serviço à sua disposição, opcionalmente este poderá divulgar as notas das avaliações através da

80

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

Quadro 4.III - Funcionalidades das ferramentas do módulo Informações dos Alunos FERRAMENTA/ FUNCIONALIDADE INFORMAÇÕES PESSOAIS Incluir informações pessoais Editar informações pessoais Excluir informações pessoais Pesquisar informações pessoais Visualizar informações pessoais EXPOSITOR DE NOTAS Acessar site de notas da PUCRS Especificar avaliação Editar avaliação Excluir avaliação Visualizar avaliação Registrar nota Editar nota Excluir nota Visualizar nota x x x x x x x x x x x x x x x x x x x x x x x x x x x PROFESSOR PERFIL DE USUÁRIO MONITOR ALUNO ADMIN.

81

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

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

82

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

Figura 4.5 - Visualização de um compromisso

83

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

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

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

84

Quadro 4.IV - Funcionalidades das ferramentas do módulo Comunicação Pública FERRAMENTA/ FUNCIONALIDADE PLANO DE AULAS Criar plano de aulas Editar plano de aulas Excluir plano de aulas Visualizar plano de aulas AGENDA DE COMPROMISSOS Incluir compromisso Editar compromisso Excluir compromisso Visualizar compromisso MURAL DE NOTÍCIAS Criar tema de notícia Editar tema de notícia Excluir tema de notícia Visualizar temas de notícia Incluir notícia Editar notícia Excluir notícia Visualizar notícia MOONLINE Incluir dúvida Excluir dúvida Responder dúvida Redirecionar dúvida ao professor Editar resposta dúvida Excluir resposta dúvida Visualizar dúvida FAQ Incluir pergunta Editar pergunta Excluir pergunta Responder pergunta Editar resposta pergunta Excluir resposta pergunta Visualizar pergunta Pesquisar pergunta x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x PERFIL DE USUÁRIO PROFESSOR MONITOR ALUNO ADMIN.

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 ensinoaprendizagem das disciplinas de Algoritmos e Lapro, oferecidas pela FACIN da PUCRS18, e visto que todos os alunos dos cursos desta Faculdade possuem uma conta de e-mail vinculada ao seu servidor de e-mails, definiu-se este servidor como o padrão para leitura (pop3.inf.pucrs.br) e envio (smtp.inf.pucrs.br) de e-mails. O usuário pode configurar qualquer outro servidor, desde que o mesmo tenha endereços para os protocolos POP e SMTP, de recebimento e envio de e-mails, respectivamente. É importante observar que as mensagens lidas através do ambiente não serão mantidas no servidor originário, mas porém serão armazenadas no ambiente, podendo ser acessadas sempre que desejado.

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

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

86

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

Quadro 4.V - Funcionalidades das ferramentas do módulo Comunicação Direta FERRAMENTA/ FUNCIONALIDADE E- MAIL Configurar conta de e-mail Ler e-mail recebido Apagar e-mail recebido Enviar novo e-mail Visualizar e-mail enviado Apagar e-mail enviado Incluir contato Editar contato Excluir contato Visualizar contato Pesquisar contato Criar assinatura Editar assinatura Excluir assinatura CHAT Criar sala de conversa Editar sala de conversa Excluir sala de conversa Utilizar sala de conversa Salvar texto da conversa FÓRUM DE DISCUSSÃO Definir assunto Disponibilizar fórum de discussão Encerrar fórum de discussão Enviar colocação Editar colocação Excluir colocação Visualizar colocações x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x PERFIL DE USUÁRIO PROFESSOR MONITOR ALUNO ADMIN.

87

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

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

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

88

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

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

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

89

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

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

90

Quadro 4.VI - Funcionalidades das ferramentas do módulo Material do Curso FERRAMENTA/ FUNCIONALIDADE GLOSSÁRIO DE TERMOS Solicitar definição de termo Editar solicitação de termo Excluir solicitação de termo Especificar definição do termo Editar definição do termo Excluir definição do termo Visualizar termo Pesquisar termo Imprimir definição de termo Salvar definição de termo BIBLIOGRAFIA Criar tipo de bibliografia Editar tipo de bibliografia Excluir tipo de bibliografia Incluir bibliografia Editar bibliografia Excluir bibliografia Visualizar bibliografia Pesquisar bibliografia Imprimir bibliografia Salvar bibliografia MATERIAL DE APOIO Incluir material de apoio Editar material de apoio Excluir material de apoio Visualizar material de apoio ATIVIDADES Incluir atividade Editar atividade Excluir atividade Visualizar atividade Encaminhar resposta atividade Atualizar resposta atividade Corrigir material por atividade Corrigir material por aluno Visualizar correção da resposta Configurar relatório Gerar relatório por estatística Gerar relatório detalhado x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x PERFIL DE USUÁRIO PROFESSOR MONITOR ALUNO ADMIN.

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 AMBAP Escrever algoritmo Editar algoritmo Salvar algoritmo Simular algoritmo Alterar parâmetros simulação Depurar algoritmo Traduzir algoritmo x x x x x x x x x x x x PERFIL DE USUÁRIO PROFESSOR MONITOR ALUNO ADMIN.

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

92

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

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

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

5.1 As funcionalidades do agente
As informações monitoradas pelo agente dizem respeito àquelas geradas através do uso das ferramentas Agenda de compromissos e Atividades do ambiente PROOGRAMA. Ou seja, são as informações referentes à realização de um compromisso agendado e/ou de uma

93

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

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

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

94

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

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

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

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

95

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

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

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

96

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

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

97

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

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

Configuração de monitoramento de ferramentas

Verificação de compromissos e atividades

Verificação de arquivos enviados

Geração de relatórios

Mensagens para os usuários

Figura 5.4 – Arquitetura interna do agente AMIGO

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

98

conforme mencionado anteriormente. Responsável pela notificação dos resultados dos monitoramentos, tem-se o módulo Mensagens para os usuários, e fornecendo os dados para a geração dos relatórios, tem-se o módulo Geração de relatórios.

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

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

99

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

Gerar relatorio Monitorar compromissos <<agent>> Amigo Professor
(from Use Case View)

Gerar relatorio detalhado

Monitorar material resposta atividade

Usuario
(from Use Case View)

Comunicar resultado do monitoramento de compromissos

Aluno
(from Use Case View)

Comunicar resultado do monitoramento do material

Figura 5.5 - Diagrama de Casos de Uso do AMIGO

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

100

expressam, em linhas gerais, o algoritmo de implementação das funcionalidades que estão detalhando. Os demais diagramas de Atividades do agente podem ser encontrados na Seção 2.2. do Apêndice D.
Professor AgenteAMIGO

Monitorar compromissos: Verifica, de tempos em tempos, a proximidade da data dos compromissos existentes na Agenda de Compromissos buscando notificar os respectivos usuarios associados a estes compromissos.

Solicitar monitoramento da Agenda de Compromissos

Analisar compromisso para verificar proximidade da data ( Periodo aviso )

[ dCompr-dAtual<=PeriodoAviso ]

[ dCompr-dAtual>PeriodoAviso ] <<use case>> Comunicar resultado do monitoramento de compromissos

Figura 5.6 - Diagrama de Atividades do requisito Monitorar compromissos

AgenteAMIGO

Usuario

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

( Dados compromisso ) Formatar texto comunicando a proximidade da atividade ( Texto formatado ) [Pelo ambiente] [Por e-mail]

Receber e-mail com o texto que foi preparado pelo e-mail

Receber e-mail com o texto que foi preparado pelo ambiente

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

101

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

Os sensores estão distribuídos nas diferentes classes que implementam as funcionalidades de troca de dados entre as páginas JSP (interface com o usuário) e os servlets (mecanismo para invocar e receber respostas do servidor) com as tabelas do BD. Estas classes foram denominadas APIs (Detalhes sobre a arquitetura e implementação do PROOGRAMA podem ser encontrados adiante, na Seção 6.2). Cada tabela do BD possui uma API correspondente. Para representar os sensores, foram definidas variáveis do tipo texto (String) que são enviadas à instância da classe AMIGO ao serem identificadas no código em execução. Por exemplo, quando o professor insere um compromisso em sua agenda, a função
inserir()

da

API

Compromisso

submete

ao

agente

do

professor

a

string

professorInsereCompromisso,

representando o sensor para esta situação. Ao executar uma

funcionalidade que possui um sensor associado, a instância correspondente do agente é ativada e executa a ação necessária para cumprir sua tarefa. Ou seja, o atuador correspondente do agente é colocado em ação no ambiente em que o agente está atuando.

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

102

6 O PROCESSO DE DESENVOLVIMENTO DO AMBIENTE PROOGRAMA E DO AGENTE AMIGO

Para orientar o processo de desenvolvimento do ambiente PROOGRAMA (e, conseqüentemente, do agente AMIGO), optou-se pelo framework proposto pela Microsoft, o MSF®. A escolha foi baseada no conhecimento prévio da equipe e na facilidade de acesso à documentação relacionada, uma vez que a descrição do modelo e os templates propostos para elaboração dos documentos de projeto estão disponíveis gratuitamente na Internet19. Outro motivo que nos levou a escolher o MSF® como referência foi o fato deste dar suporte ao desenvolvimento incremental de um software. O desenvolvimento do ambiente

PROOGRAMA possui esta característica, já que para fins de atingir-se o objetivo maior deste trabalho (o desenvolvimento do agente AMIGO) optou-se por implementar apenas parte do software especificado, tendo como resultado um protótipo envolvendo o escopo definido. Previu-se que o restante do projeto será desenvolvido em outros trabalhos de pesquisa sob orientação da professora orientadora deste trabalho, a serem definidos a critério da mesma. A submissão de uma proposta de continuação deste projeto, em conjunto com um professor parceiro do GIE/FACIN, ao CNPq (Conselho Nacional de Desenvolvimento Científico e Tecnológico), expressa o desejo de continuidade imediata do mesmo.

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

19

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

103

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

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

6.1

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

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

20

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

104

Identificaçã o do problem a E studo de trabal hos correlatos P roposta de solução baseada no Am CorA E studo detalhado do am biente AmCorA P ropo sta de c ri ação d o ambiente PROOGRA MA

R elatado no TI- II, entregue em Nov/02.

P roposta defendida no PE P , em Dez/02.

Definição da visão da solução

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

Identific ação dos requisitos de negócio Identific ação dos perfis de usuário Definição do escopo do projeto

Definição dos papéis e responsabilidades dos integrantes

Organização da form a de trabalh o da equipe

E scolha da linguagem de pro gramação E laboração da estratégia de estudo das tecnologias

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

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

105

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

Como resultado da análise feita e baseados na metodologia da professora, definiu-se um conjunto de características desejadas e que deveriam ser atendidas pelo ambiente a ser selecionado. Definiu-se que o ambiente deveria permitir:

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

A criação e manutenção do acervo das mesmas (banco de exercícios e atividades, banco de exemplos, biblioteca virtual e digital, entre outros);

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

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

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

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

A resolução destas atividades em grupo;

A gerência destes materiais entregues pelos alunos.

Em função da proximidade da proposta de ensino, baseada em uma abordagem construtivista, e da parceria de trabalho entre os grupos GIE/FACIN e GAIA21 (UFES),
21

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

106

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

Quanto à utilização do ambiente AmCorA, como esta foi estabelecida de comum acordo entre os dois professores orientadores dos grupos de pesquisa envolvidos, o orientador do GAIA colocou sua equipe à disposição para consulta e auxílio no estudo deste ambiente. Assim, a partir daquele momento iniciou-se um período de estudo e conhecimento da arquitetura, soluções e tecnologias adotadas pelo AmCorA. Este momento coincidiu com a migração do ambiente para outro sistema operacional, bem como da reformulação da sua arquitetura base, o que exigiu atenção e dedicação dos principais responsáveis pela equipe. Sabendo-se da restrição de tempo para a finalização deste estudo, solicitou-se a liberação para reproduzir o ambiente no servidor do GIE/FACIN, com a intenção de minimizar as interações com os pesquisadores do GAIA em função da demanda de trabalho dos mesmos. A estratégia adotada não obteve êxito. Visto que o AmCorA é um ambiente de origem acadêmica, ou seja, desenvolvido em um contexto de pesquisa, com diversos alunos de graduação e pósgraduaçã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

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.

22

107

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

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

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

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

108

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

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

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

109

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

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

E s pecific aç ão dos requis itos

M odelagem UM L: Cas os de us o

Definiç ão da arqu itetura prelim inar P rototipação da interface gráfic a V alidaç ão c om a professora A tualiz aç ão da espec ificação dos requisitos

E s tudo s obre as tecn ologias

Des envolvim ento de aplicações -teste

S eleç ão das te cnolo gias

Detalham ento da arqu itetura P l anejamen to do proj eto

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

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.

24

110

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

Quadro 6.I – Exemplos de requisitos não-funcionais especificados CATEGORIA ESPECIFICAÇÃO DO REQUISITO

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

Portabilidade

111

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

Inform aç ões P ess oais

Ge ren cia do r de In fraEs tru tura

A gendam ento de Com prom is s os

A tividades

E x pos itor de Notas

E -m ai ls

A M IGO

Pla n o d e Aula s

M ural de Noticias

Lis ta d e Perg u nta s Freq u en tes

Chat

Glos s ario de Term os

B ibl iogra fia

M aterial de A poio

Figura 6.3 - Diagrama de Pacotes do ambiente PROOGRAMA

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

25

Ferramenta desenvolvida pela Rational Software Corporation.

112

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

Agenda de Compromissos: proporciona que os usuarios agendem seus compromissos, estando estes vinculados ou nao a disciplina que estao cursando/ministrando. Editar compromisso <<include>> <<include>> Professor
(from Use Case View)

Incluir compromisso

<<include>> Gerenciar compromisso <<include>>

Usuario
(from Use Case Vi ew)

Excluir compromisso

Monitor
(from Use Case Vi ew)

Visualizar compromisso

Aluno
(from Use Case Vi ew)

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

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

113

Ferramenta x Requisição

Ferramenta y

Navegador (browser)

AMIGO Resposta

Máquina cliente

BD Máquina servidora Figura 6.5 - Arquitetura preliminar do ambiente PROOGRAMA

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

Verificação de Tarefas

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

Módulo Relatórios para o Professor

Módulo Mensagens para os Alunos

Figura 6.6 - Arquitetura interna preliminar do agente AMIGO

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

114

Quadro 6.II – Comparação entre as características oferecidas pelos ambientes e o PROOGRAMA
CARACTERÍSTICAS Administrador Professor Instrutor/Monitor Aluno Controle de acesso e diferentes visões conforme o perfil Ajuda/Help on-line Glossário de termos Mensagens instantâneas Sala para bate-papo (chat) Registro das salas de bate-papo E-mail interno ao curso Envio de e-mail a usuários externos ao curso Recebimento de e-mail de usuários externos Lista/Fórum de discussão Publicação de avisos Agenda/Cronograma de atividades Dados sobre os participantes Elaboração de plano de aula Publicação de material de apoio Envio de tarefas aos alunos Identificação de novas tarefas a serem corrigidas Manutenção de notas Geração de relatórios de participação Agendamento de compromissos Download de material Entrega de material por upload Consulta a resultados de tarefas Atribuição de status a uma tarefa Esclarecimento de dúvidas on-line
Assínc. Síncr.

AMCORA Sim Sim Não Sim Sim Sim Não Sim Sim Não Não Sim Sim Sim Sim Não Sim N/A Sim N/A N/A N/A Não Sim Sim Sim N/A N/A Sim

AULANET Sim Sim Sim Sim Sim Sim Não Sim Sim Sim Sim Não Não Sim Sim Sim Não Sim Sim Sim Não Sim Sim Não Sim Sim Sim Não Não

LEARN. Sim Sim Sim Sim Sim Não Não Não Sim Sim Sim Sim Não Sim Não Sim Sim Sim Sim ? Não Sim ? Não Sim Sim Sim Sim Não

WEBCT Sim Sim Sim Sim Sim ? Sim Não Sim Sim Sim Não Não Sim Sim Sim Sim Sim Sim ? Não Sim Sim Sim Sim Sim Sim Não Não

PROOGRAMA Sim Sim Sim Sim Sim Sim Sim Não Sim Sim Não Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim Não Sim Sim Sim Sim Sim Sim

Características gerais

Ferramentas de apoio ao aluno

Ferramentas de apoio ao professor

Ferramentas de comunicação

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.

Usuário

115

Figura 6.7- Exemplo de interface prototipada em forma de imagem

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

116

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

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

Servlets e JSP: por serem tecnologias específicas para o desenvolvimento para a Web, conforme já mencionado, e permitirem a organização das diferentes camadas de uma aplicação (cliente e de negócios);

Sun ONE Studio 4: para desenvolver o código-fonte. Esta ferramenta, integrada à plataforma J2EE™ versão 1.4, disponibiliza tanto um ambiente de

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

117

MySQL Server e MySQL Control Center: para armazenar os dados da aplicação e estruturar o BD, respectivamente. Suas distribuições também são gratuitas.

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

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

118

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

Ferramenta Servlet Navegador (browser) Requisição API Resposta Máquina cliente JSP BD

AMIGO Máquina servidora Figura 6.8 - Arquitetura do ambiente PROOGRAMA: visão simplificada dos componentes

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

119

plano do projeto). Decidiu-se redigir estas informações em um único documento por considerar-se desnecessário criar documentos distintos, uma vez que o porte do projeto não aborda todos os aspectos definidos, como, por exemplo, o aspecto treinamento de uso da ferramenta.

Figura 6.9 - Artefatos a serem produzidos pelo projeto

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

120

Usuario

Sistema

Incluir compromisso: Regista os dados de um novo compromisso na Agenda de Compromissos. Caso o usuario seja o professor, este podera disponibilizar compromissos para todos os demais participantes da disciplina.

Escolher data

( Dia, mes, ano ) Descrever compromisso ( Titulo, descricao ) Registrar compromisso

Visualizar icone indicando compromisso incluido

Incluir ícone compromisso definido na interface grafica

Figura 6.10 - Diagrama de atividades do requisito Incluir compromisso

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

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

121

Red ução do es copo de desenvolvimento Refinam ento dos re quis itos Definição dos requisi tos do AMIG O

Elaboraç ão da interface gráfic a Va lidaç ão com a profes sora At ual iza ção dos requisitos

M odelagem do diagram a de cl ass es

M odelagem do banc o de dados

Defini ção do funcionament o d o A MIG O Replanejam ent o do projeto

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

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

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

122

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

dis c i pl ina

unidadeAc adem ic a

curs o grupo

turma

ins cri to

us uario

respos t aA tividade

ativida de

opcoes A m igo

perfi l

c om promis s o

Co ntat oE mai l

Ms gEm ailEnviada

Figura 6.12 - Diagrama de classes conceituais do ambiente

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

123

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

u nida d eAcad em ica d is cip lina
i d Di sci p l i n a : In te g e r no m e Di sci p l i n a : S tri n g nu m e roCr ed i to s : In te ge r i dUn i d a d eA ca d em i ca : Inte ge r si g l a Un i da d e Aca d e m i ca : Stri n g n o m e Un i da d e Aca d e m i ca : Stri n g

curs o
n u m e ro Cu rso : In te g e r n o m e Cu rso : Stri n g

a rq uivoR es po s ta Ativid a de
i d A rq u i vo Re sp o staA ti vi d a d e : In te g e r n om eA rq u i vo : S tri n g d ata In se rca o : S tri n g

u su a rio
i d Usua ri o : In teg e r no m e Co m p l e to : S tri n g m a tri cu l a : S tri n g se nh a : S tri n g

turm a
i d T u rm a : In te g e r n u m e ro T u rm a : Inte ge r

i n s crito
i d Inscri to : In te g e r

pa l avra Se cre ta : Stri n g em ai l : S tri n g da taNa sci m en to : Stri n g en d e re co : S tri n g te l e fo n e Re si d en ci al : S tri n g te l e fo n e Ce l ul a r : S tri n g ou tra In fo rm a cao : S tri n g

re s p o s taAti vid ad e
i d Respo sta Ati vi d a d e : In te g e r sta tus : Stri ng co nce i to : S tri n g co m e nta ri o : S tri n g

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

com p rom is s o
i d Co m p rom i sso : In te g er de scri ca o Co m p rom i sso : S tri ng ti p o Com pro m i sso : Stri n g aca o : S tri n g da taCri a cao : S tri n g da t aA ca o : Stri ng pe ri o d oA vi soCo m p ro m i sso : In teg e r fl a g V i su a l i za : Stri n g

gru p o
i dG r up o : In te ge r

a tivida d e
i d A ti vi d ad e : I nte ge r ti tu l o : S tri n g a ssu n to : S tri n g o bj e ti vo : S tri n g ti po A ti vi d a de : S tri ng ti po Do cum en to : Stri n g n um ero Pa rti ci pa nt e s : Stri n g d ata De fi ni ca o : Stri ng d ata Di sp on i bi l i zaca o : S tri n g d ata En tre ga : S tri n g p eri o d o Avi so Ati vi d a d e : Stri ng

a ti vi d a de T urm a

co n fig u raca oAm ig o
ca b eca l h oCo m p ro mi sso Em a il : S tri ng r o d ap e Co m p ro m i sso Em ail : S tri ng n o ti fi ca Inserca oCo m pro m isso P el oA m bi e n te : S tr i ng n oti fi ca In se rca oCo m p ro m i sso Pe loE m a il : Stri ng n oti fi ca A l t e rac ao Co m pro m issoP el o A m bi e n te : S tri ng n otifi caA l t e rac a oCo m pro m i ssoP e lo E m a il : Stri ng n oti fi ca E xcl u sao Co m prom issoP el o Am bi e n te : St ri ng n oti fi ca E x cl u sa oCo m p rom i sso P elo Em a il : S tri ng n oti fi ca In se rca oA ti v i da d eP el o Am bi e nte : Stri ng n otifi caIn se rca o A tiv i da d e P e lo Em ail : S tri ng n otifi caA l t e rac a oA ti v i da d eP el o Am bi en te : Stri ng n oti fi ca A lt e raca o A tiv i da d e P el o Em a i l : S tri n g n oti fi ca E x cl u sa oAti v i da d eP el o A m bi e n te : S tri ng n oti fi caE x cl u sa o Ativ i da d e Pe lo E m a il : Stri ng n oti fi ca Re sp o staAl u n oP el o Am bi e n te : Stri ng n otifi caRe sp o sta Alu n o P elo Em a il : S tri ng n oti fi ca A l t e ra c ao Re sp o staAl u n oP el o Am bi e n te : Stri ng n otifi caA l t e rac a oRe sp o sta Alu n o P elo Em a il : S tri ng n oti fi ca E xcl u sao Re sp o staA l u n oP el oA m bi e n te : S t ri ng n oti fi ca E x cl u sa oRe sp o sta A lu n o Pe loE m a il : Stri ng

a rqu ivo Ativida d e
i d Arqu i voA ti vi d a d e : In te g e r n o m e A rq u i vo : S tri n g d a ta Inserca o : Stri n g

Figura 6.13 - Tabelas do banco de dados do ambiente

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

124

6.3

Desenvolvimento (Developing)
Uma vez tendo modelado todo o ambiente e o agente, e tomado todas as decisões para

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

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

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

26

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

125

Ins ta laç ã o da in fra-es tr utura de desenvolvim ento Criaç ão da estrutura fís ic a do BD Im plem entaç ão func ionalidades infra-es trutura Im plem entaç ão e tes t e A tividades (vis ão P rofes s or) Im plem entaç ão e teste A genda de c om prom is s os (vis ão P rofes sor) Im p lem ent aç ão dem ais funcio nalidade s A t ividad es e A genda (vis ão A luno) Im plem entação e t este E -m ai l Teste de integracão das ferr ame ntas

Imp lem ent aç ão agente A M IGO Teste integração agente A M IGO

Redaç ão dos M anua is do usuár io Redaç ão do Guia de ins talaç ão

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

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

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

126

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

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

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

127

Encerrando esta fase, a equipe realizou um teste mais extensivo da ferramenta e do ambiente e, mais uma vez, identificou algumas restrições e inconsistências em relação ao que havia sido modelado. As anotações feitas também se encontram no Apêndice F (e, da mesma forma que as anteriores, não interferem nos objetivos deste trabalho).

6.4

Estabilização (Stabilizing)
Esta fase foi composta de uma única atividade, apresentada na Figura 6.15, conduzida

pela mestranda e realizada pela professora orientadora deste trabalho. Para revisar os protótipos desenvolvidos (do ambiente e do agente) e verificar se os mesmos estavam atendendo as solicitações feitas, a professora utilizou o ambiente em caráter experimental, realizando uma simulação de uso. Durante esta breve utilização foram observados tanto os aspectos de usabilidade e interface (ex. fácil compreensão, padronização das cores, nomes e elementos definidos, entre outros) e os aspectos pedagógicos, tais como o suporte ao desenvolvimento de uma atividade em grupo, através da permissão do envio do arquivo correspondente à resposta da atividade identificando o grupo que a desenvolveu. A professora também consultou o Manual do usuário do Professor. As considerações apontadas foram apenas registradas, da mesma forma que nos testes feitos anteriormente pela equipe (Vide Apêndice F). Todas as considerações apontadas no Apêndice F serão atendidas quando do desenvolvimento da versão a ser disponibilizada aos alunos, para uso experimental em ambiente real de sala de aula. Este desenvolvimento está previsto para um período consecutivo à entrega e apresentação deste trabalho.

Teste experimental dos protótipos com a profes sora

Figura 6.15 - Atividade realizada durante a fase Estabilização

Os testes previstos com os alunos da professora ocorrerão no próximo semestre letivo à entrega deste trabalho. Estes testes não foram realizados em função do tempo, uma vez que os protótipos ficaram prontos em um prazo muito próximo da entrega do texto da dissertação,

128

e pela professora não estar ministrando na graduação nenhuma disciplina de Algoritmos ou Lapro. Sabe-se que esta questão, caso os protótipos estivesses prontos antes, teria sido viabilizada pela disposição de um outro professor colega da orientadora. Este professor havia se colocado à disposição para realizar tal experimento. Por não ter realizado o processo de teste, correção e reavaliação dos produtos entregues, sabe-se que esta fase não chegou a constituir completamente o objetivo proposto pelo MSF® para a fase Estabilização. Apesar disto, esta equipe de pesquisa comprometeu-se com a professora de dar continuidade ao projeto, no mínimo, até ter uma versão estável para utilização em sala de aula, conforme situação mencionada acima.

6.5

Implantação (Deploying)
A fase Implantação tem dois importantes objetivos, a instalação do software em

ambiente de produção, ou seja, disponibilizá-lo aos usuários finais; e a análise do projeto, tanto por parte da equipe como dos usuários, sendo que estes avaliam o projeto através da pesquisa de satisfação quanto ao produto entregue. Apesar destas serem as principais atividades propostas para esta fase, estas não foram realizadas em sua totalidade. A Figura 6.16 apresenta as atividades realizadas pela equipe.

Dis c us são das lições aprendidas P reparação da infra-estrutura para a apresentaç ão dos protótipos durante a defesa da dis s ertaç ão

Figura 6.16 - Fluxo de execução das atividades da fase Implantação

Uma vez que os protótipos não foram disponibilizados aos alunos, a única análise realizada foi feita pela equipe de pesquisa. Os integrantes discutiram em uma reunião de finalização desta etapa do projeto, denominada pelo MSF® de Lessons Learned Meeting, quais aspectos poderiam ser melhorados e destacaram os conhecimentos adquiridos, bem como manifestaram suas impressões gerais quanto suas participações no projeto. O Quadro

129

6.III apresenta as principais colocações da equipe sobre os aspectos melhorias e aprendizados.

Quadro 6.III – Principais resultados da reunião de fechamento desta etapa do projeto MELHORIAS SUGERIDAS APRENDIZADOS DESTACADOS 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 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.

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 ensinoaprendizagem, tanto em situações presenciais como não-presenciais, sendo o AmCorA o ambiente escolhido, conforme já apresentado. A escolha deste ambiente se deu baseada no estudo feito sobre alguns ambientes de suporte ao ensino e na metodologia utilizada pela professora orientadora como apoio ao processo de ensino-aprendizagem. Pelas dificuldades encontradas para atingir o objetivo mencionado, optou-se por especificar e desenvolver um ambiente próprio, onde o agente poderia passar a atuar. Desta forma, definiu-se o ambiente PROOGRAMA, que reúne as melhores características dos ambientes estudados identificadas pela equipe de pesquisa. A alteração do ambiente base para atuação do agente não trouxe prejuízos à pesquisa, uma vez que, em sua essência, ambos os ambientes possuem uma proximidade nos princípios pedagógicos que guiaram suas concepções.

131

Durante o período da pesquisa, a equipe precisou estudar novos assuntos, aprofundar tópicos de conhecimento superficial e pôr em prática conhecimentos que se possuíam previamente para poder modelar, especificar e desenvolver os protótipos do ambiente e do agente. Após as análises feitas e discussões com a professora e o restante da equipe, confirmou-se a hipótese de que o agente deveria ser modelado para permitir a sua configuração e parametrização de acordo com as preferências do usuário, uma vez que os próprios integrantes manifestaram opiniões diversas quanto à forma que gostariam de perceber o agente no ambiente. Desta forma, esta foi a hipótese modelada e implementada neste protótipo do agente.

Espera-se, com os resultados deste trabalho, atender as expectativas da professora sanando suas necessidades de ter um ambiente centralizador de diversas ferramentas e gerenciador das informações geradas da utilização deste ambiente e, reduzindo assim, seu tempo de trabalho gerencial em relação as disciplinas de Algoritmos e Lapro que ministra nos cursos de graduação da PUCRS.

7.1 Contribuições
As duas grandes contribuições desta pesquisa dizem respeito à definição de um agente para monitorar e gerenciar informações oriundas da utilização de um ambiente de suporte ao processo de ensino-aprendizagem e de um ambiente desta natureza em si, bem como a implementação de um protótipo para validar as definições propostas. A partir destas definições e protótipos, o Projeto PROOGRAMA possui subsídios suficientes para iniciar o desenvolvimento de uma versão a ser disponibilizada em caráter real de sala de aula. Outra contribuição importante é que os responsáveis e parceiros do projeto poderão definir tantas funcionalidades e agentes quanto desejarem em versões futuras. Isto será possível em função da arquitetura do ambiente ter sido projetada intencionalmente para receber novas funcionalidades e ferramentas, bem como agentes de software.

Os documentos elaborados também contribuirão para a continuidade do projeto. Os novos integrantes da equipe poderão consultar o histórico do projeto gerado através da documentação e compreender as decisões tomadas e suas justificativas, o que se considera

132

fundamental para o entendimento da existência de determinadas características e funcionalidades na arquitetura do ambiente e do agente.

De maneira geral, a descrição da adoção de um PDS para o desenvolvimento de um software educativo vem a contribuir com a área de IE, uma vez que não se encontra relatos semelhantes, que auxiliem os profissionais de Educação a modelar e definir seus softwares educacionais. Esta contribuição pode ser constatada através da publicação de um artigo discutindo a importância da formalização do processo de desenvolvimento de um software educacional, no maior e mais importante simpósio brasileiro da área de IE, o Simpósio Brasileiro de Informática na Educação, oficialmente reconhecido e patrocinado pela Sociedade Brasileira de Computação (Vide a listagem das demais publicações relacionadas a este trabalho no Apêndice H).

Em específico, a adoção do MSF® trouxe para a equipe o formalismo praticado por muitas das grandes empresas de desenvolvimento de software nacionais e mundiais, e a oportunidade de compreender-se na prática as diferentes etapas do desenvolvimento de softwares em geral, ficando claro a importância das fases de concepção e especificação da solução (segundo o MSF®, denominadas Visão e Planejamento, respectivamente), bem como que a fase de implementação é dependente das decisões tomadas nestas duas fases anteriores. A equipe deu-se conta da importância de seguir um formalismo no momento que se iniciou a especificação dos requisitos do PROOGRAMA e as alterações nem sempre se tornavam conhecimento de todos, causando o retrabalho de algumas atividades. Sendo assim, decidiu-se que todas as definições e decisões deveriam ser registradas, para que confusões desta natureza fossem evitadas. O benefício foi evidente. A partir do momento que os documentos estavam disponíveis de forma digital, e não mais de forma manuscrita como até então, tornou-se possível trabalhar de maneira distribuída. Ou seja, os integrantes passaram a ter a oportunidade de cumprir suas tarefas e atingir seus objetivos individuais no local e horários desejados, não ficando restritos ao laboratório disponível ao GIE/FACIN e nem ao seu horário de funcionamento. No caso dos bolsistas, a liberação foi acordada com a professora orientadora. Esta situação contribuiu para que a equipe agendasse reuniões periódicas de verificação dos resultados de suas atividades e estes prazos fossem cumpridos. Acredita-se que se as atividades não tivessem sido bem definidas e organizadas não teria sido possível atingir os objetivos determinados para esta pesquisa. Para a mestranda, a utilização do MSF®

133

representou, ainda, a oportunidade de colocar em prática no contexto de sua pesquisa de Mestrado parte do conhecimento adquirido durante seu estágio no convênio que suporta sua bolsa de pesquisa (Convênio Dell/PUCRS).

Em relação aos protótipos, o fato de ter-se tomado o cuidado de escolher ferramentas de distribuição gratuita permite a utilização dos mesmos pelos grupos parceiros ou outros eventuais interessados, uma vez que o custo de adquirir estas ferramentas é nulo. Desta forma, será possível contribuir com os parceiros através da disponibilização das soluções adotadas e do conhecimento gerado e, a partir disto, unificar forças para a geração de um ambiente de suporte ao ensino (presencial ou não) consistente e gratuito, que atenda as necessidades pedagógicas destes grupos. Ao atuar neste sentido, estar-se-á retribuindo as ajudas e auxílios recebidos dos demais grupos e atendendo uma das premissas do GIE/FACIN, de trabalhar integrado a outros profissionais, independentes do caráter da integração: disciplinar ou interdisciplinar, ficando a critério da natureza de cada pesquisa.

7.2 Limitações e restrições
Em função da restrição de tempo, inerente a qualquer projeto de pesquisa, reduziu-se o escopo de desenvolvimento pretendido quando da definição do ambiente PROOGRAMA. Com esta alteração, especificou-se que seriam desenvolvidas no protótipo do ambiente apenas as ferramentas necessárias para a atuação do agente, a fim de poder atender ao tempo disponibilizado para um trabalho de porte para o Mestrado.

Quanto às ferramentas, definiu-se como um dos requisitos do projeto que estas devem ser implementadas de forma independente umas das outras. Ou seja, as ferramentas devem poder funcionar isoladamente. Este requisito não foi totalmente atendido. Levando-se em consideração que apenas parte da equipe tinha conhecimento superficial sobre os conceitos relacionados à organização e utilização de um BD relacional, bem como nenhum dos integrantes conhecia previamente o SGBD MySQL e que a complexidade de projetar o BD para que as ferramentas ficassem isoladas seria aumentada, sendo necessário criar uma linguagem de comunicação entre as diferentes tabelas, a equipe optou por criar um único BD. Desta forma, existe dependência entre as ferramentas no que diz respeito ao armazenamento dos dados nas tabelas do BD. Caso a equipe tivesse um maior tempo para o estudo de uma

134

solução alternativa, esta decisão teria sido evitada. Fato este que não compromete o resultado obtido, servindo apenas como uma restrição a ser destacada. Para minimizar o futuro trabalho necessário para realizar este isolamento entre as tabelas, definiu-se uma API de comunicação entre os servlets e JSPs com o BD, conforme apresentado na Seção 6.2. Todas as funções que realizam alguma consulta ao BD estão inseridas nas APIs, permitindo uma fácil remoção ou manutenção no código relativo às tabelas. Por este motivo, considera-se que o requisito foi atendido parcialmente.

Uma outra limitação foi imposta pela falta de liberação de recursos. O ambiente não pode ser instalado no servidor da equipe por não terem sido liberadas as portas de comunicação necessárias. Sabe-se que esta questão é passível de ser resolvida, sem causar danos ao funcionamento do ambiente. Ao ter estas portas liberadas, o ambiente poderá ser acessado de qualquer máquina localizada nas diversas redes internas da PUCRS. Ou seja, computadores cadastrados e reconhecidos pelas Intranets da Universidade. Para acesso externo, será necessária a liberação da porta de proteção e acesso externo (o firewall), questão esta a ser discutida e justificada pela professora orientadora deste trabalho. A equipe não possui autonomia para requisitar tal pedido. Ao ter esta porta liberada, o PROOGRAMA estará disponível para qualquer usuário que possua uma máquina com acesso à Internet. Novamente, esta é uma restrição operacional que se salienta e não interfere nos resultados.

No que diz respeito ao AMIGO, no contexto deste protótipo, este tem seus relatórios retratando informações bastante simples. Isto se deve ao escopo restrito selecionado para esta pesquisa de Mestrado. As definições feitas para o agente atendem as necessidades da professora e solucionam a questão do tempo que esta investe na gerência das informações recebidas dos alunos no que se refere às atividades propostas (trabalhos, exercícios, entre outras).

Ainda quanto aos protótipos, algumas funcionalidades de gerenciamento da infraestrutura não foram implementadas, tal como a exclusão de todo o material relacionado a uma disciplina em específico, uma vez que, para o funcionamento do AMIGO elas não se faziam necessárias. Neste mesmo sentido, não se implementou o envio e recebimento de e-mails para/de usuários com contas externas àquela fornecida pela FACIN. Também não foi elaborado o help on-line. Sabe-se ainda que os protótipos possuem algumas inconsistências quanto ao que foi modelado e implementado, conforme descrito nas Seções 6.3 e 6.4. Por

135

exemplo, ao digitar sua senha errada, o usuário não recebe notificação de que digitou um valor inconsistente. Os dados informados são simplesmente apagados, exigindo que o usuário perceba por si mesmo o erro cometido. Tanto estas inconsistências como as funcionalidades que não foram implementadas neste momento serão atendidas ainda antes dos protótipos serem disponibilizados em caráter experimental para alunos da turma de Algoritmos da professora no próximo semestre letivo. A disponibilização para esta turma de Algoritmos virá a atender outra restrição deste trabalho, a de não ter utilizado experimentalmente o protótipo em ambiente real de sala de aula. Esta utilização foi apenas simulada com a professora, durante sua validação dos protótipos.

7.3 Trabalhos futuros
Tendo atendido as questões mencionadas acima, um primeiro trabalho proposto é disponibilizar os protótipos aos alunos e analisar suas considerações, para tal, devem ser preparados instrumentos de avaliação. Além das correções inicialmente necessárias nos protótipos, tem-se uma série de aspectos que podem ser investigados para melhorar e complementar o ambiente e o agente. A primeira questão a ser estudada é aquela relacionada à estruturação do BD. Atendendo a especificação das ferramentas funcionarem isoladamente dar-se-á a opção de, futuramente, definir um mecanismo de configuração das ferramentas a serem adotadas pelo professor, sendo este o aspecto inicial para transformar o PROOGRAMA em um ambiente de autoria de cursos.

Considerando que foram selecionadas várias ferramentas de pesquisadores parceiros para serem disponibilizadas no ambiente, como, por exemplo, a Moonline, para esclarecimento de dúvidas on-line, é necessário integrá-las ao PROOGRAMA. Neste sentido, para suprir a necessidade de definir como fazer esta integração, uma vez que nem todas foram desenvolvidas usando as mesmas tecnologias adotadas neste trabalho, propõe-se uma arquitetura de integração entre o ambiente PROOGRAMA e as demais ferramentas. Esta arquitetura foi definida em conjunto com um dos professores parceiros do GIE/FACIN e submetida como projeto de pesquisa conjunto entre os dois grupos orientados pelos professores ao CNPq.

136

A arquitetura de integração do PROOGRAMA irá agregar as ferramentas através da tecnologia de Web Services, permitindo a troca de dados e informações entre o ambiente e as ferramentas, localizadas em seus servidores originais. Isto é, não será necessário integrar fisicamente as ferramentas ao PROOGRAMA. Segundo [HAN03a; HAN03b], Web Services são aplicações modulares que podem ser descritas, publicadas e invocadas sobre uma rede, geralmente a Web. Ou seja, é uma interface que descreve uma coleção de operações que são acessíveis pela rede através de mensagens em formato XML padronizadas. Permitem uma integração de serviços de maneira rápida e eficiente. Um Web Service é um componente de software independente de implementação e plataforma. É descrito utilizando uma linguagem de descrição de serviços, publicado em um registro e descoberto através de um mecanismo padrão. Desta forma, propõe-se que as ferramentas externas ao PROOGRAMA sejam excluídas de sua atual arquitetura e encapsuladas em uma estrutura do tipo Adapter. Segundo [GAM95], este tipo de estrutura permite converter a interface de uma classe em outra interface, esperada pelos clientes e, desta forma, possibilita que classes com interfaces distintas e incompatíveis possam trabalhar juntas. O mesmo deve ocorrer para as ferramentas que estarão sendo invocadas. Esta solução permitirá que outras ferramentas também sejam endereçadas pelo PROOGRAMA. A Figura 7.1 apresenta a arquitetura de integração proposta.

Adapter_PROOGRAMA

Camada de composição em WebServices
Glossário de termos Bibliografia Material do Curso Adapter_Fórum AMIGO E-mail Material de apoio

Atividades

Fórum Adapter_Moonline

Monitor. e Gerência de Informações Moonline Adapter_ILA Plano de aulas

Chat Comunicação Direta

Informações pessoais AMBAP ILA Agenda de comprom. Mural Comunicação Pública Expositor de notas
Informações dos Alunos

Figura 7.1 - Arquitetura de integração proposta

137

Para manter uma única tecnologia no que diz respeito à interface com o usuário, também se propõe como trabalho futuro a migração da interface gráfica para XML, uma vez que esta tecnologia é suportada pelos servlets. Sendo assim, será necessário apenas mudar a interface atual de HTML e JSP para XML. Esta alteração irá permitir uma flexibilização na interface do usuário, sendo possível alterar mais facilmente características tais como cores de fundo, tipo e tamanho de fontes, entre outras.

Uma vez que a arquitetura do PROOGRAMA foi intencionalmente projetada para incluir novos agentes, será possível definir outros agentes para ampliarem a atuação do AMIGO no que tange a gestão das informações do ambiente, visando auxiliar no processo de avaliação da aprendizagem dos alunos suportada pelo ambiente virtual. Como, por exemplo, especificar agentes para auxiliarem na definição de um modelo de aluno; para gerenciarem os materiais e bibliografias disponibilizadas, notificando os alunos das novidades; e para analisarem o conteúdo dos arquivos enviados pelos alunos, buscando identificar se o conteúdo enviado está relacionado ao assunto em questão.

Ainda pode-se apontar como trabalhos futuros o estudo e tratamento nas próximas versões do ambiente aspectos relacionados à performance e portabilidade do ambiente, no que diz respeito aos elementos que constituem a interface gráfica (ao adotar-se Java, os aspectos de portabilidade da implementação como um todo já está garantido).

138

REFERÊNCIAS BIBLIOGRÁFICAS

[ALL03]

ALLAIRE Corporation. JRun. Disponível em: <http://commerce.allaire. com>. Acesso em: 27 out. 2003.

[ALM02]

ALMEIDA, Eliana et al, AMBAP: Um AMBiente de Apoio ao aprendizado de Programação, In: CONGRESSO NACIONAL DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 22, 2002, Florianópolis. Anais... Florianópolis: SBC, 2002.

[ALM03]

ALMEIDA, Maria Elizabeth. Educação a distância e tecnologia: contribuições dos ambientes virtuais de aprendizado. In: CONGRESSO NACIONAL DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 23., 2003, Campinas. Anais... Campinas: UNICAMP, 2003.

[ALV97]

ALVARES, Luis; SICHMAN, Jaime. Introdução aos Sistemas Multiagentes. In: JORNADA DE ATUALIZAÇÃO EM INFORMÁTICA, 16., 1997, Brasília. Anais... Brasília: UnB, 1997.

[AND01]

ANDRADE, Adja et al. Requisitos para a modelagem de ambientes de aprendizagem a distância: Uma proposta da PUCRS Virtual. In: INTERNATIONAL CONFERENCE ON NEW TECHNOLOGIES IN SCIENCE EDUCATION, 2001, Aveiro/Portugal. Disponível em: <http://www.ead.pucrs.br/biblioteca/pesquisas_portal/index.php>. Acesso em: 04 mar. 2003.

[ASP03]

ASP 101: The place where developers go! Disponível em: <http://www. asp101.com>. Acesso em: 29 out. 2003

[AUL02]

AULANET. Manual do Aprendiz. 2. e.d Rio de Janeiro: PUC-Rio, 2002. Disponível em: <http://www.eduweb.com.br/frame_produto.asp>. Acesso em: 30 out. 2002.

[AUS80]

AUSUBEL, David. Psicologia Educacional. Interamericana: New York, 1980.

139

[BAC00]

BACELO, Ana P. Estudo de Taxonomias de CSCW e Tecnologia de Framework para Ambientes de Ensino Colaborativo. Trabalho Individual I (Doutorado em Ciência da Computação) – PPGCC, Faculdade de Informática, PUCRS, Porto Alegre, 2000.

[BEC00]

BECK, Kent. Extreme Programming explained: Embrace change. Boston: Addison-Wesley, 2000.

[BEL03]

BELVEDERE. Disponível em: <http://advlearn.lrdc.pitt.edu/belvedere>. Acesso em: 12 jun. 2003.

[BIG01]

BIGUS, Joseph; BIGUS, Jennifer. Constructiong Intelligent Agents Using Java. New York: John Wiley and Sons, 2001.

[BOO99]

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The Unified Modeling Language User Guide. [S.l.]: Addison-Wesley, 1999.

[BOR01]

BORDINI, Rafael; VIEIRA, Renata; MOREIRA, Álvaro. Fundamentos de Sistemas Multiagentes. In: JORNADA DE ATUALIZAÇÃO EM INFORMÁTICA, 20., 2001, Fortaleza. Anais... Fortaleza, UFC, 2001.

[BOW02]

BOWLING, Elizabeth. Understanding the architecture of LearningSpace. Disponível em: <http://www-10.lotus.com/ldd/ today. nsf/displayForm/44040B437D06021185256B9C006193F5?OpenDocu ment>. Acesso em: 04 out. 2002.

[BRI02]

BRIOT, Jean-Pierre; DEMAZEAU, Yves. Principes et architecture des systèmes multi-agents. Paris: Hermes, 2002.

[BRO86]

BROOKS, Richard. A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automation, [S.l.], v. 2, n. 1, mar. 1986.

[CHA01]

CHAVES, Thais et al. Um Ambiente para Apoio à Aprendizagem de Programação, In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 12., 2001, Vitória. Anais... Vitória: UFES, 2001.

[COC02]

COCKBURN, Alistair. Agile Software Development. Boston: AddisonWesley, 2002.

140

[COP03]

COPSTEIN, Bernardo. J2EE: Criando Aplicações para Web. Disponível em: <http://www.inf.pucrs.br/~copstein/LinguagemJavaUML>. Acesso em: 26 jun. 2003.

[DEI00]

DEITEL, Harvey. Java: How to Program. New Jersey: Prentice Hall, 2000.

[DRU03]

DRUZIANI, Cássio; LIMA, José. Monitoramento personalizado de hiperdocumentos como apoio à avaliação em uma ambiente de ensino-aprendizagem na Web. Dissertação (Mestrado em Ciência da Computação) – Instituto de Informática, UFRGS, Porto Alegre, 2003.

[ESC03]

ESCOL@NET. Disponível em: <http://www.escolanet.com.br/>. Acesso em: 12 jun. 2003.

[EVA00]

EVARISTO, Jaime; CRESPO, Sérgio. Aprendendo a programar: Programando numa Linguagem Algorítmica Executável (ILA), Porto Alegre, Book Express, 2000.

[FER91]

FERBER, Jacques; GASSER, Les. Intelligence artificielle distribuée. In: INTERNATIONAL WORKSHOP ON EXPERT SYSTEMS & THEIR APPLICATIONS, 11., 1991, Avignon/France. Proceedings… Avignon: [S.n.], 1991.

[FER99]

FERBER, Jacques. Multi-Agent Systems: An Introduction to Distributed Artifical Intelligence. [S.l.]: Addison-Wesley, 1999.

[FOW00]

FOWLER, Martin; SCOTT, Kendall. UML Essencial: Um breve guia para a linguagem-padrão de modelagem de objetos. Porto Alegre: Bookman, 2000.

[FRA96]

FRANKLIN, S.; GRAESSER, A. Is it na Agent, or Just a Program?: A Taxonomy of Autonomous Agents. International Workshop on Agent Theories, Architectures and Languages, 1996, Alemanha. Proceedings… Alemanha: Springer-Verlag, 1996.

[FUK00]

FUKS, Hugo. Aprendizagem e Trabalho Cooperativo no Ambiente AulaNet. Revista Brasileira de Informática na Educação, [S.l.], n. 6, abr. 2002. Disponível em: <http://www.les.inf.puc-rio.br/ groupware>. Acesso em: 19 set. 2002.

141

[FUK01]

FUKS, Hugo; GEROSA, Marco; LUCENA, Carlos. Sobre o Desenvolvimento e Aplicação de Cursos Totalmente a Distância na Internet. Revista Brasileira de Informática na Educação, [S.l.], n. 9, set. 2001. Disponível em: <http://www.les.inf.puc-rio.br/groupware>. Acesso em: 19 set. 2002.

[FUK02]

FUKS, Hugo; RAPOSO, Alberto; GEROSA, Marco. Engenharia de Groupware: Desenvolvimento de Aplicações Colaborativas. In: JORNADA DE ATUALIZAÇÃO EM INFORMÁTICA, 21., 2002, Florianópolis. Anais... Florianópolis: SBC, 2002.

[GAI02]

GAIA. Help on-line do ambiente AmCorA. Disponível em: <http://www. gaia.ufes.br/~helpamcora/amcora.htm>. Acesso em: 11 out. 2002.

[GAM95]

GAMMA, Erich et al. Design Patterns: elements of reusable objectoriented software. Boston: Addison-Wesley,1995.

[GAS92]

GASSER, Les. Boundinaries, identity and aggregation: plurality issues in multi-agent systems. Amsterdam: Elsevier Science, 1992.

[GAV98]

GAVA, Tânia. Monitoria On-line: Um ambiente na Internet para apoio ao atendimento extra-classe. Dissertação (Mestrado em Informática) – Centro Tecnológico, UFES, Vitória, 1998.

[GAV00]

GAVA, Tânia; MENEZES, Crediné. Moonline: Um Sistema Multiagentes Baseado na Web para Apoio a Aprendizagem, In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 11., 2000, Maceió. Anais... Maceió: UFAL, 2000.

[GEN94]

GENESERETH, M; KETCHPEL, S. Software Agents. Communications of the ACM, [S.l.], v. 37, n. 7, 1994.

[GIR02]

GIRAFFA, Lucia; PINTO, Sérgio; OLIVEIRA, João Batista, PROOGRAMA: Ambiente Cooperativo de Suporte a Aprendizagem de Algoritmo e Programação. Relatório Técnico n. 024 – PPGCC, Faculdade de Informática, PUCRS, Porto Alegre, 2002.

[GOL98]

GOLDBERG, Murray. WebCT: A Web-Based Course Authoring Tool. Disponível em: <http://duff-5.ucs.ualberta.ca/CNS/PUBS/webct-intro. html>. Acesso em: 04 out. 2002.

142

[GOM03]

GOMES, Alex; WANDERLEY, Eduardo. Elicitando requisitos em projetos de software educativo. In: CONGRESSO NACIONAL DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 23., 2003, Campinas. Anais... Campinas: UNICAMP, 2003.

[HAC99]

HACK, Luciana. Mecanismos complementares para a avaliação do aluno na Educação a Distância. Dissertação (Mestrado em Ciência da Computação) – Instituto de Informática, UFRGS, Porto Alegre, 1999.

[HAN03a]

HANSEN, Roseli; PINTO, Sergio. Construindo Ambientes de Educação Baseada na Web através de Web Services Educacionais. In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 14., 2003, Rio de Janeiro. Anais... UFRJ: Rio de Janeiro, 2003.

[HAN03b]

HANSEN, Roseli; PINTO, Sergio. GlueScript: Uma Linguagem Específica de domínio para Composição de Web Services. Dissertação (Mestrado em Computação Aplicada) – Centro de Ciências Exatas e Tecnológicas, Unisinos, Porto Alegre, 2003.

[HEW77]

HEWITT, C. Viewing Control Structures as Patterns of Passing Messages. Artificial Intelligence, Holanda: Elsevier Science, v. 3, 1977.

[HÜB03]

HÜBNER, Jomi; SICHMAN, Jaime. Organização de Sistemas Multiagentes. In: ENCONTRO NACIONAL DE INTELIGÊNCIA ARTIFICIAL, 4., 2003, Campinas. Anais... Campinas: UNICAMP, 2003.

[HUH99]

HUHNS, Michael; STEPHENS, Larry. Multiagent system and societies of agents. In: WEISS, Gehard. (Org.). Multiagent Systems – A Modern Approach. [S.l.]: MIT Press, 1999. cap. 2.

[HUN02]

HUNTER, Jason; CRAWFORD, William. Java Servlet: Programação. Rio de Janeiro: Ciência Moderna, 2002.

[IHM01]

IHMC. Concept Map Software: A Knowledge Construction Toolkit. Disponível em: <http://cmap.coginst.uwf.edu/>. Acesso em: 16 mai. 2003.

143

[JAC99]

JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James The Unified Software Development Process. Workinghan: Addison-Wesley Longman, 1999.

[JEN98]

JENNINGS, Nicholas; SYCARA, Katia; WOOLDRIDGE, Michael. A Roadmap of Agent Research and Development. [S.l.]: [S.n.], 1998. KIDLINK BRASIL. Disponível em: <http://venus.rdc.puc-rio.br/kids/ kidlink>. Acessado em: 12 jun. 2003.

[KID03]

[KIS02]

KIST, Tânia. Ambientes de Gerenciamento de Cursos a Distância. Relatório de Pesquisa nº 314 (Mestrado em Ciência da Computação) Instituto de Informática, UFRGS, Porto Alegre, 2002.

[KRU01]

KRUCHTEN, Philippe The Rational Unified Process: An introduction. Boston: Addison-Wesley, 2001.

[KUR02]

KURNIAWAN, Budi. Java for the Web with Servlets, JSP, and EJB. Indianapolis: New Kiders, 2002.

[LAU01]

LAUFER, Carlos; BLOIS, Marcelo; CHOREN, Ricardo. Practice on the Web: A Tool for Learning From Cases. In: SOCIETY FOR INFORMATION TECHNOLOGY & TEACHER EDUCATION, 2001, Orlando. Proceedings… AACE: [S.n.], 2001.

[LIC03]

LICKS; VIEIRA JR.; DE AZEVEDO. TestM@ker: Uma Ferramenta de Avaliação do Aprendizado à Distância. Relatório de Trabalho de Conclusão II (Graduação em Ciência da Computação) – Faculdade de Informática, PUCRS, Porto Alegre, 2003.

[LON97]

LONG, Byron; BAECKER, Ronald. A Taxonomy of Internet Communication Tools. In: WEBNET, AACE, 1997, Toronto. Proceedings… Toronto: [S.n.], 1997. Disponível em: <http://citeseer. nj.nec.com/558859.html>. Acesso em: 27 set. 2002.

[LOT99]

LOTUS Corporation. Lotus LearningSpace Forum: Student’s Guide. 3th. ed. Cambridge: Lotus Press, 1999. Disponível em: <http://www-12. lotus.com/ldd/doc/uafiles.nsf/docs/lsf36/$File/fstudent.pdf>. Acesso em: 04 out. 2002.

144

[LUC99]

LUCENA, Carlos et al. AulaNet: Ajudando Professores a Fazerem seu Dever de Casa. In: CONGRESSO NACIONAL DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 19., 1999, Rio de Janeiro. Anais... Rio de Janeiro: EntreLugar, 1999. Disponível em: <http://www.les.inf. puc-rio.br/groupware>. Acesso em: 19 set. 2002.

[MAC99]

MACHADO, Julio H.; MENEZES, Paulo. Sistemas de Gerenciamento para Ensino a Distância. Trabalho Individual (Mestrado em Ciência da Computação) – Instituto de Informática, UFRGS, Porto Alegre, 1999.

[MAR02]

MARCZAK, Sabrina. A Gerência de Informação em Ambientes de Ensino a Distância: Um Estudo Comparativo. Trabalho Individual II (Mestrado em Ciência da Computação) – PPGCC, Faculdade de Informática, PUCRS, Porto Alegre, 2002.

[MCC96]

MCCONNELL, Steve. Rapid Development: Taming Wild Software Schedules. [S.l.]: Microsoft, 1996.

[MEL98]

MELO, Washington. Sala de Aula Virtual Cooperativa. Dissertação. (Mestrado em Ciências) – PESC/COPPE, UFRJ, Rio de Janeiro, 1998.

[MEN98]

MENEZES, Crediné et al. QSabe: Trocando Experiências sobre Informática Educativa em uma Rede de Educadores. Revista Brasileira de Informática na Educação, [S.l.], n. 2, abr. 1998. Disponível em: <http://www.inf.ufsc.br/sbc-ie/revista/nr2/ Menezes02. htm>. Acesso em: 15 jan. 2002.

[MEN99]

MENEZES, Crediné; CURY, Davidson. AmCorA: Um Ambiente Cooperativo para a Aprendizagem Construtivista Utilizando a Internet. In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 10., 1999, Curitiba, PR. Anais... Curitiba: UFPR, 1999.

[MENEG02] MENEGUZZI, Felipe. Raciocínio BDI. Trabalho Individual I (Mestrado em Ciência da Computação) – PPGCC, Faculdade de Informática, PUCRS, Porto Alegre, 2002.

[MENEZ02] MENEZES, Crediné et al. Educação a distância no Ensino Superior – Uma proposta baseada em Comunidades... In: SIMPOSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 13., 2002, São Leopoldo. Anais... São Leopoldo: UNISINOS, 2002.

145

[MIC02a]

MICROSOFT. Microsoft Solutions Frameworks Essentials: Student workbook. Microsoft Training & Certification Series, Course number 1846. [S.l.]: Microsoft Press, 2002.

[MIC02b]

MICROSOFT. MSF Process Model v. 3.1. White paper, 2002. Disponível em: <http: //www.microsoft.com/msf>. Acesso em: 20 jun. de 2003.

[MOU96]

MOULIN, Bernard; CHAIB-DRAA, Brahim. An Overview of Distributed Artificial Intelligence. In: O’HARE, Greg; JENNINGS, Nicholas (Org.). Foundations of Distributed Artificial Intelligence. New York: John Wiley and Sons, 1996.

[MUS01]

MUSA, Daniela et al. Agente para auxílio à avaliação de aprendizagem em ambientes de ensino na Web. In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 12., 2001, Vitória, ES. Anais... Vitória: UFES, 2001.

[MYS02]

MYSQL. MySQL: Reference Manual, 2002. Disponível em: <http://www. mysql.com>. Acesso em: 27 jun. 2003.

[NCS03]

NCSA. Habanero. Disponível em: <http://www.isrl.uiuc.edu/isaac/ Habanero/>. Acesso em: 12 jun. 2003

[NET02]

NETO, Roberto. Curso de JSP. Relatório Técnico (Grupo PET – Programa Especial de Treinamento) – Ciência da Computação, UFSC, Florianópolis, 2002. Disponível em: <http://monica.inf.ufsc.br/ Apostilas/jsp.pdf>. Acesso em: 15 ago. 2003.

[NET03]

NETTO, Hylson. Agregando Flexibilidade e Configurabilidade ao Ambiente AmCorA. Dissertação (Mestrado em Engenharia Elétrica) – PPGEE, Centro Tecnológico, UFES, Vitória, 2003. Disponível em: <http://www.gaia.ufes.br/amcora>. Acesso em: 25 out. 2003.

[NEW97]

NEWMAN, Alexander. Usando Java GRMC. Rio de Janeiro: Campus, 1997.

[NIE00]

NIELSEN, Jakob. Desigining Web Usability: the Practice og Simplicity. Indianapolis: New Riders, 2000.

146

[NOB02]

NOBRE, Isaura. Suporte à Cooperação em um Ambiente de aprendizagem para Programação (SAmbA). Dissertação (Mestrado em Informática) – Departamento de Informática, UFES, Vitória, 2002.

[NWA96]

NWANA, H. Software Agents: An Overview. In: The Knowledge Engineering Review. [S.l]: [S.n.], 1996.

[ORA03]

ORACLE. Disponível em: <http://www.oracle.com>. Acesso em: 03 jul. 2003.

[PAR99]

PARUNAK, V.; ODELL, J. Engineering artifacts for multi-agent systems. In: Proceedings of MAAMAW Conference in Madrid, Spain, 1999.

[PAU99]

PAULK, Mark. et al, The Capability Maturity Model: Guidelines for Improving the Software Process. Berkley: Addison-Wesley, 1999.

[PES00]

PESSOA, José M.; MENEZES, Crediné. QSabe II: A Cooperative Service for Knowledge Appropriation and Diffusion Using the Internet. In: INTERNATIONAL CONFERENCE ON ENGINEERING AND COMPUTER EDUCATION, 2000, São Paulo. Proceedings… São Paulo: [S.n.], 2000.

[PIN91]

PINTO, Sergio; SILVA, João L.; COUTINHO, Hamilton. Construção de um interpretador de linguagem algorítmica. In: SALÃO DE INICIAÇÃO CIENTÍFICA DA UFRGS, 3., 1991, Porto Alegre. Proceedings... Porto Alegre: UFRGS, 1991.

[PIN02]

PINTO, Sérgio et al. AVA – Um Ambiente Virtual Baseado em Comunidades. In: SIMPOSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 13., 2002, São Leopoldo. Anais... São Leopoldo: UNISINOS, 2002.

[POL01]

[PRE01]

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. PRESSMAN, Roger, Software Engineering: A Practioner's Approach. New York: McGraw-Hill, 2001.

147

[PRI02]

PRIKLADNICKI, Rafael. Desenvolvimento Distribuído de Software e Processos de Desenvolvimento de Software. Trabalho Individual II (Mestrado em Ciência da Computação) – PPGCC, Faculdade de Informática, PUCRS, Porto Alegre, 2002.

[RUS95]

RUSSEL, Stuart. Artificial Intelligence: A Modern Approach. New Jersey: Prentice-Hall, 1995. 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/sbcie/revista/nr4/ 070TU-santos.htm>. Acesso em: 12 jun. 2003.

[SAN99]

[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: AddisonWesley, 2003.

[SUN03a]

SUN MICROSYSTEMS. Java. Disponível em: <http://www.java.sun. com>. Acesso em: 29 jun. 2003.

[SUN03b]

SUN MICROSYSTEMS. Servlets. Disponível em: <http://www.java.sun.com/products/servlets>. Acesso em: 29 jun. 2003.

[SUN03c]

SUN MICROSYSTEMS. Java Server Pages. Disponível em: <http://www.java.sun.com/products/jsp>. Acesso em: 29 jun. 2003.

148

[SUN03d]

SUN MICROSYSTEMS. Java™ 2 Platform Enterprise Edition. ™ Disponível em: <http://www.java.sun.com/products/j2ee>. Acesso em: 29 jun. 2003.

[SUN03e]

SUN MICROSYSTEMS. Tomcat @ Jakarta. Disponível em: <http://www. java.sun.com/products/jsp/tomcat>. Acesso em: 17 set. 2003.

[STU03]

STUDY WEB. Disponível em: <http://www.studyweb.com>. Acesso em: 12 jun. 2003.

[TIG03]

TIGRIS.ORG: Open Source Software Engineering. ArgoUML. Disponível em: <http://argouml.tigris.org>. Acesso em: 23 jun. 2003.

[TOB01]

TOBAR, Carlos et al. Uma Arquitetura de Ambiente Colaborativo para o Aprendizado de Programação. In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 12., 2001, Vitória, ES. Anais... Vitória: UFES, 2001.

[WEB00]

WEBCT. WebCT 3.0: Getting Started Tutorial. 2000. Disponível em: <http://www.webct.com>. Acesso em: 17 set. 2002.

[WEI96]

WEISS, Gehard; SEN, Sandip. Adaptation and learning in multi-agent systems. Berlin: Spring-Verlag, 1996

[WEI99]

WEIB, Gabriel. Multi-Agent Systems: A modern approach to distributed artifical intelligence. London: MIT Press, 1999.

[WOO95]

WOOLDRIDGE, Michael; JENNINGS, Nicholas. Intelligent Agents: Theory and Practice. In: The Knowledge Engineering Review. [S.l]: [S.n.], 1995.

[WOO99]

WOOLDRIDGE, Michael. Intelligent Agents. In: WEISS, Gehard. (Org.). Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence. Cambridge: MIT Press, 1999.

[WOO01]

WOOLDRIDGE, Michael. An Introduction to Multi-Agent Systems. West Sussex: John Wiley Sons, 2002.

149

[WOR02]

WORLD Bank Learning Network. LearnigSpace Style Guide. Disponível em: <http://www.worldbank.org/distancelearning/Resource/Lsg/lsg. htm>. Acesso em: 04 out. 2002.

[XTP02]

EXTREME PROGRAMMING. Extreme Programming: A Gentle Introduction. White Paper, 1999. Disponível em: <http://www. extremeprogramming.org>. Acesso em: 25 jun. 2003.

[YIN01]

YIN, Robert. Estudo de Caso: planejamento e métodos. São Paulo: Bookman, 2001.

150

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

185

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

199

APÊNDICE C – Estrutura e Plano do Projeto PROOGRAMA

217

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

263

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

284

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

287

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

290

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

O Projeto PROOGRAMA na Internet http://www.inf.pucrs.br/~giraffa/proograma

Esta pesquisa foi parcialmente financiada pelo Convênio Dell/PUCRS, através da Lei de Informática Brasileira (Lei nº. 8.248/91). Também financiada pelo Centro de Tecnologia XML Microsoft/PUCRS e pelos órgãos de fomento MEC/SESu e FAPERGS.

Este trabalho foi digitado conforme o Guia para Apresentação de Trabalhos Acadêmicos, Teses e Dissertações da Biblioteca Central Irmão José Otão da PUCRS, segundo a NBR 14724 proposta pela ABNT, atualizado em 06 de agosto de 2003.

AMIGO - Um Agente para MonItorar e Gerenciar infOrmações I O no ambiente PROOGRAMA Espaço reservado para anotações dos membros da Comissão Examinadora

AMIGO - Um Agente para MonItorar e Gerenciar infOrmações I O no ambiente PROOGRAMA Espaço reservado para anotações dos membros da Comissão Examinadora

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->