UNIVERSIDADE ESTADUAL DE MARINGÁ DEPARTAMENTO DE INFORMÁTICA

Transcrição

1 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

2 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

3 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

4 SUMÁRIO 1 INTRODUÇÃO DEFINIÇÃO DO PROBLEMA JUSTIFICATIVA OBJETIVO GERAL OBJETIVOS ESPECÍFICOS DELIMITAÇÃO DO ESTUDO ORGANIZAÇÃO DO ESTUDO REVISÃO DA LITERATURA LINGUAGEM DE PROGRAMAÇÃO RUBY FRAMEWORK RAILS CONTROLE TRIBUTÁRIO METODOLOGIA METODOLOGIA DE PESQUISA DESENVOLVIMENTO DA PESQUISA E DA APLICAÇÃO VISÃO GERAL DO SISTEMA CONTROLLERS DA APLICAÇÃO CLASSES DE NEGÓCIOS BANCO DE DADOS EMISSÃO DE RELATÓRIOS CONSIDERAÇÕES FINAIS CONCLUSÃO REFERENCIAS... 33

5 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

6 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. web. Palavras Chaves: Ruby on Rails, Banco de dados, Framework web, Desenvolvimento

7 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 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

8 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

9 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 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 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

10 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 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 progra- 10

11 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 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 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 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

12 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. A linguagem pode rodar em diversas plataformas. 2.2 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

13 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

14 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

15 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 METODOLOGIA 3.1 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

16 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

17 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 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

18 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 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 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

19 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ó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

20 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

21 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

22 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 Classifica- Certidao 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

23 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

24 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

25 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

26 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

27 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

28 Figura 7: Diagrama de Entidade Relacionamento O diagrama da figura 7 nos mostra como está organizado o banco de dados, a tabela de 28