---

Grupo C5:

• Alberto Barbosa Raposo           RA 946152 (relator)
• Christian Medeiros Adriano       RA 931594
• Jefferson Blaitt                 RA 973528
• Raquel Santos Schulze            RA 956289

1. Introdução

A possibilidade de dar dinamismo à WWW, seja através de programas executados no servidor (e.g., CGI scripts [1], [2], Java servlets [3]) ou executados no cliente (e.g., Java applets [4], [5], programas em JavaScript [6]) é o que denominamos "programação na Web".

A programação na Web é o tema principal deste trabalho, que discutirá as diversas formas de programação no contexto de educação à distância, mais precisamente em um ambiente capaz de fornecer "cursos sob medida" de acordo com o perfil do aluno e "provas virtuais", também de acordo com o mesmo perfil. A Seção 2 discutirá de maneira geral as várias formas de programação na Web. A Seção 3 apresentará o ambiente a ser estudado. A Seção 4 proporá a implementação do ambiente com o mecanismo de programação que achamos mais adequado. As conclusões serão apresentadas na Seção 5.
 

2. Mecanismos de Programação na Web

Programas CGI só podem ser executados no servidor, e a cada requisição uma nova cópia do programa é criada. Isso pode sobrecarregar muito o servidor, especialmente em sites com grande número de acessos.

Uma alternativa aos programas CGI é a utilização de applets Java [4], [5]. Applets são programas Java embutidos em uma página HTML (através do tag <APPLET>), que são transmitidos para o cliente e executados no mesmo, a cada vez que a página é acessada. Os applets são transmitidos em byte-codes (conjunto de instruções pré-compiladas, semelhantes ao código de máquina, mas sem serem específicas de qualquer processador), que são verificados na máquina do cliente, garantindo a segurança do código recebido. Além do mais, applets têm outras restrições de segurança,  tais como não poderem fazer acesso a arquivos na máquina do cliente e nem se conectar a qualquer outro servidor que não o de sua origem.

Um dos problemas associados aos applets é a demora no tempo de carregamento. Cada vez que a página é acessada, há a necessidade de transferir todo o código para o cliente. Esse problema é agravado à medida que os applets vão crescendo em tamanho.

Uma das propostas que surgiram para compensar esse problema associado aos applets é a idéia de se criar uma "metáfora de canal" entre cliente e servidor Web [8]. Segundo essa proposta, os canais (uma hierarquia de diretório contendo arquivos) seriam copiados no disco dos clientes que os solicitassem. Com o armazenamento local, o usuário só teria que carregar os programas na primeira vez que solicitasse o canal. Depois disso, o cliente determina a freqüência com que ele solicita ao servidor a atualização do canal (e o servidor determina se há a necessidade de tal atualização). Essa implementação difere dos Web "pushers" [9], [10] porque estes últimos fazem a atualização via "broadcast" a partir do servidor  (com o objetivo mais voltado em facilitar com que as fontes de informação a atualizem através da Internet - exemplos típicos são revistas e jornais eletrônicos). A grande desvantagem dessa tecnologia é a utilização do espaço em disco do cliente.

Outra forma de se realizar o processamento no cliente é através de programas JavaScript [6]. Essa é uma solução proprietária e permite que se coloque programas embutidos nas páginas HTML, programas esses que o "browser" (Netscape) é capaz de interpretar. No entanto, JavaScript é uma linguagem com limitações e não tem obtido o sucesso esperado pelos seus idealizadores.

A execução de programas no cliente nem sempre é a melhor solução. Há casos, como por exemplo o acesso a base de dados localizada no servidor, em que é mais interessante que os programas sejam executados no próprio servidor. Além disso, programas que executam no servidor não dependem do tipo de browser e são mais seguros, pois são executados sob controle direto do administrador [3].

Uma solução promissora nesse sentido é a utilização de servlets [3], uma API padrão da linguagem Java e que pretende ser uma alternativa ao CGI. Basicamente, servlets são programas CGI escritos em Java, com a diferença que o programador não precisa se preocupar com as variáveis de ambiente especificadas pelo CGI e nem com detalhes do recebimento e envio dos dados (cabeçalho HTTP, por exemplo), já que existem métodos na API para realizar  facilmente tudo isso.

As vantagens de servlets sobre CGI são várias:

• Eficiência: não é gerada uma nova cópia do programa a cada requisição.
• Segurança: servlets se beneficiam dos mecanismos de segurança da linguagem Java.
• Portabilidade: por serem escritos em Java, servlets independem de plataforma.
• Familiaridade/Coerência: Java é uma linguagem popular, e a utilização de servlets em conjunto com applets pode trazer inúmeros benefícios.

3. Ambiente de "curso sob medida" e "prova virtual"

O ambiente também fornece "provas virtuais", i.e., a avaliação é feita online pelos alunos e as respostas são enviadas para serem corrigidas pelo professor ou são corrigidas automanticamente, se forem de múltipla escolha.

Podem ser estabelecidas nove funcionalidades para este ambiente [11]:
 

1. Composição das disciplinas através de material, exercícios, provas, etc. (Processo de co-autoria.)
2. Estabelecimento de perfis para cada curso, definindo diferentes visões.
3. Cadastramento de usuários com diferentes perfis e níveis de acesso (instrutor, monitor, alunos).
4. Disponibilização do material.
5. Acompanhamento do andamento da disciplina.
6. Fornecimento de feed-back para alunos e professores.
7. Aplicação de provas e testes.
8. Correção das provas e cálculo das notas.
9. Disponibilização dos resultados para eventuais consultas.

4. Implementação por servlets e applets

As tarefas de um servlet podem ser divididas em três etapas [3]:

a- Requisição: recebe os parâmetros passados pelo cliente.
b- Execução: realiza o processamento, utilizando os dados recebidos na etapa anterior.
c- Resposta: gera o resultado num formato adequado (página HTML, imagem, etc).

1. Composição da disciplina

Na colaboração entre autores é necessário um servlet para controlar a concorrência de escrita, evitando que mais de um autor edite o curso na mesma granularidade ao mesmo tempo. Por granularidade, entendemos uma página, um capítulo, ou outra segmentação qualquer definida pelo autor no momento da escrita. Dividimos esse processo em dois servlets, descritos a seguir:

Servlet para a requisição do material a ser editado:

a- Requisição: é passada a identificação do autor, a parte do material a ser editada e a visão que ele deseja (i.e., se quer ver sua parte isolada, dentro do contexto geral, só as modificações recentes, etc).
b- Execução: autentica o usuário e verifica se o material está disponível (i.e., se outro autor não o está editando).
c- Resposta: gera o material com a visão escolhida e um applet com ferramentas de edição (ou mensagem de erro, em caso de usuário não autorizado ou material não disponível para edição).

a- Requisição: recebe a identificação do autor, a hora atual, o conteúdo modificado e o escopo a ser visualizado (só a sua parte, como o todo foi alterado, etc).
b- Execução: acrescenta a nova versão à base de dados.
c- Resposta: de acordo com o escopo requisitado gera uma página com o novo material, confirmando as alterações.

Nessa etapa são estabelecidos os perfis de apresentação do material. A idéia é que um usuário especial (por exemplo o coordenador de graduação de Engenharia Elétrica) selecione dentro do material criado na etapa anterior os tópicos que seriam utilizados dentro do perfil que ele estabelece. O servlet para esta funcionalidade seria:

a- Requisição: recebe a identificação do usuário, os tópicos selecionados e o curso (perfil) a que eles se aplicam.
b- Execução: acrescenta esse perfil à base de dados (desde que o usuário seja autorizado para tal).
c- Resposta: o curso sob medida (com os tópicos selecionados).

3. Cadastro de usuários

Essa etapa é semelhante à anterior do ponto de vista do servlet, que também fará apenas o armazenamento  na base de dados da informação passada pelo usuário.

a- Requisição: recebe os dados do usuário e o perfil no qual ele se encaixa (por exemplo, em que curso universitário ele está matriculado).
b- Execução: armazena esse usuário na  base de dados.
c- Resposta: mensagem indicando o sucesso ou não da operação.

Nessa etapa o aluno visualiza o curso segundo o seu perfil.

a- Requisição: recebe a identificação do usuário.
b- Execução: verifica na base de dados o perfil daquele usuário e verifica se o curso está disponível para ele (i.e., se o tempo do curso não foi expirado e se o aluno de fato está matriculado).
c- Resposta: o curso sob medida para o perfil do aluno (ou mensagem de erro).

5. Acompanhamento do curso

Dividimos o acompanhamento do curso segundo o ponto de vista do aluno e o do professor. Para o aluno, o acompanhamento do curso significa apenas saber que partes do curso ele já leu, que exercícios foram feitos, etc. Para o professor, o acompanhamento é mais abrangente, e ele pode acompanhar o que cada aluno já leu, tempo gasto na leitura, etc.

O servlet que implementaria o acompanhamento do ponto de vista do aluno seria:

a- Requisição: recebe a identificação do aluno.
b- Execução: consulta suas informações na base de dados (como comentado no item anterior, estas informações seriam enviadas por um applet enviado junto com o material do curso).
c- Resposta: informações sobre o que já foi lido, etc.

a- Requisição: identificação do aluno ou grupo que se deseja monitorar.
b- Execução: consulta na base de dados.
c- Resposta: informações sobre o que já foi lido pelo aluno ou grupo, tempo gasto, etc.

De certa maneira, parte do feed-back está embutido no item anterior (o acompanhamento do curso é uma forma de feed-back). A outra parte do que entendemos como feed-back pode ser realizada por meio de ferramentas de comunicação já existentes, não havendo a necessidade de implementação específica para este ambiente.

7. Disponibilização da prova

Nesta etapa o aluno recebe e realiza a prova. Dividimos em duas sub-etapas: requisição da prova e conclusão da prova.

Servlet para a requisição da prova:

a- Requisição: identificação do aluno e qual prova vai realizar.
b- Execução: consulta na base de dados para estabelecer o perfil do aluno e verificar a prova a ser enviada. É preciso verificar também se o aluno já realizou a prova antes. Marca a hora em que a prova foi enviada.
c- Resposta: a prova personalizada.

a- Requisição: respostas das questões e hora de término da prova.
b- Execução: envia respostas para o professor (por e-mail por exemplo) ou as armazena numa base de dados para futura correção pelo professor e contabiliza o tempo gasto na realização da prova.
c- Resposta: mensagem confirmando a recepção da prova e tempo gasto em sua realização.

8. Correção

No caso de prova de múltipla escolha,  a correção seria automática, realizada pelo servlet:

a- Requisição: respostas das questões e hora de término da prova.
b- Execução: correção, cálculo da nota, armazenagem do resultado na base de dados.
c- Resposta: confirmação de recepção, gabarito e nota.

9. Disponibilização dos resultados

Um simples servlet de acesso a base de dados em conjunto com um applet gráfico para a visualização das notas implementariam esta funcionalidade.

5. Conclusão

Mecanismos como CGI, applets, servlets e outros têm impulsionado o desenvolvimento e crescimento da WWW, fornecendo a ela as funcionalidades de todo tipo de aplicação. Com a combinação das diversas técnicas de programação na Web, há poucas coisas que um Web site não pode fazer!

6. Referências