FACULDADES COC
BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO
Diego Antonio Sales
SISTEMA DE APONTAMENTOS MÓVEL PARA CONTROLE DE
PRODUÇÃO DE BOMBAS DE CONCRETO
Orientador: Prof. Reginaldo Aparecido Gotardo
Ribeirão Preto
2009
Diego Antonio Sales
SISTEMA DE APONTAMENTOS MÓVEL PARA CONTROLE DE
PRODUÇÃO DE BOMBAS DE CONCRETO
Trabalho de conclusão de curso
apresentado às Faculdades COC
de Ribeirão Preto, sob orientação
do Prof. Ms. Reginaldo Aparecido
Gotardo, para obtenção do grau
de Bacharel em Engenharia da
Computação.
Ribeirão Preto
2009
ii
AGRADECIMENTO
Agradeço aos meus pais por terem confiado em mim e por terem me
dado a oportunidade de cursar engenharia.
À minha esposa, Dayane, por ter sido paciente e compreensiva quando
precisei me dedicar incontáveis horas, dias, semanas a este trabalho.
Aos meus colegas de trabalho da Leão Engenharia, em especial ao
Marcos Vinícius, pela idéia do tema e a oportunidade de trabalhar em um
projeto que serviria ao mesmo tempo como trabalho de conclusão de curso e
como uma solução inovadora para a empresa.
Ao meu orientador Reginaldo pelo direcionamento e esclarecimentos no
decorrer do trabalho.
Ao professor Paulo César pelas idéias por estar sempre disposto a
ajudar quando precisei.
Aos meus colegas da faculdade, pela descontração, que muitas vezes
foi fundamental.
À minha cadelinha Flor, que sempre me animou nos momentos difíceis,
com sua alegria contagiante.
iii
LISTA DE FIGURAS
Figura 1. Foto de betoneira da Leão Engenharia...................................................... 4
Figura 2. Foto de um caminhão-bomba .................................................................... 5
Figura 3. Configuracoes e perfis ............................................................................... 9
Figura 4.Ciclo de vida de uma aplicação MIDP....................................................... 10
Figura 5. Tela apresentada pelo aplicativo Exemplo .............................................. 11
Figura 6. Hierarquia de classes do MIDP ................................................................ 12
Figura 7. Tela com comando .................................................................................... 14
Figura 8. Lista ........................................................................................................... 15
Figura 9. Textbox ...................................................................................................... 16
Figura 10. Form com StringItem, ChoiceGroup e TextField................................... 18
Figura 11. Form com um Gauge, DateField e ImageItem ....................................... 19
Figura 12. Esquema de funcionamento do framework Floggy .............................. 24
Figura 13.Formulário ................................................................................................ 30
Figura 14. Conteúdo de recebe.php ........................................................................ 30
Figura 15. Tabela pessoas sendo visualizada no banco de dados ....................... 31
Figura 16. Exibição da página exibe.php ................................................................ 32
Figura 17. Exemplo de XML bem formado .............................................................. 35
Figura 18. Tabela pessoa no banco de dados ........................................................ 38
Figura 19. Tabela salario no banco de dados ......................................................... 38
Figura 20. Resultado do select do exemplo ............................................................ 39
Figura 21. Estados e eventos ................................................................................... 42
Figura 22. Tela informativa ....................................................................................... 42
Figura 23. Menu do administrador........................................................................... 43
Figura 24. Menu de escolha de parâmetros “sim” e ”não”.................................... 43
Figura 25. Tela de entrada de telefone .................................................................... 44
Figura 26. Aviso de recebimento de dados............................................................. 44
Figura 27. Lista de bombistas .................................................................................. 45
Figura 28. Lista de prefixos...................................................................................... 45
Figura 29. Lista de eventos registrados .................................................................. 46
Figura 30. Tela de identificação ............................................................................... 46
Figura 31. Lista do estado “na empresa” ................................................................ 47
Figura 32. Lista do estado “em deslocamento”...................................................... 47
Figura 33. Lista do estado “na obra”....................................................................... 47
Figura 34. Lista do estado “bombeando” ............................................................... 47
Figura 35. Lista de ocorrências ............................................................................... 47
iv
Figura 36. Tela de entrada de m³ ............................................................................. 48
Figura 37. Tela de entrada de KM ............................................................................ 48
Figura 38. Tela de entrada de N.F. ........................................................................... 48
Figura 39. Tela de entrada de contrato.................................................................... 48
Figura 40. Confirmação ............................................................................................ 49
Figura 41. Confirmação ............................................................................................ 49
Figura 42. Resultados............................................................................................... 55
v
LISTA DE ABREVIATURAS
AMS – Application Management Software
API – Application Program Interface
CDC – Connected Device Configuration
CLDC – Connected Limited Device Configuration
DDL – Dada Definition language
DML – Data Manilulation language
HTML – Hypertext Markup Language
HTTP – Hypertext transfer protocol
JEE – Java Enterprise Edition
JME – Java Micro Edition
JSE – Java Standard Edition
MIDP – Mobile Information Device Profile
PHP – Hypertext Preprocessor
RMS – Record Management System
SGBD – Sistema Gerenciador de Banco de Dados
XML – Extensible Markup Language
W3C – World Wide Web Consortium
vi
RESUMO
O trabalho consiste em um sistema para automatizar processos de
coleta de dados em campo. Ele é composto por um módulo executado no
telefone celular, desenvolvido em JME e outro módulo executado em um
servidor web, desenvolvido em PHP. A persistência de dados no servidor é
feita em banco de dados MySQL e no telefone celular em RMS. Com a
implantação desse sistema é esperada maior agilidade e fidelidade dos dados
coletados em campo já que estes em geral são feitos em papel e demoram
horas ou mesmo dias para chegarem ao seu destino. Neste sistema, a
transmissão dos dados é feita via internet pelo protocolo HTTP e no formato
XML, garantindo assim a velocidade e a consistência da informação. Se existir
conectividade com a internet os dados chegam ao servidor em menos de um
minuto. Caso contrário os dados permanecem gravados na memória
persistente do celular até que o usuário entre em uma área com cobertura de
internet móvel. Os dados podem transitar nos dois sentidos, tanto do servidor
para o telefone celular (download de listas de pessoas, equipamentos, tarefas,
itinerário etc.) como do telefone celular para o servidor (apontamentos de hora,
litros, produtos entregues, pesquisas de opinião etc.). No módulo web é
possível visualizar relatórios com indicativos de desempenho, consumo,
produtividade, entre outros, que podem ser utilizados como critério para
tomada de decisões.
vii
ABSTRACT
This work consists of a system to automate processes for data collection
in the field. It consists of a module running on the mobile phone, developed in
JME and another module that runs on a web server, developed in PHP. The
persistence on the server is made by MySQL database and in the mobile phone
by RMS. By implementing this system is expected greater speed and reliability
of data collected in the field as they are usually made of paper and take hours
or even days to reach their destination. In this system, data transmission is
made via the Internet HTTP protocol and XML, ensuring speed and consistency
of information. If there is connectivity to the Internet, data arrives at the server in
less than a minute. Otherwise the data remains stored in the persistent memory
of the phone until the user enters an area covered by mobile internet. The data
can traffic in both directions, from the server to the cellular phone (download
lists of people, equipment, tasks, route etc.). And from phone to the server
(notes of hours, liters, products delivered, polls etc..). In the web module reports
are available with indicatives of performance, consumption, productivity, among
others, that can be used as criteria for decision making.
viii
SUMÁRIO
INTRODUÇÃO ................................................................................... 1
CAPÍTULO 1. COLETA DE DADOS EM CAMPO ........................... 4
1.1 Bombeamento de concreto .................................................................................. 4
1.2 Apontamentos Manuais........................................................................................ 6
CAPÍTULO 2. JAVA MICRO EDITION ............................................. 7
2.1 Principais plataformas Java ................................................................................. 7
2.2 Configurações ....................................................................................................... 8
2.2.1 CDC ................................................................................................................. 8
2.2.2 CLDC ............................................................................................................... 8
2.3 Perfis...................................................................................................................... 8
2.4 Ciclo de vida de um programa JME/MIDP ........................................................... 9
2.5 Exemplo de um programa em JME/MIDP .......................................................... 10
2.6 Interface com o usuário...................................................................................... 11
2.7 Command ............................................................................................................ 12
2.8 Screen.................................................................................................................. 14
2.8.1 List ................................................................................................................. 14
2.8.2 TextBox .......................................................................................................... 15
2.8.3 Alert ............................................................................................................... 16
2.8.4 Form e seus itens........................................................................................... 16
2.9 Persistência de dados ........................................................................................ 19
2.10 Framework de persistência Floggy ................................................................. 22
CAPÍTULO 3. PHP .......................................................................... 28
3.1 Processamento server side................................................................................ 28
3.2 Trabalhando com formulários HTML ................................................................. 29
3.3 Acesso a bancos de dados ................................................................................ 31
CAPÍTULO 4. OUTRAS TECNOLOGIAS UTILIZADAS ................ 34
CAPÍTULO 4. OUTRAS TECNOLOGIAS UTILIZADAS ................ 34
4.1 XML ...................................................................................................................... 34
4.1.1 XML bem formados ........................................................................................ 34
4.2 SQL ...................................................................................................................... 36
4.2.1 DDL................................................................................................................ 36
4.2.2 DML ............................................................................................................... 37
CAPÍTULO 5. SISTEMA DE APONTAMENTOS MÓVEL ............. 40
5.1 Módulo celular..................................................................................................... 40
5.1.1 Eventos .......................................................................................................... 40
5.1.2 Ocorrências.................................................................................................... 41
5.1.3 Estados .......................................................................................................... 41
5.1.4 Opções do administrador ............................................................................... 42
ix
5.1.5 Operaçao do programa .................................................................................. 46
5.1.6 Telas de entrada de dados............................................................................. 48
5.1.7 Telas de confirmação ..................................................................................... 48
5.2 Módulo web ......................................................................................................... 49
CAPÍTULO 6. CONCLUSÃO .......................................................... 56
REFERÊNCIAS BIBLIOGRÁFICAS ............................................... 58
BIBLIOGRAFIA ............................................................................... 59
x
INTRODUÇÃO
A necessidade da intervenção humana nos processos de aquisição e
transmissão de informações é um fator prejudicial quando se tem por objetivo a
velocidade e a consistência dos dados.
Todo processo manual está sujeito às limitações do ser humano. As
limitações
principais
são a propensão a erros
e
a velocidade
de
“processamento”.
Um exemplo de processo manual está no apontamento realizado em
campo por funcionários de uma empresa. Normalmente esse processo é feito
manualmente com o uso de prancheta, papel e caneta. Os apontamentos
podem ser de diversos tipos: coleta de ponto de funcionários, registro de
horário de inicio e fim de atividades de máquinas, quantidade de mercadoria
entregue em determinado local para determinado cliente entre outros.
Nesse exemplo existem claramente dois pontos onde podem ocorrer
erros. Um está no funcionário que faz os apontamentos, muitas vezes munido
de notas fiscais, formulários e relógio. Outro está no funcionário que pega a
planilha e passa a informação para o formato de planilha eletrônica a fim de
gerar relatórios com gráficos e informações gerenciais. Sem contar que desde
o momento do apontamento até a geração do relatório podem se passar várias
horas ou até dias.
Um sistema que automatizasse esses apontamentos, diminuindo ao
máximo a intervenção humana aperfeiçoaria esse processo com grandes
ganhos para os funcionários e gerentes.
Foram
analisadas
as
possíveis
soluções
que
pudessem
ser
implementadas em um sistema:
 Sistema que roda em dispositivo móvel e grava os dados localmente.
Estes são posteriormente descarregados em um computador que então
faz o processamento dos dados. Sistemas como esse são comuns no
mercado e são utilizados por diversas empresas.
Prós: diminui a intervenção humana.
1
Contras: não resolve o problema da velocidade, pois é necessário
descarregar os dados posteriormente.
 Sistema web que pode ser acessado de qualquer lugar. Os
apontamentos são instantaneamente transmitidos e a compatibilidade é
total.
Prós: diminui a intervenção humana e torna a transmissão de
dados muito rápida.
Contras: em um local onde não exista cobertura de internet móvel
ou no caso da falha na transmissão, o sistema fica inoperante.
 Sistema que roda nos dispositivos móveis com acesso à internet e
possibilidade dos dados serem persistidos em memória não volátil.
Prós: diminui a intervenção humana, torna a transmissão de
dados rápida e não é dependente de cobertura de internet. O sistema
pode então gravar os dados e tentar transmiti-los. Caso exista
conectividade, o processo está encerrado, caso não exista o sistema
aguarda outra oportunidade para transmitir.
Claramente a terceira solução é a mais interessante.
Este trabalho tem como objetivo o estudo dos requisitos e das
tecnologias disponíveis para desenvolvimento desse sistema, assim como um
estudo de caso aplicado em uma empresa real.
No capítulo 1 é apresentado como é feito hoje em dia o controle de
produção de bombas de concreto.
No capítulo 2 é apresentado um estudo sobre a linguagem Java,
especificamente a JME, que é uma versão resumida e limitada do Java para
dispositivos com restrições de processamento e memória.
2
No capítulo 3 é apresentada a linguagem PHP, que é a linguagem mais
usada atualmente para o desenvolvimento de páginas web dinâmicas e com
acesso a banco de dados.
No capitulo 4 são apresentadas outras tecnologias que foram
necessárias para o desenvolvimento do sistema, o XML, linguagem padrão no
intercambio de informações entre sistemas diferentes e o SQL, linguagem
padrão para envio de comandos a sistemas gerenciadores de banco de dados.
No capítulo 5 é apresentado o sistema desenvolvido, tanto o módulo
celular como o módulo web.
3
CAPÍTULO 1. COLETA DE DADOS EM CAMPO
Esse trabalho foi desenvolvido para automatizar processos de coleta de
dados em campo para empresas. Especificamente será aplicado para dar
maior eficiência no controle de produção do serviço de bombeamento de
concreto de uma empresa de engenharia de Ribeirão Preto.
1.1 Bombeamento de concreto
O serviço de bombeamento de concreto consiste em transportar
concreto pronto para ser aplicado do nível do solo até o local da sua aplicação.
O concreto é trazido em caminhões chamados de betoneiras e é despejado em
um compartimento especial de outro caminhão, chamado de caminhão-bomba.
Este último é equipado com uma bomba movida por um motor à combustão. A
bomba pode ser movimentada por um motor dedicado ou pelo mesmo motor
usado pelo caminhão para se locomover, dependendo do fabricante e modelo.
Fotos desses caminhões estão ilustradas nas figuras 1 e 2.
Figura 1. Foto de betoneira da Leão Engenharia
4
Figura 2. Foto de um caminhão-bomba
O funcionário responsável pelo bombeamento e pelo caminhão-bomba é
chamado de bombista. Normalmente ele chega à obra antes do concreto e
junto com um auxiliar, prepara a bomba e mangueiras para a chegada do
mesmo.
Ao longo de um dia de trabalho as betoneiras vão chegando uma após a
outra e o concreto vai sendo bombeado para formar a parte sólida de
construções em locais de difícil acesso, como lajes, shoppings, pontes ou
construções de maior porte como centrais hidrelétricas e estações de
tratamento de água e esgoto.
Quando todo o concreto foi bombeado, o bombista e seu auxiliar são
responsáveis por fazer a limpeza das mangueiras e preparar o caminhão para
o translado até a empresa ou para outra obra.
5
1.2 Apontamentos Manuais
O bombista sempre leva consigo uma prancheta com papel e caneta.
Equipado disso e de um relógio ele é responsável por anotar informações
sobre o andamento do trabalho no decorrer do dia. As informações são
registradas nos seguintes momentos: ao sair da empresa, ao chegar à obra, ao
iniciar o bombeamento, ao término do bombeamento, na saída da obra e na
chegada à empresa.
A planilha usada para fazer esses apontamentos hoje em dia está
disponível no final deste trabalho, no anexo I.
As informações registradas são as seguintes: quilometragem do
caminhão, hora do evento, contrato ou nota fiscal bombeada, quantidade
bombeada e prefixo do caminhão-bomba utilizado.
Todas essas informações chegam posteriormente aos escritórios da
empresa, onde funcionários da área administrativa digitam-nas em planilhas
eletrônicas. A partir dessas planilhas são gerados relatórios e indicadores que
são utilizados pelo gestor da área para acompanhamento do trabalho de seus
equipamentos e funcionários. Com base nesses indicadores ele toma atitudes
que vão contribuir para melhorar a eficiência e a qualidade do serviço de
bombeamento de concreto.
6
CAPÍTULO 2. JAVA MICRO EDITION
Segundo pesquisa realizada pela Tiobe Software1, o Java é a linguagem
de programação mais popular do mundo. Sua popularidade se dá devido às
vantagens que a linguagem oferece. Os pontos fortes do Java, segundo Yuan
são:
 Portabilidade: O desenvolvedor Java não precisa se preocupar em qual
sistema sua aplicação vai ser executada. Uma vez desenvolvida, a
aplicação funcionará em qualquer sistema que suporte o Java.
 Robustez: O bytecode é verificado antes da execução e o coletor de lixo
trata de recuperar a memória. Mesmo que aconteça uma falha, ela se
restringe à máquina virtual, não interferindo no funcionamento e nos
dados do sistema.
 Segurança: O ambiente de execução Java fornece avançados recursos
de segurança baseados em sua API de gerenciamento padronizada.
 Orientação a objeto: A linguagem Java é bem estruturada, baseada em
classes e objetos e oferece suporte às mais diversas aplicações, com
uma vasta biblioteca e comunidade de desenvolvedores ativos.
 Ampla aceitação e suporte: É relativamente fácil fazer clientes Java
trabalharem com servidores de aplicação Java. Devido à ampla adoção
do J2EE em servidores, o Java móvel é o candidato líder na disputa pelo
mercado dos front-ends.
2.1 Principais plataformas Java
Embora a portabilidade entre sistemas seja um dos conceitos principais
do Java, os desenvolvedores perceberam que mesmo a portabilidade tem
limites. Essa portabilidade só é válida para sistemas operacionais e hardwares
similares. Hoje em dia a plataforma Java é dividida em três diferentes edições,
cada uma delas com características próprias: Java Standard Edition(JSE),
destinada à computadores desktop, Java Enterprise Edition(JEE), destinada a
1
Disponível em http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html, acessado em
01/11/2009
7
servidores e Java Micro Edition(JME), destinada à dispositivos com limitações
de processamento e memória. (YUAN, 2002).
2.2 Configurações
O JME é suportado por diversos dispositivos móveis. Como esses
dispositivos têm diferenças e semelhanças em sua arquitetura e finalidade,
seus
desenvolvedores
dividiram-no
em
dois
grupos,
chamados
de
configurações. Dessa forma foi possível manter certo nível de portabilidade
entre
dispositivos
semelhantes.
As
configurações
disponíveis
são
a
CDC(Connected Device Configuration) e a CLDC(Connected Limited Device
Configuration). (ROSSATO; LUGON 2005)
2.2.1 CDC
Connected Device Configuration é a configuração de dispositivos de
maior poder computacional, como PDA’s, comunicadores sem fio, Internet TV’s
e sistemas de navegação automotivo. Essa configuração implementa
completamente
a
máquina
virtual
Java,
com
pequenas
diferenças,
especialmente no que se refere às limitações dos dispositivos. Essa máquina
virtual é chamada de CVM(Compact Virtual Machine).
2.2.2 CLDC
Connected Limited Device Configuration é a configuração de dispositivos
mais simples como telefones celulares e organizadores pessoais. Ela
implementa uma versão limitada da máquina virtual Java chamada de KVM –
Kilobyte Virtual Machine, chamada assim porque a memória de trabalho
disponível não chega a um Megabyte.
2.3 Perfis
As configurações definem o núcleo do ambiente de execução JME, mas
não tem suporte as características mais específicas dos dispositivos. Essa
função fica a cargo dos perfis. Perfis fornecem API’s de suporte que definem
um ciclo de vida, apresentação(interface com o usuário), persistência de dados
e conectividade à rede aos programas JME. Cada perfil é característico de um
8
tipo de dispositivo. A figura a seguir mostra um esquemático da arquitetura
JME, com suas configurações, perfis e dispositivos alvo.
Figura 3. Configurações e perfis2
Para telefones celulares, o perfil predominante disponível é o MIDP
(Mobile Information Device Profile). Ele implementa uma forma padrão de ter
acesso à tela e aos botões do dispositivo, um mecanismo de persistência e
uma forma de acesso à rede. Aplicações desenvolvidas para esse perfil são
chamadas de Midlets. (ROSSATO; LUGON 2005)
2.4 Ciclo de vida de um programa JME/MIDP
Um midlet segue um ciclo especial de vida, como um applet. Após a
execução do construtor, um método especial chamado startApp() é chamado. A
figura a seguir ilustra quais são os estados e quais são os eventos que os
alteram.
2
Disponível em http://www.devmedia.com.br/imagens/javamagazine/desjj2mep1fig01.JPG,
acessado em 02/11/2009
9
3
Figura 4. Ciclo de vida de uma aplicação MIDP
Após a execução do construtor, a aplicação entra no estado paused e
então é iniciada pelo AMS ao chamar o método startApp(), indo para o estado
active. Se o programa precisar ser interrompido, ele vai para o estado paused.
Ele pode ir para esse estado se a aplicação precisar ser interrompida, como
por exemplo ao receber uma ligação, ou se o programa chamar explicitamente
o método pauseApp(). Para retornar ao estado active, o método startApp() é
chamado novamente e o programa permanece nesse ciclo até que seja
chamado o método destroyApp(), que pode ser chamado pela aplicação
explicitamente quando o usuário notifica que quer sair do programa ou pelo
próprio AMS quando o usuário finaliza a aplicação pelo menu do
celular.(FRANÇA, 2005)
2.5 Exemplo de um programa em JME/MIDP
O código a seguir é um dos exemplos mais simples que se pode ter de
um programa em JME. Ao ser executado, o programa apresenta a tela ilustrada
pela figura x.
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class Exemplo extends MIDlet{
public Display display;
3
Disponível em http://www.devmedia.com.br/images/articles/178782/3.gif, acessado em
01/11/2009
10
public Alert alerta;
public void startApp(){
display = Display.getDisplay(this);
alerta = new Alert("Exemplo", "Exemplo de programa em
JME",
null, AlertType.ALARM);
display.setCurrent(alerta);
}
public void pauseApp(){ }
public void destroyApp(boolean unconditional){ }
}
Figura 5. Tela apresentada pelo aplicativo Exemplo
2.6 Interface com o usuário
Como aplicações feitas em JME podem rodar em qualquer dispositivo
que tenha a máquina virtual Java e como em cada um deles pode ter
características diferentes de tamanho da tela, quantidade de cores, disposição
dos botões entre outras, foi disponibilizada a classe Display. Essa classe
abstrata tem um método que retorna uma referencia que pode ser usada dentro
do programa para ter acesso à tela do dispositivo. O acesso é obtido a partir do
método Display.getDisplay(Midlet midlet). Tipicamente é usada na classe
principal do programa que herda de Midlet da seguinte forma forma:
Display display;
display = Display.getDisplay(this);
11
Posteriormente o programa pode alternar o Displayable sendo exibido no
momento por uma chamada do método display.setCurrent(Displayable
displayable).(FRANÇA, 2005)
Os Displayables podem ser de dois tipos: do tipo Screen e do tipo
Canvas. Canvas é uma API gráfica de baixo nível que pode ser usada para
representar qualquer coisa na tela, necessitando para isso ser desenhada com
o objeto implícito Graphics g. Geralmente é usada para desenvolvimento de
jogos ou aplicações que necessitem de uma maior liberdade na forma dos itens
apresentados na tela. Screen é uma API de alto nível, e nela são utilizados
componentes prontos, como Alert, TextBox, List e Form.
A figura a seguir mostra uma representação hierarquica das classes
citadas:
Figura 6. Hierarquia de classes do MIDP4
2.7 Command
Para executar ações no programa, o usuário se utilizará dos Commands.
Esses acionamentos de commandos deverão ser capturados por listeners de
modo semelhante ao feito no JSE.
O construtor de Command é Command(String titulo, CommandType
type, int priority). Título é o texto apresentado no command, CommandType é
para dizer qual o tipo do command e priority é para dizer quais commandos vão
4
Disponível em http://www.javamovel.com/2009_05_01_archive.html, acessado em 03/11/2009
12
serão apresentados antes dos outros. O JME foi feito dessa forma porque não
se sabe quantos botões e nem onde eles ficam disponíveis no aparelho. Se o
aparelho tiver um botão usado para voltar, ele será mapeado em um comando
do tipo Command.BACK, se tiver um botão padrão para cancelar/sair de
menus, será mapeado em um comando do tipo Command.EXIT e assim por
diante.
Um exemplo do uso de um commands está demonstrado a seguir:
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class ExemploComando extends Midlet implements CommandListener{
public Command comando;
public void startApp(){
display = Display.getDisplay(this);
form = new Form("Exemplo commands", null);
comando = new Command("Comando", Command.OK, 0);
form.addCommand(comando);
form.setCommandListener(this);
display.setCurrent(form);
}
public void commandAction(Command c, Displayable d) {
if(d == form){
if(c == comando){
//Código a ser executado ao acionar o comando
}
}
}
public void pauseApp(){ }
public void destroyApp(boolean unconditional){ }
}
}
Na figura a seguir está o resultado de quando se executa o programa no
emulador:
13
Figura 7. Tela com comando
2.8 Screen
As Screens, seu funcionamento e um exemplo de seu uso serão
apresentados em detalhe a seguir
2.8.1 List
List é uma lista que pode apresentar opções na forma de texto ou
imagem ao usuário. Ela pode ser do tipo exclusiva, onde apresentara as
opções precedidas de um radio button, do tipo múltipla, onde elas serão
precedidas por um checkbox ou do tipo implícita, onde os itens são
apresentados na tela para simples seleção.
A seguir está exemplificado um trecho de código onde é declarada,
instanciada e exibida na tela do dispositivo uma lista múltipla com algumas
opções para serem escolhidas.
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class ExemploList extends MIDlet{
public Display display;
public Form formulario;
public List lista;
public void startApp(){
lista = new List("Lista", List.MULTIPLE);
comando = new Command("Comando", Command.OK, 0);
lista.addCommand(comando);
lista.setCommandListener(this);
14
display.setCurrent(lista);
}
public void pauseApp(){ }
public void destroyApp(boolean unconditional){ }
}
Ao ser executado esse programa é exibida a tela ilustrada na figura a seguir:
Figura 8. Lista
2.8.2 TextBox
TextBox é uma caixa de texto que ocupa a tela inteira e que serve para
que o usuário entre com um texto. Da mesma forma dos outros Screens, pode
conter commands. Um exemplo de seu uso está apresentado no código a
seguir:
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class ExemploTextBox extends MIDlet{
public Display display;
public Form formulario;
public TextBox areaDeTexto;
public void startApp(){
display = Display.getDisplay(this);
areaDeTexto = new TextBox("Área de texto", “Essa area toda
pode ser usada como campo para digitação de texto pelo usuário”,
500, TextField.ANY);
display.setCurrent(areaDeTexto);
15
}
public void pauseApp(){ }
public void destroyApp(boolean unconditional){ }
}
Ao ser executado esse programa é exibida a tela ilustrada na figura 9.
Figura 9. Textbox
2.8.3 Alert
Alerts são usados para informar o usuário sobre algum evento e podem
ser configurados para permanecer na tela durante um tempo pré-determinado,
para depois serem substituídos por outro displayable. Por isso a classe Display
disponibiliza o método display.setCurrent(Alert alert, Displayable displayable)
para mostrar o alerta na tela e logo em seguida o próximo displayable.
O primeiro exemplo de programa em JME dado foi utilizando esse
Screen.
2.8.4 Form e seus itens
Apenas no screen Form podem ser inseridos outros itens de interface
com o usuário.
No exemplo a seguir foi demonstrado como usar três desses itens,
StringItem, ChoiceGroup e TextField:
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
16
public class ExemploList extends MIDlet{
public Display display;
public Form formulario;
public StringItem stringItem;
public ChoiceGroup choiceGroup;
public TextField textField;
public void startApp(){
display = Display.getDisplay(this);
formulario = new Form("Formulário", null);
stringItem = new StringItem("Rótulo", "Texto que não pode
ser editado");
choiceGroup = new ChoiceGroup("Escolha",
ChoiceGroup.EXCLUSIVE);
choiceGroup.append("Opção 1", null);
choiceGroup.append("Opção 2", null);
choiceGroup.append("Opção 3", null);
textField = new TextField("Rótulo", "Texto inicial, pode
ser editado", 50, TextField.ANY);
formulario.append(stringItem);
formulario.append(choiceGroup);
formulario.append(textField);
display.setCurrent(formulario);
}
public void pauseApp(){ }
public void destroyApp(boolean unconditional){ }
}
A figura a seguir mostra a tela exibida pelo programa ao ser executado:
17
Figura 10. Form com StringItem, ChoiceGroup e TextField
No próximo exemplo é mostrado um programa para exibir na tela um
Gauge, um DateField e uma ImageItem:
import java.io.IOException;
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class ExemploList extends MIDlet{
public Display display;
public Form formulario;
public Gauge gauge;
public DateField dateField;
public ImageItem imageItem;
public Image imagem;
public void startApp(){
display = Display.getDisplay(this);
formulario = new Form("Formulário", null);
try{
imagem = Image.createImage("/duke.jpg");
}
catch (IOException ex){ }
gauge = new Gauge("Gauge", true, 100, 0);
dateField = new DateField("Horário",DateField.DATE_TIME);
imageItem = new ImageItem("Imagem", imagem,
ImageItem.LAYOUT_CENTER, "");
formulario.append(gauge);
formulario.append(dateField);
formulario.append(imageItem);
display.setCurrent(formulario);
}
public void pauseApp(){ }
public void destroyApp(boolean unconditional){ }
}
E o resultado de quando se executa esse programa está ilustrado na
figura a seguir:
18
Figura 11. Form com um Gauge, DateField e ImageItem
2.9 Persistência de dados
Em JME/MIDP a persistência de dados pode ser feita de duas formas,
através do Record Store Management(RMS) e através de arquivos. Esta ultima
forma foi implementada apenas recentemente e não são todos os dispositivos
que tem suporte a ela.
Através do RMS é possível salvar informações que poderão ser
acessadas posteriormente pela aplicação. Os dados ficam armazenados em
uma estrutura própria chamada RecordStore. Ela é semelhante a um banco de
dados relacional, com operações de inserção, exclusão e atualização, porém
com capacidade limitada de armazenamento.
A persistência usando RMS é custosa para o desenvolvedor pois ele
deve implementar
linha a linha cada dado que deseja armazenar,
transformando-o em array de bytes. Posteriormente deve recuperar os dados
lendo os bytes e convertendo para o tipo de dado compatível.
Para exemplificar como é feita a persistência de um objeto da classe
Bombista, será mostrado o código da classe e depois um exemplo de como
armazenar e ler os dados do RMS:
Classe Bombista:
public class Bombista{
19
public String nome;
public int matricula;
public int senha;
public Bombista(String nome, int matricula, int senha){
this.nome = nome;
this.matricula = matricula;
this.senha = senha;
}
}
Gravando dados:
import java.io.ByteArrayOutputStream;
import java.io.DataOutputStream;
import javax.microedition.midlet.*;
import javax.microedition.rms.*;
public class ExemploRMS extends MIDlet{
public RecordStore rs;
public Bombista bombista;
public ByteArrayOutputStream baos;
public DataOutputStream dos;
public void startApp(){
bombista = new Bombista("José da Silva", 10, 20);
armazenaBombista(bombista);
}
public void armazenaBombista(Bombista b){
baos = new ByteArrayOutputStream();
dos = new DataOutputStream(baos);
try{
rs = RecordStore.openRecordStore("Bombistas", true);
dos.writeUTF(b.nome);
dos.writeInt(b.matricula);
dos.writeInt(b.senha);
byte[] dados = baos.toByteArray();
rs.addRecord(dados, 0, dados.length);
}
catch (Exception e){ }
}
public void pauseApp(){ }
public void destroyApp(boolean unconditional){
}
}
20
Recuperando dados:
import java.io.ByteArrayInputStream;
import java.io.DataInputStream;
import javax.microedition.midlet.*;
import javax.microedition.rms.*;
public class RecuperandoRegistro extends MIDlet{
public RecordStore rs;
public RecordEnumeration re;
public ByteArrayInputStream dais;
public DataInputStream dis;
public Bombista bombista;
public void startApp(){
bombista = recuperaBombista("José da Silva");
System.out.println(bombista.nome + " " +
bombista.matricula + " " + bombista.senha);
}
public Bombista recuperaBombista(String buscaNome){
byte[] dados = new byte[100];
Bombista b = null;
try {
rs = RecordStore.openRecordStore("Bombistas", true);
re = rs.enumerateRecords(new FiltroNome(buscaNome),
null, false);
while(re.hasNextElement()){
dados = rs.getRecord(re.nextRecordId());
String nome;
int matricula, senha;
dais = new ByteArrayInputStream(dados);
dis = new DataInputStream(dais);
nome = dis.readUTF();
matricula = dis.readInt();
senha = dis.readInt();
b = new Bombista(nome, matricula, senha);
}
}
catch (Exception ex){ }
return b;
}
21
public void pauseApp(){ }
public void destroyApp(boolean unconditional){ }
}
Classe FiltroNome:
import java.io.ByteArrayInputStream;
import java.io.DataInputStream;
import java.io.IOException;
import javax.microedition.rms.RecordFilter;
public class FiltroNome implements RecordFilter{
public String buscaNome;
public FiltroNome(String buscaNome){
this.buscaNome = buscaNome;
}
public boolean matches(byte[] candidate){
DataInputStream dis = new DataInputStream(new
ByteArrayInputStream(candidate));
try{
return dis.readUTF().equals(buscaNome);
}
catch(IOException ex){ }
return false;
}
}
2.10 Framework de persistência Floggy
A
persistência
dos
dados
em
aplicações
JME/MIDP
é
feita
tradicionalmente utilizando RMS, porém essa API delega ao desenvolvedor
toda a tarefa de transformar cada atributo dos objetos em array de bytes, num
processo complexo e custoso. (ROSSATO; LUGON 2005)
Com o passar do tempo, foram sendo desenvolvidas aplicações cada
vez mais complexas, que necessitavam cada vez mais guardar uma
quantidade maior de informações em memória não-volátil.
22
Diante desses fatos, surgiu a necessidade da criação de um framework
que abstraísse to desenvolvedor todos os detalhes da persistência, para que
este concentre seus esforços na lógica da aplicação.
Foram pesquisadas e encontradas algumas soluções para esse
problema, sendo a maioria delas proprietária ou específica para determinado
dispositivo, dessa forma não se enquadrando nos requisitos do sistema. Uma
dessas soluções se mostrou ideal, o framework floggy, desenvolvido por
brasileiros. Alem de ser open source, ele é foi desenvolvido para funcionar em
qualquer dispositivo que implemente o perfil MIDP.
Com o uso do floggy, o desenvolvedor pode persistir um objeto e todos
os seus atributos com apenas uma linha de código, simplesmente utilizando o
método
save,
alem
de
outras
facilidades
que
fazem com que
o
desenvolvimento seja totalmente orientado a objeto.
Ao compilar um código com esse framework, primeiro ele é transformado
em bytecode(.class) pelo compilador Java, depois o compilador floggy enxerta
nos arquivos o código de persistência para todos os atributos que serão
persistidos. Após isso eles são pré-verificados gerando novo bytecode e esses
são finalmente empacotados no arquivo jar, junto com a biblioteca floggy. O
esquema de funcionamento do framework está ilustrado na figura a seguir:
23
Figura 12. Esquema de funcionamento do framework Floggy
Utilizando o floggy, o exemplo anterior de salvar e recuperar um
bombista fica muito mais simples
Para se utilizar do framework, a classe Bombista deve implementar a
interface Persistable e deve ter métodos de acesso getters e setters:
A código da classe modificada é apresentado a seguir:
import net.sourceforge.floggy.persistence.Persistable;
public class Bombista implements Persistable{
public String nome;
.public int matricula;
public int senha;
public Bombista(String nome, int matricula, int senha){
this.nome = nome;
this.matricula = matricula;
this.senha = senha;
24
}
public Bombista(){ }
public String getNome() {
return nome;
}
public void setNome(String nome) {
this.nome = nome;
}
public int getMatricula() {
return matricula;
}
public void setMatricula(int matricula) {
this.matricula = matricula;
}
public int getSenha() {
return senha;
}
public void setSenha(int senha) {
this.senha = senha;
}
}
Dessa vez, o código para salvar um bombista na memória fica muito mais
simples, como é mostrado a seguir:
import javax.microedition.midlet.*;
import net.sourceforge.floggy.persistence.PersistableManager;
public class SalvaFloggy extends MIDlet {
public Bombista bombista;
public void startApp(){
PersistableManager pm = PersistableManager.getInstance();
bombista = new Bombista("José da Silva", 10, 20);
try{
pm.save(bombista);
}
catch (Exception e){ }
}
public void pauseApp(){ }
public void destroyApp(boolean unconditional){ }
}
25
Classe RecuperaFloggy:
import javax.microedition.midlet.*;
import net.sourceforge.floggy.persistence.ObjectSet;
import net.sourceforge.floggy.persistence.PersistableManager;
public class RecuperaFloggy extends MIDlet{
public Bombista bombista;
public void startApp(){
bombista = recuperaBombista("José da Silva");
System.out.println(bombista.nome + " " +
bombista.matricula + " " + bombista.senha);
}
public Bombista recuperaBombista(String buscaNome){
PersistableManager pm = PersistableManager.getInstance();
ObjectSet objectSet;
Bombista b = null;
try {
objectSet = pm.find(Bombista.class, new
FiltroNomeFloggy(buscaNome), null);
if(objectSet.size() > 0){
b = (Bombista) objectSet.get(0);
return b;
}
}
catch (Exception e){ }
return b;
}
public void pauseApp(){ }
public void destroyApp(boolean unconditional){ }
}
Classe FiltroNomeFloggy:
import net.sourceforge.floggy.persistence.Persistable;
public class FiltroNomeFloggy implements
net.sourceforge.floggy.persistence.Filter{
public String buscaNome;
public FiltroNomeFloggy(String buscaNome){
this.buscaNome = buscaNome;
26
}
public boolean matches(Persistable persistable){
Bombista b = (Bombista) persistable;
return b.nome.equals(buscaNome);
}
}
27
CAPÍTULO 3. PHP
O PHP é uma linguagem de programação que surgiu em 1995. Ele é
direcionado para o desenvolvimento de páginas web. Se utilizando dele, é
possível fazer páginas web dinâmicas e com acesso aos mais diversos tipos de
banco de dados existentes. Segundo Niederauer(2004), o PHP é uma das
linguagens mais utilizadas para o desenvolvimento web no mundo. Existem
mais de 10 milhões de páginas que se utilizam dele.
3.1 Processamento server side
Diferentemente das outras linguagens de script como o javascript, o PHP
é executado no servidor, não no cliente. Um arquivo com extensão .php nada
mais é do que um arquivo html com algumas instruções de processamento
embutidas. Para exemplificar isso serão apresentados o arquivo original
ola.php e em seguida como ele chega para o cliente:
Arquivo original saudacao.php:
<html>
<head>
<title>Saudação</title>
</head>
<body>
<?php
//isto é um comentário
echo “<p>Saudações pessoas da Terra!</p>”;
?>
</body>
</html>
Resultado para o cliente:
<html>
<head>
<title>Saudação</title>
</head>
<body>
<p>Saudações pessoas da Terra!</p>
</body>
</html>
28
Como pode ser notado, tudo que está entre <?php e ?> é o código PHP
e este não é passado diretamente para o cliente. O PHP trabalha em conjunto
com um servidor web devidamente configurado para processor esses scripts
quando o cliente requisita a visualização da página. Pode ser colocado dentro
do arquivo.php inclusive endereço, usuário e senha de banco de dados que
estes não serão visiveis para o cliente mesmo que ele visualize o código fonte
resultante de sua navegação.
3.2 Trabalhando com formulários HTML
Dentre os recursos do PHP está a capacidade de transmitir informação
de uma página para outra, através de do uso de recursos como GET e POST.
Utilizando o GET, a informação é passada na própria URL. Um exemplo disso
é
http://www.dominio.com.br/processa.php?nome=Diego&sobrenome=Sales.
Nesse exemplo é passado por GET para a página processa.php duas
informações ou variáveis: nome, com o valor “Diego” e sobrenome com o valor
“Sales”.
A diferença mais óbvia do GET e do POST é que o GET passa as
informações na própria URL e o POST as passa abrindo um novo canal de
comunicação, não visível ao cliente. Além disso há outras diferenças como o
limite de caracteres que pode ser passado. O GET tem um limite de cerca de
2KB, dependendo da configuração servidor/cliente, e o POST tem limite
configurável nos parâmetros do servidor web(padrão é 8MB).
Dados de formulário geralmente são transmitidos por POST, sendo o
GET mais usado para gerar hyperlinks dinamicos.
Para exemplificar isso sera apresentado um formulário simples, o código
e a vizualização(note que esse formulário não precisa ser dinâmico) e em
seguida o código do arquivo recebe.php com o resultado quando se pressiona
o botão enviar:
Arquivo formulário.html:
<html>
<head>
<title>Formulário</title>
29
</head>
<body bgcolor="lightblue">
<form action="recebe.php" method="post">
<p>Digite seu nome: <input type="text" name="nome" /></p>
<p>Digite
seu
sobrenome:
<input
type="text"
name="sobrenome"
/></p>
<p><input type="submit" value="Enviar" /></p>
</form>
</body>
</html>
Figura 13.Formulário
Arquivo recebe.php
<html>
<head>
<title>Recebendo dados</title>
</head>
<body bgcolor="lightblue">
<p><?php echo "Seja bem vindo, ".$_POST['nome']." ".
$_POST['sobrenome']; ?></p>
</body>
</html>
Figura 14. Conteúdo de recebe.php
Algumas observações podem ser feitas sobre esse código do arquivo
recebe.php:
Dentro das tags <?php e ?>, variáveis são identificadas sempre com um
símbolo de cifrão antes do seu nome. Nesse caso a variável utilizada foi
$_POST. $_POST é uma variável especial do PHP que serve para armazenar
as informações recebidas via POST na forma de um array associativo. Dessa
30
forma a informação passada pelo formulário pelo campo com identificação
“nome”
e
método
de
envio
POST
estará
armazenada
na
variável
$_POST[‘nome’].
Echo é uma função que serve para ecoar no HTML o que estiver na
frente dela na forma de string. Strings são delimitadas por aspas simples ou
duplas e podem ser concatenadas utilizando o caracter ponto(.).
3.3 Acesso a bancos de dados
O PHP oferece suporte a maioria dos bancos de dados disponiveis no
mercado atualmente. Os bancos de dados não suportados diretamente podem
ser acessados via ODBC. A forma como é feito o acesso é simples, feito
através de funções especificas para cada banco.
Para utilizar o banco de dados MySQL são utilizadas as funções
precedidas por “mysql_” como mysql_connect(string $server, string $username,
string $password), que serve para conectar-se ao banco.
A seguir é apresentado um exemplo simples de uma página php que
conecta em um servidor MySQL, seleciona todas as linhas da tabela “pessoas”
no banco de dados “cadastros” e apresenta em forma de tabela na tela.
Figura 15. Tabela pessoas sendo visualizada no banco de dados
exibe.php
<html>
<head>
<title>Acesso a banco de dados</title>
</head>
<body>
<table border="1">
<tr><th>Nome</th><th>Cor favorita</th><th>Comida favorita</th></tr>
<?php
31
$conexao = mysql_connect("localhost", "root", "usbw");
mysql_select_db("cadastros");
$query = "select * from pessoas";
$resultado = mysql_query($query);
$i = 1;
while($linha = mysql_fetch_assoc($resultado)){
if($i%2 == 0){
$cor = "lightblue";
}
else{
$cor = "gray";
}
echo "<tr bgcolor=\"".$cor."\">
<td>".$linha['nome']."</td>
<td>".$linha['cor']."</td>
<td>".$linha['comida']."</td>
</tr>";
$i++;
}
?>
</table>
</body>
</html>
Figura 16. Exibição da página exibe.php
No exemplo, a variável $conexão recebe o recurso retornado pela
função mysql_connect. É passado o endereço localhost, o usuário root e a
senha usbw. Em seguida, com mysql_select_db, é selecionado o banco de
dados que vai se trabalhar, cadastros. A variável $query recebe a string com a
consulta SQL que trará todos os registros da tabela “pessoas”(veja sessão 4.2).
A função mysql_query serve tanto para passar comandos de select como de
32
update, delete e insert. No caso foi executado o select e a massa de dados fica
armazenada no recurso $resultado. Em seguida foi usado um recurso para dar
o efeito cor sim cor não da seguinte forma: a variável $i foi inicializada com o
valor 1(note a ausência da necessidade de declarer variáveis e de se
especificar um tipo para elas). A cada iteração do loop while ela é
incrementada e antes do PHP ecoar para o HTML a nova linha vinda da tabela
é checado se $i dividido por 2 dá resto zero. Caso positivo, a cor da linha será
lightblue, caso contrário sera gray.
Continuando o raciocínio, a função mysql_fetch_assoc pega a próxima
linha da massa de dados armazenada em $resultado e armazena no array
associativo $linha. A partir daí, a cada iteração as variáveis $linha[‘nome’],
$linha[‘cor’]
e
linha[‘comida’]
terão
valores
correspondentes
à
linha
correspondente no banco de dados.
33
CAPÍTULO 4. OUTRAS TECNOLOGIAS UTILIZADAS
Neste capítulo será feita uma revisão de outras duas tecnologias que
foram utilizadas para o desenvolvimento do sistema, o XML e o SQL.
4.1 XML
XML é uma recomendação da W3C para estruturar conjuntos de
informações de forma portável e bem conhecida, para serem intercambiadas
entre sistemas diferentes. É uma meta-linguagem de marcação e é estruturada
na forma de texto, contendo tags, que são as marcações que começam com o
símbolo de menor, “<” e terminam com o símbolo de maior “>”.
Existem tags de abertura e de fechamento, sendo que toda informação
útil do documento XML deve estar contida entre essas tags. Um exemplo de
tag de abertura é <nome> e de fechamando </nome>. A diferença entre elas é
que a tag de fechamento sempre começa com um símbolo de barra “/”.
As tags servem para dizer ao programa que recebe a informação do que
se trata o dado delimitado entre elas.
Utilizando-se do XML é possível simplesmente fazer uso dos diversos
writers e parsers já implementados, ao invés de desenvolver um layout
proprietário de intercâmbio de dados que só sirva para uma aplicação em
específico. Documentos XML devem obedecer uma série de regras para que
sejam úteis. A principal delas é ser “bem formado”.
4.1.1 XML bem formados
Documentos bem formados seguem uma série de regras:
 Devem conter um elemento raiz, ou seja, todos os outros
elementos devem estar contidos dentro desse elemento.
 Todo elemento aberto deve ser fechado. Para se utilizar um
elemento vazio pode ser utilizado uma tag especial que abre e
fecha o elemento simultaneamente. Tags de abertura e
fechamento são da forma <pessoa id=”4” />, com uma barra ”/”
antes do “>”
 XML é case sentitive, ou seja, <Pessoa> é diferente de <pessoa>.
Deve ser observado as letras maiúisculas e minúsculas das tags.
34
 As tags devem ser aninhadas corretamente, ou seja, abertas e
fechadas na ordem em que foram apresentadas. Elementos filhos
devem sempre estar cercados por seus elementos pais.
 Os valores dos atributos, que ficam dentro das tags, após com os
nomes dos elementos, devem ser envoltos por aspas simples ou
duplas.
 Atributos não podem ter nomes repetidos. Se for necessário o uso
de informações múltiplas, devem ser utilizados elementos ao
invés de atributos.
Na figura 17 é apresentado um exemplo de documento XML bem
formado.
5
Figura 17. Exemplo de XML bem formado
5
Disponível em http://www.loiane.com/2009/03/documento-xml-bem-formado-introducao-ao-
xml-parte-iv/, acessado em 24/11/2009
35
4.2 SQL
SQL ou Structured Query Language é a linguagem padrão para o envio
de comandos para servidores de banco de dados relacionais. Ela foi inspirada
nas teorias da algebra relacional e surgiu no início da década de 70.
Existem pequenas peculiaridades na sintaxe do SQL para cada sistema
gerenciador de banco de dados, mas em essência o SQL é um padrão e um
comando que funciona em um banco provavelmente funcionará nos demais.
Os comandos SQL são divididos em dois grupos: DDL (data definition
language) e DML(data manipulation language).
4.2.1 DDL
Comandos DDL servem para definição da estrutura do banco de dados.
As estruturas que podem ser definidas com o DDL são as tabelas, índices e
visões.
Tabela é o nome dado à estrutura de dados onde ficam armazenados os
dados. Índices são estruturas associadas às tabelas e são usados para buscar
dados mais rapidamente. Funciona de maneira análoga aos sumários contidos
nos livros, que fazem com que a busca por alguma informação seja mais
eficiente do que se o leitor buscasse página a página. E visões ou views são
instruções de consulta encapsuladas. Na prática não armazenam dados em si,
mas sim instruções SELECT que buscam informações em diversas tabelas,
podendo o desenvolvedor abstrair-se da forma como os dados estão gravados
fisicamente.
Basicamente os DDL’s são os comandos CREATE, DROP e ALTER.
Com esses comandos é possível criar, deletar ou alterar tabelas, índices e
visões.
A seguir é apresentado um exemplo de criação de tabela utilizando o
comando CREATE TABLE:
CREATE TABLE pessoas(
seq
int primary key,
nome
char(50) not null,
dt_nascimento datetime not null);
Nesse exemplo é criada a tabela “pessoas” com três colunas, “seq”,
“nome” e “dt_nascimento”.
36
“Seq” é do tipo inteiro e tem uma restrição: primary key. O campo sendo
primary key faz com que haver dois ou mais registros com o mesmo “seq”, ou
seja, identifica um registro univocamente.
“Nome” é do tipo caracter(char), de tamanho 50 e tem a restrição not
null, que faz com que o SGBD não permita que sejam inseridos registros com o
campo “nome” nulo.
“Dt_nascimento” é do tipo datetime, que é a forma como campos com
data e hora são armazenados em alguns bancos de dados, e também tem a
restrição not null.
4.2.2 DML
Comandos DML são utilizados para manipular os dados que estão
gravados no banco de dados. Basicamente são comandos SELECT, INSERT,
UPDATE e DELETE, usados respectivamente para recuperar, inserir, atualizar
e apagar dados.
Para mostrar como novos registros são inseridos, será apresentada em
forma de exemplo a inserção de um registro na tabela “pessoas”, criada no
exemplo anterior:
INSERT INTO pessoas(seq, nome, dt_nascimento)
VALUES(1, ‘Diego Sales’, ‘1984-01-08 01:30:00’);
Nesse exemplo é inserido um registro na tabela “pessoas” com os
valores de seqüencial 1, nome “Diego Sales” e data de nascimento dia 08 de
janeiro de 1984.
No caso de se precisar atualizar esse registro de “Diego Sales” para
“Diego Antonio Sales”, deverá ser utilizado o comando UPDATE. No exemplo
a seguir isso é feito buscando o registro pelo nome:
UPDATE pessoas
SET nome = ‘Diego Antonio Sales’
WHERE nome = ‘Diego Sales’;
O registro pode ser atualizado de outra forma, mais recomendada,
utilizando-se de sua chave primária para fazer a busca. Dessa forma não se
37
corre o risco de atualizar mais de um registro. Essa outra forma de fazer o
update está demonstrada no exemplo a seguir:
UPDATE pessoas
SET nome = ‘Diego Antonio Sales’
WHERE seq = 1;
Para apagar o registro pode ser usado o comando DROP. Nesse
comando a cláusula WHERE tem a mesma função que tem no comando
UPDATE, restringir em quais registros serão aplicados as alterações(ou
exclusões). Para apagar o registro que estamos trabalhando deve ser enviado
ao banco o comando a seguir:
DELETE FROM pessoas
WHERE seq = 1;
Para buscar dados das tabelas ou views, é utilizado o comando
SELECT. Um SELECT pode trazer dados de uma ou mais tabelas. Ele tem
várias cláusulas que servem para restringir a busca ou modificar a forma como
os dados serão apresentados.
Para ilustrar o funcionamento do SELECT serão apresentadas duas
tabelas, uma com dados sobre pessoas e outra com informações sobre
salários, a instrução SELECT responsável por buscar e trazer os dados e a
visualização do resultado:
Figura 19. Tabela salario no banco de dados
Figura 18. Tabela pessoa no banco de dados
38
Instrução select:
SELECT p.nome, s.valor
FROM pessoa p, salario s
WHERE p.id_salario = s.id
AND s.valor BETWEEN 1000 AND 3000;
Esse SELECT vai trazer o nome e o salário das pessoas que tem salário
entre 1000 e 3000. São necessários utilizar-se de JOIN’s, que são os
relacionamentos entre as tabelas, para que o comando não traga dados
errados, nesse exemplo a linha WHERE p.id_salario = s.id relaciona as pessoas
com os salários, de forma que em cada linha do resultado, o valor de salário
que aparecer é o correspondente aquele salário daquela pessoa na tabela
salário.
O resultado de quando se executa esse SELECT é apresentado na
figura a seguir:
Figura 20. Resultado do select do exemplo
39
CAPÍTULO 5. SISTEMA DE APONTAMENTOS MÓVEL
Nesse capítulo serão apresentados os dois módulos que compõem o
sistema, o módulo celular e o módulo web.
5.1 Módulo celular
Esse módulo foi desenvolvido em JME e é o módulo principal do
sistema. Ele é operado pelos bombistas, para fazer os apontamentos em
campo e eventualmente pelos administradores do sistema para fazer sua
parametrização. Foi construído baseado em um modelo de estados e eventos.
De acordo com o estado atual o programa apresenta as opções de
apontamento para o bombista.
O bombista também pode apontar uma ocorrência, que é quando
acontece alguma coisa que foge ao fluxo normal de funcionamento do
programa.
Um apontamento consiste em uma coleção de informações sobre um
evento ou ocorrência. As informações são: data/hora, estado, evento(ou
ocorrência), IMEI do aparelho, número do telefone, Km, metros cúbicos (m3),
contrato, NF(nota fiscal), matrícula do bombista e prefixo do caminhão-bomba.
5.1.1 Eventos
Eventos são os apontamentos principais do sistema e é com base neles
que os relatórios serão calculados. Os eventos são:

Saída para obra: registra o momento e a quilometragem do
caminhão-bomba quando o bombista sai da empresa.

Chegada na obra: registra o momento e a quilometragem do
caminhão-bomba quando o bombista chega na obra.

Início
do
bombeamento:
registra
o
momento
de
início
do
bombeamento. De acordo com os parâmetros configurados pode
registrar qual é o contrato ou a nota fiscal cujo concreto será
bombeado ou o bombista pode deixar para informar esses dados ao
final do bombeamento.
40

Final do bombeamento: registra o momento do final do bombeamento
juntamente com a quantidade de metros cúbicos bombeados. De
acordo com os parâmetros configurados exige que o bombista
informe o contrato ou a nota fiscal cujo concreto foi bombeado, caso
não tenha sido informado no início do bombeamento.

Saída da obra: registra o momento que o bombista deixa a obra,
juntamente com a quilometragem do caminhão-bomba.

Chegada na empresa: registra o momento e a quilometragem do
caminhão-bomba ao chegar na empresa.
5.1.2 Ocorrências
Qualquer acontecimento fora do normal que acontecer durante o
trabalho e que o bombista julgar útil transmitir à empresa pode ser apontado na
forma de uma ocorrência. São elas:

Cancelamento do bombeado: Quando por algum motivo, por pedido
do cliente, condições climáticas desfavoráveis etc., o bombeamento é
cancelado.

Quebra da bomba: Quando a bomba fica incapacitada de funcionar
devido à quebra.

Quebra do caminhão: Quando o acontece alguma coisa que
impossibilite o caminhão de retornar normalmente à empresa. Ao ser
confirmada essa ocorrência, é solicitado que seja informado a
quilometragem do caminhão e o programa volta automaticamente
para o estado “na empresa”, apresentado posteriormente nesse
capítulo.
5.1.3 Estados
O programa usa o conceito de estado para saber quais opções devem
ser apresentadas para o bombista escolher. São eles:

Na empresa: é o estado inicial e final de todo processo. Um ciclo
completo deve sempre iniciar e terminar a execução nesse estado.
41

Em deslocamento: o sistema permanece nesse estado sempre que o
caminhão bomba estiver se deslocando. Ele entra nesse estado
quando é apontado um evento de saída para obra ou saída da obra.

Na obra: o sistema permanece nesse estado sempre que o
caminhão-bomba estiver na obra mas não estiver bombeando.

Bombeando: o sistema permanece nesse estado quando o
bombeamento estiver acontecendo.
A figura abaixo ilustra o relacionamento entre os estados e os eventos
Figura 21. Estados e eventos
A opção de enviar dados está disponível em todos os estados, mesmo
quando não houver nenhum apontamento para ser enviado. Foi feito dessa
forma para não gerar dúvidas sobre a existência ou não de apontamentos não
enviados, pois ao acessar essa opção, vai aparecer na tela a quantidade de
apontamentos enviados ou a mensagem “Não tem nenhum registro para
enviar”, ilustrada na figura abaixo:
Figura 22. Tela informativa
5.1.4 Opções do administrador
Antes de o bombista iniciar a utilização do sistema, o administrador deve
entrar com sua senha privativa para configurar os parâmetros e receber os
dados de bombistas e caminhões-bomba do servidor.
42
Ao entrar no sistema com a senha do administrador é apresentada a tela
ilustrada pela figura abaixo:
Figura 23. Menu do administrador
As três primeiras opções são os parâmetros configuráveis somente com
as opções “sim” e “não”. Quando um deles é selecionado é apresentada a tela
ilustrada pela figura a seguir:
Figura 24. Menu de escolha de parâmetros “sim” e ”não”
E quando a opção “número telefone” é selecionada, é apresentada a tela
ilustrada pela figura a seguir:
43
Figura 25. Tela de entrada de telefone
A opção “enviar dados” faz o mesmo tanto para o administrador como
para o bombista: tenta enviar os todos os apontamentos que estiverem na
memória do celular para o servidor e exibe na tela quantos foram enviados, ou
no caso de falha, uma mensagem descritiva.
Ao selecionar a opção recebe bombistas o programa tenta estabelecer
conexão com o servidor web e receber a lista com os bombistas habilitados a
utilizar o programa, com suas respectivas matriculas e senhas privativas. Ao
final é exibida a tela ilustrada na figura a seguir no caso de sucesso ou uma
mensagem descritiva do erro.
Figura 26. Aviso de recebimento de dados
A opção recebe caminhões é análoga a opção anterior, porem ao invés
de buscar no servidor o cadastro dos bombistas a lista de caminhões-bomba
disponíveis para uso.
44
A opção ver bombistas exibe na tela uma lista com todos os bombistas
armazenados naquele momento na memória do celular. A tela com os dados
esta ilustrada na figura a seguir:
Figura 27. Lista de bombistas
A opcao ver caminhões é análoga a pcao ver bombistas. Ao ser
escolhida essa pcao é exibida a tela ilustrada na figura a seguir:
Figura 28. Lista de prefixos
A opção ver eventos exibe na tela a lista dos apontamentos
armazenados na memória do celular. Os apontamentos são apagados da
memória quando são enviados com sucesso ao servidor. Um exemplo dessa
tela com alguns apontamentos esta ilustrada na figura a seguir:
45
Figura 29. Lista de eventos registrados
5.1.5 Operaçao do programa
Quando o programa é aberto, a primeira tela exibida é a que esta
iludstrada na figura a seguir:
Figura 30. Tela de identificação
Nessa tela é necessário informar a matricula e a senha do bombista ou a
matricula e senha especial do administrador do sistema.
Quando é informada uma identidade válida o programa vai para a tela de
escolha de eventos. De acordo com o estado atual, são exibidas diferentes
opções. As quatro possibilidades estão ilustradas nas figuras a seguir:
46
Figura 31. Lista do estado “na empresa”
Figura 32. Lista do estado “em deslocamento”
Figura 33. Lista do estado “na obra”
Figura 34. Lista do estado “bombeando”
Como pode ser verificado nas figuras, a opção de registrar ocorrencia
está disponível nos estados em deslocamento e na obra. Ao ser selecionada
essa opção é exibida a tela ilustrada pela figura a seguir:
Figura 35. Lista de ocorrências
47
5.1.6 Telas de entrada de dados
É solicitada que seja digitada a quilometragem do caminhão ao ser
apontado um dos seguintes eventos: saída para obra, chegada na obra, saída
da obra, chegada na empresa, ou a ocorrência quebra do caminhão. É
solicitado a quantidade de metros cúbicos bombeados quando é apontado o
evento fim do bombeamento. Nesse momento também pode ser necessário
informar a nota fiscal ou o contrato bombeado, de acordo com os parâmetros.
Essas telas de entrada de dados estão ilustradas nas figuras a seguir:
Figura 36. Tela de entrada de m³
Figura 37. Tela de entrada de KM
Figura 38. Tela de entrada de N.F.
Figura 39. Tela de entrada de contrato
5.1.7 Telas de confirmação
Sempre antes de ser registrado qualquer apontamento é apresentado na
tela uma mensagem de confirmação, para evitar que sejam gravados
48
apontamentos errados. Algumas dessas telas de confirmação esta ilustradas
nas figuras a seguir:
Figura 40. Confirmação
Figura 41. Confirmação
5.2 Módulo web
Até o momento de entrega deste trabalho não foram desenvolvidos
todos os relatórios com os indicativos frutos dos apontamentos. Dessa forma,
serão apresentados os componentes desse módulo responsáveis pela inserção
dos dados no banco de dados, por escrever os dados dos bombistas
armazenados no banco no formato XML e uma prévia dos apontamentos,
apresentados em forma de tabela.
parametros.php
<?php
$server
= "maquina.host.com";
$username
= "usuario";
$password
= "senha";
$database_name = "leao1";
mysql_connect($server, $username, $password);
mysql_select_db($database_name);
?>
Esse arquivo parametros.php será utilizado por todos os outros para
evitar que o código seja duplicado em todos eles. Nele será feita a conexão
com o banco de dados.
49
Arquivo responsável pela inclusão dos apontamentos, apont.php
<?php
require('parametros.php');
if(isset($_POST['estado']) &&
isset($_POST['evento']) &&
isset($_POST['instante']) &&
isset($_POST['imei']) &&
isset($_POST['prefixo']) &&
isset($_POST['m3']) &&
isset($_POST['nf']) &&
isset($_POST['contrato']) &&
isset($_POST['km']) &&
isset($_POST['matricula'])){
$estado
= $_POST['estado'];
$evento
= $_POST['evento'];
$instante
= $_POST['instante'];
$imei
= $_POST['imei'];
$prefixo
= $_POST['prefixo'];
$m3
= $_POST['m3'];
$nf
= $_POST['nf'];
$contrato
= $_POST['contrato'];
$km
= $_POST['km'];
$matricula
= $_POST['matricula'];
$insert = "insert into trc_mvl_apont
(cod_estado,
cod_evento,
instante,
imei,
prefixo,
m3,
nf,
contrato,
km,
matricula)
values($estado,
$evento,
$instante,
50
'$imei',
'$prefixo',
$m3,
$nf,
$contrato,
$km,
$matricula)";
mysql_query($insert) or die("*");
echo "#";
}
else{
echo "*";
}
?>
Nesse arquivo é verificado se todas as variáveis estão setadas, após
isso elas são transferidas para variáveis com nomes mais amigáveis e em
seguida é feito o insert com a função mysql_query. Observe que não é gerado
um arquivo HTML como resposta, essa página ecoa simplesmente o caracter #
em caso de sucesso e * em caso de falha e serve para o módulo celular saber
se o registro foi inserido com sucesso.
Arquivo
responsável
pelo
recebimento
do
cadastro
dos
bombistas,
recbomb.php:
<?php
require('parametros.php');
if(isset($_GET['imei'])){
$query
= "select * from trc_mvl_bombista";
$result = mysql_query($query) or die ("*");
header("Content-Type: text/xml");
$xmlWriter = new XMLWriter();
$xmlWriter->openMemory();
$xmlWriter->setIndentString('
');
$xmlWriter->setIndent(true);
51
$xmlWriter->startDocument("1.0", "UTF-8");
$xmlWriter->startElement("bombistas");
while($row = mysql_fetch_array($result)){
$xmlWriter->startElement("bombista");
$xmlWriter->writeElement("matricula", $row['matricula']);
$xmlWriter->writeElement("nome", $row['nome']);
$xmlWriter->writeElement("senha", $row['senha']);
$xmlWriter->endElement();
}
$xmlWriter->endElement();
$xmlWriter->endDocument();
echo $xmlWriter->outputMemory();
}
else{
echo "*";
}
?>
Nesse arquivo, se for recebida a variável setada $_GET[‘imei’], mesmo
que vazia, fará com que seja exibida a lista dos bombistas em formato XML. A
forma como foi escrito o XML é diferente como das formas de escrever
mostradas anteriormente, utilizando simplesmente a função echo. Aqui é
utilizada a classe XMLWriter. Nela está implementada uma forma mais
elegante de se escrever XML, além de mais segura, pois delega à outra
camada a responsabilidade por cada caractere dado como resposta à
requisição.
Arquivo que exibe na tela uma tabela com os apontamentos armazenados no
banco de dados, acompanhamento.php:
<?php
require('parametros.php');
?>
<html>
<head>
<title>Acompanhamento das bombas</title>
52
</head>
<body>
<center>
<table border="1" style="border-collapse:collapse; fontfamily:Arial;" >
<tr>
<th>Hora</th>
<th>Estado</th>
<th>Evento</th>
<th>IMEI</th>
<th>KM</th>
<th>M3</th>
<th>Contrato</th>
<th>NF</th>
<th>Matrícula</th>
<th>Nome</th>
<th>Prefixo</th>
</tr>";
<?php
$query = "SELECT es.estado,
ev.evento,
a.imei,
a.km,
a.m3,
a.contrato,
a.nf,
a.matricula,
b.nome,
a.prefixo,
FROM_UNIXTIME(a.instante/1000) hora
FROM trc_mvl_apont a,
trc_mvl_estado es,
trc_mvl_evento ev,
trc_mvl_bombista b
WHERE a.cod_estado = es.cod_estado
AND a.cod_evento = ev.cod_evento
AND a.matricula = b.matricula
ORDER BY a.instante";
$result = mysql_query($query);
$i = 0;
53
while($row = mysql_fetch_array($result)){
$i++;
if($i%2 == 0){
$cor = "lightblue";
}
else{
$cor = "lightyellow";
}
echo "<tr bgcolor=\"$cor\"><td><font
size=2>".$row['hora']."</td>
<td><font size=2>".$row['estado']."</font></td>
<td><font size=2>".$row['evento']."</font></td>
<td><font size=2>".$row['imei']."</font></td>
<td><font size=2>".$row['km']."</font></td>
<td><font size=2>".$row['m3']."</font></td>
<td><font size=2>".$row['contrato']."</font></td>
<td><font size=2>".$row['nf']."</font></td>
<td><font size=2>".$row['matricula']."</font></td>
<td><font size=2>".$row['nome']."</font></td>
<td><font
size=2>".$row['prefixo']."</font></td></tr>";
}
?>
</table>
</center>
</body>
</html>
Quando o arquivo acompanhamento.php é acessado ele exibe na tela
uma tabela com todos os apontamentos armazenados naquele momento no
banco de dados. Essa tabela será semelhante à ilustrada na figura a
seguir(dados fictícios):
54
Figura 42. Resultados
55
CAPÍTULO 6. CONCLUSÃO
No momento em que este trabalho foi concluído o sistema estava em
fase de testes e os resultados preliminares indicavam que ele atingiu o objetivo
inicial proposto. Esses resultados podem ser visualizados na figura 42.
A implantação do sistema facilitou o trabalho de vários funcionários da
empresa. Agora os bombistas não precisam mais levar prancheta, papel e
caneta para a obra, nem perder tempo conferindo no relógio o horário de
chegada do concreto. O tempo que o funcionário da área administrativa
gastava para pegar os apontamentos manuais e digitar no sistema agora pode
ter ser aproveitado para outros trabalhos.
Além da diminuição do volume de trabalho dos funcionários da empresa,
conseguiu-se maior agilidade em todo processo e menor quantidade de erros
inseridos por apontamentos ou digitações erradas.
Essa agilidade no processo possibilitou um controle de produção mais
eficiente para prestação de serviços de bombeamento de concreto.
Um dos requisitos para implantação do sistema era que não
demandasse compra de novos equipamentos. Como ele roda em um telefone
celular e estes são substituídos com freqüência, também foi um requisito do
sistema que este funcionasse em outros telefones. A portabilidade do programa
escrito em JME de funcionar em qualquer dispositivo que implemente sua
máquina virtual, independentemente do fabricante ou modelo do telefone foi
decisiva para sua escolha como plataforma de desenvolvimento.
A utilização do PHP como linguagem de desenvolvimento do modulo
web se mostrou ideal pois atendeu aos requisitos sem gerar custos extras por
hospedagem em servidores web dinâmicos menos populares. Esse módulo faz
a comunicação com o banco de dados e escreve os dados em XML de forma
relativamente simples. Alem disso recebe os dados do celular de maneira
relativamente segura via POST e é rápido nas respostas.
O intercambio das informações do servidor web para o celular
inicialmente foi feito utilizando de texto puro, separando os campos por
vírgulas. Notou-se que dessa forma somente o programa desenvolvido para
56
esse fim conseguiria fazer uso das informações, já que estavam em um layout
proprietário do programa, alem disso, quando as informações estavam
inconsistentes no servidor, aconteciam erros na interpretação dos dados. Com
a substituição desse modelo por outro, utilizando XML, o código ficou bem mais
legível para outros programas que no futuro precisem se utilizar da informação,
alem de que se a informaçao não estiver consistente no servidor, o parser XML
critica o erro antes que cause leitura incorreta.
O servidor de banco de dados MySQL atendeu aos requisitos
eficientemente e foi escolhido pelos mesmos motivos do modulo web.
Como trabalho futuro pode ser incluído no programa suporte a ler
coordenadas do sistema GPS de telefones celulares que tenham esse suporte.
Dessa forma, junto com os apontamentos poderiam ser registradas as
coordenadas dos caminhões-bomba. Outro aprimoramento possível de ser
implementado é o uso da câmera do telefone para leitura de códigos de barra,
utilizando-se de processamento digital de imagem.
57
REFERÊNCIAS BIBLIOGRÁFICAS
Yuan, Michael Juntao - Enterprise J2ME – 2002
Rossato, Thiago e Lugon, Priscila T. – Trabalho de conclusão de curso –
Framework de persistência Floggy – 2005
NIEDERAUER, Juliano - Desenvolvendo Websites com PHP
58
BIBLIOGRAFIA
DEITEL
Java em 21 dias
Rischpater, Ray – Beginning JAVA ME Platform
O'Reilly - J2ME in a Nutshell
59