E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias Municipais de Obras...

0

UNIVERSIDADE PARA O DESENVOLVIMENTO DO ALTO VALE DO ITAJAÍ

PAULO LUIS STEINHAUSER

E-OBRAS:

Proposta de Desenvolvimento do Protótipo de Sistema para

Secretarias Municipais de Obras Utilizando Java

RIO DO SUL

2008

1



E-OBRAS:


Secretarias Municipais de Obras Utilizando Java Trabalho de conclusão de curso a ser

apresentado ao Curso de Bacharel em Sistemas

de Informação da Área das Ciências Naturais,

da Computação e das Engenharias, da

Universidade para o Desenvolvimento do Alto

Vale do Itajaí,como requisito parcial para a

obtenção do grau de Bacharel em Sistemas de

Informação.

Prof. Orientador: Marcondes Maçaneiro

RIO DO SUL

2008

2



E-OBRAS:


Secretarias Municipais de Obras Utilizando Java

Trabalho de conclusão de curso, do curso de

Sistemas de Informação, da Área das Ciências

Naturais, da Computação e das Engenharias,

da Universidade para o Desenvolvimento do

Alto Vale do Itajaí, a ser apreciado pela Banca

Examinadora, formada por:

______________________________________

Professor Orientador: Marcondes Maçaneiro

Banca Examinadora:

______________________________________

Prof. Fernando Andrade Bastos

______________________________________

Prof. Franciano Samagaia

Rio do Sul, Dezembro de 2008

3

Aos pais, que me encorajaram a seguir em mais essa jornada.

� �

4

AGRADECIMENTOS

Aos meus amigos e colegas da faculdade, que durante o curso foram fundamentais

para que eu conseguisse superar todos os obstáculos encontrados, em especial aos integrantes

da equipe “Maçã Corporation” Diego, Evandro e Rodrigo, que auxiliaram em muitos projetos

desenvolvidos ao longo do curso e mostraram a importância da amizade para superar

barreiras.

Aos professores do curso de Sistemas de Informação, especialmente aos que mais

exigiram, mas ao mesmo tempo nos apoiaram, mostrando a importância de aprender com os

nossos esforços, dando um valor significativamente às nossas conquistas durante o decorrer

do curso. Em especial aos professores Marco, Fernando, Juliano e, sobretudo ao professor

orientador Marcondes, que durante essa longa caminhada foram essenciais para o nosso

desenvolvimento como acadêmicos e como pessoas.

Aos meus familiares, que no decorrer do curso me apoiaram, mesmo quando não

tinha muito tempo para eles.

A Deus, por ter me dado a oportunidade de conviver esses quatro anos difíceis,

porém inesquecíveis, com os melhores colegas que um acadêmico pode desejar.

Aos funcionários e estagiários da Biblioteca Central da Universidade para o

Desenvolvimento do Alto Vale do Itajaí, que auxiliaram de uma forma e de outra para a

produção deste trabalho.

A minha grande amiga Rose, que leu e releu o trabalho em busca de erros

ortográficos, meu enorme agradecimento.

Aos funcionários e colegas da Empresa Brasileira de Correios e Telégrafos, que

entenderam minha ausência em muitas ocasiões. Aos que não entenderam, paciência.

A minha namorada Larissa, que me incentivou e me apoiou nessa difícil fase da

minha vida, e me mostrou que problemas estão aí para serem resolvidos.

Enfim, a todos que de uma forma ou de outra colaboram para a minha formação,

especialmente os que me apoiaram nas horas mais difíceis, como na elaboração deste trabalho

de conclusão de curso.

� � � �

5

RESUMO

Este trabalho de conclusão de curso trata do desenvolvimento de um protótipo de sistema

multiplataforma utilizando a linguagem de programação Java e também da possibilidade

futura do desenvolvimento de outra versão do protótipo destinada a dispositivos móveis, tais

como Palm ou Smartphones a fim de facilitar o acompanhamento de serviços realizados pelas

Secretarias de Obras das Prefeituras Municipais. Todo o desenvolvimento trata da construção

do protótipo que deve focar na solicitação e agendamento de serviços, bem como cadastros

tais como de contribuintes e funcionários, isso no sistema desktop. Já no protótipo do sistema

portátil, o objetivo é disponibilizar os dados das solicitações e da agenda, para facilitar o

controle em campo. Muitas tecnologias serão empregadas para a construção desse protótipo,

que vão desde a linguagem de programação Java, que tem como vantagens ser

multiplataforma, segura, completa e orientada a objetos. Também será empregado o sistema

de gerenciamento de banco de dados MySQL, emuladores e simuladores de dispositivos

móveis e ainda ferramentas de sincronização de dados entre esses dispositivos e

microcomputadores. Todo o esforço não foi em vão, pois no desenvolvimento do protótipo

houve o aprendizado de novas tecnologias que estão cada vez mais presentes no nosso meio, e

ainda pelo fato de que o protótipo pode ser futuramente aprimorado para uma versão

comercial.

Palavras-chave: Java, dispositivos móveis, multiplataforma.

6

ABSTRACT

This work of course conclusion treats of the development of a prototype of multiplatform

system using the programming language Java and also of the future possibility of the

development of another version of the prototype destined to movable devices, such like Palm

or Smartphones in order to facilitate the attendance of services accomplished by the General

offices of Works of the Municipal halls. The whole development treats of the construction of

the prototype should focus on that request and scheduling services, as well as entries such as

taxpayers and employees, that the desktop system. Already in the prototype portable system,

the goal is to provide the data requests and of the calendar, to facilitate the control on the

field. Many technologies will be employed for the construction of this prototype, which range

from the programming language Java, which has the advantages multiplatform be safe,

comprehensive and focused on objects. It will also be the employee database management

system MySQL, emulators and simulators for mobile devices and tools for synchronization of

data between these devices and microcomputers. Every effort was not in vain, because the

development of the prototype was the learning of new technologies that are increasingly

present in our environment, and also by the fact that the prototype can be further enhanced to

a commercial version.

Keywords: Java, mobile devices, multiplatform.

7

LISTA DE ILUSTRAÇÕES

Figura 1 – Exemplo de serviço prestado. ................................................................................. 23�

Figura 2 – Sistema de Banco de Dados. ................................................................................... 25�

Figura 3 – Estrutura e funções de um SGBD. .......................................................................... 28�

Figura 4 – Troca de mensagens entre objetos........................................................................... 32�

Figura 5 – Abstração, encapsulamento, herança e polimorfismo. ............................................ 33�

Figura 6 – Analogia entre pessoa e objeto ................................................................................ 35�

Figura 7 – Diagramas da UML ................................................................................................. 39�

Figura 8 – Comparação entre Java e outras linguagens ........................................................... 43�

Figura 9 – Funcionamento do JDBC. ....................................................................................... 48�

Figura 10 – Subdivisões do Java .............................................................................................. 49�

Figura 11 – Diferenças entre CDC e CLDC ............................................................................. 51�

Figura 12 – Perfil e Configuração do J2ME ............................................................................. 53�

Figura 13 – Acesso de RecordStore por MIDlets. .................................................................... 54�

Figura 14 – Computação Móvel. .............................................................................................. 57�

Figura 15 – Palm E2. ................................................................................................................ 58�

Figura 16 – Conduit. ................................................................................................................. 59�

Figura 17 – Banco de Dados Palm. .......................................................................................... 62�

Figura 18 – IDE NetBeans. ...................................................................................................... 63�

Figura 19 – Power Architect ..................................................................................................... 65�

Figura 20 – iReport ................................................................................................................... 66�

Figura 21 – Diagrama de Casos de Uso. .................................................................................. 69�

Figura 22 – Diagrama de Classes. ............................................................................................ 70�

Figura 23 – Diagrama de Atividades geral do protótipo. ......................................................... 71�

Figura 24 – Diagrama de Atividades do cadastro de cidades. .................................................. 72�

Figura 25 – Diagrama de Atividades do cadastro de CEP. ...................................................... 72�

Figura 26 – Diagrama de Atividades do cadastro da Prefeitura. .............................................. 73�

Figura 27 – Modelo de Entidade Relacionamento. .................................................................. 74�

Figura 28 – phpMyAdmin. ....................................................................................................... 76�

Figura 29 – Trecho do dump do banco. .................................................................................... 80�

Figura 30 – Trecho do código da classe Cidade. ...................................................................... 81�

Figura 31 – Parte do código da classe CidadeDao. .................................................................. 82�

Figura 32 – Trecho do código da classe CidadeFacade. ........................................................... 83�

Figura 33 – Exemplo de código do arquivo XML. .................................................................. 84�

Figura 34 – Configuração para acesso ao banco de dados. ...................................................... 84�

Figura 35 – Teste de gravação. ................................................................................................. 85�

Figura 36 – Exemplo da utilização do JSF. .............................................................................. 87�

Figura 37 – Tela de cadastro de cidades. .................................................................................. 88�

Figura 38 – Tela de exibição dos dados. .................................................................................. 88�

Figura 39 – Relatório gerado. ................................................................................................... 89�

Figura 40 – Trecho do fonte do protótipo para dispositivo móvel. .......................................... 91�

Figura 41 – Tela do sistema móvel ........................................................................................... 92�

LISTA DE QUADROS

Quadro 1 – Relação vereadores x população............................................................................ 20�

LISTA DE ABREVIATURAS E SIGLAS

AOO Análise Orientada a Objetos AWT Abstract Window Toolkit APOO Análise e Programação Orientada a Objetos CRT Cathode Ray Tube (tubo de raios catódicos) DAO Data Access Object DBA Administrador de Banco de Dados DDL Data Definition Language DML Data Manipulation Language GUI Graphical User Interface JAD Java Application Descriptor JAR Java Archive JDBC Java Database Connectivity JDK Java Development Kit JEE Java Enterprise Edition JME Java Micro Edition JSE Java Standard Edition JSF JavaServer Faces JSP JavaServer Pages JVM Java Virtual Machine LCD Liquid Crystal Display (display de cristal líquido) LP Linguagem de Programação ODBC Open Database Connectivity OMG Object Management Group OO Orientação a Objetos POSE Palm OS Emulator RMS Record Management System (sistema de gerenciamento de registro) SGBD Sistema de Gerenciamento de Banco de Dados SGBDR Sistema Gerenciador de Banco de Dados Relacionais SQL Structured Query Language UML Unified Modeling Language XML Extensible Markup Language

SUMÁRIO

1 INTRODUÇÃO ................................................................................................................... 14�

1.1 JUSTIFICATIVAS ............................................................................................................. 15�

1.2 OBJETIVOS ....................................................................................................................... 17�

1.2.1 Objetivo Geral ............................................................................................................... 17�

1.2.2 objetivos Específicos ...................................................................................................... 17�

2 FUNDAMENTAÇÃO TEÓRICA ...................................................................................... 18�

2.1 ADMINISTRAÇÃO PÚBLICA ........................................................................................ 18�

2.1.2 Prefeitura Municipal ..................................................................................................... 18�

2.1.2.1 Divisões ........................................................................................................................ 19�

2.1.2.2 Fontes de Receita .......................................................................................................... 21�

2.1.3 Secretaria Municipal de Obras .................................................................................... 22�

2.2 BANCO DE DADOS ......................................................................................................... 24�

2.2.1 Componentes de um Banco de Dados .......................................................................... 25�

2.2.1.1 Dados ............................................................................................................................ 26�

2.2.1.2 Hardware ...................................................................................................................... 26�

2.2.1.3 Software ........................................................................................................................ 26�

2.2.1.4 Usuários ........................................................................................................................ 27�

2.2.2 Sistema de Gerenciamento de Banco de Dados .......................................................... 27�

2.2.3 SQL ................................................................................................................................. 29�

2.2.4 MySQL ........................................................................................................................... 29�

2.3 ORIENTAÇÃO A OBJETOS ............................................................................................ 30�

2.3.1 Análise Orientada a Objetos ......................................................................................... 33�

2.3.2 UML ................................................................................................................................ 35�

2.3.2.1 Definição ...................................................................................................................... 35�

2.3.2.2 Histórico da UML ......................................................................................................... 37�

2.3.2.3 Diagramas da UML ...................................................................................................... 38�

2.3.3 Programação Orientada a Objetos .............................................................................. 40�

2.4 JAVA .................................................................................................................................. 42�

2.4.1 Conceitos ........................................................................................................................ 42�

2.4.2 Histórico ......................................................................................................................... 44�

2.4.3 Interfaces Gráficas do Java .......................................................................................... 46�

2.4.4 Acesso a Banco de Dados .............................................................................................. 47�

2.4.5 Subdivisões do Java ....................................................................................................... 48�

2.4.5.1 Java Standard Edition ................................................................................................... 49�

2.4.5.2 Java Enterprise Edition ................................................................................................. 49�

2.4.5.3 Java Micro Edition ....................................................................................................... 50�

2.4.5.4 Java Card ...................................................................................................................... 54�

2.5 COMPUTAÇÃO MÓVEL ................................................................................................. 54�

2.5.1 Histórico ......................................................................................................................... 54�

2.5.2 Palm ................................................................................................................................ 57�

2.5.2.1 Sincronização de dados e aplicativos ........................................................................... 58�

2.5.2.2 Aplicações para Palm OS ............................................................................................. 59�

2.5.2.3 Simuladores .................................................................................................................. 60�

2.5.2.4 Banco de Dados Palm ................................................................................................... 61�

2.6 AMBIENTES DE DESENVOLVIMENTO ...................................................................... 62�

2.6.1 NetBeans ......................................................................................................................... 62�

2.6.2 Power Architect ............................................................................................................. 64�

2.6.3 iReport ............................................................................................................................ 65�

3 ANÁLISE ............................................................................................................................. 67�

3.1 ANÁLISE DE REQUISITOS ............................................................................................ 67�

3.2 DIAGRAMAS .................................................................................................................... 68�

3.2.1 Diagrama de Casos de Uso ............................................................................................ 68�

3.2.2 Diagrama de Classes ...................................................................................................... 69�

3.2.3 Diagrama de Atividades ................................................................................................ 71�

3.2.4 Modelo de Entidade Relacionamento .......................................................................... 73�

4 IMPLEMENTAÇÃO .......................................................................................................... 75�

4.1 IMPORTAÇÃO DOS PACOTES ...................................................................................... 77�

4.2 BANCO DE DADOS ......................................................................................................... 79�

4.3 CLASSES DE NEGÓCIO .................................................................................................. 80�

4.3.1 A Classe Dominio ........................................................................................................... 81�

4.3.2 A Classe DAO ................................................................................................................ 82�

4.3.3 A Classe FACADE ......................................................................................................... 83�

4.3.4 A conexão com o banco de dados ................................................................................. 84�

4.3.5 Os primeiros testes ........................................................................................................ 85�

4.4 AS CLASSES DA APLICAÇÃO WEB ............................................................................ 85�

4.4.1 A Classe Provider .......................................................................................................... 86�

4.4.2 Criação de telas .............................................................................................................. 86�

4.5 RELATÓRIOS ................................................................................................................... 88�

4.6 A APLICAÇÃO PARA DISPOSITIVOS MÓVEIS ......................................................... 90�

5 CONCLUSÕES E RECOMENDAÇÕES ......................................................................... 94�

REFERÊNCIAS ..................................................................................................................... 96�

ANEXO I – ORGANOGRAMA HIERÁRQUICO GERAL DO MUNICÍPIO DE RIO

DO SUL .................................................................................................................................... 99�

ANEXO II – ORGANOGRAMA HIERÁRQUICO DA SECRETARIA DE OBRAS DO

MUNICÍPIO DE RIO DO SUL ............................................................................................. 100�

14

1 INTRODUÇÃO

As Prefeituras Municipais podem ser consideradas como sendo órgãos

independentes que manifestam o Poder Executivo do município do qual fazem parte. Essa

independência é caracterizada pelo fato de que esse órgão não está hierarquizado a nenhum

outro. Ela é composta por vários órgãos inferiores como as Secretarias Municipais, dentre as

quais se encontra a Secretaria Municipal de Obras.

A Secretaria Municipal de Obras é um órgão subordinado diretamente ao gabinete

do prefeito, prestando vários serviços à população, tais como: manutenção e pavimentação de

ruas, construção e manutenção de pontes, drenagens, patrolamento de estradas não

pavimentadas dentre inúmeros outros que visam garantir o bem estar de toda a população.

Muitos desses serviços planejados previamente, alguns são realizados a partir de necessidades

emergenciais e outros ainda, são realizados após solicitação dos contribuintes.

Em nossa região, a maioria das Secretarias Municipais de Obras faz anotações das

solicitações em agendas, blocos de papel ou no máximo em algum software que não foi

desenvolvido para essa finalidade específica. Também não são controlados os serviços

realizados em determinada data, região ou para determinado contribuinte nem quanto tempo

ou verba foram gastos para realizar tal serviço. Isso gera um grande número de transtornos

tanto para a população que anseia pela execução desses serviços quanto para a Secretaria

Municipal de Obras, que não tem um controle real do processo. Como não há controle dos

processos, também não são gerados dados estatísticos, que poderiam criar uma transparência e

auxiliar aos administradores públicos na tomada de decisão.

Em visita a algumas Secretarias Municipais de Obras da região do Alto Vale do

Itajaí pode-se perceber que não há dados concretos referente ao número de solicitações e

serviços realizados pelas mesmas. Em alguns casos, não há sequer um microcomputador

disponível para o armazenamento e disponibilização de informações.

Nota-se que o controle e disponibilização das informações são fundamentais tanto

para as Prefeituras e Secretarias de Obras Municipais quanto para os munícipes. Para tanto, há

a necessidade da utilização de um software criado com esse propósito, ou seja, de agilizar

processos, armazenar informações, disponibilizá-las aos contribuintes de forma clara e

transparente entre outros.

15

1.1 JUSTIFICATIVAS

A tecnologia da informação está cada vez mais presente em nosso meio, seja nas

empresas, órgãos públicos e mesmo em nossa casa. Os sistemas de informação se apresentam

das mais variadas formas, como em grandes servidores, computadores pessoais, dispositivos

móveis entre outros.

Inúmeros serviços que outrora eram demorados ou impossíveis de serem

executados hoje são eficientes graças a sistemas de informação. Tem-se então uma noção de

quanto a nossa sociedade atual está ligada a esses sistemas.

Órgãos públicos como prefeituras, para garantir uma maior agilidade e qualidade

nos serviços prestados, bem como a transparência dos processos utilizam a tecnologia de

informação como ferramenta de apoio. Grande parte dos setores das prefeituras da região é

informatizada, gerando assim uma diminuição do uso de material impresso, possibilitando o

armazenamento seguro das informações e aumentando consideravelmente a integração entre

setores e facilidade de pesquisa de documentos.

Para os prefeitos municipais, o setor de obras é de extrema importância, uma vez

que é dali que a maioria dos projetos é realizada. Então a informatização desse setor vem de

encontro a seus interesses, pois este poderá comprovar com dados concretos os investimentos

feitos no município.

Já para os contribuintes, a informatização desses órgãos públicos é muito

importante, pois lhes possibilita solicitar serviços e ainda fazer o acompanhamento de sua

solicitação de forma clara e principalmente, rápida.

Infelizmente, em muitas secretarias municipais da região essa informatização é

muito baixa ou mesmo inexistente, como acontece com boa parte das secretarias de obra

municipais. Sabe-se que atualmente, quando um contribuinte se desloca até uma dessas

secretarias e solicita determinado serviço, o responsável pelo agendamento, simplesmente

anota a solicitação em uma ficha de papel ou em algum programa de computador não

específico para determinado setor. Aí surgem os problemas de precariedade no controle e

acompanhamento desses serviços. Também torna muito difícil para os responsáveis pela

secretaria terem dados precisos quanto aos serviços realizados em determinado período, em

determinada região e quais os contribuintes atendidos.

Baseando-se nessas premissas, surge então a proposta de desenvolvimento de um

protótipo de sistema para auxiliar no controle das solicitações e agendamento de serviços.

16

Esse protótipo será composto por um sistema desktop, que constituirá o módulo principal,

responsável pelo controle, cadastros e agendamentos e solicitações e outro módulo auxiliar,

que será baseado na tecnologia móvel, com a qual o responsável pela realização ou

fiscalização das obras poderá levar consigo, de maneira simples, as informações referentes à

agenda de serviços entro outros dados para acompanhamento do processo.

Para tanto, há a necessidade da utilização de uma linguagem de programação que

seja multiplataforma, robusta e ainda, gratuita. Foram analisadas algumas opções para a

escolha da linguagem que daria vida ao protótipo. Após esse processo de comparações, a

linguagem de programação escolhida, por atender a esses quesitos e ainda, por ser uma

tecnologia nova e muito promissora, é a Java.

O Java foi lançado no mercado pela Sun Microsystems em 1995 e desde então só

vem evoluindo. Fruto de um grande trabalho de pesquisa tecnológica e científica o Java ainda

entusiasma programadores, analistas de sistemas, isso porque essa linguagem reúne inúmeras

facilidades e pode ser considerado um ambiente completo de desenvolvimento e execução de

sistemas.

Como principais características do Java pode-se destacar que é uma linguagem de

programação que é orientada a objetos, mostrando grande robustez, com alto nível de

portabilidade, o que permite que seja rodado tanto em desktops, quanto em redes e

dispositivos de menor capacidade e tamanho, como o Palm e celulares.

Se a Sun desejava desenvolver uma linguagem de programação que pudesse ser

multiplataforma, tanto no que se refere a hardware quanto ao que se refere a sistema

operacional, o Java foi e é um sucesso.

Como foi visto acima, há motivos de sobra que indicam que o Java é a melhor

escolha para o desenvolvimento do protótipo. Mas além desses, há um que é de grande valia,

o aprendizado de uma nova e complexa linguagem de programação que certamente será mais

utilizada por desenvolvedores que buscam unir todas as características de uma robusta LP em

seus sistemas.

Outro aspecto importante que se deve ressaltar do projeto é a criação de um

módulo para tecnologia móvel, como para a plataforma Palm OS. A mobilidade das

informações facilita em muito o trabalho de campo, como na fiscalização de serviços que

estão sendo executados quanto para a manutenção de uma agenda de fácil acesso e utilização.

Um problema que deve ser levado em consideração é o fato de que a maioria das

pessoas que trabalham na área de obras não está preparada para o uso da tecnologia. Surge daí

17

um grande desafio, o treinamento desses funcionários, já que de nada adianta a existência de

um sistema que não tenha usuários habilitados para utilizá-lo de forma correta.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Desenvolver um protótipo de sistema multiplataforma, a fim de auxiliar no

gerenciamento das secretarias de obras das prefeituras municipais.

1.2.2 objetivos Específicos

� Analisar a linguagem Java para o desenvolvimento do protótipo;

� Estudar a história dos dispositivos móveis;

� Avaliar o uso de linguagem de programação para dispositivos móveis;

� Analisar ferramentas de comunicação entre dispositivos móveis e microcomputadores;

� Analisar o Sistema de Gerenciamento de Banco de Dados MySQL.

18

2 FUNDAMENTAÇÃO TEÓRICA

2.1 ADMINISTRAÇÃO PÚBLICA

Pode-se definir os termos administrar e administração pública, respectivamente

como sendo:

“[...] administrar é gerir interesses, segundo a lei, a moral e a finalidade dos bens entregues à guarda e conservação alheias. Se os bens e interesses geridos são individuais, realiza-se administração particular, se são da coletividade, realiza-se administração pública. A administração pública, portanto, é a gestão de bens e interesses qualificados da comunidade no âmbito federal, estadual ou municipal, visando ao bem comum. (Meirelles ,2002 apud AGUIAR, 2004, p. 18-19);

Da definição anterior pode-se perceber a importância da administração e,

sobretudo, a boa administração pública tem para a sociedade como um todo. Ela tem como

intenção administrar os bens públicos, ou seja, os bens que são da população que faz parte de

determinada região que é administrado por um governo.

Esses bens públicos mencionados pelo autor podem ser caracterizados, conforme

Giambiagi e Além (2001), como bens cujo consumo ou utilização dos mesmos pode ser feito

por um indivíduo como por mais integrantes da sociedade. Em outras palavras são bens que

podem ser consumidos por alguns cidadãos sem que seja prejudicada a disponibilidade para

os outros. Porém sabe-se que nem sempre isso acontece, pois alguns acabam se beneficiando

mais do que os outros na utilização desses bens.

Os bens públicos podem, de acordo com Giambiagi e Além (2001), ser

classificados como tangíveis, como as ruas e a iluminação pública ou intangíveis, tais como a

segurança pública, defesa nacional entre outros.

2.1.2 Prefeitura Municipal

Uma definição de Prefeitura Municipal é dada como sendo:

19

“[...] órgão pelo qual se manifesta o Poder Executivo do Município. Caracteriza-se por ser um órgão independente - por não hierarquizado a qualquer outro; composto - porque integrado por outros órgãos inferiores; central - porque nele se concentram todas as atribuições do Executivo, para serem distribuídas a seus órgãos subordinados; e unipessoal - porque atua e decide através de um único agente, que é o prefeito. E da Câmara dos Vereadores, como órgão legislativo.” (VERÍSSIMO, 2001).

Fica perceptível então o quanto a estrutura da Prefeitura Municipal é importante

para os cidadãos, uma vez que de acordo com o autor, esses órgãos receberam muito mais

autonomia após a constituição de 1988. Essa autonomia é sentida nos três aspectos, ou seja,

no político, administrativo e financeiro.

“Não se pode, todavia, confundir a Prefeitura (órgão executivo) com o Município

(pessoa jurídica) ou com o prefeito (chefe do órgão e agente político).” (VERÍSSIMO, 2001).

2.1.2.1 Divisões

O responsável por conduzir a Administração Pública Municipal é, de acordo com

o site oficial do IBAM (2008), o prefeito. Ele tem muitas atribuições e conseqüentemente

muitas responsabilidades também, seja legalmente bem como pela confiança que lhe foi

depositada para a solução dos problemas do município. O prefeito acumula funções políticas,

administrativas e executivas.

A importância dessas funções e, portanto, do papel do Prefeito resulta do fato de que ele não é um funcionário, mas um agente político responsável pelo ramo executivo de uma unidade de Governo autônoma - o Município. Como tal, o Prefeito não é subordinado a outra autoridade, apenas à lei. Acatará a lei e os mandados judiciais, como qualquer autoridade e qualquer pessoa. (IBAM, 2008).

Além de acumular essas três funções anteriormente citadas, conforme o IBAM

(2008), o Prefeito Municipal é o responsável pela prestação de contas da sua administração.

Caso isso não ocorra ou sejam encontradas irregularidades, poderá haver intervenção estadual

20

no Município. Essa prestação de contas é um relatório juntamente com o balanço anual do

Município, e ainda um relatório orçamentário feito a cada dois meses.

Em relação ao Gabinete do Prefeito, é importante destacar que este

“[...] deve manter uma estrutura para assistir direta e imediatamente ao prefeito municipal na sua representação civil e nas relações com autoridades em geral. Entre outras atribuições, destacam-se: garantir a prestação de serviços municipais de acordo com as diretrizes de governo; promover contatos com autoridades e organizações dos diferentes níveis e esferas governamentais; coordenar a elaboração da agenda e dos programas oficiais do prefeito municipal; coordenar as atividades das administrações regionais; e participar das avaliações das ações governamentais.” (VERÍSSIMO, 2001).

Além do Prefeito, Vice-Prefeito e outros funcionários, a administração pública é

composta ainda pelos vereadores, que assim como o Prefeito, são eleitos pelo voto da

população votante de determinado município. “Vereadores são agentes públicos, da categoria

dos agentes políticos, investidos de mandato legislativo e eleitos mediante pleito direto e

simultâneo realizado em todo o país, para um mandato de quatro anos.” (IBAM, 2008).

O número de Vereadores pode variar de acordo com o número de pessoas que

vivem em determinado município, com podemos ver no quadro a seguir:

Quadro 1 – Relação vereadores x população. Fonte: IBAM (2008).

Em se tratando de funções da Câmara Municipal de Vereadores, destacam-se três:

A primeira é a função legislativa, que consiste na elaboração das leis sobre matérias de competência exclusiva do Município.

21

A segunda função é a fiscalizadora, que tem por objetivo o exercício do controle da Administração local, principalmente quanto à execução orçamentária e ao julgamento das contas apresentadas pelo Prefeito. O controle externo da Câmara Municipal é exercido com o auxílio do Tribunal de Contas do Estado ou do Conselho ou Tribunal de Contas dos Municípios, onde houver. Constitui também função da Câmara a administrativa, a qual restringe-se à sua organização interna, ou seja, à estruturação organizacional, à organização de seu quadro de pessoal, à direção de seus serviços auxiliares e, principalmente, à elaboração de seu Regimento Interno. (IBAM, 2008).

Como foi visto até agora, a Administração Municipal é realizada principalmente

pelo Prefeito e pelos Vereadores. É importante lembrar que as prefeituras são compostas de

vários setores, como as Secretarias Municipais, dentre as quais encontramos a Secretaria

Municipal de Saúde, Secretaria Municipal da Educação e a Secretaria Municipal de Obras.

Pode-se ver um exemplo de como é a estrutura interna de uma Prefeitura no anexo I, onde é

apresentado o Organograma Hierárquico da Prefeitura Municipal de Rio do Sul.

2.1.2.2 Fontes de Receita

As Receitas Municipais são indispensáveis para manter a estrutura e os serviços

prestados pela Prefeitura Municipal à população do município.

De acordo com o site do IBAM (2008), são várias as fontes de receita que as

Prefeituras Municipais do país dispõem. Alguns exemplos dessas receitas são:

• Receitas Tributárias � englobam os tributos, constituídos de impostos e

taxas, recolhidos pela e para a Prefeitura Municipal;

• Receitas de Transferências Constitucionais � caracteriza-se por uma parte

dos impostos recolhidos para o Estado e para a União que são destinados

aos municípios.

• Compensação financeira � de acordo com o IBAM (2008) são recursos

de “[...] caráter indenizatório pela exploração de recursos naturais em seu

território, adjacências e plataforma continental.”

• Receita patrimonial � “[...] é constituído de bens móveis e imóveis,

podendo, quando explorado economicamente, gerar receitas patrimoniais

mobiliárias e imobiliárias; [...]” (IBAM, 2008). A receita propriamente

dita vem da venda, aluguel ou aplicações financeiras desses patrimônios.

22

• Outras receitas correntes � conforme IBAM (2008) enquadram-se neste

grupo de receitas as “[...] multas e outras penalidades não tributáveis [...]”.

2.1.3 Secretaria Municipal de Obras

A Secretaria Municipal de Obras é um órgão subordinado ao Gabinete do Prefeito

e tem por finalidade realizar obras em benefício da população residente no município.

De acordo com o site oficial da Prefeitura Municipal de Rio do Sul – SC (2008), a

Secretaria Municipal de Obras objetiva “[...] atender os anseios da comunidade, através da

realização de obras públicas, como limpeza urbana, jardinagem, drenagem (bocas de lobo,

caixas e tubulações), manutenção, calçamento e pavimentação de ruas, manutenção de pontes,

construção de pontilhões.”

Ainda é de responsabilidade da Secretaria de Obras, conforme o site da Prefeitura

Municipal de Rio do Sul – SC (2008), auxiliar as outras Secretarias que fazem parte da

Administração Pública Municipal com seus equipamentos, veículos e mão-de-obra e ainda

executar projetos que são de interesse municipal.

Já o site da Prefeitura Municipal de Blumenau – SC (2008) destaca o seguinte:

A Secretaria de Obras e Serviços Urbanos (SEOSUR) responde pela coordenação, acompanhamento e fiscalização de obras de engenharia do município, nas áreas de Edificação, Pavimentação, Saneamento e Iluminação Pública. Além disso, toda a parte de Manutenção de vias e locais públicos, como praças, são de responsabilidade da Seosur, que trabalha para garantir a qualidade de vida e o progresso da comunidade blumenauense.

É evidente a grande importância que a Secretaria de Obras tem no contexto

Municipal, uma vez que ela garante o funcionamento de vários setores com a realização de

obras dos mais diversos tipos e a manutenção das vias públicas, estradas e outros.

Na figura a seguir pode-se ver um exemplo de obra realizada pela Secretaria:

23

Figura 1 – Exemplo de serviço prestado.

Fonte: Prefeitura Municipal de Blumenau (2008).

A Secretaria Municipal de Obras é, assim como a Prefeitura, subdividida em

áreas, tendo um responsável por cada uma delas. Podemos perceber claramente isso no anexo

II, onde encontra-se o Organograma Hierárquico da Secretaria Municipal de Obras e Serviços

Urbanos da Prefeitura Municipal de Rio do Sul – SC.

Os serviços realizados pelas Secretarias geralmente são frutos de um amplo

planejamento, como no caso de pavimentação de ruas e colocação de rede de esgoto em

determinado local. Porém, há em muitos casos a necessidade da realização de algum serviço

que surgiu em decorrência de algum fator não planejado, como a danificação de alguma rua

por causa de alagamento, por exemplo.

O contribuinte pode solicitar algum serviço à Secretaria de Obras de sua cidade e

essas solicitações são anotadas em algum meio, seja ele um bloco de anotações ou em algum

dispositivo computacional. Na nossa região, como se pôde perceber através de conversas com

Secretários Municipais de Obras, essas anotações são geralmente feitas em bilhetes de papel

ou algo semelhante, impossibilitando um controle das obras que foram ou serão realizadas.

Um caso que é comum de ser encontrado na região é o da Secretaria de Obras da

Prefeitura Municipal de Atalanta, onde toda solicitação de serviço realizada por um

contribuinte passa pela mão do Secretário de obras, sendo que o mesmo dá uma previsão por

auto de quando o serviço será realizado, tomando como base o fluxo de trabalho e a

24

disponibilidade dos equipamentos e funcionários. As anotações dos pedidos são comumente

feitas em pequenos bilhetes, causando certa desorganização e falta de controle no setor. Com

os pedidos em mãos, o secretário procede a distribuição dos serviços, informando aos

funcionários: Quem? Aonde? Como? O acompanhamento do trabalho é feito pelo fiscal de

obras, que posteriormente passa verbalmente o andamento e os resultados ao Secretário.

É importante lembra que em geral as Secretarias Municipais de Obras são

mantidas por verbas provenientes das Prefeituras da qual elas fazem parte.

2.2 BANCO DE DADOS

Conforme Date (2003), um sistema de banco de dados consiste num sistema

computadorizado que tem por finalidade de armazenar e manter registros, podendo ser

comparado com um armário de arquivamento. O autor ainda afirma que banco de dados “[...]

é um repositório ou recipiente para uma coleção de arquivos de dados computadorizados.”

(DATE, 2003, p. 3).

Há de se lembrar a importância que os bancos de dados têm atualmente no mundo

inteiro. Eles podem ser empregados para “[...] manter registros internos, apresentar dados a

consumidores e clientes na World Wide Web1 e fornecer suporte a muitos outros processos

comerciais.” (GARCIA-MOLINA, 2001, p. 1).

Segundo Date (2003), o usuário de um banco de dados pode realizar várias

operações como: adicionar arquivos ao banco ou remover esses arquivos previamente

adicionados, e ainda fazer operações de inserção, busca, exclusão e alteração dos dados desses

arquivos.

Ainda pode-se definir banco de dados como sendo “[...] uma coleção de dados

persistentes, usada pelos sistemas de aplicação de uma determinada empresa.” (DATE, 2003,

p. 10).

O termo persistente é bem definido como:

1 World Wide Web ou simplesmente Web, como é mais conhecida, pode ser entendida como “[...] um sistema com padrões aceitos universalmente para armazenar, recuperar, formatar e apresentar informações utilizando uma arquitetura cliente/servidor. A Web combina texto, hipermídia elementos gráficos e som.” (LAUDON, 2006, p. 293).

25

Por persistente, queremos sugerir intuitivamente que os dados desse banco de dados diferem em espécie de outros dados mais efêmeros, como dados de entrada, dados de saída, filas de trabalho, blocos de controle de software, instruções SQL, resultados intermediários e, de modo geral, quaisquer dados que tenham natureza transitória. Mais precisamente, dizemos que os dados no banco de dados “persistem” porque, uma vez aceitos pelo SGBD para entrada no banco de dados em primeiro lugar, eles só podem ser removidos do banco de dados mais tarde por alguma requisição explícita ao SGBD, e não como um mero efeito colateral de (por exemplo) algum programa concluindo sua execução. (DATE, 2003, p. 10).

Pode-se perceber por essa definição que a persistência no banco de dados é um

dos principais fatores que o tornam seguro e funcional.

2.2.1 Componentes de um Banco de Dados

Um Sistema de Banco de Dados, conforme Date (2003) é composto pelos

seguintes elementos: dados, hardware, software e usuários.

Figura 2 – Sistema de Banco de Dados. Fonte: Date (2003).

26

2.2.1.1 Dados

As informações contidas num Sistema de Banco de Dados podem estar

concentradas num único banco de dados ou ainda, divididas em vários distintos. No entender

de Date (2003), os dados contidos num banco de dados estarão, geralmente, integrados e

compartilhados. Esses aspectos garantem vantagens tanto para os ambientes grandes como os

ambientes pequenos.

Seguindo a linha de raciocínio do autor, “por integrado, queremos dizer que o

banco de dados pode ser considerado como uma unificação de vários arquivos que, de outro

modo, seriam distintos, com a eliminação de qualquer redundância parcial ou total entre esses

arquivos”. (DATE, 2003, p. 7).

Já o termo compartilhado, de acordo com Date (2003), significa que os dados

podem ser compartilhados entre diferentes usuários. Isso também possibilita que vários

usuários possam ter acesso aos mesmos dados simultaneamente.

2.2.1.2 Hardware

O hardware é todo o equipamento envolvido no armazenamento e disponibilidade

dos dados. Segundo Date (2003), o hardware inclui os dispositivos de armazenamento, como

os discos rígidos, fitas magnéticas entre outros, bem como os controladores desses

dispositivos e os canais de entrada e saída. Também estão incluídos no hardware, os

processadores e memória principal.

2.2.1.3 Software

O software envolvido em questão, uma camada existente entre o banco de dados

físico e os usuários do sistema, que de acordo com Date (2003), é conhecido como Sistema de

Gerenciamento de Banco de Dados ou SGBD.

A função do software SGBD é:

27

“[...] isolar os usuários do banco de dados dos detalhes no nível de hardware (assim como os sistemas de linguagens de programação isolam os programadores de aplicações dos detalhes no nível de hardware). Em outras palavras, o SGBD oferece aos usuários uma visão do banco de dados um tanto elevada acima do nível de hardware, e ele admite operações do usuário [...] que são expressas em termos dessa visão de nível mais elevado.” (DATE, 2003, p. 8)

Fica evidente a importância desse software para o usuário, pois ele vai fornecer

um isolamento dos usuários do banco de dados dos detalhes do hardware, criando um

ambiente menos complexo.

2.2.1.4 Usuários

Quanto aos usuários, Date (2003) nos informa que existem três classes destes:

• Na primeira classe estão incluídos os programadores de aplicações, que

desenvolvem aplicações que acessam o banco de dados;

• A segunda classe é constituída por usuários finais, que acessam esses

dados de forma interativa;

• E por último, a terceira classe, que é constituída pelo administrador de

banco de dados, ou DBA. Como o próprio nome indica, a função do DBA

é administrar o banco de dados, papel muito importante para o perfeito

funcionamento do banco.

2.2.2 Sistema de Gerenciamento de Banco de Dados

Um Sistema de Gerenciamento de Banco de Dados, de acordo com Date (2003), é

um software que tem por responsabilidade tratar do acesso ao banco de dados.

Já Oliveira (1999) trata de SGBD como sendo um sistema cuja responsabilidade é

de fazer o armazenamento dos dados e facilitar o acesso e a atualização das informações de

forma segura.

28

Podemos ainda definir um Sistema de Gerenciamento de Banco de dados como

sendo “[...] uma ferramenta poderosa para criar e gerenciar grandes quantidades de dados de

forma eficiente e permitir que esses dados persistam durante longos espaços de tempo com

segurança. Esses sistemas estão entre os tipos mais complexos de software disponíveis.”

(GARCIA-MOLINA, 2001, p. 1).

A figura a seguir mostra como está estruturado um SGBD:

Figura 3 – Estrutura e funções de um SGBD. Fonte: Date (2003)

Nota-se então a importância de um SGBD para o cliente. No entender de Garcia-

Molina (2001), um SGBD deve oferecer ao usuário alguns recursos, tais como a persistência

no armazenamento dos dados, interface de programação onde se pode manipular os dados de

29

forma simples e eficiente e ainda tem que ter o poder de gerenciar as transações, podendo

gerenciar o acesso aos dados e até fazer a recuperação de erros.

2.2.3 SQL

De acordo com Date (2003), SQL significa Structured Query Language, ou

linguagem de consulta estruturada. Foi originalmente desenvolvida pela IBM na década de

1970, e se tornou posteriormente, um padrão internacional.

Na SQL há a inclusão de dois componentes de linguagem, um para a definição

dos dados conhecida como DDL, e outro para a manipulação desses dados chamada de DML.

Na DDL temos três comandos principais: CREATE, ALTER e DROP. O

comando CREATE serve para criar objetos que até então não existiam no banco de dados, já

o comando ALTER tem o poder de modificar objetos previamente criados e finalmente o

comando DROP, elimina objetos criados pelo comando CREATE.

Por outro lado, de acordo com Date (2003), na DML existem comandos para a

manipulação de dados como: SELECT, INSERT, DELETE e UPDATE. O comando SELECT

seleciona linhas e recupera dados de uma tabela, o comando INSERT é responsável por

inserir linhas na tabela, já o DELETE exclui linhas de uma tabela e o UPDATE, atualiza uma

ou mais linhas de determinada tabela.

2.2.4 MySQL

O MySQL é um dos SGBDs mais utilizado no mundo todo, em especial em por

usuários do sistema operacional Linux. De acordo com Soares (2001), o MySQL é uma

ferramenta poderosa, com alto nível de segurança e ainda com a vantagem de ser fácil de usar.

Outras vantagens que esse SGBD apresenta são o fato de ele ser gratuito e ainda por estar

disponíveis em várias plataformas computacionais, tais como: Windows, Linux, MacOS, IBM

AIX, Sun Solaris entre outros.

Já Niederauer (2005) reforça a idéia da grande utilização do MySQL

principalmente em aplicações Web. Para o autor o MySQL “[...] é um SGBD (Sistema de

Gerência de Banco de Dados) relacional que utiliza a linguagem padrão SQL (Structured

30

Query Language), e é largamente utilizado em aplicações Web. É o mais popular entre os

bancos de dados com código-fonte aberto.”(NIEDERAUER, 2005, p.6).

A sua maior atratividade, de acordo com Niederauer (2005) é o fato de que o

MySQL é uma tecnologia complexa a um custo baixo. Suas principais características que

fazem com que ele seja tão bem divulgado mundialmente são a sua grande velocidade, sua

escalabilidade e, sobretudo sua confiabilidade. Algumas dessas vantagens estão citadas a

seguir:

• número ilimitado de utilização de usuários simultâneos; • capacidade de manipulação de tabelas com mais de 50.000.000 de registros; • alta velocidade de execução de comandos; • fácil e eficiente controle de privilégios de usuários. (NIEDERAUER, 2005,

p.6).

No site oficial da MySQL AB (2008), estão destacados as principais

características do MySQL, que são a de trabalhar com grande volume de dados,

disponibilizando-os a todos que necessitam deles a qualquer momento, com a vantagem de

que o SGBD é disponibilizado à custo zero. Outra vantagem é que o MySQL permite o acesso

das principais linguagens de programação, tais como o PHP, Java, Delphi.

Criada por David Axmark, Allan Larsson e Michael Widenius, a empresa MySQL

AB detém a marca MySQL, do domínio mysql.com e ainda do código fonte do MySQL

Server. Atualmente, segundo o site da MySQL AB, nos dias atuais, o MySQL é o SGBD de

código aberto mais utilizado no mundo todo, chegando a ultrapassar a marca dos 6 milhões de

instalações. Dentre os grandes usuários do SGBD, a empresa destaca a NASA, Yahoo,

Motorola, entre outras.

2.3 ORIENTAÇÃO A OBJETOS

A Orientação a Objetos, de acordo com Bezerra (2002) é um novo paradigma1 na

modelagem e construção de sistemas.

1 “[...] forma de abordar um problema.” (BEZERRA, 2002, p. 5).

31

O paradigma da orientação a objetos visualiza um sistema de software como uma

coleção de agentes interconectados chamados objetos. Cada objeto é responsável por realizar

tarefas específicas. É através da interação entre objetos que uma tarefa computacional é

realizada. (BEZERRA, 2002, p. 6).

Outra definição de Orientação a Objetos pode ser:

“A Orientação a Objetos (OO) é uma técnica de programação que se baseia na

construção e utilização de objetos. Um objeto, ao combinar dados e operações específicas

delimita um conjunto particular de funcionalidades ou responsabilidades.” (JANDL JUNIOR,

2007, p. 76).

Conforme Jandl Junior (2007), técnicas de orientação a objetos se mostram muito

eficientes, uma vez que define a responsabilidade de cada objeto, permite a reusabilidade e

ainda facilita a modificação e manutenção do sistema.

Bom, falou-se até aqui sobre o que é Orientação a Objetos, mas falta ainda definir

alguns conceitos, como objeto. Um objeto, de acordo com Bezerra (2002) são as coisas

existentes no mundo real, e que são representadas posteriormente na Orientação a Objetos.

Essas coisas podem ser uma pessoa, um livro entre inúmeras outras.

Outro conceito fundamental para o entendimento de OO é de classe, que pode ser

assim definido:

Uma classe é um modelo para um novo tipo de objeto que pode ser definido pelo programador, que relaciona suas características e comportamentos (funcionalidades) e que pode representar uma entidade real ou abstrata. Sendo assim, são utilizadas classes para definir novos tipos de objetos. (JANDL JUNIOR, 2007, p. 76).

Com a definição acima podemos perceber que classe é algo como uma forma,

onde se pode construir objetos, que herdam características dessa classe, mas podem ainda ter

outras que não foram definidas na classe da qual pertencem.

Para que os objetos executem suas operações, é necessário que os mesmos

recebam estímulos para realizar determinadas tarefas. Conforme Bezerra (2002), quando um

objeto recebe um estímulo, pode-se dizer que ele está recebendo uma mensagem solicitando a

realização de alguma tarefa. Dentro de um sistema ocorre a troca de mensagens entre objetos

constantemente, como mostra a figura a seguir:

32

Figura 4 – Troca de mensagens entre objetos. Fonte: Bezerra (2002)

Outra coisa a ser levada em consideração na Orientação a Objetos é a abstração,

que pode ser assim definido:

“Uma abstração é qualquer modelo que inclui os aspectos mais importantes,

essenciais de alguma coisa, ao mesmo tempo em que ignora os detalhes menos importantes.”

(BEZERRA, 2002, p. 8).

A abstração se torna muito importante então para OO, uma vez que permite focar

na parte importante do projeto, deixando de lado as que não interessam muito ao

desenvolvedor.

Os tipos de abstração encontradas em OO são o encapsulamento, o polimorfismo

e a herança, como podemos observar na ilustração a seguir:

33

Figura 5 – Abstração, encapsulamento, herança e polimorfismo. Fonte: Bezerra (2002)

Em relação ao encapsulamento, Bezerra (2002, p. 9) o define como sendo “[...]

uma forma de restringir o acesso ao comportamento interno de um objeto”. Isso quer dizer

que para um objeto A pedir colaboração para o objeto B, o requisitante, ou seja, A, não

precisa saber como B vai realizar o processo, basta saber se ele pode ou não realizar tal tarefa.

Já o polimorfismo “[...] indica a capacidade de abstrair várias implementações

diferentes em uma única interface.” (BEZERRA, 2002, p.10). Isso significa que um objeto

pode fazer solicitações para outros objetos semelhantes, embora esses implementem sua

interface1 de formas variadas.

E finalmente a herança, que “[...] facilita o compartilhamento de comportamento

comum entre um conjunto de classes semelhantes. Além disso, as diferenças ou variações de

uma classe em particular podem ser organizadas de forma mais clara”. (BEZERRA, 2002,

p.10).

2.3.1 Análise Orientada a Objetos

A análise é um processo muitíssimo importante para a concepção de bons

sistemas de informação, uma vez que é nesse processo que se ocorre todo o processo de

investigação do problema a ser solucionado pelo sistema. De acordo do Wazlawick (2004),

muitos problemas são solucionados antes da implementação do software, fazendo-se uso de

1 “[...] a interface de um objeto é o que ele conhece e o que ele sabe fazer, sem descrever como o objeto o conhece o faz. (BEZERRA, 2002, p. 9)

34

uma boa análise do mesmo. O tempo “perdido” na análise na maioria das vezes é bem menor

do que o tempo gasto para solucionar problemas no software depois de pronto.

A análise orientada a objetos, conforme Yourdon (1999, p. 7) é um modelo que

“[...] retrata objetos que representam um domínio de aplicação específico, juntamente com

diversos relacionamentos estruturais e de comunicação. [...].”

O modelo de AOO serve para dois propósitos:

Primeiro, para formalizar a “visão” do mundo real dentro do qual o sistema de software será construído. Ele estabelece os objetos que servirão como as principais estruturas organizacionais do sistema de software, bem como as principais estruturas organizacionais que o mundo real impõe em qualquer sistema de software construído naquele domínio de aplicação. Em segundo lugar, o modelo de AOO estabelece a maneira pela qual um dado conjunto de objetos colabora para executar o trabalho do sistema de software que está sendo especificado. Essa colaboração é representada no modelo como um conjunto de conexões de mensagens que mostram como cada objeto se comunica com os demais. (YOURDON, 1999, p. 7-8).

A modelagem orientada a objetos, de acordo com Yourdon (1999), está dividida

em 5 camadas, que são: no primeiro nível a camada de Classes e Objetos, no segundo

camada de atributos, em seguida a de serviços, estruturas e assuntos.

Entende-se por objeto em AOO como sendo “[...] abstrações de conceito do

domínio de aplicação do mundo real. Esta camada representa as bases do modelo de AOO

como um todo”. (YOURDON, 1999, p. 8). Na figura a seguir há a analogia entre uma pessoa

e um objeto, ou seja, como o objeto pessoa poderia ser representado em AOO, onde menina

seria um objeto do tipo pessoa, que seria composto por membros:

35

Figura 6 – Analogia entre pessoa e objeto Fonte: Yourdon (1999)

2.3.2 UML

2.3.2.1 Definição

A UML é uma linguagem gráfica muito utilizada mundialmente para a elaboração

de sistemas que vão desde os mais simples até os mais complexos. Uma definição mais

precisa sobre UML pode ser dada como:

A UML (Unified Modeling Language) é uma linguagem-padrão para elaboração da estrutura de projetos de software. A UML poderá ser empregada para a visualização, a especificação, a construção e a documentação de artefatos que façam uso de sistemas complexos de software. (BOOCH, 2000, p. 13).

36

Ainda conforme Booch (2000), esta linguagem se destina a modelagem de

sistemas que vão desde softwares corporativos baseados na Internet1 até programas embutidos

com grande grau de complexidade.

Na visão de Fowler (2000), a UML é:

“[...] uma linguagem de modelagem; não um método. A maioria dos métodos consiste, pelo menos e, princípio, de uma linguagem de modelagem e de um processo. A linguagem de modelagem é a notação (principalmente gráfica) utilizada por métodos para expressar projetos. O processo é a sugestão de quais passos a serem seguidos na elaboração de um projeto.” (FOWLER, 2000, p. 19)

Também se pode definir UML como sendo “[...] uma linguagem visual para

modelar sistemas orientados a objetos. Isso quer dizer que a UML é uma linguagem

constituída de elementos gráficos (visuais) utilizados na modelagem que permitem representar

os conceitos do paradigma da orientação a objetos.” (BEZERRA, 2002, p. 58).

Na definição acima podemos perceber a importância do uso da UML para a

criação de sistemas orientados a objetos, já que esta linguagem nos permite modelar

visualmente tais sistemas, facilitando em muito todo o processo de criação.

Já na visão de Soares (2001), a UML é uma linguagem que se destina à

estruturação de projetos. De acordo com o autor, a UML pode ser utilizada em vários tipos e

tamanhos de projetos, tornando todo o processo transparente e criando uma organização que,

sem a utilização de tal linguagem, seria difícil, se não impossível de se conseguir.

Com a UML você pode especificar, visualizar, construir e documentar todo o sistema a ser desenvolvido. Um dos principais objetivos da UML é tornar todo o processo de desenvolvimento totalmente transparente e organizado, permitindo que várias pessoas ou até mesmo vários grupos trabalhem de forma sincronizada e com menor perda de tempo possível, pois está tudo lá; desde a definição das classes até os casos de uso do sistema. (SOARES, 2001, p. 16).

1 A Internet poder ser definida como sendo “[...] um conjunto de redes de computador interligadas pelo mundo inteiro, que têm em comum um conjunto de protocolos e serviços, de forma que os usuários a ela conectados possam usufruir serviços de informação e comunicação de alcance mundial.” (MARCONDES, 2001, p. 2).

37

Fica evidente que a UML é peça fundamental para a o desenvolvimento de

projetos, uma vez que ela se destina a facilitar tanto o próprio desenvolvimento quanto o

entendimento do mesmo posteriormente, inclusive por pessoas que não participaram do

processo de desenvolvimento.

Booch (2000) nos lembra que a UML é somente uma linguagem, que se torna um

elemento de um processo de desenvolvimento de sistemas. A UML facilita o entendimento de

um sistema, embora que seja necessária a criação de vários modelos e que esses estejam

interconectados, possibilitando o entendimento de qualquer aspecto do sistema envolvido. A

linguagem UML indica como se cria e se lê modelos de sistemas, porém esta não sugere quais

e nem quando os modelos devem ser criados, pois “[...] essa tarefa cabe ao processo de

desenvolvimento de software.” (BOOCH, 2000, p. 13).

2.3.2.2 Histórico da UML

De acordo com Soares (2001), a UML se originou em função da necessidade de

técnicas que fossem mais adequadas para a especificação de sistemas de grande porte. Na

época havia três técnicas, Booch, OOSE e OMT, que a partir de então começaram a caminhar

em uma única direção. Os responsáveis por tais técnicas eram Grady Booch, Ivar Jacobson e

James Rumbaugh.

Em meados dos anos 90, como nos diz Soares (2001), Booch, Jacobson e

Rombaugh resolveram unir esforços e a partir daí criar uma nova técnica, que seria única e

abrangente, ou seja, contendo os pontos fortes de cada técnica e eliminando seus pontos

fracos.

No entender de Booch (2000), no início do projeto de unificação foram traçados

três objetivos:

• Permitir a modelagem de sistemas utilizando técnicas de orientação à

objetos;

• Auxiliar nos projetos de grande complexidade;

• Fazer uma única linguagem de programação que fosse entendida tanto por

pessoas quanto por computadores.

38

Surge então, no mês de outubro de 1995, um desenho do que seria a versão 0.8 da

UML. Posteriormente houve a cooperação de várias empresas mundialmente conhecidas para

um aperfeiçoamento da UML, dentre essas empresas, Soares (2001) destaca a Rational,

Microsoft, Oracle, IBM, HP entre outras. A versão 1.0 da UML já é consagrada como uma

linguagem bem-definida e poderosa.

A versão 1.1 da UML surgiu no ano de 1997 e a OMG a adota como linguagem

padrão para modelagem. Em 1998 foi lançada a versão 1.2 e no final deste mesmo ano, a

versão 1.3.

2.3.2.3 Diagramas da UML

Na UML são empregados vários diagramas, a fim de possibilitar a visualização

dos modelos que estão sendo construídos sob diferentes perspectivas. Para um melhor

entendimento, podemos ver a definição do autor sobre o termo diagrama:

“Um diagrama é uma apresentação gráfica de um conjunto de elementos,

geralmente representados como um gráfico conectado de vértices (itens) e arcos

(relacionamentos).” (BOOCH, 2000, p. 89).

No todo são nove os diagramas que compõe a UML, e estes estão divididos em

dois grupos: os diagramas estruturais, que servem para visualizar e documentar os aspectos

estáticos do sistema, e os comportamentais, que diferem dos anteriores por tratarem dos

aspectos dinâmicos do sistema. Fazem parte do grupo de diagramas estruturas, conforme

Booch (2000) os seguintes digramas:

39

Figura 7 – Diagramas da UML Fonte: Bezerra(2002)

• Digrama de classes � de acordo com Booch (2000) são os diagramas

mais facilmente encontrados em modelagens de sistemas orientados a

objetos. “Um digrama de classes mostra um conjunto de classes,

interfaces e colaborações e seus relacionamentos.” (BOOCH, 2000, p. 94).

• Diagrama de objetos � são utilizados para ilustrar “[...] a estrutura de

dados, registros estáticos de instâncias dos itens encontrados nos digramas

de classes.” (BOOCH, 2000, p. 94).

• Diagrama de componentes � esse diagrama, conforme Booch (2000)

serve para ilustrar os componentes e o relacionamento dos mesmos.

• Diagrama de implantação � “Um diagrama de implantação mostra um

conjunto de nós1 e seus relacionamentos.” (BOOCH, 2000, p. 94).

Já em se tratando de diagramas comportamentais estão incluídos nesse grupo, de

acordo com Booch (2000):

1 “Um nó é um elemento físico que existe em tempo de execução e representa um recurso computacional, geralmente tendo pelo menos alguma memória e, freqüentemente, capacidade de processamento.” (BOOCH, 2000, p. 356).

40

• Diagrama de casos de uso � é muito importante para organizar e modelar

os componentes de um sistema. “Um diagrama de caso de uso mostra um

conjunto de casos de uso e atores (um tipo especial de classe) e seus

relacionamentos.” (BOOCH, 2000, p. 95).

• Diagrama de seqüência � “Um diagrama de seqüência é um diagrama de

interação que dá ênfase à ordenação temporal de mensagens.” (BOOCH,

2000, p. 95). Isso significa que ele trata dos objetos e das mensagens

enviadas e recebidas pelos mesmos.

• Diagrama de colaboração � esse diagrama trata da organização estrutural

dos objetos, que de acordo com Booch (2000), enviam e recebem

mensagens. “Um diagrama de colaboração mostra um conjunto de objetos,

as conexões existentes entre esses objetos e as mensagens enviadas e

recebidas pelos objetos.” (BOOCH, 2000, p. 95).

• Diagrama de gráfico de estados � esses diagramas enfatizam o

comportamento de um objeto, que é alterado por eventos. “Um diagrama

de gráfico de estados mostra uma máquina de estados, que consiste de

estados, transições, eventos e atividades.” (BOOCH, 2000, p. 95).

• Diagrama de atividades � diagrama utilizado para mostrar o fluxo de

atividades que ocorrem em um sistema. “Uma atividade mostra um

conjunto de atividades, o fluxo seqüencial ou ramificado de uma atividade

para outra e os objetos que realizam ou sofrem ações.” (BOOCH, 2000, p.

95).

2.3.3 Programação Orientada a Objetos

Entende-se por Programação Orientada a Objetos como sendo “[...] um paradigma

de programação de computadores onde se usam classes de objetos, criados a partir dos

modelos descritos [...], para representar e processar dados usando programas de

computadores.” (SANTOS, 2003, p. 4).

Esses modelos anteriormente mencionados nada mais são que simples

representações de objetos utilizados por pessoas diariamente. De acordo com Santos (2003),

41

eles devem ser abstraídos do mundo computacional, ou seja, independem do uso ou não de

computadores para sua existência e utilização.

Modelos podem conter operações ou procedimentos que, segundo Santos (2003),

são comandos encarregados de processar dados contidos no mesmo. Há ainda a possibilidade

da criação de modelos em que só encontremos dados ou somente operações, embora que seja

interessante não trabalhar somente com dados, mas também com operações sobre eles. Já os

que possuam somente operações fazem mais sentido de existirem e são chamados de

bibliotecas de operações.

Na programação orientada a objetos ainda podemos contar com o

encapsulamento, que é “a capacidade de ocultar dados dentro de modelos, permitindo que

somente operações especializadas ou dedicadas manipulem os dados ocultos [...]” (SANTOS,

2003, p. 6). Na verdade, de acordo com autor, o encapsulamento deve ser sempre levado em

consideração por um programador que se utiliza de uma linguagem orientada a objetos.

Outra coisa importante na programação orientada à objetos é a utilização de

classes, que “[...] são estruturas das linguagens de programação orientadas a objetos para

conter, para determinado modelo, os dados que devem ser representados e as operações que

devem ser efetuadas com esses dados”. (SANTOS, 2003, p. 14). O autor ainda nos lembra da

importância do cuidado na hora da nomeação da classe, pois esta deve ser fácil de lembrar e

ainda com alguma associação ao modelo em que está sendo utilizada.

Uma melhor definição de classe é representada abaixo:

Classes são escritas com os recursos e regras da linguagem de programação orientada a objetos para implementação dos modelos, mas em muitos casos as classes são somente moldes ou formas que representam os modelos abstratamente. Para representação dos dados específicos usando classes deste tipo será necessária a criação de objetos ou instâncias desta classe. Um objeto ou instância é uma materialização da classe, e assim pode ser usado para representar dados e executar operações. Para que os objetos ou instâncias possam ser manipulados, é necessária a criação de referências a estes objetos, que são basicamente variáveis do “tipo” da classe (SANTOS, 2003, p. 14)

Já os métodos, de acordo com Santos (2003), são as operações que se encontram

mantidas numa classe e os dados contidos na classe são seus campos ou atributos.

42

2.4 JAVA

2.4.1 Conceitos

A linguagem de programação Java é mundialmente conhecida pelos fatos de ser

orientada a objetos e de ser multiplataforma. No entender de Niemeyer (2000) os programas

criados nessa linguagem são compilados e interpretados. Os códigos-fontes escritos em Java

são transformados em instruções binárias, sendo compilados em formato comum,

independente da plataforma em que será executado.

Como o Java é orientado a objetos, unidade essencial do código são as classes,

que podem ser definidas como:

“[...] componentes da aplicação que mantêm código executável e dados. As classes compiladas da Java são distribuídas em formato binário universal, que contém o código de bytes da Java e outras informações da classe. As classes podem ser mantidas separadamente e armazenadas em arquivos ou pacotes em um sistema local ou servidor de rede1. As classes são localizadas e carregadas dinamicamente na runtime, quando são exigidas por uma aplicação.” (NIEMEYER, 2000. p. 6).

Já para Sierra e Bates (2007, p. 25), em Java a classe é:

“[...] é o projeto de um objeto. Ela informa à máquina virtual como criar um objeto desse tipo específico. Cada objeto criado a partir dessa classe terá seus próprios valores para variáveis de instância da classe. Por exemplo, você pode usar a classe Button para criar vários botões diferentes, e cada botão poderá ter sua própria cor, tamanho, forma, rótulo e assim por diante”.

Apesar da semelhança de sintaxe com C e o C++, segundo Niemeyer (2000), essa

aparente similaridade pára por aí. Na verdade, em alguns aspectos ela se assemelha mais com

o Smalltalk e Lisp do que com as linguagens de programação C e C++. Podemos ter uma

idéia da comparação da Java com outras linguagens de programação na figura a seguir:

1 Redes de Computadores é, de acordo com Tanenbaum (1997, p. 2), “[...] um conjunto de computadores autônomos interconectados.”

43

Figura 8 – Comparação entre Java e outras linguagens Fonte: Niemeyer, 2000.

Observando-se a figura anterior, podemos ver que a linguagem de programação

Java é a única dentre as apresentadas que consegue ter um equilíbrio nos três pilares que são a

velocidade, segurança e a portabilidade.

Os códigos Java, de acordo com Sierra e Bates (2007) podem ser escritos em

qualquer editor de texto, como o bloco de notas do Windows, por exemplo, desde que seja

atribuída a eles a extensão correta no nome do arquivo. Isso significa que o desenvolvedor

não precisará desembolsar dinheiro para adquirir um programa específico para o

desenvolvimento de seus aplicativos e ainda gera a facilidade de poder desenvolver os

códigos em outros computadores que contém com um simples editor de texto, coisa que

praticamente todos os computadores atuais têm. Porém vale lembrar que há muitos ambientes

de desenvolvimento Java disponíveis gratuitamente, como o Netbeans e o Eclipse. Esses

programas facilitam a vida do programador por indicarem erros de sintaxe no código-fonte,

apresentar uma interface amigável e com inúmeros recursos e ainda permitirem o teste e

compilação dos códigos, sem a necessidade de recorrer ao prompt de comando.

Porém, apesar dessa aparente simplicidade quanto ao uso de editores de texto para

a programação, há a necessidade da compilação do código e depois, para que esse código seja

executado em determinado equipamento, é necessário que este tenha uma Máquina Virtual

para interpretar esse código. Podemos perceber isso no trecho abaixo:

Como você sabe, o mecanismo por trás de todo aplicativo Java (ou applet, servlet etc) é a JVM.

44

Uma vez que você tenha compilado seu código-fonte Java em um (ou mais) arquivos de classe e, opcionalmente, incluído em um arquivo JAR (Java Archive, repositório de arquivos Java), a JVM transforma os arquivos de classe (mais precisamente, o código de byte nos arquivos de classe) no código de máquina para a plataforma que está executando a JVM. A JVM também é responsável por fornecer segurança, alocar e não alocar memória, e gerenciar linhas de execução. É ela que faz seus programas Java funcionarem, por assim dizer. (MUCHOW, 2004, p. 5).

Ainda, segundo Johnson (2007), quando compilamos um programa escrito em

Java, gera-se um bytecode1, que é lido por um interpretador chamado de Máquina Virtual

Java, ou simplesmente, JVM. Para que um programa desenvolvido em Java rode num

equipamento, é necessário que este tenha a JVM adequada ao seu sistema operacional

instalada, pois é esta que vai traduzir para a linguagem de máquina em tempo de execução.

Com isso, podemos concluir a importância na Máquina Virtual, ou JVM, para a

execução das aplicações desenvolvidas em Java. Também se percebe que a Máquina Virtual

está intimamente relacionada à plataforma em que está sendo executada, ou seja, diferentes

sistemas operacionais utilizam diferentes Máquinas Virtuais desenvolvidas para os mesmos,

mas que consigam interpretar o código de forma semelhante, possibilitando assim que uma

aplicação, por exemplo, que foi desenvolvido para o sistema operacional Windows, seja

executado perfeitamente em outro sistema operacional como o Linux ou Mac OS.

Alguns detalhes devem ser lembrados no desenvolvimento de um aplicativo Java,

como Mecenas (2003) nos alerta. Devemos no lembrar que o Java é “case sensitive”, ou seja,

o Java diferencia maiúsculas de minúsculas. Todo programa Java deve ter um método público

chamado “main”, pois é nesse método em que o código começa a ser executado. Há outras

características especiais citadas pelo autor, mas que não serão abordados no presente

momento.

2.4.2 Histórico

Conforme Jandl Junior (2007) a história do Java se deu início no ano de 1991,

com um pequeno grupo de desenvolvedores da Sun Microsystems. Esse grupo se denominava

Green e tinham como objetivo criar uma nova geração de computadores, que seriam portáteis,

1 É um código intermediário que a JVM irá interpretar.

45

inteligentes e com grande capacidade de comunicação entre si. Para que o projeto fosse bem

sucedido, optou-se por criar uma nova plataforma de desenvolvimento, que gerasse um

software com a capacidade de ser utilizado em vários tipos de equipamentos diferentes. Num

primeiro momento, foi escolhida a linguagem de programação C++, tendo em vista que os

integrantes do grupo já tinham experiência com essa linguagem.

A idéia de utilização do C++ durou pouco, pois essa era complicada de utilizar e

ainda não oferecia todos os recursos necessários para o desenvolvimento do projeto. Surgiu

então, por parte de James Gosling, a idéia de criar uma nova linguagem de programação, que

fosse portátil, fácil de programar e simples. Segundo Jandl Junior (2007), surgiu então a Oak,

uma linguagem de programação interpretada. Por problemas de copyright1, a nova linguagem

deveria mudar de nome, passando então para o seu nome atual, Java.

No início o Java não era muito conhecido e nem tinha nenhum uso específico. De

acordo com Jandl Junior (2007), foi em 1994, com o advento da internet, que o Java começa a

ser conhecido e utilizado. Em 1996 já se podia fazer download de pequenas aplicações Java

denominadas applets.

Em 1996 a Sun disponibiliza gratuitamente um conjunto de ferramentas para o

desenvolvimento de aplicações Java, surgindo assim o JDK 1.02. Em relação às plataformas o

autor nos diz:

As plataformas inicialmente atendidas foram: Sun Solaris e Microsoft Windows 95/NT. Uma vez que a especificação da linguagem e do ambiente de execução também foram colocados publicamente disponíveis, progressivamente foram aparecendo kits para outras plataformas, tais como IBM OS/2, Linux e Apple Mac. (JANDL JUNIOR, 2007, p. 21)

Como vimos, em 1996 o Java passou de uma linguagem desconhecida e sem uso

específico para uma linguagem mundialmente conhecida, com utilização em vários sistemas

operacionais. Sobre o sucesso que o Java tem atualmente, Johnson (2007) acrescenta que isso

se deve principalmente à portabilidade do código.

Outro fato curioso sobre a história do Java é a numeração da versão. De acordo

com Sierra e Bates (2007), essa numeração que acompanha o nome tem muito a ver com

questões de marketing. Por exemplo, o Java 1.5, logo após ser lançado foi renomeado para 1 Refere-se a direitos autorais.

46

Java 5, mas no kit do desenvolvedor o número da versão é 1.5. Essa versão ainda pode ser

encontrada com os nomes de Java 5.0 ou ainda de Tiger. Então o Java saltou da versão 1.4

diretamente para a versão 5.0, sem passar pelas versões 3.0 ou 4.0, o que é realmente

estranho. O Java encontra-se atualmente na versão 6.

2.4.3 Interfaces Gráficas do Java

O Java “[...] oferece capacidades únicas no desenvolvimento de aplicações

gráficas que, sem modificação ou recompilação, podem ser executados em diferentes

ambientes gráficos, o que é uma vantagem significativa, além das facilidades de seu

desenvolvimento.” (JANDL JUNIOR, 2007, p.148). Isso significa que a interface gráfica dos

programas desenvolvidos em Java se adapta a maioria dos sistemas operacionais atuais.

Em se tratando da interface gráfica das aplicações desenvolvidas em Java, estas

podem ser construídas basicamente por dois grupos de ferramentas, o AWT (Abstract

Window Toolkit) e o Swing.

O AWT, de acordo com Mecenas (2003) é um conjunto de ferramentas de janelas

abstratas, que foi desenvolvida levando em consideração as metas de portabilidade dos

programas Java.

O segredo é que o AWT executa apenas as funções comuns a todos os sistemas de janelas. Isso equivale dizer, entretanto, que os componentes do pacote java.awt estão diretamente relacionados com as capacidades gráficas da plataforma hospedeira. Dessa forma, um mesmo programa Java pode apresentar aparências diversas, quando executado em diferentes plataformas. (MECENAS, 2003, p. 169).

De acordo com Jandl Junior (2007), o AWT é bem robusto e sua biblioteca

implementa um mecanismo peer-to-peer, onde cada classe corresponde a um componente do

AWT, acessando os componentes nativos de cada sistema operacional.

O aspecto positivo disso é que o uso dos componentes de diferentes plataformas é facilitado por esta API Java, tornando transparentes as diferenças entre os sistemas operacionais. Uma aplicação AWT, que contém um botão, usará o componente nativo equivalente do sistema onde a aplicação é executada. Mesmo que a aparência

47

do componente apresente ligeira diferença, o comportamento e funcionalidade durante a operação serão os mesmos. No entanto, isso exige um mecanismo razoavelmente complexo e pesado de troca de mensagens entre o sistema operacional e a JVM, o que reduz a performance dos componentes AWT (daí serem chamados de componentes pesados ou heavy-weight components). Além disso, a quantidade de componentes disponíveis é relativamente pequena e a construção de novos componentes se torna complexa ou dependente da plataforma. (JANDL JUNIOR, 2007, p.149).

Por se tratar de componentes relativamente pesados, como afirma Mecenas

(2003), o AWT foi sendo substituído pelos componentes Swing, que além de serem mais

leves, têm a vantagem de serem mais flexíveis com maior portabilidade.

Os componentes Swing, segundo Jandl Junior (2007), são 100% Java, liberando

esses das restrições de cada plataforma e são considerados componentes leves, ou lightweight

components. Suas principais características são a grande capacidade de configuração, que

inclui a possibilidade de mudança da aparência visual dos programas, recursos de

acessibilidade a portadores de deficiências, pacote de classes para desenho 2D entre outras.

2.4.4 Acesso a Banco de Dados

Como a maior parte dos aplicativos desenvolvidos tem o intuído de armazenar,

manipular e recuperar dados, a linguagem de programação usada deve ter recursos e

ferramentas que auxiliem na conexão do sistema com o banco de dados.

No entender de Mecenas (2003), os bancos de dados atuais podem ser acessados

praticamente por sistemas desenvolvidos em qualquer linguagem, já que existem ferramentas

que auxiliam nesse processo como o ODBC (Open Database Connectivity).

O Java conta com um conjunto de ferramentas para acesso a interface ODBC,

conhecida como JDBC. O JDBC, de acordo com Mecenas (2003, p. 245) “[...] foi concebido

para oferecer acesso universal a dados, para programas escritos em Java”.

Já no entender de Jandl Junior (2007), o JDBC é uma API com componentes

necessários para o acesso aos SGBDRs por uma aplicação Java. Ela é “[...] considerada uma

das APIs mais importantes do Java, pois na prática é difícil imaginar uma aplicação de cunho

corporativo que não necessite armazenar, de modo organizado e confiável, grandes

quantidades de dados.” (JANDL JUNIOR, 2007, p. 336).

48

Na figura que segue, podemos perceber que o JDBC pode acessar tanto dados em

um SDBD local quanto num remoto:

Figura 9 – Funcionamento do JDBC. Fonte: Jandl Junior, 2007.

Diante disso podemos perceber a importância de tal ferramenta para facilitar o

acesso ao banco de dados através de aplicativos desenvolvidos com a linguagem de

programação Java.

2.4.5 Subdivisões do Java

A plataforma Java tem uma característica interessante, ela se subdivide em três

categorias, cada qual destinada a um tipo de plataforma de hardware.

De acordo com Jandl Junior (2007), o Java está organizado em três categorias, as

quais são: J2ME (Java Micro Edition), J2SE (Java Standard Edition) e J2EE (Java Enterprise

Edition). Johnson (2007) ainda nos fala de outra categoria, o Java Card.

49

Figura 10 – Subdivisões do Java Fonte: Johnson, 2007.

2.4.5.1 Java Standard Edition

O J2SE ou Java Standard Edition, segundo Johnson, é a plataforma geralmente

instalada em microcomputadores comuns, ou seja, desktops.

Sobre o Java Standard Edition Jandl Junior (2007, p. 22) nos diz:

“Integra os elementos padrão plataforma e permite o desenvolvimento de

aplicações de pequeno e médio porte. Inclui todas as APIs consideradas de base, além da

máquina virtual padrão”.

2.4.5.2 Java Enterprise Edition

O Java Enterprise Edition, ou J2EE é, conforme Jandl Junior (2007), voltada para

o desenvolvimento de aplicações corporativas complexas. Johnson complementa:

J2EE é a maior plataforma Java. Nela são definidos alguns padrões de desenvolvimento de software. É multicamada e baseada em componentes. Os programas são executados em servidores de aplicações, sendo essa plataforma usada principalmente para aplicações corporativas. (JOHNSON, 2007, p. 26)

As definições para o J2EE vão muito não param por aí. Para Alur, Crupi e Malks

(2004), o Java Enterprise Edition serve para a criação de softwares distribuídos. Essa versão é

uma unificação de todos os outros padrões e APIs relacionados a empresas.

50

De acordo com Alur, Crupi e Malks (2004), o J2EE apresenta muitas vantagens

para as empresas, das quais se destaca:

• O estabelecimento de padrões em diferentes áreas de uma empresa que

estejam utilizando algum recurso computacional. Esses padrões podem ser

desde conexão com o banco de dados até a definição de protocolos de

comunicação;

• A possibilidade de desenvolvimento de softwares bem implementados;

• Diminuição do tempo para o lançamento do produto;

• Aumento da produtividade do programador.

Através desses pontos anteriormente citados podemos perceber que o J2EE é de

grande valia para o desenvolvimento de sistemas que irão rodar em uma rede de

computadores local, ou ainda na Internet.

Segundo Muchow (2004) o J2EE tem suporte interno para servlets1, JSP2 e XML.

Pode-se concluir então que o J2EE é amplamente utilizado para desenvolvimento de sistemas

que devem rodar via web.

2.4.5.3 Java Micro Edition

De acordo com Johnson (2007), o J2ME foi lançado em 1999 e veio substituir

outra tecnologia lançada anteriormente pela Sun, o Personal Java, que era voltado a

dispositivos móveis, mas que não funcionava muito bem em aparelhos com pouco poder

computacional, como celulares. Como esses dispositivos são muito limitados em recursos, o

J2ME também possui um menor número de recursos que as versões J2SE e o J2EE.

Como existem diferenças entre os recursos disponíveis nos dispositivos móveis, o

J2ME foi dividido em dois tipos de configuração, o CLDC e o CDC. Conforme Muchow

1 “Um servlet é um componente web de tecnologia Java, gerenciado por um container e capaz de gerar conteúdo dinâmico.” (JANDL JUNIOR, 2007, p. 473).

2 “[...] JSP é a junção de elementos Java com código HTML por meio de marcações semelhantes ao XML.” (JANDL JUNIOR, 2007, p. 556).

51

(2004, p. 2), a configuração “define os recursos da linguagem Java e as bibliotecas Java

básicas da JVM para essa configuração em particular”.

Figura 11 – Diferenças entre CDC e CLDC

Fonte: Johnson, 2007.

Essa divisão é feita baseando-se nos recursos disponíveis no dispositivo, tais

como a quantidade de memória, tamanho e resolução da tela, e ainda, de acordo com Muchow

(2004), no tipo de conectividade e principalmente, no poder de processamento.

Os dispositivos que se enquadram no CDC (Configuração de Dispositivo

Conectado) são aqueles que têm menos limitações de recursos, pois conforme o autor, estes

dever possuir:

• 512 kilobytes (no mínimo) de memória para executar o Java. • 256 kilobytes (no mínimo) de memória para alocação de memória em tempo de

execucao. • Conectividade de rede, largura de banda possivelmente persistente e alta

(MUCHOW, 2004, p. 4).

Olhando para os requisitos acima, pode-se imaginar que a maioria dos atuais

dispositivos móveis se enquadrem no mesmo, porém é importante lembrar que pelo fato de

que esses aparelhos apresentem tamanho muito pequeno, há muitas limitações, deixando uma

grande quantidade de equipamentos para o outro perfil, o CLDC (Configuração de

Dispositivo Conectado Limitado). Os requisitos para estes dispositivos são bem mais fáceis

de serem alcançados, pois são os seguintes:

52

• 128 kilobytes de memória para executar o Java. • 32 kilobytes para alocação de memória em tempo de execucao. • Interface restrita com o usuário. • Baixo poder, normalmente alimentado por bateria. • Conectividade de rede, normalmente dispositivos sem fio com largura de banda

baixa e acesso intermitente. (MUCHOW, 2004, p. 4).

Fica claro a partir da comparação das duas configurações as diferenças de

requisitos para que um dispositivo móvel se enquadre em um ou outra categoria de

configuração. Mas Muchow (2004) nos lembra que alguns dispositivos como o PDA, celular,

pager entre outros se encaixaram na categoria do CLDC, pois todos apresentam características

comuns à essa categoria. Porém, um PDA tem tamanho de tela bem superior ao celular, bem

como poder de processamento maior. Para tratar desse problema, a Sun criou o conceito de

perfil no Java Micro Edition.

Perfil pode ser entendido como uma extensão de uma configuração. De acordo

com Muchow (2004), ao perfil cabe fornecer bibliotecas que serão utilizadas para o

desenvolvimento de um aplicativo para um dispositivo em particular. O perfil é definido pelo

MIDP, que de acordo com o autor é:

“[...] MIDP (Mobile Information Device Profile, perfil de dispositivo de informação móvel) define APIs para componentes, entrada e tratamento de eventos de interface com o usuário, armazenamento persistente, interligação em rede e cronômetros, levando em consideração as limitações de tela e memória dos dispositivos móveis”. (MUCHOW, 2004, p. 5).

A fim de tornar mais transparente essa idéia de divisão do Java Micro Edition,

pode-se observar a figura a seguir:

53

Figura 12 – Perfil e Configuração do J2ME

Fonte: Muchow, 2004.

No Java Micro Edition existe um mecanismo de persistência de dados que é muito

importante para o desenvolvimento de aplicações que necessitem armazenar e recuperar

futuramente informações. Esse mecanismo chama-se Record Management System (sistema de

gerenciamento de registro), ou simplesmente RMS, como é conhecido.

De acordo com Johnson (2007), o RMS é constituído por uma classe chamada

RecordStore, que é responsável pelos métodos de armazenamento, consulta, e também a

exclusão de dados.

Uma definição bem simplificada de RecordStore é dada pelo autor como sendo

um conjunto de registros ou ainda, lugar onde são armazenados esses registros, que são arrays

de bytes.

Uma informação importante acerca do RMS é que uma MIDlet1 pode acessar o

RecordStore criado por outra MIDlet, desde que seja definido isso pelo programador.

1 “Uma MIDlet é um aplicativo Java projetado para ser executado em um dispositivo móvel. Mais especificamente, uma MIDlet tem como classes Java básicas a CLDC e o MIDP.”(MUCHOW, 2004, p. 23).

54

Figura 13 – Acesso de RecordStore por MIDlets. Fonte: Johnson, 2007.

2.4.5.4 Java Card

O Java Card é atualmente a menor plataforma Java e segundo Johnson (2007),

possui mais limitações do que o J2ME. O Java Card possibilita que sejam criados programas

que sejam executados em cartões inteligentes, os smart cards.

2.5 COMPUTAÇÃO MÓVEL

2.5.1 Histórico

Ao contrário do que a maioria das pessoas imagina, os dispositivos

computacionais móveis já existem há muitos anos. De acordo com Alvez (2002), o

surgimento desses equipamentos se deu no início da década de 1980. Em 1981 Adam

Osborne lançou o que seria considerado o primeiro microcomputador portátil no mundo, e

55

este se chamavam Osborne-1. Este equipamento era auto-suficiente, pois possuía unidades de

disco, monitor, interface para impressora e modem, e era dotado de um processador de 8 bits

Z-80 e seu sistema operacional era o CP/M.

Na prática, é um pouco de exagero dizer que tal equipamento era portátil, já que o

mesmo pesava aproximadamente 10,5 kg, mas na época, esse peso era considerado pequeno,

comparado com os computadores existentes até então.

O Osborne-1 foi posteriormente substituído pelo Osborne Encore, que conforme

Alvez (2002) era mais compacto e compatível com a linha de computadores mais famosos da

época, o IBM-PC. O antigo monitor CRT foi substituído por um visor de LCD e seu teclado

tinha a possibilidade de ser dobrado, ficando com a aparência de uma bolsa fechada quando o

dispositivo se encontrava fechado.

O primeiro dispositivo realmente pequeno foi o Epson HX-20, que tinha um

pequeno visor com uma resolução de 120 x 32 pixels no modo gráfico. Segundo Alvez

(2002), o aparelho contava ainda com uma pequena impressora matricial, mas tinha sérios

problemas de limitação de hardware, como no armazenamento das informações, que era feito

numa fita cassete. Mesmo com limitações técnicas, o aparelho foi um sucesso.

Outros equipamentos surgiram com maiores recursos de hardware e software,

como:

“[...] o Sharp PC-5000, Epson PX-8, Tandy 100, NEC PC 8201-A e Olivetti M10 (esses três últimos eram na verdade produzidos por uma mesma empresa japonesa Kyocera). O Sharp PC-5000 rodava o sistema operacional MS-DOS, enquanto o Epson PX-8 trabalhava com o CP/M. Esses equipamentos possuíam um visor de cristal líquido com maior capacidade de apresentação, maior quantidade de memória e aplicativos internos, como o caso do Epson PX-8 que vinha com o WordStar embutido na ROM. O peso médio girava em torno de 1,8 Kg.” (ALVEZ, 2002, p. 21).

Como podemos perceber, houve grande avanço no que diz respeito a capacidade e

portabilidade dos equipamentos, mas ainda muito inferiores se comparados aos equipamentos

atuais que tem capacidade de processamento e armazenamento consideravelmente grandes

enquanto seu peso não passa de alguns gramas.

A verdadeira evolução desses equipamentos se deu quando foi criado um

equipamento pequeno o bastante para que coubesse no bolso, e a empresa que conseguiu

tamanha façanha foi a Palm. Como nos indica Alvez (2002), a Palm lançou um equipamento

56

com características dos atuais dispositivos no ano de 1992, e este se chamava Palm Pilot. Esse

dispositivo não possuía teclado e sim uma tela sensível ao toque, que vinha acompanhado de

uma caneta que se utilizava como apontador na tela, possibilitando ainda o reconhecimento da

escrita. O produto já vinha com vários softwares instalados e tinha a capacidade de se

comunicar com o microcomputador.

Paralelamente com os produtos da Palm, foram surgindo outros similares. O

problema é que o sistema operacional da Palm era proprietário. De acordo com Alvez (2002),

a Microsoft percebeu esse problema e desenvolveu um sistema operacional que pudesse ser

utilizado nesses dispositivos. Esse sistema operacional foi chamado de Windows CE, que

possui interface parecida com o sistema desktop e com arquitetura similar ao Windows NT.

Os sistemas operacionais citados acima, o Palm OS e o Windows CE, são os que

dominam o mercado atualmente. Uma curiosidade que não podia ser deixada de lado é que

em alguns produtos da Palm encontramos rodando o sistema operacional Windows CE.

Atualmente, de acordo com Johnson (2007), os dispositivos de computação móvel

podem ser classificados em três grupos, de acordo com seu poder computacional e recursos

que os mesmos disponibilizam ao usuário. No primeiro grupo, com grande poder

computacional (em se tratando de dispositivos móveis) estão os laptops. Num segundo grupo

estão os equipamentos com poder computacional intermediário, ou seja, menor que o primeiro

grupo mas maior que o terceiro. Neste grupo encontram-se os PDAs, como o Palm, equipados

com telas pequenas mas capacidade computacional razoavelmente alta. Já o terceiro grupo é

formado por telefones celulares, que vem evoluindo muito em relação à sua capacidade

computacional e em recursos. Os SmartPhones estão incluídos neste grupo, muito embora

incorporem a maioria dos recursos dos PDAs.

57

Figura 14 – Computação Móvel. Fonte: Johnson, 2007.

2.5.2 Palm

Os dispositivos da Palm atuais são uma evolução continuada dos seus

antecessores. Atualmente possui hardware com boa capacidade de processamento e

armazenamento, e quase todos têm entrada para cartões de memória, a fim de ampliar a

capacidade de armazenamento de dados.

58

Figura 15 – Palm E2.

Fonte: Submarino, 2008.

O sistema operacional Palm OS continua, segundo Alvez (2002), sendo

proprietário. Juntamente com o sistema operacional, vem instalado um pacote de softwares

muito úteis, como uma agenda eletrônica, calculadora entre outros.

2.5.2.1 Sincronização de dados e aplicativos

Há várias formas de comunicação entre o Palm e outros dispositivos, como

computadores, celulares entre outros, e com isso podendo até acessar a internet. As formas

mais triviais de conectar o Palm com outro dispositivo é através de cabo, Bluetooth,

infravermelho e wireless.

Para que o Palm se comunique corretamente com um microcomputador é

necessário a instalação de um software chamado Palm Desktop, fornecido pela própria Palm.

Por meio desse software, de acordo com Alvez (2002), pode-se inserir arquivos e/ou

programas que serão carregados ou instalados na próxima sincronização do dispositivo. Vale

59

lembrar que o software responsável por essa sincronização entre Palm e micro é o HotSync,

que deve estar instalado tanto no PDA quanto no micro.

Um detalhe importante e que não deve ser deixado de lado é a necessidade da

utilização de um conduíte, (conduit) para a troca de informações entre o computador e um

aplicativo Palm.

Para Borges (2002, p. 102), a definição de conduítes pode ser dada como sendo

“[...] aplicações para PCs que possibilitam o acesso, a partir do desktop, do sistema de

arquivos Palm.”

Figura 16 – Conduit. Fonte: Borges, 2002.

A definição anterior evidencia a importância da criação e utilização de um

conduíte para a sincronização dos dados entre os equipamentos. Muitas ferramentas de

programação, como o AppForge facilitam a criação de um conduíte padrão, também chamado

de Universal Conduit. Infelizmente, linguagens de programação como o Java não possuem

esse tipo de facilidade, pois o programador terá que desenvolver seu próprio conduíte, tarefa

demorada e nada fácil.

2.5.2.2 Aplicações para Palm OS

Os aplicativos para Palm devem estar num formato que o mesmo compreenda, e

este formato é o PRC, que nada mais é do que um código executável para o sistema

60

operacional Palm OS. Aí vem uma questão bem interessante, como executar aplicativos Java

no Palm?

De acordo com Muchow (2004), para que um aplicativo Java seja instalado em

um dispositivo que rode o sistema operacional da Palm, é necessário fazer a conversão desse

aplicativo. No caso do Java não é diferente, deve-se primeiramente instalar uma máquina

virtual específica para esse dispositivo e a partir daí, todos os aplicativos escritos na

linguagem de programação Java devem primeiramente passar por um processo de conversão.

Como foi citado anteriormente, antes de instalar softwares desenvolvidos em Java

e posteriormente convertidos para o formato PRC no Palm, faz-se necessário a instalação do

software Java, a JVM, neste dispositivo. Segundo Muchow (2004), essa JVM, em sua versão

1.0, era conhecida como Java HQ. Atualmente uma das JVMs para Palm OS é desenvolvido

pela IBM e chama-se WebSphere Micro Environment e suporta a configuração CLDC 1.1 e o

perfil MIDP 2.0. Há outras VMs disponíveis gratuitamente, como é o caso do SuperWaba

Virtual Machine, que encontra-se atualmente na versão 5.85. Porém é necessário lembrar que

o SuperWaba não á uma máquina virtual para aplicações desenvolvidas em Java, mas sim

para programas escritos na linguagem Waba.

Para que seja feita a conversão dos aplicativos desenvolvidos em Java, é

necessária a utilização de algum programa que faça esse trabalho. De acordo com Muchow

(2004), um exemplo desses softwares é o PRC Converter Tool, também da IBM e que é

distribuído junto com o WebSphere Micro Environment. O programa converte as MIDlets

que são distribuídas como dois arquivo (um JAD e um JAR) em um único arquivo PRC.

2.5.2.3 Simuladores

Apesar de atualmente ser fácil de adquirir um dispositivo Palm em virtude dos

baixos preços e grande variedade de modelos que atendem a quase todas as necessidades, nem

sempre é viável adquirir um aparelho desses, como no caso do desenvolvedor querer apenas

testar seus programas, mas não achar conveniente comprar o dispositivo só para esses testes.

E mesmo que tenhamos um Palm para rodar esses aplicativos, é conveniente primeiramente

testar a aplicação em um simulador antes de instalá-lo no equipamento real.

De acordo com Muchow (2004), um desses simuladores mundialmente

conhecidos é o Palm OS Emulator, ou POSE. Com esse simulador podemos emular vários

61

dispositivos Palm, de acordo com a ROM que será rodada. É nessa ROM, que não está

incluso no POSE, que se encontra a imagem do sistema operacional da Palm. É necessário

fazer o download da ROM com a versão exata do sistema operacional em que queremos testar

nossos aplicativos, porém, vale lembrar que se deve baixar a versão do sistema operacional

3.5 em diante, já que versões anteriores a essa, são muito limitadas em se tratando de

recursos.

Para Alvez (2002) o POSE é uma ferramenta muito importante, já que este

permite que testes dos aplicativos desenvolvidos possam ser feitos diretamente no

computador, sem a necessidade da instalação no dispositivo real.

2.5.2.4 Banco de Dados Palm

De acordo Borges (2002), a extensão dos bancos de dados do sistema Palm é

PDB. Já na definição de Alvez (2002), o banco de dados do Palm não possui extensão,

embora muitas pessoas achem que a extensão do banco de dados do Palm seja “.PDB”, esse é

apenas um tipo de arquivo gerado pelo Palm Desktop durante o backup. O banco de dados

Palm é composto por uma estrutura seqüencial e “[...] não possui o conceito de campos, tipo

de dados, chave primária e índices [...]”(ALVEZ, 2002, p. 143).

A estrutura do banco fica por conta do programador, bem como esses dados

deverão ser gravados nos registros, que não possuem tamanho definido.

A estrutura do banco de dados Palm é a seguinte:

“Um banco de dados Palm possui uma estrutura formada por um cabeçalho (Header) com 72 bytes fixos e blocos de dados com tamanho variável. Cada um desses blocos tem uma função dentro do banco de dados.” (ALVEZ, 2002, p. 143).

62

Figura 17 – Banco de Dados Palm. Fonte: Alvez, 2002.

É no cabeçalho que se encontra informações como o nome do banco de dados,

criador, data de criação, modificação e backup, versão do banco entre outras.

Já na lista de entradas de registro, de acordo com Alvez (2002), há informações

sobre todas as entradas de registros armazenados em determinado banco de dados.

Na entrada dos registros, há dados sobre atributos dos registros gravados no Palm.

Outra forma de armazenar informações de forma persistente nos dispositivos

móveis, para os aplicativos escritos em Java, é a utilização do RMS. Como foi visto

anteriormente, o RMS (Record Management System) permite que uma MIDlet acesse, grave e

exclua dados na memória não volátil dos dispositivos móveis, semelhante ao que acontece

com as informações armazenadas no banco de dados Palm.

2.6 AMBIENTES DE DESENVOLVIMENTO

2.6.1 NetBeans

De acordo com Gonçalves (2008), o Netbeans é uma IDE (Integrated

Development Environment) desenvolvida em Java Swing e para que seja possível utilizá-la,

faz-se necessário a instalação da JVM na máquina.

63

Já Gomes (2008) cita que o NetBeans é a IDE oficial da SUN para

desenvolvimento de aplicações em Java, tornando-se ideal para o desenvolvimento de

aplicações web que utilizem tecnologias tais como Hibernate, Spring e JSF.

Como se pode perceber pelas definições dos autores, o NetBeans é um ambiente

de desenvolvimento de aplicações Java, inclusive para Web, bem completo, que vem por

facilitar em muito a vida dos desenvolvedores desse tipo de sistema. Outro fato importante é

que o NetBeans pode ser instalado tanto no Sistema Operacional Windows quanto no Linux,

tendo em cada um sistema as suas particularidades mas com interface idêntica.

A instalação no Windows é bem tranqüila, já no Linux é interessante o

conhecimento de alguns comandos do prompt de comando desse sistema operacional.

Figura 18 – IDE NetBeans. Fonte: Acervo do autor.

O NetBeans pode ser utilizado desde o início do projeto, uma vez que com esta

ferramenta, pode-se tranqüilamente criar todos os diagramas comumente utilizados nos

sistemas orientados a objetos. Também pode-se trabalhar com toda a parte de criação do

64

código fonte do sistema com muita facilidade, bem como na criação visual de telas dos

softwares.

Como foi citado anteriormente, o NetBeans é ideal para desenvolvedores Web que

se utilizam de toda a robustez e segurança da linguagem de programação Java para as suas

aplicações. O NetBeans pode por exemplo criar páginas Java contidas em HTML, chamadas

de JavaServer Pages ou simplesmente JSP. Segundo Gonçalves (2008), as páginas JSP são

dinâmicas, sendo que “a primeira vez que uma página JSP é carregada pelo container JSP, o

código Java é compilado gerando um Servlet que é executado. As chamadas subseqüentes são

envidas diretamente ao Servlet, não havendo mais recompilação do código Java.

2.6.2 Power Architect

De acordo com o site oficial da SQL Power (2008), o Power*Architect Data

Modeling Tool é uma ferramenta open source destinada a DBA´s, analistas e desenvolvedores

de sistemas que necessitem de uma boa modelagem do banco de dados da aplicação.

A ferramenta é simples de utilizar e bem robusta, e com a facilidade poder ser

utilizada facilmente em vários sistemas operacionais, uma vez que é desenvolvida em Java.

Além de ser multiplataforma, outro fato anteriormente citado não pode ser deixado de lado, o

de ser Open Source, ao contrário de algumas ferramentas conhecidas como o Case Studio.

65

Figura 19 – Power Architect Fonte: Acervo do autor.

Como se pode perceber na figura anterior, o Power Architect tem uma interface

bem simples, mas nem por isso ele deixa de ser uma boa ferramenta para a modelagem do

banco de dados de forma rápida, e com vários recursos de teste, e ainda com a facilidade de se

conectar diretamente ao banco de dados e inserir o SQL sem dificuldades.

2.6.3 iReport

De acordo com o site oficial da JasperForge.org (2008), empresa que desenvolve

o iReport, ele foi criado por Teodor Danciu e é uma das melhores ferramentas disponíveis

para a construção de relatórios em sistemas desenvolvidos em Java.

Um dos grandes diferenciais do iReport em relação a maioria dos softwares que

tem por finalidade desenvolver relatórios para os programas em Java é a facilidade em que ele

proporciona, pois permite projetar relatórios visualmente, o que proporciona uma grande

66

facilidade até para quem nunca teve contato com esse tipo de ferramenta, e assim proporciona

o projeto de relatórios num tempo muito curto, mesmo que esses relatórios sejam complexos.

Figura 20 – iReport Fonte: Acervo do autor.

Como pode ser percebido na figura anterior, o iReport conta com um ambiente

visual bem fácil de usar e manipular, facilitando em muito a vida do desenvolvedor, que não

precisa ficar escrevendo manualmente tanto os comandos SQL quanto o código que será

inserido na aplicação, porém não impedindo que isso seja feito para que o relatório se adéqüe

a qualquer situação pretendida.

67

3 ANÁLISE

3.1 ANÁLISE DE REQUISITOS

1. O protótipo de sistema deve contar com telas para cadastro de funcionários,

contribuintes, materiais, serviços entre outros. Essas telas deverão ter aspecto

bem intuitivo, com funções para verificação e validação dos dados informados

pelo funcionário responsável pela utilização do sistema. Os dados desses

cadastros devem contemplar todas as informações essenciais ou que poderão

ser úteis futuramente.

2. Deverá haver a possibilidade de geração de relatórios para a análise e

divulgação dos serviços prestados aos contribuintes, gerando assim uma maior

transparência dos processos e gastos públicos bem como a utilização dessas

informações para se fazer uma previsão de gastos futuros;

3. Existência de um módulo para dispositivos móveis, preferencialmente

instalado num dispositivo com boa capacidade de armazenamento e

processamento de dados, como um Palm, por exemplo. Esse módulo deverá

ser focado na agenda de serviços a serem realizadas, para um melhor controle

das atividades;

4. O E-OBRAS deverá ter uma tela para solicitação de serviços, de forma que o

contribuinte, ao se dirigir a Secretaria de Obras, possa solicitar serviços para si

ou para sua região, e possibilitando que posteriormente esses dados sejam

recuperados de maneira rápida e fácil.

5. No agendamento de serviços, o protótipo deve ser capaz de agrupar

solicitações com características em comum, como o bairro que o serviço foi

solicitado, para com isso, verificar a viabilidade de determinado serviço em

determinado momento e diminuindo despesas com deslocação de máquinas,

equipamentos e pessoal de um lugar para outro do município.

68

6. Para que o protótipo ofereça certo grau de segurança, deverá exigir a

autenticação do usuário, ou seja, do funcionário habilitado a operar o mesmo.

Para a criação ou alteração de senhas, deverá exigir que o usuário informe um

senha que tenha um número mínimo de caracteres, não permitindo que sejam

criadas senhas muito curtas.

7. O protótipo deverá ser multiplataforma, a fim de ser perfeitamente compatível

com a maioria dos sistemas operacionais disponíveis atualmente, como

Windows e Linux. Para que isso seja possível, deverá ser criado numa

linguagem de programação que permita tal característica, como o Java e

utilizando como sistema gerenciador de banco de dados, o mundialmente

conhecido MySQL.

8. O protótipo do sofware desktop deverá ter sua estrutura baseada na orientação

a objetos.

3.2 DIAGRAMAS

Para o desenvolvimento dos diagramas referentes a este Trabalho de Conclusão de

Curso, foram utilizados para a construção dos modelos UML, o software NetBeans. Já para o

desenvolvimento do ERD foi dado preferência a outro software livre, que embora menos

conhecido que o famoso Case Studio, pose ser considerado equivalente ao mesmo. Esse

software citado anteriormente é o Power Architect.

3.2.1 Diagrama de Casos de Uso

O Diagrama de Casos de Uso do EObras é apresentado na próxima ilustração e

tem por finalidade apresentar o protótipo de modo simplificado, sem entrar em detalhes de

seu funcionamento. Isso para que seja fácil para qualquer pessoa, seja ela um profissional da

área ou ainda o cliente, ter uma noção de como e por quem serão executados os processos do

sistema.

69

Figura 21 – Diagrama de Casos de Uso. Fonte: Acervo do autor.

3.2.2 Diagrama de Classes

O Diagrama de Classes do protótipo de sistema EObras é representado na figura a

seguir. Nesse modelo podem-se verificar as associações entre as classes que compõe o

sistema, bem como o relacionamento entre as mesmas. Também é considerado um dos

principais diagramas da UML, por isso é essencial na modelagem de qualquer projeto de

sistema orientado a objetos.

70

Figura 22 – Diagrama de Classes. Fonte: Acervo do autor.

71

3.2.3 Diagrama de Atividades

Entende-se por atividades, todas as principais tarefas vinculadas ao protótipo de

sistema EObras. O diagrama de atividades permite então visualizar de forma simplificada as

tarefas do sistema, bem como as diferentes opções em alguns casos.

Para um melhor entendimento do protótipo, optou-se por fazer um diagrama de

atividades geral, englobando o sistema como um todo e outros diagramas que correspondem a

cada caso de uso.

Figura 23 – Diagrama de Atividades geral do protótipo. Fonte: Acervo do autor.

72

Os diagramas de atividades a seguir correspondem a alguns casos de usos do

protótipo do sistema, lembrando que não foram incluídos neste trabalho todos os diagramas

UML, pois com os diagramas nele contido, já é possível ter uma visão geral do protótipo.

Figura 24 – Diagrama de Atividades do cadastro de cidades.

Fonte: Acervo do autor.

Figura 25 – Diagrama de Atividades do cadastro de CEP. Fonte: Acervo do autor.

73

Figura 26 – Diagrama de Atividades do cadastro da Prefeitura. Fonte: Acervo do autor.

3.2.4 Modelo de Entidade Relacionamento

A figura abaixo mostra o Modelo de Entidade Relacionamento (MER), que serve

de base para o modelo de dados. Nesse modelo pode-se perceber a relação e cardinalidade

entre as tabelas do banco de dados relacional.

Percebe-se no modelo que a tabela principal do banco de dados é a

SOLICITACAO, que pode ter vários tipos diferentes e independentes de solicitações, sejam

elas de materiais, equipamentos, funcionários e serviço. Vale ressaltar que há a necessidade

de haver um contribuinte envolvido na solicitação, uma vez que a tabela CONTRIBUINTE é

ligada diretamente à tabela SOLICITACAO e seu valor não pode ser nulo, embora não faça

parte da chave primária de tal tabela.

74

Figura 27 – Modelo de Entidade Relacionamento. Fonte: Acervo do autor.

75

4 IMPLEMENTAÇÃO

Para o desenvolvimento do protótipo do sistema, utilizou-se a linguagem de

programação Java, que por ser uma linguagem multiplataforma adequou-se perfeitamente aos

propósitos iniciais. Aliado a essa poderosa linguagem de programação, foi utilizado um

ambiente de desenvolvimento bem completo, que é o caso do NetBeans. A escolha do

NetBeans se deu por vários motivos, dentre os quais vale destacar a facilidade que ele

proporciona ao programador, uma vez que no mesmo sistema, pode-se trabalhar com os

diagramas da UML, codificação do sistema, parte visual entre outros.

Já para o projeto e criação do banco de dados, foi escolhido a ferramenta Power

Architec aliada ao poderoso banco de dados MySQL. A escolha do MySQL foi certa, pois se

trata de um SGBD com características muito interessantes, tais como a confiabilidade, rapidez

e ainda pelo fato de ser gratuito. A seleção da ferramenta de modelagem do banco foi mais

complexa, uma vez que o nome mais cogitado entre a maioria dos programadores e o Case

Studio. Porém optou-se pela utilização do Power Architec, que se mostrou muito eficiente e

fácil de trabalhar, e ainda com a vantagem de ser multiplataforma, uma vez que e uma

ferramenta desenvolvida em Java, e basta ter a JVM instalada na máquina e executar o

programa. Apesar de não ter um visual como o Case Studio, suas funcionalidades são

praticamente as mesmas, facilitando muito a vida até mesmo de quem nunca teve o contato

com tal ferramenta.

Para a administração, gerenciamento e manipulação do bando de dados, optou-se

pela utilização do phpMyAdmin, pois o mesmo permite que se crie e depois manipule

facilmente uma base de dados, permitindo também visualizar de forma simplificada as

informações nela contida. Vale frisar que o phpMyAdmin também é multiplataforma, e esse

foi um dos principais motivos pela escolha de sua utilização, já que o sistema EObras esta

sendo desenvolvida em ambiente Linux.

76

Figura 28 – phpMyAdmin. Fonte: Acervo do autor.

O protótipo de sistema de gerenciamento de Secretarias de Obras Municipais, ou

simplesmente EObras, pode ser considerado um protótipo de sistema que apesar de contar

com funcionalidades básicas, se torna complexo pelas tecnologias nele empregadas. Não

estamos falando aqui de tecnologias triviais como o Delphi, HTML, PHP entre outros, mas

sim de um conjunto de ferramentas que se utilizam da linguagem de programação Java.

A idéia inicial da construção do protótipo consistiu na criação de um sistema

capaz de armazenar informações necessárias para o perfeito funcionamento da parte

administrativa de uma Secretaria de Obras Municipais, tais como a manutenção de cadastro

de equipamentos, veículos, funcionários, contribuintes a ainda, as solicitações e agendamento

de serviços para determinada região ou contribuinte.

Também se pensou na criação de uma interface Web para a disponibilização das

informações acerca das solicitações realizadas, para dar uma maior transparência na

realização das obras públicas. Para que isso seja possível, é necessário que o sistema rode de

um servidor, tal qual o Apache. Até o momento não foi implementado nem projetado nada em

relação à auditoria do sistema, pois devido à complexidade do mesmo, levaria um tempo

muito grande para analisar todas as possibilidades referentes a esse assunto.

77

Como já foi mencionado várias vezes neste Trabalho de Conclusão de Curso, o

sistema EObras está sendo desenvolvido com a linguagem de programação Java, que

atualmente e uma das mais promissoras, embora complexa, no mercado. Porém, para que esta

aplicação seja desenvolvida de maneira mais simples, no que se refere ao acesso ao banco de

dados, há a necessidade de adicionar ao projeto bibliotecas de ferramentas tais como o Spring,

Hibernate e ainda o MySQLConnector.

No caso do Spring, que é um framework de desenvolvimento Java, este tem por

finalidade facilitar a integração de algumas soluções como o Hibernate. No caso do EObras,

ele se torna vital, pois fará a integração entre o Hibernate, que fica na camada de persistência,

e o JSF, que é a camada Web.

O Hibernate é o responsável pela persistência dos dados. Na verdade ele não salva

diretamente as informações em tabelas dos bancos de dados relacionais, e sim nas classes

envolvidas, ou seja, ele facilita em muito a manipulação de dados em banco de dados

relacionais mesmo trabalhando com sistema Orientado a Objetos.

4.1 IMPORTAÇÃO DOS PACOTES

Para o desenvolvimento do protótipo fez-se necessário a importação, instalação e

configuração de pacotes específicos para o NetBeans. Tais pacotes, vitais para o

funcionamento do sistema, foram conseguidos através de downloads dos próprios fabricantes,

ou seja, do site dos desenvolvedores de tais ferramentas.

No caso do pacote do Spring, ele se encontrava disponível no endereço

www.springframework.org. Não será foco deste trabalho a instalação das bibliotecas, mas sim

as bibliotecas necessárias para o funcionamento do prototótipo. No site encontrou-se um

arquivo compactado contendo vários arquivos JAR, e que depois de descompactado, foram

utilizadas as seguintes bibliotecas:

a. dist\spring.jar

b. lib\c3p0\c3p0-0.9.1.1.jar

c. lib\cglib\cglib-nodep-2.1.3.jar

d. lib\ehcache\ehcache-1.2.4.jar

e. lib\jakarta-commons\commons-dbcp.jar

78

f. lib\jakarta-commons\commons-pool.jar

g. lib\j2ee\persistense.jar

h. lib\j2ee\jsf-api.jar

Já para a utilização do Hibernate, o processo é um pouco mais complexo, pois se

tratam de dois arquivos zipados, um chamado Hibernate Core e o outro Hibernate Entity-

Manager, ambos disponíveis em www.hibernate.org. Para o desenvolvimento, foi necessária a

descompactação dos dois arquivos numa pasta e a seguir, foram adicionadas as seguintes

bibliotecas ao projeto:

a. hibernate-3.2\hibernate3.jar

b. hibernate-3.2\lib\ant-1.6.5.jar

c. hibernate-3.2\lib\ant-antlr-1.6.5.jar

d. hibernate-3.2\lib\antlr-2.7.6.jar

e. hibernate-3.2\lib\asm.jar

f. hibernate-3.2\lib\asm-attrs.jar

g. hibernate-3.2\lib\cglib-2.1.3.jar

h. hibernate-3.2\lib\commons-collections-2.1.1.jar

i. hibernate-3.2\lib\commons-logging-1.0.4.jar

j. hibernate-3.2\lib\dom4j-1.6.1.jar

k. hibernate-3.2\lib\ehcache-1.2.3.jar

l. hibernate-3.2\lib\javaassist.jar

m. hibernate-3.2\lib\jdbc2_0-stdext.jar

n. hibernate-3.2\lib\jta.jar

o. hibernate\hibernate-entitymanager-3.1.1.GA\hibernate-entitymanager.jar

p. hibernate\hibernate-entitymanager-3.1.1.GA\lib\ejb3-persistence.jar

q. hibernate\hibernate-entitymanager-3.1.1.GA\lib\hibernate-annotations.jar

r. hibernate\hibernate-entitymanager-3.1.1.GA\lib\hibernate-commons

-annotations.jar

s. hibernate\hibernate-entitymanager-3.1.1.GA\lib\jboss-archive.browsing.jar

Apesar de serem muitas as bibliotecas do Hibernate para serem inclusas no

sistema, o processo é bem simples, tal qual como a importação das bibliotecas do Spring.

79

Finalmente, para fazer a conexão com o banco de dados MySQL, houve a

necessidade de se utilizar um driver específico para isso, que é o MySQL ConectorJ, que se

encontra disponível no site www.mysql.org. Assim como nos casos anteriores, o arquivo teve

de ser descompactado antes de ser utilizado. Depois desse processo, foi adicionada a seguinte

biblioteca no projeto:

a. mysql-connector-java-5.1.6-bin.jar

Apesar de ser um grande número de bibliotecas para serem adicionadas ao

projeto, o processo é bem simplificado, pois o NetBeans dá a opção de importar bibliotecas de

maneira descomplicada e rápida. Talvez o único problema seja encontrar as versões corretas

de cada biblioteca, pois nota-se claramente que existem diferenças em cada versão dos

pacotes.

4.2 BANCO DE DADOS

Deixando de lado os requisitos iniciais para a criação do protótipo, como a

importação dos pacotes de bibliotecas, a criação dos diagramas e do Modelo de Entidade

Relacionamento, houve a necessidade de testar o código SQL gerada pelo Power Architect.

Para tal foi feita uma verificação do código, na busca de alguma anormalidade e após alguns

testes de inserção, exclusão e alteração dentro do próprio phpMyAdmin.

No screenshot do dump do referido banco, pode-se perceber no início,

informações acerca do phpMyAdmin, sua versão, o host onde está rodando (no caso

Localhost), bem como a data e hora da criação do referido dump e a versão do servidor. Pode-

se ainda observar o código necessário para a criação da tabela AGENDA e suas colunas.

80

Figura 29 – Trecho do dump do banco. Fonte: Acervo do autor

A tabela AGENDA, por exemplo, armazena informações sobre agendamentos de

serviços, tendo como chave primaria o próprio numero da solicitação do qual foi criado o

agendamento.

4.3 CLASSES DE NEGÓCIO

O protótipo do sistema EObras foi desenvolvido em camadas distintas, uma, a de

negócios, responsável pelo acesso ao banco de dados, das funções e outras funcionalidades ao

sistema, e a aplicação web, destinada a disponibilizar essas funcionalidades desenvolvidas na

camada de negócios bem como os dados contidos na base de dados e criar uma interface

amigável para o usuário.

81

O primeiro passo foi configurar a conexão com o banco de dados, com a

utilização do mysql-connector. Essa conexão foi necessária para que fosse feito todo o

mapeamento da base de dados, gerando as classes que compõe o sistema.

Todo o processo de mapeamento foi feito utilizando-se recursos do NetBeans e

suas livrarias, facilitando a vida do programador e agilizando o processo de desenvolvimento.

Para que seja mais padronizado e organizado, as classes criadas foram inseridas

dentro de packages, fáceis de identificar. Um caso que ocorre esse tipo de situação e quando

foram criadas as classes oriundas do mapeamento do banco de dados, que se encontram no

package Domínio.

4.3.1 A Classe Dominio

Ao criar as classes do package Dominio, já são feitos os imports necessários

automaticamente

Figura 30 – Trecho do código da classe Cidade. Fonte: Acervo do autor

82

O trecho do código apresentado na figura anterior pode-se perceber o nome do

package onde a classe está inserida, que no caso é o domínio. Logo abaixo estão os imports,

principalmente os que tratam da persistência dos dados. Como já foi citado anteriormente,

quase todo o código em questão foi gerado automaticamente no processo de mapeamento das

tabelas do banco de dados.

Também fica explícito no código o nome da tabela da qual a classe foi gerada, que

no caso é a tabela CIDADE e os nomes das colunas. Outra coisa que chama a atenção é o fato

de na própria classe gerada já haver a informação se determinada coluna pode ser ou não nula,

e ainda, a cardinalidade da ligação entre as tabelas.

4.3.2 A Classe DAO

Para o desenvolvimento do protótipo foram criadas várias camadas, cada uma

com suas características e funcionalidades. As classes DAO foram criadas para a realização

da parte lógica do sistema, ou seja, é a camada que vai trabalhar com o banco de dados

relacional por meio do Hibernate.

Figura 31 – Parte do código da classe CidadeDao. Fonte: Acervo do autor

83

Na classe DAO (Data Access Object) são feitas operações como gravar e excluir

informações no sistema.

O DataAccessException trata-se de uma classe que trata das exceções que podem

ocorrer no sistema automaticamente, através do Spring, sem maiores complicações ao

programador. Para tanto é necessário o uso do annotation @Repository, pois é ele que indica

ao Spring que ele deve tratar dessas exceções.

4.3.3 A Classe FACADE

Para a utilização das facilidades do Spring, faz-se necessário a utilização de mais

uma camada na aplicação, que a princípio pereceu ser mais trabalhoso, mas no final da contas

compensou em muito. Essa camada, denominada FACADE é quem simplifica mais ainda o

acesso ao banco de dados e cria uma interface mais simples para trabalhar com as operações

criadas na classe Dao.

A figura a seguir mostra um trecho do código da classe CidadeFacade:

Figura 32 – Trecho do código da classe CidadeFacade.

Fonte: Acervo do autor

84

Nota-se que para trabalhar com as operações da classe Dao, é necessário que a

classe Facade tenha acesso direto ao Dao, sendo necessário os devidos imports.

Como já foi mencionada anteriormente, a utilização de annotations no sistema

facilita em muitos aspectos, um dos principais é a possibilidade de utilização do Spring para

controlar todas as classes do sistema sem a necessidade de utilização de vários arquivos

separados, ou seja, num só arquivo XML pode-se informar ao Spring as classes envolvidas e

como tratar todas. Um trecho do código do arquivo applicationContext.xml é apresentado a

seguir:

Figura 33 – Exemplo de código do arquivo XML. Fonte: Acervo do autor

4.3.4 A conexão com o banco de dados

Para que fosse possível a conexão com o banco de dados, foi necessária a

configuração de alguns parâmetros como o driver que está sendo utilizado, a url do banco,

usuário e senha. Essas informações ficam armazenadas no arquivo jdbc.properties, como

pode-se ver na figura a seguir:

Figura 34 – Configuração para acesso ao banco de dados. Fonte: Acervo do autor

Como se pode perceber, o banco está rodando no localhost, na porta 3306 e se

chama eobras, o usuário é root e não há senha definida para tal banco.

85

4.3.5 Os primeiros testes

O desenvolvimento do protótipo até essa etapa não possibilitou nenhum tipo de

teste para ver se realmente alguma coisa estava funcionando. Para que fosse possível realizar

esses testes, foram criadas classes especificas para tal fim. No caso do teste para a classe

CidadeFacade, foi construída justamente com o propósito de testar se o sistema estava

conseguindo de comunicar com o banco de dados e efetuando os procedimentos necessários.

Na figura a seguir está exposto um código para teste de inserção no banco de dados, mais

especificamente na tabela CIDADE.

Figura 35 – Teste de gravação. Fonte: Acervo do autor

4.4 AS CLASSES DA APLICAÇÃO WEB

Para a aplicação Web, foi criado um novo projeto, chamado eobras4.war. Assim

como na camada de negócios, eobras4.jar, foi necessário a importação das bibliotecas citadas

anteriormente, isso para a utilização das facilidades do Hibernate e do Spring. Vale ressaltar

que a aplicação Web é dependente das camadas da aplicação anteriormente desenvolvidas.

Também, como na camada da aplicação, usa-se o arquivo de configuração

applicationContext.xml. A parte da configuração do Spring não será foco deste trabalho, só

alguns detalhes importantes serão aqui expostos.

86

4.4.1 A Classe Provider

No sistema EObras, a classe CidadeProvider, por exemplo, é a classe que faz

ligação entre os componentes visuais do JSF com a aplicação, ou melhor, com os dados

contidos num banco de dados. Exemplificando, digamos que é essa classe que faz com que

um componente tabela mostre as informações na tela.

Para que o projeto web funcione, também é necessário um arquivo XML para a

configuração. Na verdade o referido arquivo é muito semelhante ao arquivo XML

desenvolvido para a aplicação de negócios, com todas as configurações padrão para chamar as

funcionalidades do Spring e a configuração individual de cada classe.

Outras configurações foram necessárias para o desenvolvimento do aplicativo,

porém estas não serão tratadas neste trabalho.

4.4.2 Criação de telas

Para a criação da parte visual do sistema o NetBeans oferece muitos recursos

interessantes. O layout das telas foi desenhado através dos componentes disponíveis no

próprio NetBeans, agilizando o processo.

Para que houvesse a facilidade da criação das telas assim como no Delphi ou

Visual Basic, foi utilizado um framework chamado JavaServer Faces ou simplesmente JSF.

No JSF há uma paleta com vários componentes que vão desde simples labels, edits até grids

para a visualização de dados.

Um exemplo bem simples de uma tela criada com o JSF está na figura que segue:

87

Figura 36 – Exemplo da utilização do JSF. Fonte: Acervo do autor

O exemplo anterior mostra uma tela simples com grid para mostrar as

informações contidas num banco de dados. Obviamente para que a tela se torne funcional é

necessário a integração com o Spring e a criação de métodos para os componentes façam

realmente algo.

Os exemplos que seguem, são imagens das telas de cadastro de cidade e

visualização dos dados cadastrados na tabela cidade. Vale ressaltar que as telas ainda não tem

uma interface gráfica muito atraente, porém já podem ser consideradas funcionais, pois são

bem simples de entendimento e atendem ao seu propósito.

88

Figura 37 – Tela de cadastro de cidades. Fonte: Acervo do autor

Figura 38 – Tela de exibição dos dados. Fonte: Acervo do autor

4.5 RELATÓRIOS

Durante o desenvolvimento do sistema se pensou qual a ferramenta ideal para a

criação de relatórios necessários, e optou-se pela utilização do iReport. A escolha foi

motivada pelo fato de ele se adequar perfeitamente as necessidades do sistema e ainda,

facilitar a vida do desenvolvedor e ainda gerar relatórios nos mais variados formatos de

arquivos.

89

Figura 39 – Relatório gerado. Fonte: Acervo do autor

90

4.6 A APLICAÇÃO PARA DISPOSITIVOS MÓVEIS

Para o desenvolvimento da aplicação para dispositivos móveis a escolha também

foi pela utilização do Java juntamente com o software de desenvolvimento NetBeans, que já

vem com suporte ao JME na versão 6.5 e em algumas anteriores.

Outras opções de desenvolvimento para o protótipo poderiam ter sido escolhidas,

a maioria delas mais simples de trabalhar e com mais recursos no que se refere a

implementação da parte gráfica do sistema, o SuperWaba seria uma dessas opções. Porém,

como a proposta original era estudar a linguagem de programação Java, esta foi a adotada,

apesar do grau de dificuldade que a mesma traz ao se implementar sistemas para dispositivos

como celulares e palmtops. Vale salientar que o protótipo do sistema móvel desenvolvido até

o momento se trata apenas de um software capaz de armazenar informações de modo

persistente em dispositivos móveis, mais especificamente de informações sobre cadastro de

funcionários, que no futuro será parte integrante de todo o sistema que girará em torno da

agenda.

A aplicação desenvolvida foi chamada de EObras_Mob_RMS, pois é um módulo

do sistema EObras, porém para dispositivos móveis e que armazena as informações através da

persistência dos dados utilizando RMS, como foi visto na fundamentação teórica.

Basicamente o sistema não foge muito do desenvolvimento de outros aplicativos

Java, onde primeiramente se faz os imports dos pacotes necessários ao funcionamento do

sistema e posteriormente cria-se a classe principal, onde estarão declaradas as variáveis do

sistema e implementados os métodos responsáveis por fazer o sistema funcionar.

91

Figura 40 – Trecho do fonte do protótipo para dispositivo móvel. Fonte: Acervo do autor

Para dar um pequeno entendimento ao código anteriormente exposto,

primeiramente deve-se saber do que trata cada biblioteca importada no início do fonte:

javax.microedition.midlet.MIDlet � todos os programas desenvolvidos em JME

devem importar essa classe que gerencia o ciclo de vida da aplicação, onde um MIDlet pode

ser encontrado no estado ativo, pausado ou destruído.

java.io � biblioteca que trata do controle dos dispositivos de entrada e saída do

sistema;

javax.microedition.rms � essa biblioteca é a responsável pela persistência dos

dados no dispositivo móvel. Não é comparado como um banco de dados obviamente, mas

sem ela os dados não ficariam gravados no dispositivo;

javax.microedition.lcdui � trata dos recursos gráficos do sistema;

java.util.Vector � o nome já diz tudo, essa biblioteca permite a utilização de

vetores no sistema.

A partir do conhecimento das bibliotecas envolvidas na criação do sistema

EObras_Mobile_RMS fica mais fácil de se entender o que foi implementado. Mas para ficar

mais simples de se entender, o comentário será bem superficial, não entrando muito nos

detalhes técnicos envolvidos.

92

No início foi criada a classe principal do protótipo, chamada de Obras_Mid.

Essa classe se estende da biblioteca MIDlet, que já foi mencionada anteriormente. Após a

declaração da classe está o construtor da mesma, que carregará a classe mencionada. Nesse

construtor são configurados uma série de parâmetros do sistema, bem como de alguns

componentes.

Após essas configurações do construtor da classe, são implementados métodos e

outras classes para que o sistema funcione como os métodos de listar registros, excluir

registros e adicionar registros.

Como já foi mencionado, o protótipo visa a criar uma agenda com algumas

informações, que no momento são informações dos funcionários da prefeitura. Muito embora

os sistema não conte ainda com uma interface gráfica atraente, é simples de se trabalhar,

como pode-se perceber na figura a seguir, onde estão sendo listados os registros contidos no

recordstore.

Figura 41 – Tela do sistema móvel Fonte: Acervo do autor

93

Na figura anterior fica visível a funcionalidade de exibir as informações na tela do

dispositivo móvel, lembrando que este pode ser desde um celular ou ainda um smartphone,

embora que cada um destes, irá exibir as informações ou mesmo os componentes de maneira

diferente. Caso haja a intenção de implantar o protótipo em um dispositivo Palm, é necessário

a conversão dos arquivos .jar e .jad em um arquivo .prc, que como foi citado na

fundamentação teórica, é o arquivo dos programas para o sistema operacional Palm OS.

94

5 CONCLUSÕES E RECOMENDAÇÕES

Os avanços tecnológicos proporcionam a praticamente todos os setores grandes

desenvolvimentos, proporcionando comodidades e facilidades até ontem inimagináveis. As

prefeituras municipais podem e devem fazer uso dessas tecnologias para um melhor

planejamento e apresentar resultados aos cidadãos de forma clara e concisa.

O presente Trabalho de Conclusão de Curso procurou demonstrar a importância

da criação de um sistema para o gerenciamento de secretarias de obras teria para as

prefeituras. Também procurou abordar o desenvolvimento deste protótipo, utilizando para

isso, a linguagem de programação Java, mundialmente conhecida pela suas características

como a de ser gratuita, multiplataforma, orientada a objetos e robusta, embora seja uma

linguagem relativamente complexa.

A utilização dessa linguagem de programação para o desenvolvimento do sistema

é muito promissora, pois além das características anteriormente citadas, existem várias

ferramentas para o auxílio do desenvolvedor. São justamente essas ferramentas que vem

socorrer os novatos dessa linguagem. No caso do desenvolvimento do protótipo EObras,

desenvolvido com o auxílio do NetBeans, Hibernate e Spring notou-se o quão importante são

ferramentas como essas para facilitar e agilizar os processos e diminuir o grau de dificuldade

que o Java proporciona aos iniciantes. Outro fator que há de se considerar é o fato de que

numa mesma IDE, o NetBeans, foi possível tanto o desenvolvimento do protótipo Web

quanto o sistema para dispositivos móveis.

Ao longo do desenvolvimento do Trabalho de Conclusão de Curso foram

encontradas muitas dificuldades, tanto na parte teórica, por se tratar de um assunto muito

amplo, quanto na implementação do protótipo. No desenvolvimento do sistema vale citar as

dificuldades em encontrar disponíveis na internet os pacotes corretos com as bibliotecas a

serem adicionadas ao NetBeans e pelo fato do protótipo ser constituído de várias camadas, o

que de certa forma dificultou o desenvolvimento, ainda mais se for levado em consideração o

pouco tempo para estudar sobre o assunto e tecnologias abordadas e desenvolver o protótipo.

Outra grande dificuldade encontrada foi sem dúvidas trabalhar com o paradigma da

orientação a objetos, que sai completamente da rotina de quem está acostumado com

programação estruturada.

95

Dos objetivos iniciais do projeto, praticamente todos foram alcançados, uma vez

que foi desenvolvido grande parte do sistema Web, utilizando o Java em conjunto com o

SGBD MySQL, a criação de relatórios e ainda, o desenvolvimento do protótipo para

dispositivos móveis, utilizando também a linguagem de programação Java, o que possibilita a

portabilidade do sistema para as mais variadas plataformas como Palm, celulares,

SmarthPhones entre outros. Apesar de todos os problemas encontrados, há de se considerar a

importância do estudo e contato com novas tecnologias, o que por si só já é muito

compensador.

Por fim se pode concluir que o desenvolvimento do protótipo seria impossível

se não fosse uma boa fundamentação teórica, pois foi essa fundamentação que serviu de

alicerce para a construção de algo maior, ou seja, o protótipo em si.

Como propostas para trabalhos futuros deixa-se as idéias de prosseguir no

desenvolvimento dos sistemas, tanto Web como o móvel, a criação de um conduit para a

sincronização das informações do Palm com as do banco de dados do sistema principal e a

implementação de auditoria do sistema Web.

96

REFERÊNCIAS

AGUIAR, Ivan Aune de. Serviço de Inspeção Federal: Nível de satisfação do cliente. 2004. 105 f. Dissertação (Mestrado em Engenharia de Produção) – Programa de Pós-graduação em Engenharia de Produção, Universidade Federal de Santa Catarina, Florianópolis. Disponível em: < http://teses.eps.ufsc.br/defesa/pdf/11501.pdf>. Acesso em: 05 de jun. 2008. ALEXANDRONI, Marcio. Entenda o Formato PDB (Palm Database). 2001. Disponível em: <http://www.clubedainformatica.com.br/documentos/mostraartigo.php?artigo=47>. Acesso em: 12 de mai. 2008. ALUR, Deepak; CRUPI, John; MALKS, Dan. Core J2EE patterns. Rio de Janeiro: Campus, c2004. 587 p. ALVES, Willian Pereira. Palm OS e Windows CE: desenvolvimento de aplicações. São Paulo: Érica, 2002. 252 p. BEZERRA, Eduardo. Princípios de análise e projetos de sistemas com UML. Rio de Janeiro: Campus, 2002. 286 p. BLUMENAU, Prefeitura Municipal. SEOSUR - Secretaria Municipal Obras e Serviços Urbanos. Disponível em: <http://www.blumenau.sc.gov.br/novo/site/conteudo/ index.php?IDSECAO=330&IDPAI=154>. Acesso em: 05 de jun. 2008. BOOCH, Grady. UML: guia do usuário. Rio de Janeiro: Campus, 2000. 472 p BORGES, Jeff. Programando para Palm OS com VB e AppForge. Rio de Janeiro: Ciência Moderna, c2002. 112 p. DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Campus, 2003. 864 p. FOWLER, Martin. UML essencial: um breve guia para a linguagem-padrão de modelagem de objetos. 2. ed. Porto Alegre: Bookman, 2000. 169 p GARCIA-MOLINA, Hector. Implementação de sistemas de bancos de dados. Rio de Janeiro: Campus, 2001. 685 p. GIAMBIAGI, Fabio; ALÉM, Ana Cláudia. Finanças públicas: teoria e prática no Brasil. 2. ed. rev. e atual. Rio de Janeiro: Elsevier, c2001. 475 p. GOMES, Yuri Marx P. Java na Web com JSF, Spring, Hibernate e Netbeans 6. Rio de Janeiro: Editora Ciência Moderna Ltda., 2008. GONÇALVES, Edson. Desenvolvendo Aplicações Web com NetBeans IDE 6. Rio de Janeiro: Editora Ciência Moderna Ltda., 2008.

97

HIBERNATE, site oficial da empresa. Disponível em: < http://www.hibernate.org/>. Acesso em: 08 de nov. 2008. INSTITUTO BRASILEIRO DE ADMINISTRAÇÃO MUNICIPAL – IBAM. A Câmara Municipal. Disponível em: <http://www.ibam.org.br/publique/cgi/cgilua.exe/sys/ start.htm?sid=13&infoid=242>. Acesso em: 04 de jun. 2008. ______. O Prefeito como Chefe do Executivo Municipal. Disponível em: <http://www.ibam.org.br/publique/ cgi/cgilua.exe/sys/start.htm?sid=13&infoid=241>. Acesso em: 04 de jun. 2008. ______. Receitas Municipais. Disponível em: <http://www.ibam.org.br/publique/cgi/ cgilua.exe/sys/start.htm?sid=13&infoid=244>. Acesso em: 04 de jun. 2008. JANDL JUNIOR, Peter. Java: guia do programador. São Paulo: Novatec Editora, 2007. JASPERFORGE.ORG, site oficial da empresa. IReportManualV1.2.1 Wiki. Disponível em: <http://jasperforge.org/plugins/mwiki/index.php/IReportManualV1.2.1>. Acesso em: 28 de set. 2008. JOHNSON, Thienne M. Java para dispositivos móveis: desenvolvendo aplicações com J2ME. São Paulo: Novatec Editora, 2007. LAUDON, Kenneth C.. Sistemas de informação gerenciais: administrando a empresa digital. 5. ed. São Paulo: Pearson Prentice Hall, 2006. 562 p. MARCONDES, Christian Alfim. Programando em HTML 4.0. 6. ed. São Paulo: Érica, 2001. 272 p. MECENAS, Ivan. Java 2: fundamentos, Swing e JDBC. Rio de Janeiro: Alta Books, c2003. 378 p. MUCHOW, John W. Core J2ME: Tecnologia & MIDP. São Paulo : Pearson Makron Books, 2004. MYSQL, Download Connector/J 5.1. Disponível em: <http://dev.mysql.com/downloads/ connector/j/5.1.html>. Acesso em: 08 de nov. 2008. MYSQL AB, A Empresa. 2008. Disponível em: <http://www.mysqlbrasil.com.br/ ?q=node/1>. Acesso em: 02 de mai. 2008. NEIMEYER, Patrick. Aprendendo Java 2 SDK - Versão 1.3. Rio de Janeiro: Campus, 2000. 700 p. NIEDERAUER, Julino. Integrando PHP 5 com MySQL: Guia de Consulta Rápida. São Paulo: Novatec Editora, 2005.

98

OLIVEIRA, Ricardo José de. MS-SQL Server 7.0: dominando seus dados. São Paulo: Érica, 1999. 344 p. RIO DO SUL, Prefeitura Municipal. Estrutura administrativa: Secretaria de Obras e Serviços Urbanos. Disponível em: <http://www.riodosul.sc.gov.br/portal/ principal.php?pg=1272>. Acesso em: 05 de jun. 2008. RIO DO SUL. Prefeitura Municipal. Lei Complementar n. 100, de 24 abril de 2003. Dispõe sobre a estrutura administrativa do poder executivo do município de Rio do Sul e dá outras providências. Disponível em: <http://www.legislacaomunicipal.com.br/php/redacoes/ 83102574000106/Lei04453.doc>. Acesso em: 05 de jun. 2008. SANTOS, Rafael. Introdução à Programação Orientada a Objetos usando Java. Rio de Janeiro: Campus, 2003. SIERRA, Kathy; BATES, Bert. Use a cabeça !: java. Rio de Janeiro: Alta Books, c2005. 470 p. SOARES, Walace. Crie um site B2C: com PHP 4 e MySQL. São Paulo: Érica, 2001. 608 p. ______. MySQL: conceitos e aplicações. São Paulo: Érica, 2001. 294 p. SPRING, site oficial da empresa. Spring Downloads. Disponível em: < http://www.springsource.org/download >. Acesso em: 08 de nov. 2008. SQL POWER, site oficial da empresa. Disponível em:< http://www.sqlpower.ca/page/architect>. Acesso em: 28 de set. 2008. SUBMARINO, site de compras da empresa Submarino. Disponível em: < http://www.submarino.com.br/>. Acesso em: 05 de jun. 2008. SUPERWABA, site oficial da empresa. Disponível em: < http://www.superwaba.com.br/>. Acesso em: 28 de set. 2008. TANENBAUM, Andrew S.. Redes de computadores. Rio de Janeiro: Campus, 1997. 923 p. VERÍSSIMO, Dijonilson Paulo Amaral. Administração Municipal: Prefeito e Prefeitura. 2001. Disponível em: <http://www.escritorioonline.com/webnews/noticia.php?id_noticia= 1809&>. Acesso em: 30 de mai. 2008. WAZLAWICK, Raul Sidnei. Análise e projeto de sistemas de informação orientados a obejtos. Rio de Janeiro: Elsevier, c2004. 298 p. YOURDON, Edward. Análise e projeto orientados a objetos: estudos de casos. São Paulo: Makron Books, 1999. 328 p.

99

ANEXO I – ORGANOGRAMA HIERÁRQUICO GERAL DO MUNICÍPIO DE

RIO DO SUL

100

ANEXO II – ORGANOGRAMA HIERÁRQUICO DA SECRETARIA DE OBRAS DO

MUNICÍPIO DE RIO DO SUL

E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias Municipais de Obras...

Software

Transcript of E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias Municipais de Obras...