sistema para coleta de dados baseado em dispositivos móveis e

UNIVERSIDADE DO PLANALTO CATARINENSE
DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
CURSO DE SISTEMAS DE INFORMAÇÃO
(BACHARELADO)
CLEITON FERNANDO REMOR
SISTEMA PARA COLETA DE DADOS BASEADO EM DISPOSITIVOS
MÓVEIS E WEB SERVICES
LAGES (SC)
2008
CLEITON FERNANDO REMOR
SISTEMA PARA COLETA DE DADOS BASEADO EM DISPOSITIVOS
MÓVEIS E WEB SERVICES
Trabalho de Conclusão de Curso
submetido à Universidade do Planalto
Catarinense para obtenção dos créditos
de disciplina com nome equivalente no
curso de Sistemas de Informação Bacharelado.
Orientação: Prof. Wilson Castello Branco
Neto, Dr.
LAGES (SC)
2008
CLEITON FERNANDO REMOR
DESENVOLVIMENTO DE UM SISTEMA DE INFORMAÇÃO PARA
COLETA DE DADOS
ESTE RELATÓRIO, DO TRABALHO
DE CONCLUSÃO DE CURSO, FOI
JULGADO
ADEQUADO
PARA
OBTENÇÃO DOS CRÉDITOS DA
DISCIPLINA DE TRABALHO DE
CONCLUSÃO DE CURSO, DO 8º.
SEMESTRE, OBRIGATÓRIA PARA
OBTENÇÃO DO TÍTULO DE:
BACHAREL EM
INFORMAÇÃO
SISTEMAS
DE
Lages (SC), 04 de Dezembro de 2008
Prof. Wilson Castello Branco Neto, Dr.
Orientador
BANCA EXAMINADORA:
Prof. Marcos André Pisching, M.Sc.
UNIPLAC
Prof. Angelo Augusto Frozza, M.Sc.
UNIPLAC
Prof. Wilson Castello Branco Neto, Dr.
Professor de TCC
Prof. Angelo Augusto Frozza, M.Sc.
Coordenador de Curso
Dedico a Deus que me deu condições para
desenvolver este trabalho.
LISTA DE ILUSTRAÇÕES
FIGURA 1 FIGURA 2 FIGURA 3 FIGURA 4 FIGURA 5 FIGURA 6 FIGURA 7 FIGURA 8 FIGURA 9 FIGURA 10 FIGURA 11 FIGURA 12 FIGURA 13 FIGURA 14 FIGURA 15 FIGURA 16 FIGURA 17 FIGURA 18 FIGURA 19 FIGURA 20 FIGURA 21 FIGURA 22 FIGURA 23 FIGURA 24 FIGURA 25 FIGURA 26 -
PDA com o sistema operacional Pocket PC da Microsoft. ..................20
Osborne 1..............................................................................................20
IBM-PC.................................................................................................21
Epson HX-20 ........................................................................................21
Tela inicial do Visual Studio 2005. .......................................................25
Desenv. de um sistema para computador de mesa no Visual
Studio 2005 ...........................................................................................25
Desenvolvimento de uma aplicação para PDA no Visual
Studio 2005 ...........................................................................................26
Emuladores da Microsoft incluídos no Visual Studio 2005..................26
Ambiente de desenvolvimento de aplicativos móveis no
NetBeans ..............................................................................................27
Emulador do NetBeans em execução .................................................28
Ambiente de desenvolvimento do PDAToolBox ................................29
Ambiente de desenvolvimento do SQL Server Management Studio
Express ................................................................................................31
Ciclo de vida do sistema baseado em ciclos iterativos .......................37
Estrutura de um projeto de web service no Visual Studio ..................57
Esquema de funcionamento do sistema ..............................................58
Exemplo de reutilização das camadas MVC ......................................60
Estrutura de camadas do sistema ........................................................61
Interface gráfica da primeira etapa do cadastro de abastecimento de
veículos ...............................................................................................81
Interface gráfica para a inclusão e alteração de abastecimento de
veículo.................................................................................................84
Acessando o arquivo ServicoRetornaDados.asmx .............................93
Acessando o método retornaUnidadesNegocio .................................94
Resultado da execução do método retornaUnidadeNegocio .............94
Acessando o arquivo ServicoRecebeDados.asmx ..............................95
Acessando o método inserirAbastecimentoMaquina .........................96
Resultado da execução do método
inserirAbastecimentoMaquina............................................................97
Interface de alteração dos endereços dos web services no
aplicativo do módulo de comunicação no PDA. ................................98
FIGURA 27 - Interface do processo de comunicação no PDA .................................98
FIGURA 28 - Resultado da etapa de obtenção de dados com o aplicativo do
módulo de comunicação no PDA .......................................................99
FIGURA 29 - Resultado da etapa de envio de dados com o aplicativo do
módulo de comunicação no PDA .....................................................100
FIGURA 30 - Tabela ABASTECIMENTOVEICULO do banco de dados da
empresa antes do processo de comunicação .....................................100
FIGURA 31 - Tabela ABASTECIMENTOVEICULO do banco de dados da
empresa depois do processo de comunicação...................................101
FIGURA 32 - Designado ou alterando uma unidade de negócio no PDA ..............102
FIGURA 33 - Alertas mostrado quando da não designação de uma unidade de
negócio ..............................................................................................102
FIGURA 34 - Interfaces do cadastro de abastecimento de veículo .........................103
FIGURA 35 - Resultado da etapa de coleta de dados com o aplicativo do
módulo de coleta no PDA .................................................................104
FIGURA 36 - Tela inicial para cadastro de atividades ............................................105
FIGURA 37 - Interface para a inserção ou alteração de uma atividade ..................105
FIGURA 38 - Menu de opções para atividades .......................................................106
FIGURA 39 - Interface para inserção de funcionário em atividade ........................106
FIGURA 40 - Interface para efetuar uma cópia de segurança.................................108
FIGURA 41 - Interface para restaurar uma cópia de segurança ..............................108
FIGURA 42 - Resultado do teste de cópia de segurança.........................................109
QUADRO 1 - Comparativo entre ferramentas de desenvolvimento .........................31
QUADRO 2 - Comparativo entre modelos de PDA ..................................................34
QUADRO 3 - Requisito funcional F1 – Manter informações sobre
unidades de negócio...........................................................................40
QUADRO 4 - Requisito funcional F2 – Manter informações sobre parcelas ...........41
QUADRO 5 - Requisito funcional F3 – Manter informações sobre quadras ............41
QUADRO 6 - Requisito funcional F4 – Manter informações sobre culturas ............41
QUADRO 7 - Requisito funcional F5 – Manter informações sobre cultivares .........42
QUADRO 8 - Requisito funcional F6 – Manter informações sobre clones ..............42
QUADRO 9 - Requisito funcional F7 – Manter informações sobre
funcionários ........................................................................................42
QUADRO 10 - Requisito funcional F8 – Manter informações sobre
implementos......................................................................................42
QUADRO 11 - Requisito funcional F9 – Manter informações sobre tipos de
materiais............................................................................................42
QUADRO 12 - Requisito funcional F10 – Manter informações sobre subtipos de
materiais............................................................................................43
QUADRO 13 - Requisito funcional F11 – Manter informações sobre
materiais............................................................................................43
QUADRO 14 - Requisito funcional F12 – Manter informações sobre
veículos .............................................................................................43
QUADRO 15 - Requisito funcional F13 – Manter informações sobre tipos de
máquinas ...........................................................................................43
QUADRO 16 - Requisito funcional F14 – Manter informações sobre
máquinas ...........................................................................................43
QUADRO 17 - Requisito funcional F15 – Manter informações sobre safras ...........43
QUADRO 18 - Requisito funcional F16 – Manter informações sobre tipos de
atividades ..........................................................................................44
QUADRO 19 - Requisito funcional F17 – Manter informações sobre pragas ..........44
QUADRO 20 - Requisito funcional F18 – Manter informações sobre
atividades ..........................................................................................44
QUADRO 21 - Requisito funcional F19 – Manter informações sobre atividades
dos funcionários ................................................................................44
QUADRO 22 - Requisito funcional F20 – Manter informações sobre a utilização
de veículos ........................................................................................45
QUADRO 23 - Requisito funcional F21 – Manter informações sobre a utilização
de máquinas ......................................................................................45
QUADRO 24 - Requisito funcional F22 – Manter informações sobre abastecimentos
de máquinas. .....................................................................................45
QUADRO 25 - Requisito funcional F23 – Manter informações sobre abastecimento
de veículos. .......................................................................................45
QUADRO 26 - Requisito funcional F24 – Manter informações sobre materiais
utilizados. ..........................................................................................45
QUADRO 27 - Requisito funcional F25 – Manter informações sobre insumos
utilizados. ..........................................................................................46
QUADRO 28 - Requisito funcional F27 – Transferir dados da empresa para o
PDA. .................................................................................................46
QUADRO 29 - Requisito funcional F28 – Transferir dados do PDA para a
empresa. ............................................................................................46
QUADRO 30 - Requisito funcional F28 – Efetuar cópia de segurança. ...................47
QUADRO 31 - Requisitos suplementares para o módulo PDA. ...............................47
QUADRO 32 - Requisitos suplementares para o módulo de comunicação. .............47
QUADRO 33 - Casos de Uso do sistema ..................................................................48
QUADRO 34 - Conceitos do sistema ........................................................................49
QUADRO 35 - Expansão do caso de uso UC1 – Atribuir atividades aos
funcionários ......................................................................................51
QUADRO 36 - Expansão do caso de uso UC2 – Encerrar atividade dos
funcionários ......................................................................................52
QUADRO 37 - Estrutura de camadas do sistema ......................................................60
QUADRO 38 - Código fonte da classe UnidadeNegocio ..........................................62
QUADRO 39 - Código fonte da classe (web service) ServicoRetornaDados ...........64
QUADRO 40 - Código fonte da classe Conexao I ....................................................65
QUADRO 41 - Código fonte da classe Conexao II ...................................................67
QUADRO 42 - Arquivo xml de configuração da conexão com banco de dados
Firebird .............................................................................................68
QUADRO 43 - Código fonte da classe ControleUnidadeNegocio ...........................68
QUADRO 44 - Classe RecebeDados do aplicativo para PDA do módulo de
comunicação .....................................................................................71
QUADRO 45 - Método de inserção de dados na tabela UnidadeNegocio do
PDA ..................................................................................................73
QUADRO 46 - Método que retorna todos os abastecimentos de veículos
armazenados no PDA .......................................................................74
QUADRO 47 - Código fonte do método para o envio dos dados ao web service
receptor .............................................................................................75
QUADRO 48 - Método que insere os abastecimentos de veículos no banco
de dados da empresa .........................................................................77
QUADRO 49 - Método inserirAbastecimentoVeiculo do web service
ServicoRecebeDados ........................................................................78
QUADRO 50 - Método retornaAbastecimentoVeiculo da classe
ControleAbastecimentoVeiculo ........................................................81
QUADRO 51 - Código fonte das ações dos botões da interface principal de
cadastro. ............................................................................................82
QUADRO 52 - Thread que efetua a busca de dados essenciais para o
cadastro. ............................................................................................84
QUADRO 53 - Código fonte do formulário de inserção e alteração de
abastecimento de veículo I ...............................................................85
QUADRO 54 - Código fonte do formulário de inserção e alteração de
abastecimento de veículo II ..............................................................87
QUADRO 55 - Código fonte da criação da cópia de segurança ................................90
QUADRO 56 - Código fonte para a recuperação da cópia de segurança ..................90
LISTA DE ABREVIATURAS E SIGLAS
ARM
DLL
GPS
HP
IBGE
IDE
IIS
ISAM
JME
MOS
MVC
PDA
PU
RISC
RPC
RUP
SDK
SGBD
SOAP
SQL
UC
XML
- Advanced RISC Machine
- Dynamic link library
- Global Position System
- Hewlett-Packard
- Instituto Brasileiro de Geografía e Estatística
- Integrated Development Environment
- Internet Information Service
- Infra-estrutura de Suporte às Aplicações Móveis
- Java Micro Edition
- Machine Operating System
- Model View Controller
- Personal Digital Assistant
- Processo Unificado
- Reduced Instruction Set Computer
- Remote Procedure Call
- Rational Unified Process
- Software Development Kit
- Sistema Gerenciador de Banco de Dados
- Simple Object Access Protocol
- Structured Query Language
- Use Case
- Extensible Markup Language
RESUMO
Em muitos negócios é fundamental coletar dados, seja explicita ou implicitamente,
para tomar decisões. Com o avanço da tecnologia da computação móvel, antigos
sistemas, como a coleta e armazenamento em papel, vem sendo substituídos pela
coleta com computadores móveis, como: notebooks, Assistentes Pessoais Digitais,
celulares etc., pois a coleta manual pode ocasionar diversos contratempos, como a
perda de dados, rasuras ou até mesmo mau preenchimento de planilhas, por exemplo.
Existem diversos sistemas para a coleta de dados em dispositivos móveis, mas na
grande maioria são sistemas proprietários e desenvolvidos para usuários específicos,
não podendo ser aproveitados por outros usuários potenciais. Levando em conta este
contexto, apresenta-se o desenvolvimento de um sistema para coleta de dados baseado
em dispositivos móveis para uma empresa do ramo de frutas utilizar em suas diversas
fazendas. Tal sistema deve possibilitar ao usuário coletar, armazenar e transmitir os
dados registrados a um banco de dados central. Através de estudos verificou-se a
possibilidade de desenvolvimento em diversas linguagens de programação, sendo a
linguagem C# com a ferramenta Visual Studio escolhida, por se tratar de uma
ferramenta com diversas funcionalidades e de grande eficácia, que possibilitam o
desenvolvimento do sistema proposto. Além dos aplicativos para dispositivos móveis,
também se tem o desenvolvimento de serviços web para fazer a transferência de dados
entre o dispositivo móvel e o banco de dados da empresa. Todo o sistema é
desenvolvido seguindo o padrão MVC, sendo assim, tem-se um projeto com códigos e
bibliotecas bem organizados e com a possibilidade de reutilização destes em todo o
projeto.
Palavras-chave:
Aplicativos para Dispositivos Móveis; Assistente Pessoal Digital; Serviço Web; Coleta
e Transmissão de Dados; Empresas Produtoras de Frutas.
ABSTRACT
In many businesses is crucial to do the data collection, it can be explicitly or
implicitly, to make decisions. With the advance of mobile computing technology, old
systems like the collection and storage of data in paper, has been replaced by the
collection with mobile computers, form example: notebooks, Personal Digital
Assistant, cellphones etc., because the manual collection can causes various problems
like the loss of data, erasure or even bad fill in spreadsheets for example. There are
several systems for data collection on mobile devices, but mostly proprietary systems
and designed for specific users and can’t be used by other potential users. Considering
this context, it’s showing a system for data collection based on mobile devices for a
company in the industry of fruit use in its various farms. The system should possibilty
the user to collect, store and transmit data to a central database. With studies it could
be certified that there was the possibility of development in various programming
languages, and the language C# with Visual Studio tool was chosen because it is a tool
with multiple functions and high-efficiency, that possibility the development of the
proposed system. In addition to the applications for mobile devices, also has been the
development of web services to make the data transfer between the mobile device and
the company's databases. The whole system is developed following the MVC pattern,
so it causes that the codes and libraries are well-organized and the possibility of reuse
them in the project.
Keywords:
Applications for Mobile Devices; Personal Digital Assistant; Web Service; Collection
and Transmission of Data; Companies that Produce Fruit.
SUMÁRIO
1 INTRODUÇÃO ........................................................................................................13
1.1 Apresentação ...........................................................................................................13
1.2 Descrição do problema ............................................................................................14
1.3 Justificativa ..............................................................................................................15
1.4 Objetivo geral ..........................................................................................................16
1.5 Objetivos específicos ...............................................................................................16
1.6 Metodologia .............................................................................................................16
2 COMPUTAÇÃO MÓVEL ......................................................................................18
2.1 Histórico ..................................................................................................................18
2.2 PDA .........................................................................................................................20
2.3 Linguagens e ferramentas de desenvolvimento.......................................................23
2.3.1 Visual Studio .................................................................................................................... 24
2.3.2 NetBeans IDE .................................................................................................................. 27
2.3.3 PDAToolBox .................................................................................................................... 28
2.3.4 Outras ferramentas de desenvolvimento ......................................................................... 29
2.3.5 Microsoft SQL Server Mobile .......................................................................................... 30
2.3.6 Análise das ferramentas .................................................................................................. 31
2.4 Modelos de PDA .....................................................................................................32
2.4.1 Palm ................................................................................................................................. 32
2.4.2 HP (Hewlett-Packard) ..................................................................................................... 32
2.4.3 Comparativo entre modelos ............................................................................................ 33
2.5 Conclusão ................................................................................................................34
3 ANÁLISE E PROJETO DO SISTEMA .................................................................36
3.1 Processo Unificado de desenvolvimento de software .............................................36
3.2 Concepção ...............................................................................................................37
3.2.1 Modelo atual de coleta de dados da empresa alvo do sistema ....................................... 39
3.2.2 Sumário executivo ........................................................................................................... 40
3.2.3 Levantamento de requisitos ............................................................................................. 40
3.2.4 Organização dos requisitos em casos de uso .................................................................. 47
3.2.5 Organização dos requisitos em função de conceitos....................................................... 48
3.3 Elaboração ...............................................................................................................49
3.3.1 Expansão dos casos de uso.............................................................................................. 50
3.3.2 Modelo conceitual ........................................................................................................... 52
3.3.3 Diagrama de classe ......................................................................................................... 53
3.3.4 Diagrama de estado de navegação ................................................................................. 53
3.4 Conclusão ................................................................................................................54
4 IMPLEMENTAÇÃO DO SISTEMA .....................................................................55
4.1 Web service ..............................................................................................................55
4.2 Arquitetura do sistema .............................................................................................58
4.3 Camada de modelo ..................................................................................................61
4.4 Módulo de comunicação..........................................................................................63
4.4.1 Web service provedor dos dados ..................................................................................... 63
4.4.2 Recepção dos dados no PDA ........................................................................................... 70
4.4.3 Envio dos dados do PDA ................................................................................................. 74
4.4.4 Recepção e inserção dos dados no servidor.................................................................... 77
4.5 Módulo de coleta de dados ......................................................................................79
4.5.1 Designar unidade de negócio .......................................................................................... 79
4.5.2 Coleta dos dados ............................................................................................................. 80
4.5.3 Cópia de segurança ......................................................................................................... 89
4.6 Conclusão ................................................................................................................91
5 APRESENTAÇÃO DO SISTEMA .........................................................................92
5.1 Módulo de comunicação..........................................................................................92
5.1.1 Web service provedor de dados ....................................................................................... 92
5.1.2 Web service receptor de dados ........................................................................................ 95
5.1.3 Aplicativo de comunicação no PDA ................................................................................ 97
5.2 Módulo de coleta de dados ....................................................................................101
5.2.1 Designar unidade de negócio ........................................................................................ 101
5.2.2 Coleta de dados ............................................................................................................. 102
5.2.3 Cópia de segurança ....................................................................................................... 107
5.3 Conclusão ..............................................................................................................109
6 CONSIDERAÇÕES FINAIS .................................................................................110
REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................113
BIBLIOGRAFIA COMPLEMENTAR ...................................................................116
APÊNDICES ..............................................................................................................117
ANEXOS.....................................................................................................................133
13
1 INTRODUÇÃO
1.1 Apresentação
A informática tem, cada vez mais, tomado conta do universo dos negócios e
as empresas sentem a necessidade de informatizarem suas atividades para não
perderem clientes e mercado. Em um mundo de extrema concorrência como o atual,
saem na frente as empresas com um sistema de informação baseado em computadores
(LAUDON e LAUDON, 1999).
Nesse universo da informação, uma tecnologia que está em pleno
crescimento é a dos dispositivos móveis. Celulares, computadores portáteis e
computadores de mão estão desempenhando funções que antes dependiam de vários
funcionários ou, quando informatizados, de uma máquina de grande porte e sem
nenhuma mobilidade.
A utilização específica de computadores de mão, conhecidos pela sigla PDA
(Personal Digital Assistant) não é mais uma novidade. Muitas empresas que
necessitam de dados descentralizados, como, por exemplo, os pedidos de compra de
seus clientes, têm nesse tipo de computador a solução ideal de informatização, pois
torna prático o processo de venda.
Outro exemplo, no qual se enquadra esse trabalho, é o de uma empresa com
vários setores e um fluxo grande de informações distribuídas entre estes. Nesse caso, o
PDA pode ser de grande utilidade na coleta, tratamento e atualização destas
informações.
A empresa que serve como cenário para o trabalho em questão atua com
14
produção de frutas em diversos municípios da Serra Catarinense, tais como: São
Joaquim, Painel e Lages. Ela possui um grande fluxo de atividades em diferentes
setores e unidades de produção, o que implica na necessidade de coleta de dados
descentralizados. Todas as funcionalidades do sistema proposto são baseadas nas
necessidades específicas desta empresa, cujo nome é omitido ao longo do trabalho por
solicitação da mesma.
O primeiro capítulo deste trabalho apresenta uma introdução ao tema
abordado, juntamente com a definição do problema, objetivos, justificativa e
metodologia utilizada. No segundo capítulo é abordado um estudo sobre os
computadores de mão (PDA) existentes no mercado, bem como as ferramentas de
desenvolvimento para os mesmos. O terceiro capítulo apresenta a modelagem do
sistema desenvolvido. O quarto capítulo mostra a implementação do sistema e no
quinto capítulo é feita uma apresentação do mesmo após concluída a implementação.
Finalizando o trabalho de conclusão de curso, são apresentadas as considerações finais
no sexto capítulo.
1.2 Descrição do problema
Uma empresa que atua na produção de frutas em diversos municípios da
Serra Catarinense tem um grande fluxo de atividades em diferentes setores e unidades
de produção. Os dados oriundos destas atividades são centralizados em um único
banco de dados na matriz. Ela utiliza planilhas em papel, que os gerentes de cada
unidade de produção preenchem com os dados necessários e encaminham ao setor de
informática para serem digitados. Esse processo, além do tempo demandado, pode
causar diversos contratempos, como, por exemplo, a perda de uma dessas planilhas, a
digitação incorreta dos dados ou, até mesmo, o preenchimento incorreto, uma vez que
não há nenhuma ferramenta capaz de analisar os dados manuscritos.
15
1.3 Justificativa
É comum, ainda hoje, que sistemas antigos, tais como planilhas, controles e
relatórios em papel, sejam utilizados nas empresas. Porém, estes estão se tornando
cada vez mais defasados devido ao avanço das tecnologias, o crescimento da
concorrência em todas as áreas de trabalho e a preocupação com o meio ambiente.
Ainda, surge neste cenário uma série de dificuldades que as empresas encontram na
sua administração, que engloba desde a simples perda de um relatório até uma tomada
de decisão errada, que pode acarretar em grandes prejuízos em um determinado
negócio.
É uma necessidade que as empresas se adaptem às novas tecnologias e à
utilização de sistemas de informação, pois todas estão passando por um momento de
extrema concorrência por recursos de toda ordem, como fornecedores, clientes,
matéria prima e tecnologia (LAUDON e LAUDON, 1999).
A empresa em questão geralmente tem vários problemas com a utilização
dos métodos atuais, pois utiliza planilhas para o controle de suas unidades e centraliza
as informações mensalmente em um único banco de dados. As falhas são diversas,
entre elas estão a perda de planilhas e o mau preenchimento das mesmas, pois uma
planilha preenchida de forma errada no início do mês pode acarretar em erros no
momento da digitação.
Além dos problemas administrativos, a empresa também enfrenta problemas
de ordem financeira com a compra de papel e os prejuízos causados pelas falhas supra
citadas.
Uma possível solução consiste na informatização do sistema de coleta de
dados, utilizando computadores de mão. Assim, a empresa pode solucionar boa parte
dos problemas, pois esse tipo de sistema tem condições de fazer uma crítica simultânea
ao preenchimento, o que soluciona os erros ocorridos nessa etapa. Somam-se a isso as
facilidades que o sistema gera, como a atualização no banco de dados com uma
temporalidade menor que a atual, que é de um mês, facilitando e agilizando a tomada
de decisão e, conseqüentemente, melhorando a administração da empresa.
16
1.4 Objetivo geral
Desenvolver um sistema de informação para uma empresa utilizar na coleta,
tratamento e armazenamento de dados de suas diversas unidades, com um módulo
baseado em computadores de mão para realizar a coleta dos dados, bem como um
módulo responsável para fazer a comunicação entre o módulo supra citado com o
banco de dados da empresa.
1.5 Objetivos específicos
Para este trabalho, têm-se como objetivos específicos:
a) Fazer um levantamento dos modelos e características dos computadores
de mão disponíveis no mercado, a fim de auxiliar na escolha de tal
dispositivo para a implantação do sistema a ser desenvolvido;
b) Desenvolver um aplicativo para computadores de mão, para ser utilizado
na coleta, tratamento, armazenamento e exportação de dados;
c) Desenvolver um aplicativo, que possa ser acessado via Internet, para
receber os dados oriundos dos computadores de mão e inseri-los em um
banco de dados.
1.6 Metodologia
Neste trabalho foi desenvolvido um sistema de informação para a coleta de
dados, com um módulo baseado em computadores de mão, bem como um módulo
responsável por fazer a transferência dos dados coletados ao banco de dados de uma
empresa que atua no ramo de produção de frutas.
No início do trabalho realizou-se um levantamento a respeito dos
computadores de mão, os modelos disponíveis no mercado, as características e os
custos. Também foi feito um levantamento das ferramentas de desenvolvimento de
aplicativos para esse tipo de computador. Para essa atividade foram utilizados como
17
fonte de pesquisa artigos, revistas, websites, trabalhos científicos e livros, resultando
no capítulo dois.
O próximo passo foi a modelagem do sistema baseado em módulos, que foi
feita segundo o Processo Unificado. Essa fase do trabalho resultou no capítulo três.
Após a modelagem, o passo seguinte foi o desenvolvimento do sistema. Para
a programação dos aplicativos baseados em computadores de mão foi utilizada a
linguagem C# e a ferramenta Visual Studio 2005. O banco de dados foi desenvolvido
com o Microsoft SQL Server 2005 Mobile Edition. Para o módulo de transferência dos
dados também foi utilizada a linguam C# e a ferramenta Visual Studio 2005, porém
esse módulo foi desenvolvido com a utilização do Firebird como sistema gerenciador
de banco de dados, pois é nesse sistema que está o banco de dados atual da empresa.
Essa etapa do trabalho resultou no capítulo quatro.
Ao final do capítulo quatro, foram realizados testes para comprovar o
funcionamento dos módulos desenvolvidos, tanto para a coleta como para a
transferência dos dados, resultando no capítulo cinco deste trabalho.
Por fim, no capítulo seis, são apresentadas as considerações finais do
trabalho.
18
2 COMPUTAÇÃO MÓVEL
Neste capítulo são apresentados conceitos básicos sobre computação móvel e
seus equipamentos. Em seguida, apresenta-se um levantamento mais detalhado sobre o
Assistente Digital Pessoal (PDA – Personal Digital Assistant), que é o dispositivo
móvel utilizado neste trabalho, especificando os modelos existentes, características e
preços, bem como as ferramentas e linguagens de programação disponíveis para esse
tipo de equipamento.
2.1 Histórico
Com o avanço da tecnologia e a necessidade cada vez maior de acesso
contínuo a dados, tem-se um cenário evolutivo de comunicação entre dispositivos
móveis com bancos de dados e redes fixas, bem como com outros dispositivos móveis
(MATEUS e LOUREIRO, 1998, p. 1). Nesse cenário encontra-se a computação
móvel, que, conforme ISAM (2008), é “a computação onde todos os elementos do
sistema têm a propriedade de mobilidade”.
Pode-se, então, definir computação móvel como um paradigma de
computação em que os elementos têm a propriedade de mobilidade, bem como a
possibilidade de conexão com outros elementos, sejam eles fixos ou móveis.
Esse paradigma traz algumas vantagens aos usuários, como: a mobilidade na
utilização de componentes computacionais; a disponibilidade de uma gama enorme de
aplicativos em um só aparelho que pode ser utilizado de inúmeras formas; a
substituição de sistemas antecessores, como o armazenamento em papel (utilização de
planilhas, agendas, cadernos), evitando a perda de dados por extravio ou avarias; e, a
19
facilidadade de comunicação, seja entre pessoas ou dispositivos (ZENI et al., 2004, p.
1).
Assim como a computação móvel oferece vantagens, também apresenta
desvantagens, como: possibilidade de perda de dados por falhas nos aplicativos ou
pelo extravio dos equipamentos; dificuldade que o usuário pode ter em digitar os
dados devido aos teclados serem virtuais ou pequenos; e, principalmente, limitações de
memória impostas pelos dispositivos (ZENI et al., 2004, p. 1).
A computação móvel é considerada como uma nova revolução da
informática e dos meios de comunicação, como os grandes centros de processamento
dos anos sessenta, o surgimento de terminais nos anos setenta e a evolução das redes
de computadores nos anos oitenta (MATEUS e LOUREIRO, 1998, p. 1).
Como toda revolução tecnológica, ela vem acompanhada de uma enorme
gama de dispositivos, que vão desde os computadores portateis (notebooks) até os
sistemas embarcados. Dentre esses dispositivos pode-se destacar:
• PDA
(Personal
Digital
Assistant):
Computador
de
mão
com
características muito parecidas com as de um computador de mesa, porém
com grandes limitações com relação a esse;
• Celular: Telefone móvel com diversas ferramentas que tem como
objetivo facilitar a comunicação entre os usuários, possibilita o envio de
mensagens, além de possuir aplicativos de organização pessoal;
• Smartphone: Pode ser definido como uma junção do celular com o PDA,
pois possui todas as características do telefone, aliadas às funcionalidades
de um PDA;
• Leitor de livros: Dispositivo eletrônico que tem por objetivo o
armazenamento e visualização de livros em formato digital.
A seguir, trata-se com mais profundidade sobre PDA, que é o objetivo deste
capítulo.
20
2.2 PDA
O Assistente Pessoal Digital, conhecido pela sigla em inglês PDA (Personal
Digital Assistant), é um dispositivo móvel com características similares às de um
computador de mesa, pois possibilita ao usuário executar várias funções que há tempos
atrás não eram possíveis sem que se estivesse em frente a um microcomputador. A
figura 1 mostra um PDA.
FIGURA 1 - PDA com o sistema operacional Pocket PC da Microsoft.
(Fonte: SOCRIA.NET, 2008)
Equipamentos portáteis ou ao menos transportáveis existem desde a década
de 80. Em 1981, Adam Osborne lançou o primeiro computador portátil que se tem
notícia, o Osborne-1, que pode ser visto na figura 2. Tempos depois, também lançado
pela Osborne, surge o IBM-PC, que pode ser visto na figura 3.
FIGURA 2 - Osborne 1
(Fonte: ALVES, 2002, p. 20).
21
FIGURA 3 - IBM-PC
(Fonte: ALVES, 2002, p. 20).
O primeiro dispositivo com característica realmente móvel que surgiu foi o
Epson HX-20, que tinha um hardware muito limitado e a tela pequena dificultava a
apresentação dos aplicativos, como pode ser visto na figura 4 (ALVES, 2002, p. 1922).
FIGURA 4 - Epson HX-20
(Fonte: ALVES, 2002, p. 21).
Nos anos 90, a Apple lançou o primeiro PDA do mundo, o Newton, que não
foi um grande sucesso de vendas. Em 1992 nasce a Palm Inc., adquirida em 1995 pela
US Robotics, que lançou os primeiros Palmtops (PDA) que realmente fizeram sucesso,
são eles: o Pilot 1000 e o Pilot 5000. Em 1997, a 3Com adquiriu a US Robotics e, a
partir desse ano, o mercado teve uma expansão gigantesca (TROIS, 2003, p. 1).
A Microsoft entrou nesse mercado lançando uma versão do Windows para
computadores móveis, denominada Windows CE, e a ofereceu aos fabricantes, fazendo
com que logo surgissem PDA e Handled PC com esse sistema (ALVES, 2002, p. 23).
Hoje, a Microsoft disponibiliza o Windows Mobile, que é uma versão aperfeiçoada do
Windows CE, utilizado tanto em PDA, quanto em telefones celulares.
Com essa diversidade de dispositivos, cresce cada vez mais o número de
22
aplicativos móveis no mercado, muitos deles disponíveis nos próprios sistemas
operacionais, como, por exemplo, o Windows Mobile, que traz aplicativos clássicos da
Microsoft, como o Word, Excel e alguns jogos, que vêm acompanhando a série
Windows para desktop desde a sua criação. O sistema operacional da Palm também
traz muitos aplicativos, como calculadora, editor de memorandos, leitor de e-mails e
um to-do list (lista de afazeres).
Além dos aplicativos disponibilizados juntamente com os sistemas
operacionais, também existem vários outros de uso comercial e exclusivos, como
sistemas de vendas, pesquisas e coleta de dados. Pode-se citar o aplicativo utilizado
pelo IBGE (Instituto Brasileiro de Geografia e Estatística) no censo agropecuário do
ano de 2007. Nesse caso, o uso do PDA trouxe várias vantagens em relação ao método
anterior de coleta utilizado pelo Instituto, como, por exemplo, a crítica imediata no
momento em que os dados eram coletados, o preenchimento de todos os quesitos
obrigatórios e a dispensa do transporte de grandes volumes de questionários em papel
(IBGE, 2008, p. 34).
Na atualidade, existem dois sistemas operacionais que se destacam no
mundo dos PDA: o Palm OS e o Windows Mobile. Existem ainda outros sistema
operacionais, como o Linux e os sistema da Apple, porém é inegável que os mais
utilizados sejam os primeiros citados, conforme visto em Criarweb (2008):
Embora existam outras alternativas, como a possibilidade de instalar Linux,
o que é certo é que a batalha no mercado dos PDA se trava atualmente entre
o tradicional Palm OS e o irmão caçula do Windows, Windows CE ou
Windows Mobile.
O Palm OS é um sistema operacional embarcado e compatível com
processadores ARM (Advanced RISC Machine), esses processadores possuem uma
arquitetura tipicamente RISC (Reduced Instruction Set Computer), desenvolvida pela
Arcon Computers, a qual é baseada no MOS (Machine Operating System) Technology
6502 e no Berkeley RISC 1, a partir da versão 5.0, e bastante otimizado para
dispositivos com pouca memória e display pequeno (LOPES, 2006, p. 20-25).
O Windows Mobile é um sistema operacional criado pela Microsoft, que
23
conta com o Windows Office Mobile Edition, além de uma gama de aplicativos da
empresa, como o Outlook para a leitura de e-mails. Até a versão 5.0 existiam três
categorias desse sistema (SILVA, 2007):
• Windows Mobile 2003/5.0 for Pocket PC: Utilizado em equipamentos
com características de organizadores pessoais;
• Windows Mobile 2003/5.0 for Pocket PC Phone Edition: Tem as mesmas
características do primeiro, acrescido de uma opção de comunicação de
dados e voz sobre GSM/GPRS/3G;
• Windows Mobile 2003/5.0 for SmartPhone: Sistema que se adéqua a uma
utilização intensiva de telefone e com algumas características de
organizador pessoal.
A partir da versão 6.0, a nomenclatura deu lugar respectivamente à (SILVA,
2007):
• Windows Mobile 6 Classic, equivalente ao Windows Mobile 2003/5.0 for
Pocket PC.
• Windows Mobile 6 Professional, equivalente ao Windows Mobile
2003/5.0 for Pocket PC Phone Edition.
• Windos Mobile 6 Standard, equivalente ao Windows Mobile 2003/5.0 for
SmartPhone.
2.3 Linguagens e ferramentas de desenvolvimento
Apesar de os computadores de mão serem uma realidade recente, existem
inúmeras linguagens e ferramentas de desenvolvimento para esse tipo de dispositivo
(SOUZA, 2004, p. 24). Algumas linguagens são utilizadas no desenvolvimento para
PDA, bem como no desenvolvimento de aplicações para computadores de mesa. Essas
linguagens têm comandos e sintaxe básica iguais, porém existem algumas restrições
ocasionadas pela diferença dos tipos de hardware. Dentre outras linguagens destacamse: C++; Java; Pascal; C#; Visual Basic.
24
Existem, ainda, algumas linguagens de programação específicas para
dispositivos móveis, é o caso do SuperWaba que, segundo Pereira (2008, p. 2):
...é uma plataforma que possui uma implementação própria de linguagem
(com sintaxe semelhante ao Java), máquina virtual, formato de arquivos de
classes e um conjunto de classes. Além disso, ele permite o uso de
ferramentas Java no desenvolvimento. Dentre as diversas características,
podemos notar o suporte para SQL, leitor de código de barras, protocolo
GPS, protocolo HTTP, tratamento de imagens JPEG, GIF e PNG, e suporte
para compressão de dados.
Além das linguagens de desenvovimento, tem-se no mercado inúmeras
ferramentas que auxiliam o desenvolvedor. Essas ferramentas, em sua grande maioria,
auxiliam na elaboração do código fonte de um aplicativo através de interfaces gráficas.
Por meio destas interfaces é possível, por exemplo, arrastar uma caixa de texto para
um formulário, ficando a ferramenta encarregada de gerar o código para essa ação.
Existem ferramentas de acesso livre, outras com custos baixos e outras com custos
bastante elevados, que dão suporte a uma ou mais liguagens de programação. Dessa
maneira, o desenvolvedor pode escolher a que melhor se adéqua às suas necessidades e
possibilidades. A seguir são apresentadas algumas delas.
2.3.1 Visual Studio
O Visual Studio é uma IDE (Integrated Development Environment) para a
plataforma .NET, projetado pela Microsoft. Ele é proprietário e tem suporte nativo a
quatro linguagens de programação, são elas: Visual Basic; Visual C#; Visual J#; e
Visual C++. A figura 5 apresenta a tela inicial do Visual Studio, a partir do qual é
possível desenvolver sistemas para web, computadores de mesa (figura 6), dispositivos
móveis (figura 7), além de sistemas para servidores, como web services.
Com o .Net é possível desenvolver aplicativos para qualquer sistema
operacional. Como pode ser visto em MSDN (2008a): “Do ponto de vista dos
programadores, o ‘.NET Framework’ é o sistema operacional. É através dele que são
invocadas todas as funções necessárias ao funcionamento dos programas, sob qualquer
sistema operacional”.
25
Para o desenvolvedor ter a possibilidade de testar aplicações feitas para
dispositivos móveis no Visual Studio, sem que haja a necessidade de possuir tal
dispositivo, a Microsoft disponibiliza de forma integrada com o sistema uma variedade
de emuladores, como pode ser visto na figura 8.
FIGURA 5 - Tela inicial do Visual Studio 2005.
FIGURA 6 - Desenv. de um sistema para computador de mesa no Visual Studio 2005
26
FIGURA 7 - Desenvolvimento de uma aplicação para PDA no Visual Studio 2005
FIGURA 8 - Emuladores da Microsoft incluídos no Visual Studio 2005
27
2.3.2 NetBeans IDE
A IDE NetBeans é uma ferramenta de desenvolvimento gratuita e open
source que permite escrever, compilar, depurar e instalar programas. A IDE é
completamente escrita em Java e voltada para essa plataforma, porém, também pode
suportar outras linguagens de programação (NETBEANS, 2008).
Por ser uma IDE multiplataforma, os aplicativos desenvolvidos com o
NetBeans na linguagem Java podem rodar em qualquer sistema operacional ou
dispositivo, desde que esse tenha a máquina virtual Java instalada. Com o NetBeans
também é possível o desenvolvimento de aplicativos para dispositivos móveis,
utilizando a extensão JME (Java Micro Edition) e um emulador da máquina virtual
para testar as aplicações (figuras 9 e 10).
FIGURA 9 - Ambiente de desenvolvimento de aplicativos móveis no NetBeans
28
FIGURA 10 - Emulador do NetBeans em execução
2.3.3 PDAToolBox
O PDAToolBox é um sistema que possibilita o desenvolvimento de
aplicativos que rodam no sistema operacional Palm OS sem que o desenvolvedor
precise ter um profundo conhecimento em linguagens de programação, pois funciona
no modo visual - arrastar e soltar. O PDAToolBox é uma ferramenta proprietária,
porém é possível instalar uma versão que funciona por trinta dias gratuitamente
(TROIS, 2003, p. 23).
Com essa ferramenta é possível criar programas apenas para o sistema
operacional Palm OS. Com ela não é possível, por exemplo, criar aplicativos para o
Windows Mobile ou qualquer outro sistema operacional. Na figura 11 é mostrado o
ambiente de desenvolvimento do PDAToolBox.
29
FIGURA 11 - Ambiente de desenvolvimento do PDAToolBox
2.3.4 Outras ferramentas de desenvolvimento
Existem, ainda, inúmeras ferramentas de desenvolvimento específicas para
PDA, como as citadas a seguir:
• PocketStudio: Ferramenta proprietária, com uma interface semelhante à
do Delphi e também baseada na linguagem Pascal (ALVES, 2002, p. 95);
• CodeWarrior: É uma ferramenta de desenvolvimento para Palm muito
utilizada pelos programadores, por ser baseada na linguagem C/C++ é
bastante poderosa (ALVES, 2002, p. 69);
• DeveloperStudio: É uma ferramenta de desenvolvimento para Palm que
contém um ambiente de trabalho integrado, composto por um editor de
texto, bem como um editor de tabelas. É baseada nas linguagens C/C++
(ALVES, 2002, p. 81).
30
No início da era mobile utilizavam-se mais as ferramentas de
desenvolvimento específico para esse tipo de dispositivo, como é o caso do
PDAToolBox, PocketStudio e CodeWarrior, por exemplo. Atualmente, as ferramentas
mais genéricas, como o Visual Studio e NetBeans, que servem tanto para o
desenvolvimento mobile como para não mobile, estão em maior evidência.
2.3.5 Microsoft SQL Server Mobile
O Microsoft SQL Server Mobile é uma versão do conhecido sistema
gerenciador de banco de dados da Microsoft específica para ser utilizado em
dispositivos móveis, que proporciona aos usuários e desenvolvedores grandes
vantagens na sua utilização. Segundo Schaal (2005, p. 9), “Bancos de dados ou
porções de bancos de dados podem ser facilmente sincronizados para computadores
móveis para que os funcionários possam ainda se beneficiar do acesso aos dados
corporativos quanto estiverem fora”. Já em Microsoft (2008) se faz referência à
integração com outras ferramentas de desenvolvimento da Microsoft:
A integração total do SQL Server 2005 Mobile Edition com o SQL Server
2005 e o Visual Studio 2005 fornece uma plataforma para desenvolvedores
construírem rapidamente aplicações que estendem o gerenciamento de dados
corporativos aos dispositivos móveis.
Também é
disponibilizado gratuitamente
o software SQL Server
Management Studio Express, no qual o desenvolvedor encontra uma interface de
desenvolvimento facilitada, que, em muitos casos, dispensa o uso da linguagem SQL
(Structured Query Language) na criação de um banco de dados, pois o software monta
o código SQL a partir dos diagramas. Na figura 12 é apresentado o ambiente de
desenvolvimento do SQL Server Management Studio Express.
31
FIGURA 12 - Ambiente de desenvolvimento do SQL Server Management Studio Express
2.3.6 Análise das ferramentas
Dentre todas as ferramentas disponíveis no mercado, optou-se para o
desenvolvimento deste trabalho por uma do tipo genérica, ou seja, que serve para
desenvolver sistemas em diversas plataformas (Mobile, Web, Desktop). O quadro 1
mostra um resumo das ferramentas apresentadas neste capítulo.
QUADRO 1 - Comparativo entre ferramentas de desenvolvimento
Ferramenta
NetBeans
Linguagens nativas
de desenvolvimento
Visual basic, C#,
C/C++, J#
Java
PDAToolBox
PocketStudio
CodeWarrior
DeveloperStudio
Modo visual
Pascal
C/C++
C/C++
Visual Studio
Dispositivos
Móveis
Windows Mobile /
Palm OS
Windows Mobile /
Palm OS
Palm OS
Palm OS
Palm OS
Palm OS
Outras Plataformas
Gratuita
Sim
Não
Sim
Sim
Não
Não
Sim
Não
Não
Não
Não
Não
A ferramenta Visual Studio tem um ambiente de desenvolvimento para
32
disposítivos móveis muito amplo, principalmente com o sistema operacional Windows
Mobile, utilizando a plataforma .NET, além de contar com suporte ao sistema
gerenciador de banco de dados Microsoft SQL Server Mobile. Aliado a essas
características favoráveis para este trabalho, tem-se o interesse por parte do autor em
aprofundar seus conhecimentos nessa ferramenta.
Analisadas todas as características supra citadas, escolheu-se para o
desenvolvimento do sistema alvo deste trabalho a ferramenta Visual Studio 2005.
2.4 Modelos de PDA
Destacam-se no mercado de PDA, atualmente, duas plataformas que acabam
dividindo os fabricantes destes dispositivos: o Palm OS e o Windows Mobile. Existem,
também, outras plataformas, mas que não têm tanto destaque como as supra citadas. A
seguir são apresentadas algumas informações sobre os fabricantes e modelos de PDA
dessas duas plataformas.
Além da Palm e HP, também existem outros fabricantes de PDA no
mercado. Tem-se nesse cenário empressas como a Dell, Acer, Mio e Asus, que
disponibilizam dispositivos com diversas características.
2.4.1 Palm
A Palm é uma empresa de produtos móveis que tem como objetivo auxiliar
as pessoas no gerenciamento de sua vida pessoal (PALM, 2008).
A Palm trabalha atualmente com smartphones, PDA e acessórios. Tem como
sistema operacional de seus aparelhos o Palm OS e Windows Mobile em alguns
produtos, como é o caso dos modelos de smarthphones Treo 750 e Treo 700wx.
2.4.2 HP (Hewlett-Packard)
A Hewlett-Packard, conhecida em todo o mundo pela sigla HP, existe desde
o ano de 1939, quando iniciou seu trabalho com medidores elétricos e calculadoras. Na
33
década de oitenta fez grande sucesso no setor de impressoras e servidores, porém teve
que esperar até o final dos anos noventa para encontrar seu lugar no mercado de
computadores pessoal (CONHEÇA A HISTÓRIA DA HP, 2001).
Na linha dos computadores de mão, a HP trabalha com PDA, GPS (Global
Position System) e smartphones, na grande maioria com o sistema operacional
Windows Mobile. Dentre os modelos de PDA disponíveis à venda, pode-se destacar o
iPAQ 110 e o iPAQ 210.
2.4.3 Comparativo entre modelos
Como a quantidade e a variedade de equipamentos no mercado é muito
grande, ao escolher um PDA é necessário avaliar alguns requisitos, para que no final a
escolha seja coerente com as necessidades do usuário.
Podem ser definidos os seguintes requisitos básicos ao funcionamento e
custo/beneficio para comparar os diversos modelos existentes: processador; memória
total; armazenamento; existência de suporte às conexões bluetooth e wireless; tamanho
da tela; sistema operacional; suporte a cartão de expansão de memória e preço médio.
O quadro 2 mostra esse comparativo com modelos das empreas HP, Palm e Mio.
Dentre os modelos pesquisados, três não têm suporte a comunicação em rede
sem fio (wireless), são o Palm Z22, Palm Tungsten E2 e Mio P350, por esse motivo
foram descartados, uma vez que a conexão wireless é muito útil para dispositivos
móveis. Dos modelos restantes, o HP iPAQ 110 Classic Handhled, HP iPAQ 210
Enterprise Handhled e Mio P550 estão com o preço médio muito elevado. Restaram
os modelos Palm TX e HP iPAQ hx2400 que atingiram o mesmo preço médio de 1.100
reais.
O objetivo desse trabalho não é avaliar qual modelo de PDA é o melhor, mas
sim, identificar o mais adequado para a implantação do sistema em questão. Sendo
assim, foi escolhido para a implantação dos aplicativos mobiles do sistema o modelo
HP iPAQ hx2400, pois esse é equipado com o sistema operacional Windows Mobile
5.0, o que facilita o sincronismo com os demais computadores da empresa, que
trabalham com a plataforma Windows, sendo esse o modelo que apresenta melhor
34
custo/benefício para a implantação do sistema.
QUADRO 2 - Comparativo entre modelos de PDA
Modelo
Proces
sador
Memória total
Memória
para armaZenamento
Wireless
Bluetooth
Tela
Sistema
operacional
Palm Z22
200
Mhz
32Mb
20Mb
Não
Não
Colorida,
160x160
Palm
Tungsten
E2
Palm TX
200
Mhz
32Mb
26Mb
Não
Sim
Colorida
320x320
312
Mhz
128Mb
100Mb
Sim
Sim
Colorida
320x480
HP iPAQ
110
Classic
Handhled
HP iPAQ
210
Entreprise
Handhled
HP iPAQ
hx2400
624
Mhz
320Mb
64Mb
Sim
Sim
Colorida
240x320
Palm OS
Garnet
5.4
Palm OS
Garnet
5.4
Palm OS
Garnet
5.4
Windows
Mobile 6
Classic
624
Mhz
384Mb
128Mb
Sim
Sim
Colorida
640X480
520
Mhz
256Mb
64Mb
Sim
Sim
Colorida
240x320
Mio P350
400
Mhz
192Mb
64Mb
Não
Não
Colorida
240x320
Mio P550
400
Mhz
64Mb
Sim
Sim
Colorida
240x320
Cartão
de
expansão
Não
Preço
médio
R$
Sim
400,00
Sim
1.100,00
Sim
1.400,00
Windows
Mobile 6
Classic
Sim
2.400,00
Windows
Mobile
5.0
Windows
Mobile
5.0
Windows
Mobile
5.0
Sim
1.100,00
Sim
1.350,00
Sim
1.550,00
350,00
2.5 Conclusão
A elaboração deste capítulo teve grande importância no que diz respeito ao
aprendizado sobre dispositivos móveis, com ênfase maior em Assistente Pessoal
Digital, que é o dispositivo móvel usado neste trabalho. A pesquisa sobre PDA foi
fundamental, uma vez que através dela foi possível definir as ferramentas a serem
utilizadas no desenvolvimento do sistema, bem como seus requisitos e arquitetura, já
que nem todos os PDA são iguais e dão suporte às mesmas ferramentas e plataformas.
Outro fator importante é a pesquisa com relação às linguagens de
programação para o desenvolvimento de aplicações móveis. Essa pesquisa tem
fundamental importância numa realidade cada vez mais voltada a esse tipo de
35
dispositivo, soma-se a isso o aprendizado adquirido a respeito dessas ferramentas e das
linguagens de programação, além da pesquisa subsidiar o desenvolvimento deste
trabalho.
36
3 ANÁLISE E PROJETO DO SISTEMA
Neste capítulo são apresentados a análise e parte do projeto do sistema para
coleta de dados proposto neste trabalho. Para a elaboração deste capítulo foram
utilizadas algumas etapas do processo unificado, conforme apresentado em Wazlawick
(2004), consideradas fundamentais para este projeto.
3.1 Processo Unificado de desenvolvimento de software
Um sistema de informação é um tipo especializado de sistema, que pode ser
definido como um conjunto de componentes inter-relacionados trabalhando juntos
para coletar, recuperar, processar, armazenar e distribuir a informação. Geralmente um
sistema de informação computadorizado tem implementado uma grande quantidade de
código e que necessita de alterações constantes conforme as necessidades dos usuários
e a legislação vigente. Por exemplo, um sistema de vendas, por estar fortemente
atrelado à legislação fiscal, em caso de mudanças nas leis tem que ser adequado
(LELES, 2008).
Os sistemas de informação podem ser classificados como elegantes e
deselegantes. Um sistema elegante, segundo Wazlawick (2004, p. 19), é “aquele cuja
estrutura é intrinsecamente mais fácil de compreender, que é autodocumentado e pode
ser compreendido em nível macro ou em detalhes. Ele é mais fácil de modificar:
quando alguma de suas características é mudada, ele continua funcionando”. Já um
sistema deselegante é feito sem uma estrutura clara, sem a utilização de padrões e sem
planejamento, um sistema deselegante não pode ser alterado sem que isso afete seu
funcionamento.
37
Visando auxiliar o desenvolvedor na execução de projetos de aplicativos, o
Processo Unificado (PU), que também é conhecido pela sigla RUP (Rational Unified
Process), descreve um método de análise e projeto de sistemas que comporta em suas
recomendações as antigas fases de estudo de viabilidade, análise de requisitos, análise
de domínio e projeto em múltiplas camadas. Essas fases aparecem no PU organizadas
da seguinte forma: concepção, elaboração, construção e transição.
A fase de concepção incorpora o estudo de viabilidade e uma parte da análise
de requisitos. As fases de elaboração e construção ocorrem dentro de ciclos iterativos,
no qual a elaboração é constituída de análise e projeto e a construção corresponde à
implementação e testes. A fase de transição ocorre após o ultimo ciclo iterativo,
quando o sistema é implantado, substituindo o sistema atual, seja ele computadorizado
ou não. A figura 13 mostra o ciclo de vida de um sistema baseado em ciclos iterativos.
FIGURA 13 - Ciclo de vida do sistema baseado em ciclos iterativos
(Fonte: WAZLAWICK, 2004, p. 24)
3.2 Concepção
A fase de concepção é uma etapa na qual o analista vai buscar as primeiras
informações sobre o sistema a ser desenvolvido. Nessa etapa, assume-se por parte do
analista uma grande interação com o usuário e cliente e pouco conhecimento sobre o
sistema. O objetivo da fase de concepção é descobrir se vale a pena fazer a análise do
38
sistema, mas sem fazê-la propriamente dita (WAZLAWICK, 2004, p. 32).
Recomenda-se que a fase de concepção não demore mais do que duas
semanas para ser concluída, isso se dá porque o cliente e o analista teoricamente ainda
não têm um contrato firmado, sendo assim, se o analista perder muito tempo nesse
momento e a negociação com o cliente falhar, tem-se um prejuízo por parte do
analista.
Wazlawick (2004, p. 32-57) divide a fase de concepção em três partes, são
elas: levantamento de requisitos, organização dos requisitos e planejamento de
desenvolvimento. A seguir é apresentada cada uma delas:
a) Levantamento de Requisitos: Consiste em uma pesquisa junto ao cliente de quais
requisitos o sistema deve dispor. Nesse momento o analista produz alguns
documentos, tais como:
• Sumário executivo: Texto corrido, sem a necessidade de nenhuma
estrutura espacial, que deve descrever as principais idéias do cliente sobre
o sistema.
• Requisitos funcionais e não-funcionais: Registra todos os tópicos
relativos ao que o sistema deve fazer. Nesse momento o documento não
precisa estar totalmente estruturado, admitem-se eventuais lacunas que
serão preenchidas durante os outros ciclos do desenvolvimento.
b) Organização dos requisitos: Depois de identificados, os requisitos são organizados
em grupos correlacionados. Os requisitos podem ser agrupados da seguinte forma:
• Casos de uso (UC – Use Case): É necessário identificar os grandes
processos que o cliente executa, os quais, possivelmente, são compostos
por diversas operações elementares, como, por exemplo, consultas e
alteração de dados
• Conceitos e operações cadastrais: Os conceitos são informações que
possivelmente sofrem operações de manutenção. Em geral essas
operações são inserir, alterar, remover e consultar. Em um sistema
39
bancário, por exemplo, existem clientes, que é um conceito, o cadastro de
um novo cliente é uma operação cadastral realizada sobre o conceito
cliente.
• Consultas: São os relatórios que o sistema deve produzir, sua
identificação na fase de concepção pode ajudar muito no levantamento de
requisitos e na elaboração do sistema.
c) Planejamento do desenvolvimento: Nessa fase, o analista faz um planejamento do
desenvolvimento do sistema, é nesse momento, por exemplo, que são definidos os
cronogramas de execução e custos. Essa fase é de grande importância para que o
projeto possa ser executado, sem ela podem ocorrer problemas como o não
cumprimento de prazos e estouro de orçamento.
Nas subseções seguintes, são apresentadas as atividades da concepção para o
projeto em questão.
3.2.1 Modelo atual de coleta de dados da empresa alvo do sistema
Para iniciar o levantamento de requisitos do sistema proposto, é preciso antes
entender como a empresa faz a coleta dos dados atualmente.
A empresa faz uso de determinadas planilhas para coletar os dados referentes
às atividades executadas em cada unidade de trabalho. Essas planilhas são preenchidas
por cada gerente e encaminhadas à sede da empresa, onde são digitadas por um
funcionário, sendo assim as informações inseridas no banco de dados da empresa. Nos
Anexos A, B e C são apresentadas respectivamente as planilhas utilizadas pela
empresa para a coleta de: atividades; utilização de veículos; e abastecimento de
veículos. Existem também outras planilhas, como é o caso das planilhas de utilização
de máquinas, utilização de materiais, utilização de insumos, abastecimento de
máquinas e participação de funcionários nas atividades da empresa.
40
3.2.2 Sumário executivo
É proposto o desenvolvimento de um sistema de informação para a coleta de
dados nas unidades de uma empresa especializada na produção de frutas. O sistema
visa a substituição do método atual de coleta da empresa que se baseia em um sistema
manual com a utilização de planilhas em papel. O sistema é divido em dois módulos, o
primeiro, executado em um PDA, é responsável pelo trabalho efetivo de coleta e deve
manter as informações coletadas até que sejam transferidas ao banco de dados da
empresa. O sistema deve ainda permitir a execução de uma cópia de segurança dos
dados em uma mídia de gravação, bem como a eventual restauração desses dados. O
segundo módulo deve fazer a ligação entre os dados coletados através do primeiro e o
banco de dados da empresa.
3.2.3 Levantamento de requisitos
Na etapa de levantamento de requisitos, o analista deve ouvir o cliente para
identificar todas as necessidades para o sistema. Os requisitos funcionais e nãofuncionais do sistema são apresentados do quadro 3 ao quadro 30 conforme modelo
apresentado em Wazlawick (2004, p. 40).
Os requisitos funcionais F1 ao F17 (quadros 3 ao 19) dizem respeito a
informações que são obtidas do banco de dados da empresa e não devem ser alteradas
no módulo de coleta de dados. Essas informações são mantidas no PDA porque sem
elas é impossível coletar os dados ao qual destina-se o sistema.
QUADRO 3 - Requisito funcional F1 – Manter informações sobre unidades de negócio
F1 Manter informações sobre unidades de negócio.
Oculto ( )
Descrição: Manter informações sobre as unidades de negócio da empresa, permitindo sua importação e
consulta. As informações que devem ser mantidas são: Código*, Nome*, Localidade e Município.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF1.2 Manipulação
da informação.
NF1.3 Exposição da
informação.
Não deve ser possível alterar nenhum dado
registrado através do módulo PDA.
As informações referentes à unidade de
negócio devem ser apresentadas na tela
inicial do módulo PDA.
Interface
Interface
X
X
X
41
O requisito funcional F1, apresentado no quadro 3, tem fundamental
importância para o módulo de coleta de dados, pois através da informação das
unidades de negócio da empresa, pode ser evitado o download de informações
desnecessárias à unidade de negócio para a qual o PDA está em utilização. É muito
importante que apenas as informações pertinentes a cada unidade de negócio sejam
mantidas no PDA, a menos que informações de outras unidades de negócio possam ser
úteis à coleta dos dados, pois esse tipo de dispositivo tem limitações de memória e o
armazenamento de informações desnecessárias pode causar falta de memória para o
armazenamento de informações pertinentes.
QUADRO 4 - Requisito funcional F2 – Manter informações sobre parcelas
F2 Manter informações sobre parcelas.
Oculto ( )
Descrição: Manter informações sobre as parcelas da unidade de negócio da empresa, permitindo sua
importação e consulta. As informações que devem mantidas são: Código*, quantidade de quadras*, cultura*,
unidade de negócio* e área.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF2.1 Controle de
dados.
Deve ser possível ao usuário visualizar
apenas as parcelas da unidade de negócio em
questão.
NF2.2 Manipulação Não deve ser possível alterar nenhum dado
da informação.
registrado através do módulo PDA.
Interface
X
Interface
X
QUADRO 5 - Requisito funcional F3 – Manter informações sobre quadras
F3 Manter informações sobre quadras.
Oculto ( )
Descrição: Manter informações sobre as quadras de cada parcela da unidade de negócio, permitindo sua
importação e consulta. As informações que devem ser mantidas são: Código*, parcela*, ano de implantação.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF3.1 Controle de
dados.
Deve ser possível ao usuário visualizar
apenas as quadras da unidade de negócio em
questão.
NF3.2 Manipulação Não deve ser possível alterar nenhum dado
da informação.
registrado através do módulo PDA.
Interface
X
Interface
X
QUADRO 6 - Requisito funcional F4 – Manter informações sobre culturas
F4 Manter informações sobre culturas.
Oculto ( )
Descrição: Manter informações sobre as culturas produzidas pela empresa, permitindo sua importação e
consulta. A informação que deve ser mantida é: Nome*.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF4.1 Manipulação Não deve ser possível alterar nenhum dado
da informação.
registrado através do módulo PDA.
Interface
X
42
QUADRO 7 - Requisito funcional F5 – Manter informações sobre cultivares
F5 Manter informações sobre cultivares.
Oculto ( )
Descrição: Manter informações sobre cultivares de cada cultura, permitindo sua importação e consulta. As
informações que devem ser mantidas são: Nome*, Cultura*.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF5.1 Manipulação Não deve ser possível alterar nenhum dado
da informação.
registrado através do módulo PDA.
Interface
X
QUADRO 8 - Requisito funcional F6 – Manter informações sobre clones
F6 Manter informações sobre clones.
Oculto ( )
Descrição: Manter informações sobre clones de cada cultivar, permitindo sua importação e consulta. As
informações que devem ser mantidas são: Nome*, Cultivar*.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF6.1 Manipulação Não deve ser possível alterar nenhum dado
da informação.
registrado através do módulo PDA.
Interface
X
QUADRO 9 - Requisito funcional F7 – Manter informações sobre funcionários
F7 Manter informações sobre funcionários.
Oculto ( )
Descrição: O sistema deve manter informações sobre os funcionários da empresa, permitindo sua importação e
consulta. As informações armazenadas devem ser o nome do funcionário* e o seu código*.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF7.1 Manipulação
da informação.
NF 7.2 Obtenção da
informação.
Não deve ser possível alterar nenhum dado
registrado através do módulo PDA.
Só devem ser obtidos os funcionários cujo a
situação seja ativo.
Interface
X
Persistência
X
QUADRO 10 - Requisito funcional F8 – Manter informações sobre implementos
F8 Manter informações sobre implementos.
Oculto ( )
Descrição: Manter as informações sobre os implementos da empresa utilizados na unidade de negócio em
questão, permitindo sua importação e consulta. As informações a serem mantidas são: Nome*, código*,
unidade de negócio*.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF8.1 Manipulação Não deve ser possível alterar nenhum dado
da informação.
registrado através do módulo PDA.
NF8.2 Apresentação Devem ser apresentado inicialmente apenas
das informações.
os implementos da unidade de negócio em
questão, também possibilitando a busca dos
demais implementos da empresa.
Interface
Interface
X
X
QUADRO 11 - Requisito funcional F9 – Manter informações sobre tipos de materiais
F9 Manter informações sobre tipos de materiais.
Oculto ( )
Descrição: Manter informações sobre tipos de materiais, permitindo sua importação e consulta. A informação
que deve ser mantida é: Nome*.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF9.1 Manipulação Não deve ser possível alterar nenhum dado
da informação.
registrado através do módulo PDA.
Interface
X
43
QUADRO 12 - Requisito funcional F10 – Manter informações sobre subtipos de materiais
F10 Manter informações sobre subtipos de materiais.
Oculto ( )
Descrição: Manter informações sobre subtipos de materiais, permitindo sua importação e consulta. As
informações que devem ser mantidas são: Nome* e tipo de material*
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF10.1
Manipulação da
informação.
Não deve ser possível alterar nenhum dado
registrado através do módulo PDA.
Interface
X
QUADRO 13 - Requisito funcional F11 – Manter informações sobre materiais
F11 Manter informações sobre materiais.
Oculto ( )
Descrição: Manter informações sobre materiais em estoque na empresa, permitindo sua importação e consulta.
As informações que devem ser mantidas são: Nome*, subtipo* e quantidade em estoque.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF11.1
Manipulação da
informação.
Não deve ser possível alterar nenhum dado
registrado através do módulo PDA.
Interface
X
QUADRO 14 - Requisito funcional F12 – Manter informações sobre veículos
F12 Manter informações sobre veículos
Oculto ( )
Descrição: Manter informações sobre os veículos da empresa, permitindo sua importação e consulta. As
informação que devem ser mantidas são: Placa, nome*, código*, unidade de negócio*.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF12.1
Apresentação das
informações.
Deve ser possível ao usuário visualizar
apenas os veículo da unidade de negócio em
questão.
Interface
X
QUADRO 15 - Requisito funcional F13 – Manter informações sobre tipos de máquinas
F13 Manter informações sobre tipos de máquinas.
Oculto ( )
Descrição: Manter informações sobre os tipos de máquinas da empresa, permitindo sua importação e consulta.
A informação que deve ser mantida é: Nome*.
QUADRO 16 - Requisito funcional F14 – Manter informações sobre máquinas
F14 Manter informações sobre máquinas.
Oculto ( )
Descrição: Manter informações sobre as máquinas na empresa, permitindo sua importação e consulta. As
informações que devem ser mantidas são: Nome*, código*, tipo da máquina*, operador, unidade de negócio*.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF14.1
Apresentação das
informações.
Deve ser possível ao usuário visualizar
apenas as máquinas da unidade de negócio
em questão.
Interface
X
QUADRO 17 - Requisito funcional F15 – Manter informações sobre safras
F15 Manter informações sobre safras.
Oculto ( )
Descrição: Manter informações sobre safras, permitindo sua importação e consulta. As informações que devem
ser mantidas são: Ano*, se a safra for a atual.
44
QUADRO 18 - Requisito funcional F16 – Manter informações sobre tipos de atividades
F16 Manter informações sobre tipos de atividades.
Oculto ( )
Descrição: Manter informações sobre os tipos de atividades mantidos pela empresa, permitindo sua importação
e consulta. As informações que devem ser mantidas são: Nome*, unidade de rendimento, rendimento médio,
rateio.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF16.1
Manipulação da
informação.
Não deve ser possível alterar nenhum dado
registrado através do módulo PDA.
Interface
X
QUADRO 19 - Requisito funcional F17 – Manter informações sobre pragas
F17 Manter informações sobre pragas.
Oculto ( )
Descrição: Manter informações sobre pragas, permitindo sua importação e consulta. A informação que deve
ser mantida é: Nome*.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF17.1
Manipulação da
informação.
Não deve ser possível alterar nenhum dado
registrado através do módulo PDA.
Interface
X
Os requisitos funcionais F18 ao F25 (quadros 20 ao 27) fazem referência aos
dados que são coletados pelo módulo de coleta de dados e que são enviados para o
banco de dados da empresa através do módulo de comunicação de dados.
QUADRO 20 - Requisito funcional F18 – Manter informações sobre atividades
F18 Manter informações sobre atividades.
Oculto ( )
Descrição: Manter informações sobre atividades realizadas na empresa, permitindo sua inserção, alteração,
exclusão e consulta. As informações que devem ser mantidas são: Safra*, quadra*, clone*, tipo de atividade*,
data de início*, data de término e número de tratamento*.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF18.1
Manipulação da
informação.
NF 18.2 Exposição
da informação.
Deve ser possível alterar as informações
mantidas através do módulo de coleta de
dados.
Uma atividade será considerada encerrada
quando a data de termino for cadastrada.
Interface
Persistência
X
X
QUADRO 21 - Requisito funcional F19 – Manter informações sobre atividades dos funcionários
F19 Manter informações sobre atividades dos Oculto ( )
funcionários.
Descrição: Manter informações sobre as atividades desenvolvidas por cada funcionário, permitindo sua
inserção, alteração, exclusão e consulta. As informações que devem ser mantidas são: Funcionário*, atividade
realizada*, data*, hora de início, hora do termino, rendimento, horas improdutivas, horas produtivas,
observações, encarregado responsável*.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF19.1
Manipulação da
informação.
Deve ser possível alterar as informações
mantidas através do módulo de coleta de
dados.
Interface
X
45
QUADRO 22 - Requisito funcional F20 – Manter informações sobre a utilização de veículos
F20 Manter informações sobre a utilização de veículos.
Oculto ( )
Descrição: Manter informações sobre a utilização de veículos na unidade de negócio correspondente,
permitindo sua inserção, alteração, exclusão e consulta. As informações que devem ser mantidas são: Data*,
motorista*, veículo*, atividade realizada*, hora de início, hora do termino, velocímetro de início, velocímetro
do termino, litros de combustível abastecidos.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF20.1
Manipulação da
informação.
Deve ser possível alterar as informações
mantidas através do módulo de coleta de
dados.
Interface
X
QUADRO 23 - Requisito funcional F21 – Manter informações sobre a utilização de máquinas
F21 Manter informações sobre a utilização de máquinas. Oculto ( )
Descrição: Manter informações sobre a utilização de máquinas na unidade de negócio correspondente,
permitindo sua inserção, alteração, exclusão e consulta. As informações que devem ser mantidas são: Data*,
atividade realizada*, máquina*, operador*, horímetro inicial, horímetro final, hora de início, hora do termino,
litros de combustível abastecidos, implemento utilizado, volume de calda.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF21.1
Manipulação da
informação.
Deve ser possível alterar as informações
mantidas através do módulo de coleta de
dados.
Interface
X
QUADRO 24 - Requisito funcional F22 – Manter informações sobre abastecimentos de máquinas.
F23 Manter informações sobre abastecimentos de Oculto ( )
máquinas.
Descrição: Manter informações sobre o abastecimento de combustível das máquinas na unidade de negócio
correspondente, permitindo sua inserção, alteração, exclusão e consulta. As informações que devem ser
mantidas são: Data*, total de litros*, valor de litro, maquina*, funcionário*, safra* e horímetro da máquina.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF22.1
Manipulação da
informação.
Deve ser possível alterar as informações
mantidas através do módulo de coleta de
dados.
Interface
X
QUADRO 25 - Requisito funcional F23 – Manter informações sobre abastecimento de veículos.
F23 Manter informações sobre abastecimento de veículos. Oculto ( )
Descrição: Manter informações sobre o abastecimento de combustível de veículos na unidade de negócio
correspondente, permitindo sua inserção, alteração, exclusão e consulta. As informações que devem ser
mantidas são: Data*, total de litros*, valor do litro, safra*, funcionário*, veículo*, velocímetro do veículo.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF23.1
Manipulação da
informação.
Deve ser possível alterar as informações
mantidas através do módulo de coleta de
dados.
Interface
X
QUADRO 26 - Requisito funcional F24 – Manter informações sobre materiais utilizados.
F24 Manter informações sobre materiais utilizados
Oculto ( )
Descrição: Manter informações sobre os materiais utilizados nas atividades desenvolvidas na unidade de
negócio, permitindo sua inserção, alteração, exclusão e consulta. As informações que devem ser mantidas são:
Atividade realizada*, material*, data*, valor médio, valor informado, quantidade total*.
46
F24 Manter informações sobre materiais utilizados
Requisitos Não-Funcionais
Nome
Restrição
NF24.1
Manipulação da
informação.
Oculto ( )
Deve ser possível alterar as informações
mantidas através do módulo de coleta de
dados.
Categoria
Desejável
Interface
Permanente
X
QUADRO 27 - Requisito funcional F25 – Manter informações sobre insumos utilizados.
F25 Manter informações sobre insumos utilizados.
Oculto ( )
Descrição: Manter informações sobre insumos utilizado nas atividades desenvolvidas na unidade de negócio,
permitindo sua inserção, alteração, exclusão e consulta. As informações que devem ser mantidas são: Atividade
realizada*, material (insumo)*, praga*, quantidade, volume, dose, data de início*, data de termino*, hora de
início*, hora de termino*.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF25.1
Manipulação da
informação.
Deve ser possível alterar as informações
mantidas através do módulo de coleta de
dados.
Interface
X
Os requisitos funcionais F26 e F27 (quadros 28 e 29) fazem referência à
comunicação entre o módulo PDA e o banco de dados da empresa. O requisito
funcional F28 (quadro 30) é responsável pela segurança dos dados coletados, antes que
esses sejam inseridos no banco de dados.
QUADRO 28 - Requisito funcional F27 – Transferir dados da empresa para o PDA.
F26 Transferir dados da empresa para o PDA
Oculto ( )
Descrição: Efetuar o download dos dados necessários a utilização do módulo PDA.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável
NF26.1
Manipulação da
informação.
NF26.2 Meio de
comunicação.
Antes de efetuar o download, para evitar a
manutenção de informação repetida, o PDA
deve verificar se as tabelas do módulo estão
vazias.
As informações devem ser obtidas através do
módulo responsável para a comunicação.
Permanente
Persistência
Interface
QUADRO 29 - Requisito funcional F28 – Transferir dados do PDA para a empresa.
F27 Transferir dados do PDA para a empresa
Oculto ( )
Descrição: Enviar os dados coletados com o PDA para o banco de dados da empresa, utilizando como meio de
transporte o módulo do sistema responsável por essa etapa.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF27.1 Meio de
comunicação.
NF27.2 Cópia de
segurança.
NF 27.3
As informações devem ser transferidas
através do módulo responsável para a
comunicação.
Antes de executar a transferência das
informações, o PDA deve efetuar uma cópia
de segurança dos dados.
Só devem ser transmitidas os registros de
Interface
Segurança
Persistência
X
47
F27 Transferir dados do PDA para a empresa
Transmissão de
atividades realizadas já encerradas.
atividades.
Oculto ( )
QUADRO 30 - Requisito funcional F28 – Efetuar cópia de segurança.
F28 Efetuar cópia de segurança
Oculto ( )
Descrição: Possibilitar ao usuário efetuar cópia de segurança dos dados coletados, bem como faze-lo sem que o
usuário requisite em antes do requisito funcional 20.
Requisitos Não-Funcionais
Nome
Restrição
Categoria
Desejável Permanente
NF28.1 Mídia de
gravação.
Deve ser armazenada a cópia de segurança
em um cartão de memória, e na falta desse
deve ser armazenado em uma pasta no PDA.
Interface
O sistema tem ainda os requisitos suplementares que são apresentados no
quadro 31 (módulo de coleta de dados) e quadro 32 (módulo de comunicação).
QUADRO 31 - Requisitos suplementares para o módulo PDA.
Nome
Restrição
S1 Tipo de interface A interface do módulo deve ser
implementada no padrão de janelas do
sistema Windows Mobile.
Categoria
Desejável
Permanente
Interface
QUADRO 32 - Requisitos suplementares para o módulo de comunicação.
Nome
Restrição
S2 Tipo de interface A interface do módulo de comunicação deve
ser implementada como um web service.
S3 Armazenamento A camada de persistência já existente pode
de dados.
ser alterada conforme as necessidades do
cliente, no desenvolvimento do módulo deve
ser tratada essa situação.
Categoria
Desejável
Permanente
X
X
Interface
Persistência
3.2.4 Organização dos requisitos em casos de uso
Os casos de uso são os grandes processos de negócio da empresa (usuário do
sistema), devem cobrir as principais atividades da empresa ligadas ao sistema a ser
implementado. Os casos de uso têm como objetivo levantar informações sobre como o
sistema interage com possíveis usuários e quais consultas e transformações de
informação são necessárias além daquelas já identificadas na fase de levantamento de
requisitos. O quadro 33 mostra a relação de casos de uso para o sistema desenvolvido
neste trabalho.
Na organização dos requisitos em casos de uso, devem ser observadas as
48
seguintes informações:
• Nome: O nome do caso de uso.
• Atores: Os atores envolvidos nas ações a qual se refere o caso de uso.
• Descrição: Uma breve descrição do caso de uso.
• Referências cruzadas: O caso de uso é associado a um conjunto de
requisitos funcionais do sistema, esses requisitos devem aparecer nas
referências cruzadas.
QUADRO 33 - Casos de Uso do sistema
Nome
UC1 - Atribuir
atividades aos
funcionários.
UC2 - Encerrar
atividade de
funcionários
Atores
Encarregado,
Funcionário
Encarregado,
Funcionário,.
Descrição
O encarregado identifica os funcionários, designa
funções a cada um e efetua o registro do início da
execução da atividade
Ao termino da execução da atividade, o
encarregado identifica a atividade atribuída ao
funcionário, registra os dados da execução, bem
como as horas improdutivas.
Referências cruzadas
F7, F18, F19
F7, F18, F19
3.2.5 Organização dos requisitos em função de conceitos
Algumas operações simples que o sistema executa (como, por exemplo, o
registro de um funcionário) não devem ser consideradas como caso de uso, pois seu
processo iterativo é de apenas um passo, não sendo necessário assim estudá-lo. Essas
operações possivelmente fazem parte de casos de uso. Para identificar essas operações,
sugere-se que o analista identifique todos os conceitos envolvidos no sistema. O
quadro 34 mostra os conceitos do sistema em questão.
Para a organização dos conceitos, sugere-se um quadro a com os seguintes
campos:
• Conceito: Nome do conceito.
• Inserção (I): Indica se o conceito deve sofrer inserção.
• Alteração (A): Indica se o conceito deve sofrer alteração.
• Exclusão (E): Indica se o conceito deve sofrer exclusão.
• Consulta (C): Indica se o conceito deve sofrer consulta.
• Importação (Im): Indica se o conceito pode ser importado de outra fonte.
• Observação: Nesse campo, registra-se possíveis restrições ou regras de
49
validação sobre o conceito.
• Referências cruzadas: Os requisitos funcionais ao qual estão envolvidos o
conceito.
QUADRO 34 - Conceitos do sistema
Conceito
Abastecimento
de máquina
Abastecimento
de veículo
Atividade
Atividade de
funcionário
Clone
Cultivar
Cultura
Funcionário
Implemento
Máquina
Material
Parcela
Praga
Quadra
Safra
Subtipo Material
Tipo Atividade
Tipo de máquina
Tipo de material
Unidade de
negócio
Utilização de
insumo
Utilização de
máquina
Utilização de
material
Utilização de
veículo
Veículo
I A E C
X X X X
Im
Observação
Ref. Cruzadas
F7, F14, F22
X X X X
F7, F14, F23
X X X X
X X X X
F16, F18
F7, F18, F19
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
F5, F6
F4, F5
F4
F7
F1, F8
F1, F13, F14
F10, F11
F1, F2, F4
F17
F2, F3
F15
F9, F10
F16
F13
F9
F1
X X X X
F11, F17, F18
X X X X
F7, F14, F18
X X X X
F11, F18
X X X X
F7, F12, F18
X
X
F1, F12
3.3 Elaboração
A fase de elaboração, segundo o PU, pode ser divida em duas subfases:
análise e projeto. Na subfase de análise, o analista aprimora a documentação obtida na
concepção do projeto, essa fase comporta três atividades distintas, são elas:
• Expansão dos casos de uso: Na fase de concepção, os casos de uso são
descritos de uma maneira superficial, não se tem detalhes da operação
50
realizada, sendo assim impossível determinar uma seqüência real dos
fatos. A expansão dos casos de uso entra nesse contexto com o objetivo
de detalhar cada ação, permitindo ao analista especificar cada passo
executando no caso de uso, bem como as possíveis exceções e variantes
desses passos.
• Construção do modelo conceitual: É um diagrama que procura mostrar
quais são os elementos de informação tratados pelo sistema. Faz parte do
domínio do problema, e não do domínio da solução, portanto não deve
ser confundido com a arquitetura do sistema.
• Contratos: Cada operação de inserção ou consulta no sistema implica em
uma intenção por parte do usuário, a função dos contratos é capturar essas
intenções, são organizados em contratos de operação do sistema e
contratos de consulta de sistema.
Até a subfase de análise da elaboração, o analista pensa no sistema como um
problema ao qual a solução ainda não foi proposta. Na subfase de projeto, o analista já
começa a propor a solução para o problema, é nessa fase que o sistema começa a ser
projetado.
Nas subseções a seguir são apresentadas as atividades da elaboração para o
projeto em questão.
3.3.1 Expansão dos casos de uso
Identificados os casos de uso na fase de concepção, a próxima etapa para o
projeto é expandi-los. Para demonstrar a expansão dos casos de uso do projeto em
questão, sugere-se um quadro com os seguintes campos:
• Caso de uso: Nome do caso de uso.
• Atores: Os atores envolvidos nas ações a qual se refere o caso de uso.
• Fluxo principal: O fluxo principal consiste nos passos obrigatórios de
cada caso de uso e que envolvem informações que passam dos atores ao
sistema e do sistema aos atores. No fluxo principal deve-se considerar
51
que todos os passos ocorram sem problema algum.
• Tratamento de exceções: Os passos do fluxo principal podem acarretar
em algumas exceções, por exemplo, em uma operação de saque num
sistema bancário, o ator cliente pode não ter saldo para a operação, isso
acarreta em uma exceção que não permite que a operação seja concluída.
Essas exceções devem ser tratadas nesse momento.
No fluxo principal e no tratamento de exceções é possível determinar quais
passos são eventos de sistema, ou seja, quais trasnportam informações do ator para o
sistema, e quais passos são respostas de sistema, ou seja, transportam informações do
sistema para os atores. Esse tratamento se dá incluindo as siglas [EV] para evento de
sistema e [RS] para resposta de sistema antes de cada passo.
Os quadros 35 e 36 mostram a expansão dos casos de uso do sistema
desenvolvido neste trabalho.
QUADRO 35 - Expansão do caso de uso UC1 – Atribuir atividades aos funcionários
Caso de uso: Atribuir atividades aos funcionários
Atores: Encarregado
Fluxo principal:
1. [RS] O sistema apresenta as atividades em andamento.
2 [EV] O encarregado seleciona uma atividade.
3. [RS] O sistema apresenta os dados da atividade.
4. [EV] O encarregado informa a data e o encarregado da atividade.
5 [EV] O encarregado seleciona o funcionário que vai trabalhar na atividade e informa a hora de inicio.
Repete o passo 4 até incluir todos os funcionários.
6. [EV] O encarregado encerra o registro.
Tratamento de exceções:
2a Atividade não cadastrada.
2a.1 O encarregado cadastra a atividade.
2a.2 Retorna ao fluxo principal no passo 2.
4a. O encarregado não consta no cadastro.
4a.1 O encarregado verifica junto a matriz se está regular e registrado.
4a.2 Caso o registro do encarregado esteja correto, atualiza o cadastro e retornar ao fluxo principal no
passo 1.
4a.3 Caso o encarregado não esteja registrado, aborta a operação.
5a. O funcionário não consta no cadastro.
5a.1 O encarregado verifica junto a matriz se o funcionário está regular e registrado.
5a.2 Caso o registro do funcionário esteja correto o encarregado atualiza o cadastro e retornar ao fluxo
principal no passo 1.
5a.3 Caso o funcionário não esteja registrado o encarregado aborta a operação.
52
QUADRO 36 - Expansão do caso de uso UC2 – Encerrar atividade dos funcionários
Caso de uso: Encerrar atividade dos funcionários
Atores: Encarregado
Fluxo principal:
1. [RS] O sistema apresenta as atividades em execução.
2. [EV] O encarregado seleciona a atividade para o encerramento.
3. [RS] O sistema apresenta os dados da execução da atividade.
4. [EV] O encarregado registra a hora de encerramento da atividade pelo funcionário.
Repete o passo 4 até efetuar o registro para todos os funcionários.
5. [EV] O encarregado registra as horas improdutivas.
6. [RS] O sistema informa o total de horas improdutivas.
7. [EV] O encarregado encerra o registro.
Tratamento de exceções:
7a Algum funcionário não teve o termino registrado.
7a.1 O encarregado registra a hora de termino do funcionário.
7a.2 Retorna ao fluxo principal no passo 5.
3.3.2 Modelo conceitual
O modelo conceitual é um artefato do domínio do problema e deve descrever
a informação que o sistema vai gerenciar. O modelo conceitual não deve ser
confundido com a arquitetura do aplicativo, bem como, com o modelo de dados, pois
esses artefatos fazem parte do domínio da solução, ou seja, fazem parte do projeto do
sistema (WAZLAWICK, 2004, p. 102).
Por se tratar de um artefato do domínio do problema, o modelo conceitual
deve ser construído sem direção a nenhuma tecnologia, nem mesmo deve ser tratado
como um sistema computacional.
Antes da construção do modelo, o analista deve identificar alguns elementos
básicos, são eles:
• Conceitos: É a representação da informação complexa, ou seja,
informação que não pode ser representada apenas por um tipo
alfanumérico.
• Atributos: São informações alfanuméricas diretamente ligadas aos
conceitos.
• Associações: Consiste em um tipo de informação que liga diferentes
conceitos entre si.
Ao identificar esses elementos, o modelo pode começar a ser construído. No
53
Apêndice A está o modelo conceitual do sistema desenvolvido neste trabalho.
3.3.3 Diagrama de classe
O diagrama de classes de projeto é construído apartir do modelo conceitual
porém com algumas modificações básicas conforme visto em Wazlawick (2004, p.
185), são elas:
• Adição dos métodos: os métodos de cada classe são adicionados
declarados no diagrama, fato que não ocorre no modelo conceitual;
• Adição da direção das associações: no diagrama de classes é
determinada a direção de navegação das associações;
• Detalhamento dos atributos e associações: se necessário, pode-se definir
os tipos dos atributos, bem como o nome de papel de cada associação;
• Alteração na estrutura das classes e associações: pode ser necessário
criar novas classes para implementar estruturas do projeto;
• Criação de atributos privados ou protegidos: no modelo conceitual todos
os atributos devem ser declarados como públicos, uma vez que
representam a informação e não faz sentido uma informação que não
possa ser acessível.
Para a modelagem do diagrama de classes do sistema desenvolvido neste
trabalho, usou-se a ferramenta Class Diagram do Visual Studio, o diagrama é
apresentado no Apêndice B.
3.3.4 Diagrama de estado de navegação
O diagrama de estado de navegação indica todas as interfaces gráficas que
compõem o sistema e com quais eventos se dá a navegação entre elas. Cada evento
rotulado neste diagrama é posteriormente associado a algum controle da janela de
origem (botão, menu, por exemplo). É desejável que os nomes dos eventos
correspondam aos nomes dos controles de interface encarregado de efetivar o evento
54
(WAZLAWICK, 2004).
No sistema proposto, dois aplicativos fazem uso de janelas como interface
com o usuário, são eles o aplicativo do módulo de coleta e o aplicativo do módulo de
comunicação utilizado no PDA. Os diagramas de estado de navegação desses
aplicativos são apresentados nos Apêndices C (aplicativo do módulo de coleta) e
Apêndice D (aplicativo do módulo de comunicação).
3.4 Conclusão
A elaboração deste capítulo teve grande importância no que diz respeito ao
aprendizado sobre o Processo Unificado para o desenvolvimento de sistemas,
principalmente nas fases de concepção e elaboração. Além do aprendizado, a
importância deste capítulo estende-se à elaboração da análise e de parte do projeto do
sistema a ser desenvolvido, dessa maneira subsidiando o início da implementação,
assunto alvo do próximo capítulo.
55
4 IMPLEMENTAÇÃO DO SISTEMA
Neste capítulo apresenta-se o processo de desenvolvimento do sistema
proposto neste trabalho. São utilizados, para isso, a tecnologia de web service, a
ferramenta de desenvolvimento Visual Studio 2005 com a linguagem C#, o banco de
dados Microsoft SQL Server 2005 Mobile e o provedor de conexão entre o Visual
Studio e o sistema gerenciador de banco de dados Firebird.
4.1 Web service
É apresentada nessa sessão uma breve explicação sobre web service, pois
essa tecnologia é utilizada e tem grande relevância no sistema proposto neste trabalho.
Um web service, ou serviço web, segundo Deitel (2005, p. 894) é “... um
aplicativo armazenado em uma máquina que pode ser acessado em outra máquina, em
uma rede”. A máquina em que o web service reside é comumente referida como
máquina remota. O aplicativo que acessa o web service envia uma chamada para a
máquina remota, que processa a chamada e envia uma resposta ao aplicativo
(DEITEL, 2005, p. 894).
Para compreender o funcionamento de um web service, é necessário entender
as tecnologias XML, SOAP e RPC.
• XML (Extensible Markup Language): É uma tecnologia aberta, portável
e amplamente suportada para descrever dados, o XML é um padrão para
o armazenamento de dados intercambiados entre programas. Com
arquivos XML é possível enviar dados de um aplicativo a outro de forma
simples e organizada (DEITEL, 2005, p. 724).
56
• SOAP (Simple Object Access Protocol): É um protocolo independente de
plataforma que utiliza XML para efetuar chamadas a procedimentos
remotos por meio de HTTP. As mensagens SOAP são muito populares,
pois são escritas em códigos XML, sendo fácil de entender e
independente de plataforma (DEITEL, 2005, p. 897-898).
• RPC (Remote Procedure Call): Chamada de procedimento remoto é uma
tecnologia de comunicação entre processos que permite a um programa
de computador chamar um procedimento em outro computador,
normalmente através de uma rede.
Em um web service, os procedimentos são chamados pelo cliente de maneira
remota, utilizando uma chamada RPC. Os métodos no web service são marcados pelo
atributo WebMethod, tornando-se, dessa maneira, acessíveis para qualquer aplicativo
por meio de uma chamada RPC. A maioria das requisições e respostas de web service
é transmitida por SOAP, sendo assim, qualquer cliente capaz de processar mensagens
SOAP pode utilizar o serviço, independente da linguagem em que o web service esteja
escrito (DEITEL, 2005, p. 895).
Um web service criado no Visual Studio 2005 é dividido em duas partes: um
arquivo com a extensão ASMX, que contém informações sobre o serviço, como as
descrições dos métodos e as maneiras de testar esses métodos; e um arquivo de código
de retaguarda, que fornece a implementação dos métodos que o web service contém
(DEITEL, 2005, p. 895).
O Visual Studio, ainda, cria no projeto dois diretórios denominados
App_Code, para armazenar os arquivos de códigos de retaguarda e App_Data, para
armazenar os arquivos de persistência. Ao incorporar alguma biblioteca no projeto, o
Visual Studio cria outro diretório denominado bin e armazena os arquivos da biblioteca
incorporada neste diretório. A figura 14 mostra a estrutura de um projeto de web
service no Visual Studio.
Para criar um novo projeto de web service no Visual Studio basta ao
desenvolvedor seguir os seguintes passos:
57
• Com o Visual Studio aberto, escolher a opção de menu: File, New, Web
Site.
• Escolher a opção ASP.NET Web Service.
• Escolher a linguagem de desenvolvimento e o diretório de destino.
FIGURA 14 - Estrutura de um projeto de web service no Visual Studio
Dependendo o tipo de trabalho requerido do projeto de web service, o Visual
Studio ainda cria um arquivo de configuração denominado web.config, que segundo
Silva (2008):
...é um arquivo especial que configura o comportamento de sua aplicação
asp.net e está no formato xml podendo ser editado facilmente com um editor
comum, como o bloco de notas. Cada aplicativo web que você cria, pode ter
o seu próprio arquivo web.config, e as informações deste arquivo valem para
o diretório corrente e seus subdiretórios.
58
4.2 Arquitetura do sistema
O sistema do trabalho em questão é constituído por dois módulos, um
denominado módulo de coleta de dados, que é responsável por efetuar a coleta dos
dados da empresa em campo, utilizando um dispositivo PDA (Personal Digital
Assistant). O outro módulo é denominado módulo de comunicação e é responsável por
efetuar a comunicação e transferência de dados entre o dispositivo PDA e o banco de
dados da empresa. A figura 15 mostra um esquema de funcionamento do sistema.
FIGURA 15 - Esquema de funcionamento do sistema
O padrão de arquitetura de software utilizado é o MVC (Model View
Controller), que traduzido para português significa: Modelo, Visão e Controlador. O
MVC consiste em dividir uma aplicação em três camadas. A camada de modelo
(Model) é a representação específica da informação operada pela aplicação. A camada
controladora (Controller) é responsável por processar e responder a eventos,
59
geralmente ações do usuário. A camada de visão (View) é responsável pela interação
com o sistema, essa camada envia eventos com as ações a serem executadas para a
camada controladora. Normalmente essa camada trabalha como uma interface para o
usuário do sistema.
Utilizar o MVC em aplicações orientadas a objetos traz algumas vantagens,
como a facilidade de manutenção do aplicativo, uma vez que as camadas são
independentes uma das outras. Sendo assim, havendo necessidade de alteração de uma
camada, isso pode ser feito sem que, necessariamente, seja preciso alterar as demais
(UNITO SISTEMAS, 2008).
Outra vantagem é a possibilidade de reutilização das camadas, pois cada
camada de modelo pode ser utilizada em quantos controladores possa servir, bem
como a camada controladora pode servir para quantas camadas de visão seja
necessário (UNITO SISTEMAS, 2008).
A figura 16 mostra um exemplo da reutilização das camadas MVC. Neste
caso são apresentados dois aplicativos, o primeiro é um aplicativo desktop, que tem
como camada de visão uma interface padrão Windows em que o usuário pode efetuar
consultas e cadastros. A camada de visão do segundo aplicativo é um web service que
pode ser acessado de qualquer máquina através de uma rede, assim como no sistema
proposto neste trabalho. Ambos os aplicativos utilizam as mesmas camadas de
controle e modelo, não sendo necessário desenvolvê-las especificamente para cada um.
No sistema em questão, os aplicativos dos dois módulos tem como camada
de modelo uma mesma biblioteca, denominada ModelagemSistema. No módulo de
comunicação, os dois web services tem como camada de visão os arquivos
ServicoRetornaDados.asmx (provedor de dados) e ServicoRecebeDados.asmx
(receptor
de
dados)
e
utilizam
WebServiceComunicacao.Control.
como
camada
controladora
a
biblioteca
60
FIGURA 16 - Exemplo de reutilização das camadas MVC
O aplicativo do módulo de comunicação do PDA tem como camada de visão
as interfaces presentes no arquivo executável PDA.Comunicacao.exe. Já o aplicativo
do módulo de coleta tem como camada de visão as interfaces do arquivo executável
PDA.Coleta.exe. Estes dois aplicativos utilizam a mesma camada controladora,
disponível na biblioteca PDA.Control. A figura 17 e o quadro 37 mostram a estrutura
de camadas do sistema.
QUADRO 37 - Estrutura de camadas do sistema
Modulo
Comunica
ção
Comunica
ção
Comunica
ção
Coleta
Aplicativo
Web service
Provedor
Web service
Receptor
PDA.Comunica
cao
PDA.Coleta
Camada de visão
ServicoRetornaD
ados.asmx
ServicoRecebeD
ados.asmx
PDA.Comunicac
ao.exe
PDA.Coleta.exe
Camada de controle
WebServiceComunicacao.
Control
WebServiceComunicacao.
Control
PDA.Control
Camada de modelo
ModelagemSistema
PDA.Control
ModelagemSistema
ModelagemSistema
ModelagemSistema
61
FIGURA 17 - Estrutura de camadas do sistema
4.3 Camada de modelo
Antes de iniciar o desenvolvimento dos módulos de comunicação e coleta,
tem-se o desenvolvimento, a partir do modelo conceitual apresentado no apêndice A,
da biblioteca responsável pela estrutura de classes do sistema. A biblioteca,
denominada ModelagemSistema, implementa a camada de modelo do sistema e é
utilizada em todos os aplicativos dos módulos que o compõem.
Para o desenvolvimento das classes da biblioteca ModelagemSistema utilizase a ferramenta ClassDiagram do Visual Studio, com ela é possível declarar os
atributos, propriedades e métodos das classes de maneira visual. No apêndice B deste
trabalho é mostrado o modelo de classes da biblioteca desenvolvido com a ferramenta
ClassDiagram.
O quadro 38 mostra o código fonte da classe UnidadeNegocio, como
exemplo, a qual faz parte da referida biblioteca. Para cada classe do modelo conceitual
foi criada uma classe com as mesmas características de UnidadeNegocio.
62
Assim
como
as
outras
bibliotecas
desenvolvidas
neste
trabalho,
ModelagemSistema após compilada torna-se em um arquivo do tipo DLL (Dynamic
Link Library) que pode ser acessado de qualquer aplicação desenvolvida para a
plataforma .Net.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
QUADRO 38 - Código fonte da classe UnidadeNegocio
using System;
using System.Collections.Generic;
using System.Text;
namespace ModelagemSistema
{
public class UnidadeNegocio
{
private int _idUnidadeNegocio;
public int IdUnidadeNegocio
{
get { return _idUnidadeNegocio; }
set { _idUnidadeNegocio = value; }
}
private string _codigo;
public string Codigo
{
get { return _codigo; }
set { _codigo = value; }
}
private string _localidade;
public string Localidade
{
get { return _localidade; }
set { _localidade = value; }
}
private string _nome;
public string Nome
{
get { return _nome; }
set { _nome = value; }
}
private string _municipio;
public string Municipio
{
get { return _municipio; }
set { _municipio = value; }
}
private bool _pertencente;
public bool Pertencente
{
get { return _pertencente; }
set { _pertencente = value; }
}
public UnidadeNegocio()
{
Pertencente = false;
}
}
}
63
No quadro 38, a linha 5 mostra o nome do projeto ao qual a classe pertence,
na linha 7 é feita a declaração da classe e da linha 9 à linha 44 ocorre a declaração dos
atributos e das propriedades da classe, com seus métodos Get e Set. Nas linhas 45 a 48
define-se o método construtor da classe.
A definição de propriedades na linguagem C# garante um objetivo
importante das linguagens de programação orientada a objetos, que é fornecer acesso
controlado às variáveis internas de uma classe. Como no exemplo do quadro 38, as
variáveis declaradas como privadas podem receber e retornar valores através das
propriedades, que por serem declaradas como públicas, são acessíveis por outras
classes (MICROSOFT, 2006).
A biblioteca ModelagemSistema é a camada de modelo de todos os
aplicativos dos módulos do sistema desenvolvido neste trabalho. As camadas
controladoras e de visão são específicas para cada aplicativo e, por isto, são discutidas
individualmente a partir da seção 4.4.
4.4 Módulo de comunicação
O módulo de comunicação faz a comunicação (envio e recebimento) dos
dados entre o banco de dados da empresa e o PDA. Ele é composto por dois web
services, um denomindado web service provedor, que provê os dados essenciais para o
funcionamento do módulo de coleta do sistema, e o outro denominado web service
receptor, que recebe os dados coletados no módulo de coleta e insere-os no banco de
dados da empresa. Além dos dois web services¸ o módulo de comunicação ainda tem
um aplicativo instalado no PDA responsável pelo envio e recebimento de dados nesse
dispositivo.
4.4.1 Web service provedor dos dados
O web service construído para prover os dados essenciais ao funcionamento
do módulo de coleta recebe o nome de ServicoRetornaDados. Ele tem por objetivo
64
buscar no banco de dados da empresa os dados necessários para que o usuário possa
usar o módulo de coleta no PDA.
Para conectar o sistema gerenciador de banco de dados Firebird com o
Visual Studio 2005 é necessário a utilização de um provedor, ou seja, uma biblioteca
baseada em ado.net1 com as mesmas características de qualquer outro provedor do
Visual Studio (PIMENTA, 2008). Para efetuar a instalação do provedor, é necessário
fazer o download da página do Firebird (FIREBIRD, 2008), após terminado o
download basta desanexar o pacote e importar ao projeto do Visual Studio a biblioteca
FirebirdSql. Data.FirebirdClient.dll.
Seguindo o padrão MVC, o web service deste trabalho faz uso da biblioteca
ModelagemSistema como camada de modelo. A camada de visão é o próprio web
service, através do arquivo ServicoRetornaDados.asmx, e a camada controladora é a
biblioteca WebServiceComunicacao.Control.
O
quadro
39
mostra
a
estrutura
da
classe
(web
service)
ServicoRetornaDados, com o método que retorna a lista de unidades de negócios
obtidas através da classe ControleUnidadeNegocio da camada controladora. Nessa
seção é mostrada apenas a classe responsável por prover os dados, a classe responsável
por receber os dados no PDA é mostrada na seção 4.4.2.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
1
QUADRO 39 - Código fonte da classe (web service) ServicoRetornaDados
using System;
using System.Web;
using System.Collections;
using System.Collections.Generic;
using System.Web.Services;
using System.Web.Services.Protocols;
using WebServiceComunicacao.Control;
using ModelagemSistema;
/// <summary>
/// Summary description for ServicoRetornaDados
/// </summary>
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class ServicoRetornaDados :
System.Web.Services.WebService
{
Tecnologia de acesso a dados no .NET framework. O ado.net é uma evolução do modelo Cliente/Servidor,
projetada especialmente para a construção de aplicações escaláveis, distribuídas e para a web (PAULI, 2008).
65
public ServicoRetornaDados()
{
19
20
21
22
23
24
25
26
27
28
29
30
31
}
[WebMethod]
public List<UnidadeNegocio> retornaUnidadesNegocio()
{
ControleUnidadeNegocio controle = new
ControleUnidadeNegocio();
return controle.retornaUnidadesNegocio();
}
}
No quadro 39, a linha 24 mostra a declaração WebMethod do método
retornaUnidadesNegocio, fazendo com que esse método seja acessível por outra
máquina através de um chamado RPC. O método retornaUnidadesNegocio (linhas 25
à 30) cria um objeto da classe ControleUnidadeNegocio da camada controladora e
retorna
a
lista
de
unidades
de
negócio
montada
através
da
chamada
controle.retornaUnidadesNegocio (linha 30).
Na linha 16 pode-se notar que a classe ServicoRetornaDados herda as
características da classe System.Web.Services.WebService. Herdar essa classe não é
obrigatório, porém possibilita ao web service acessar os objetos intrínsecos do asp.net,
tais como Application e Session (MSDN, 2008b).
Para a camada controladora, foi desenvolvida uma nova biblioteca,
denominada WebServiceComunicacao.Control, essa biblioteca conta com uma classe
responsável pela conexão com o banco de dados, denominada Conexao, que é
apresentada nos quadros 40 e 41.
1
2
3
4
5
6
7
8
9
10
using
using
using
using
using
QUADRO 40 - Código fonte da classe Conexao I
System;
System.Collections.Generic;
System.Text;
FirebirdSql.Data.FirebirdClient;
System.Xml;
namespace WebServiceComunicacao.Control
{
public class Conexao: System.Web.UI.Page
{
66
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
FbConnection conexao;
public Conexao()
{
try
{
this.conexao = new
FbConnection(getStringConnection());
}
catch (Exception)
{
throw;
}
}
public FbConnection getConexao()
{
return this.conexao;
}
public void abreConexao()
{
try
{
this.conexao.Open();
}
catch (Exception)
{
throw;
}
}
public void fechaConexao()
{
try
{
this.conexao.Close();
}
catch (Exception)
{
throw;
}
}
No quadro 40, a linha 4 mostra que a classe Conexao usa o pacote
FirebirdSql.Data.FirebirdClient disponível no provedor de conexão e a linha 9 mostra
a herança da classe System.Web.UI.Page, que possibilita utilizar, entre outros, o
método Server.MapPath que mapeia o diretório onde está alocado o web service.
Na linha 11 cria-se um objeto da classe FbConnection, responsável pela
conexão com o banco de dados. No construtor da classe (linhas 12 a 23) este objeto é
iniciado com uma string de conexão. Três métodos essenciais para o gerenciamento da
conexão são implementados: o método getConexao (linhas 24 à 27), responsável por
retornar o objeto da classe FbConnection; o método abreConexao (linhas 28 à 38),
responsável por abrir a conexão com o banco de dados; e o método fechaConexao
67
(linhas 39 à 49), que é responsável por fechar a conexão com o banco de dados.
A string de conexão é obtida através de um arquivo XML criado para
armazenar as configurações da conexão. O método que obtém os dados do arquivo é
apresentado nas linhas 1 à 51 do quadro 41, dessa maneira, caso alguma configuração
da conexão seja alterada não é necessário re-compilar o sistema, basta, com um
simples editor de texto alterar o arquivo XML apresentado no quadro 42.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
QUADRO 41 - Código fonte da classe Conexao II
private String getStringConnection()
{
String stringConnection;
XmlDocument documento = new XmlDocument();
try
{
documento.Load(Server.MapPath"configuracao.xml"));
}
catch (Exception)
{
documento.Load("TCCWebService\\configuracao.xml");
}
XmlNodeList listaNodos;
listaNodos =
documento.SelectNodes
("configuracao/bancoDados[@tipo='firebird']");
XmlNode nodo = listaNodos.Item(0);
stringConnection = "user=" +
nodo.SelectSingleNode("user").InnerText;
stringConnection += "password=" +
nodo.SelectSingleNode("password").InnerText;
stringConnection += "database=" +
nodo.SelectSingleNode("database").InnerText;
stringConnection += "datasource=" +
nodo.SelectSingleNode("datasource").InnerText;
stringConnection += "port=" +
nodo.SelectSingleNode("port").InnerText;
stringConnection += "dialect=" +
nodo.SelectSingleNode("dialect").InnerText;
stringConnection += "charset=" +
nodo.SelectSingleNode("charset").InnerText;
stringConnection += "role=" +
nodo.SelectSingleNode("role").InnerText;
stringConnection += "connection lifetime=" +
nodo.SelectSingleNode
("connection_lifetime").InnerText;
stringConnection += "pooling=" +
nodo.SelectSingleNode("pooling").InnerText;
stringConnection += "minpoolsize=" +
nodo.SelectSingleNode("minpoolsize").InnerText;
stringConnection += "maxpoolsize=" +
nodo.SelectSingleNode("maxpoolsize").InnerText;
stringConnection += "packet size=" +
nodo.SelectSingleNode("packet_size").InnerText;
stringConnection += "servertype=" +
nodo.SelectSingleNode("servertype").InnerText;
68
47
48
49
50
51
52
53 }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
documento = null;
listaNodos = null;
nodo = null;
return stringConnection;
}
}
QUADRO 42 - Arquivo xml de configuração da conexão com banco de dados Firebird
<?xml version="1.0" encoding="utf-8" ?>
<configuracao>
<bancoDados tipo="firebird">
<user>SYSDBA;</user>
<password>masterkey;</password>
<database>
D:\Tcc\Desenvolvimento\BancoDados\CUSTOS.GDB;
</database>
<datasource>localhost;</datasource>
<port>3050;</port>
<dialect>3;</dialect>
<charset>none;</charset>
<role>;</role>
<connection_lifetime>15;</connection_lifetime>
<pooling>true;</pooling>
<minpoolsize>0;</minpoolsize>
<maxpoolsize>50;</maxpoolsize>
<packet_size>8192;</packet_size>
<servertype>0;</servertype>
</bancoDados>
</configuracao>
Além da classe Conexao, a biblioteca contém as demais classes responsáveis
pelas ações no banco de dados. O quadro 43 demonstra, como exemplo, o código fonte
da classe ControleUnidadeNegocio.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
using
using
using
using
using
QUADRO 43 - Código fonte da classe ControleUnidadeNegocio
System;
System.Collections.Generic;
System.Text;
FirebirdSql.Data.FirebirdClient;
ModelagemSistema;
namespace WebServiceComunicacao.Control
{
public class ControleUnidadeNegocio
{
Conexao conexao;
public ControleUnidadeNegocio()
{
conexao = new Conexao();
}
public List<UnidadeNegocio> retornaUnidadesNegocio()
{
List<UnidadeNegocio> unidadesNegocio = new
69
List<UnidadeNegocio>();
UnidadeNegocio unidadeNegocio = new
UnidadeNegocio();
conexao.abreConexao();
FbCommand comando =
new FbCommand("SELECT IDUNIDADENEGOCIO, CODIGO," +
NOME,LOCALIDADE, MUNICIPIO FROM UNIDADENEGOCIO" +
" ORDER BY IDUNIDADENEGOCIO",
this.conexao.getConexao());
try
{
FbDataReader reader = comando.ExecuteReader();
while (reader.Read())
{
unidadeNegocio = populaObjeto(reader);
unidadesNegocio.Add(unidadeNegocio);
unidadeNegocio = new UnidadeNegocio();
}
}
catch (Exception)
{
throw;
}
conexao.fechaConexao();
return unidadesNegocio;
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60 }
}
private UnidadeNegocio populaObjeto(FbDataReader reader)
{
UnidadeNegocio unidadeNegocio = new
UnidadeNegocio();
if (reader.IsDBNull(0)==false)
{
unidadeNegocio.IdUnidadeNegocio =
reader.GetInt32(0);
}
if (reader.IsDBNull(1)==false)
{
unidadeNegocio.Codigo = reader.GetString(1);
}
...
return unidadeNegocio;
}
}
No quadro 43, a linha 5 faz referência a utilização da biblioteca
ModelagemSistema que contém as classes da camada de modelo do sistema. Nas
linhas 13 a 16, tem-se o método construtor da classe que inicia um objeto da classe
Conexao definido na linha 11.
O método retornaUnidadesNegocio (linhas 17 à 40) é responsável por obter
os dados da tabela unidadenegocio no banco de dados e empacotá-los em uma lista de
objetos da classe UnidadeNegocio. Na linha 22 é criado um objeto da classe
70
FbCommand responsável pelo comando de busca no banco de dados e a linha 26
mostra a criação de um objeto da classe FbDataReader responsável por receber os
resultados do objeto de comando. Nas linhas 27 a 32 acontece o empacotamento dos
dados na lista.
Nas linhas 41 a 58 apresenta-se o método populaObjeto que recebe o
FbDataReader2 por parâmetro, checa se os dados recebidos não são nulos e faz a
população de um objeto UnidadeNegocio, retornando-o para que ele seja inserido na
lista.
Para as demais tabelas do banco de dados, a busca e a provisão dos dados é
feita da mesma forma da tabela de unidades de negócio, apresentada como exemplo
nesta sessão.
4.4.2 Recepção dos dados no PDA
O módulo de comunicação do sistema também possui um aplicativo no PDA
responsável por receber e enviar os dados para o servidor da empresa (através dos web
services). Nesta subseção é mostrada a primeira fase do desenvolvimento deste
aplicativo que diz respeito à recepção dos dados do banco de dados gerados pelo web
service ServicoRetornaDados, apresentado em 4.4.1.
O primeiro passo para a criação desse aplicativo é iniciar um novo projeto no
Visual Studio, para isso basta ao desenvolvedor seguir os seguintes passos.
• Com o Visual Studio aberto clicar em File, New, Project;
• Selecionar a opção Smart Device; nesse momento o Visual Studio
disponibiliza os conjuntos de ferramentas para o desenvolvimento nas
plataformas Pocket PC 2003, Smartphone 2003 e Windows CE 5.0. Caso
haja a necessidade de desenvolvimento em outra plataforma é preciso
certificar-se da disponibilidade e instalar o SDK (Software Development
Kit) da plataforma requerida;
• No caso deste trabalho, a plataforma de desenvolvimento é Pocket PC
2003, sendo assim basta selecionar essa opção e em seguida Device
71
Application;
• Informar o nome do projeto, o diretório de armazenamento e o nome da
solução.
O sistema gerenciador de banco de dados para o PDA é o Microsoft SQL
Server 2005 Mobile Edition, uma versão para dispositivos móveis do conhecido
Sistema Gerenciador de Bando de Dados (SGBD) da Microsoft. Entre outras
funcionalidades disponíveis, esta ferramenta destaca-se pela integração total com sua
versão para dispositivos não móveis e o Visual Studio 2005 (MICROSOFT, 2008).
Com essa integração, é possível desenvolver um banco de dados no próprio Visual
Studio, sem a necessidade de uma interface alheia.
O processo efetivo de comunicação inicia-se neste aplicativo do módulo de
comunicação. O quadro 44 apresenta partes do código fonte da classe RecebeDados
com o método recebeUnidadeNegocio, essa classe tem por objetivo fazer toda a
transferência dos dados das unidades de negócio cadastradas no banco de dados da
empresa para o PDA.
Com o Visual Studio é possível inserir referências web em um projeto. Com
essa funcionalidade tem-se facilmente a possibilidade de utilizar um web service, por
exemplo, como se fosse uma classe do projeto. Para adicionar uma referência web no
Visual Studio basta seguir os seguintes passos:
• No menu principal do Visual Studio, clicar em Project, Add Web
Reference;
• Em Url, definir o endereço do web service;
• Em Web reference name indicar o nome da referência web, que é o nome
da classe para gerenciar a referência criada.
1
2
3
4
5
2
QUADRO 44 - Classe RecebeDados do aplicativo para PDA do módulo de comunicação
using PDA.Control;
using ModelagemSistema;
namespace PDA.Comunicacao
{
Versão do DataReader para o provedor Firebird, utiliza-se para ler os dados obtidos com uma consulta SQL.
72
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46 }
public class RecebeDados
{
private WebServiceRetornaDados.ServicoRetornaDados servico;
public RecebeDados(String url)
{
try{
this.servico = new
WebServiceRetornaDados.ServicoRetornaDados();
this.servico.Url = url;
}
catch (Exception ex){
throw;
}
}
private void recebeUnidadeNegocio()
{
List<WebServiceRetornaDados.UnidadeNegocio> listaWs =
new List< WebServiceRetornaDados.UnidadeNegocio>();
ControleUnidadeNegocio controle = new
ControleUnidadeNegocio();
UnidadeNegocio unidadeNegocio = new UnidadeNegocio();
controle.limparTabela();
try{
ListaWs.AddRange
(this.servico.retornaUnidadesNegocio());
}
catch (Exception){
throw;
}
foreach (WebServiceRetornaDados.UnidadeNegocio
unidadeNegocioWs in listaWs)
{
unidadeNegocio.IdUnidadeNegocio =
unidadeNegocioWs.IdUnidadeNegocio;
unidadeNegocio.Codigo = unidadeNegocioWs.Codigo;
...
try{
controle.inserirUnidadeNegocio(unidadeNegocio);
}
catch (Exception){
throw;
}
unidadeNegocio = new UnidadeNegocio();
}
}
}
No quadro 44, na linha 8 é criado um objeto da referência ao web service
denominado servico; as linhas 9 à 18 mostram o método construtor da classe que
recebe por parâmetro o endereço Url do web service, dentro deste método, na linha 12
cria-se uma nova instância do objeto servico e na linha 13 é atribuida à propriedade
Url do objeto, o endereço do web service recebido por parâmetro.
As linhas 19 à 44 mostram o método responsável pela obtenção e inserção
73
dos dados no banco de dados do módulo coleta (PDA). Na linha 21 cria-se uma lista
de objetos da classe UnidadeNegocio do web service. Na linha 22 cria-se um objeto da
classe ControleUnidadeNegocio da biblioteca PDA.Control. Esse objeto é responsável
por fazer a inserção dos dados no banco do PDA (linha 37). Na linha 23 cria-se um
objeto da classe UnidadeNegocio da biblioteca ModelagemSistema.
Na linha 24 utiliza-se o método limparTabela do objeto controle, assim a
tabela é esvaziada antes de iniciar o processo de inserção, evitando dados repetidos no
banco de dados. Na linha 26, a lista criada na linha 21 é populada com os dados
obtidos do método retornaUnidadesNegocio do web service. E, nas linhas 31 à 43,
cada item da lista é inserido no banco de dados do PDA.
Como já foi citado, a camada de modelo utilizada no aplicativo que recebe os
dados no PDA é a mesma utilizada no desenvolvimento dos web services
(ModelagemSistema). A camada controladora é a biblioteca PDA.Control que também
é a camada controladora do aplicativo do módulo de coleta.
A biblioteca de controle PDA.Control, responsável pelas operações de
inserção, alteração, exclusão e consulta de dados faz uso do recurso Dataset tipado
que fornece uma representação em objeto dos dados relacionais. Utilizando esse
recurso, evita-se a utilização de comandos da linguagem SQL (Structured Query
Language) no código fonte do programa, deixando essa codificação toda no Dataset.
Dessa maneira, têm-se códigos mais limpos, organizados e de fácil manutenção.
O quadro 45 mostra o método de inserção de dados na tabela
UnidadeNegocio do PDA. Esse método pertence à classe ControleUnidadeNegocio da
biblioteca PDA.Control.
1
2
3
4
5
6
QUADRO 45 - Método de inserção de dados na tabela UnidadeNegocio do PDA
public void inserirUnidadeNegocio(UnidadeNegocio unidadeNegocio)
{
BancoDadosDataSet.UnidadeNegocioDataTable tabela;
BancoDadosDataSetTableAdapters.UnidadeNegocioTableAdapter
adapter;
tabela = new BancoDadosDataSet.UnidadeNegocioDataTable();
adapter = new
BancoDadosDataSetTableAdapters.UnidadeNegocioTableAdapter();
7
this.adapter.Fill(this.tabela);
8
try
9
{
10
74
adapter.Insert(unidadeNegocio.IdUnidadeNegocio,
unidadeNegocio.Codigo,
unidadeNegocio.Localidade, unidadeNegocio.Municipio,
unidadeNegocio.Nome, unidadeNegocio.Pertencente);
12
13
14
15
16
17
}
catch (Exception)
{
throw;
}
}
No quadro 45 pode-se notar que não há nenhum código SQL. Nas linhas 3 a
6 são criados e inicializados os objetos tabela e adapter da tabela UnidadeNegocio do
Dataset. Na linha 10 é feita a inserção de dados no banco utilizando o método Insert
do objeto adapter, que recebe como parâmetros os atributos do objeto que devem ser
armazenados na tabela.
A recepção no PDA dos demais dados enviados pelo web service é feita da
mesma maneira que a recepção dos dados da tabela de unidades de negócio,
apresentado como exemplo nesta sessão.
4.4.3 Envio dos dados do PDA
O envio de dados do PDA para o banco de dados da empresa acontece
através do aplicativo PDA.Comunicacao no módulo de comunicação do sistema. O
aplicativo é responsável por buscar os dados no banco de dados do dispositivo e enviálos ao web service receptor de dados. Para obter os dados cadastrados no banco de
dados é utilizada a biblioteca controladora (PDA.Control). O quadro 46 mostra o
código
fonte
do
método
retornaAbastecimentoVeiculo
da
classe
ControleAbastecimentoVeiculo da biblioteca controladora.
QUADRO 46 - Método que retorna todos os abastecimentos de veículos armazenados no PDA
public List<AbastecimentoVeiculo>
retornaAbastecimentoVeiculo(bool ordenarData)
2
{
3
List<AbastecimentoVeiculo> lista = new
List<AbastecimentoVeiculo>();
4
AbastecimentoVeiculo abastecimentoVeiculo = new
AbastecimentoVeiculo();
5
...
6
7
if (ordenarData == false){
8
this.adapter.Fill(this.tabela);
1
75
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29 }
}else{
this.adapter.FillByOrderByData(this.tabela);
}
try{
foreach (BancoDadosDataSet.AbastecimentoVeiculoRow linha
in this.tabela){
abastecimentoVeiculo.IdAbastecimentoVeiculo =
linha.IdAbastecimentoVeiculo;
abastecimentoVeiculo.Data = linha.Data;
...
lista.Add(abastecimentoVeiculo);
abastecimentoVeiculo = new AbastecimentoVeiculo();
}
}catch (Exception){
throw;
}finally{
safra.mataTabela();
funcionario.mataTabela();
veiculo.mataTabela();
this.tabela.Clear();
}
return lista;
No quadro 46, a linha 1 mostra a declaração do método, que recebe o
parâmetro ordenarData, através do qual é escolhido se a busca deve retornar os dados
ordenados por data ou não. Nas linhas 3 a 5 são criados os objetos utilizados na
consulta. Nas linhas 7 a 11 é feita a consulta no banco de dados através do data set
tipado. Nas linhas 13 a 19 os dados obtidos são organizados em uma lista de
abastecimentos de veículos, a qual é retornada na linha 28.
Com a lista obtida, basta enviar os dados ao web service receptor. O quadro
47 mostra o código fonte do método responsável pelo envio através do aplicativo do
módulo de comunicação no PDA.
QUADRO 47 - Código fonte do método para o envio dos dados ao web service receptor
public void enviaAbastecimentoVeiculo()
{
ControleAbastecimentoVeiculo controle = new
ControleAbastecimentoVeiculo();
4
WebSeriviceRecebeDados.AbastecimentoVeiculo abastecimentoWs;
5
if (listaAbastecimentoVeiculo.Count > 0)
6
{
7
foreach (AbastecimentoVeiculo abastecimento in
this.listaAbastecimentoVeiculo){
8
abastecimentoWs = new
WebSeriviceRecebeDados.AbastecimentoVeiculo();
9
abastecimentoWs.IdAbastecimentoVeiculo =
abastecimento.IdAbastecimentoVeiculo;
10
abastecimentoWs.Data
= abastecimento.Data;
11
1
2
3
76
12
13
...
try{
if(servico.inserirAbastecimentoVeiculo
(abastecimentoWs)){
try{
controle.removerAbastecimentoVeiculo
(abastecimento.IdAbastecimentoVeiculo);
}catch (Exception){
throw;
}
}else{
MessageBox.Show("Mensagem de erro","Erro",
MessageBoxButtons.OK, MessageBoxIcon.Hand,
MessageBoxDefaultButton.Button1);
}
}catch (Exception){
throw;
}
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
}
}
}
No quadro 47, na linha 1, é criado o método responsável pelo envio dos
dados ao web service receptor e na linha 3 é criado um objeto da classe controladora
ControleAbastecimentoVeiculo e, na linha 4, é criado um objeto do tipo
AbastecimentoVeiculo do web service. Na linha 5 é feita uma verificação, para que os
demais comandos do método sejam executados apenas se o total de registros na lista
de abastecimentos de veículos for maior que zero, caso contrário significa que não há
dados a serem enviados, sendo assim não é necessário executar os demais comandos
do método.
Nas linhas 7 a 27 é percorrida toda a lista de dados e executados os seguintes
comandos para cada registro: nas linhas 8 a 11 os dados são empacotados no objeto
abastecimentoWs; na linha 13 são enviados os dados do registro; caso o web service
não retorne nenhuma mensagem de erro, na linha 15 esse registro é excluído, evitando
assim que o mesmo dado possa ser enviado novamente. Ao final do procedimento,
caso não ocorra nenhum erro, as tabelas de dados coletados devem estar limpas (sem
nenhum registro).
Os dados dos demais cadastros do sistema são enviados ao web service
receptor de dados de maneira semelhante ao envio dos abastecimentos de veículos,
mostrado nessa seção. No envio da tabela Atividades, conforme o requisito não
funcional NF27.3 mostrado no quadro 29 do capítulo três, apenas as atividades com o
77
status de encerrada são transmitidas.
4.4.4 Recepção e inserção dos dados no servidor
A recepção e inserção dos dados no banco de dados da empresa é feita no
web service receptor de dados denominado ServicoRecebeDados. Esse web service
tem o objetivo de receber os dados do PDA e inseri-los no banco de dados Firebird da
empresa.
Assim como o web service provedor de dados, o receptor faz uso da
biblioteca controladora WebServiceComunicacao.Control. É através dessa biblioteca
que os dados recebidos do PDA são inseridos no banco de dados da empresa. O quadro
48 mostra o código do método de inserção dos dados de abastecimentos de veículos no
banco de dados Firebird, o qual pertence à classe ControleAbastecimentoVeiculo da
biblioteca controladora WebServiceComunicacao.Control.
QUADRO 48 - Método que insere os abastecimentos de veículos no banco de dados da empresa
public bool inserirAbastecimentoVeiculo
1
(AbastecimentoVeiculo abastecimento)
{
2
bool correto = true;
3
try{
4
this.conexao.abreConexao();
5
FbCommand comando = new FbCommand("INSERT INTO
6
ABASTECIMENTOSVEICULOS VALUES"(GEN_ID”
+”(GEN_ID_ABASTECIMENTOVEICULO, 1), @DATA, @TOTALLITROS,
@VALORLITRO, " + "@IDSAFRA, @IDFUNCIONARIO, @IDVEICULO,
@VELOCIMETRO)", this.conexao.getConexao());
FbDataAdapter dataAdapter = new FbDataAdapter(comando);
7
dataAdapter.SelectCommand.Parameters.Clear();
8
dataAdapter.SelectCommand.Parameters.Add("@DATA",
9
abastecimento.Data);
. . .
10
11
if (abastecimento.Safra.IdSafra > 0){
12
dataAdapter.SelectCommand.Parameters.Add("@IDSAFRA",
abastecimento.Safra.IdSafra);
}else{
13
dataAdapter.SelectCommand.Parameters.Add("@IDSAFRA",
14
null);
}
15
. . .
16
17
dataAdapter.SelectCommand.ExecuteNonQuery();
18
78
19
20
21
22
23
24
25 }
}catch (Exception){
correto = false;
throw;
}
this.conexao.fechaConexao();
return correto;
No quadro 48, na linha 1, é declarado o método que recebe como parâmetro
um objeto da classe AbastecimentoVeiculo. Na linha 6 é criado um novo comando
SQL e nele são informados os parâmetros que recebem os dados a serem inseridos no
banco, um exemplo de parâmetro é @DATA (esse parâmetro recebe a data de um
determinado registro). Na linha 7 é criado um objeto da classe FbDataAdapter
(semelhando ao TableAdapter dos datasets tipados só que para o Firebird), nas linhas
9 a 10 são atribuídos os valores aos parâmetros.
O banco de dados da empresa aceita que os campos de chaves estrangeiras,
como é o caso do IDSAFRA, que representa um registro da tabela Safra recebam
valores nulos. Por esse motivo, nas linhas 12 a 16 são feitas checagens se os velores
recebidos são ou não nulos. Na linha 18 é executado o código SQL que insere os dados
efetivamente no banco.
Com o método de inserção no banco de dados pronto, basta desenvolver o
web service em questão para realizar a sua chamada. O quadro 49 mostra o código
fonte do método inserirAbastecimentoVeiculo do web service ServicoRecebeDados.
1
2
3
4
5
6
QUADRO 49 - Método inserirAbastecimentoVeiculo do web service ServicoRecebeDados
[WebMethod]
public bool inserirAbastecimentoVeiculo(AbastecimentoVeiculo
abastecimento)
{
bool correto = true;
7
8
9
10
11
12
13 }
ControleAbastecimentoVeiculo controle = new
ControleAbastecimentoVeiculo();
if (controle.inserirAbastecimentoVeiculo
(abastecimento)==false)
{
correto = false;
}
return correto;
79
No quadro 49, na linha 1 o método é declarado como um método web, na
linha 2 é criado o método que recebe como parâmetro todos os dados a serem inseridos
no banco de dados. Na linha 6 é criado um objeto da classe controladora
ControleAbastecimentoVeiculo e nas linhas 8 a 11 é chamado o método
inserirAbastecimentoVeiculo (quadro 48) que faz a inserção dos dados no banco.
A recepção e inserção dos dados dos demais cadastros do sistema e feita de
forma semelhante à recepção e inserção dos dados de abastecimentos de veículos
mostrado nessa seção.
4.5 Módulo de coleta de dados
O módulo de coleta de dados do sistema tem por objetivo possibilitar ao
usuário o cadastro de informações de interesse da empresa em um PDA. Esse módulo
consiste em um aplicativo para PDA, desenvolvido com a ferramenta Visual Studio e a
linguagem C#. As informações coletadas ficam temporariamente armazenadas no
banco de dados do PDA, até que sejam transmitidas ao banco de dados da empresa
através do módulo de comunicação.
Assim como os demais aplicativos do sistema, o módulo de coleta faz uso
das camadas de modelo (biblioteca ModelagemSistema) e controladora (biblioteca
PDA.Control).
4.5.1 Designar unidade de negócio
Quando se desenvolve algum tipo de aplicativo para dispositivos móveis,
tem-se que pensar, além das funcionalidades desejadas, em desempenho, evitando
processamentos e ocupações desnecessárias de memória, além de aspectos que
facilitem a utilização do aplicativo pelo usuário.
Muitos recursos da empresa em questão são alocados por unidades de
negócios, como é o caso dos veículos, por exemplo. Cada unidade de negócio tem seus
próprios veículos, sendo assim, em um cadastro de abastecimento ou utilização de
veículos o usuário deve ter a opção de ocultar os veículos que não dizem respeito a sua
80
unidade de negócio.
Para que seja possível efetuar tal filtro nos dados é necessário conhecer a
unidade de negócio na qual se está trabalhando. O módulo de coleta de dados do
sistema, ao ser iniciado, verifica no banco de dados do PDA qual unidade de negócio
está designada como a pertencente a este dispositivo. Após feita a verificação, o
aplicativo armazena em memória o número de identificação da unidade de negócio e
utiliza-o para filtrar os registros quando necessário.
Caso não haja nenhuma unidade de negócio designada ao PDA, o aplicativo
não permite que o usuário faça algum cadastro sem antes designar uma unidade de
negócio para o PDA.
4.5.2 Coleta dos dados
O objetivo do módulo de coleta de dados é proporcionar ao usuário a
possibilidade de registrar no PDA dados com relação às atividades desenvolvidas nas
unidades de negócio da empresa. Para ilustrar essa funcionalidade é apresentado a
seguir o cadastro de abastecimento de veículos, atividade essa que é executada na
empresa.
O cadastro de abastecimento de veículos possibilita ao usuário do sistema
visualizar, inserir, alterar e excluir registros. A primeira etapa deste cadastro deve
demonstrar todos os registros efetuados, bem como as opções de ações sobre esses
registros. A interface gráfica da primeira etapa do cadastro pode ser vista na figura 18.
81
FIGURA 18 - Interface gráfica da primeira etapa do cadastro de abastecimento de veículos
Nesta interface são apresentados os dados já cadastrados, obtidos através do
método
retornaAbastecimentoVeiculo
da
classe
ControleAbastecimentoVeiculo
pertencente à biblioteca PDA.Control (camada controladora do sistema). O quadro 50
mostra o código fonte deste método.
QUADRO 50 - Método retornaAbastecimentoVeiculo da classe ControleAbastecimentoVeiculo
public List<AbastecimentoVeiculo>
retornaAbastecimentoVeiculo(bool ordenarData)
2
{
3
List<AbastecimentoVeiculo> lista =
new List<AbastecimentoVeiculo>();
4
AbastecimentoVeiculo abastecimentoVeiculo =
new AbastecimentoVeiculo();
5
ControleSafra safra = new ControleSafra();
6
7
...
8
9
if (ordenarData == false){
10
this.adapter.Fill(this.tabela);
11
}else{
12
this.adapter.FillByOrderByData(this.tabela);
13
}
14
15
try{
16
foreach (BancoDadosDataSet.AbastecimentoVeiculoRow
17
linha in this.tabela){
18
abastecimentoVeiculo.Data = linha.Data;
19
abastecimentoVeiculo.TotalLitros = linha.TotalLt;
20
...
21
lista.Add(abastecimentoVeiculo);
22
abastecimentoVeiculo = new AbastecimentoVeiculo();
23
}
24
}
25
...
26
return lista;
27 }
1
82
No quadro 50, a linha 1 mostra a declaração do método, que recebe por
parâmetro uma variável do tipo bool (verdadeiro ou falso) na qual é informado
verdadeiro se os dados buscados devem ser ordenados por data ou falso se não. Na
linha 3 é criada a lista a ser retornada ao final do método e nas linhas 4 à 7 são criados
os demais objetos necessários para o funcionamento do método.
Nas linhas 9 à 13 é feita a chamada aos métodos do dataset responsável pela
busca no banco de dados. Nas linhas 16 à 23 todos os registros obtidos com a busca no
banco de dados são inseridos na lista de abastecimento de veículos, que é retornada na
linha 26.
Ainda na interface principal do cadastro, figura 18, abaixo dos dados já
cadastrados, estão dispostos três botões que assumem ações distintas. O primeiro inicia
a interface de inserção; o segundo inicia a interface de inserção já populando os
campos com os dados do registro selecionado da grade de registros, para que o usuário
possa alterá-los; e o terceiro possibilita a exclusão do registro selecionado. O quadro
51 mostra o código fonte de cada botão, ou seja, as ações que eles tomam quando são
invocados (clicados).
1
2
QUADRO 51 - Código fonte das ações dos botões da interface principal de cadastro.
//Botão Novo
FormAbastecimentoVeiculoEditar form = new
FormAbastecimentoVeiculoEditar(funcionarios, safras,
veiculos, true, IdUnidadeNegocio, 0);
form.ShowDialog();
form = null;
montaTabela();
3
4
5
6
//Botão Alterar / Visualizar
7
8
if (tabela.Rows.Count != 0)
9
{
10
FormAbastecimentoVeiculoEditar form = new
FormAbastecimentoVeiculoEditar(funcionarios, safras,
veiculos,
false, IdUnidadeNegocio, (int)dataGrid1.Tag);
11
form.ShowDialog();
12
form = null;
13
montaTabela();
14
15 }else
16 {
17
visual.mensagemAlerta("Não há registros cadastrados", "");
18
}
19
20
83
//Botão Excluir
21 if (visual.mensagemConfirmacao("Deseja reamente remover o
22 registro?","Confirmação")==DialogResult.Yes)
23 {
controle.removerAbastecimentoVeiculo((int)dataGrid1.Tag);
24
abastecimentoVeiculoBindingSource.RemoveAt
25
(abastecimentoVeiculoBindingSource.Position);
26
dataGrid1.Refresh();
visual.mensagemSimples("Registro excluido com sucesso", "OK");
}
No quadro 51, as linhas 2 à 5 mostram a ação quando o botão novo é clicado,
essa ação repete-se com algumas alterações no botão alterar (linhas 7 à 17). Na linha 2
é criado e inicializado o formulário de inserção, passando por parâmetro as listas de
veículos, funcionários e safras, o valor true que informa ao formulário que a ação é de
inserção (novo registro), além do campo id da unidade de negócio e o valor 0 (zero).
Na linha 10 ocorre a criação do formulário para a alteração de um registro.
Suas diferenças em relação à criação de um novo registro é indicada pelos parâmetros
false, que informa ao formulário que não é um novo registro, e o id do abastecimento
de veículo do registro selecionado na grade de registros.
Nas linhas 3 e 11 o formulário é mostrado. Nas linhas 4 e 12 o formulário é
limpo da memória (após ser fechado) e nas linhas 5 e 13 é chamado o método que
atualiza a grid de registros após a inserção ou alteração.
Nas linhas 20 à 26 do quadro 47 é mostrado o código responsável por excluir
um registro selecionado na grade de registros. Na linha 20 é criada uma caixa de
diálogo que pede uma confirmação de exclusão para o usuário; no caso da
confirmação ser positiva, executam-se as linhas 22 à 25 que, respectivamente, excluem
o registro do banco de dados e do grid, atualizam este grid e exibem uma mensagem
confirmando a exclusão.
Na interface para a inclusão e alteração dos registros são usados os seguintes
componentes: combobox para mostrar a lista de veículos, funcionários e safras
cadastradas; um calendário para ser selecionada a data do abastecimento; textbox para
ser digitado o total de litros, valor do litro, velocímetro e mostrar se a safra selecionada
é a atual; um checkbox para o usuário escolher se todos os veículos ou apenas os
veículos da unidade de negócio devem ser mostrados e três botões para executar as
84
ações desejadas. Na figura 19 é mostrada essa interface gráfica.
Com a interface gráfica desenvolvida, a primeira ação a ser tomada é a
população dos comboboxes. O formulário recebe como parâmetro as listas de veículos,
funcionários e safras da interface anterior e insere-as nos comboboxes.
Recebendo os dados como parâmetro, não se tem a necessidade de buscá-los
no banco de dados, o que toma muito tempo de processamento, atrasando as ações do
usuário. A busca e montagem dessas listas são feitas por uma Thread executada ao ser
criada a primeira interface (figura 18). Assim, no mesmo momento em que a interface
é criada, é feita a busca no banco de dados e a montagem das listas que,
posteriormente, são enviadas por parâmetro para a interface de inserção e alteração
(figura 19). No quadro 52 é mostrado o código fonte da busca e população das listas,
bem como a execução através de uma Thread.
FIGURA 19 - Interface gráfica para a inclusão e alteração de abastecimento de veículo
1
2
3
4
5
6
7
8
QUADRO 52 - Thread que efetua a busca de dados essenciais para o cadastro.
private void obtemDadosParaCadastro()
{
controleSafra = new ControleSafra();
controleFuncionario = new ControleFuncionario();
controleVeiculo = new ControleVeiculo();
safras.AddRange(controleSafra.retornaSafras());
funcionarios.AddRange
(controleFuncionario.retornaFuncionarios());
85
9
veiculos.AddRange(controleVeiculo.retornarVeiculos());
10
11
Thread.Sleep(100);
12 }
13
14 //Criação e chamada da Thread no método construtor da classe
15
16 Thread thread1 = new Thread(new
ThreadStart(obtemDadosParaCadastro));
17 thread1.Start();
No quadro 52, nas linhas 3 a 5, são incializados os objetos das classes de
controle de safra, controle de funcionário e controle de veículo. Com esses objetos é
possível obter os dados cadastrados de cada tabela no banco de dados (tabelas de
safras, funcionários e veículos). Nas linhas 7 à 9, as listas de safras, funcionários e
veículos são populadas com os dados do banco. Na linha 11 a thread é colocada em
espera por 100 milisegundos. Nas linhas 16 e 17, a thread é criada e iniciada.
Os quadros 53 e 54 mostram o código fonte responsável por executar as
funções do formulário de inserção e alteração.
QUADRO 53 - Código fonte do formulário de inserção e alteração de abastecimento de veículo I
...
1
using ModelagemSistema;
2
using PDA.Control;
3
4
namespace PDA.Coleta
5
{
6
public partial class FormAbastecimentoVeiculoEditar : Form{
7
private bool novoRegistro;
8
private int idUnidadeNegocio;
9
private FerramentasVisuais visual=new FerramentasVisuais();
10
private List<Funcionario> listaFuncionarios =
11
new List<Funcionario>();
...
12
public FormAbastecimentoVeiculoEditar(List<Funcionario>
13
lisFun,List<Safra> lisSaf,List<Veiculo> lisVei, bool
novoRegistro,int idUnidadeNegocio, int idAbastecimento){
this.novoRegistro = novoRegistro;
14
15
this.idUnidadeNegocio = idUnidadeNegocio;
16
populasListas(lisFun, lisSaf, lisVei);
17
InitializeComponent();
18
populaCombos();
19
limparCampos();
20
if (this.novoRegistro == false){
21
btnFinalizar.Enabled = false;
22
btnConfirmar.Text = "Alterar";
23
populaCampos(idAbastecimento);
24
}
25
}
26
private void populasListas(List<Funcionario> lisFun,
List<Safra> lisSaf, List<Veiculo> lisVei){
86
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
if (listaFuncionarios.Count > 0)
listaFuncionarios.Clear();
...
listaFuncionarios.AddRange(lisFun);
...
}
private void populaCombos(){
bindingVeiculo.DataSource = listaVeiculos;
comboVeiculo.Refresh();
...
}
private void atualizaComboVeiculo(){
if (checkVeiculosDemaisUN.Checked==false){
listaVeiculos = new List<Veiculo>();
listaVeiculos.AddRange
(controleVeiculo.retornarVeiculos());
bindingVeiculo.DataSource = listaVeiculos;
comboVeiculo.Refresh();
comboVeiculo.Text = "";
}else if (checkVeiculosDemaisUN.Checked == true){
listaVeiculos = new List<Veiculo>();
listaVeiculos.AddRange(controleVeiculo.
retornarVeiculosPorUn(idUnidadeNegocio));
bindingVeiculo.DataSource = listaVeiculos;
comboVeiculo.Refresh();
comboVeiculo.Text = "";
}
}
private void limparCampos(){
if (novoRegistro==true){
comboVeiculo.Text = null;
...
}
textTotalLt.Text = "";
funcionario = new Funcionario();
...
}
private void populaCampos(int idAbastecimento){
abastecimento = controle.
retornaAbastecimentVeiculoPorId(idAbastecimento);
if (abastecimento.Safra.Atual == true){
textSafraAtual.Text = "Sim";
}else{
textSafraAtual.Text = "Não";
}
textTotalLt.Text =
Convert.ToString(abastecimento.TotalLitros);
safra = abastecimento.Safra;
combo.SelectedValue = safra.IdSafra;
}
No quadro 53, as linhas 2 e 3 fazem referência às camadas de modelo e
controladora do sistema; na linha 7 é declarada a classe, herdando as característcas da
classe Form uma vez que essa classe é um formulário (interface gráfica); nas linhas 8 a
12 são declarados todos os objetos e listas necessárias ao funcionamento da classe. Nas
linhas 13 à 25 é declarado o método construtor da classe.
Na linha 14 é atribuído à variável novoRegistro o valor recebido por
87
paramêtro (true tratando-se de um novo registro e false se não, sendo assim uma
alteração ou visualização). Na linha 15 é atribuído à variável idUnidadeNegocio o
valor recebido por parâmetro, esse valor diz respeito à unidade de negócio designada
para o PDA utilizado.
Na linha 16 é chamado o método populasListas (linhas 26 à 32) que é
responsável por popular as listas de veículos, funcionários e safras com os valores
recebidos por parâmetro. Na linha 17 é chamado o método InitializeComponent que é
criado pelo Visual Studio, sendo responsável pela inicialização dos componentes
visuais do formulários. Na linha 18 é chamado o método populaCombos (linhas 32 à
37), que é responsável por preencher os comboboxes com os dados das listas, por fim é
chamado, na linha 19, o método limparCampos (linhas 54 à 62), responsável por
atribuir valores nulos aos componentes visuais da classe.
Na linha 20 é feita uma verificação, se a variável novoRegistro possuir o
valor false significa que não se trata de uma inclusão e sim de uma alteração ou
visualização de registro. Sendo assim, na linha 21 o botão finalizar é desabilitado, o
botão confirmar recebe o texto Alterar; nas linhas 22 e 23 é chamado o método
populaCampos (linhas 62 à 73) que atribuí aos componentes visuais os valores do
registro a ser alterado ou visualizado.
QUADRO 54 - Código fonte do formulário de inserção e alteração de abastecimento de veículo II
...
1
private void gravarDados(){
2
if (comboVeiculo.Text.Equals("")){
3
veiculo = new Veiculo();
4
}else{
5
veiculo = buscaVeiculoLista
6
((int)comboVeiculo.SelectedValue);
7
}
8
abastecimento.Veiculo = veiculo;
9
...
10
if (novoRegistro == true){
11
controle.inserirAbastecimentoVeiculo
12
(abastecimento);
visual.mensagemSimples("Mensagem", "OK");
13
}else if (novoRegistro == false){
14
controle.alterarAbastecimentoVeiculo
15
(abastecimento);
visual.mensagemSimples("Mensagem", "OK");
16
}
17
}
18
19 private Funcionario buscaFuncionarioLista(int idFuncionario){
Funcionario func =
20
88
listaFuncionarios.Find(new Predicate<Funcionario>(
delegate(Funcionario funcionario) { return
funcionario.IdFuncionario == idFuncionario; }
));
return func;
21
22 }
23 private void inputPanel1_EnabledChanged(object sender,
EventArgs e){
if (inputPanel1.Enabled == true){
24
this.FormBorderStyle = FormBorderStyle.None;
25
this.AutoScroll = true;
26
this.Height -= inputPanel1.Bounds.Height;
27
}
28
if (inputPanel1.Enabled == false){
29
this.Height += inputPanel1.Bounds.Height;
30
this.AutoScroll = false;
31
32
this.FormBorderStyle = FormBorderStyle.FixedSingle;
33
}
34
}
35 private void checkVeiculosDemaisUN_CheckStateChanged
(object sender, EventArgs e){
36
atualizaComboVeiculo();
37 }
38 private void btnConfirmar_Click(object sender, EventArgs e){
39
if (novoRegistro == true){
40
gravarDados();
41
limparCampos();
42
}else{
43
gravarDados();
44
this.Close();
45
}
46 }
47 private void btnCancelar_Click(object sender, EventArgs e){
48
if (novoRegistro == true){
49
limparCampos();
50
}else{
51
this.Close();
52
}
53 }
54 private void comboSafra_SelectedValueChanged
(object sender, EventArgs e){
55
if (comboSafra.SelectedItem != null){
56
safra = buscaSafraLista
(Convert.ToInt32(comboSafra.SelectedValue));
57
if (safra.Atual == true){
58
textSafraAtual.Text = "Sim";
59
}else{
60
textSafraAtual.Text = "Não";
61
}
62
}
63 }
64 private void btnFinalizar_Click(object sender, EventArgs e){
this.Close();
65 }
66 private void comboSafra_LostFocus(object sender, EventArgs e){
67
if (comboSafra.Text==""){
68
textSafraAtual.Text = "";
69
}
70
}
71 }
72 }
89
No quadro 54, nas linhas 2 à 18 é mostrado o método gravarDados. Esse
método inicia a execução fazendo a seguinte verificação: caso a variável novoRegistro
tenha o valor true, ele chama o método inserirAbastecimentoVeiculo da classe
ControleAbastecimentoVeiculo, que insere um novo registro de abastecimento de
veículo; caso o valor seja false, é chamado o método alterarAbastecimentoVeiculo que
altera um determinado registro.
Nas linhas 23 à 34 é criado um evento no componente inputPanel
(responsável por gerenciar o teclado virtual do Windows Mobile). Esse evento faz com
que, ao ser mostrado o teclado, a tela tenha seu tamanho diminuído, evitando assim
que o teclado virtual a sobreponha.
As classes controladoras responsáveis por salvar os dados cadastrados no
banco de dados do PDA são as mesmas utilizadas no módulo de comunicação,
mostrado no item 4.4.2 deste trabalho.
Os demais cadastros do módulo de coleta são implementados de forma
semelhante ao cadastro de abastecimento de veículos, apresentado como exemplo
nesta sessão.
4.5.3 Cópia de segurança
A cópia de segurança, no módulo de coleta, tem por objetivo criar uma cópia
do arquivo de banco de dados do PDA para qualquer outro diretório (inclusive em
cartões de memória), bem como restaurá-la se necessário. Em caso de qualquer tipo de
problema com o PDA, tendo a cópia de segurança, essa pode ser utilizada em um outro
PDA, evitando a perda de dados.
Para efetuar a cópia de segurança, utiliza-se o componente SaveDialog do
Visual Studio, bem como para recuperá-la utiliza-se o componente OpenDialog. O
quadro 55 mostra o código fonte para a criação e o quadro 56 mostra o código fonte
para a recuperação da cópia de segurança.
90
1
2
3
4
5
6
7
8
9
10
11
12
13
14
QUADRO 55 - Código fonte da criação da cópia de segurança
String diretorioSistema =
System.IO.Path.GetDirectoryName
(System.Reflection.Assembly.
GetExecutingAssembly().GetName().CodeBase);
dialogoSalvar.FileName = "BackUpColeta";
if (dialogoSalvar.ShowDialog()==DialogResult.OK)
{
try
{
System.IO.File.Copy(diretorioSistema + "\\BancoDados.sdf",
dialogoSalvar.FileName, true);
visual.mensagemSimples("Cópia efetuada com sucesso",
"Sucesso");
}
catch (Exception)
{
visual.mensagemErro("Falha ao tentar executar a cópia de
segurança", "Erro");
}
}
No quadro 55, na linha 1, é obtido o diretório atual do sistema, na linha 3 é
chamado o SaveDialog e na linha 7 o arquivo de banco de dados é copiado para o
diretório escolhido no SaveDialog.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
QUADRO 56 - Código fonte para a recuperação da cópia de segurança
String diretorioSistema = System.IO.Path.GetDirectoryName
(System.Reflection.Assembly.GetExecutingAssembly().
GetName().CodeBase);
if (dialogoAbrir.ShowDialog()!= DialogResult.Cancel)
{
try
{
System.IO.File.Copy(dialogoAbrir.FileName,
diretorioSistema + "\\BancoDados.sdf", true);
visual.mensagemConfirmacao("Cópia de segurança
recuperada com sucesso. Você deve reiniciar seu PDA "+
"para completar esse processo ")
}
catch (Exception)
{
visual.mensagemErro("Falha ao recuperar cópia de
segurança", "Erro");
}
}
No quadro 56, na linha 1, é obtido o diretório atual do sistema; na linha 2 é
chamado o OpenDialog; na linha 6 é copiado o arquivo de banco de dados do diretório
obtido através do OpenDialog para o diretório do programa; na linha 7 o aplicativo
solicita ao usuário que reinicie o PDA. Reiniciar o PDA é necessário para completar o
91
processo de recuperação da cópia de segurança.
4.6 Conclusão
Este capítulo tem o objetivo de mostrar como o sistema foi desenvolvido,
utilizando a ferramenta Visual Studio e a linguagem C#. Com os exemplos de código
fonte é possível ter uma noção exata dos comandos e classes utilizados no
desenvolvimento dos diferentes módulos e aplicativos do sistema. O estudo sobre
MVC e web services também enriqueceu o trabalho. Com o MVC pôde-se estruturar o
sistema de maneira mais clara e elegante, facilitando a manutenção e leitura dos
códigos fonte das classes desenvolvidas. Com o uso de web services pôde-se efetuar a
transmissão dos dados através da rede mundial de computadores, evitando assim o
deslocamento de dispositivos entre as unidades de negócio da empresa.
92
5 APRESENTAÇÃO DO SISTEMA
Neste capítulo apresenta-se o sistema desenvolvido, para isso foram feitos
testes nos dois módulos (comunicação e coleta de dados) com o objetivo de identificar
possíveis falhas, bem como certificar-se do funcionamento do mesmo. Os testes são
feitos conforme a arquitetura apresentada no capítulo 4, testando o módulo de
comunicação e, em seguida, o módulo de coleta com todas as suas funcionalidades.
5.1 Módulo de comunicação
O módulo de comunicação faz a transmissão dos dados da empresa para o
PDA, bem como do PDA para a empresa. Para isso são utilizados dois web services e
um aplicativo no PDA. Depois de feito um processo de comunicação, espera-se que o
banco de dados da empresa contenha todos os dados coletados com o PDA e no PDA
estejam disponíveis os dados necessários para o funcionamento do módulo de coleta.
5.1.1 Web service provedor de dados
O primeiro aplicativo do sistema testado é o web service provedor de dados.
Esse tem como o objetivo dispor ao cliente (aplicativo que faz uso) os dados contidos
no banco de dados da empresa, essenciais ao funcionamento do módulo de coleta do
sistema.
Para colocar o web service em funcionamento é necessário um servidor web
com suporte ao asp.net. Neste trabalho é usado o IIS (Internet Information Service) da
Microsoft. Para testar o funcionamento do web service basta acessar o arquivo
ServicoRetornaDados.asmx com um programa de visualização web, como o Internet
93
Explorer da Microsoft.
Ao acessar o arquivo, são exibidos todos os métodos declarados como
WebMethod (figura 20). Clicando sobre o método desejado, abre-se outra página com
a indicação: To test the operation using the HTTP POST protocol, click the 'Invoke'
button (figura 21). Ao clicar no botão Invoke uma nova página é aberta com o
resultado do método no formato XML (Extensible Markup Language), como pode ser
visto na figura 22.
Para testar os demais métodos do web service provedor de dados basta seguir
os mesmos passos mostrados nessa seção, uma vez que todas as consultas são feitas de
forma semelhante ao método retornaUnidadeNegocio.
FIGURA 20 - Acessando o arquivo ServicoRetornaDados.asmx
94
FIGURA 21 - Acessando o método retornaUnidadesNegocio
FIGURA 22 - Resultado da execução do método retornaUnidadeNegocio
95
5.1.2 Web service receptor de dados
O web service receptor de dados é responsável por receber os dados
coletados no PDA e inserí-los no banco de dados da empresa. Cada método de
inserção retorna um valor do tipo booleano (verdadeiro ou falso) que indica se os
dados foram inseridos corretamente no banco.
Para testar o web service receptor de dados, a exemplo do provedor, é
utilizado o IIS e o Internet Explorer. Acessando o arquivo ServicoRecebeDados.asmx
tem-se as interfaces apresentadas nas figuras 23 e 24. Na figura 23 são apresentados
todos os métodos do web service (WebMethod) e na figura 24 é apresentado o
formulário para testar o método inserirAbastecimentoMaquina.
FIGURA 23 - Acessando o arquivo ServicoRecebeDados.asmx
96
FIGURA 24 - Acessando o método inserirAbastecimentoMaquina
O IIS cria a interface de teste apenas se os parâmetros do método forem de
tipos de dados primitivos da linguagem, o que não ocorre no trabalho em questão, uma
vez que é enviado um objeto como parâmetro. Para demonstrar essa interface foi
criado o referido método com os parâmetros sendo dados primitivos e, após o término
do teste, alterado à realidade do sistema em questão.
Na figura 25 é mostrada a interface que o sistema apresenta após a inserção
dos dados, retornando em formato XML um valor booleano indicando se o cadastro
foi inserido com sucesso.
97
FIGURA 25 - Resultado da execução do método inserirAbastecimentoMaquina
5.1.3 Aplicativo de comunicação no PDA
O aplicativo de comunicação no PDA tem a função de enviar os dados
coletados ao web service receptor e receber os dados essenciais ao funcionamento do
módulo de coleta do web service provedor de dados.
O aplicativo busca em um arquivo XML os endereços dos web services, bem
como permite a alteração desses endereços. Dessa maneira, em caso de mudança dos
endereços, basta ao usuário atualizá-los por meio da interface apresentada na figura 26.
Com os endereços dos web services corretos, basta ao usuário clicar sobre o
botão Iniciar comunicação e aguardar até o término do processo, conforme
apresentado na figura 27.
98
FIGURA 26 - Interface de alteração dos endereços dos web services no aplicativo do módulo
de comunicação no PDA.
FIGURA 27 - Interface do processo de comunicação no PDA
99
Para verificar se o processo funcionou corretamente, basta acessar o arquivo
BancoDados.sdf no PDA, utilizando o programa Query Analyzer (disponível com o
Microsoft SQL Server Mobile) e buscar os dados armazenados. Na figura 28 apresentase a tabela de unidade de negócios (dados recebidos do web service provedor) e na
figura 29 apresenta-se a tabela de abastecimento de veículos (dados enviados ao web
service receptor).
FIGURA 28 - Resultado da etapa de obtenção de dados com o aplicativo do módulo de
comunicação no PDA
Na figura 28, a interface da esquerda mostra a aba Grid da tabela
UnidadeNegocio em branco, uma vez que até então não há dado algum no banco de
dados do PDA. Ainda na figura 28, a interface da direita apresenta a aba Grid após
efetuada a comunicação com o web service provedor de dados. Nesse momento, a
tabela contém cinco registros, que são os registros cadastrados no banco de dados do
PDA, os quais foram obtidos por meio do web service do banco de dados da empresa.
Na figura 29, a interface da esquerda mostra a aba Grid da tabela
AbastecimentoVeiculo com os registros cadastrados no PDA por meio do módulo de
coleta. Após efetuada a comunicação, os dados são enviados ao banco de dados da
empresa e a mesma tabela deve estar sem nenhum registro, conforme pode ser visto na
100
interface da direita na figura 29.
FIGURA 29 - Resultado da etapa de envio de dados com o aplicativo do módulo de
comunicação no PDA
Para certificar-se completamente do funcionamento do módulo de
transmissão, é preciso verificar se os dados transmitidos foram inseridos no banco de
dados da empresa. Na figura 30 é mostrada a tabela ABASTECIMENTOVEICULO do
banco de dados no servidor antes do processo de comunicação. Nesse momento a
tabela não tem registro algum. Na figura 31 é mostrada a mesma tabela após o
processo de comunicação, com os dados coletados pelo módulo de coleta do sistema.
FIGURA 30 - Tabela ABASTECIMENTOVEICULO do banco de dados da empresa antes do
processo de comunicação
101
FIGURA 31 - Tabela ABASTECIMENTOVEICULO do banco de dados da empresa depois
do processo de comunicação
5.2 Módulo de coleta de dados
O módulo de coleta de dados é responsável por coletar os dados em campo e
armazená-lo eu um dispositivo PDA para posterior transferência. Esse módulo é
constituído de um aplicativo instalado em um PDA que tem três funções básicas, são
elas: designar unidade de negócio, coleta de dados e cópia de segurança.
5.2.1 Designar unidade de negócio
Com a função designar unidade de negócio é possível atribuir ou alterar uma
única unidade de negócio ao PDA em uso. Dessa maneira é possível filtrar os dados
evitando que o usuário tenha contato direto com dados que não dizem respeito à
unidade de negócio à qual pertence.
Para designar uma unidade de negócio a um PDA basta acessar na interface
principal a opção Alterar unidade de negócio. Uma nova janela é mostrada e o usuário
pode escolher a unidade de negócio que deseja atribuir ao PDA. A figura 32 mostra as
etapas para designar ou alterar uma unidade de negócio.
Caso o PDA não tenha uma unidade de negócio atribuída, ao iniciar o
aplicativo de coleta é mostrada uma mensagem alertando o usuário. Neste caso, não é
possível acessar nenhum recurso do aplicativo (exceto cópia de segurança) como pode
ser visto da figura 33.
102
FIGURA 32 - Designado ou alterando uma unidade de negócio no PDA
FIGURA 33 - Alertas mostrado a não designação de uma unidade de negócio
5.2.2 Coleta de dados
A função de coleta de dados representa os cadastros efetuados com o módulo
de coleta no dispositivo PDA. É com essa função que os dados referentes às atividades
nas unidades de negócios da empresa são coletados.
103
As interfaces dos cadastros têm a seguinte estrutura: a primeira tela mostra
os registros já cadastrados e as funções que podem ser executadas com eles. Ao
escolher uma função de edição de um registro (inclusão ou alteração), uma nova tela é
mostrada para a execução dessa função.
Para exemplificar a função de coleta de dados são mostradas na figura 34 as
interfaces de cadastro de abastecimento de veículo. O aplicativo ainda proporciona os
cadastros de: abastecimento de máquina; atividade; atividade por funcionário;
utilização de insumo; utilização de máquina; utilização de material; e utilização de
veículo.
FIGURA 34 - Interfaces do cadastro de abastecimento de veículo
Para comprovar a inserção dos dados no banco de dados do PDA, a figura 35
mostra a tabela AbastecimentoVeiculo sem nenhum dado na interface da esquerda e, na
interface da direita, a mesma tabela com os dados cadastrados através do aplicativo do
módulo de coleta de dados.
104
FIGURA 35 - Resultado da etapa de coleta de dados com o aplicativo do módulo de coleta
no PDA
O cadastro de atividades realizadas tem algumas diferenças com relação ao
cadastro de abastecimento de veículos. A primeira delas é a possibilidade de filtrar as
atividades e mostrar na tela apenas as encerradas, as não encerradas ou todas as
atividades, conforme as necessidades do usuário. A figura 36 mostra a primeira
interface do cadastro de atividades. A alteração ou inserção de novas atividades ocorre
de forma semelhante aos demais cadastros, conforme apresentado na figura 37.
Outra diferença com relação ao cadastro de abastecimento de veículos, é que
atrelados às atividades realizadas, estão os cadastros de funcionários por atividades,
utilização de veículos, utilização de máquinas, utilização de materiais e utilização de
insumos. Para realizar o cadastro de uma dessas funções, o usuário deve primeiro
selecionar uma atividade e depois clicar no botão Opções para atividades ou manter
pressionado na tela para que o menu apareça, conforme a figura 38. Na figura 39 é
mostrada a interface para a alteração ou inserção de funcionários em uma atividade. O
registro de utilização de máquinas, veículos, materiais e insumos em uma atividade é
feito de forma similar ao registro de funcionários.
105
FIGURA 36 - Tela inicial para cadastro de atividades
FIGURA 37 - Interface para a inserção ou alteração de uma atividade
106
FIGURA 38 - Menu de opções para atividades
FIGURA 39 - Interface para inserção de funcionário em atividade
107
5.2.3 Cópia de segurança
A função de cópia de segurança tem por objetivo proporcionar ao usuário do
aplicativo a possibilidade de efetuar uma cópia fiel do banco de dados do PDA. Essa
funcionalidade é de grande importância, pois a cópia pode ser feita em uma mídia
removível (cartão SD, por exemplo) que pode ser guardada e recuperada em outro
PDA, no caso de qualquer avaria do equipamento.
A interface apresentada quando o usuário efetua uma cópia de segurança é
gerada automaticamente pelo componente SaveFileDialog do Visual Studio. A
linguagem das etiquetas mostradas respeita a língua da verão do Windows Mobile (no
caso do emulador do Visual Studio tem-se a língua inglesa). A figura 40 mostra essa
interface, que tem os seguintes campos:
• Name: Nome do arquivo de cópia de segurança;
• Folder: Diretório de destino da cópia de segurança;
• Type: Tipo do arquivo, essa opção não pode ser alterada, é sempre do tipo
Banco de dados;
• Location: Dispositivo no qual é efetuada a cópia de segurança (PDA,
cartão SD).
Para restaurar uma cópia de segurança é usada uma interface (figura 41)
gerada a partir do componente OpenFileDialog, que apresenta os seguintes campos:
• Folder: Nesse campo é possível escolher um diretório específico para
procurar por arquivos de cópia;
• Type: Tipo de arquivo a qual se procura, esse campo não pode ser
alterado, é sempre do tipo Banco de dados.
Após escolher as opções de busca é mostrada uma relação de todos os
arquivos encontrados, para concretizar a restauração da cópia basta clicar sobre o
arquivo desejado.
108
FIGURA 40 - Interface para efetuar uma cópia de segurança
FIGURA 41 - Interface para restaurar uma cópia de segurança
109
Para comprovar o funcionamento da cópia de segurança, a figura 42 mostra o
cadastro de abastecimento de veículo com dois registros (primeira interface). Em
seguida foi efetuada uma cópia de segurança e foram excluídos os registros (segunda
interface). Após restaurada a cópia, os dois registros são mostrados novamente
(terceira interface).
FIGURA 42 - Resultado do teste de cópia de segurança
5.3 Conclusão
O desenvolvimento deste capítulo tem grande importância no que diz
respeito à demonstração do sistema desenvolvido. Com os testes de coleta e
comunicação de dados foi possível demonstrar o sistema e todas as suas
funcionalidades. Além de demonstrar o sistema em questão, tem-se o aprendizado
adquirido com relação ao sistema operacional Windows Mobile, sistema operacional
do dispositivo PDA ao qual o sistema é designado.
110
6 CONSIDERAÇÕES FINAIS
Este trabalho teve como principal enfoque o desenvolvimento de um sistema
para coleta de dados baseado em dispositivos móveis, nesse caso especificamente,
dispositivos PDA (Personal Digital Assistant). Além da coleta dos dados, o sistema
deve proporcionar a comunicação e transferência dos dados coletados para um banco
de dados em um servidor não móvel.
O primeiro objetivo específico foi fazer um levantamento dos modelos e
características dos computadores de mão disponíveis no mercado, a fim de auxiliar na
escolha de tal dispositivo para a implantação do sistema desenvolvido. Este objetivo
envolveu uma grande pesquisa em web sites, artigos científicos, revistas e livros do
gênero.
Uma dificuldade enfrentada nesta etapa foi a obtenção de materiais para
pesquisa, pois a utilização de dispositivos dessa natureza ainda é recente e existem
poucas publicações sobre esse assunto.
Apesar desta dificuldade, foram estudados diversos modelos de dispositivos
PDA, bem como ferramentas para o desenvolvimento de aplicativos para tal. Essa
etapa resultou em um quadro comparativo entre os modelos (quadro 2, mostrado no
item 2.4. deste trabalho), auxiliando na escolha de um modelo para a implantação do
sistema, o que leva a concluir que esse objetivo foi atingido com sucesso.
O estudo sobre PDA se fez priorizando dois sistemas operacionais distintos,
o Palm OS e o Wndows Mobile. Para a escolha do dispositivo mais adequado à
implantação do sistema forma observados, além do sistema operacional, os seguintes
requisitos: processador; memória total; memória para armazenamento; conexão
wireless; conexão bluetooth; dimensões da tela; possibilidade de utilização de cartão
111
de expansão de memória; e preço médio. Tendo alguns modelos com requisitos muito
parecidos, o item que pesou na escolha final foi o preço médio.
O segundo objetivo específico do trabalho foi desenvolver um aplicativo
para computadores de mão, para ser utilizado na coleta, tratamento, armazenamento e
exportação de dados. Este objetivo envolveu uma pesquisa sobre o desenvolvimento
para dispositivos PDA e um grande empenho no desenvolvimento do aplicativo.
Nesta etapa também enfrentou-se dificuldades na obtenção de materiais
bibliográficos com relação ao desenvolvimento para esse tipo de dispositivo,
dificuldade esta que foi suprida com o uso de web sites e revistas técnicas do gênero.
Apesar disto, foram desenvolvidos dois aplicativos para dispositivos PDA, o
primeiro responsável por coletar e armazenar os dados no dispositivo e o segundo
responsável pela exportação dos dados. Ambos os aplicativos tiveram um
funcionamento correto, como demonstra o capítulo 5, o que leva a concluir que esse
objetivo também foi atingido com sucesso.
A utilização do padrão MVC (Model, View, Controller) somou muito ao
sistema e ao aprendizado do autor, uma vez que esse tipo de projeto vem sendo
utilizado cada vez mais no desenvolvimento de sistemas. Com o MVC é possível
organizar o sistema em camadas independentes, facilitando alterações e a reutilização
de código.
O terceiro e último objetivo específico foi desenvolver um aplicativo, que
possa ser acessado via Internet, para receber os dados oriundos dos computadores de
mão e inseri-los em um banco de dados. Este objetivo envolveu uma pesquisa sobre a
melhor forma de desenvolvimento, sendo escolhidos os aplicativos do tipo web
service. Após definir a forma de desenvolvimento também foi feito um estudo sobre
como desenvolver esse tipo de aplicativo e foram implementados os web services
necessários. O funcionamento correto destes leva a concluir que o objetivo também foi
atingido com sucesso.
O estudo sobre web services envolveu um aperfeiçoamento sobre sistemas
distribuídos, formas de comunicação entre eles e o envio de mensagem de uma
máquina à outra. Esse estudo vem a somar ao desenvolvimento técnico do autor, uma
112
vez que, atualmente, o mercado de trabalho exige cada vez mais conhecimento em
diversas áreas da tecnologia da informação.
Com
o
sucesso
do
sistema
desenvolvido
almejam-se
futuros
aperfeiçoamentos a este, como um aplicativo de análise dos dados coletados. Com esse
aplicativo pode-se oferecer ao usuário a possibilidades de verificar os dados coletados
a autorizar ou não a inserção no banco de dados de destino. Ainda podem-se
maximizar os aplicativos para PDA, possibilitando a instalação dos mesmos em outros
tipos de dispositivos móveis, como celulares, por exemplo.
113
REFERÊNCIAS BIBLIOGRÁFICAS
ALVES, W. P. Palm OS e Windows CE: desenvolvimento de aplicações. São Paulo:
Érica, 2002. 252 p.
CRIARWEB. Sistemas Operacionais para PDA’s: Comparação entre os s.o’s mais
usados para PDA’s: Palm OS e Pocket PC. Disponível em: <http://www.criarweb.
com/artigos/611.php>. Acessado em: 10 out. 2008.
CONHEÇA A HISTÓRIA DA HP desde sua fundação em uma garagem. Folha
Online, set. 2001. Informática. Disponível em: <http://www1.folha.uol.com.br/folha/
informatica/ult124u7818.shtml>. Acessado em: 01 abr. 2008.
DEITEL, H. M. et al. C#: Como programar. São Paulo: Personal Education, 2005.
1153 p.
FIREBIRD. Firebird .NET Data Providers downloads. Disponível em: <
http://www.firebirdsql .org/index.php?op=files&id=netprovider>. Acessado em: 15.
ago. 2008.
IBGE. PDAs e questionários eletrônicos. In: IBGE. Inovações e impactos nos
sistemas de informações estatísticas e geográficas do Brasil. Rio de Janeiro: IBGE,
2008. p. 33-34.
ISAM. Motivação. Site oficial do projeto Infra-estrutura de Suporte às Aplicações
Móveis - ISAM. Disponível em: <http://www.inf.ufrgs.br/~isam/#apresentacao>.
Acessado em: 18 mar. 2008.
LAUDON, K. P.; LAUDON, J. P. Sistemas de informação: com Internet. 4. ed. Rio
de Janeiro: LTC, 1999. 389 p.
LELES, A. D. Sistemas de informação. São Paulo. Disponível em:
<http://www.sypnet.com.br/content/view/25/2/>. Acessado em: 08 out. 2008.
LOPES, R. R. F. PALMTOPS: Programabilidade e Conectividade. Rio Claro, 2006.
102 p. Disponível em: <http://www.sohand.icmc.usp.br/~rigolin/downloads/
palestra_JavaME_PalmOS_20060929.pdf>. Acessado em: 26 mar. 2008.
MATEUS, G.R.; LOUREIRO, A. A. F. Introdução à Computação Móvel. In: Escola
de Computação, COPPE/Sistemas, 11. 1998, Rio de Janeiro. Anais... Rio de Janeiro:
NCE/UFRJ, 1998. 189 p.
114
MICROSOFT. SQL Server 2005 Mobile Edition. Disponível em:
<http://www.microsoft.com/brasil/servidores/sql/editions/sqlmobile/default.mspx>.
Acessado em: 30 mar. 2008.
MICROSOFT. Como definir e utilizar propriedades no Visual C#. 2006.
Disponível em: < http://support.microsoft.com/kb/319265/pt>. Acessado em: 10 ago.
2008.
MSDN. .NET Framework. Dev Center - .NET Framework. Disponível em:
<http://www.microsoft.com/brasil/msdn/framework/default.mspx>. Acessado em: 26
mar. 2008a.
MSDN. Descrição: Herança da classe WebService. Visual Studio 2008. Disponível
em: <http://msdn.microsoft.com/pt-br/library/44cad698.aspx >. Acessado em: 11 ago.
2008b.
NETBEANS. O que é o NetBeans?. Bem vindo ao NetBeans e ao site
www.netbeans.org. Disponível em: <http://www.netbeans.org/index_pt_BR.html>.
Acessado em: 28 mar. 2008.
PALM. About Palm, Inc.. Disponível em <http://www.palm.com/us/company/>.
Acessado em: 08 out. 2008.
PAULI, G. Curso de ADO.NET e BDP – Parte I: introdução ao ado.net. Disponível
em: <http://www.devmedia.com.br/articles/viewcomp.asp?comp=586&hl=*Ado.
net*>. Acessado em: 24 jul. 2008.
PEREIRA, R. Introdução ao SuperWaba. 15 p. Disponível em:
<http://www.superwaba.org/etc/wm_introducao_ao_SuperWaba.pdf>. Acessado em:
23 mar. 2008.
PIMENTA, L. A. Trabalhando com Firebird no Visual Studio: provider para o
Firebird. Disponível em: <http://www.devmedia.com.br/articles/viewcomp.asp?
comp=1218&hl=*Firebird*%20and%20*Visual*%20and%20*Studio*>. Acessado
em: 24 jul. 2008.
SCHAAL, D. Porque Atualizar para o SQL Server 2005?. 2005. 13 p. Disponível
em: <http://download.microsoft.com/download/6/6/5/665c5f78-326a-449c-84dac42ce489f233/Why_Upgrade.doc>. Acessado em: 30 mar. 2008.
SILVA, A. Ecrã táctil vs. Operação exclusivamente com teclado. Como escolher um
equipamento Windows Mobile. Portugal, out. 2007. Disponível em:
<http://www.microsoft.com/portugal/windowsmobile/artigos/artwm.mspx>. Acessado
em: 26 mar. 2008.
SILVA, C. J. O. da. Para que serve o Web.Config?: web.config:. Disponível em: <
http://www.devmedia.com.br/articles/viewcomp.asp?comp=4498&hl=*Web.config*>.
115
Acessado em: 23 jul. 2008.
SOCRIA.NET. Produtos. Site de uma loja virtual com produtos diversos. Disponível
em: <http://loja.socria.net/images/ PDA%20ACER%20N30.jpg>. Acessado em: 30
mar. 2008.
SOUZA, M. M. SisComPM: uma proposta de comunicação entre COPOM e viaturas
policiais militares utilizando comunicação wireless. 2004. 102 f. Monografia
(Bacharelado em Ciência da Computação) – Departamento de Ciência da Computação,
Universidade Federal de Lavras – UFLA, Lavras.
TROIS, J. Palmtops para iniciantes e experts. São Paulo: Visual Books, 2003. 158 p.
UNITO SISTEMAS. Desenvolvimento no molde MVC. Disponível em:
<http://www.unito.com.br/6676>. Acessado em: 08 out. 2008.
ZENI, C. et al. Panorama do uso de computação móvel com conexão Wireless. In:
CONGRESSO BRASILEIRO DE INFORMÁTICA EM SAÚDE, 9., 2004, Ribeirão
Preto. Anais... Ribeirão Preto: CBIS, 2004. p. 1. Disponível em:
<http://www.sbis.org.br/cbis9/arquivos/625.pdf >. Acessado em: 20 mar. 2008.
WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a
objetos. Rio de Janeiro: Elsevier, 2004. 298 p.
116
BIBLIOGRAFIA COMPLEMENTAR
OGLIARI, R. Programação para PDA. Disponível em: <http://
www.mobilidadetudo.com/2006/07/programao-para-pda.html>. Acessado em: 01 out.
2007.
APÊNDICES
APÊNDICE A – MODELAGEM CONCEITUAL DO SISTEMA ......................118
APÊNDICE B – DIAGRAMA DE CLASSES DO SISTEMA ..............................119
APÊNDICE C – DIAGRAMA DE ESTADO DE NAVEGAÇÃO DO
APLICATIVO DO MÓDULO DE COLETA DE DADOS NO PDA ...................120
APÊNDICE D – DIAGRAMA DE ESTADO DE NAVEGAÇÃO DO
APLICATIVO DO MÓDULO DE COMUNICAÇÃO NO PDA .........................121
APÊNDICE E - ARTIGO .........................................................................................122
APÊNDICE A – MODELAGEM CONCEITUAL DO SISTEMA
APÊNDICE B – DIAGRAMA DE CLASSES DO SISTEMA
CE C – DIAGRAMA DE ESTADO DE NAVEGAÇÃO DO APLICATIVO DO MÓDULO DE COLETA DE DA
APÊNDICE D – DIAGRAMA DE ESTADO DE NAVEGAÇÃO DO
APLICATIVO DO MÓDULO DE COMUNICAÇÃO NO PDA
APÊNDICE E - ARTIGO
Sistema para coleta de dados baseado em dispositivos móveis
Cleiton Fernando Remor1 e Wilson Castello Branco Neto2
1
2
Curso de Sistemas de Informação da Universidade do Planalto Catarinense
(UNIPLAC) – Lages – SC – Brasil
Departamento de Ciências Exatas e Tecnológicas Universidade do Planalto Catarinense
(UNIPLAC) – Lages – SC – Brasil
[email protected], [email protected]
Abstract. This paper presents an information system for data collection based on
mobile devices, this system aims to replace the current method of data collection
from a company that works with fruits, that is not computerized. The system should
provide for user the data collection using a mobile device, in this case a PDA, it’s
also necessary do the transfer of data collected to the company's database. At the
end of the work, we can conclude that the objectives have been achieved, and the
system was collected the data and transmitted them successfully.
Resumo. Este trabalho apresenta um sistema de informação para coleta de dados
baseado em dispositivos móveis, esse sistema tem por objetivo substituir o método
de coleta de dados atual de uma empresa do ramo de produção de frutas, que é feito
de maneira não informatizada. O sistema deve proporcionar ao usuário a coleta de
dados utilizando um dispositivo móvel, neste caso um PDA, também é necessário
efetuar a transmissão dos dados coletados ao banco de dados da empresa. Ao
término do trabalho pode-se concluir que os objetivos foram atingidos, tendo o
sistema coletado dados e transmitido com sucesso.
1. Introdução
Com o avanço da concorrência entre as empresas, aumenta cada vez mais a necessidade de
obter-se dados sobre o funcionamento e trabalho de uma instituição com a maior freqüência
possível. Dessa maneira pode haver um gerenciamento de determinada instituição com maior
eficácia, neste contexto apresenta-se a coleta de dados. Em instituições com trabalho
descentralizado há a necessidade da obtenção dos dados das atividades de cada unidade, a
coleta dos dados pode ser feita de forma não informatizada, através de planilhas em papel ou
de maneira informatizada, como é mostrado neste artigo.
A informática tem, cada vez mais, tomado conta do universo dos negócios e as
empresas sentem a necessidade de informatizarem suas atividades para não perderem clientes
e mercado. Em um mundo de extrema concorrência como o atual, saem na frente as empresas
com um sistema de informação baseado em computadores [Laudon e Laudon 1999].
É uma necessidade que as empresas se adaptem às novas tecnologias e à utilização de
sistemas de informação, pois todas estão passando por um momento de extrema concorrência
por recursos de toda ordem, como fornecedores, clientes, matéria prima e tecnologia [Laudon
e Laudon 1999].
A coleta de dados não informatizada, feita basicamente com o uso de formulários em
papel e utilizada há muitos anos, traz consigo algumas dificuldades e problemas, como a
chance de perda de um determinado formulário, o mau preenchimento ou até mesmo a má
caligrafia, o que pode ocasionar o não entendimento ou distorção das informações.
Com a informatização de um sistema de coleta de dados, os problemas supracitados
são superados, uma vez que não há o manuseio de formulários em papel e a entrada de dados
se dá de maneira padronizada (não há a diferença entre caligrafias). Soma-se a isso a
possibilidade de análise e crítica dos dados através de um sistema computacional, o que pode
garantir ao usuário que os dados tenham sido coletados corretamente.
Este artigo apresenta um sistema para coleta de dados baseado em dispositivos
móveis, concebido para uma empresa que atua na produção de frutas em diversos municípios
da Serra Catarinense, essa empresa tem um grande fluxo de atividades em diferentes setores e
unidades de produção. Os dados oriundos destas atividades são coletados e centralizados em
um único banco de dados na matriz.
Neste artigo são abordados os temas relevantes à implantação do sistema. A seção 2
mostra uma introdução sobre dispositivos móveis, com ênfase maior no dispositivo PDA
(Personal Digital Assistant) e o sistema operacional Windows Mobile. A seção 3 trata da
descrição do sistema, mostrando o sistema atual utilizado pela empresa, bem como apresenta
o sistema de informação proposto para a substituição deste. A seção 4 aborda a
implementação do sistema, mostrando o paradigma de programação utilizado, a arquitetura e
o desenvolvimento do sistema. Finalizando, a seção 5 traz as considerações finais, com
algumas possibilidades de trabalhos futuros que possam enriquecer o sistema mostrado.
2. Dispositivos móveis
Para que o desenvolvimento, bem como a implantação do sistema tenham uma base sólida, é
preciso fazer um estudo teórico sobre dispositivos móveis, dando ênfase ao dispositivo PDA
com a plataforma Windows Mobile, pois é nesse dispositivo que o sistema é implantado.
Com o avanço da tecnologia e a necessidade cada vez maior de acesso contínuo a dados, temse um cenário evolutivo de comunicação entre dispositivos móveis com bancos de dados e
redes fixas, bem como com outros dispositivos móveis [Mateus e Loureiro 1998]. Nesse
cenário encontra-se a computação móvel, que, conforme [ISAM 2008], é “a computação onde
todos os elementos do sistema têm a propriedade de mobilidade”.
Pode-se, então, definir computação móvel como um paradigma de computação em que
os elementos têm a propriedade de mobilidade, bem como a possibilidade de conexão com
outros elementos, sejam eles fixos ou móveis.
2.1. PDA
O Assistente Pessoal Digital, conhecido pela sigla em inglês PDA (Personal Digital
Assistant), é um dispositivo móvel com características similares às de um computador de
mesa, pois possibilita ao usuário executar várias funções que há tempos atrás não eram
possíveis sem que se estivesse em frente a um microcomputador.
O PDA existe desde os anos 90, quando a Apple lançou o primeiro PDA do mundo, o
Newton, porém esse não foi um grande sucesso de vendas. Em 1992 nasceu a Palm Inc.,
adquirida em 1995 pela US Robotics, que lançou os primeiros Palmtops (PDA) que realmente
foram um sucesso, são eles: o Pilot 1000 e o Pilot 5000. Em 1997 a 3Com adquiriu a US
Robotics e, a partir desse ano, o mercado teve um expansão gigantesca [Trois 2003].
Na atualidade, existem dois sistemas operacionais que se destacam no mundo dos
PDA: o Palm OS e o Windows Mobile. Existem ainda outros sistema operacionais, como o
Linux e os sistema da Apple, porém é inegável que os mais utilizados sejam os primeiros
citados [Criarweb 2008].
2.3. Windows Mobile
A empresa de Softwares Microsoft entrou no mercado dos dispositivos móveis lançando a
primeira versão do seu consagrado sistema operacional de computadores de mesa Windows
para esse tipo de dispositivo, denominado Windows CE, e o ofereceu aos fabricantes, fazendo
com que logo surgissem PDA e Handles PC com esse sistema [Alves 2002].
O sucessor do Windows CE, denominado Windows Mobile, é um sistema operacional
que conta com o Windows Office Mobile Edition¸ além de uma gama de aplicativos da
empresa, como o Outlook para a leitura de e-mail. Até a versão 5.0 existem três categorias
desse sistema, são elas: Windows Mobile 2003/5.0 for Pocket PC, utilizada em equipamento
com características de organizadores pessoais, tais como PDA; Windows Mobile 2003/5.0 for
Pocket PC Phone Edition, com as mesmas características do primeiro, acrescido de uma
opção de comunicação de dados e voz sobre GSM/GPRS/3G; e, Windows Mobile 2003/5.0
for SmartPhone, sistema que se adéqua a uma utilização intensiva de telefone e com algumas
características de organizador pessoal [Silva 2007].
A partir da versão 6.0, a nomenclatura do Windows Mobile deu lugar respectivamente
à: Windows Mobile 6 Classic, equivalente ao Windows Mobile 2003/5.0 for Pocket PC;
Windows Mobile 6 Professional, equivalente ao Windows Mobile 2003/5.0 for Pocket PC
Phone Edition; e, Windos Mobile 6 Standard, equivalente ao Windows Mobile 2003/5.0 for
SmartPhone [Silva 2007].
É em um PDA com o sistema operacional Windows Mobile em que os aplicativos
móveis do sistema proposto devem ser implantados.
3. Descrição do sistema
O sistema proposto visa substituir o método atual de coleta de dados da empresa, que é feito
de forma manual. A empresa utiliza planilhas em papel em que os gerentes de cada unidade
preenchem com os dados necessários e encaminham ao setor de informática para serem
digitados, esse encaminhamento e digitação demandam de recursos e levam um tempo
considerável para serem concluídos.
Informações de suma importância ao gerenciamento da empresa, como, por exemplo,
as atividades realizadas em cada unidade de negócio, a utilização de veículos, máquinas,
materiais e insumos, que deveriam estar sempre atualizados no banco de dados, tem sua
atualização realizada com muita demora por meio do sistema manual de coleta. Somam-se a
isso, os problemas comuns a esse tipo de coleta, como por exemplo, o risco de perda de
alguma planilha, o mau preenchimento ou caligrafia deselegante, que podem ocasionar
distorções nas informações, além dos recursos demandados com a compra de papel e
transporte das referidas planilhas.
A idéia central para a informatização desse sistema é, desenvolver um aplicativo para ser
utilizado em um dispositivo móvel (PDA), capaz de coletar os dados necessários, bem como
transmiti-los ao banco de dados da empresa sempre que preciso.
O sistema deve ser capaz de coletar dados referentes às seguintes atividades que são
executadas nas unidades de negócio da empresa: abastecimento de veículos; abastecimento de
máquinas; atividades realizadas; participação de funcionários, utilização de materiais,
insumos veículos e máquinas em uma determinada atividade.
Outra função importante a qual o sistema deve desempenhar de maneira eficiente e
rápida é a transmissão desses dados ao banco de dados da empresa, para isso o meio mais
eficaz e com melhor custo/benefício encontrado é o envio dos dados através da rede mundial
de computadores (Internet). O envio através da Internet pode ser realizado de qualquer ponto
de conexão à rede, estando ou não localizado na unidade de negócio.
Além das funções de coleta e transmissão dos dados, o sistema deve proporcionar a
possibilidade de se fazer cópias de segurança dos dados já coletados, dessa forma, qualquer
avaria que possa ocorrer ao dispositivo não ocasiona a perda dos dados, garantindo assim a
integridade destes.
Com a proposta do sistema apresentado, podem-se obter resultados significativos com
relação à melhoria no processo de coleta de dados da empresa, pois a utilização de um PDA
padroniza a forma de coleta e, com a transmissão de dados pela rede mundial de
computadores, pode-se ter o banco de dados da empresa atualizado com a temporalidade
desejada pela instituição.
4. Implementação do sistema
Um sistema de informação é um tipo especializado de sistema, que pode ser definido como
um conjunto de componentes inter-relacionados trabalhando juntos para coletar, recuperar,
processar, armazenar e distribuir a informação. Geralmente um sistema de informação
computadorizado tem implementado uma grande quantidade de código e que necessita de
alterações constantes conforme as necessidades dos usuários e a legislação vigente. Por
exemplo, um sistema de vendas, por estar fortemente atrelado à legislação fiscal, em caso de
mudanças nas leis tem que ser adequado [Leles 2008].
Os sistemas de informação podem ser classificados como elegantes e deselegantes.
Um sistema elegante é aquele cuja estrutura é intrinsecamente mais fácil de compreender, que
é autodocumentado e pode ser compreendido em nível macro ou em detalhes. Ele é mais fácil
de modificar: quando alguma de suas características é mudada ele continua funcionando. Já
um sistema deselegante é feito sem uma estrutura clara, sem a utilização de padrões e sem
planejamento, um sistema deselegante não pode ser alterado sem que isso afete seu
funcionamento [Wazlawick 2004].
O sistema de informação para coleta de dados baseado em dispositivos móveis
começou a ser desenvolvido após o levantamento e organização de requisitos e a definição de
alguns pontos importantes sobre ele, tais como: o sistema deve ser orientado a objetos; o
padrão de arquitetura de software utilizado é o MVC (Model View Controller); o sistema é
divido em dois módulos, um para coleta de dados e outro para comunicação; e, para o módulo
de comunicação é utilizado a tecnologia de web services.
4.1 MVC (Model View Controller)
O MVC, que traduzido para o português significa Modelo, Visão e Controlador, consiste em
dividir uma aplicação em três camadas. A camada de modelo (Model) é a representação
específica da informação operada pela aplicação. A camada controladora (Controller) é
responsável por processar e responder a eventos, geralmente ações do usuário. A camada de
visão (View) é responsável pela interação com o sistema, essa camada envia eventos com as
ações a serem executadas para a camada controladora. Normalmente a camada de visão
trabalha como uma interface para o usuário do sistema.
Utilizar o MVC em aplicações orientadas a objetos traz algumas vantagens, como a
facilidade de manutenção do aplicativo, uma vez que as camadas são independentes uma das
outras. Sendo assim, havendo necessidade de alteração de uma camada, isso pode ser feito
sem que, necessariamente, seja preciso alterar as demais. Outra vantagem é a possibilidade de
reutilização das camadas, pois cada camada de modelo pode ser utilizada em quantos
controladores possa servir, bem como a camada controladora pode servir para quantas
camadas de visão seja necessário [Unito Sistemas 2008].
4.2 Web service
Um web service, ou serviço web, é um aplicativo armazenado em uma máquina que pode ser
acessado em outra máquina, através de uma rede. A máquina em que o web service reside é
comumente referida como máquina remota. O aplicativo que acessa o web service envia uma
chamada para a máquina remota, que processa a chamada e envia uma resposta ao aplicativo
[Deitel 2005].
Em um web service, os procedimentos são chamados pelo cliente de maneira remota,
utilizando uma chamada RPC. Os métodos no web service são marcados pelo atributo
WebMethod, tornando-se, dessa maneira, acessíveis para qualquer aplicativo por meio de uma
chamada RPC. A maioria das requisições e respostas de web service é transmitida por SOAP,
sendo assim, qualquer cliente capaz de processar mensagens SOAP pode utilizar o serviço,
independente da linguagem em que o web service esteja escrito [Deitel 2005].
4.3 Arquitetura do sistema
Para o desenvolvimento do sistema proposto, é preciso avaliar como tal sistema deve
trabalhar. Para coletar os dados necessários, o aplicativo do módulo de coleta deve ter em seu
banco de dados os registros essenciais ao seu funcionamento, por exemplo: ao coletar dados
referentes a um abastecimento de veículo é preciso que o aplicativo de coleta tenha em seu
banco tal veículo cadastrado.
O módulo de coleta recebe os dados já cadastrados no banco de dados da empresa
através do módulo de comunicação. Com os dados recebidos, pode-se efetuar a coleta de
dados nas unidades da empresa, utilizando o módulo de coleta. Por fim, os dados coletados
são enviados ao banco de dados da empresa através do módulo de comunicação, esse fluxo de
trabalho do sistema é mostrado na figura 1.
Figura 1. Fluxo de trabalho do sistema
Antes de iniciar o desenvolvimento dos módulos de comunicação e coleta, tem-se o
desenvolvimento da biblioteca responsável pela estrutura de classes do sistema. A biblioteca,
denominada ModelagemSistema implementa a camada de modelo do sistema e é utilizada em
todos os aplicativos dos módulos que o compõem.
Assim como as outras bibliotecas desenvolvidas neste trabalho, ModelagemSistema
após compilada torna-se em um arquivo do tipo DLL (Dynamic Link Library) que pode ser
acessado de qualquer aplicação desenvolvida para a plataforma .Net, dessa forma basta
desenvolver a biblioteca uma única vez, pois o mesmo arquivo serve para todos os aplicativos
do sistema.
O sistema é constituído por dois módulos, um denominado módulo de coleta de dados,
que é responsável por efetuar a coleta dos dados da empresa em campo, utilizando um
dispositivo PDA. O outro módulo, denominado módulo de comunicação, é responsável por
efetuar a comunicação e transferência de dados entre o dispositivo PDA e o banco de dados
da empresa. Os aplicativos dos dois módulos do sistema têm como camada de modelo a
mesma biblioteca (ModelagemSistema).
No módulo de comunicação, os dois web services tem como camada de visão os
arquivos ServicoRetornaDados.asmx e ServicoRecebeDados.asmx e utilizam como camada
controladora a biblioteca WebServiceComunicacao.Control.
O aplicativo do módulo de comunicação do PDA tem como camada de visão as
interfaces presentes no arquivo executável PDA.Comunicacao.exe. Já o aplicativo do módulo
de coleta tem como camada de visão as interfaces do arquivo executável PDA.Coleta.exe.
Estes dois aplicativos utilizam a mesma camada controladora, disponível na biblioteca
PDA.Control. Na figura 2 e quadro 1 é mostrado a estrutura de camadas do sistema.
Figura 2. Estrutura de camadas do sistema
Quadro 1. Estrutura de camadas do sistema
Modulo
Aplicativo
Comunicação
Comunicação
Comunicação
Coleta
Web service
Provedor
Web service
Receptor
PDA.Comuni
cacao
PDA.Coleta
Camada de
visão
ServicoRetorn
aDados.asmx
ServicoRecebe
Dados.asmx
PDA.Comunic
acao.exe
PDA.Coleta.
exe
Camada de controle
WebService
Comunicacao.Control
WebService
Comunicação.Control
PDA.Control
PDA.Control
Camada de
modelo
Modelagem
Sistema
Modelagem
Sistema
Modelagem
Sistema
Modelagem
Sistema
4.4 Módulo de coleta de dados
O módulo de coleta de dados do sistema tem por objetivo possibilitar ao usuário o cadastro de
informações de interesse da empresa em um PDA. Esse módulo consiste em um aplicativo
para PDA, desenvolvido com a ferramenta Visual Studio e a linguagem C#. As informações
coletadas ficam temporariamente armazenadas no banco de dados do PDA, até que sejam
transmitidas ao banco de dados da empresa através do módulo de comunicação.
Assim como os demais aplicativos do sistema, o módulo de coleta faz uso das
camadas de modelo (biblioteca ModelagemSistema) e controladora (biblioteca PDA.Control).
O módulo de coleta tem três funções básicas, que são apresentadas a seguir.
A primeira função é designar unidade de negócio. Essa função tem por objetivo
atribuir uma unidade de negócio da empresa ao PDA em uso, dessa maneira é possível efetuar
filtros nos dados, evitando o uso desnecessário de recursos do dispositivo, como memória, por
exemplo. Ao ser iniciado, o aplicativo verifica no banco de dados do PDA qual unidade de
negócio está designada como a pertencente a este dispositivo. Após feita a verificação, o
aplicativo armazena em memória o número de identificação da unidade de negócio e utiliza-o
para filtrar os dados quando necessário. Caso não haja nenhuma unidade de negócio
designada ao PDA, o aplicativo não permite que o usuário faça algum cadastro sem antes
designar uma unidade de negócio para o PDA.
A segunda função é a coleta de dados. Essa função possibilita ao usuário cadastrar os
dados referentes às atividades da empresa, esses dados ficam armazenados no PDA até que
sejam transmitidos ao banco de dados da empresa. Para ilustrar a coleta de dados, na figura 3
é mostrada a interface de cadastro de abastecimento de veículos. Na primeira interface são
mostrados todos os registros já efetuados, bem como as opções de ação sobre esses registros e
na segunda interface é mostrada a janela de alteração e inclusão de registros.
Figura 3. Interfaces para cadastro de abastecimento de veículos
A terceira função é a cópia de segurança. Essa função tem por objetivo criar uma
cópia do arquivo de banco de dados do PDA para qualquer outro diretório (inclusive em
cartões de memória), bem como restaurá-la se necessário. Em caso de qualquer tipo de
problema com o PDA, tendo a cópia de segurança, essa pode ser utilizada em um outro PDA,
evitando a perda de dados.
4.5 Módulo de comunicação
O módulo de comunicação faz a comunicação (envio e recebimento) dos dados entre o banco
de dados da empresa e o PDA. Ele é composto por dois web services, um denominado web
service provedor, que provê os dados essenciais para o funcionamento do módulo de coleta do
sistema, e o outro denominado web service receptor, que recebe os dados coletados no
módulo de coleta e insere-os no banco de dados da empresa. Além dos dois web services¸ o
módulo de comunicação ainda tem um aplicativo instalado no PDA responsável pelo envio e
recebimento de dados nesse dispositivo.
O web service provedor, denomidado ServicoRetornaDados tem por objetivo buscar
no banco de dados da empresa os dados necessários para que o usuário possa usar o módulo
de coleta no PDA. Seguindo o padrão MVC, o web service faz uso da biblioteca
ModelagemSistema como camada de modelo. A camada de visão é o próprio web service,
através do arquivo ServicoRetornaDados.asmx, e a camada controladora é a biblioteca
WebServiceComunicacao.Control. A figura 4 mostra o resultado de uma busca desse web
service utilizando o programa de navegação na internet Microsoft Internet Explorer.
Figura 4. Resultado de uma busca com o web service provedor
O web service receptor, denominado ServicoRecebeDados tem por objetivo receber os
dados do PDA e inseri-los no banco de dados da empresa. Seguindo o padrão MVC, o web
service faz uso da biblioteca ModelagemSistema como camada de modelo. A camada de visão
é o próprio web service, através do arquivo ServicoRecebeDados.asmx, e a camada
controladora é a biblioteca WebServiceComunicacao.Control.
O módulo de comunicação ainda tem um aplicativo no PDA, esse tem o objetivo de
receber do web service provedor, os dados essenciais à utilização do módulo de coleta, bem
como buscar todos os dados armazenados no PDA e enviá-los ao web service receptor. O
aplicativo utiliza como camada de modelo a biblioteca ModelagemSistema. A camada de
visão é a interface apresentada no executável PDA.Comunicacao.exe, e a camada
controladora é a biblioteca PDA.Control. A figura 5 mostra a interface do aplicativo.
Figura 5. Interface do aplicativo do módulo de comunicação no PDA
5. Considerações Finais
Este artigo é uma síntese do Trabalho de Conclusão de Curso com o mesmo tema, do curso de
Sistemas de Informação da Universidade do Planalto Catarinense – UNIPLAC – Lages/SC.
De forma concisa abordaram-se temas com relação à coleta de dados em organizações,
apresentando uma alternativa à coleta manual, por meio de dispositivos móveis, nesse caso
PDA, além da transferência de dados entre o dispositivo e um banco de dados central, com a
utilização de web services.
Ao término da implementação do sistema, verificou-se que esse funcionou da maneira
esperada, pois com o sistema é possível coletar, armazenar e transferir os dados para o banco
de dados da empresa em questão. Assim, pode-se concluir que todos os objetivos do trabalho
de conclusão de curso forma atingidos com sucesso.
Com a utilização do sistema, problemas encontrados com a coleta manual de dados
(utilizando planilhas em papel) foram sanados, problemas esses que variavam desde o mau
preenchimento de uma planilha ou a perda da mesma, até a demora na atualização do banco
de dados e a dificuldade para o transporte das planilhas. Utilizando o sistema, todos os dados
ficam armazenados em um único dispositivo PDA, que proporciona a realização de cópias de
segurança para garantir a integridade dos dados. A transmissão e inserção no banco de dados
se da através da rede mundial de computadores (Internet) e com a freqüência e temporalidade
desejada pelo usuário.
Após o termino do desenvolvimento do sistema, pôde-se verificar a possibilidade de
melhorias no mesmo, o que leva a incentivar futuras pesquisas para efetuar tais melhorias.
Almeja-se o desenvolvimento de um aplicativo para ser instalado na sede da empresa em que
um funcionário possa analisar os dados antes que esses sejam inseridos no banco, e melhorias
nos aplicativos do PDA, adaptando-os para outros tipos de dispositivos móveis, como
telefones celulares por exemplo.
6. Referências Bibliográficas
Alves, W. P. (2002) Palm OS e Windows CE: desenvolvimento de aplicações, Érica. São
Paulo.
Criarweb. (2008) “Sistemas Operacionais para PDA’s: Comparação entre os s.o’s mais
usados para PDA’s: Palm OS e Pocket PC” http://www.criarweb. com/artigos/611.php.
Deitel. H. M. et al. (2005) C#. Como programar.Personal Education, São Paulo .
ISAM. Motivação. (2008) “Site oficial do projeto Infra-estrutura de Suporte às Aplicações
Móveis – ISAM”, http://www.inf.ufrgs.br/~isam/#apresentacao.
Laudon, K. P.; Laudon, J. P. (1999) Sistemas de informação: com Internet, LTC, Rio de
Janeiro, 4. ed.
Leles, A. D. (2008) “Sistemas de informação”, São Paulo,http://www.sypnet.com.br/
content/view/25/2/.
Mateus, G. R.; Loureiro, A. A. F. (1998) “Introdução à Computação Móvel”. In: XI Escola de
Computação, COPPE/Sistemas, Rio de Janeiro.
Silva, A. (2007) “Ecrã táctil vs. Operação exclusivamente com teclado. Como escolher um
equipamento Windows Mobile”, http://www.microsoft.com/portugal/
windowsmobile/artigos/artwm.mspx.
Trois, J. (2003) Palmtops para iniciantes e experts, Visual Books, São Paulo.
Unito Sistemas, “Desenvolvimento no molde MVC”, http://www.unito.com.br/6676.
Wazlawick, R. S. (2004) Análise e projeto de sistemas de informação orientados a objetos,
Elsevier, Rio de Janeiro.
ANEXOS
ANEXO A – PLANILHA DE COLETA DE ATIVIDADES................................135
ANEXO B – PLANILHA DE COLETA DE UTILIZAÇÃO DE VEÍCULO......136
ANEXO C – PLANILHA DE COLETA DE ABASTECIMENTO DE
VEÍCULOS................................................................................................................137
ANEXO A – PLANILHA DE COLETA DE ATIVIDADES
ANEXO C – PLANILHA DE COLETA DE ABASTECIMENTO DE VEÍCULOS