Utilizacao de Ruby On Rails para o desenvolvimento de

UNIVERSIDADE ESTADUAL DE MARINGÁ
DEPARTAMENTO DE INFORMÁTICA
UTILIZAÇÃO DE RUBY ON RAILS PARA O DESENVOLVIMENTO DE UMA
APLICAÇÃO COM BANCO DE DADOS LEGADO
ELLISON MAEDA
ORIENTADOR: GÉCEN DE MARCHI
MARINGÁ
2012
ELLISON MAEDA
UTILIZAÇÃO DE RUBY ON RAILS PARA O DESENVOLVIMENTO DE UMA
APLICAÇÃO COM BANCO DE DADOS LEGADO
Trabalho apresentado como requisito para a
aprovação no curso de Especialização em Desenvolvimento de Sistemas para Web da Universidade Estadual de Maringá.
Orientador: Prof. Gécen de Marchi
MARINGÁ
2012
ELLISON MAEDA
UTILIZAÇÃO DE RUBY ON RAILS PARA O DESENVOLVIMENTO DE UMA
APLICAÇÃO COM BANCO DE DADOS LEGADO
BANCA EXAMINADORA
___________________________________________________
Prof. Orientador Gécen de Marchi
____________________________________________________
____________________________________________________
SUMÁRIO
1
INTRODUÇÃO ............................................................................................................................. 7
1.1
DEFINIÇÃO DO PROBLEMA ........................................................................................................... 7
1.2
JUSTIFICATIVA ............................................................................................................................. 8
1.3
OBJETIVO GERAL ......................................................................................................................... 8
1.4
OBJETIVOS ESPECÍFICOS .............................................................................................................. 9
1.5
DELIMITAÇÃO DO ESTUDO ........................................................................................................... 9
1.6
ORGANIZAÇÃO DO ESTUDO .......................................................................................................... 9
2
REVISÃO DA LITERATURA................................................................................................... 10
2.1
LINGUAGEM DE PROGRAMAÇÃO RUBY ...................................................................................... 10
2.2
FRAMEWORK RAILS ................................................................................................................... 12
2.3
CONTROLE TRIBUTÁRIO ............................................................................................................. 14
3
METODOLOGIA........................................................................................................................ 15
3.1
4
DESENVOLVIMENTO DA PESQUISA E DA APLICAÇÃO............................................... 17
4.1
VISÃO GERAL DO SISTEMA ......................................................................................................... 17
4.2
CONTROLLERS DA APLICAÇÃO................................................................................................... 18
4.3
CLASSES DE NEGÓCIOS .............................................................................................................. 20
4.4
BANCO DE DADOS ...................................................................................................................... 25
4.5
EMISSÃO DE RELATÓRIOS .......................................................................................................... 29
5
CONSIDERAÇÕES FINAIS...................................................................................................... 31
5.1
6
METODOLOGIA DE PESQUISA..................................................................................................... 15
CONCLUSÃO ............................................................................................................................... 31
REFERENCIAS........................................................................................................................... 33
LISTA DE FIGURAS
Figura 1: Diagrama de funcionamento do sistema ...................................................................20
Figura 2: Diagrama de classes da emissão de certidão.............................................................22
Figura 3: Diagrama de classes de consulta de dados................................................................23
Figura 4: Classe modelo Debitosbloqueto................................................................................24
Figura 5: Método find...............................................................................................................25
Figura 6: Configuração do banco de dados ..............................................................................26
Figura 7: Diagrama de Entidade Relacionamento....................................................................28
Figura 8: Requisição SOAP do relatório ..................................................................................31
RESUMO
Este trabalho teve por objetivo utilizar a liguagem Ruby e o framework Rails para desenvolver uma aplicação que efetua uma conexão com um banco de dados legado. O Ruby on
Rails é um web framework que tem por objetivo desenvolver aplicações para a internet, e este
utiliza um conjunto de convenções para que o desenvolvedor não precise se preocupar com
configurações, tais convenções são aplicadas em sua comunicação com o sistema gerenciador
de banco de dados. A base que foi utilizada no trabalho não segue as convenções utilizadas
pela ferramenta de desenvolvimento, e para que a aplicação de exemplo possa efetuar a conexão para tratamento e exibição dos dados neste trabalho foi feito um estudo sobre como isto
pode ser feito e qual o esforço necessário. Após a execução do trabalho foi visto que o framework possui os recursos necessários para efetuar a conexão com o banco de dados que não
se encontra no esquema adequado da ferramenta.
Palavras Chaves: Ruby on Rails, Banco de dados, Framework web, Desenvolvimento
web.
1
1.1
INTRODUÇÃO
DEFINIÇÃO DO PROBLEMA
Atualmente uma das tecnologias utilizadas para um desenvolvimento ágil é o Ruby on
Rails, este é um conjunto de tecnologias e frameworks que permitem o desenvolvimento de
um aplicativo web. O Ruby on Rails, como o próprio nome já diz utiliza a linguagem de programação Ruby, uma linguagem interpretada e orientada a objetos, segundo Thomas e Hansson esta linguagem permite que o desenvolvedor possa expressar idéias naturalmente e de
forma limpa, permitindo que se possa criar programas que são fáceis de escrever e de manter
(2006, p. 15). Ainda segundo Thomas e Hansson (2006, p. 15) este framework utiliza a “convention over configuration” isto quer dizer que o Rails utiliza convenções ao invés de deixar a
configuração de acordo com o desenvolvedor, isso também é aplicado sobre o framework de
comunicação com o banco de dados que este utiliza, que pode mapear objetos para tabelas do
banco de dados. Desta forma, o desenvolvimento de aplicações utilizando esta tecnologia é
bastante centrado para desenvolvimento de aplicações novas, porém existem diversos sistemas que trabalham internamente e que precisam de dados a serem disponibilizados pela internet.
No caso deste trabalho o sistema que terá as informações disponibilizadas será um sistema de informação tributário interno de uma prefeitura, que já possui um software que está
gerenciando as informações internas e estas serão disponibilizadas para o acesso dos contribuintes.
Assim este trabalho irá focar o desenvolvimento de aplicações utilizando o Ruby on
Rails para apoiar aplicações já legadas.
7
1.2
JUSTIFICATIVA
Existem diversos softwares de sistemas de informações em versões desktop que geram
diversos tipos de informações para os usuários, um dos objetivos do sistema de informação é
a geração de informações para dar suporte a tomada de decisões (O' Brien, p.9) e para isso um
dos atributos para a geração de informação é a qualidade, e boa qualidade num sistema de informação é a prontidão (O' Brien, p.25), isto quer dizer que ao ser requerida ela deve estar
pronta para o usuário.
Um dos recursos para garantir essa agilidade da informação é justamente utilizar a internet, e para isso é necessário o desenvolvimento de uma aplicação que faça a comunicação
com o banco de dados e ler a informação gerada pelo sistema de informação interno de uma
empresa para que esta seja disponibilizada para seus usuários pela internet.
Como já dito o framework Rails utiliza diversos padrões próprios que muito provavelmente não será utilizado pela aplicação que já está em produção. E como o Ruby on Rails
é um dos frameworks de produção web existentes atualmente este poderia ser utilizado prontamente para a disponibilização da informação pela internet de um sistema já´em produtividade numa empresa.
Logo este trabalho se justifica pela utilização do Ruby on Rails para o desenvolvimento de uma aplicação que irá ler informações de um banco de dados já existente e disponibilizar esta informação pela world wide web garantindo assim a qualidade da informação para a
tomada de decisões.
1.3
OBJETIVO GERAL
Desenvolver uma aplicação utilizando o framework Ruby on Rails que faça a comunicação com um banco de dados existente para a disponibilização de informações internas para
sua acessibilidade pela internet.
8
1.4
OBJETIVOS ESPECÍFICOS
1. Elaborar o constructo teórico do framework Ruby on Rails
2. Conhecer as tecnologias utilizadas no trabalho e a sua aplicação pratica
3. Desenvolver a aplicação web utilizando o Ruby on Rails
1.5
DELIMITAÇÃO DO ESTUDO
O desenvolvimento deste trabalho focará no desenvolvimento de uma aplicação web
para ler informações de um sistema de informação tributário de uma prefeitura e disponibilizar aos usuários pela internet utilizando o Ruby on Rails. O desenvolvimento do trabalho ocorrerá de março de 2012 a novembro do mesmo ano.
1.6
ORGANIZAÇÃO DO ESTUDO
O trabalho apresenta-se em capítulos, que são subdivididos para proporcionar maior
clareza e facilidade de compreensão.
O Capítulo 1 contempla as considerações iniciais acerca do trabalho a ser desenvolvido.
No Capítulo 2, demonstra-se o arcabouço teórico, que servirá como sustentação ao desenvolvimento do presente trabalho.
Já o Capítulo 3, evidencia a metodologia utilizada, como referenciais bibliográficos e
métodos de coleta de dados.
É no Capítulo 4 que o objeto de estudo deste trabalho é abordado, ou seja, o detalhamento do desenvolvimento utilizando o framework Rails.
Por fim, o Capítulo 5 apresenta a conclusão do trabalho, evidenciando os resultados do
estudo individual e a aplicação web desenvolvido.
9
2
2.1
REVISÃO DA LITERATURA
LINGUAGEM DE PROGRAMAÇÃO RUBY
Ruby é uma linguagem de programação dinâmica com uma complexa, mas expressiva
gramática e um núcleo de classes com uma API rica e poderosa. Ruby é uma linguagem orientada a objetos, porém permite estilos de programação procedurais e funcionais. Segundo o
autor um dos focos no desenvolvimento da linguagem é tornar a linguagem rápida e fácil de
utilizar.
Um dos princípios utilizados pelo Ruby é o “Principle of least surprise” procurando
sempre minimizar confusão por parte dos desenvolvedores e problemas durante o desenvolvimento tal como códigos confusos e que não dizem o que está sendo e como está sendo executado. Segundo Matsumoto a linguagem foi criada para que programadores “ordinários” pudessem trabalhar (Matsumoto 2001).
Os recursos mais básicos de Ruby são (Matsumoto 2001):
Interpretive programming: Ruby é uma linguagem interpretada, evitando a necessidade de compilação, segundo o autor o objetivo de ser uma linguagem interpretada é diminuir os
ciclos de desenvolvimento, apenas alimentando o interpretador.
Dynamic programming: A linguagem tem um recurso de efetuar operações em runtime, é possível até gerar programas dentro de programas e executá-los.
Familiar syntax: Visando facilitar o aprendizado da linguagem a sintaxe se baseou em
linguagens como Java, Perl, Python, C/C++ ou até Smalltalk, então Ruby não será um desafio
tão grande para aprender.
Iterators: Ruby possui métodos para iteração evitando a necessidade de contadores para controlar a iteração.
Ampla biblioteca: A linguagem possui diversas bibliotecas, para o desenvolvimento de
aplicações, desde bibliotecas de tipos básicos até bibliotecas de threads e programação de redes.
Garbage collection: Programação orientada a objetos utiliza diversos objetos durante
sua execução, e assim como Java, Ruby possui um coletor de lixo.
Ruby possui capacidade de metaprogramação ou a programação dinâmica como citado
anteriormente. Metaprogramação é um recurso onde a linguagem pode alterar outros progra10
mas ou a si mesmo na hora da compilação ou em runtime, este recurso permite que os programadores utilizem menos tempo para achar uma solução, ou criar uma sem a necessidade
recompilar novamente o software. No Ruby um exemplo seria a criação de métodos em classes feitos em runtime (Flanagam e Matsumoto 2008. p.16).
Segundo o criador do Ruby, a linguagem foi criada pois este não estava completamente satisfeito com as linguagens existentes. Algumas linguagens eram simples e limitadas demais, outras complexas demais. Ruby foi criada para ser tornar a programação simples e rápida. Ruby foi disponibilizada ao publico no ano de 1995 e teve uma boa aceitação, pois desde
então muitos programadores se simpatizaram com a linguagem e começaram a programar utilizando esta linguagem (Flanagam e Matsumoto 2008. p.16).
Uma das características que Matsumoto adicionou na linguagem é uma sintaxe bastante dinâmica não necessitando seguir regras na digitação do código, um exemplo é a possibilidade de omitir parentes nas chamadas de funções, passando apenas parâmetros, isso é proposital, já que um dos objetivos da linguagem é deixar a programação mais tranqüila e prazerosa
(Flanagam e Matsumoto 2008. p.17).
A orientação a objetos em Ruby se aplica nos tipos de valores, Thomas e Hansson
(2006, p. 630), dizem que tudo que é manipulado durante o desenvolvimento de uma aplicação é um objeto. Flanagam e Matsumoto (2008, p. 16) explicam melhor esta orientação a objetos dizendo que Ruby todo tipo de valor é um objeto, números são objetos, booleanos são
objetos e até null é um objeto. E cada objeto tem um conjunto de funções assim em Ruby até
as operações matemáticas são chamadas de funções para manipulação de objetos. Um exemplo seria uma classe array, que guarda diversos valores de objetos, este possui um método
each, este método permite que se faça uma iteração pelo conjunto de dados.
Outra característica da linguagem Ruby é que esta é bastante sistemática quanto a encapsulamento dos objetos, qualquer acesso a variáveis de instancias dentro das classes devem
ter os métodos acessores. A linguagem também pode diferenciar o método de acesso no texto,
que pode ser público, privado ou protegido (Flanagam e Matsumoto 2008, p. 17).
Apesar do acesso restrito a propriedades da classe, estas são abertas, podendo o programador redefinir métodos de classes, ou adicionar métodos em classes. Um exemplo pode
ser dito com a classe Integer do Ruby, como já dito anteriormente as operações são chamadas
para métodos, logo a operação de soma é um método em Ruby, pelo fato da linguagem ter
classes abertas é possível redefinir o método de somar para subtrair, assim quando o operador
de soma for chamado ele irá executar a função que foi redefinida na classe (Flanagam e Matsumoto 2008, p. 214).
11
Outra característica da linguagem é que o programador não precisa definir tipos ou escopo das variáveis, utilizando convenções nos nomes das variáveis o interpretador pode saber
se é uma variável local, variável global, etc (Flanagam e Matsumoto p. 76).
A linguagem Ruby também é duck typing, isto é, para que não necessita estender um
objeto ou implementar uma interface para se encaixar em um determinado tipo, basta que a
classe implemente os métodos necessários e a classe pode ser de um tipo especifico. (Flanagam e Matsumoto 2008, p. 89 a 90)
Ruby também possui diversas features de uma linguagem de programação moderna
(Matsumoto 2001):
•
Possui formas de tratamento de exceções para que o programador possa administrar os possíveis erros que o programa possa enfrentar.
•
Um coletor de lixo para os objetos que não estão sendo mais utilizados.
•
É possível escrever extensões para a linguagem C.
•
Ruby pode carregar bibliotecas de extensões, por exemplo, uma chamada a
funções de dll's do sistema operacional Windows.
•
2.2
A linguagem pode rodar em diversas plataformas.
FRAMEWORK RAILS
O Ruby on Rails é um framework ágil que combina diversas ferramentas para o desenvolvimento, este procura tornar fácil o desenvolvimento, instalação e a manutenção dos
sistemas web. Ruby ficou bastante famoso em questão de meses, pois muitos desenvolvedores
não estavam satisfeitos com as tecnologias existentes e Rails é um framework que facilitou
muito o trabalho.
Segundo Griffths (2009, p.6 capitulo 1) o framework é focado em produzir sistemas
centrados no banco de dados, isto é, seu principal trabalho é manipular dados sem que os utilizadores do sistema necessitem de utilizar a linguagem SQL para este tratamento, para que
isto possa ser efetuado o Rails utiliza o ActionPack, uma biblioteca para auxilio na geração de
paginas que efetuam comunicação com o banco de dados.
O Rails utiliza dois conceitos chaves, o DRY (Don't Repeat Yourself), isto quer dizer,
que cada código escrito deve estar somente em um local da aplicação, para isso o framework
procura utilizar de diversos recursos do Ruby para que isto seja aplicado.
12
O outro conceito é a Convention over Configuration, isto é, o sistema utiliza convenções ao invés de configurações, evitando assim tempos e arquivos de configurações dentro da
aplicação. Todas as aplicações Rails utilizam a mesma estrutura de pastas e os mesmos padrões em nomes, resultando em aplicações fáceis de entender, além disso, as ferramentas que
o framework possui também podem ajudar o desenvolvedor na produção do software. Griffths
(2009, p 9 capitulo 1).
Segundo Thomas e Hansson (2006, p. 24) o Rails utiliza a arquitetura MVC (Model
View Controller), separando cada parte do código em seu lugar e cada uma destas partes interagem de uma forma única. O MVC procura separar a interface do sistema das classes lógicas
que irão manipular os dados para a geração da informação. Desta forma é possível também
criar testes automatizados para cada parte independentemente e também, reaproveitar classes
já prontas caso seja necessário alterações em partes especificas do sistema. O framework já
separa cada parte do código fonte em pastas separadas, ficando as views em uma pasta, models em outra pasta e os controllers em outra pasta (Griffths 2009, p 43 capitulo 1).
No Rails o model é a parte do sistema que irá administrar como os dados são guardados no banco de dados, o view é a parte da aplicação onde será apresentada para o usuário, ou
pode ser chamada de camada de apresentação. O controller é a parte da aplicação define como a aplicação irá funcionar, como os dados serão acessados e tratados do model e qual parte
da view irá exibir os dados para o usuário.
Este framework também possui suporte a testes de software, e pode criar esqueletos de
testes para cada funcionalidade adicionada assim uma aplicação feita utilizando Rails “tende”
a ser testada pelo programador, permitindo a aplicação de desenvolvimento orientado a testes
Thomas e Hansson (2006, p. 184).
As pastas dentro de uma aplicação Rails são nomeadas de acordo com seu conteúdo,
citarei a seguir algumas pastas dentro da estrutura do framework e sua função, dentro da raiz
temos as seguintes pastas (Thomas e Hansson 2006, p. 229):
App: nesta pasta ficará o código da aplicação em si aqui serão inseridos os controllers
da aplicação os html’s que serão disponibilizados para o usuário que acessar o sistema, e as
configurações de acesso a banco de dados. Muita parte do desenvolvimento de uma aplicação
ficará dentro desta pasta.
Config: nesta pasta estão localizados os arquivos de configuração da aplicação, dentre
eles nesta aplicação de exemplo destacaram-se os arquivos routes.rb onde fica a configuração
de resposta da aplicação para cada requisição e database.yml onde fica a configuração do
banco de dados a ser utilizado pela aplicação.
13
Db: Dentro desta pasta ficam as migrações do banco de dados, para cada versão do
banco que se altera fica gravado nesta pasta, para possivelmente se for necessário o desenvolvedor poderá voltar a versão do banco de dados para uma versão anterior.
Test: Aqui ficam os testes unitários para o sistema, o Rails para cada controller criado
com o scaffold já cria também um teste unitário para a aplicação.
Dentro da pasta app ainda há mais pastas da aplicação, entre elas podemos destacar
para esta aplicação (Thomas e Hansson 2006, p. 229, p. 22, 23):
Controllers: dentro desta pasta é onde será inserida a parte da aplicação responsável
pelo processamento das requisições
Models: nesta pasta ficam os modelos e qualquer alteração necessárias neste, no caso
desta aplicação em desenvolvimento será necessário efetuar nos modelos além de sua declaração inserir algumas configurações para sobrescrever os padrões definidos pelo Rails, visto
que o framework já automatiza parte do processo como por exemplo as propriedades são buscadas diretamente do banco de dados.
Views: esta pasta conterá a parte da aplicação que apresentada no browser do cliente,
apesar do Ruby on Rails utilizar o MVC caso o programador queira ele pode estar adicionando código para ser executado nesta parte da aplicação.
2.3
CONTROLE TRIBUTÁRIO
O objetivo do sistema a ser desenvolvido será disponibilizar informações acerca de
tributos para com o contribuinte, tais tributos são gerados no departamento tributário do município e para que o contribuinte possa ter acesso a informações acerca de seu tributo, deve se
dirigir a prefeitura. Para explicar melhor a funcionalidade do sistema esta seção do trabalho
irá falar sobre alguns conceitos de tributos.
Segundo Fabretti (2004, p. 50) um tributo é toda prestação obrigatória, em valor, que
tenha um suporte legal. Em outras palavras um tributo é uma conta obrigatória que o contribuinte deve pagar. Ainda segundo Fabretti (2004, p. 51) o tributo pode ser não vinculado, é cobrado independentemente de o estado estar prestando serviço ao contribuinte, e pode ser gerado, por exemplo numa operação que o contribuinte efetua, um exemplo seria ter a posse de
um imóvel tendo que pagar o imposto predial e territorial ao município, o tributo não vinculado é chamado de imposto.
O tributo pode ser também, vinculado neste caso chamado de taxa ou contribuições de
14
melhoria, neste caso o tributo é cobrado quando o estado presta um tipo de serviço ao contribuinte, por exemplo, a pavimentação de um bairro, onde o município pode cobrar uma taxa
para efetuar o serviço.
As informações destes impostos e os impostos são gerados dentro da parte administrativa da prefeitura, alguns deles para serem pagos necessitam do boleto para que o contribuinte
possa efetuar seu pagamento e este deve ser adquirido na prefeitura, um dos objetivos do sistema exemplo é pular esta parte disponibilizando a guia para ser impressa pela internet.
Outra função do sistema será a possibilidade de emissão de certidões negativas, positivas e positiva com efeito negativo. Segundo Fabretti (2004, p. 155) a certidão negativa é a
prova que o contribuinte quitou os débitos para com o município, para o contribuinte poder
adquirir esta certidão, seus débitos devem estar pagos na prefeitura, mesmo aqueles que não
estão vencidos. O sistema exemplo poderá emitir esta certidão via internet caso o contribuinte
esteja com todos seus débitos pagos. Caso o contribuinte possua débitos pendentes, mas estes
não ultrapassaram sua data de pagamento este poderá emitir a certidão positiva com efeito
negativo, provando que o contribuinte tem débitos para com a repartição pública, no entanto
está em dia. Se o contribuinte atrasou um imposto então a certidão será positiva
O sistema web permitirá a emissão desta certidão via internet, e além desta funcionalidade o contribuinte poderá efetuar consultas de suas pendências para com a administração pública de seu município.
3
3.1
METODOLOGIA
METODOLOGIA DE PESQUISA
Este trabalho utilizará das pesquisas bibliográficas, visto que será feito um levantamento bibliográfico das tecnologias utilizadas no trabalho. O outro tipo de pesquisa utilizado
será o estudo de caso, pois será feito um estudo sobre o framework utilizado e procurar conhecer sobre ele no ambiente do estudo. Visto que este trabalho não utilizará de quantidades
para chegar a seus resultados então para a abordagem do problema será adotado o meio qualitativo.
15
Esta pesquisa será aplicada com base em uma aplicação desktop que roda na parte administrativa de uma prefeitura no setor de arrecadação, o objetivo do aplicativo é complementar o aplicativo que está em andamento na entidade provendo maior facilidade para os contribuintes
Para o desenvolvimento da aplicação, será feito o estudo do framework Rails e da linguagem de programação Ruby, em seguida será feito a criação da aplicação utilizando recursos do framework. Depois será estudada uma forma viável de se efetuar a conexão no banco
de dados SQL Server 2005 e com as tabelas do banco de dados que já existem na aplicação
que está rodando visto que o Ruby on Rails.
Não haverá coleta de dados visto que o trabalho será uma pesquisa e desenvolvimento
de atividades referentes a desenvolvimento de software.
Ao final do desenvolvimento espera-se que exista conhecimento sobre a tecnologia e
sobre o desenvolvimento do sistema feito a fim de saber quais foram às dificuldades encontradas no desenvolvimento da aplicação.
Para o desenvolvimento do produto será utilizado conjunto de ferramentas que tenha
suporte a linguagem Ruby, além disso provavelmente será utilizado o Jasper Server para os
relatórios, e haverá a necessidade de configuração do Rails para o acesso ao banco de dados
SQL Server 2005 e a estrutura de tabelas no qual o sistema desktop já está rodando pois o
framework não oferece suporte a esta operação.
Após o desenvolvimento da parte comunicativa do desktop com o banco de dados, será implementado a emissão da guias e seu layout para emissão de guias e emissão de relatórios para o contribuinte. Nesta parte segundo pesquisas até o momento será utilizados Jasper
Reports.
Depois do desenvolvimento da aplicação será feito a parte de testes para as operações
da aplicação procurando obter o desenvolvimento ágil, um dos objetivos do Ruby on Rails.
16
4
4.1
DESENVOLVIMENTO DA PESQUISA E DA APLICAÇÃO
VISÃO GERAL DO SISTEMA
Para o desenvolvimento da pesquisa foi utilizados principalmente quatro livros e consultas em diversos sites da internet e fóruns sobre desenvolvimento de software, essas pesquisas visaram aprender como seria o desenvolvimento utilizando o framework Rails, seu funcionamento, a sua estrutura, forma de trabalho, forma de acesso aos dados e forma de passar
os dados para serem apresentados. E o desenvolvimento utilizando a linguagem Ruby, principalmente quanto sua sintaxe e sua disponibilização de recursos para o programador e quanto a
organização do código e da arquitetura do sistema.
Além das pastas utilizadas pelo framework para a construção da aplicação foram criadas mais duas pastas dentro da pasta app para auxiliar os processos necessários do sistema, as
pastas adicionadas foram:
•
Pasta classes: Esta pasta tem o objetivo de guardar as classes criadas que irão
efetuar o processamento das regras de negócio da aplicação, cada controller
que necessitar de uma dessas classes será incluído sua dependência para então
sua utilização. O objetivo de criar esta pasta é para melhor organizar o sistema
e deixá-lo melhor para sua manutenção.
•
Pasta relatório: Aqui ficarão os relatórios em formato Portable Document Format um tipo de formato onde seu conteúdo pode ser visualizado mas não editado. Os relatórios gerados nesta pasta são apenas temporários pois após a geração deste será disponibilizado para download para o contribuinte.
O ambiente de desenvolvimento da aplicação será o sistema operacional Linux na distribuição Fedora versão 16. O banco de dados SQL Server 2005 será executado em uma maquina virtual para seu acesso, pois este é incompatível com o ambiente Unix selecionado para
desenvolvimento. O ambiente Linux foi selecionado pois grande parte das ferramentas de desenvolvimento a serem utilizadas na construção da aplicação já se encontravam instaladas
neste ambiente, podendo assim iniciar os trabalhos mais rapidamente.
Foram feitos estudos de diversas ferramentas na internet e foi visto que não há um
ambiente próprio para o desenvolvimento em Ruby on Rails, cada programador pode escolher
as ferramentas que desejar para criar aplicação utilizando o framework. Um dos editores que
17
parece bastante popular é o TextMate citado também por Thomas e Hansson (2006, p.37) como escolha pessoal. Porém este editor pode ser executado somente em sistemas Apple, tornando sua escolha para o desenvolvimento da aplicação não relevante. Depois de algumas
pesquisas foi decidido utilizar para a edição de código Ruby a principio o editor Kate da suíte
KDE do sistema Linux, e mais tarde este foi trocado para o editor VIM também do sistema
Linux. Para a manutenção e consulta do banco de dados a ferramenta utilizada foi o Microsoft
SQL Server Management Studio que acompanha o banco de dados SQL Server 2005.
Para rodar a maquina virtual onde o banco de dados se encontra foi utilizado o Virtual
Box, neste foi instalado o sistema operacional Windows XP e em seguida o SQL Server 2005.
Foi necessário também instalar o Java e o Servlet Container Apache Tomcat, estes foram necessários para rodar o repositório de relatórios Jasper Server que será utilizado para a
geração de relatórios da aplicação. O Java foi necessário também para executar o editor IReport, um editor visual de relatórios que permite criar e alterar relatórios que serão alocados no
repositório. Juntamente com estas ferramentas foi preciso também o PostgreSQL que é o banco de dados onde os relatórios administrados pelo Jasper Server serão alocados.
4.2
CONTROLLERS DA APLICAÇÃO
Como já dito anteriormente os arquivos com o código para processamento da aplicação devem ficar dentro da pasta app/controllers no caso desta aplicação exemplo, a consulta
pôde ser feita com um controller simples, bastando pegar os parâmetros que vieram de uma
view e efetuar a consulta via SQL no banco de dados.
Para criar os controllers e efetuar a conexão com banco de dados, um dos recursos do
framework que foi estudado é o “scaffold”. Segundo Griffths (2009, p 12 capitulo 1) este comando gera código que possibilita a aplicação efetuar as operações de criar, atualizar, ler, e
excluir informações do banco de dados, permitindo que o desenvolvedor economize tempo ao
efetuar conexão e comandos com o banco de dados.
Porém para este trabalho não foi possível utilizar o “scaffold” pois este já cria uma estrutura com o banco de dados, e como as tabelas já existem esta estrutura deve ser ignorada,
após uma visualização no livro de Griffths não foi localizado uma forma de efetuar o comando para uma estrutura já existente, logo foi preciso criar os controllers manualmente.
Na criação do controller de consulta foi criado um model para a tabela consultada na
pasta model, em seguida foi criado o controller para tratar a requisição e enviar o resultado
18
para o cliente na pasta controllers. Em seguida foi preciso criar um HTML na camada de apresentação dentro da pasta views, este arquivo além do código HTML permite também código Ruby para algum processamento.
Para poder disponibilizar o recurso para um cliente que acessar a aplicação foi preciso
alterar o arquivo config/routes.rb este arquivo permite ao programador indicar quais os recursos e onde está os recursos no servidor a serem disponibilizados, no caso da aplicação que
está sendo desenvolvida foi adicionado a seguinte linha para disponibilizar um controller para
a consulta de débitos.
match "Consulta" => "consulta#efetuaConsulta"
Com está linha o Rails caso receba uma requisição do cliente irá procurar um controlador na pasta controller dentro de app e este controller, estará vinculado a uma determinada
view que cuidará de exibir os dados para o usuário. No caso da aplicação será disponibilizado
para o usuário um HTML com um campo para digitação, este campo irá enviar dados para um
controller e este irá retornar os dados requeridos para consulta.
Um dos controller criados é o que utiliza a conexão com o banco de dados e efetua
uma consulta para saber quais contas o usuário tem a pagar para a prefeitura, ele utiliza o model ValoresParcelas que faz consulta e retorna um array com os dados do cadastro. Estes dados então são enviados para a view onde há um tratamento para sua exibição. Este parte do
sistema é a única que não utiliza uma classe de negócio e faz o tratamento no próprio controller do Rails. No restante da aplicação o sistema passa os dados para classes especializadas e
estes fazem a conexão e o tratamento dos dados.
A opção para a utilização das classes para tratamento de negócios foi algo para organizar melhor a aplicação, colocando as regras do sistema num local que não fosse necessário
utilizar o framework, foi possível desta forma não iniciar o ambiente Rails para a programação destas classes. Outra vantagem encontrada foi também a possibilidade de criar testes unitários para estas classes validando as regras do sistema. Após a finalizar a programação bastou efetuar a criação de objetos, preencher os dados necessários para que a aplicação já funcionasse de acordo com as suas especificações.
Na figura 1 está um diagrama do funcionamento do sistema no momento em que este
recebe a requisição do browser do cliente:
19
Figura 1: Diagrama de funcionamento do sistema
4.3
CLASSES DE NEGÓCIOS
Para organizar melhor o sistema foi criado algumas classes de negócio cujo objetivo é
o de efetuar os tratamentos das requisições e trazer as respostas para o usuário final, essas
classes de negócio também facilitam o desenvolvimento e a manutenção da aplicação, cada
conjunto de classes tem um teste unitário para validar se a classe está correta e em caso de
alteração poder ser efetuado uma verificação no sistema com agilidade para garantir que tudo
está correto.
As classes foram produzidas para serem pequenas e especialistas na área que foram
desenvolvidas, por exemplo, a classe que gera os relatórios tem o objetivo de simplesmente
gerar o relatório, segundo Martin, boas classes tem poucas responsabilidades e seu nome deve
dizer bem o quais são suas responsabilidades (Martin, p. 167).
Como já dito cada classe de negócio desenvolvido na aplicação tem um teste unitário
para garantir seu funcionamento. Os testes unitários não apenas auxiliaram no desenvolvimento do código, mas também em seu refinamento para que estes estivessem prontos a desenvolver suas funções, para isso foi utilizado as três leis do TDD (Test Driven Development)
segundo Martin (Martim, p.122).
1º Você não deve escrever o código de produção sem antes escrever um teste falho
2º Você não deve escrever mais do que o teste que seja suficientemente possível de falhar, e não estar compilando é falhar.
3º Você não deve escrever mais código de produção do que aquele que passe no teste
que está falhando.
De acordo com estes três itens foi criado um conjunto de classes para a emissão de
20
certidões negativas e certidões positivas com efeito negativo. Esse conjunto de classes utiliza
um model para conectar no banco de dados e efetuar uma consulta nos débitos do cadastro, e
então se for o caso imprimir uma certidão para o cadastro. Apesar de ser um model que aponta
para uma tabela do banco de dados, o Active Record permite que sejam parametrizadas consultas diversas no banco de dados, é o caso desta classe que efetua consultas para saber se a
certidão requisitada pelo cadastro é negativa ou positiva com efeito negativo.
Outra funcionalidade feita através das classes foi o de emissão de guia de recolhimento, foi criada uma classe para gerar o código de barras e uma para efetuar a gravação dos dados da emissão da guia de recolhimento no banco de dados do sistema. Desta forma o sistema
administrativo ao receber o arquivo de pagamentos do banco pode identificar e saber qual o
débito que foi baixado. As duas classes relacionados a guia de recolhimento tem suporte de
um teste unitário que foi utilizado também para a sua produção.
Como o restante do esquema de banco de dados a tabela que guarda informações dos
boletos emitidos não segue o padrão definido pelo framework e foi preciso efetuar algumas
alterações para que o a gravação da emissão das guias fosse possível:
•
Alterar o nome da tabela para minúsculo
•
Alterar os nomes dos campos da tabela para minúsculo
•
Definir no model do Rails qual é a chave primaria utilizada pela tabela
•
Definir no model do Rails qual é o nome da tabela a ser acessada, pois o padrão do Rails utiliza tabelas no plural e o nome da tabelas está no singular
(Griffths 2009, p 53 capitulo 2).
•
Definir no model do Rails quais os campos a serem acessados
Após efetuar as alterações acima já foi possível utilizar o método Create do Rails que
permite criar um registro no banco de dados. Porém esta tabela que guarda a emissão de boletos tem uma chave única chamado de “idDebitosBloqueto” então não foi necessário tratar
chaves compostas no framework.
Outra classe de apoio ao sistema que foi criado foi a classe para efetuar chamadas de
relatórios, esta classe faz a comunicação com o Jasper Server passando o relatório desejado e
os parâmetros para os filtros, e ao receber o retorno do servidor de relatórios faz o tratamento
e cria um arquivo pdf contendo os dados do relatório. A parte de comunicação com o banco
de dados como é feita pelo repositório de relatórios não precisou ser tratada no Ruby on Rails,
bastou apenas configurar o servidor, criar os relatórios e efetuar as chamadas.
A figura 2 ilustra um diagrama de classes da emissão de certidão:
21
Figura 2: Diagrama de classes da emissão de certidão
No diagrama de classes exibido na figura 2 podemos ver como as classes para a função de emissão de certidões do sistema funciona, temos o controller que chama o ClassificaCertidao que é responsável por verificar se o cadastro possui débitos, em caso positivo o cadastro já tem uma certidão positiva com efeito negativo, se o contribuinte tem contas vencidas
então tem uma certidão positiva (esta certidão não pode ser emitida pela web somente na prefeitura), caso as duas funções não retornem valor verdadeiro então é uma certidão negativa.
A classe que faz a classificação da certidão já chama o RelatorioCertidao que tem como objetivo carregar o layout do repositório e em seguida disponibilizar ao controller, ela
também verifica se os dados fornecidos são validos. As duas classes localizadas a direita da
figura são os models do framework, onde somente um para cada classe foi suficiente para realizar as funções. As operações em ambas as classes utilizando os modelos foi somente para
consulta de dados, não necessitando a gravação de informações no banco de dados.
22
Na figura 3 será detalhado as classes referentes a consulta de dados:
Figura 3: Diagrama de classes de consulta de dados
O diagrama da figura 3 define a parte de consulta de dados, apesar das classes não se
interligarem entre si, coloquei-as na mesma imagem, pois estas são invocadas da mesma view
e do mesmo formulário HTML, a sua chamada é configurada via código JavaScript. A primeira classe da esquerda é a classe que efetua uma consulta no banco e traz dados de contas
que o cidadão ainda não pagou na prefeitura, a consulta é feita diretamente pelo controller
não havendo uma classe especifica para a operação.
A classe RelatorioDebitoController tem a mesma responsabilidade da ConsultaController, a diferença é que esta efetua uma comunicação com o repositório de relatório e envia
23
um arquivo PDF para o usuário contendo os dados dos débitos do usuário que ainda não foram pagos. Para isso não há operações no controller toda a consulta dos dados e configuração
foi feito no relatório que se encontra no Jasper Server.
Por ultimo a direita temos as classes relacionadas a emissão de guia de recolhimento
para o usuário efetuar os pagamentos de suas contas. A classe que inicia o processo é o EmissaoGuiaController, pelo sistema permitir que o usuário possa selecionar diversas guias para
serem impressas de uma única vez, ela é responsável por receber este conjunto de valores enviados da view e para cada valor ela efetuará a gravação de um registro na tabela DébitosBloqueto, que como será visto no próximo tópico é a tabela responsável por identificar qual pagamento se refere a qual conta.
Para gravar um registro na DebitosBloqueto a classe GravarDebitosBloqueto deve reunir diversas informações, em meio a suas operações ela utiliza uma outra classe responsável
por gerar o código de barras que irá compor o boleto gerado, após gerar o código de barras ele
fica disponível em uma propriedade que em seguida a GravarDebitosBloqueto utiliza para
efetuar a gravação na tabela. A classe utiliza dois models, um para efetuar a gravação da tabela, que como dito anteriormente foi preciso de alterações devido aos padrões do Ruby on
Rails, e outro para buscar informações da conta a ser gravada. Entre os dados buscados estão
a data de vencimento e o valor, apesar desses dados estarem listados na tela principal estes
não são enviados pela view ao controller.
A figura 4 mostra a classe de modelo DebitosBloqueto com a alteração necessária para
efetuar a gravação do registro:
Figura 4: Classe modelo Debitosbloqueto
A primeira linha indica o nome da classe e a classe que esta herda suas características,
é a base de um model para utilizar o active Record no Ruby on Rails, o comando
self.table_name permite que se possa dizer qual o nome da tabela a classe deverá acessar no
banco de dados, neste caso foi utilizado este recurso pois o nome da tabela está no singular no
banco, no entanto para framework deveria estar no plural, assim utilizando o table_name foi
24
possível acessar a tabela. O comando primary_key diz ao Ruby on Rails qual é a chave primaria da tabela, caso esta também não siga as convenções do framework. Por ultimo é definido
quais campos o Rails irá acessar na tabela, neste caso foi somente definido os campos principais para efetuar a gravação da tabela para posteriormente identificar qual o débito no momento que o banco enviar o arquivo retorno.
Após efetuar a gravação da tabela DebitosBloqueto o controller de emissão de guias
procede para chamar a classe de relatórios que está no Jasper Server para exibir a guia de recolhimento para o usuário. Este relatório da guia também tem sua consulta de dados configurada dentro de si, e não foi necessário configurações no framework para sua utilização, apenas
a sua chamada passando os filtros como parâmetros.
Nos casos onde os nomes das tabelas foram alterados para seguir a convenção do Rails
não foi preciso alterar os models, bastando utilizar eles da forma normal, no entanto segundo
testes não foi possível efetuar operações de inserção, somente de consulta. O comando principal de consulta utilizado segue na figura 5.
Figura 5: Método find.
Este é o principal método de consulta utilizado na aplicação, é desta forma que os dados são buscados do banco de dados pela aplicação, neste exemplo o método find busca os
dados definidos na opção select e retorna um array de objetos, para acessar os objetos pode-se
utilizar o método each e assim efetuar uma iteração sobre os registros. Como pode ser visualizado na figura, este método permitem definir a clausula where e join de comandos SQL.
4.4
BANCO DE DADOS
O framework utiliza convenção ao invés de configuração, porém não é o alvo deste
trabalho, já que este não visa uma aplicação nova e que será desenvolvida em sua totalidade
de acordo com os padrões do Ruby on Rails mas sim já utilizando um banco de dados que já
existe e tem uma estrutura que já está em produção. Para isto foram necessários alterações e
configurações para que o Rails utiliza-se a estrutura do banco de dados já existente.
25
O banco de dados que a aplicação utiliza é o Microsoft SQL Server 2005 que roda no
sistema operacional Windows XP, no caso do cliente da aplicação. Porém o ambiente de desenvolvimento do sistema será o Unix, utilizando a distribuição Fedora desta forma o banco
de dados não será executado na maquina de desenvolvimento, e logo seria necessário efetuar
esta conexão da distribuição Linux para a maquina com o sistema Windows XP. Esta conexão
também seria positiva pois também seria possível o cliente efetuar esta conexão e desta forma
se for de preferência do cliente colocar esta aplicação num ambiente Linux.
A primeira tentativa de conexão com o banco de dados foi feita utilizando o UnixODBC e FreeTDS, a configuração funcionou bem e pôde feita a conexão entre os dois sistemas, porém houve um problema quanto a um dos gems utilizado pela aplicação Rails e não
foi possível conectar utilizando a aplicação Rails, logo a combinação destes dois softwares
não foi utilizada na aplicação.
A segunda tentativa foi bem sucedida, este utilizou um gem chamado Tiny TDS, este
gem não precisou de configurações no sistema operacional bastou apenas adicioná-lo e configurar o database.yml para acessar o SQL Server instalado em outra maquina. O arquivo database.yml ficou com a estrutura exibida na figura 6 para a conexão com o banco no ambiente
de desenvolvimento:
Figura 6: Configuração do banco de dados
Após a conexão com o banco de dados foi feito um estudo para saber como seria possível o framework Rails comunicar com as tabelas do banco de dados, as alterações necessárias para isso foram poucas alterações necessárias e não foram encontradas muitas dificuldades para utilização das tabelas existentes.
A alteração necessária era apenas colocar em minúsculos todos os nomes de campos
da tabela que seria utilizada na comunicação, desta forma foi possível efetuar consultas nos
referidos dados. Quanto as chaves primarias, como o sistema de exemplo é utilizado a principio somente para consultas este não precisará efetuar inserções logo não seguirei em frente
com esta parte do framework.
As classes que efetuam a conexão com o banco de dados são as classes de emissão de
certidões, o controller que efetua a consulta no banco de dados, e a emissão de guias de recolhimento. Apesar de estarem utilizando os models estes não estão sendo utilizados como uma
26
representação de tabelas do banco de dados, e sim como objetos de consulta, visto que para
trazer os dados é utilizado um método chamado find onde se define os parâmetros de uma
consulta SQL e é retornado um array de objetos contendo o resultado da consulta.
Na figura 7 uma imagem do diagrama de entidade relacionamento:
27
Figura 7: Diagrama de Entidade Relacionamento
O diagrama da figura 7 nos mostra como está organizado o banco de dados, a tabela de
28
cadastro geral e cgcm são as tabelas onde são guardadas informações sobre os contribuintes,
tais informações serão utilizadas na certidão e na guia de recolhimento onde haverá dados
como endereço de correspondência do contribuinte e dados de seus documentos. A tabela de
valoresparcelas é a tabela que guarda as informações tais como vencimentos, e quais contas
ainda não foram pagas, é dela que o sistema irá buscar as informações mais importantes para a
aplicação. As tabelas de débitos, valoresdebitos e valoresparcelasreceitas são tabelas que fornecem informações que irão complementar a tabela de valoresparcelas, são importantes no
sistema tributário que roda dentro da prefeitura, porém não serão tão utilizadas no sistema
web.
As tabelas débitosbloqueto e débitosbloquetoagr localizados na parte inferior da figura
são as tabelas que o sistema tributário da prefeitura utiliza para identificar qual o debito, apesar desta não ter ligação com as tabelas que guardam as contas, as informações destas são salvas para posterior identificação. O model DebitosBloqueto, utilizado no framework precisou
ser alterado para efetuar a gravação conforme citado no tópico de Classes de Negócio.
4.5
EMISSÃO DE RELATÓRIOS
Nos relatórios a opção é de utilizar o Jasper Server para guardar e disponibilizar os relatórios para a aplicação. O Jasper Server é, segundo o site jasperforge.org um servidor de relatórios que permite a disponibilização de informações na web em diversos formatos, sendo
possível a criação de um relatório no iReport e então envia-lo ao servidor, habilitando assim a
possibilidade de reavê-lo em diversos formatos de arquivo. Dessa forma como podemos ver o
Jasper Server é um servidor de relatórios que permite o armazenamento de relatórios e sua
disponibilização para sua visualização na web.
A decisão de se utilizar este servidor é o fato deste poder guardar os layouts e poder
disponibilizar não somente a aplicação web mas a qualquer tipo de aplicação que necessite do
relatório. Outro motivo do qual o Jasper Server foi escolhido é a utilização do Ireport, um design visual de relatórios, visto que segundo pesquisas pelo site Google não foi possível localizar semelhante para a linguagem Ruby. A necessidade do iReport é sua facilidade para poder
desenhar o layout, visto que além do relatórios e certidão necessários para a aplicação, será
preciso ter a possibilidade de desenhar uma guia de recolhimento, e para isso um editor visual
facilita muito o trabalho.
A edição dos layouts de relatórios pelo iReport também possibilita que outras pessoas
29
possam editar os relatórios com maior facilidade e não somente o programador. Desta forma
há uma possibilidade melhor de divisão do trabalho entre membros da equipe, podendo uma
pessoa que não trabalha com programação a possibilidade de estar editando os layouts de acordo com as necessidades do cliente. E podendo o Jasper Server e iReport produzir relatórios
completos isso possibilita a total liberdade para outros profissionais a edição e criação de relatórios, bastando o programador caso seja necessário a implementação da chamada no sistema.
A configuração do Jasper Server com o banco de dados e o servidor não foi difícil, os
parâmetros para conexão são configurados nos relatórios onde são setados usuário, senha e
caminho para o servidor e o banco de dados no caso do MS SQL Server. Quanto ao driver de
conexão foi preciso apenas utilizar um JDBC fornecido pela Microsoft e adicioná-lo ao Tomcat para que o Jasper Server se efetuar a conexão com o servidor de banco de dados.
O Jasper Server pode se comunicar com diversas plataformas, uma das formas de sua
comunicação é utilizando o SOAP (Simple Object Access Protocol). Segundo o site
www.w3.org o SOAP é um protocolo para troca de informações estruturada em um ambiente
descentralizado e distribuído. Utiliza a tecnologia XML para construir suas mensagens que
podem ser enviadas e recebidas de diversas formas. O SOAP foi criado para ser independente
de qualquer plataforma ou linguagem de programação.
Como este protocolo de comunicação é independente de plataforma ou linguagem de
programação o Ruby pode efetuar a comunicação com o Jasper Server e utilizar seus recursos
de relatórios, o SOAP permite o servidor listar os relatórios para a aplicação, organizá-los no
servidor, adicionar relatórios ao repositório, excluir relatórios deste, efetuar chamadas, etc.
Outras formas de se efetuar comunicação com o servidor é utilizando REST ou sua API Java,
porém estes recursos não serão abordados neste trabalho.
Para o sistema desenvolvido neste trabalho estarei utilizando o SOAP, para a comunicação com o relatório utilizando este protocolo foi feito uma classe que efetua chamada e
transferência do relatório em um local onde a aplicação possa acessar, na sua exibição foi utilizado um link direto para este local para então exibir ou baixar. O formato escolhido para a
exibição do relatório é o PDF. Apesar de o Jasper Server permitir maior possibilidade de recursos, apenas será utilizado a chamada dos relatórios pelo sistema em Ruby.
A requisição SOAP para a transferência do relatório é o código mostrado na figura 8:
30
Figura 8: Requisição SOAP do relatório
O XML da figura 8 então é empacotado numa requisição POST criado via Ruby e enviado ao servidor, ao servidor processar a requisição este retorna uma resposta confirmando
que a requisição foi bem sucedida ou se algo deu errado, caso não haja problemas o servidor
retorna juntamente com a resposta o arquivo do relatório desejado que como já dito é um
PDF. Para extrair o arquivo da resposta do servidor foi utilizado um método que verifica o
inicio do arquivo e o fim e extrai este pedaço da response retornado pelo servidor.
5
5.1
CONSIDERAÇÕES FINAIS
CONCLUSÃO
O presente trabalho teve o objetivo demonstrar o desenvolvimento de uma aplicação
utilizando o Web Framework Rails e um banco de dados que não segue as convenções que
esta ferramenta precisa para efetuar a comunicação, não foi feito um estudo completo sobre a
interface de comunicação do Rails com o banco de dados.
Conforme visto no trabalho, não houve muita necessidade de alteração no banco de
dados e o Active Record permitiu que as operações necessárias para a aplicação fossem executadas sem problemas bastando apenas pequenas alterações nas tabelas no banco de dados.
Como já dito os models do framework não foram utilizados devidamente. Esta decisão foi
31
tomada, pois o banco de dados foi estruturado de uma forma em que o autor do trabalho não
viu uma forma produtiva de se utilizar os modelos do sistema como uma representação do
banco de dados.
Logo os models do sistema foram utilizados principalmente em consulta de dados,
buscando os dados ao qual o sistema necessitava para efetuar suas operações. Para que os
modelos do Rails funcionassem desta forma não foi preciso efetuar muitas configurações,
bastou apenas criá-los manualmente estendendo de ActiveRecord::Base alterar os nomes de
suas tabelas e campos para minúsculo e já foi possível utilizar os métodos de consulta de dados. Apesar das convenções do framework, a parte para efetuar as consultas foi simples para
fazer funcionar, e os métodos de consultas disponibilizados pelo ActiveRecord permite ao desenvolvedor buscar dados do banco como um comando select assim qualquer tipo de informação pode ser buscada do banco de dados.
A parte de gravação dos dados foi necessária para a operação de emissão de guia de
pagamento online, e a tabela também não segue as convenções da ferramenta. Os métodos
disponibilizados pela ferramenta a principio eram somente para consulta de dados, não podendo assim executar um comando de inserção foi preciso efetuar a comunicação do model
com o banco de dados. Após pesquisas na internet foi visto que a interface de comunicação
permite efetuar sua parametrização, assim a gravação de dados pode prosseguir sem problemas.
A parte de relatórios foi um pouco mais complicada, pois não foi encontrado um editor
de relatório que tivesse um recurso de design visual da linguagem Ruby logo foi recorrido ao
Jasper Server que permite a comunicação com outras linguagens para emissão dos relatórios.
Utilizando esta tecnologia a geração e disponibilização de relatórios pela aplicação foi simples, também não havendo dificuldades.
Assim conforme a construção da aplicação e os recursos que foram disponibilizados
pelo framework, chegou-se a conclusão que é possível desenvolver uma aplicação com um
banco de dados legado. Aplicação de exemplo criada pôde ser realizada e suas funcionalidades puderam ser implementadas sem muitas dificuldades, apesar do banco de dados não seguir as convenções do Ruby on Rails, este permitiu sem problemas que a comunicação fosse
feita e os dados manipulados de acordo com a necessidade da aplicação sem muito esforço.
Este aplicativo porém não utilizou muitos dos recursos de banco de dados, como por
exemplo, a utilização de relacionamentos entre os models, ou a manipulação de chaves compostas (apesar de estas existirem no diagrama, elas não foram necessárias). Desta forma fica
aberto a possibilidade de estudos mais avançados quanto a utilização de banco de dados e a
32
parametrização destes nas classes de modelo de dados do Ruby on Rails.
6
REFERENCIAS
MARCONI, Marina de Andrade; LAKATOS, Eva Maria. Metologia Científica. 5. ed São
Paulo: Atlas 2011
GIL, Antonio Carlos. Como Elaborar Projetos de Pesquisa. 4 ed. São Paulo: Atlas 2011
FLANAGAM, David; MATSUMOTO, Yukihiro. The Ruby Programming Language. 1 ed
O’Reilly 2008
THOMAS, Dave; HANSSON, David Heinemeier. Agile Web Development With Rails. 2
ed The Pragmatic Programmers 2006
FABRETTI, Láudio Camargo; FABRETTI, Dilene Ramos. Direito Tributário. 3. ed São
Paulo: Atlas 2004
O’BRIEN, James. Sistemas de Informação e as Decisões Gerenciais na era da Internet. 9.
ed São Paulo: Saraiva 2002
MATSUMOTO, Yukihiro. Ruby in a Nutshell. O’Reilly 2001
GRIFFTHS, David. Head First Rails. 1 ed. O’Reilly 2009
33