next_inactive up previous


Trabalho de Formatura
Sistema de Controle de Alunos da CPG1

aluno: Rodrigo Moreira Barbosa
barbosa@linux.ime.usp.br


orientador: Marcelo Finger
mfinger@ime.usp.br

9. Dezembro 2002
Versão 1.0

Resumo:

Este é o trabalho final que explica o meu projeto de formatura: O que foi realizado, o que foi aprendido, o que falta realizar, bem como as dificuldades encontradas.


Sumário

Objetivos

O projeto consistiu no desenvolvimento de um banco de dados para a Comissão de Pós-Graduação (CPG) do IME. A CPG, no exercício de suas atividades, utiliza atualmente os dados corporativos da USP disponibilizados através do sistema Fênix (sistema de controle da pós-graduação da USP). Entretanto, o Fênix apresenta uma série de deficiências: Como exemplo, pode-se tomar a ausência de um controle com aspecto temporal dos alunos. Com o Fênix, não é possível, por exemplo, fazer a verificação automática de alunos em dia com os testes preliminares, de qualificação e de língua. Da mesma forma, o Fênix não possibilita a indicação de alunos que estejam em situação propícia ao desligamento do curso por falta de cumprimento às regras do mestrado ou doutorado de cada curso. Um ponto interessante é que boa parte desses dados estão disponíveis na base de dados corporativos da USP; só não são disponibilizados de forma automática pelo Fênix devido à especificidade de regras de cada unidade.

Diante dessa constatação, fica evidente que o primeiro passo na criação de um banco de dados para a CPG dependeria da disponibilização dos dados do Fênix. Após consultas ao Departamento de Informática da USP (DI), soubemos da possibilidade de um replicação local dos dados do Fênix, sem possibilidade de envio de dados, só de recebimento. Ou seja, um espelhamento.

Tomamos a decisão de priorizar a replicação dos dados do Fênix, para, posteriormente, verificar a necessidade da criação de tabelas com dados locais para complementação de funcionalidades.

Determinamos, então, quatro pontos primordiais ao nosso projeto:

  1. Acesso aos dados do Fênix
  2. Máquina
  3. Prototipação para uma maior interação com os usuários
  4. Facilidade de manutenção

Decisões de Projeto

Desde o princípio, o prof. Marcelo Finger traçou a diretriz de utilização de software livre. A partir dessa premissa, optou-se por um servidor Linux executando um Sistema Gerenciador de Banco de Dados (SGBD) livre. O primeiro nome de SGBD pensando foi o do PostgreSQL. O PostgreSQl é um SGBD relacional/ orientado a objeto extremamente sofisticado. É considerado mundialmente como o melhor banco de dados opensource disponível, possibilitando o uso de store procedures, triggers, transações e consultas com subselects. Entretanto, logo descartamos essa aparente promissora oportunidade depois de averiguarmos que o SGBD utilizado pela USP no armazenamento dos dados corporativos é o Sybase Adaptative Server Anywhere - um poderoso SGBD comercial comparável ao Oracle e ao SQL Server. A replicação dos dados do Sybase para o PostgreSQL seria um processo extremente complicado e sem funcionamento garantido, devido ao evidente desinteresse de empresas como a Sybase de fazer com que seus produtos integrem-se com software livre. Nossa certeza pelo descarte do PostgreSQL aconteceu após a descoberta de que o Sybase Adaptative Enterprise 11.9.2 para Linux é livre 2 para desenvolvimento. A única restrição comercial estaria relacionada ao número de conexões de clientes Sybase acessando o SGBD. Todavia, não fizemos uso desses clientes, optando por acesso via JDBC - vide 3.1.

Outras importantes decisões de projeto foram as determinações de que o sistema deveria ser voltado à Web além de orientado a objetos. A opção pela Web garante uma maior flexibilidade, já que se poderia rodar o sistema de qualquer máquina com acesso à rede e com algum browser instalado. A orientação a objetos garante uma manuntenção muito mais fácil.

Arquitetura e Ferramentas Utilizadas

Sistema

Por ser um sistema orientado a objetos com interface gráfica, a escolha por uma arquitetura Model-View-Controller - MVC - foi bastante natural.

O MVC é um arcabouço - framework - muito popular no desenvolvimento de sistemas. Ele divide a aplicação em três camadas distinas: modelo, visão e controle.

Nessa arquitetura, ainda encaixam-se duas subcamadas:

Figura 1: Arquitetura do Sistema
\includegraphics[scale=0.7]{arquitetura.eps}

Servidor de Dados

As tecnologias utilizadas na criação e configuração do servidor de dados foram as seguintes:

Histórico e Dificuldades Encontradas

Foram muitas as dificuldades encontradas no projeto. Além das dificuldades técnicas inerentes à criação de um banco de dados e à implementação de um sistema computadorizado, também esbarramos em aspectos burocráticos para o acesso aos dados do Fênix. Se analisada friamente, a burocracia é perfeitamente cabível frente aos cuidados necessários a dados corporativos. Questões tais como quem fará a replicação, quem ficará responsável pelo banco de dados, endereço da máquina que manterá a base replicada são primordiais e a burocracia da USP exige que elas sejam respondidas claramente para que a segurança dos dados seja preservada. Nesta seção abordaremos o histórico da criação do nosso servido de dados, bem como detalhes de todas as dificuldades encontradas.

Aspectos Burocráticos para a Replicação de Dados

Determinada a necessidade da replicação dos dados do Fênix, o primeiro passo foi contatar o Departamento de Informática da USP - DI - para o preenchimento dos requisitos burocráticos. O professor Marcelo Finger realizou o primeiro contato com o professor Natal, responsável pelo DI. O professor Natal instruiu-nos a requisitar à CPG o preenchimento de um pedido formal para o acesso aos dados corporativos. Transcrorrido aproximadamente um mês, recebemos a documentação com as instruções técnicas para o processo de replicação, bem como toda documentação do banco de dados corporativos.

Alocação de Máquina para o Servidor Local

Recebida a documentação do DI, o próximo passo foi a alocação de uma máquina a ser utilizada como servidor. Tal tarefa foi realizada pelo professor Marcelo Finger, que designou uma máquina que já havia sido requisitada para projetos seus. Mais uma vez, esbarramos em aspectos burocráticos, esperando a chegada da máquina, cuja compra é realizada segundo regras rigorosas, que acabam por atrasar todo o processo. De posse da máquina, iniciamos o processo de instalação do Linux.

Preparação para a Instalação do Linux

Por ter de basear um SGBD, alguns cuidados tiveram que ser tomados para uma instalação mais confiável do Linux. A máquina determinada para ser o servidor local possuía dois HDs de 40 Gb. Separamos o primeiro HD para a instalação do Linux e o segundo para o banco de dados, entregando-o ao gerenciamento do SGBD, ou seja, acesso a raw device, o que garante um melhor desempenho no acesso aos dados. O HD do Linux foi dividido em 5 partições: 1 Gb para a raiz (/), 1 Gb para arquivos temporários (/tmp), 2 Gb para swap, 0,5 Gb para arquivos voláteis (/var), 53 Gb para arquivos de de programas (/usr) e restante para arquivos do usuário (/home). Essa divisão, garante um discreto aumento na confiabilidade do servidor, na medida em que uma falha do sistema de arquivos em uma dada partição, não afeta as demais. O HD do banco de dados foi dividido em 12 partições: 4 partições de 1 Gb para o próprio SGBD (banco de dados mestre, banco de dados de store procedures do sistema, banco de dados de auditoria, banco de dados para two-phase commit), 2 partições de 2 Gb para log do BD, 4 partições de 2 Gb para o BD, uma partição de 2 Gb de temp disk, ou seja, uma partição de arquivos temporários, uma partição com o espaço restante para futuros banco de dados.

Colocação do Servidor em Rede

A colocação do servidor em rede ocorreu sem maiores transtornos. A dificuldade maior talvez tenha sido descobrir qual o modelo de placa de rede onboard ele utiliza, para depois poder instalar no kernel os módulos adequados.

Configuração do Linux

No decorrer da configuração do Debian GNU/Linux 3.0, vários problemas de foram enfrentados devido ao fato de o micro servidor ser um computador novo cujo hardware não era totalmente suportado pela distribuição:

Instalação do Sybase Adaptative Server Enterprise

A instalação do Sybase Adaptative Server Enterprise também trouxe consigo muitos percauços.

Para começar, a versão disponível para download é dividida em pacotes RPM (pacotes RedHat). Como a distribuição do nosso servidor é Debian, precisei tratar todas dependências de pacotes manualmente. Feita a instalação dos pacotes de dependências, fiz a instalação pelo aplicativo rpm ignorando as dependências, visto que ele não enxerga os pacotes Debian instalados.

Feita a instalação do Sybase, foi feita a execução do aplicativo que constrói o servidor de dados. A execução desse aplicativo falhou nas primeiras vezes e analisando as mensagens do arquivo de log, tive a impressão de que havia um problema de incompatibilidade do SGBD com o kernel. Após infrutíferas tentativas de solução, finalmente descobri que o problema encontrava-se na configuração do arquivo /etc/hosts que associa endereços na rede a nomes de máquinas. Nesse arquivo, não havia feito o registro do nome da máquina (tolkien) como localhost.

Realizados esses passos, foi feita a alteração dos scripts de inicialização do Sybase, visto que eles foram desenvolvidos para Solaris e não para Linux.

Configuração do Gateway da Rede do CEC

Pelo fato de se encontrar na rede do CEC (Centro de Ensino de Computação), nosso servidor não dispõe de um endereço IP verdadeiro na Internet, mas sim de um endereço IP falso (interno à rede CEC). A única máquina que possui IP verdadeiro é o gateway da rede. À primeira vista, isso poderia constituir um problema, visto que um dos pré-requisitos impostos pelo DI para replicação de dados é que o servidor de dados local possua um endereço IP na Internet. Contornamos essa dificuldade mediante um artifício bem simples: Instalamos no gateway do CEC o aplicativo rinetd que redireciona conexões em uma dada porta para alguma outra máquina na rede. Assim sendo, configuramô-lo para redirecionar as conexões na porta 4100 para a porta 4100 de nosso servidor; também fizemos o redirecionamento da porta 5000 para a porta 22 do no servidor, para poder operá-lo remotamente via SSH. A configuração da porta 4100 foi feita pelo fato de essa ser a porta default do Sybase.

Replicação dos Dados

Construído o servidor, submeti para execução um script que cria o banco de dados, a partição de log, a partição de arquivos temporários, além do usuário administrador do banco de dados (dbmaint) e do usuário simples com o qual o sistema da CPG acessará o BD.

Feito tudo isso, o DI enviou os scripts de replicação que foram aplicados ao BD com senha de administrador. Do lado do DI, roda o servidor de replicação de dados, o Sybase Replication Server, que atualiza diversas bases da dados replicados através de mecanismos semelhantes a triggers, espelhando todas as operações de atualização que ocorrem no BD principal. O IME recebe os dados através de uma conexão (rota) entre esse servidor do DI - servidor primário - e o nosso servidor - servidor de replicação.

No Servidor de Replicação é criado a replication_definition, uma para cada tabela que será replicada. As tabelas que deverão receber os dados, devem assinar essas replications definitions através das subscriptions. Tudo funciona como uma editora que vende assinaturas: A editora anuncia que tem revistas e oferece a assinatura, e o cliente de acordo com suas necessidades, faz a assinutara somente dos exemplares que lhe interessam.

Esta fase também foi permeada de dificuldades dada a minha inexperiência com administração de banco de dados. Ao lado disso, vem a dificuldade do próprio Sybase, um SGBD que, embora muito poderoso, possui uma complexidade bem alta, agravada por seus comandos confusos e pouco mnemônicos, sua interface pobre e pouco elucidativa, além de uma documentação extensa e pouco prática. Uma parte dessas dificuldades foi contornada com a instalação do Like Sybase Central, um aplicativo, feito por terceiros, para administração do Sybase. Descobri-o através de consultas feitas a amigos que me indicaram sua página no freshmeat.net.

Experiência com Servlets Java, JDBC, JSP e HTML

Terminadas todas as etapas acima, iniciei o estudo das tecnlogias de Servlets Java, JDBC, JSP e HTML. Criei uma página de testes que acessa o banco de dados e realiza uma consulta simples no Banco de Dados. Para tal, tive que baixar o driver JDBC para SYBASE, o jConnect 5.5. Para utilizá-lo, também tive que aplicar algumas store procedures fornecidas, que disponibilizam ao driver informações sobre metadados.

Disciplinas Importantes

Foram muitas as disciplinas que contribuíram à realização do projeto. Dentre as mais importantes, podemos citar:

Conclusão e Tarefas a Realizar

O projeto de formatura foi uma atividade que só acrescentou pontos positivos à minha formação acadêmica. Embora não tenha sido completado em toda a sua abrangência, por dificuldades já citadas, permitiu que certas carências do curso de bacharelado em Ciência da Computação fossem suplantadas. Também serviu para mostrar na prática, alguns pontos defendidos apaixonadamente por alguns professores do IME, tais como a aplicabilidade da teoria à prática, bem como a adequação do Linux a atividades críticas, que podem ser até atividades comerciais. Explicarei melhor esses pontos.

É inegável que o nosso bacharelado é de um nível excelente, igualado, se é que pode ser considerado igualado, por pouquíssimos cursos no país. Conquanto esteja em um patamar privilegiado, vários fatores poderiam ser melhorados. A base teórica que nos é apresentada é muito forte e realmente tem muita utilidade prática. Um defeito no curso, no entanto, é a ausência de atividades mais práticas que nos possam mostrar o devido valor da teoria. É certo que aplicamos a teoria em inúmeros e infindáveis EPs. Embora permitam a melhor fixação do conteúdo aprendido, esses exercícios são, muitas vezes, tão abstratos, quando não mais abstratos, do que a teoria. Isso de certa forma acaba por desmotivar o aluno, que tem a impressão de não estar aprendendo nada de útil. Nesse instante, meu projeto de formatura serviu para mostrar-me o quão errado é esse raciocínio. Enfrentar todas a dificuldades primeiro burocráticas, depois técnicas e pessoais que envolvem o desenvolvimento de um sistema computadorizado, mostraram-me a utilidade de matérias como engenharia de software, por exemplo. Até então, achava que essa disciplina não passava de um festival de obviedades professadas por autores que nunca haviam realmente feito nada na prática.

Ainda nessa mesma linha, sempre ouvimos de nossos professores as maravilhas que cercam o Linux: Estabilidade, confiabilidade, etc. Até então, não tinha uma real noção do que isso fosse. Mas ao instalar o SO e verificar a disponibilidade do sistema, bem como sua estabilidade, tive noção do quão bom é se poder confiar no SO que roda sob o SGBD. Além do mais, pude constatar o tão alardeado suporte que a comunidade Linux oferece. Realmente, problemas bem complicados, como os citados, foram resolvidos facilmente com dicas obtidas junto a essa comunidades. Em contrapartida, pude constatar algo que é um tanto quanto ``escondido'', por assim dizer, pelos amantes do Linux: De fato, o Linux é realmente muito pobre no que diz respeito à interação homem/computador e, nesse ponto, perde feio para sistemas como o Windows. Nessa área, muito ainda tem que ser feito, para que ele possa tornar-se um sistema popular entre usuário leigos.

Quanto à instalação do SGBD Sybase, pude também constatar o quão difícil essa tarefa pode tornar-se no Linux. Pegar um Sybase instalado e criar nele algumas poucas store procedures, como aconteceu na disciplina de laboratório de banco de dados, é algo que acaba por ocultar a verdadeira complexidade de se criar um banco de dados e de o colocar em funcionamento. Essa parte prática faltou nessa disciplina, que deveria enfocá-la mais fortemente, dado seu título de ``laboratório''.

Explicadas as minhas dificuldades, justifico o meu atraso no projeto. Pretendo agora em dezembro, começar a implementação do sistema voltado à Web, mesmo porque meu projeto de formatura está dentro de um projeto de iniciação científica com bolsa do CNPQ. Já agendei entrevistas com o pessoal da CPG e já realizei estudos e implementações de teste utilizando Servlets, JDBC e JSP.

Concluindo, posso afirmar que esse projeto permitiu-me aprender muito. Talvez, esse tenha sido o ano em que mais aprendi no bacharelado. Na minha opinião, o projeto cumpriu seu intuito e complementou de forma inquestionável a minha formação. Só quero deixar aqui minha crítica construtiva, para que o curso de computação volte-se um pouco mais a áreas mais práticas e áreas de tecnologia, para que haja uma menor dissonância cognitiva no aluno, ou seja, para que ele sinta que está aprendendo algo de útil e não sinta o arrependimento, que observo em alguns, pela escolha de um curso que aparenta ser estritamente teórico e desfocado da realidade, o que, na minha opinião, não acontece de forma alguma.

Referências Bibliográficas Utilizadas no Projeto

About this document ...

Trabalho de Formatura
Sistema de Controle de Alunos da CPG1

This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.48)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -split=0 trabalho_de_formatura.tex

The translation was initiated by Rodrigo Moreira Barbosa on 2002-12-09


Footnotes

... CPG1
Projeto com bolsa de IC do CNPQ
... livre2
Vide lincença de uso do Adaptive Server Enterprise for Linux versão 11.9.2.

next_inactive up previous
Rodrigo Moreira Barbosa 2002-12-09