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
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 De-senvolvimento de Sistemas para Web da Uni-versidade Estadual de Maringá.
Orientador: Prof. Gécen de Marchi
MARINGÁ 2012
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
____________________________________________________
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 METODOLOGIA DE PESQUISA... 15
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 CONCLUSÃO... 31 6 REFERENCIAS... 33
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
Este trabalho teve por objetivo utilizar a liguagem Ruby e o framework Rails para de-senvolver 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 cone-xã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 fra-mework 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 INTRODUÇÃO
1.1 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 pro-gramação Ruby, uma linguagem interpretada e orientada a objetos, segundo Thomas e Hans-son 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 “con-vention 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 siste-mas que trabalham internamente e que precisam de dados a serem disponibilizados pela inter-net.
No caso deste trabalho o sistema que terá as informações disponibilizadas será um sis-tema 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 contribu-intes.
Assim este trabalho irá focar o desenvolvimento de aplicações utilizando o Ruby on Rails para apoiar aplicações já legadas.
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 in-formaçã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 in-ternet, 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 prova-velmente 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 pron-tamente para a disponibilização da informação pela internet de um sistema já´em produtivida-de numa empresa.
Logo este trabalho se justifica pela utilização do Ruby on Rails para o desenvolvimen-to de uma aplicação que irá ler informações de um banco de dados já existente e disponibili-zar 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 comuni-cação com um banco de dados existente para a disponibilização de informações internas para sua acessibilidade pela internet.
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 disponibili-zar aos usuários pela internet utilizando o Ruby on Rails. O desenvolvimento do trabalho o-correrá 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 desenvolvi-do.
No Capítulo 2, demonstra-se o arcabouço teórico, que servirá como sustentação ao de-senvolvimento 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 detalha-mento do desenvolvidetalha-mento 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.
2 REVISÃO DA LITERATURA
2.1 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 ori-entada 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 desenvol-vimento tal como códigos confusos e que não dizem o que está sendo e como está sendo exe-cutado. Segundo Matsumoto a linguagem foi criada para que programadores “ordinários” pu-dessem trabalhar (Matsumoto 2001).
Os recursos mais básicos de Ruby são (Matsumoto 2001):
Interpretive programming: Ruby é uma linguagem interpretada, evitando a necessida-de necessida-de compilação, segundo o autor o objetivo necessida-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 runti-me, é 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 pa-ra controlar a itepa-raçã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 re-des.
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
progra-mas ou a si mesmo na hora da compilação ou em runtime, este recurso permite que os pro-gramadores 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 clas-ses feitos em runtime (Flanagam e Matsumoto 2008. p.16).
Segundo o criador do Ruby, a linguagem foi criada pois este não estava completamen-te satisfeito com as linguagens exiscompletamen-tencompletamen-tes. Algumas linguagens eram simples e limitadas de-mais, outras complexas demais. Ruby foi criada para ser tornar a programação simples e rápi-da. 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 uti-lizando esta linguagem (Flanagam e Matsumoto 2008. p.16).
Uma das características que Matsumoto adicionou na linguagem é uma sintaxe bastan-te dinâmica não necessitando seguir regras na digitação do código, um exemplo é a possibili-dade de omitir parentes nas chamadas de funções, passando apenas parâmetros, isso é propo-sital, 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 orientaaplica-ção a ob-jetos dizendo que Ruby todo tipo de valor é um objeto, números são obob-jetos, 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 exem-plo 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 en-capsulamento 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 pro-gramador 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 Mat-sumoto 2008, p. 214).
Outra característica da linguagem é que o programador não precisa definir tipos ou es-copo 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. (Flana-gam 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 admi-nistrar 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.
• A linguagem pode rodar em diversas plataformas.
2.2 FRAMEWORK RAILS
O Ruby on Rails é um framework ágil que combina diversas ferramentas para o de-senvolvimento, este procura tornar fácil o dede-senvolvimento, 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 uti-lizadores 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.
O outro conceito é a Convention over Configuration, isto é, o sistema utiliza conven-ções ao invés de configuraconven-ções, evitando assim tempos e arquivos de configuraconven-ções dentro da aplicação. Todas as aplicações Rails utilizam a mesma estrutura de pastas e os mesmos pa-drõ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 inte-ragem 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, mo-dels 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 guarda-dos no banco de daguarda-dos, 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 co-mo a aplicação irá funcionar, coco-mo os dados serão acessados e tratados do co-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.
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 desenvol-vedor 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 bus-cadas 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 adicionan-do código para ser executaadicionan-do 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 mu-nicí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 contribu-inte deve pagar. Ainda segundo Fabretti (2004, p. 51) o tributo pode ser não vinculado, é co-brado independentemente de o estado estar prestando serviço ao contribuinte, e pode ser gera-do, 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 vincula-do é chamavincula-do de imposto.
melhoria, neste caso o tributo é cobrado quando o estado presta um tipo de serviço ao contri-buinte, 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 administra-tiva 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 sis-tema 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, positi-vas 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 funcionali-dade o contribuinte poderá efetuar consultas de suas pendências para com a administração pú-blica de seu município.
3 METODOLOGIA
3.1 METODOLOGIA DE PESQUISA
Este trabalho utilizará das pesquisas bibliográficas, visto que será feito um levanta-mento 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 co-nhecer 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 quali-tativo.
Esta pesquisa será aplicada com base em uma aplicação desktop que roda na parte ad-ministrativa de uma prefeitura no setor de arrecadação, o objetivo do aplicativo é complemen-tar o aplicativo que está em andamento na entidade provendo maior facilidade para os contri-buintes
Para o desenvolvimento da aplicação, será feito o estudo do framework Rails e da lin-guagem de programação Ruby, em seguida será feito a criação da aplicação utilizando recur-sos 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 encon-tradas 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, se-rá 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.
4 DESENVOLVIMENTO DA PESQUISA E DA APLICAÇÃO
4.1 VISÃO GERAL DO SISTEMA
Para o desenvolvimento da pesquisa foi utilizados principalmente quatro livros e con-sultas em diversos sites da internet e fóruns sobre desenvolvimento de software, essas pesqui-sas visaram aprender como seria o desenvolvimento utilizando o framework Rails, seu fun-cionamento, 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, princi-palmente 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 cria-das 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 For-mat um tipo de forFor-mato onde seu conteúdo pode ser visualizado mas não edita-do. 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 dis-tribuição Fedora versão 16. O banco de dados SQL Server 2005 será executado em uma ma-quina 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 de-senvolvimento 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
parece bastante popular é o TextMate citado também por Thomas e Hansson (2006, p.37) co-mo escolha pessoal. Porém este editor pode ser executado somente em sistemas Apple, tor-nando 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 fo-ram 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 IRe-port, 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 ban-co 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 aplicaaplica-çã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 co-mando 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 es-trutura com o banco de dados, e como as tabelas já existem esta eses-trutura deve ser ignorada, após uma visualização no livro de Griffths não foi localizado uma forma de efetuar o coman-do 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
para o cliente na pasta controllers. Em seguida foi preciso criar um HTML na camada de a-presentação dentro da pasta views, este arquivo além do código HTML permite também códi-go 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 recur-sos e onde está os recurrecur-sos 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 contro-lador 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 mo-del ValoresParcelas que faz consulta e retorna um array com os dados do cadastro. Estes da-dos então são enviada-dos 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 control-ler 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 organi-zar 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 uni-tários para estas classes validando as regras do sistema. Após a finalizar a programação bas-tou efetuar a criação de objetos, preencher os dados necessários para que a aplicação já fun-cionasse 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:
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 desenvolvi-mento do código, mas também em seu refinadesenvolvi-mento para que estes estivessem prontos a de-senvolver 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 fa-lhar, 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.
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 con-sultas diversas no banco de dados, é o caso desta classe que efetua concon-sultas 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 recolhimen-to, foi criada uma classe para gerar o código de barras e uma para efetuar a gravação dos da-dos da emissão da guia de recolhimento no banco de dada-dos 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 pa-drã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 bole-tos tem uma chave única chamado de “idDebibole-tosBloqueto” 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.
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 ClassifiCertidao que é responsável por verificar se o cadastro possui débitos, em caso positivo o ca-dastro 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 pre-feitura), 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 co-mo 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 rea-lizar as funções. As operações em ambas as classes utilizando os modelos foi somente para
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 pri-meira 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 ConsultaCon-troller, a diferença é que esta efetua uma comunicação com o repositório de relatório e envia
um arquivo PDF para o usuário contendo os dados dos débitos do usuário que ainda não fo-ram 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 Emis-saoGuiaController, 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 en-viados da view e para cada valor ela efetuará a gravação de um registro na tabela DébitosBlo-queto, que como será visto no próximo tópico é a tabela responsável por identificar qual pa-gamento se refere a qual conta.
Para gravar um registro na DebitosBloqueto a classe GravarDebitosBloqueto deve re-unir 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 tabe-la, 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
possível acessar a tabela. O comando primary_key diz ao Ruby on Rails qual é a chave prima-ria 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 princi-pais para efetuar a gravação da tabela para posteriormente identificar qual o débito no mo-mento 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 re-colhimento para o usuário. Este relatório da guia também tem sua consulta de dados configu-rada 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 princi-pal 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 da-dos são buscada-dos do banco de dada-dos 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 visuali-zado 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.
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 de-senvolvimento 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 Uni-xODBC e FreeTDS, a configuração funcionou bem e pôde feita a conexão entre os dois sis-temas, 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 confi-gurar o database.yml para acessar o SQL Server instalado em outra maquina. O arquivo data-base.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 pos-sível o framework Rails comunicar com as tabelas do banco de dados, as alterações necessá-rias para isso foram poucas alterações necessánecessá-rias e não foram encontradas muitas dificulda-des 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 princi-pio 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
reco-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.
Figura 7: Diagrama de Entidade Relacionamento
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 for-necem 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, ape-sar desta não ter ligação com as tabelas que guardam as contas, as informações destas são sal-vas 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 latórios para a aplicação. O Jasper Server é, segundo o site jasperforge.org um servidor de re-lató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 de-sign visual de relatórios, visto que segundo pesquisas pelo site Google não foi possível locali-zar 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.
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 a-cordo 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 rela-tó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 Tom-cat 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 comuni-caçã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 uti-lizado 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 re-cursos, apenas será utilizado a chamada dos relatórios pelo sistema em Ruby.
Figura 8: Requisição SOAP do relatório
O XML da figura 8 então é empacotado numa requisição POST criado via Ruby e en-viado 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 CONSIDERAÇÕES FINAIS
5.1 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 execu-tadas 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
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 da-dos. 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 de-senvolvedor buscar dados do banco como um comando select assim qualquer tipo de infor-maçã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 po-dendo 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 proble-mas.
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 sim-ples, 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 funcionalida-des puderam ser implementadas sem muitas dificuldafuncionalida-des, apesar do banco de dados não se-guir 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 com-postas (apesar de estas existirem no diagrama, elas não foram necessárias). Desta forma fica
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
