O Jefras é um
sistema que visa facilitar o processo de compra de livros para a
biblioteca do IME. Atualmente, esse processo é um tanto quanto
burocrático. Os professores responsáveis pela lista
de compras de livros se vêem envoltos por uma papelada que
em nada facilita o processo de decisão sobre quais livros
devem ou não ser comprados. São tantos papéis,
que não é possível ter controle sobre qual
livro foi pedido há muitos anos e qual foi pedido recentemente.
Pior, muitas vezes, aquele livro pedido há mais tempo nem
é mais de interesse e, ainda assim, está na lista
de livros a serem comprados.
O processo de compras de livros atualmente O sistema Jefras |
O objetivo do sistema Jefras
é facilitar o processo de compras de livros atualmente. Ele
será responsável por registrar os pedidos de livros
de cada professor, registrar votos de alunos em livros e gerar uma
lista de livros automaticamente, baseado em alguns critérios: - a importância (prioridade) do livro para o professor que fez a sugestão; - o número de votos não docentes; - o preço do livro. Utilizando esses critérios e o valor da verba disponível para a compra, a lista de compras será gerada automaticamente. A importância de cada um dos critérios na geração da lista é configurada por um administrador do sistema. A lista de compras gerada pode ser alterada pelo administrador, que adiciona e remove livros. O sistema controla quando a lista entrou em compras, quando os livros chegaram à biblioteca, e, se por algum motivo, como indisponibilidade, quais livros não foram entregues. Os usuários são notificados por e-mail a respeito das várias etapas do processo. Por exemplo, um usuário que votou em um livro é notificado quando ele foi enviado para compra, sabe a data de previsão de chegada, é notificado caso ele esteja esgotado e etc. O sistema faz também a busca automática de preços dos livros no site da Livraria Cultura. |
Por ser um projeto do curso de XP, o
Jefras teve as suas funcionalidades escritas em story cards. Para
quem não está familiarizado com XP (eXtremme Programming),
story cards são cartões de papelão nos quais
os usuários escrevem “histórias”, descrevendo
como vão utilizar o sistema. Cada “história”
representa uma funcionalidade a ser adicionada ao sistema. Para
visualizar os cartões que descrevem as funcionalidades do
Jefras, visite a página de XP de 2002.
Também é possível dividir as funcionalidades do Jefras em categorias de usuário. Para cada tipo de usuário, existe um conjunto de funcionalidades disponíveis. Seguem, nos próximos tópicos, as funcionalidades do sistema classificadas dessa forma. Convidado Professor Administrador |
Para detalharmos mais facilmente o que
fizemos, vamos primeiramente descrever como era o sistema Jefras
no começo do ano. O Jefras originalmente utilizava o arcabouço Prevayler[1] para fazer persistência de dados. Essa ferramenta realiza a persistência dos objetos Java de forma "transparente" para o programador, sem o uso de um banco de dados, registrando seriação desses objetos em arquivos no disco. Para utilizar o Prevayler, você deve implementar uma classe (PrevalentSystem), que será o seu banco. Ela deve conter referências para todos os objetos que devem ser persistidos, de modo que, quando ela for seriada em um arquivo, todas as referências também o serão. Sempre que for necessário alterar os dados persistidos, é preciso implementar uma interface Command: public interface Command { public Serializable execute(PrevalentSystem system) throws Exception; } No método execute, é recebida uma referência para PrevalentSystem, e é nesse método que deve ser alterado o banco. Essa forma de encapsular um código qualquer em um objeto é uma implementação do Padrão Command (233)[2]. O Prevayler grava os dados do PrevalentSystem em um certo intervalo de tempo. E, sempre que um comando tiver que ser executado, ele é seriado em um arquivo de log do Prevayler. Desse modo, caso o sistema saia do ar por algum motivo, o Prevayler restaura o PrevalentSystem que foi seriado em um arquivo, e executa cada comando que foi gravado no log desde a última vez que o objeto banco foi salvo. Um comando no Prevayler é uma transação. Caso se deseje colocar vários comandos dentro de uma transação, não seria possível. A única solução seria criar um comando que executasse o mesmo que esses comandos executam. No Jefras, dados do banco são manipulados e alterados o tempo todo. Praticamente qualquer coisa que o usuário fizer na tela resulta em alterações no banco. Isso significa que quase toda a lógica do Jefras teria que ser implementada em comandos. E era assim que estava a arquitetura de classes do Jefras: uma arquitetura monolítica, composta de mais de 20 classes comandos, além de uma classe que seria o PrevalentSystem. Essa classe (que persistia todos os livros registrados no sistema, todos os professores, e etc) era um tanto extensa. Além de métodos relacionados à persistência de objetos, existiam métodos para ordenação de livros, que nada tinham a ver com a função da classe: referenciar objetos a serem persistidos. Além dessas classes relativas à persistência, havia as classes das entidades que tinham que ser persistidas no sistema: Book, Professor, Guest, Admin, Classification e etc. Cada uma delas possuía um conjunto de exceções internas. Havia uma exceção para cada campo que fosse inválido dessa classe. Por exemplo, para Book, tínhamos: Book.InvalidISSNException, Book.InvalidTitleException, Book.InvalidPublisherException, Book.InvalidEditionException, e assim por diante. Os construtores faziam a validação de cada atributo, e lançavam mais de cinco exceções. Algumas classes possuíam métodos estáticos que validavam outras classes. Por exemplo, Book tinha um método validateProfessor, que o construtor de Professor invoca para fazer validação. Os comandos eram invocados diretamente das páginas jsp. Nessas páginas, exceções como as de validação eram tratadas. Em alguns pontos, o catch era vazio, em outros, a exceção era impressa na tela. Existia também um pacote de testes, que possuía testes apenas para verificar se o construtor de cada entidade lançava cada uma daquelas exceções corretamente. Havia também uma servlet (e algumas classes auxiliares), denominada JefrasServlet, que direcionava o browser do usuário para a página correta, de acordo com o endereço pedido. Essa servlet era também responsável por inicializar o Prevayler. Além disso tudo, existiam classes que geravam a lista de compras. |
No início do ano, tomamos familiaridade
com a regra do negócio que o sistema se propõe a resolver.
Estudamos como o sistema tinha sido desenvolvido até então,
e tomamos conhecimento de quais ferramentas tinham sido utilizadas
para isso.
Primeira Refatoração Transição para J2EE C1: persiste P
na tabela “professor”. Se desligarmos o sistema após essas
operações, no momento de colocarmos o sistema no ar
existirão duas cópias do professor P
e duas do livro B. Veja por quê: cada registro
de um comando seriado é uma “foto” daquele comando
e dos objetos para os quais referencia. Primeiramente, o comando
C1 é desseriado. É criada, então,
uma instância do comando C1 na memória,
que contém uma referência para um objeto professor
P’, que também foi carregada na memória
utilizando a versão seriada do professor P.
Esse comando é executado, o que adiciona o professor P’
na tabela “professor”. O mesmo é feito com C2.
É criada uma instância de C2 na memória,
baseada na “foto” tirada de C2 anteriormente,
que está registrada no log. Isso leva à criação
de um livro B’, com os mesmos atributos e
dados que tinha o livro B, antes de o sistema ser
desligado. Em seguida, é criada uma instância do comando
C3 na memória, apontando para uma instância
de um voto V’ que também é
criado, contendo os dados do voto V original. Esse,
por sua vez, tem uma referência ao professor P
e ao livro B, que também são instanciados
na memória, criando um professor P’’
e um livro B’’ na memória, com
os mesmos dados que havia no professor P e no livro
B. Validação de Dados A camada Web |
O modo em que desenvolvemos o Jefras
foi um pouco caótico. Fazendo estágio e faculdade,
não tínhamos tanto tempo quanto gostaríamos.
Tínhamos que improvisar. Trabalhamos separadamente em casa,
à noite nos dias de semana. E, quando tínhamos alguma
janela no horário da faculdade, programávamos em dupla,
como é feito em XP. Mesmo quando desenvolvíamos o
sistema em separado, sempre tomamos juntos as decisões, expondo
abertamente as nossas idéias. Utilizamos testes durante o desenvolvimento inteiro, porque achamos que é muito importante validar a correção do sistema. No decorrer do processo, foram feitas algumas reuniões com o Prof. Dr. Fábio Kon e os clientes da biblioteca. Mas, infelizmente foram poucas as reuniões, devido à baixa disponibilidade do nosso horário. |
A arquitetura principal do Jefras é
uma típica arquitetura baseada na plataforma J2EE:
• O cliente interage com o sistema utilizando
o browser. Tipicamente, não haverá processamento no
lado cliente, a menos que a aplicação seja composta
por applets. Como no Jefras não existem applets, a máquina
cliente não executa nenhum processamento. Padrões utilizados Seguem os principais padrões que utilizamos para desenvolver o Jefras. EJBHomeFactory[5] ValidationStrategy[3] TransferObject[6] Model – View - Controller |
As principais tecnologias e ferramentas que utilizamos
para desenvolver o sistema Jefras foram: |
Apesar de o ano estar acabando, pretendemos
dar continuidade ao projeto. Muito foi feito e o sistema se
apresenta pronto para ser colocado em produção. Contudo,
faltam muitas coisas a fazer, como desenvolver uma documentação
para o usuário. |
| 1 - Prevayler - www.prevayler.org |
