TCC E-Obras

Prévia do material em texto

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 
 
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 
 
 
 
 
 
 
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 
 
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 
 
 
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ÚBLICAPode-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 propriamentedita 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 facilitaa 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. 
 
 
Coma 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 orientadaa 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,