Você está na página 1de 75

CENTRO UNIVERSITRIO LUTERANO DE SANTARM CURSO DE SISTEMAS DE INFORMAO MANOEL FERNANDO CARDOSO BENTES

DESENVOLVIMENTO DE UM CONTROLE DE CAIXA/BANCO USANDO JAVA E HIBERNATE

SANTARM 2011

MANOEL FERNANDO CARDOSO BENTES

DESENVOLVIMENTO DE UM CONTROLE DE CAIXA/BANCO USANDO JAVA E HIBERNATE

Trabalho de concluso de curso apresentado para a obteno do grau de bacharel em Sistemas de Informao pelo Centro Universitrio Luterano de Santarm. Orientador: Prof. Pedroso Arajo. Esp. Carlos Alberto

SANTARM 2011

MANOEL FERNANDO CARDOSO BENTES

DESENVOLVIMENTO DE UM CONTROLE DE CAIXA/BANCO USANDO JAVA E HIBERNATE

Trabalho de concluso de curso apresentado para a obteno de grau de bacharel em Sistema de Informao pelo Centro Universitrio Luterano de Santarm.

Data de apresentao: _____/_____/_____.

_________________________________ NOME Titulao Instituio

_________ Conceito

_________________________________ NOME Titulao Instituio

_________ Conceito

_________________________________ NOME Titulao Instituio

_________ Conceito

A minha famlia, pelo grande incentivo, fora e contribuio para minha formao pessoal. Aos mestres que atravs de seus conhecimentos, contriburam para a minha formao profissional.

AGRADECIMENTOS

Primeiramente a Deus, por me fazer acordar todos os dias, por me presentear pela companhia de grandes pessoas as quais eu posso chamar de amigos, e pelas oportunidades que surgiram durante minha vida.

Aos meus pais Manoel Walberto Ferreira Bentes e Ivanilda Mota Cardoso, por terem me dado oportunidade de cursar uma faculdade, pela fora e esforo que fizeram durante a minha jornada acadmica. E as minhas irms Aline e Janaynna por todo o carinho e pacincia que me destinaram.

A minha namorada Mythian Bastos Queiroz, que esteve ao meu lado durante todo o desenvolvimento deste trabalho, pela compreenso, fora e ajuda nos momentos difceis.

Aos professores do curso de Sistemas de Informao pelo conhecimento compartilhado e pela minha formao acadmica. E em especial ao meu amigo e orientador Carlos Alberto Pedroso Arajo, pela confiana, ateno, dedicao e grande ajuda na realizao deste trabalho.

Aos amigos e colegas, os quais eu tive a honra de conviver, por todo o apoio e ajuda e pelo compartilhamento de ideias.

E por fim, a todos os que participaram direta ou indiretamente para o xito na concluso dessa jornada.

RESUMO

Com a crescente evoluo das tecnologias o produto software tem se tornado importante para as organizaes, sendo que inmeras tarefas s so possveis de serem realizadas com a presena de um sistema de informao que as automatize. Normalmente, um sistema bem projetado consegue obter maior simplicidade no desenvolvimento e consequentemente melhores resultados em sua manuteno, sendo assim, a utilizao de alguns frameworks nos permite garantir essas melhorias. Este trabalho descreve a proposta de desenvolvimento de um software voltado para o gerenciamento do caixa/banco de uma empresa, utilizando uma ferramenta de mapeamento objeto/relacional denominada Hibernate. A metodologia utilizada para o desenvolvimento do trabalho foi o levantamento bibliogrfico e posteriormente o estudo das tecnologias, levantamento de dados, escolha de um processo para o desenvolvimento e ento o desenvolvimento do projeto. Sendo assim, um estudo mais detalhado do framework utilizado foi realizado, de modo a estimular o interesse de utilizao do mesmo, para o meio acadmico do curso de Sistemas de Informao. Palavras-chave: Hibernate. Framework. Mapeamento Objeto/Relacional.

ABSTRACT

With the increasing development of technologies the software product has become important for organizations, and many tasks are only possible to be performed in the presence of an information system that automates. Normally, a well designed system can achieve greater simplicity in the development and therefore better results in their maintenance, so the use of some frameworks allow us to guarantee these improvements. This paper describes the proposed development of software aimed at managing the cash/bank of a company using a tool for object/relational mapping called Hibernate. The methodology used to develop the study was the literature and later the study of technology, data collection, choice of a process for developing and then develop the project. Therefore, a more detailed study was conducted using the framework in order to stimulate interest in using it, for the academic course of Information Systems. Key-words: Hibernate. Framework. Object/Relational Mapping.

LISTA DE ILUSTRAES

Figura 1 - Diagrama de Atividades, representando as fases de Planejamento, Desenvolvimento e Encerramento com as atividades (em azul) e artefatos (em verde). ....................................................................................................................... 25 Figura 2 - Atuao do Hibernate dentro de uma aplicao. ...................................... 28 Figura 3 - Arquitetura do Hibernate em um sistema simples. .................................... 29 Figura 4 - Diagrama de Casos de Uso geral do Sistema. ......................................... 37 Quadro 1- Descrio dos Casos de Uso. .................................................................. 38 Figura 5 - Modelo de negcios. ................................................................................. 38 Quadro 2 - Descrio das Classes do Sistema. ........................................................ 39 Figura 6 - Diagrama de casos de uso do primeiro sprint. .......................................... 41 Figura 7 - Diagrama de classes de domnio do primeiro sprint. ................................ 43 Quadro 3 - Descrio das classes do primeiro sprint. ............................................... 43 Figura 8 - Diagrama de sequncia referente funcionalidade de insero de contas bancrias. .................................................................................................................. 45 Figura 9 - Diagrama de Sequncia referente operao de consulta de contas bancrias. .................................................................................................................. 47 Figura 10 - Diagrama de casos de uso do segundo sprint. ....................................... 48 Figura 11 - Diagrama de Classes de domnio referente ao segundo sprint. ............. 49 Quadro 4 - Descrio das classes do segundo sprint. .............................................. 49 Figura 12 - Diagrama de sequncia referente funcionalidade de insero no caixa. .................................................................................................................................. 51 Figura 13 - Diagrama de sequncia referente funcionalidade de consulta de lanamentos. ............................................................................................................. 53 Figura 14 - Casos de uso do terceiro sprint............................................................... 54 Figura 15 - Classes de Domnio do terceiro sprint. ................................................... 55 Quadro 5 - Descrio das classes do terceiro sprint. ................................................ 56 Figura 16 - Diagrama de Sequncia referente funcionalidade de emisso de relatrio por data. ...................................................................................................... 57 Figura 17 - Diagrama de classes detalhado referente s telas do sistema. .............. 58 Figura 18 - Diagrama de classes detalhado referente s classes de controle e interface InterfaceDao. .............................................................................................. 59 Figura 19 - Diagrama de classes detalhado do pacote br.com.jcaixa.beans. ......... 60 Figura 20 - Diagrama de classes detalhado referente classe CaixaFacade. ......... 61 Figura 21 - Modelo ER do sistema. ........................................................................... 62 Figura 22 - Tela de login do sistema. ........................................................................ 63 Figura 23 - Tela principal do sistema. ....................................................................... 64 Figura 24 - Tela de controle de usurios. .................................................................. 65 Figura 25 - Tela de Manuteno de Contas Bancrias. ............................................ 66 Figura 26 - Tela de Manuteno do Plano de Contas. .............................................. 67 Figura 27 - Tela de Controle de Lanamentos. ......................................................... 68 Figura 28 - Tela de Consulta de Contas Bancrias. .................................................. 69 Figura 29 - Tela de Consulta de Plano de Contas..................................................... 70 Figura 30 - Tela de Consulta de Lanamentos.......................................................... 71 Figura 31 - Tela de Emisso de Relatrio de Lanamentos por perodo. ................. 71

LISTA DE TABELAS

1 - Produto Total........................................................................................................ 39 2 - Atividades realizadas no primeiro sprint. .............................................................. 41 3 - Atividades realizadas no segundo sprint. ............................................................. 48 4 - Atividades realizadas no terceiro sprint. ............................................................... 54

LISTA DE SIGLAS

API - Interface de Programao de Aplicativos AWT Abstract Windowing Toolkit CVS - Concurrent Versions System DAO - Data Access Object EJB Enterprise Java Beans ER - Entidade/relacionamento HQL - Hibernate Query Language IDE - Integrated Development Environment JDBC Java DataBase Connectivity JDK Java Development Kit JIT - Just In Time JPA Java Persistence API JSP Java Server Pages JUDE - Java and UML Developers Environment JVM - Java Virtual Machine ODBC - Open Data Base Connectivity ORM - Mapeamento objeto/relacional P@PSI - Processo gil para Pequenos Sistemas PHP PHP Hypertext Preprocessor POJO - Plain Old Java Object SGBD Sistema de Gerenciamento de Banco de Dados SQL Structured Query Language TI - Tecnologia da Informao UML - Unified Modeling Language WYSIWYG - What You See Is What You Get XML - Extensible Markup Language XP - eXtreme Programming

SUMRIO

1 INTRODUO ....................................................................................................... 13 2 CONSIDERAES INICIAIS ................................................................................. 15 2.1 O PROJETO........................................................................................................ 15 2.1.1 Descrio da Solicitao do Cliente ............................................................. 15 2.1.2 Descrio do Software Atual ......................................................................... 16 2.2 JUSTIFICATIVA .................................................................................................. 16 2.3 FERRAMENTAS E TECNOLOGIAS UTILIZADAS ............................................. 17 2.3.1 JUDE Community UML ............................................................................... 17 2.3.2 DBDesigner ..................................................................................................... 18 2.3.3 Java ................................................................................................................. 18 2.3.3.1 Principais Caractersticas .............................................................................. 19 2.3.4 NetBeans ......................................................................................................... 20 2.3.5 PostgreSQL..................................................................................................... 21 2.3.6 iReport ............................................................................................................. 21 2.3.7 Padro DAO .................................................................................................... 22 2.3.8 POJO ............................................................................................................... 23 2.3.9 Facade ............................................................................................................. 23 2.3.10 Genricos ...................................................................................................... 24 2.4 PROCESSO DE DESENVOLVIMENTO UTILIZADO .......................................... 24 3 HIBERNATE .......................................................................................................... 26 3.1 PERSISTNCIA E MAPEAMENTO OBJETO/RELACIONAL ............................. 26 3.2 ARQUITETURA DO HIBERNATE ....................................................................... 29 3.3 CONSULTAS ...................................................................................................... 31 3.3.1 HQL .................................................................................................................. 32 3.3.2 Criteria Query API........................................................................................... 32 3.3.3 SQLQuery........................................................................................................ 32 3.4 METADADOS DE MAPEAMENTO OBJETO/RELACIONAL .............................. 33 3.4.1 Metadados em XML ........................................................................................ 33 3.4.2 Metadados baseados em Anotaes ............................................................ 33 3.5 MAPEAMENTO DE HERANA .......................................................................... 34 3.6 VANTAGENS E DESVANTAGENS .................................................................... 34 4 DESENVOLVIMENTO ........................................................................................... 36 4.1 FASE DE PLANEJAMENTO ............................................................................... 36 4.1.1 Levantamento de Requisitos ......................................................................... 36 4.1.2 Anlise dos Requisitos .................................................................................. 37 4.2 FASE DE DESENVOLVIMENTO ........................................................................ 40 4.2.1 Criao dos sprints ........................................................................................ 40 4.2.2 Primeiro sprint (01/02 19/02/2011) .............................................................. 41 4.2.3 Segundo sprint (21/02 12/03/2011) ............................................................. 48 4.2.4 Terceiro sprint (14/03 02/04/2011) .............................................................. 54 4.2.5 Modelagem do Sistema.................................................................................. 58 4.3 FASE DE ENCERRAMENTO.............................................................................. 62 4.3.1 Tela de Login .................................................................................................. 63

4.3.2 Tela Principal .................................................................................................. 63 4.3.3 Tela de Controle de Usurios ........................................................................ 64 4.3.4 Tela de Manuteno de Contas Bancrias ................................................... 65 4.3.5 Tela de Manuteno de Plano de Contas ..................................................... 66 4.3.6 Tela de Controle de lanamentos ................................................................. 67 4.3.7 Tela de Consulta de Contas Bancrias ........................................................ 68 4.3.8 Tela de Consulta de Plano de Contas........................................................... 69 4.3.9 Tela de Consulta de Lanamentos ............................................................... 70 4.3.10 Tela de Emisso de Relatrio por Perodo ................................................. 71 5 CONCLUSO ........................................................................................................ 72 REFERNCIAS ......................................................................................................... 74

13

1 INTRODUO

A informtica tem grande importncia na vida da humanidade, pois a mesma encontra-se em vrias reas de pesquisa e produo mundial. Hoje em dia, a busca pela disseminao dessa tecnologia para outras reas constante, o que leva pessoas da rea de TI (Tecnologia da Informao) a se empenharem mais no desenvolvimento de solues que tornem gil o trabalho feito em outras reas. As novas tecnologias, os novos mtodos de programao, a valorizao e o gerenciamento da informao, a simplicidade, a usabilidade, e padres de desenvolvimento e otimizao de processos so peas fundamentais que, juntamente ao usurio, devem compor o desenvolvimento de um sistema. Atualmente, mesmo com o grande nmero de tecnologias disponveis, existem muitas empresas que no fazem uso desses avanos tecnolgicos, gerenciam seus processos sem fazer uso da informtica, ou ento fazem uso dessa tecnologia de forma indevida, resultando na falta de eficincia no trabalho. O controle de caixa/banco um processo que visa promover um gerenciamento nas entradas (crdito ou depsitos) e sadas (dbito ou saques), em dinheiro, de uma empresa. Essas entradas e sadas so registradas em um livro que mostra o histrico e o valor, e informa se a quantia uma entrada ou uma sada. No fim do dia calculado o saldo do caixa, que o resultado do dia anterior somado as entradas e subtrado pelas sadas (saldo do caixa = saldo anterior + entradas sadas). O processo de coleta de dados do controle de caixa/banco da empresa For Business, assim como em muitas outras empresas, feito por meio do uso planilhas eletrnicas do aplicativo Excel do pacote Office da Empresa Microsoft, e este requer que o usurio tenha conhecimento bsico e avanado neste software. Alm disso, o usurio precisa montar frmulas para encontrar o resultado do saldo do caixa. Este trabalho trata o desenvolvimento de um sistema para controle de caixa/banco para a empresa citada anteriormente, com nfase na utilizao do framework Hibernate, atravs do ambiente de desenvolvimento NetBeans. E para organizar o desenvolvimento do projeto e document-lo, utilizou-se o processo de desenvolvimento denominado P@PSI (Processo gil para Pequenos Sistemas), este est descrito no segundo captulo para melhor entendimento do leitor.

14

Este trabalho est dividido em cinco captulos, sendo que no primeiro consta da introduo. O segundo captulo trata das consideraes iniciais, onde so destacadas as tecnologias utilizadas e o processo de desenvolvimento utilizado. O terceiro captulo trata do Hibernate, abordando conceitos como persistncia e mapeamento objeto/relacional, sua arquitetura, tipos de consultas, metadados de mapeamento objeto/relacional, mapeamento de heranas, vantagens e

desvantagens. O quarto captulo apresenta o desenvolvimento do software, destacando as fases de planejamento, desenvolvimento e encerramento do sistema. E por fim, o quinto captulo conclui o presente trabalho.

15

2 CONSIDERAES INICIAIS

Este captulo tem como objetivo contextualizar o tema do projeto, as tecnologias utilizadas e a justificativa para a utilizao das mesmas, colocando definies e descries que venham a facilitar o entendimento deste trabalho.

2.1 O PROJETO

O projeto proposto consiste na elaborao de um sistema para controle de caixa/banco para a Empresa de nome fantasia For Business, que uma empresa de cursos de formao profissional.

2.1.1 Descrio da Solicitao do Cliente

A For Business solicitou atravs de sua diretoria um sistema que realize o controle do caixa/banco da empresa. Durante a reunio, ocorreu a definio do escopo1 do projeto, e com base nos relatos feitos pelo cliente foi possvel definir as funcionalidades que o sistema deveria dispor para satisfazer o problema da empresa. A empresa necessita de um gerenciamento bem efetivo do caixa, de forma que periodicamente ela tenha como saber o valor gasto em cada rea especfica do negcio, como por exemplo: salrios, impostos, energia eltrica, telefone, combustvel para veculos, etc. Alm disso, necessrio gerenciar as contas bancrias, que so uma espcie de caixa, pois tem entradas (depsitos) e sadas (cheques, saques, etc.). O cliente tambm deseja a integrao do caixa dirio s contas do banco. O cliente possui conhecimento da existncia de softwares que tenham como funo o controle do caixa/banco, porm relatou que prefere um sistema que seja

Tudo o que est definido dentro de um projeto.

16

desenvolvido na regio, pela facilidade na manuteno, at mesmo para ocasies de atualizao do software, e treinamento de uso do sistema.

2.1.2 Descrio do Software Atual

O controle do caixa/banco da empresa For Business funciona da seguinte forma: o usurio registra os movimentos do caixa, que so as entradas e sadas de dinheiro. Essas entradas e sadas so escritas em uma planilha do software Excel que exibe o histrico e o valor, e informa se o procedimento de entrada ou de sada. No momento em que uma entrada ou uma sada registrada, o clculo do saldo total efetuado, devido o uso de frmulas matemticas do prprio Excel. Alm de fazer um controle de caixa, a planilha eletrnica tambm utilizada para fazer um gerenciamento de contas bancrias, que por sua vez, funciona como um controle de caixa, onde sero registrados os saques e os depsitos realizados pela empresa em determinada conta bancria.

2.2 JUSTIFICATIVA

Atualmente, para o desenvolvimento de sistemas necessrio fazer uso de linguagens de programao, muitas delas so direcionadas ao paradigma orientado a objeto. Os desenvolvedores de softwares tambm necessitam utilizar uma base de dados para realizar a persistncia dos dados, dentre as existentes, muitos optam pela relacional. Com base nessas escolhas, segundo Arajo (2011), surgem problemas para os desenvolvedores, pois os mesmos acabam lidando com um termo bastante comum denominado diferena de impedncia, que ocorre entre os modelos: relacional e de objetos. Essa diferena evidente, j que o paradigma orientado a objetos est baseado na engenharia de software e o modelo relacional se baseia em princpios matemticos. Mesmo havendo meios para no passar por esta situao, esta maneira ainda a mais utilizada.

17

Arajo (2011) afirma que, para fazer a unio destes diferentes paradigmas no desenvolvimento de um sistema necessrio que o desenvolvedor possua bastante conhecimento de ambos os modelos, ou seja, o programador deve entend-los e tambm deve conhecer as diferenas existentes nos mesmos, para poder realizar o mapeamento de uma representao de dados relacional para um modelo orientado a objetos. Sendo assim, para resolver os problemas existentes devido diferena de impedncia, surgiram diversas ferramentas de mapeamento objeto/relacional, uma delas o framework2 Hibernate, o qual estar sendo abordado no terceiro captulo deste trabalho e utilizado no decorrer do desenvolvimento do sistema.

2.3 FERRAMENTAS E TECNOLOGIAS UTILIZADAS

Antes do desenvolvimento, todo sistema passa por avaliao das tecnologias e ferramentas que se adaptam ao objetivo da equipe de desenvolvedores. Neste tpico so descritas as ferramentas que se adequaram a experincia do desenvolvedor do software, e sequencialmente a metodologia adotada no desenvolvimento do sistema proposto.

2.3.1 JUDE Community UML

Carmo Junior (2010, p.30) afirma que, antes de um sistema ser desenvolvido, de fundamental importncia o uso da prtica da modelagem, pois a mesma auxilia desde a fase de anlise at a fase de planejamento do sistema, com o intuito de facilitar, padronizar e aperfeioar o desenvolvimento do sistema. Segundo Queiroz (2010, p. 19), a UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) uma linguagem visual voltada para a modelagem de sistemas por meio do paradigma Orientado a Objetos.
2

um conjunto de classes e interfaces que cooperam para resolver um tipo de problema de software.

18

De acordo com Berta e Almeida (2006, p.9), o objetivo da modelagem atravs da UML dar auxlio aos engenheiros de software na definio das caractersticas do software, tais como os requisitos, comportamento, estrutura lgica, e at mesmo nas necessidades fsicas em relao ao equipamento sobre o qual o sistema dever ser implantado. Para Berta (2010 apud CARMO JUNIOR, p. 107) JUDE (Java and UML Developers Environment) uma IDE para Modelagem de dados (UML) criada com Java e de uso fcil e intuitivo. Carmo Junior (2010, p. 30) tambm acrescenta que atravs da IDE JUDE h a possibilidade da realizao de uma modelagem de dados mais complexa, e tambm a apresentao dos dados ao usurio de forma simplificada atravs da interface amigvel da IDE.

2.3.2 DBDesigner

De acordo com Carmo Junior (2010), o DBDesigner uma ferramenta utilizada para fazer a modelagem de banco de dados, no qual possibilita a criao de tabelas e seus relacionamentos de forma visual. Alm de criar o diagrama de banco de dados, o DBDesigner possibilita a importao dessa informao para um script de banco de dados. Essa importao feita especialmente para a base de dados MySQL, fazendo a gerao de tabelas e consultas, levando em conta a Sintaxe SQL desse SGBD.

2.3.3 Java

Segundo Jandl Junior (2007, p.20), Java uma plataforma de programao que foi desenvolvida pela empresa Sun Microsystems em 1995. Essa plataforma um ambiente completo de desenvolvimento e execuo de programas que rene vrias facilidades, tais como: orientao a objetos, robustez, portabilidade, operaes em rede (com destaque internet) e segurana.

19

2.3.3.1 Principais Caractersticas

Jandl Junior (2007, p.22) afirma que a linguagem de programao Java possui caractersticas que em conjunto, diferenciam-na de outras linguagens de programao. So elas: Orientada a Objetos: Java considerada uma linguagem puramente orientada a objetos, pois com exceo de seus tipos de dados primitivos, tudo em Java so classes ou instncias de classes. Alm disso, essa linguagem oferece mecanismos de abstrao, encapsulamento e hereditariedade, que so requisitos necessrios para uma linguagem ser considerada orientada a objetos. Independente de Plataforma: Java uma linguagem de programao independente de plataforma, ou seja, os programas desenvolvidos em Java no so compilados para uma determinada plataforma de hardware, mas sim para um formato intermedirio conhecido como bytecode, que interpretado pela JVM (Java Virtual Machine) para a plataforma na qual executada. Performance: A linguagem Java foi projetada para ser compacta, independente de plataforma e para a utilizao em rede, razo pelo qual passou a ser interpretada com o emprego de bytecodes. Logo nas primeiras verses, o Java tinha desempenho razovel devido os mecanismos de interpretao. Mas essa falha foi corrigida, pois, foi inserido um compilador JIT (Just In Time) na JVM, com a capacidade de converter os bytecodes em cdigo nativo durante a carga do programa, o que possibilitou timos resultados no desempenho dos programas.

20

Segurana: Java foi elaborado para ser utilizado em ambientes em rede/distribudos. Por causa disso, muita nfase foi dada a segurana. Java permite a construo de sistemas livres de vrus e falsificao.

2.3.4 NetBeans

De acordo com Gonalves (2006), o NetBeans um ambiente de desenvolvimento, IDE, escrito totalmente em Java. Este projeto foi fundado pela empresa Sun Microsystems em junho de 2000. Gonalves (2006) afirma que a IDE NetBeans vem evoluindo rapidamente a cada verso, o que torna essa IDE competitiva junto as melhores ferramentas de desenvolvimento Java do mundo. Essa IDE possui vrias funcionalidades que vem atraindo cada vez mais desenvolvedores do mundo inteiro:

Um editor amigvel de telas AWT/Swing; Suporte completo ao Java Enterprise Edition; Integrao com banco de dados; Plug-ins de diversos tipos que estendem a capacidade do programa; CVS; Depurador de aplicativos e componentes JSPs e EJBs; Suporte para desenvolvimento e consumo de WebServices, entre outros;

O NetBeans IDE um premiado ambiente de desenvolvimento integrado disponvel para Windows, Mac, Linux e Solaris. O projeto NetBeans consiste em um open-source IDE e uma plataforma de aplicaes que permitem aos desenvolvedores criar rapidamente web, enterprise, desktop e aplicaes mveis usando a plataforma Java, bem como o JavaFX, PHP, JavaScript e Ajax, Ruby e Ruby on Rails , Groovy e Grails, e C/C++. (NETBEANS, 2010).

21

2.3.5 PostgreSQL

um poderoso SGBD (Sistema Gerenciador de Banco de Dados) ObjetoRelacional gratuito e de cdigo aberto (NIEDERAUER, 2001). O PostgreSQL tem suporte a quase todas as instrues SQL (Structured Query Language), e contem grande parte dos tipos de dados do ISO SQL: 1999, incluindo INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL e TIMESTAMP. Alm de possuir mecanismos eficientes de segurana e integridade de dados. Tem recursos que podem ser comparados aos melhores bancos de dados existentes. Outro recurso desse SGBD, o armazenamento de dados binrios, tais como, figuras, sons e vdeos. E ainda possui interfaces nativas de programao para Java, C/C++, .Net, Perl, Python, Ruby, Tcl, ODBC, entre outros (POSTGRESQL, 2010).

2.3.6 iReport

Em 2001, Teodor Danciu criou o JasperReports, que uma biblioteca totalmente escrita na linguagem de programao Java, e possui seu cdigo-fonte aberto. Danciu projetou essa biblioteca para ajudar os desenvolvedores de software a criarem relatrios para aplicaes voltadas tanto para Desktop, quanto para Web, fornecendo uma API que facilita o desenvolvimento desses relatrios. De acordo com Gonalves (2009), apesar de o JasperReports ter trazido simplificao no desenvolvimento de relatrios, o desenvolvedor de software, alm de ter que conhecer o formato XML, para o desenvolvimento dos relatrios, tambm tinha que fazer clculos para posicionar os componentes no relatrio de forma organizada. Em 2002, o italiano Giulio Toffoli, desenvolveu uma ferramenta, de forma independente, para a criao de relatrios de forma visual chamada iReport. E atualmente, essa ferramenta foi reescrita para trabalhar dentro da IDE NetBeans. Gonalves (2009, p.3) afirma que o iReport para NetBeans IDE um programa

22

OpenSource, capaz de criar visualmente os mais complexos relatrios para aplicaes Java no formato da biblioteca JasperReports. Atravs do iReport, o desenvolvedor tem a possibilidade de criar seus relatrios de forma simplificada atravs da interface grfica e de fcil manuseio desta ferramenta. Gonalves (2009) acrescenta, informando que o iReport possui diversas caractersticas que o torna uma ferramenta de desenvolvimento de relatrios profissionais no mesmo nvel de outros tipos de ferramentas voltadas para a criao de relatrios. As caractersticas do iReport so:

Suporte a 100% das tags XML do JasperReports; Editor WYSIWYG para a criao de relatrios, possuindo ferramentas que incluem desenho de retngulos, linhas, elipses, caixas de texto, rtulos, grficos, sub-relatrios, cdigo de barras e etc;

Integrao para compilar e exportar; Suporte para todos os banco de dados acessveis pela ponte JDBC; Assistentes para criar relatrios rapidamente; Suporte a grficos; Bibliotecas de estilos e etc.

2.3.7 Padro DAO

De acordo com Gomes (2008, p.9), O DAO (Data Access Object) o ponto de chamada para utilizar os recursos do banco de dados, tanto para consultas (select), quanto para manipulao de dados (insert, update, delete). DAO um padro de persistncia responsvel pelas operaes (insero, excluso, atualizao e leitura) no modelo de negcios. Gomes (2008) acrescenta que a utilizao do padro DAO permite a separao do cdigo do negcio, do cdigo utilizado para fazer a manipulao de banco de dados. Possibilitando a interdependncia de banco de dados de tal forma que a mudana do mesmo no gera manuteno nas classes de negcios.

23

2.3.8 POJO

Segundo Gomes (2008, p.10), trata-se de um objeto Java utilizado para implementar o modelo de domnio da aplicao. Os POJOs so objetos Java que seguem o padro JavaBeans, sendo conhecido por prever que a classe tenha um construtor padro e mtodos getters e setters para os atributos declarados na mesma. De acordo com Arajo (2011), as classes persistentes de uma aplicao so aquelas que representam as entidades de domnio do negcio. Essas entidades de domnio, normalmente, so classes que possuem muitos objetos e estes, por sua vez, vo armazenar informaes persistentes e logo tero um perodo de vida longo.

2.3.9 Facade

De acordo com Gomes (2008, p. 8), O Facade o ponto de chamada para utilizar as funcionalidades de negcio da aplicao. Se a aplicao possuir uma funcionalidade para realizar clculo do saldo do caixa, por exemplo, haver um mtodo em um Facade apropriado para implementar e executar esse clculo. Gomes (2008) afirma que a vantagem da utilizao de Facades o encapsulamento e o isolamento do cdigo de negcio das classes que interagem com o usurio ou outros sistemas. O que facilita a reutilizao da mesma funcionalidade de negcio por duas ou mais telas, por um ou mais sistemas ou componentes do mesmo.

24

2.3.10 Genricos

Jandl Junior (2007, p.135) define os genricos (generics) como mecanismos para a criao de tipos parametrizados, ou seja, permitem a definio de uma classe ou mtodo para funcionar com uma variedade dos tipos, mas que operar com um tipo particular de cada vez.

Os genricos so um aperfeioamento do mecanismo de controle de tipos do Java que permitem que classes ou mtodos operem sobre objetos de diversos tipos ao mesmo tempo em que prev verificao em tempo de compilao e execuo, eliminando a necessidade de operaes de coero (type casting). Os genricos so provavelmente a caracterstica mais importante introduzida na verso 5 do Java (SUN, 2007 apud Jandl Junior, p.136).

Jandl Junior (2007) afirma que classes e mtodos que fazem uso de generics do a possibilidade de prover funcionalidades comuns que podem ser utilizadas com diferentes tipos de dados.

2.4 PROCESSO DE DESENVOLVIMENTO UTILIZADO

Ser utilizado o P@PSI (Processo gil para Pequenos Sistemas), que uma metodologia gil voltada para pequenos sistemas, desenvolvidos por equipes pequenas e com pouca experincia no ramo de desenvolvimento de sistemas. Essa metodologia gil une os princpios e prticas de mtodos empricos como o Scrum e a XP (eXtreme Programming) com o auxlio da organizao do Processo Unificado, que um processo definido, e possui como caracterstica a incluso de pontos que levam a equipe de desenvolvimento obter hbitos dirios de trabalho que iro trazer produtividade, disciplina e facilidade na comunicao. Segundo Geller (2008), o processo gil P@PSI descrito como sendo gerenciado pelo Scrum, adotando prticas da XP e com fluxos organizados do Processo Unificado. Constitui-se de trs fases: Planejamento, Desenvolvimento e Encerramento, que so representadas na figura 1.

25

Figura 1 - Diagrama de Atividades, representando as fases de Planejamento, Desenvolvimento e Encerramento com as atividades (em azul) e artefatos (em verde). Fonte: GELLER, 2008.

Na fase de planejamento, a equipe de desenvolvimento dever trabalhar na captura de requisitos para definir um produto total. Em seguida, entra-se na fase de desenvolvimento, onde ser feita a priorizao de uma funcionalidade do produto total. E, enfim, entra-se na fase de encerramento, onde ocorre a reviso, a demonstrao e a entrega da funcionalidade ao cliente. Nesse ponto o processo retorna executando uma nova iterao com um conjunto de novas funcionalidades priorizadas dentro de um novo sprint3. Assim que o Produto Total estiver finalizado, o processo encerrado.

Bloco de atividades ou funcionalidades.

26

3 HIBERNATE

Este captulo tem como objetivo apresentar o framework Hibernate, descrevendo sua origem e caractersticas, dando conceitos aos termos persistncia e mapeamento objeto/relacional, exibindo sua arquitetura, e apresentando seus pontos positivos e negativos que serviro de base para o desenvolvedor de sistemas decidir se este meio adequado ou no para ser aplicado ao seu projeto de desenvolvimento. Bauer e King (2007, p.31), definem o Hibernate como um framework de persistncia e mapeamento objeto/relacional (ORM). Este framework foi totalmente escrito e desenvolvido por programadores da linguagem de programao Java. Desenvolvedores que se espalharam pelo mundo inteiro, liderados por Gavin King. E teve a sua primeira verso publicada em 2004. Como se tratava de um projeto pessoal, King utilizava o seu tempo livre para solucionar problemas identificados por outros programadores que utilizavam esse framework. Por motivo da popularidade do Hibernate e, com o aumento de usurios que utilizavam essa ferramenta, King percebeu que a continuao do Hibernate seria invivel de ser mantida apenas em seu tempo livre. Por esse motivo King entrou para o JBoss Group da JBoss Inc. (Empresa comprada pela Red Hat) e esta contratou os principais desenvolvedores desse framework para fazer o suporte mais efetivo do mesmo. O framework Hibernate Open Source, ou seja, o mesmo tem seu cdigo fonte livre, fazendo com que ele seja utilizado e distribudo livremente por programadores do mundo inteiro. O uso do mesmo reduz o tempo de desenvolvimento apoiado nos conceitos de Orientao a Objetos (Herana, Polimorfismo, Composio e o Java Collection), dando nfase para o negcio.

3.1 PERSISTNCIA E MAPEAMENTO OBJETO/RELACIONAL

Para melhor compreenso do funcionamento desde framework necessrio definir o conceito de persistncia.

27

Persistncia um dos conceitos fundamentais no desenvolvimento de aplicaes. Se um sistema de informao no preservar os dados quando ele for desligado, o sistema ser de pouco uso prtico. Quando se fala de persistncia em Java, normalmente est sendo falado sobre como guardar dados em um banco de dados relacional usando SQL. Em uma aplicao orientada a objetos, a persistncia permite a sobrevivncia de um objeto ao processo que o criou. O estado do objeto pode ser guardado no disco, e um objeto com um mesmo estado pode ser recriado em algum ponto futuro (BAUER; KING, 2007, p.5).

Smolenaars e Costa (2005, p.46) relatam que a camada de persistncia encapsula o acesso direto ao banco de dados pela aplicao, fazendo com que o banco de dados torne-se mais confivel, pois isola as operaes de acesso direto ao mesmo. O termo mapeamento objeto/relacional consiste de uma tcnica responsvel em mapear uma representao de dados de um modelo de objetos para um modelo de dados relacional, baseando-se em um modelo ER (Entidade/relacionamento). Para Arajo (2011) o Mapeamento Objeto-Relacional a persistncia, ou seja, o armazenamento de objetos criados em uma aplicao, para tabelas em um banco de dados relacional [...].

Alm de criar o mapeamento objeto/relacional, o Hibernate uma ferramenta que possui facilidades para realizar operaes de banco de dados tanto para consultas (queries), quanto para a manipulao de dados (insert, update, delete) e pode reduzir significativamente o tempo de desenvolvimento comparado ao alto tempo gasto pelas operaes manuais de dados feitas com SQL e JDBC (PRIMO; SANTOS, 2009, p.46).

Primo e Santos (2009, p.46) afirmam que o Hibernate uma ferramenta de consulta e persistncia objeto/relacional de alta performance, que tem como funo transformar as classes Java em tabelas de banco de dados, e tipos de dados Java em tipos de dados SQL. De acordo com Smolenaars e Costa (2005, p.47), o Hibernate fica posicionado como uma camada entre a aplicao e o banco de dados, tratando de carregar e salvar objetos. A figura 2 mostra a atuao do Hibernate dentro de uma aplicao.

28

Figura 2 - Atuao do Hibernate dentro de uma aplicao. Fonte: PRIMO; SANTOS, 2009.

Mazzi (2010) afirma que, atualmente, o projeto Hibernate encontra-se na verso 3.x, a qual absorveu diversas caractersticas e inovaes, tais como, anotaes JDK 5.0 (Metadados da linguagem Java), que surgiu como uma alternativa aos mapeamentos criados com arquivos XML. E informa que durante o mapeamento objeto/relacional, possvel adicionar gerao automtica de chaves primrias para cada identidade. Esse mapeamento pode ser feito de duas formas, uma delas fazendo uso de arquivos XML para fazer a comunicao com os POJOs (Plain Old Java Objects). O outro modo de mapear os POJOs utilizando anotaes (annotations) do JDK 5.0. Sua caracterstica mais importante, de acordo com Rocha (2010), a transformao das classes Java para tabelas de bancos de dados e dos tipos de dados Java para tipos de dados SQL.

29

3.2 ARQUITETURA DO HIBERNATE

Segundo Smolenaars e Costa (2005, p.49), a arquitetura do Hibernate depende da complexidade do projeto, do nmero de APIs e de componentes que so utilizados. A figura 3 exibe a arquitetura do Hibernate.

Figura 3 - Arquitetura do Hibernate em um sistema simples. Fonte: SMOLENAARS; COSTA, 2005.

De acordo com as especificaes do Hibernate, segundo Bauer e King (2007), os componentes so definidos da seguinte forma: SessionFactory (org.hibernate.SessionFactory): a fbrica de sesses, ou seja, um objeto utilizado para obter sesses de conexo com o banco de dados, e carregar as configuraes compiladas do Hibernate que foram definidas na aplicao. Esse um objeto pesado, ou seja, na primeira execuo a aplicao demora alguns segundos para iniciar. Session (org.hibernate.Session): o objeto que tem como funo iniciar uma sesso de acesso a dados, e obtida por meio da fbrica de sesses.

30

Em outras palavras, a Session funciona como um dilogo entre a aplicao e a persistncia (banco de dados). Esse objeto faz o controle de um cache de objetos persistentes, sendo que esses objetos tm a vida curta. Persistent Objects: So objetos manipulados, em outras palavras, so os POJOs do projeto (devem possuir construtor sem parmetros e mtodos get/set para os atributos da classe). Transient Objects: So instncias de classes persistentes que no esto associadas a uma Session. Os Objetos instanciados atravs do operador new no so imediatamente persistentes. O estado deles transiente, ou seja, eles no esto associados a qualquer linha de tabela de banco de dados, fazendo com que o estado deles seja perdido e no seja mais referenciado por qualquer outro objeto. Transaction (org.hibernate.Transaction): Objeto utilizado para fazer as transaes com o banco de dados.

O framework Hibernate formado de vrios mdulos Java, que podem ser combinados de acordo com o tipo de projeto escolhido. Arajo (2011) afirma que essa combinao depende dos requisitos de negcio e das tcnicas que o programador optar para o projeto. Estes so os mdulos do Hibernate: Hibernate Core: este o prprio Hibernate, ou seja, a base para a persistncia que constitui todos os outros mdulos citados abaixo. Atravs deste mdulo possvel realizar o mapeamento objeto/relacional fazendo uso da XML. Hibernate Annotations: atravs deste mdulo, o desenvolvedor tem a possibilidade de criar o mapeamento objeto/relacional fazendo o uso de anotaes do JDK 5, tornando-se uma opo para quem no deseja desenvolver utilizando XML.

31

Hibernate Entity Manager: este mdulo uma implementao da JPA4 (Java Persistence API). A EntityManager responsvel por praticamente todas as operaes de persistncia de objetos. Hibernate Shards: este um framework utilizado para encapsular e simplificar o particionamento de dados horizontal, que so vrias instncias de bancos de dados e os dados da aplicao divididos entre eles. Hibernate Validator: este um conjunto de anotaes que aplicado s classes persistentes para definir regras de integridade e validao de dados. Hibernate Search: este mdulo a integrao do Hibernate com o motor de busca Lucene para indexao e consulta de dados. Hibernate Tools: esta uma ferramenta de desenvolvimento para a IDE Eclipse e Ant implementada com um conjunto de plug-ins. Hibernate Evens: este componente responsvel por facilitar a auditoria e o controle de verses de classes persistentes atravs do uso de anotaes.

3.3 CONSULTAS

Uma das caractersticas do Hibernate, segundo Arajo (2011), est presente na parte de consultas, pois o mesmo incorpora trs meios para realizar buscas de registros em bancos de dados: a HQL (Hibernate Query Language), a Criteria Query API e a SQLQuery.

API padro do Java para persistncia que deve ser implementada por frameworks que queiram seguir o padro.

32

3.3.1 HQL

O Hibernate oferece uma poderosa linguagem de consulta que possui sintaxe semelhante a SQL e com suporte a consultas polimrficas. A HQL uma extenso da SQL com alguns recursos de orientao a objetos, que fazem com que o programador no referencie tabelas, mas sim, objetos da classe que foram mapeados para as tabelas de bancos de dados.

3.3.2 Criteria Query API

A Criteria Query API formada por um conjunto de classes com intuito de montar queries5 em cdigo Java, onde o programador define todos os critrios de busca com apoio completo de agregaes (aggregation), projees (projection) e sub-consultas (subselects), adicionando restries (restrictions) de pesquisa chamando mtodos da classe relacionada. Segundo Linhares (2010), nesse que tipo o de consulta tudo ganhe definido as

programaticamente,

fazendo

com

programador

todas

funcionalidades inerentes da POO (Programao Orientada a Objetos) para montar consultas de forma personalizada.

3.3.3 SQLQuery

De acordo com Arajo (2011), esse tipo de consulta possui a sintaxe SQL nativa de cada SGBD suportado pelo Hibernate.

Consultas de banco de dados.

33

3.4 METADADOS DE MAPEAMENTO OBJETO/RELACIONAL

Para Arajo (2011), os metadados de mapeamento objeto/relacional so as informaes que faro a gerncia do mapeamento entre as classes e as tabelas de banco de dados, propriedades dos campos das classes e colunas das tabelas, associao de classes e chaves estrangeiras, tipos de dados da linguagem Java e tipos de dados SQL, etc. O Hibernate possibilita ao desenvolvedor de software duas formas para fazer o mapeamento objeto/relacional, uma atravs da linguagem XML (eXtensible Markup Language), a outra maneira atravs de anotaes.

3.4.1 Metadados em XML

A linguagem de marcao XML o formato de metadados objeto/relacional mais utilizado por desenvolvedores que utilizam o Hibernate, j que um meio bastante legvel e de fcil entendimento. Para King (2011 apud Arajo), documentos de mapeamento escritos em XML devem ser leves, facilmente manipulados por editores de texto, de leitura fcil e customizveis tanto durante o desenvolvimento quanto em tempo de execuo.

3.4.2 Metadados baseados em Anotaes

Diferente da utilizao dos metadados com o uso da XML onde os arquivos .xml ficam separados das classes de negcio, os metadados baseados em anotaes so colocados junto das informaes que eles descrevem, ou seja, esses metadados estaro localizados nas classes de negcio, tambm chamadas de POJOs. Segundo Arajo (2011), As anotaes so informaes precedidas por arroba (@) inseridas no cdigo fonte e que so ignorados pelo compilador.

34

3.5 MAPEAMENTO DE HERANA

Como dito no incio deste captulo, o framework Hibernate se apoia nos conceitos de orientao a objetos. Atravs da utilizao do Hibernate, o desenvolvedor de software tem a possibilidade de mapear herana para tabelas de banco de dados. De acordo com Arajo (2011), h trs meios para realizar esse mapeamento:

Mapear toda a hierarquia para uma nica tabela, onde todos os atributos das classes sero mapeados para uma nica tabela;

Mapear cada classe concreta da hierarquia para sua prpria tabela, onde cada tabela ir conter, alm dos atributos criados na classe, aqueles atributos que so herdados;

Mapear cada classe para sua prpria tabela, onde sero criadas tabelas para cada classe.

3.6 VANTAGENS E DESVANTAGENS

Bauer e King (2007, p.29) citam que o framework Hibernate conta com as seguintes vantagens:

Produtividade: permite que o programador se concentre na lgica do negcio da programao;

Manutenibilidade: Reduz significativamente o nmero de linhas de cdigo e faz a separao da camada de persistncia da camada de negcios;

35

Performance: Uma reivindicao comum que a persistncia codificada mo possa sempre ser pelo menos to rpida, e frequentemente ser mais rpida, quanto uma persistncia automatizada;

Independncia de Fabricante: O Hibernate no fica restrito a somente um banco de dados. Como o mesmo possui classes de dialeto SQL, isso faz com que a aplicao desenvolvida nesse framework tenha portabilidade em grande parte dos bancos de dados relacionais.

O Hibernate possui as seguintes desvantagens:

O framework Hibernate no uma boa opo para todo o tipo de aplicao, ou seja, aplicaes que fazem uso extensivo de stored procedures, triggers ou que programam a maior parte da lgica da aplicao no banco de dados, que esteja contando com modelo de objetos pobre no vai se beneficiar com o uso do Hibernate (LINHARES, 2010).

Ou seja, o desenvolvedor pode optar pelo uso do Hibernate se o mesmo concentrar toda a lgica do negcio na aplicao. Alm disso, o Hibernate possui suporte apenas a bancos de dados relacionais.

36

4 DESENVOLVIMENTO

Neste captulo sero descritas as etapas do desenvolvimento do sistema. O processo utilizado formado por trs fases, so elas: Planejamento,

Desenvolvimento e Encerramento.

4.1 FASE DE PLANEJAMENTO

A fase de Planejamento iniciada atravs do contato com o representante da empresa para qual est sendo desenvolvido o software. No caso o cliente o diretor de uma empresa de cursos profissionalizantes denominada pelo nome fantasia de Profisso. Nesta fase est incluso o Levantamento de Requisitos e a Anlise dos Requisitos, que definem o Produto Total, que o conjunto de estrias de usurios que definem as funcionalidades de um sistema.

4.1.1 Levantamento de Requisitos

Como dito no inicio do capitulo 2, a empresa para qual est sendo desenvolvido o software destinada a venda de cursos profissionalizantes. Ao manter contato com a empresa, houve a possibilidade de se fazer verificaes com intuito de encontrar problemas existentes no controle financeiro da mesma. Foi realizada uma entrevista com o cliente e este informou os problemas existentes, com foco nas operaes que fazem entradas e sadas no livro-caixa6 da empresa. Com base nas informaes cedidas durante a reunio com o cliente, foi possvel fazer o levantamento de requisitos, com foco nos requisitos funcionais que so essenciais para atender as necessidades do cliente, e em seguida, com os requisitos no funcionais no qual ser tratada a interface grfica do software.

Nele so registrados todos os fatos administrativos que envolvam entradas e sadas de dinheiro (RIBEIRO, 1996, p.86).

37

4.1.2 Anlise dos Requisitos

Depois do estudo realizado com base no levantamento de requisitos, foram definidos os seguintes casos de usos que so exibidos na figura 4, e so descritos no quadro 1.

Figura 4 - Diagrama de Casos de Uso geral do Sistema.

Manter Usurio

Manter Banco

Manter Plano de Contas

O administrador poder cadastrar usurios para que possam utilizar o sistema. O administrador poder incluir, remover ou alterar dados dos usurios. J o usurio comum s realizar o controle do caixa. O usurio pode efetuar a incluso, remoo, alterao e consulta dos dados sobre a Conta Bancria. O usurio pode efetuar a incluso, remoo, alterao e consulta dos dados sobre o Plano de Contas7.

o agrupamento ordenado de todas as contas que so utilizadas pela contabilidade dentro de determinada empresa (MARION, 2009, p.124).

38

Manter Lanamentos

Emitir Livro-caixa

Emitir Relatrio de Lanamentos por Data

Fazer Login

O usurio pode efetuar a incluso, remoo, alterao e consulta dos dados sobre os lanamentos8 efetuados no caixa. Este caso de uso apresentar o Livrocaixa contendo todos os lanamentos efetuados no Sistema. Este caso de uso apresentar o relatrio de Lanamentos por um perodo especificado. Este caso de uso representa que um usurio comum ou o administrador s podero acessar o sistema aps fazerem login.

Quadro 1- Descrio dos Casos de Uso.

Para atender os casos de uso, foram criadas as seguintes classes: PlanoDeContas, Banco, Caixa, Usurio, Administrador e Usurio, as duas ltimas herdam atributos e mtodos da classe Pessoa. Essas classes devem possuir atributos necessrios para armazenar os dados no sistema. A figura 5 exibe o modelo de negcios do sistema e o quadro 2 descreve estas classes.

Figura 5 - Modelo de negcios.

Caixa

Representa a classe do sistema referente ao caixa que responsvel por lanar todas as entradas e sadas, em dinheiro, da empresa. Essa classe possui dois construtores, um vazio e outro com parmetro para o id, seus atributos e mtodos getters e setters.

o meio pelo qual se processa a escriturao contbil. a forma mercantil de se processar o registro dos fatos no livro dirio (RIBEIRO, 2002).

39

Banco

Representa a classe do sistema referente a contas bancrias que ir registrar as mesmas no banco de dados. Essa classe possui dois construtores, um vazio e outro com parmetro para o id, seus atributos e mtodos getters e setters. Representa a classe do sistema referente ao plano de contas que responsvel por agrupar todas as contas da empresa. Essa classe possui dois construtores, um vazio e outro com parmetro para o id, seus atributos e mtodos getters e setters. Representa a classe do sistema referente ao usurio, ou seja, atravs dessa classe ser possvel inserir usurios no sistema. Essa classe herda os atributos e mtodos da classe Pessoa. Representa a classe do sistema referente ao Administrador, ou seja, essa classe vai conter o usurio com privilgios administrativos para inserir usurios no sistema. Essa classe herda os atributos e mtodos da classe Pessoa. Representa a classe do sistema referente a Pessoa que estende seus atributos e mtodos para as classes Administrador e Usuario. Essa classe possui dois construtores, um vazio e outro com parmetro para o id, seus atributos e mtodos getters e setters.
Quadro 2 - Descrio das Classes do Sistema.

PlanoDeContas

Usuario

Administrador

Pessoa

Aps o trmino das descries dos diagramas de casos de uso e de classes, o Produto Total obtido. No produto total definido o que ser desenvolvido no sistema, ou seja, uma lista que contm todas as estrias de usurios que sero atendidas no software. A tabela 1 exibe o Produto Total, apresentando todos os itens, com suas respectivas prioridades e tempo de desenvolvimento.
Tabela 1 - Produto Total.

Produto Total Produto: Controle de caixa/banco Data: 01/02/11 Prioridade Item Descrio Fase de Planejamento alta 1 Levantamento de requisitos alta 2 Modelagem (Casos de Uso) alta 3 Modelagem (Classes)

Estimativa (Horas) 9 5 2 2

40

alta alta alta alta baixa baixa baixa alta alta

4 5 6 7 8 9 10 11 12

Fase de Desenvolvimento Manter usurio Manter banco Manter plano de contas Manter lanamentos Emitir livro-caixa Emitir relatrio de lanamentos por data Fazer login Fase de Encerramento Entrega da documentao do software Entrega do software

141 24 24 24 24 15 15 15 2 1 1

4.2 FASE DE DESENVOLVIMENTO

Na fase de desenvolvimento, determinado o tempo que ser utilizado para a implementao de cada sprint, levando em considerao o nvel de complexidade das funcionalidades. Baseando-se pela tabela que define o produto total, trs sprints sero apresentados neste trabalho.

4.2.1 Criao dos sprints

Seguindo os princpios do P@PSI, os sprints escolhidos pelo desenvolvedor do sistema, corresponde aos casos de uso Manter Banco, Manter Plano de contas, Manter Lanamento, Manter usurio que foram definidos no produto total, como sendo, de prioridade alta. E por fim os casos de uso, Emitir Livro-caixa, emitir relatrios de lanamentos por data e fazer login, que foram definidos, como sendo, de prioridade baixa. Os casos de uso citados acima foram divididos em trs sprints.

41

4.2.2 Primeiro sprint (01/02 19/02/2011)

Depois de analisar o produto total, chega a hora de determinar as tarefas que sero executadas para que o produto seja desenvolvido. O primeiro sprint compreende aos casos de uso: Manter Banco, Manter Plano de contas e Manter usurio, como mostra a figura 6. No produto total, estes casos de uso possuem prioridade alta.

Figura 6 - Diagrama de casos de uso do primeiro sprint.

O presente sprint compreende as tarefas de implementao das telas BancoView, ConsultaBancoView, PlanoDeContasView,

ConsultaPlanoDeContasView e UsuarioView. A tabela 2 mostra detalhadamente as atividades desenvolvidas neste sprint.


Tabela 2 - Atividades realizadas no primeiro sprint.

Primeiro sprint
Produto: Casos de Uso: Perodo: Descrio Modelagem do sistema (casos de uso e classes de domnio) Modelagem do sistema (modelo ER) Definio das Telas Controle de Caixa/Banco Manter Banco, Manter Plano de Contas e Manter Usurio. Trs semanas a partir do dia 01/02/2011 Data de Entrada Data Limite Data de Soluo Semana 1 2 3 3 1 4 Horas Tempo Total 3 1 4

01/02/2011 03/02/2011 02/02/2011 01/02/2011 03/02/2011 02/02/2011 03/02/2011 05/02/2011 05/02/2011

42

Desenvolvimento da Tela BancoView Implementao das funcionalidades (BancoView) Desenvolvimento da Tela PlanoDeContasView Implementao das funcionalidades (PlanoDeContasView) Desenvolvimento da Tela UsuarioView Implementao das funcionalidades (UsuarioView) Desenvolvimento da Tela ConsultaBancoView Implementao das funcionalidades (ConsultaBancoView) Desenvolvimento da Tela ConsultaPlanoDeContas View Implementao das funcionalidades (Consulta PlanoDeContasView) Teste de funcionalidades entre o banco e as telas

07/02/2011 08/02/2011 07/02/2011 08/02/2011 09/02/2011 09/02/2011 10/02/2011 12/02/2011 11/02/2011 12/02/2011 14/02/2011 14/02/2011 15/02/2011 16/02/2011 15/02/2011 15/02/2011 16/02/2011 16/02/2011 16/02/2011 16/02/2011 16/02/2011 17/02/2011 18/02/2011 17/02/2011

4 6 4 4 2 4 6 2 6

4 6 4 6 4 6 2 6

18/02/2011 18/02/2011 18/02/2011

19/02/2011 19/02/2011 19/02/2011 08/02/2011 21/02/2011 19/02/2011

6 1

6 1 57

Tempo total durante as trs semanas:

Como foi dito anteriormente, este sprint foi dividido em cinco telas: BancoView, PlanoDeContasView e UsuarioView, que contm as operaes de cadastro, alterao e excluso de contas bancrias, plano de contas e usurios no sistema; e ConsultaBancoView, ConsultaPlanoDeContasView, que possuem somente uma operao que a de consultar contas bancrias e plano de contas. Estas telas sero apresentadas na fase de encerramento deste trabalho. Antes da definio das telas, foi feita a documentao do sistema, onde foram criados os diagramas de classes e os diagramas de sequncia. Durante o desenvolvimento do sistema, esses diagramas foram criados e melhorados de acordo com a necessidade que ia surgindo. Para atender este sprint, foi necessria a criao das seguintes classes: BancoView, PlanoDeContasView, DaoGenerico, UsuarioView,ConsultaBancoView, BancoBean, PlanoDeContaBean,

ConsultaPlanoDeContasView,

43

UsuarioBean, AdministradorBean e PessoaBean. A figura 7 mostra o diagrama de domnio referente ao primeiro sprint e o quadro 3 descreve estas classes.

Figura 7 - Diagrama de classes de domnio do primeiro sprint.

BancoView PlanoDeContasView UsuarioView ConsultaBancoView ConsultaPlanoDeContasView DaoGenrico BancoDao PlanoDeContasDao PessoaBean AdministradorBean UsuarioBean PlanoDeContasBean BancoBean
Quadro 3 - Descrio das classes do primeiro sprint.

Classes responsveis por fazer a comunicao do mundo externo com o sistema.

Classes controladoras responsveis pelas operaes de banco de dados.

Entidades do sistema.

44

Em seguida, na figura 8, o diagrama de sequncia de Manter Banco mostra quais passos o usurio deve seguir para fazer a insero de uma conta bancria no sistema. Para o usurio realizar esta operao necessrio, primeiramente que o mesmo faa login no sistema. Assim que o usurio realiza o login a tela Principal exibida, e a partir da, faz acesso tela de cadastro de Contas Bancrias (BancoView). O usurio cria um novo registro, informa os dados solicitados e salva as informaes. Ao realizar a operao de insero, a tela BancoView faz acesso a classe DaoGenrico, passando como argumento um objeto do tipo BancoBean, em seguida solicita o mtodo salva( ), enviando as informaes para a serem salvas no banco de dados.

45

Figura 8 - Diagrama de sequncia referente funcionalidade de insero de contas bancrias.

46

O diagrama de sequncia representado na figura 9 exibe a operao de consulta de Contas Bancrias. Neste diagrama, o usurio, primeiramente faz login no sistema, acessa a tela principal, e em seguida faz acesso a tela de consulta de contas bancrias. A partir da o usurio informa o nmero da conta bancria e a classe BancoDao executa a pesquisa no banco de dados. Se existir alguma conta bancria, a mesma ser exibida.

47

Figura 9 - Diagrama de Sequncia referente operao de consulta de contas bancrias.

48

4.2.3 Segundo sprint (21/02 12/03/2011)

O presente sprint foi escolhido por possuir prioridade alta e tambm por ser parte principal do sistema, ou seja, esta parte que vai conter as funcionalidades que faro o controle do caixa da empresa. Este sprint possui somente um caso de uso que o Manter lanamento, como mostra a figura 10. E este sprint foi definido no produto total como sendo, de prioridade alta e o mesmo mostra as atividades realizadas na tabela 3.

Figura 10 - Diagrama de casos de uso do segundo sprint.

Assim como o sprint anterior, este sprint tambm foi dividido em telas: CaixaView e ConsultaLancamentoView.
Tabela 3 - Atividades realizadas no segundo sprint.

Produto: Casos de Uso: Perodo:

Segundo sprint Controle de Caixa/Banco Manter Lanamento Trs semanas a partir do dia 21/02/2011 Semana Data de Entrada Data Limite Data de Soluo Horas Tempo Total 3 1 4 8 8 16

Descrio Modelagem do sistema (casos de uso e classes de domnio) Modelagem do sistema (modelo ER) Definio das Telas Desenvolvimento da Tela CaixaView Implementao das funcionalidades (CaixaView) Desenvolvimento da Tela ConsultaLancamentoVie w

1 2 3 1 4 8 8

21/02/2011 22/02/2011 21/02/2011 21/02/2011 22/02/2011 21/02/2011 22/02/2011 22/02/2011 22/02/2011 23/02/2011 24/02/2011 24/02/2011 24/02/2011 04/03/2011 03/03/2011

04/03/2011 05/03/2011 05/03/2011

49

Implementao das funcionalidades (ConsultaLancamentoVie w) Teste de funcionalidades entre o banco e as telas

05/03/2011 12/03/2011 12/02/2011

16

24/02/2011 14/03/2011 12/03/2011

1 57

Tempo total durante as trs semanas:

Para atender este sprint foi necessria a criao das seguintes classes: CaixaView, ConsultaLancamentoView, CaixaBean e CaixaDao. A figura 11 mostra o diagrama de domnio referente ao presente sprint, e o quadro 4 descreve estas classes.

Figura 11 - Diagrama de Classes de domnio referente ao segundo sprint.

CaixaView

Classes responsveis por fazer a comunicao do

ConsultaLancamentoView mundo externo com o sistema. DaoGenerico CaixaDao BancoBean CaixaBean PlanoDeContasBean
Quadro 4 - Descrio das classes do segundo sprint.

Classes controladoras responsveis pelas operaes de banco de dados.

Entidades do sistema.

50

O diagrama a seguir mostra as interaes necessrias para a insero de um lanamento no caixa, e est ilustrado na figura 12. Este diagrama se assemelha, em parte, com o diagrama do sprint anterior. O que os difere o acesso a classe CaixaFacade, que responsvel por calcular o total de dbito 9, crdito10 e o saldo do caixa. Ao finalizar a insero dos dados no caixa, so chamados os mtodos calculaTotalDeDebito(), calculaTotalDeCredito() e calculaSaldoTotalDoCaixa().

10

Aplicao de Recursos (RIBEIRO, 2002). Origem de Recursos (Idem, 2002).

51

Figura 12 - Diagrama de sequncia referente funcionalidade de insero no caixa.

52

O diagrama de sequncia exibido na figura 13 representa a operao de consulta de lanamentos. Neste diagrama, o usurio primeiramente faz login no sistema, em sequncia a tela principal exibida. A partir da, o usurio acessa a tela de consulta de lanamentos, informa o perodo, ou seja, a data inicial e a data final, em seguida o mesmo consulta pela data especificada. Por fim a informao solicitada exibida na tela de consulta. E assim como na figura 12, h a presena do facade CaixaFacade que vai calcular os totais de entrada e sada do caixa.

53

Figura 13 - Diagrama de sequncia referente funcionalidade de consulta de lanamentos.

54

4.2.4 Terceiro sprint (14/03 02/04/2011)

O terceiro sprint possui prioridade baixa e compreende os relatrios que o sistema ir emitir, e tambm, as telas: principal e a de autenticao do sistema. O presente sprint possui trs casos de uso que so: Emitir relatrios de lanamentos por data, Emitir Livro-caixa e Fazer login. A figura 12 mostra o diagrama de casos de uso referente ao terceiro sprint e a tabela 4 mostra as atividades realizadas neste sprint.

Figura 14 - Casos de uso do terceiro sprint.

Tabela 4 - Atividades realizadas no terceiro sprint.

Terceiro sprint Produto: Casos de Uso: Perodo: Controle de Caixa/Banco Emitir relatrio de Lanamentos por Data, Emitir Livro-caixa e Fazer Login. Trs semanas a partir do dia 14/03/2011 Semana Horas Data de Data Data de Tempo Entrada Limite Soluo 1 2 3 Total 14/03/2011 15/02/2011 14/02/2011 14/03/2011 15/03/2011 14/03/2011 15/03/2011 15/03/2011 15/03/2011 15/03/2011 15/03/2011 15/03/2011 16/03/2011 26/03/2011 24/03/2011 3 1 4 4 4 6 3 1 4 4 10

Descrio Modelagem do sistema (casos de uso e classes de domnio) Modelagem do sistema (modelo ER) Definio das Telas Desenvolvimento da Tela de login do sistema Implementao das

55

funcionalidades (tela de login do sistema) Desenvolvimento da Tela de Principal do sistema Implementao das funcionalidades (tela Principal do sistema) Desenvolvimento da Tela de relatrio por Perodo Implementao do relatrio de lanamentos por perodo Implementao do relatrio de exibio do livro-caixa Teste de funcionalidades entre o banco e as telas 25/03/2011 28/03/2011 26/03/2011 28/03/2011 30/03/2011 30/03/2011 30/03/2011 30/03/2011 30/03/2011 31/03/2011 01/04/2011 01/04/2011 4 8 1 8 8 8 1 8

01/04/2011 02/04/2011 02/04/2011 02/04/2011 02/04/2011 02/04/2011

8 1

8 1 56

Tempo total durante as trs semanas:

Para atender a este sprint foi necessria a criao das seguintes classes: RelatorioLancamentoPorData, Login e Principal. A figura 13 mostra o diagrama de domnio referente ao sprint, e o quadro 5 descreve estas classes.

Figura 15 - Classes de Domnio do terceiro sprint.

RelatorioLancamentoPor Data

Classes responsveis por fazer a comunicao do mundo externo com o sistema.

56

Login Principal CaixaDao Classe controladora responsvel pelas operaes de banco de dados. BancoBean CaixaBean PlanoDeContasBean
Quadro 5 - Descrio das classes do terceiro sprint.

Entidades do sistema.

O diagrama de sequncia ilustrado na figura 14 mostra as atividades necessrias para a exibio do relatrio de lanamentos por perodo. Neste diagrama, o usurio, primeiramente, faz login no sistema, em seguida a tela principal exibida. A partir da, o usurio acessa a tela de Emisso de relatrio de lanamentos, informa o perodo desejado, ou seja, a data inicial e a data final, em seguida o mesmo consulta pela data especificada. Por fim a informao solicitada exibida atravs de um relatrio.

57

Figura 16 - Diagrama de Sequncia referente funcionalidade de emisso de relatrio por data.

58

4.2.5 Modelagem do Sistema

Durante o desenvolvimento do sistema, foi percebido que o nmero de classes era muito grande, e estavam todas misturadas, dificultando at mesmo o entendimento do desenvolvedor. Para solucionar este problema, foi necessrio fazer o empacotamento das classes. A figura 17 mostra o diagrama de classes detalhado referente s telas do sistema. Estas classes encontram-se no pacote br.com.jcaixa.view, pois as mesmas so classes responsveis pela interao do usurio externo com o sistema. So elas: Login, Principal, PlanoDeContasView, BancoView, CaixaView, e

UsuarioView,

ConsultaPlanoDeContasView,

ConsultaBancoView

ConsultaLancamentoView.

Figura 17 - Diagrama de classes detalhado referente s telas do sistema.

A figura 18 exibe o diagrama de classes detalhado referente classe que realiza operaes relacionadas ao banco de dados e interface que implementa

59

essas funcionalidades na classe de controle. So elas: DaoGenerico e InterfaceDao contidas respectivamente nos pacotes br.com.jcaixa.dao e br.com.jcaixa.dao.interfaces.

Figura 18 - Diagrama de classes detalhado referente s classes de controle e interface InterfaceDao.

A figura 19 exibe o diagrama de classe detalhado referente aos POJOs do sistema. So elas: PlanoDeContasBean, BancoBean, CaixaBean, UsuarioBean e AdministradorBean que herdam atributos e mtodos da classe PessoaBean. Estas classes se encontram no pacote br.com.jcaixa.beans.

60

Figura 19 - Diagrama de classes detalhado do pacote br.com.jcaixa.beans.

A figura 20 mostra o diagrama de classes detalhado referente classe CaixaFacade, que responsvel por realizar os clculos referentes ao total de dbito, crdito e o saldo total e saldo anterior do caixa.

61

Figura 20 - Diagrama de classes detalhado referente classe CaixaFacade.

Aps o desenvolvimento das classes persistentes e das telas do sistema, logo na primeira execuo do programa, o Hibernate gerou as tabelas de banco de dados. A figura 21 mostra o modelo ER do sistema. Nota-se que h certa diferena entre os POJOs criados no sistema, visualizados na figura 19, e as tabelas de banco de dados. A diferena que s h a tabela tb_usuario para armazenar as informaes vindas das classes PessoaBean, AdministradorBean e UsuarioBean. Isso ocorre porque o Hibernate, atravs do mapeamento objeto/relacional, capaz de mapear herana para tabelas de banco de dados. A herana visualizada na figura 19 foi mapeada para uma nica tabela tb_usuario, por este motivo foi criado um campo com o nome tipo_pessoa, que serve para indicar o tipo de objeto que est sendo armazenado na tabela.

62

Figura 21 - Modelo ER do sistema.

4.3 FASE DE ENCERRAMENTO

As atividades realizadas nesta fase so concebidas por reviso dos sprints, demonstrao dos resultados e entrega do produto ao cliente. Como o produto apresentado neste trabalho foi concludo, no h a necessidade de voltar para a Fase de Desenvolvimento. Os trs sprints formados pelos casos de uso: Manter usurio, Manter banco, Manter plano de contas, Manter lanamentos, Fazer login, Emitir relatrio de lanamentos por data e Emitir Livro-caixa, tiveram suas funcionalidades

implementadas, testadas e aprovadas pelo cliente. Com o resultado dos sprints implementados neste projeto, so apresentadas as telas resultantes do desenvolvimento do sistema.

63

4.3.1 Tela de Login

A tela de login a tela de autenticao do jCaixa, atravs dela que o usurio vai entrar com seu nome de usurio e senha para fazer acesso ao sistema.

Figura 22 - Tela de login do sistema.

4.3.2 Tela Principal

A tela principal a tela de apresentao do jCaixa, atravs da mesma que o usurio vai executar determinada tarefa. Vale ressaltar, que o usurio Master11, o administrador do sistema, possui permisso somente para realizar o cadastramento de usurios. Os usurios cadastrados pelo administrador sero responsveis pelas tarefas relacionadas ao controle do caixa/banco. Essas restries so visveis na tela principal do sistema, pois, quando o usurio Master faz login, os botes e menus relacionados ao controle do caixa/banco so desabilitados. Quando um usurio cadastrado pelo administrador faz acesso no sistema, o boto e o menu referente ao controle de usurios so desabilitados, impedindo que um usurio comum modifique as informaes de outro usurio.

11

Este usurio criado na primeira execuo do sistema, ou seja, a prpria aplicao verifica se h usurios cadastrados na tabela tb_usuario, caso no haja, a aplicao insere o usurio Master com privilgios administrativos nesta tabela.

64

Figura 23 - Tela principal do sistema.

4.3.3 Tela de Controle de Usurios

Nesta tela o usurio Master tem a possibilidade de inserir um novo usurio, alterar os dados de um usurio cadastrado, e excluir determinado usurio. possvel observar as alteraes realizadas, j que a tabela sempre atualizada quando so realizadas as operaes de insero, alterao e excluso de registro. Alm disso, os campos so preenchidos com a informao da linha selecionada da tabela e, ainda h a possibilidade do administrador navegar nos registros, fazendo uso dos botes de navegao.

65

Figura 24 - Tela de controle de usurios.

4.3.4 Tela de Manuteno de Contas Bancrias

Nesta tela o usurio cadastrado pelo administrador do sistema tem a possibilidade de inserir uma nova conta bancria, alterar os dados de uma conta cadastrada, e excluir determinada conta bancria. Assim como no tpico anterior, a tabela sempre atualizada quando so realizadas as operaes de insero, alterao e excluso de registro. E os campos so preenchidos com a informao da linha selecionada da tabela. E ainda possvel navegar pelos registros, fazendo uso dos botes de navegao.

66

Figura 25 - Tela de Manuteno de Contas Bancrias.

4.3.5 Tela de Manuteno de Plano de Contas

Nesta tela o usurio cadastrado pelo administrador do sistema tem a possibilidade de inserir uma nova conta no plano de contas da empresa, alterar os dados de uma conta cadastrada, e excluir determinada conta. Vale ressaltar que ao fazer a insero de uma conta no plano de contas, o usurio deve especificar a natureza da conta, ou seja, ele deve informar se a conta a ser inserida uma receita12 ou uma despesa13. Assim como no tpico anterior, a tabela sempre atualizada quando so realizadas as operaes de insero, alterao e excluso de registro. E os campos

12

Corresponde, em geral, a vendas de mercadorias ou prestaes de servios (MARION, 2009, p.84). 13 todo sacrifcio, todo esforo da empresa para obter Receita (Idem, p.85).

67

so preenchidos com a informao da linha selecionada da tabela. E ainda possvel navegar pelos registros, fazendo uso dos botes de navegao.

Figura 26 - Tela de Manuteno do Plano de Contas.

4.3.6 Tela de Controle de lanamentos

Nesta tela o usurio cadastrado pelo administrador do sistema tem a possibilidade de inserir um novo lanamento no caixa/banco da empresa, alterar os dados de um lanamento, e excluir determinado lanamento. Vale ressaltar que ao fazer a insero de um lanamento no caixa/banco, o usurio deve especificar a conta onde ser efetuado o lanamento, ou seja, o usurio deve escolher uma conta do caixa ou uma conta bancria. Alm disso, o usurio deve informar se o lanamento efetuado uma entrada ou uma sada. Nesta tela h restries que impedem que o usurio realize alteraes e excluses de lanamentos que foram efetuados no dia anterior. Pois, tal operao ocasionaria em alteraes no processo contbil do livro-caixa.

68

Assim como nos tpicos anteriores, a tabela sempre atualizada quando so realizadas as operaes de insero, alterao e excluso de registro. E os campos so preenchidos com a informao da linha selecionada da tabela. E ainda possvel navegar pelos registros, fazendo uso dos botes de navegao. Nesta tela, so exibidas as informaes referentes ao processo de contabilidade do caixa, so elas: Total de entradas e sadas, saldo anterior e saldo atual do caixa.

Figura 27 - Tela de Controle de Lanamentos.

4.3.7 Tela de Consulta de Contas Bancrias

Atravs desta tela o usurio tem a possibilidade de consultar contas bancrias especificando o nmero da conta bancria ou o nome do banco. E a partir da, sero listados na tabela os dados como o id, o banco, a agncia e o nmero da conta.

69

Como dito anteriormente, nesta tela h dois meios de realizar a consulta, uma delas informando o nmero da conta bancria, a outra maneira informar o nome do banco.

Figura 28 - Tela de Consulta de Contas Bancrias.

4.3.8 Tela de Consulta de Plano de Contas

Atravs desta tela o usurio tem a possibilidade de consultar contas no plano de contas especificando o nome da conta ou a natureza da conta. E a partir da, sero listados na tabela os dados como o id, a conta e a natureza da conta. Como dito anteriormente, nesta tela h dois meios de realizar a consulta, uma delas informando o nome da conta, a outra forma escolher a natureza da conta.

70

Figura 29 - Tela de Consulta de Plano de Contas.

4.3.9 Tela de Consulta de Lanamentos

Atravs desta tela o usurio tem a possibilidade de consultar lanamentos especificando o perodo, histrico, ou o nmero do documento. E a partir da, sero listados na tabela os dados como o id, a data, o local, a conta, o tipo de lanamento, o histrico, o nmero da conta bancria e o valor. Como dito anteriormente, nesta tela h trs meios de realizar a consulta, uma delas informando o perodo, a outra maneira informar o histrico, e por fim, o outro meio informar o nmero do documento. No painel da parte inferior da tela, so exibidas as informaes do caixa para aquele perodo, histrico ou nmero do documento especificado.

71

Figura 30 - Tela de Consulta de Lanamentos.

4.3.10 Tela de Emisso de Relatrio por Perodo

Nesta tela, o usurio informa o perodo para a exibio de um relatrio de lanamentos. A partir da, sero listados no relatrio os dados como o id, a data, o local, a conta, o tipo de lanamento, o histrico, o nmero da conta bancria e o valor, seguido das informaes do caixa referente ao perodo especfico.

Figura 31 - Tela de Emisso de Relatrio de Lanamentos por perodo.

72

5 CONCLUSO

A utilizao de novas tecnologias no desenvolvimento de sistemas deixa o desenvolvedor de software bastante empolgado, porm, isso acaba se tornando um trabalho difcil devido falta de conhecimento relacionada ferramenta utilizada, resultando em um trabalho dobrado. Pois, o desenvolvedor tem que estudar estes avanos, e muitas das vezes, essas novidades deixam o mesmo na dvida ser que essa tecnologia corresponde s expectativas?. Por este motivo de extrema importncia que o desenvolvedor tenha conhecimento pleno das ferramentas utilizadas, para saber se este meio vivel ou no para o sistema proposto. O uso do Hibernate juntamente com a linguagem de programao Java se mostrou uma excelente alternativa para desenvolvedores que buscam interligar uma linguagem de programao orientada a objetos com um SGBD relacional. Este trabalho teve como objetivo realizar o desenvolvimento de um sistema para gerenciar o caixa/banco de uma empresa, atravs da utilizao da linguagem de Java e do framework Hibernate. Assim como apresentar uma reviso bibliogrfica sobre as ferramentas e tecnologias utilizadas no desenvolvimento deste trabalho, com nfase no framework de persistncia e mapeamento objeto/relacional Hibernate. Algumas dificuldades foram encontradas no decorrer da utilizao do Hibernate, no que se refere a integrao deste framework com o Swing, porm com muita pacincia e um estudo mais aprofundado sobre o assunto, foi possvel solucion-lo. O uso do Hibernate na produo deste trabalho trouxe bastante produtividade, j que este framework possibilita ao desenvolvedor focar-se na aplicao e no na base de dados utilizada. importante ressaltar que o Hibernate no veio para substituir outros meios de programao atravs do uso da linguagem Java, mas sim facilitar no

desenvolvimento de sistemas onde os paradigmas so diferentes. Lembrando que este framework no indicado para todo o tipo de projeto de desenvolvimento. O produto resultante, o sistema de controle de caixa/banco para a empresa For Business (jCaixa), encontra-se em sua primeira verso. O que torna possvel a implementao de novas funcionalidades para prximas verses.

73

Espera-se, que a partir do trabalho apresentado sobre o desenvolvimento de um sistema com o uso do Hibernate, possam surgir projetos de desenvolvimento relacionados com esta ferramenta. Pois a mesma oferece muitos benefcios para o desenvolvedor que deseja focar-se em sua aplicao. Futuramente, pretende-se completar o sistema atribuindo novas

funcionalidades, como a integrao com contas bancrias via internet, relatrios estatsticos que visam apresentar o valor gasto em cada conta do plano de contas da empresa e relatrios com grficos, mecanismos de segurana que tendem a proteger as senhas dos usurios, e gerao de logs para registrar o que est sendo executado no sistema. E outras funcionalidades, dependendo das necessidades do cliente, e de como o software est sendo utilizado na empresa.

74

REFERNCIAS

ARAJO, Carlos. Introduo Persistncia com Hibernate Parte 1. Easy Java Magazine, edio 5, 2011. BAUER, Cristhian; KING, Gavin. Java Persistence com Hibernate. Rio de Janeiro: Editora Cincia Moderna Ltda., 2007. BERTA, Caroline; ALMEIDA, rika. Guia Prtico de UML. Santarm: Grfica Tiago, 2006. CARMO JUNIOR, Evandro do. Labin Manager: Um sistema Web para gesto dos laboratrios de informtica do CEULS/ULBRA, 2010, 95 f. Trabalho de Concluso de Curso (Graduao em Sistemas de Informao) Centro Universitrio Luterano de Santarm, Santarm, 2010. GELLER, Marla B. et al. P@PSI Processo gil para pequenos sistemas, descrio e aplicao. In. Anais do Evento Cientfico TECSUL e Revista de Informtica N4 da Faculdade Mater Dei, 2008. GOMES, Yuri Marx P. Java na Web com JSF, Spring, Hibernate e NetBeans 6. Rio de Janeiro: Editora Cincia Moderna Ltda, 2008. GONALVES, Edson. Desenvolvendo Relatrios Profissionais com iReport para Netbeans IDE. Rio de Janeiro: Editora Cincia Moderna Ltda, 2009. ______. Dominando NetBeans. Rio de Janeiro: Editora Cincia Moderna Ltda, 2006. JANDL JUNIOR, Peter. Java: guia do programador. So Paulo: Novatec Editora, 2007. LINHARES, Maurcio. Introduo ao Hibernate 3. Disponvel em: <http://www.guj.com.br/content/articles/hibernate/intruducao_hibernate3_guj.pdf>. Acesso em: 23 fev. 2010. MARION, Jos Carlos. Contabilidade Bsica. 10.ed. So Paulo: Atlas, 2009. MAZZI, Carlos. O que o Hibernate?. Disponvel em: <www.devmedia.com.br/articles/viewcomp.asp?comp=16899>. Acesso em: 20 mai. 2010.

75

NetBeans IDE 6.8 Release Information. Disponvel em: <http://netbeans.org/community/releases/68/>. Acesso em: 20 mar. 2010. NIEDERAUER, Juliano. PostgreSQL Guia de Consulta Rpida. Disponvel em: <http://www.novateceditora.com.br/guias/postgresql/>. Acesso em: 31 mar. 2010. PRIMO, Izalmo; SANTOS, Samuel. Desenvolvendo com Hibernate. Java Magazine, Edio 73, 2009, 46-57. QUEIROZ, Mythian Bastos. Aplicao da Programao Orientada a Aspectos no desenvolvimento de software atravs do P@PSI, 2010, 72 f. Trabalho de Concluso de Curso (Graduao em Sistemas de Informao) Centro Universitrio Luterano de Santarm, Santarm, 2010. RIBEIRO, Osni Moura. Contabilidade Bsica Fcil. 20.ed. So Paulo: Saraiva, 1996. ______. Contabilidade Geral Fcil. 3.ed. So Paulo: Saraiva, 2002. ROCHA, Gabriel. Camada de Persistncia para Aplicaes Java: O Hibernate. Disponvel em: <http://www.mauroborges.com.br/downloads/Setor%20de%20TI/POO/Hibernate.pdf >. Acesso em: 20 mai. 2010. SMOLENAARS, Daniel; COSTA, Fabola. Questionrios Dinmicos on-line para coleta de dados. 2005. 97 f. Trabalho de Concluso de Curso (Graduao em Sistemas de Informao) Universidade Federal de Santa Catarina, 2005. Sobre o PostgreSQL. Disponvel em: <http://www.postgresql.org.br/sobre>. Acesso em: 31 mar. 2010.

Você também pode gostar