Felipe Pierre Conter* Fabiana Frata Furlan Peres*
* Universidade Estadual do Oeste do Paraná (UNIOESTE).
Utilização do framework “Ruby On Rails” no desenvolvimento de um módulo web para
sistema de biblioteca
Use of “Ruby On Rails” framework in the development of a web module for library system
Resumo
O framework Ruby on Rails tem ganhado destaque como ferramenta para desenvol-vimento web. Ele promete ser mais produtivo que outras abordagens. O seguinte trabalho, ainda em desenvolvimento, propõe utilizar o framework para o desenvolvi-mento de um módulo web para o Sistema de Biblioteca da UNIOESTE. Essa aplicação terá um banco de dados próprio, porém também irá manipular informações do banco de dados já em utilização do sistema atual da biblioteca. Isso nos permite explorar e analisar duas abordagens com o framework: o desenvolvimento a partir de um banco de dados vazio, que irá evoluir juntamente com a aplicação e o acesso a um banco de dados já existente. Pretende-se encontrar os pontos fracos e fortes do desenvolvimento em ambas as abordagens.
Palavras-chave: Engenharia de software. Web. Frameworks. Desenvolvimento ágil.
Abstract
The Ruby on Rails framework has been in evidence as a web development tool. It promises to be more productive than other approaches. The following work, still under development, proposes to use the framework for the development of a web module for the Library System at the State University West of Paraná (UNIOESTE). This application will have its own database, but it will also use information from the database in use by the current library system. This allows us to explore and analyze two approaches with the framework: the development from an empty data-base, which will evolve together with the application and access to an already existing database. This work intends to find out the weak and strong points of the development in both approaches.
Keywords: Software engineering. Web. Frameworks. Agile development.
1 Introdução
O framework Ruby on Rails, também chamado de Rails ou RoR, propõe maior facilidade e rapidez no desenvolvimento e manutenção de aplicações web. Outra importante característica deste framework é que ele disponibiliza suporte às novas tecnologias exis-tentes na rede, como Ajax e interfaces RESTful, favo-recendo sua popularização e destaque como uma das principais ferramentas de desenvolvimento web. Exis-te uma gama de sisExis-temas altamenExis-te complexos e fun-cionais que necessitam de manutenção evolutiva que podem ser feitas utilizando tecnologias mais fáceis de se utilizar (FULTON, 2005).
Segundo Rangel, um desenvolvedor que utiliza este framework, com Ruby on Rails, a produtividade é mai-or pmai-orque se escreve menos códigos, mais eficientes. Afirma ainda que um projeto que em Java levaria 120 dias para ser produzido, com Rails é reduzido para 5 dias (SPOSITO, 2006).
Neste contexto, este estudo propõe o desenvolvi-mento de um módulo web para um sistema de biblio-teca, estendendo o acesso a informações sobre a dis-ponibilidade do acervo, que poderão ser acessadas por meio de um website.
Desta forma é possível analisar e identificar pontos fortes e fracos no desenvolvimento com essa ferramenta, com enfoque especial no acesso aos bancos de dados.
2 Fundamentação Teórica
2.1 Desenvolvimento Web
A Internet evoluiu de uma rede de troca de traba-lhos acadêmicos a uma rede mundial que conecta qual-quer parte do mundo. Quando os aplicativos web come-çaram a ser desenvolvidos, existiam muitas limitações que foram sendo resolvidas. O grande diferencial da web atual, consiste na dinamicidade de aplicações, que es-tão em um patamar talvez até mais avançado que as aplicações desktop (ASLESON; SCHUTTA 2006).
Há alguns anos, se uma aplicação cliente/servidor em desktop necessitasse de atualização, seria neces-sário atualizar cliente por cliente. Havendo muita difi-culdade na instalação e na distribuição do software.
Com os softwares na internet, em forma de sites, não é mais necessário a instalação na máquina clien-te. Porém, ainda existiam alguns problemas relacio-nados com a “pobre” interatividade com o usuário. Muitos elementos de interatividade das aplicações
desktop tiveram que ser sacrificados para que fossem formatados como código HTML.
A cada interação do usuário com o servidor, era preciso que o cliente aguardasse a atualização da página por inteiro. O tempo “perdido” na atualização e o tráfego desnecessário gerado pela retransmissão de elementos requisitados eram as principais barreiras que impediam o avanço das aplicações web. Muitas abordagens tentaram modificar estes entraves, como a CGI1, os Applets e Servlets da Sun2, o JavaScript, o Flash da Macromedia, dentre outras. Porém, poucas conseguiram se manter até hoje (ASLESON; SCHUTTA 2006).
A necessidade por páginas cada vez mais dinâmi-cas fez com que várias tecnologias surgissem prome-tendo serem mais produtivas e modernas. Dentre es-sas tecnologias, os frameworks de aplicações web surgiram para suportar o desenvolvimento de websites dinâmicos, aplicações web e web services (interfaces para interação de aplicação a aplicação na web, intermediada normalmente por arquivos XML).
Um framework web elimina algumas dificuldades associadas com atividades comuns no desenvolvimen-to web, por exemplo, disponibilizando recursos para facilitar o acesso ao banco de dados, criação de
templates, controle de sessões e freqüentemente
pro-movem o reuso de código em sua aplicação.
2.2 O Framework Ruby on Rails
O Framework Ruby on Rails chamado simplesmen-te de Rails, torna mais fácil o desenvolvimento e ma-nutenção de aplicações web. Permite ao programador menor preocupação com a configuração e com a coe-são entre os elementos da aplicação, como comuni-cação entre as regras de negócio, o banco de dados e a página que irá para o browser do cliente. Assim o programador pode concentrar seu foco na aplicação em si (THOMAS et al., 2007).
Para Walton e Hibbs (2006) o Rails mantém a cur-va de aprendizado baixa, permitindo facilidade e rapi-dez no desenvolvimento no Rails. Criado em 2004 por David Heinemeier Hansson, um desenvolvedor da em-presa 37Signals3, o Rails surgiu como a base para o desenvolvimento de uma aplicação de controle de pro-jetos, ou seja, surgiu de um problema real na
37Signals. Foi escrito totalmente na linguagem Ruby,
sendo que a linguagem padrão de desenvolvimento no
framework também é o Ruby.
A seguir são apresentados alguns conceitos relaci-onados ao Rails:
- Convenção ao invés da configuração: Certos pa-drões de inferência entre os elementos da aplicação fazem que seja desnecessário fazer arquivos externos de configuração, como no Struts (CUNHA NETO, 2007), sendo necessário apenas definir as configurações que fogem do padrão.
- KISS: “Keep it simple, stupid”, ou na tradução, “deixe simples, estúpido” (CUNHA NETO, 2007). O conceito se resume em manter tudo simples de uma forma geral. Ou seja, não “reinventar a roda”. Dessa forma, é muito mais fácil identificar o que cada parte do código faz em específico.
- DRY: “Don`t repeat yourself”, ou na tradução, “não se repita”. Todo o conhecimento em um sistema deve ser expresso em apenas um lugar, evitando repetição de código. O Rails leva o programador a seguir esse conceito, sendo que mudanças futuras nos requisitos de um sistema acabam tendo impacto reduzido, pois o tempo gasto nessas mudanças é menor (THOMAS et al., 2007).
- Desenvolvimento Ágil: É mais importante satisfa-zer o cliente com a entrega mais rápida e contínua de software, de preferência numa escala de tempo pe-quena. Isso o encoraja a pedir mudanças no software e os problemas de identificação errônea de requisitos são identificados mais cedo. O desenvolvimento Ágil favorece “indivíduos e interações” sobre processos e ferramentas, “software funcionando” sobre documen-tação compreensiva, “colaboração do cliente” sobre negociação de contrato, e “responder a mudanças” sobre seguir um plano. O Rails é relacionado forte-mente com o desenvolvimento Ágil, pois a empresa onde o seu desenvolvimento se iniciou é adepta dessa abordagem (HIGHSMITH, 2001).
2.3 A Arquitetura MVC – Model, View e Controller
Em 1979, Trygve Reenskaug especificou uma nova arquitetura de desenvolvimento de aplicações interativas, chamada MVC. Nesta abordagem, uma aplicação é dividida em três tipos de componentes: models, views e controllers ou modelos, visões/interfaces e controladores (THOMAS et al., 2007).No Rails, as aplicações seguem a arquitetura MVC. Existe um lugar específico para cada parte de código desenvolvido. Devido ao princípio da convenção ao in-vés de configuração, o model, view e controller funcio-nam de maneira que tipicamente não é necessário definir as configurações de relacionamento entre eles. O Rails possui padrões inteligentes que fazem com que todos esses elementos se encaixem (THOMAS et al., 2007).
O model é responsável por manter o estado da apli-cação. O estado pode estar em transição, aguardando uma resposta do usuário ou de outras aplicações e pode ser permanente, sendo nesses casos armazenado fora da aplicação, normalmente em um banco de dados.
Apesar do foco do model ser nos dados, ele tam-bém força o cumprimento de todas as regras de negó-cio que se aplicam àqueles dados. Por exemplo, para excluir da aplicação os usuários cadastrados que não tenham emprestado nenhum livro de uma biblioteca em 5 anos, é responsabilidade do model forçar essa
1 (http://www.w3.org/CGI/)
2 (http://java.sun.com/developer/onlineTraining/new2java/programming/learn/apps.html). 3 Empresa de desenvolvimento e venda de serviços na web.
restrição. Isso mantém a integridade dos dados no banco, fazendo com que nenhuma outra parte da apli-cação invalide-os (THOMAS et al., 2007).
O conceito de model no Rails é desempenhado pelo
Active Record, um componente responsável pela
per-sistência (normalmente feita em um banco de dados). O Rails utiliza aqui o conceito de ORM -
“Object-relational mapping” ou mapeamento objeto-relacional.
Bibliotecas ORM mapeiam tabelas para classes, sen-do que as linhas dessa tabela armazenam os objetos dessa classe, com seus respectivos atributos e asso-ciações. O Active Record facilita a busca por uma in-formação no banco. A consulta é transparente, não sendo necessário descrever detalhes do código de acesso específico do banco de dados que se está uti-lizando. A aplicação fica desacoplada de um banco de dados específico, pois a lógica de acesso ao banco fica isolada da lógica de negócio.
Outra facilidade provida pelo ORM do Rails é o save. Quando se deseja salvar um objeto “livro” no banco, por exemplo, basta chamar livro.save e a persistência no ban-co de dados é realizada (THOMAS et al., 2007).
Em alguns momentos, os padrões do Active Record não são adequados ao desenvolvimento, como quan-do se lida com uma base de daquan-dos com um esquema legado (não compatível com a estrutura padrão do Rails). Nesses casos, o desenvolvimento com Rails pode se tornar um pouco mais custoso com relação ao tempo gasto no desenvolvimento. Nesse sentido, o acesso ao banco pode ser feito de maneira “manual”, ou seja, informando diretamente o SQL a ser executa-do. Outra alternativa mais inteligente, porém que de-mandaria um nível de conhecimento mais aprofundado sobre o framework, seria manipular as diretivas do
Active Record para que ele execute exatamente
aqui-lo que se deseja (MARSHALL; PYTEL; JON, 2007). O Rails não é uma “caixa fechada”. Todas as clas-ses e elementos do framework estão disponíveis e escritos em Ruby. Ao executar algo, o framework in-terpreta não somente o código do usuário, mas tam-bém o código das classes do framework. Caso o desenvolvedor deseje alterar o código do framework, as mudanças serão interpretadas corretamente na pró-xima execução.
O view gera a interface de usuário, normalmente baseada em dados do model. Por exemplo, deseja-se mostrar ao usuário uma lista de livros disponíveis para empréstimo no momento. A lista dos livros estará dis-ponível no model, porém é o view quem receberá es-ses dados e os formatará para mostrar ao usuário. Contudo, o view apenas é responsável por colocar a lista de livros em uma interface amigável, de preferên-cia no browser do usuário, depois o responsável por receber algum pedido de reserva do usuário por certo livro é o controller (THOMAS et al., 2007).
O controller faz o papel de administrar a execução da aplicação. É ele que recebe os pedidos e as entra-das de dados vinentra-das de fora da aplicação, incluindo os dados do browser e cliente, interage com o model e disponibiliza um determinado view para o usuário (THOMAS et al., 2007).
Seguindo o exemplo apresentado no item anterior, quando o usuário escolhe um livro para reserva, o
controller é quem recebe esse pedido. Ele “pede” o
livro para o model e depois invoca um view passando os dados do livro requisitado.
3 Materiais e Métodos
Foi desenvolvida uma aplicação CRUD4 em Rails com objetivo de realizar o controle de acesso dos usu-ários ao módulo. Estão ainda em desenvolvimento duas outras partes deste módulo: a primeira visa acessar um banco de dados já existente no sistema de contro-le de biblioteca da UNIOESTE com objetivo de consul-tar e realizar reservas ao acervo físico disponível; e a segunda tem por objetivo cadastrar e manipular o acervo digital da biblioteca.
O controle de acesso por usuários tem como objetivo restringir o acesso a algumas funcionalidades da aplicação web, disponíveis apenas para o adminis-trador da biblioteca, como o cadastro de usuários do módulo web. É também função desse módulo associ-ar reservas de livros aos usuários cadastrados no sis-tema atual da biblioteca.
Há um banco de dados próprio do sistema admi-nistrativo atual na biblioteca, no qual são registrados empréstimos de livros, nomes de usuários, entre ou-tros dados pertinentes ao funcionamento da bibliote-ca. De fato, este módulo web irá acessar o banco de dados, somente para realização de consultas no acer-vo sendo que as informações geradas pelo módulo são persistidas num banco de dados definido para este módulo. Dados de empréstimos continuarão sendo res-ponsabilidade do sistema de controle da biblioteca.
A funcionalidade de consulta on-line e reservas têm por objetivo aproximar o aluno da biblioteca, por meio de uma interface web. O usuário poderá saber se o livro que ele deseja emprestar está disponível ou não, quando estará disponível e poderá inclusive reservar um livro que se encontre disponível. O módulo de reservas somente estará disponível para usuários autenticados no sistema, com conta on-line devidamente relaciona-da a conta no sistema de controle de bibliotecas.
Dados sobre reservas serão armazenados no novo banco, podendo ser consultados pelo administrador. O sistema irá emitir um e-mail ao operador da bibliote-ca no surgimento de uma nova reserva, para que este efetue a mesma no sistema atual da biblioteca. Esta abordagem é adotada, num primeiro momento, com objetivo de manter a integridade da aplicação, deixan-do para que seja definideixan-do o serviço de comunicação entre a aplicação e o módulo web numa próxima iteração do desenvolvimento.
A terceira funcionalidade do módulo tem por objetivo disponibilizar o acervo digital da biblioteca. Existem muitos trabalhos de conclusão de curso, monografias e dissertações em formato digital tendo como suporte CD’s. Sendo mais conveniente o acesso direto aos documentos digitais pela web. Atualmente a UNIOESTE possui um sistema nesse modelo, porém voltado
nas para teses e dissertações dos cursos de pós-gra-duação/mestrado oferecidos pela universidade.
Para o desenvolvimento da parte de controle de acesso e cadastro ao acervo digital, foi possível utili-zar várias facilidades oferecidas pelo Rails, tornando o processo de integração da aplicação com o banco de dados e a interface, uma tarefa muito simples e trans-parente para o desenvolvedor.
No que diz respeito ao acervo físico, como os da-dos já se encontram cadastrada-dos em uma base de dados ativa, o acesso será de forma diferenciada, adap-tada ao esquema em que se encontram organizados os dados, sem tirar proveito de muitas das facilidades de mapeamento ao banco de dados do Rails.
4 Resultados
Como resultados parciais, é perceptível maior faci-lidade em desenvolver com o framework, principalmen-te nos módulos de controle de acesso do módulo web e cadastro e acesso ao acervo digital. Eles foram feitos independentes do sistema da biblioteca, dando maior flexibilidade e possibilitando ao framework lidar com ver-sões do esquema do banco e persistência de dados.
A única exceção diz respeito ao cadastro de usuá-rios, no qual o acesso ao banco de dados do sistema de bibliotecas se fez necessário para associar o login do usuário da rede com o código de usuário da biblio-teca. Assim, será possível direcionar corretamente as reservas de livros feitas pelo módulo web.
O desenvolvimento fugiu do padrão no momento em que se pensou no acesso a dados de livros e de em-préstimos. No desenvolvimento desse módulo que manipula uma estrutura de dados já existente, está sendo necessário definir de forma usual a estrutura para o funcionamento correto do módulo, não permi-tindo o uso de algumas praticidades.
Uma alternativa que está sendo estudada é a mani-pulação do Active Record, para adaptar os padrões de acesso a banco de dados para a realidade do esque-ma apresentado no banco de dados da aplicação já exis-tente na biblioteca. O Rails permite que o desenvolvedor modifique os padrões de acesso ao banco, definindo-os de acordo com o esquema utilizado em seu banco de dados (MARSHALL; PYTEL; JON, 2007).
Como resultados futuros é possível comparar o aces-so utilizando declarações SQL diretamente no código Ruby, com a modificação dos padrões do Active Record.
5 Discussão
O Rails cumpriu seu papel como framework de de-senvolvimento web muito bem referente ao desenvolvi-mento de um banco de dados vazio que evoluía junta-mente com a aplicação. O Rails leva o programador a uma abordagem de desenvolvimento Ágil, seguindo os princípi-os apresentadprincípi-os anteriormente, fazendo com que o pro-cesso de desenvolvimento responda mais rapidamente a mudanças e gere resultados mais cedo no processo.
Porém ao utilizar o framework sobre um banco de dados já existente, ou para migrar uma aplicação já
implantada para o framework, o trabalho gerado com configurações extras pode ofuscaR esse ganho de pro-dutividade e os princípios do desenvolvimento Ágil e da convenção sobre configuração. Depende da famili-aridade do desenvolvedor com o Active Record ou com o SQL do banco.
Em algumas situações, utilizar SQL pode ser mais fácil que customizar o Active Record, podendo ocorrer também casos onde a vantagem de se trabalhar com o Active Record compensa o tempo gasto na configu-ração do mesmo.
6 Conclusão
O Rails é um framework relativamente novo, porém mostrou destaque em torno dele. Para o desenvolvi-mento de um módulo web guiado pelos princípios Ágeis, sobre os quais o framework foi criado, ele é uma ótima ferramenta, demonstrando ser fator de peso para a pro-dutividade em projetos web.
O caso pode alterar quando se trata de acesso a banco de dados já existentes. Os padrões de desen-volvimento e mapeamento do Rails não foram projetados para este tipo de situação, apesar de o framework possibilitar esta alternativa, ela é mais cus-tosa em termos de tempo com a configuração do aces-so ao banco.
Outros resultados ainda serão gerados, com a con-tinuidade deste estudo, mas é perceptível que o Rails é uma ferramenta muito segura para desenvolvimento Ágil.
Referências
ASLESON, R.; SCHUTTA, N. T. Foundations of ajax. Berkeley, USA: Apress, 2006.
CUNHA NETO, S. M. da. Rails versus struts: um compara-tivo de Frameworks. 2007. 56f. Monografia (Bacharelado em Ciência da Computação) – UNIRIO-Universidade Fede-ral do Estado do Rio de Janeiro, Rio de Janeiro-RJ, 2007. FULTON, H. Ruby: whatisruby. 2005. Disponível em: <http://www.rubygarden.org/Ruby/page/show/WhatIs Ruby>. Acesso em: 14 jun. 2007.
HIGHSMITH, J. History: the agile manifesto. 2001. Dis-ponível em: <http://agilemanifesto.org/history.html>. Acesso em: 14 jun. 2007.
MARSHALL, K.; PYTEL C.; JON, Y. Pro active record
for ruby: databases with ruby on rails. Berkeley, USA:
Apress, 2007.
SPOSITO, R. Rub on Rails no browser. InfoExame, São Paulo, n. 248, p. 124-5, nov. 2006.
THOMAS, D. et al. Agile web development with rails. 2nd ed. Raleigh, USA: The Pragmatic Bookshelf, 2007. WALTON, B.; HIBBS, C. Rolling with ruby on rails
re-visited. 2006. Disponível em: <http://www.onlamp.com/
pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails revisited.html>. Acesso em: 14 jun. 2007.
Felipe Pierre Conter*
Discente da Universidade Estadual do Oeste do Paraná – Campus Foz do Iguaçu (UNIOESTE).
e-mail: <felipeconter.cc@gmail.com> Fabiana Frata Furlan Peres
Mestranda em Ciência da Computação. Docente da Universidade Estadual do Oeste do Paraná – Campus Foz do Iguaçu (UNIOESTE). e-mail: <ffrata@gmail.com>
* Endereço para correspondência:
Rua Edmundo de Barros, 557, apto 44 – CEP 85851-120 – Foz do Iguaçu, Paraná, Brasil.
