Sistema de Gerenciamento Customizável Baseado em PDA`s

1
UnicenP
Curso de Engenharia da Computação
SISTEMA DE GERENCIAMENTO CUSTOMIZÁVEL
BASEADO EM PDA'S
2002
2
UNICENP – CENTRO UNIVERSITÁRIO POSITIVO
NÚCLEO DE CIÊNCIAS EXATAS E DE TECNOLOGIA
CURSO DE ENGENHARIA DA COMPUTAÇÃO
PROJETO FINAL – ESPECIFICAÇÃO E PROEJTO
SISTEMA DE GERENCIAMENTO CUSTOMIZÁVEL
BASEADO EM PDA’S
Autor: Tatiana Alves Lessnau
Prof. Orientador: Emerson Paraiso
CURITIBA
29/11/02
ii
SUMÁRIO
LISTA DE FIGURAS...............................................................................................................................iii
LISTA DE TABELAS.............................................................................................................................. iv
LISTA DE ABREVIATURAS E SIGLAS................................................................................................ v
RESUMO.................................................................................................................................................. vi
ABSTRACT ............................................................................................................................................ vii
1.
INTRODUÇÃO................................................................................................................................ 1
2.
ESPECIFICAÇÃO ........................................................................................................................... 2
2.1. DESCRIÇÃO ................................................................................................................................. 2
2.1.1. DESCRIÇÃO GERAL DO SISTEMA E ASPECTOS FUNCIONAIS ................................. 2
2.1.2. DESCRIÇÃO DOS MÓDULOS COMPONENTES DO SISTEMA..................................... 3
2.1.2.1. Banco de Dados ................................................................................................................... 4
2.1.2.2. Servidor Web ....................................................................................................................... 4
2.1.2.3. Aplicação Local - Cliente .................................................................................................... 4
2.1.2.4. Protocolos de Comunicação................................................................................................. 5
2.2. ESTUDO TEÓRICO...................................................................................................................... 5
2.2.1. ESTUDO TEÓRICO SOBRE O SGBD ................................................................................. 5
2.2.2. ESTUDO TEÓRICO SOBRE O SERVIDOR WEB............................................................... 8
2.2.3. ESTUDO TEÓRICO SOBRE A APLICAÇÃO LOCAL - CLIENTE................................... 9
2.2.4. ESTUDO TEÓRICO SOBRE A COMUNICAÇÃO............................................................ 10
2.3. ESPECIFICAÇÕES DE HARDWARE....................................................................................... 11
2.3.1. DIAGRAMA EM BLOCOS................................................................................................. 11
2.3.2. FUNÇÕES DO SISTEMA ................................................................................................... 11
2.3.3. REQUISITOS DE HARDWARE......................................................................................... 12
2.3.4.AMBIENTE DE DESENVOLVIMENTO ............................................................................ 12
2.4. ESPECIFICAÇÃO DO SOFTWARE.......................................................................................... 12
2.4.1. AMBIENTE DE DESENVOLVIMENTO ........................................................................... 13
2.4.2. LINGUAGENS E FERRAMENTAS DE SOFTWARE ...................................................... 13
2.4.3. INTERFACE COM O USUÁRIO........................................................................................ 14
2.4.4. DIAGRAMA EM BLOCOS................................................................................................. 14
2.4.5. FUNÇÕES A SEREM PROVIDAS ..................................................................................... 15
2.4.5.1. Aplicação Local - Cliente .................................................................................................. 15
2.4.5.2. Módulo Web - Servidor...................................................................................................... 15
2.5. EXEMPLO DE APLICAÇÃO..................................................................................................... 17
2.6. ESPECIFICAÇÃO DA VALIDAÇÃO DO PROJETO............................................................... 18
3.
PROJETO ....................................................................................................................................... 19
3.1. DIAGRAMA DE FLUXOS DE DADOS .................................................................................... 19
3.2. DIAGRAMA DE ENTIDADES E RELACIONAMENTOS ...................................................... 28
3.2.1. ESPECIFICAÇÃO DAS TABELAS.................................................................................... 30
3.3. DIAGRAMA DE CLASSES ....................................................................................................... 34
3.4 PROJETO DE INTERFACES ...................................................................................................... 36
3.5. CONSIDERAÇÕES SOBRE O PROJETO ................................................................................. 42
3.5.1. BANCO DE DADOS ........................................................................................................... 42
3.5.2. CLIENTE.............................................................................................................................. 42
3.5.3. SERVIDOR .......................................................................................................................... 43
3.6. FERRAMENTAS UTILIZADAS................................................................................................ 44
5.
ANEXO A – ANÁLISE DE CONCORRÊNCIA........................................................................... 48
6.
ANEXO B – ANÁLISE DE PDA’S............................................................................................... 48
7.
ANEXO C - CRONOGRAMA ...................................................................................................... 50
8.
ANEXO D – ESTIMATIVA DE CUSTOS ................................................................................... 51
9.
ANEXO E – SCRIPT DO BANCO DE DADOS........................................................................... 52
10.
REFERÊNCIAS BIBLIOGRÁFICAS....................................................................................... 55
iii
LISTA DE FIGURAS
Figura 01 - Diagrama Lógico do Sistema
03
Figura 02 - Diagrama com Módulos de Hardware Principais
11
Figura 03 - Módulos da Plataforma Java 2
13
Figura 04 - Diagrama com Módulos de Software Principais
14
Figura 05 - DFD-0, Diagrama de Contexto
20
Figura 06 - DFD-1
21
Figura 07 - DFD-2, Processo 1
22
Figura 08 - DFD-3, Processo 1.2
23
Figura 09 - DFD-2, Processo 2
24
Figura 10 - DFD-2, Processo 3
25
Figura 11 - DFD-2, Processo 4
26
Figura 12 - DFD-2, Processo 5
27
Figura 13 - Diagrama de Entidades e Relacionamentos
29
Figura 14 - Representação Física das Tabelas – Ger. de Sistemas e Usuários
30
Figura 15 - Representação Física das Tabelas - Gerenciamento de Entidades
32
Figura 16 - Diagrama de Classes
35
Figura 17 - Cadastro de Sistemas
36
Figura 18 - Cadastro de Entidades
37
Figura 19 - Cadastro de Usuários
38
Figura 20 - Acesso de Usuário com Perfil PDA
39
Figura 21 - Interface do Sistema do PDA
40
Figura 22 - Emissão de Relatórios
41
Figura 23 - Distribuição das Atividades no Tempo
50
Figura 24 - Distribuição de Custos
51
iv
LISTA DE TABELAS
Tabela I – Comparação de PDA’s
48
Tabela II – Cronograma
50
Tabela III – Estimativa de Custos
51
v
LISTA DE ABREVIATURAS E SIGLAS
PDA – Personal Digital Assistant (Assistente Digital Pessoal)
PC – Personal Computer (Computador Pessoal)
SGBD – Sistema de Gerenciamento de Banco de Dados
IIS – Internet Information Server
PWS – Personal Web Server
RMI – Remote Method Invocation (Invocação Remota de Métodos)
ASP – Active Server Pages (Páginas com Servidor Ativo)
FTP – File Transfer Protocol (Protocolo de Transmissão de Arquivos)
XML – Extensible Markup Language
RAM – Random Access Memory (Memória de Acesso Randômico)
ROM – Read Only Memory (Memória de Somente Leitura)
J2EE – Java 2 Enterprise Edition
J2SE – Java 2 Standard Edition
J2ME – Java 2 Micro Edition
vi
RESUMO
O objetivo deste projeto é o desenvolvimento de um sistema de gerenciamento
baseado em PDA's com a característica da customização. Este sistema, com base na
arquitetura cliente-servidor utilizará como clientes PDA's que possuam suporte a
aplicações Java, independentemente do hardware ou do sistema operacional. O módulo
servidor é totalmente implementado em um servidor web, em conjunto com um sistema de
gerenciamento de banco de dados. As aplicações atendidas são sistemas que necessitem de
coleta móvel de dados, como controles de venda, sistemas de pesquisa de opinião, sistemas
de requisição de produtos, entre outros. A característica marcante deste projeto em relação
às demais soluções disponíveis no mercado é justamente a customização, o que permite
que uma maior fatia do mercado de software para aplicações móveis seja atendida. Para a
implementação foi utilizada tecnologia ASP no servidor, com gerenciamento de dados no
MSDE. A opção do desenvolvimento da aplicação cliente e do módulo de comunicação em
linguagem Java foi feita para tornar o sistema independente da plataforma, gerando uma
maior diversidade de opções de PDA's para a instalação dos clientes móveis, permitindo
inclusive que, no futuro, o sistema seja executado também em telefones móveis com
suporte a Java.
vii
ABSTRACT
The objective of this project is the development of a management system based on
PDA's with the characteristic of the customization. This system, based in client-server
architecture will use as customers PDA's that support Java applications, independently of
the hardware or the operational system of the PDA. The server module is tottaly
implemented in a web server, using a data base management system. The applications this
system can handle are systems that need mobile collection of data, as selling controls,
systems of opinion research, systems of products solicitation, among others. The main
characteristic of this project in relation to another solutions available in market is exactly
the customization, wich allows that a bigger slice of the market of software for mobile
applications is attended. For the implementation, technology ASP in the server was used,
with management of data in MSDE database system. The option of the development of the
customer application and the module of communication in Java language was made to
become the system independent of the platform, being able a bigger diversity of options of
PDA's for the installation of the mobile customers, also allowing that, in the future, the
system may be also executed in mobile telephones wich support Java.
1
1. INTRODUÇÃO
Os PDA’s (Personal Digital Assistants) tornaram-se populares a partir dos anos 90,
inicialmente vistos como aparelhos capazes de controlar informações pessoais, como
tarefas, compromissos e contatos mais eficientemente que uma agenda eletrônica.
Gradativamente, estes aparelhos começam a fazer parte do mercado corporativo, sendo
esta uma área em constante expansão: a computação móvel. Diversas soluções usam o
potencial dos handhelds como ferramenta indispensável ao trabalho do dia-a-dia,
principalmente pela praticidade e mobilidade que estes aparelhos oferecem. A aplicação
destes dispositivos móveis vai desde a automação de forças de vendas até o monitoramento
de pacientes em hospitais.
A proposta do desenvolvimento deste projeto é aliar a flexibilidade e o dinamismo
oferecido pela computação móvel dos PDA’s e a confiabilidade de uma base de
gerenciamento de dados centralizada, fazendo esta integração por meio de comunicação
remota (utilizando Internet ou uma Intranet) e disponibilizando informações colhidas em
uma interface web, acessível de qualquer computador equipado com um browser.
Atualmente estão disponíveis no mercado diversos sistemas que utilizam PDA’s.
São aplicações providas por empresas especializadas (software houses) e que são, em sua
grande maioria, específicos para uma determinada aplicação. O sistema que é objeto deste
projeto final tem por meta ser customizável (não em sua totalidade, mas em alguns
aspectos, como tipo de informações que será gerenciada e formas de comunicação),
permitindo que, para determinadas aplicações sejam feitas configurações e customizações
ao sistema, atingindo assim uma fatia maior do mercado. Essa característica é também um
diferencial deste sistema em relação aos sistemas disponíveis no mercado. Isso porque, por
estar sendo utilizado um sistema básico comum e configurável, a possibilidade de atender
demandas em diferentes áreas com o mesmo sistema é sensivelmente maior, ainda que seja
necessário a implementação de pequenas alterações posteriores (específicas).
Neste documento, que corresponde à primeira fase do desenvolvimento do projeto
final, será apresentada a especificação do sistema. O objetivo é de apresentar um estudo
preliminar sobre a literatura existente, além de informações e subsídios que serão
necessários nas próximas fases do desenvolvimento do projeto.
2
2. ESPECIFICAÇÃO
Na especificação do projeto é apresentado um estudo inicial do contexto onde está
inserido este projeto, bem como a descrição das funcionalidades a serem desenvolvidas no
Sistema de Gerenciamento Customizável Baseado em PDA’s
2.1. DESCRIÇÃO
Serão apresentados nesta descrição as características gerais e os módulos do
Sistema de Gerenciamento Customizável Baseado em PDA’s, assim como uma breve
descrição de cada um destes componentes.
2.1.1. DESCRIÇÃO GERAL DO SISTEMA E ASPECTOS
FUNCIONAIS
O sistema especificado neste documento pode ser entendido como um sistema
móvel de aquisição de dados, com processamento local e armazenamento central, e que
permite a distribuição dos dados armazenados através da web.
Existirá uma interface de customização e set up que será responsável pela definição
dos aspectos configuráveis do sistema. Esse módulo será utilizado somente uma vez,
quando da instalação e customização (set up) inicial do sistema. Definidos estes requisitos,
o software de gerenciamento local poderá ser instalado no PDA, que será o responsável
pela aquisição dos dados.
No PDA, através da interface do software local, será feita a entrada de dados. Esta
informação deverá ser transmitida para o servidor, que possui a base de dados central, por
meio de uma Intranet ou da Internet, podendo ser utilizada para isso uma conexão física
com um PC (conectado à Internet ou Intranet Corporativa) ou comunicação diretamente do
dispositivo (PDA) que, neste caso, deve possuir periféricos ou módulos embutidos que
permitam essa comunicação.
3
A partir do momento que a informação está armazenada em uma base de dados
central é possível disponibilizá-la através da web. Para isso, será utilizado um servidor
web, acessando estes dados diretamente da base de dados. A interface de disponibilizarão
de dados é um tanto quanto genérica, pois atende a mais de uma aplicação (conforme a
configuração no set up do sistema). Isso não impede que sejam desenvolvidas,
posteriormente interfaces de visualização mais elaboradas, com o foco na aplicação
atendida e utilizando a mesma base de dados já disponível.
2.1.2. DESCRIÇÃO DOS MÓDULOS COMPONENTES DO SISTEMA
Um sistema é composto de diversos módulos que se inter-relacionam. A seguir
serão apresentados e descritos brevemente cada um dos módulos componentes do Sistema
de Gerenciamento Customizável Baseado em PDA’s.
Na figura 01 é apresentado o diagrama lógico do sistema, com a identificação dos
módulos básicos em que o sistema é dividido, destacando-se: banco de dados, servidor
web, aplicação cliente (interface para o PDA) e protocolos de comunicação. No diagrama,
são representadas as duas possibilidades de comunicação entre os módulos do sistema
(PDA – Servidor e PDA – PC – Servidor), além da distribuição dos dados armazenados
através da web.
Figura 01 – Diagrama Lógico do Sistema
4
2.1.2.1. Banco de Dados
No banco de dados serão armazenadas de forma centralizada todas as informações
sobre a configuração dos sistemas (customização) e os dados colhidos pela aplicação.
Será utilizado um SGBD (Sistema de Gerenciamento de Banco de Dados),
conforme será apresentado no estudo teórico. As informações armazenadas no banco de
dados serão atualizadas constantemente com os dados colhidos pelos dispositivos móveis
(PDA’s) e estarão disponíveis através do servidor web.
2.1.2.2. Servidor Web
O servidor web permite que informações sobre o sistema sejam consultadas através
de uma Intranet ou da Internet. Serão construídas páginas dinâmicas, que mesclam códigos
HTML e codificação de script para consultas no banco de dados e validações de
informações. Além disso, neste mesmo servidor será implementada a interface de recepção
dos dados colhidos pelos PDA’s. Mais informações sobre o servidor web serão
apresentadas no estudo teórico.
2.1.2.3. Aplicação Local - Cliente
A aplicação local consiste em um sistema que será instalado no PDA e permitirá
tanto a entrada de informações e armazenamento local, quanto a sincronização com a base
de dados central. Esse módulo será programado em linguagem específica para dispositivos
de processamento limitado.
5
2.1.2.4. Protocolos de Comunicação
Os protocolos de comunicação são a forma através da qual as informações são
enviadas e recebidas pelos módulos do sistema (clientes, servidor, gerenciador de banco de
dados). É necessário definir o formato de troca de informações e o meio em que estarão
trafegando. No estudo teórico, são apresentadas mais informações sobre os protocolos de
comunicação, bem como sobre a forma de interligação entre os módulos do sistema.
2.2. ESTUDO TEÓRICO
A seguir serão apresentadas informações sobre técnicas e aspectos teóricos
associados aos módulos do Sistema de Gerenciamento Customizável Baseado em PDA’s.
2.2.1. ESTUDO TEÓRICO SOBRE O SGBD
O projeto final a ser desenvolvido utiliza uma base de dados, onde são armazenadas
as informações colhidas através dos PDA's para serem distribuídas posteriormente através
de uma interface na web, além das informações sobre a customização do sistema. Para
isso, será necessária a utilização de um SGBD.
Um SGBD é um conjunto de aplicações desenvolvidas especialmente para o
tratamento de um banco de dados, fornecendo ao usuário (desenvolvedor) uma
representação conceitual dos dados, sem fornecer muitos detalhes sobre como as
informações são armazenadas. As vantagens da utilização de um SGBD incluem: controle
de redundância, compartilhamento de dados, restrições de acesso, representação de
relacionamentos complexos de dados, e tolerância a falhas.
Existem diversos SGBD's disponíveis no mercado, entre os quais pode-se destacar
os sistemas: Oracle, MySQL e SQL Server e também alguns sistemas específicos para
PDA’s, como o Oracle Lite, ThinkDB e DB2 Everyplace.
6
Líder de mercado, o sistema de gerenciamento de banco de dados Oracle é uma
excelente opção para projetos grandes e também onde exista disponibilidade de recursos
para investimento. A desvantagem deste sistema é o alto custo, e também a necessidade de
utilização de uma boa máquina para a sua execução, pois o sistema exige bastante do
hardware.
Por outro lado, o MySQL é um sistema de gerenciamento de banco de dados
gratuito, bastante difundido entre os desenvolvedores de software. Existe bastante
documentação disponível na Internet e novas versões do sistema estão sendo lançadas.
Atualmente, a última versão estável do sistema é a 3.23. Está em desenvolvimento a
versão 4.0 Alfa. Foram realizados alguns testes com o sistema, para verificação das
possibilidades oferecidas pelo sistema. O gerenciamento de tabelas e relacionamentos
funciona bem, assim como funções básicas (INSERT, UPDATE, DELETE, SELECT). O
grande problema na utilização deste banco de dados é o fato de ele ainda não gerenciar
stored procedures, que são scripts armazenados no próprio SGBD que podem ser
chamados diretamente da aplicação, tornando a aplicação mais modular, pois a lógica de
acesso ao banco de dados passa a ser armazenada do banco de dados, e não na aplicação.
Essa funcionalidade está prevista para ser implementada na versão 4.1 (ainda não
disponível).
O SQL Server é uma opção mais barata que o Oracle, mas ainda com custos
relativamente altos. O sistema é bastante eficiente, tem suporte a stored procedures,
triggers, replicação. A documentação é farta e o sistema é bastante utilizado em diversas
corporações (assim como o Oracle). Outra característica muito interessante do SQL Server
é a disponibilidade do MSDE (Microsoft Data Engine), que é um sistema gerenciador de
banco de dados compatível com o SQL Server, e que pode ser distribuído gratuitamente
com as aplicações para ele desenvolvidas. Para utilizar e distribuir o sistema é necessário
possuir uma licença de um dos softwares do pacote Microsoft Visual Studio 6.0. O sistema
MSDE torna-se portável, pois utiliza a mesma base do SQL Server. Outra vantagem é por
o sistema ser pequeno e não exigir muitos recursos de hardware (em comparação com os
sistemas maiores) e pode ser baixado na própria Internet.
Existem também SGBD’s específicos para PDA’s, como o Oracle Lite, o ThinkDB
e o DB2 Everyplace. O Oracle Lite (versão 9i) é a principal plataforma de
desenvolvimento e controle de aplicações de negócio em dispositivos móveis, com suporte
a Java em diversas plataformas e diversos dispositivos como telefones celulares, PDA’s e
laptops.
7
Já o ThinkDB é uma versão do software da Thinkingbytes para Palm OS. Algumas
características interessantes são o suporte a arquivos .MDB (do Access) e a possibilidade
de importação de arquivos do Access e do Excel, software de gerenciamento de dados e
planilha de cálculos da Microsoft, respectivamente. Esse sistema permite a sincronização
entre uma base no PC e o PDA (no caso, o Palm).
O DB2 Everyplace é um software da IBM projetado especificamente para PDA’s.
A solução consiste em um sistema relacional de banco de dados para o PDA, um servidor
bidirecional para sincronização da base no PDA com outro banco de dados externo e uma
ferramenta para o desenvolvimento de aplicações para PDA utilizando o DB2 Everyplace.
É um sistema bastante interessante em se tratando de armazenamento de dados no PDA
com sincronização externa. A desvantagem é o fato de o sistema ser pago, o que encarece
os custos do projeto.
Para o desenvolvimento deste projeto, as melhores opções são o MySQL e o
MSDE. O MySQL tem a vantagem de ser totalmente gratuito e rodar em diversas
plataformas. O MSDE tem a vantagem da portabilidade e facilidade de migração para uma
base de dados mais completa (SQL Server) e alguns recursos adicionais que não estão
presentes no MySQL. Para o PDA, o DB2 Everyplace seria uma solução bastante
interessante mas, por acarretar aumento de custos, a opção mais atrativa consiste em
gerenciar os dados no PDA como arquivos textos, produzidos com um comando
“serialize”, que transforma objetos na memória em arquivos texto, como será comentado
no tópico do estudo teórico da aplicação local. Isso é possível por estar-se utilizando uma
linguagem de programação para o cliente que permite este tipo de abordagem, por ser
orientada a objetos e dispor destes recursos, a linguagem Java. A escolha desta forma de
armazenamento no PDA não torna o sistema menos interessante do ponto de vista do
gerenciamento de dados porque o armazenamento no PDA é temporário, enquanto que na
base central, onde ficam os dados permanentes, será utilizado um sistema específico para o
gerenciamento da base de dados.
8
2.2.2. ESTUDO TEÓRICO SOBRE O SERVIDOR WEB
A proposta de implementar um sistema baseado em web segue a tendência atual, na
qual muitos sistemas antes rodando em aplicações convencionais passam a funcionar
através de uma Intranet e/ou da Internet. As vantagens de um sistema deste tipo são
diversas, indo desde a facilidade de manutenção à possibilidade de utilização de uma rede
de computadores mais heterogênea, sendo necessário apenas um browser para acessar o
sistema de controle da empresa. Com isso, todo o processamento pesado passa a ser feito
no servidor e não nos clientes.
Um sistema baseado em web necessita de um servidor capaz de disponibilizar as
informações que são acessadas pelos clientes, que estarão utilizando um browser para
visualizar dados transmitidos em hipertexto (forma como as informações transitam na web
para serem apresentadas nos browsers). Existem diversos servidores web disponíveis no
mercado, destacando-se o Apache - para Unix e Windows - e o IIS (Internet Information
Server) - para Windows.
Para este projeto, escolheu-se trabalhar com o IIS, que é compatível com a
tecnologia que será utilizada para a construção das páginas dinâmicas. Este software é
distribuído juntamente com o sistema operacional Microsoft Windows, com algumas
variações de acordo com a versão do sistema. Por exemplo, o Microsoft Windows 98 traz o
PWS (Personal Web Server), que é uma versão mais limitada do IIS. A versão NT 4.0 traz
o IIS 4.0, e as versões 2000 e Xp trazem as versões 5.0 e 5.1 do IIS, respectivamente.
As páginas armazenadas no servidor web deverão ser dinâmicas. Isso significa que
serão páginas com scrips de acesso a banco de dados, validação de informações, entre
outros. Páginas estáticas são escritas em código HTML simples. Diferentemente, as
páginas dinâmicas mesclam HTML e scrips. Estes scrips podem ser em ASP (Active
Server Pages), em PHP, ou em outra linguagem de scripts para web.
Para este sistema, a opção escolhida foi a utilização de páginas ASP, que podem ser
programadas em Visual Basic Script em conjunto com códigos Java Script e HTML. Estas
páginas têm os seus scripts executados no servidor, sendo enviado ao browser somente o
resultado da operação realizada. Podem também existir códigos executados no cliente,
como em validações. Para a disponibilização destas páginas (Active Server Pages) será
necessário utilização do IIS. Essa escolha se deu pela grande utilização desta tecnologia no
mercado corporativo e também por afinidade pessoal com a tecnologia.
9
Neste servidor será implementada, além da interface de disponibilização dos dados
e customização inicial do sistema, a interface de recebimento dos dados enviados pelo
cliente, que será comentado no estudo teórico sobre os protocolos de comunicação.
2.2.3. ESTUDO TEÓRICO SOBRE A APLICAÇÃO LOCAL - CLIENTE
Os PDA’s são dispositivos de processamento limitado que podem rodar aplicações
escritas especificamente para esse tipo de equipamento. Foram pesquisadas linguagens de
programação e ferramentas de desenvolvimento.
As principais linguagens para programação de aplicativos para PDA são C++ e
Java. Ambas as linguagens trabalham com orientação a objetos e possuem possibilidades
de implementação semelhantes.
No caso do sistema objeto deste trabalho, a utilização da linguagem Java é
extremamente interessante, pois torna a aplicação independente da plataforma do PDA.
Com isso, a variedade de PDA’s que podem utilizar o sistema é aumentada
significativamente, pois basta possuir suporte a Java (implementação de uma virtual
machine, ou “máquina virtual”) para que o PDA possa ser utilizador da aplicação local
deste sistema de gerenciamento. Além disso, existe uma grande tendência de os aparelhos
de telefonia celular incorporarem funções dos PDA’s, fazendo a fusão das duas
tecnologias. Por ser escrito em uma linguagem independente de plataforma, o sistema já
estará parcialmente preparado para funcionar nestes dispositivos.
Outra característica interessante da linguagem Java é a orientação a objetos e
comandos como o serialize, que permitem armazenar objetos em arquivos texto. Estes
arquivos, por sua vez, podem ser transmitidos para o servidor e armazenados (no formato
conveniente) em um banco de dados. É interessante notar que a linguagem Java é utilizada
em PC’s, PDA’s e diversos dispositivos, o que a torna bastante atrativa para este projeto.
A aplicação local, com base em uma configuração definida no set up do sistema
terá alguns de seus parâmetros modificados, para permitir a entrada das informações que
correspondem ao objetivo do controle do sistema.
10
2.2.4. ESTUDO TEÓRICO SOBRE A COMUNICAÇÃO
Para a comunicação entre o PDA e a base central, permitindo o intercâmbio de
informações entre os módulos será necessária a utilização de um protocolo de
comunicação. Este módulo inclui a forma como o PDA enviará os dados para a rede,
através de um microcomputador ou diretamente. Também inclui a forma como o servidor
recebe essa informação.
Está sendo estudada a possibilidade da implementação de um objeto DCOM no
servidor web, para a recepção dos dados enviados pela rede. Estes objetos são projetados
para sistemas distribuídos, com implementações de segurança, multithreading, etc.
Neste módulo também deve-se verificar a utilização de XML para torca de dados
entre o cliente, o servidor e o banco de dados. Esta tecnologia tem se desenvolvido muito
por ser simples e permitir o envio de dados pela web em formato texto.
Outra possibilidade é o desenvolvimento da recepção dos dados em Java, já que o
cliente (PDA) estará enviando um objeto Java para o servidor. A linguagem oferece
diversas possibilidades como a construção de uma aplicação, de um applet (para rodar em
um browser) ou mesmo dos objetos distribuídos Enterprise Java Beans.
A linguagem Java oferece um recurso bastante atrativo, que é a utilização de RMI
(Remote Method Invocation), que permite que a comunicação entre dispositivos seja feita
em um nível mais alto que o TCP-IP propriamente dito, e é uma tendência que está sendo
seguida pelo mercado. Neste caso, métodos podem ser invocados remotamente, e obejetos
serializáveis podem ser enviados como parâmetos.
Existem diversos outros modelos que podem ser utilizados nessa comunicação,
como a implementação de um Web Service, que é um conceito relativamente novo, que
começou a ser difundido após o lançamento do Microsoft Visual Studio .Net, uma
ferramenta de desenvolvimento. Esta ferramenta é bastante recente no mercado e
promoveu muitas modificações na forma como são desenvolvidas as aplicações web,
inclusive com a tecnologia ASP, que será utilizada neste projeto.
A transmissão dos dados do PDA para o servidor passando pelo PC, a princípio,
poderá ser feita por FTP ou através da utilização de um applet Java. Será estudada a opção
mais interessante.
11
2.3. ESPECIFICAÇÕES DE HARDWARE
Este projeto está focado no desenvolvimento de software, o que não implica que
não serão necessários conhecimentos sobre o hardware que está sendo utilizado. A seguir
serão apresentadas informações sobre o tipo de hardware que será utilizado para o
desenvolvimento e implementação do projeto.
2.3.1. DIAGRAMA EM BLOCOS
Na figura 02 são apresentados os principais módulos de hardware do sistema.
Podem ser acrescentados mais módulos, como modems ou interfaces de comunicação ao
esquema básico, conforme a necessidade.
Figura 02 – Diagrama com Módulos de Hardware Principais
2.3.2. FUNÇÕES DO SISTEMA
As funções de hardware neste projeto consistem em dar suporte às soluções de
software desenvolvidas. Como já foi mencionado, não serão desenvolvidos dispositivos de
hardware adicionais, mas aplicações em software que acessam funções do hardware
disponível (PDA’s e PC’s). No caso do PDA, a função é de recepção e armazenamento
12
temporário de dados, bem como a sua transmissão posterior. No caso do servidor a função
é de recepção, armazenamento e disponibilização de informações.
2.3.3. REQUISITOS DE HARDWARE
Para o PDA, os requisitos de hardware são bastante flexíveis, sendo necessário
somente que o dispositivo seja projetado para rodar uma aplicação Java e que exista
alguma forma de comunicação com o meio externo (porta serial, infravermelho, USB
(Universal Serial Bus), modem ou comunicação wireless). Ainda assim, na fase de projeto
serão definidos alguns requisitos mínimos para o PDA, o que garantirá o melhor
funcionamento do sistema.
Para o servidor será necessário que suporte a instalação de um servidor web e um
SGBD, bem como a conexão e acesso aos recursos através de uma rede (uma Intranet ou a
Internet).
2.3.4.AMBIENTE DE DESENVOLVIMENTO
A escolha do PDA está sendo estudada, com base nas informações apresentadas no
Anexo B – Análise de PDA’s. Para o desenvolvimento do sistema (software do servidor e
do PDA) será utilizado um microcomputador Pentium com 266 MHz, 64 Mbytes de
memória RAM, e disco rígido de 04 Gbytes, equipado com modem em cartão de acesso a
rede (PCM-CIA).
2.4. ESPECIFICAÇÃO DO SOFTWARE
Para o desenvolvimento do Sistema de Gerenciamento Customizável Baseado em
PDA’s será necessário utilizar algumas ferramentas conforme será descrito a seguir. Serão
apresentados também alguns pré-requisitos para o software que será desenvolvido.
13
2.4.1. AMBIENTE DE DESENVOLVIMENTO
O ambiente de desenvolvimento será Microsoft Windows 98, com o servidor web
PWS (Personal Web Server).
Para o desenvolvimento das aplicações Java será utilizado o J2ME. O J2ME é uma
nova versão da plataforma de desenvolvimento Java 2 destinada a dispositivos de
processamento limitado, como os PDA’s, consistindo de uma máquina virtual (virtual
machine) e alguns API’s para oferecer funcionalidades e segurança para instalar e rodar as
classes Java no dispositivo. Caso escolhida a opção do desenvolvimento dos demais
módulos (como comunicação) utilizando Java nos PC’s, poderá ser utilizado o ambiente
J2EE ou J2SE. Estes ambientes (Java 2 Enterprise Edition e Java 2 Standard Edition)
também são parte da plataforma Java 2, como é mostrado na figura 03.
Figura 03 – Módulos da Plataforma Java 2
2.4.2. LINGUAGENS E FERRAMENTAS DE SOFTWARE
Para o desenvolvimento do banco de dados será utilizado um analisador de queries
(ambiente de desenvolvimento), compatível com o SGBD escolhido e a ferramenta
Microsoft Visual Interdev, que também dá suporte ao desenvolvimento de páginas web.
No desenvolvimento do módulo web será utilizado o Microsoft Visual Interdev do
pacote Microsoft Visual Studio 6.0 e possivelmente a ferramenta J2SE ou J2EE para
desenvolvimento de applets e aplicações Java.
14
O módulo de aplicação local será desenvolvido utilizado o J2ME (Java 2
Plataform, Micro Edition) e possivelmente o Code Warrior ou Forte para Java. Uma opção
é utilizar o Palm OS Emulator para testar a aplicação no próprio PC de desenvolvimento.
Para isso será necessário obter uma ROM de Palm e instalá-la juntamente com o emulador.
Além disso, a implementação do módulo de protocolo de comunicação exigirá a
utilização de um software compatível com a solução escolhida, como um ambiente Java ou
ainda o Microsoft Visual C++ ou Microsoft Visual Basic no caso de um componente
DCOM.
2.4.3. INTERFACE COM O USUÁRIO
Pretende-se disponibilizar uma interface amigável com o sistema em todos os
módulos do sistema (tanto no PDA quanto no acesso via web). Para isso será necessário
definir uma interface que permita que as customizações sejam utilizadas para a definição
de como algumas informações serão mostradas nesta interface.
Em princípio, toda a parte do sistema que não for acessada através do PDA será
baseada em web, ou seja, acessada através de um browser.
2.4.4. DIAGRAMA EM BLOCOS
Na figura 04 é a apresentado um diagrama em blocos do software que será
desenvolvido, apresentando como as partes interagem entre si.
Figura 04 – Diagrama com Módulos de Software Principais
15
2.4.5. FUNÇÕES A SEREM PROVIDAS
Nesta etapa do projeto não são definidas em detalhes todas as funções que o sistema
desenvolvido deve possuir. Entretanto, é possível fazer uma análise macro do que deve ser
oferecido por cada um dos módulos de software utilizados pelo usuário.
2.4.5.1. Aplicação Local - Cliente
A aplicação local, que será rodada no PDA deve oferecer as seguintes
funcionalidades:
-
Interface de entrada de dados com gravação dos dados;
-
Opção de comunicação com a base central. Em princípio a comunicação será
feita em blocos (comunicação batch). Como uma melhoria ao projeto, poderá
ser implementada, caso existam recursos de tempo disponíveis, comunicação on
line com o servidor central.
2.4.5.2. Módulo Web - Servidor
O módulo web compreende a customização inicial do sistema, a comunicação entre
PDA e servidor por meio da Web (utilizando um PC) e a consulta aos dados recebidos
pela comunicação com os PDA’s.
Para a customização, pretende-se oferecer as funcionalidades:
-
Criação de um novo sistema, ou seja, o primeiro passo para a sua instalação;
-
Definição de configurações e customizações em alguns parâmetros, as serem
definidos na etapa de projeto deste sistema;
-
Disponibilização do software que será instalado no PDA.
16
Para a comunicação entre PDA, PC e Web serão oferecidas as funcionalidades:
-
Diponibilização do sistema base em Java e template gerado através da
customização para instalação no PDA;
-
Controle de PDA’s utilizados por usuário;
-
Envio de dados ao servidor e sincronização da base local do PDA.
Para a consulta, é objetivo oferecer as funcionalidades:
-
Identificação do sistema utilizado;
-
Exibição da informação coletada com a utilização de filtos de dados;
-
Caso existam recursos de tempo disponíveis, uma melhoria a ser implementada
ao projeto é a possibilidade de alteração dos dados disponíveis na web através
da própria web, ou seja, a complementação das informações já armazenadas.
17
2.5. EXEMPLO DE APLICAÇÃO
O sistema objeto deste trabalho será capaz de gerenciar diversos tipos de
aplicações, das quais será comentada, a título de exemplo, um controle de frigobar
(minibar) hoteleiro.
Esta aplicação será inicialmente cadastrada no sistema de gerenciamento através de
uma interface web. Nesta interface de customização serão definidos:
-
Nome da Aplicação;
-
Responsável pela Aplicação;
-
Usuários da Aplicação;
-
Tabelas de Armazenamento de Dados;
-
Forma de Entrada dos Dados no Cliente (PDA).
Em seguida deverá ser gerada a configuração da aplicação cliente que será instalada
no PDA com a aplicação local. Assim que a aplicação estiver instalada poderá ser feita
uma sincronização inicial com a base central (para alimentação dos dados locais – por
exemplo uma tabela de produtos disponíveis). Feita esta sincronização o sistema estará
apto para a coleta de dados.
Feita a coleta de dados, poderá ser feita a transmissão desta informação para o
servidor. Neste caso, o PDA deverá estar conectado a rede diretamente ou a um PC
(conectado a rede) e os dados serão enviados ao servidor.
O servidor fará a recepção dos dados e o seu armazenamento em banco de dados.
Todas as informações cadastradas no banco de dados estão, a partir deste momento,
disponíveis para consulta por um dos usuários da aplicação (cadastrados na customização
do sistema).
18
2.6. ESPECIFICAÇÃO DA VALIDAÇÃO DO PROJETO
Uma das etapas bastante importantes do desenvolvimento de um projeto consiste na
sua validação. Para isso devem ser feitos testes e simulações.
Para o Sistema de Gerenciamento Customizável Baseado em PDA’s serão feitos
testes para a validação da comunicação entre os módulos componentes. Também serão
feitos testes no software da aplicação local e no módulo web.
Para finalizar a validação do projeto, será feita uma simulação de uma situação real,
com a criação e customização de um sistema e a realização de todas as operações providas
pelo sistema, para que seja, desta forma, validado o seu funcionamento.
19
3. PROJETO
A seguir serão apresentadas as informações referentes à segunda etapa do
desenvolvimento deste sistema, o projeto do sistema. Este estudo tem por objetivo mostrar
como serão implementados os módulos componentes do sistema e como será o
relacionamento entre eles.
3.1. DIAGRAMA DE FLUXO DE DADOS
O diagrama de fluxo de dados de um sistema permite observar quais os módulos
do sistema e as ações que poderão ser geradas por cada usuário através destes módulos. É
através deste mapeamento inicial que é desenvolvido o diagrama de entidades e
relacionamentos (banco de dados). Estes diagramas são formas de análise estruturada de
projetos, e foram empregados principalmente na parte web do projeto do Sistema de
Gerenciamento Customizável Baseado em PDA’s.
Na figura 05, a seguir, é apresentado o DFD de nível zero, ou “diagrama de
contexto”, que mostra todo o sistema como uma única “bolha”, ou processo, que recebe e
gera diversas ações (todas as ações que o sistema gerencia).
Com a explosão do DFD-0, que é apresentada na figura 06, obtém-se o DFD de
nível um, que neste caso é bastante interessante por mostrar de forma bem clara a divisão
do sistema nos seguintes módulos:
-
Instanciação e customização de sistemas;
-
Gerenciamento de Usuários;
-
Gerenciamento de Relatórios;
-
Comunicação Cliente-Servidor;
-
Armazenamento de Dados no PDA.
As figuras 07, 08, 09, 10, 11 e 12 representam explosões destes módulos, a fim de
permitir uma visualização do sistema de forma abrangente, o que permite, com base nestes
diagramas gerados, o projeto do diagrama de entidades e relacionamentos.
20
Figura 05 – DFD-0, Diagrama de Contexto
21
Figura 06 – DFD-1
22
Figura 07 – DFD-2, Processo 1
23
Figura 08 – DFD-3, Processo 1.2
24
Figura 09 – DFD-2, Processo 2
25
Figura 10 – DFD-2, Processo 3
26
Figura 11 – DFD-2, Processo 4
27
Figura 12 – DFD-2, Processo 5
28
3.2. DIAGRAMA DE ENTIDADES E RELACIONAMENTOS
Com base nos diagramas de fluxo de dados e na especificação do Projeto foi
projetado o diagrama de entidades e relacionamentos, que é apresentado na figura 13 já no
nível de normalização que será utilizado na implementação.
Foram projetadas vinte tabelas, que representam a estrutura geral do sistema, que
fazem a administração e gerenciamento dos sistemas que são instanciados em tempo de
execução. As tabelas que serão criadas pelos usuários do sistema não são representadas
neste diagrama por serem dinâmicas, e criadas de acordo com cada sistema que é
instanciado.
Este diagrama representa a estrutura do banco de dados que será implementado. O
diagrama de entidades e relacionamentos tem muita importância dentro deste projeto, pois
uma grande parte deste sistema é baseado em implementações no banco de dados; o
próprio gerenciamento das aplicações customizáveis que são criadas através do sistema é
feito através do SGBD.
29
Figura 13 – Diagrama de Entidades e Relacionamentos
30
3.2.1. ESPECIFICAÇÃO DAS TABELAS
Nas figuras 14 e 15 são apresentadas as tabelas que gerenciam sistemas e usuários e
as tabelas de gerenciamento de entidades, respectivamente. A diferença em relação à figura
13 é que nestas é apresentada uma visão física do banco de dados, com a representação de
cada campo, tipo do campo e relacionamentos (chaves primárias e estrangeiras).
Todas as tabelas ficam armazenadas no servidor, no sistema de gerenciamento de
banco de dados MSDE. A seguir serão descritas cada uma das entidades que compõe o
sistema. Além desta descrição, o script do banco de dados, apresentado no anexo E,
permite uma melhor compreensão da estrutura de banco de dados que será criada.
Figura 14 – Representação Física das Tabelas – Ger. de Sistemas e Usuários
31
1. Entidade: tblgeSystems
Tem o propósito de armazenar os sistemas cadastrados e serve como ligação entre
as tabelas de gerenciamento de usuários e tabelas de gerenciamento de entidades. É
atualizada pelo módulo de customização e instanciação de sistemas.
2. Entidade: tblgeUsers
Armazena os usuários cadastrados no sistema, com informações como login e
senha. É atualizada pelo módulo de customização e instanciação de sistemas e acessada
pelo módulo de gerenciamento de usuários.
3. Entidades: tblgeProfiles e tblgeSystemUserProfiles
Armazenam os perfis disponíveis para os usuários dos sistemas e o relacionamento
de perfis com usuários (perfis que o usuário possui). Um usuário pode possuir vários perfis
distintos e em vários sistemas. São atualizadas pelo módulo de customização e
instanciação de sistemas e acessada pelo módulo de gerenciamento de usuários.
4. Entidades: tblgeStatus e tblgeSystemUserStatus
Armazenam os status de usuários nos sistemas e o relacionamento de usuários com
status. Um usuário pode possuir apenas um status por sistema, por isso existe uma cláusula
unique no script de criação deste tabela (conforme anexo E – Script do Banco de Dados).
São atualizadas pelo módulo de customização e instanciação de sistemas e acessada pelo
módulo de gerenciamento de usuários.
5. Entidades: tblgePDAs e tblgeUserPDAs
Armazenam os PDA’s disponíveis (cadastrados com número serial) e o status de
cada um, relacionando-o com o usuário que utiliza o aparelho. Utilizam a tabela status para
diferenciar registros de empréstimo e devolução e permitem o armazenamento de um
histórico de empréstimos de PDA’s a usuários. São atualizada no módulo de instanciação
de customização de sistemas.
32
Figura 15 – Representação Física das Tabelas - Gerenciamento de Entidades
6. Entidade: tblgeReportQuery
Armazena os scripts para geração de relatórios com as informações cadastradas.
Relaciona-se com sistemas porque os relatórios são partes do sistema, ou seja, devem ser
opções de consulta para os sistemas relacionados. É atualizada no módulo de instanciação
de customização de sistemas e utilizada no módulo de geração de relatórios.
7. Entidades: tblgeTables, tblgeTableTypes e tblgeSystemTables
A tabela tblgeTables armazena um registro para cada nova tabela criada para um
sistema que é instanciado. A tabela tblgeTableTypes armazena os tipos de tabelas,
indicando de tratam-se de depósitos fixos (que devem ser copiados para o PDA), se são
tabelas de armazenamento de coletas (que são alimentadas no PDA), etc. A tabela
tblgeSystemTables relaciona as tabelas com os sistemas. Uma tabela pode relacionar-se
com mais de um sistema. São atualizadas no módulo de instanciação de customização de
sistemas.
33
8. Entidades: tblgeFields e tblgeTableFields
Armazenam os campos criados em cada tabela e o relacionamento destes campos
com as tabelas (quais tabelas possuem quais campos). São atualizadas no módulo de
instanciação de customização de sistemas.
9. Entidades: tblgeFieldTypes e tblgeFieldTypeInterfaces
A tabela tblgeFieldTypes armazena os tipos de campos disponíveis, que podem ser
escolhidos na customização do sistema. A tabela FieldTypeInterfaces é uma tabela de
relacionamento auxiliar que relaciona tipos de campos com interfaces (representadas por
outra entidade), a fim de permitir que exista uma consistência entre os tipos de campos e as
interfaces utilizadas. São atualizadas no módulo de instanciação de customização de
sistemas.
10. Entidade: tblgeTableFieldRelationship
Esta tabela armazena os relacionamentos entre as tabelas, indicando chaves
primárias e estrangeiras. Existe uma clausula unique nesta entidade para que os
relacionamentos sejam armazenados sem redundâncias. É atualizada no módulo de
instanciação de customização de sistemas e utilizada no módulo de geração de relatórios.
11. Entidades: tblgeInterfaces e tblgeSystemFieldInterface
Armazenam respectivamente as interfaces com o usuário para cadastro em campos
disponíveis e o relacionamento dos campos com as interfaces dentro d um sistema. Uma
tabela pode possuir campos com interfaces diferentes em diferentes sistemas, conforme a
necessidade do usuário. São atualizadas no módulo de instanciação de customização de
sistemas e utilizada no módulo de geração de relatórios.
12. Entidade: tblgeFieldInterfaceKey
Esta tabela permite a criação de campos com valores pré-definidos vetoriais, ou
seja, para uma tabela de armazenamento, pode-se definir que um determinado campo tenha
em sua interface um vetor de opções vindos de um cadastro de uma outra tabela. É
atualizada no módulo de instanciação de customização de sistemas e utilizada no módulo
de geração de relatórios.
34
3.3. DIAGRAMA DE CLASSES
O projeto dos módulos cliente e servidor que serão implementados em linguagem
Java utilizam fortemente o conceito de.orientação a objetos. Por isso, apesar da análise de
grande parte do sistema ter sido feita de forma estruturada, para estes módulos foi feita
uma análise orientada a objetos, que permitiu a construção do diagrama de classes
apresentado na figura 16.
Estas classes devem ser utilizadas tanto no cliente (aplicação do PDA), quanto nos
applets de comunicação e na aplicação que roda no servidor, fazendo da comunicação com
os demais módulos do sistema. Esta é inclusive a grande vantagem da programação
orientada a objetos: além de permitir encapsulamento, permitir o reaproveitamento de
código.
35
Figura 16 – Diagrama de Classes
36
3.4 PROJETO DE INTERFACES
Nas figuras a seguir são representadas algumas das interfaces do sistema com o
usuário, em alguns dos módulos que compõe o sistema.
Estas interfaces podem sofrer alterações na etapa de implementação, pois
representam neste momento uma idéia do que será implementado no sistema.
Figura 17 – Cadastro de Sistemas
A figura 17 representa o cadastro de um sistema no Sistema de Gerenciamento
Customizável Basedo em PDA’s. É possível cadastrar entidades, usuários e relatórios.
Apenas o usuário administrador tem acesso ao cadastro de sistemas, entidades, usuários e
relatórios.
37
Figura 18 – Cadastro de Entidades
A figura 18 representa o cadastro de uma entidade. Pode-se criar uma tabela
definindo-se seu tipo, seus campos e, quando necessário, a interface dos campos. Podem
ser cadastrados dados fixos, para tabelas do tipo depósito fixo (tabelas que nunca tem seus
dados alterados no PDA, pois são pré-definidos no servidor).
38
Figura 19 – Cadastro de Usuários
Na figura 19 é apresentada uma representação do cadastro de um usuário de um
sistema instanciado.
39
Figura 20 – Acesso de Usuário com Perfil PDA
A figura 20 é um projeto da tela de acesso ao sistema web de um usuário com perfil
PDA, ou seja, um usuário que utiliza o PDA como coletor de dados. Neste caso o acesso é
feito via PC, mediante um login. Existe a possibilidade de receber uma instalação do
sistema para o PDA (que deve ser posteriormente transferida para o aparelho) ou de
comunicação (por um applet Java).
40
Figura 21 – Interface do Sistema do PDA
A figura 21 representa as duas funcionalidades básicas da aplicação que é
executada nos PDA’s: coleta de dados e comunicação.
A coleta de dados é construída com base nas entidades e interfaces definidas na
comunicação. A comunicação permite que o usuário escolha, no PDA, qual a forma de
comunicação entre o PDA e o Servidor, e qual a porta do aparelho utilizada (serial, USB
ou Infravermelho).
41
Figura 22 – Emissão de Relatórios
A figura 22 é o projeto da interface para o usuário com perfil consulta web, que
pode emitir relatórios dos dados que foram coletados pelos PDA’s e armazenados no
servidor. O acesso é feito mediante login e os relatórios são pré-definidos em uma lista,
onde o usuário pode selecionar quais as informações deseja acessar.
42
3.5. CONSIDERAÇÕES SOBRE O PROJETO
A seguir serão apresentadas algumas considerações sobre o projeto do sistema, para
cada um dos módulos (banco de dados, cliente e servidor).
3.5.1. BANCO DE DADOS
O banco de dados será implementado no MSDE (SQL Server), e será acessado via
ODBC, no caso das páginas ASP e via JDBC no caso da aplicação Java para comunicação
que estará sendo executada no servidor.
Além das tabelas, já especificadas neste documento, serão armazenadas no próprio
SGBD as procedures para acesso aos dados, tornando o sistema mais encapsulado, pois a
lógica de banco de dados ficará toda no banco de dados. Os comandos na base de dados
são executados mediante a chamadas de procedures no código.
As tabelas apresentadas (sistema geral), são as tabelas que administram o restante
do banco de dados e permitem que o sistema recupere as informações das demais tabelas
que serão criadas em tempo de execução. Por exemplo, a construção de um “SELECT” na
base de dados de um sistema que foi instanciado será feita com base em informações
coletadas das tabelas administrativas. Construída a query, o comando será passado ao
banco de dados para o retorno dos dados específicos.
3.5.2. CLIENTE
A aplicação do cliente será totalmente implementada em Java e não terá acesso
direto ao SGBD, mas sim a arquivos em formato texto que são armazenados no PDA.
Assim, coloca-se como requisito para este sistema que o PDA tenha pelo menos dois
megabytes de memória livre, para que o sistema possa ser instalado, juntamente com
tabelas e dados coletados.
43
A implementação será feita com base nas especificações J2ME e J2SE, além do
pacote RMI (Remote Method Invocation, ou Invocação Remota de Métodos) para a
comunicação. No cliente pretende-se utilizar o Personal Java, que faz parte da
especificação do J2ME, para a execução das aplicações Java.
Uma característica marcante do sistema do cliente é o fato de ele ser composto de
uma base comum, que contém o sistema que é executado no PDA, e um template, que é
criado especificamente para cada sistema.
3.5.3. SERVIDOR
O servidor será composto de um site, baseado em tecnologia ASP que permitirá a
administração dos sistemas, consulta de relatórios e comunicação do PDA com o servidor.
A comunicação com o cliente será feita por RMI e, para isso uma aplicação estará rodando
no servidor para receber e armazenar os dados que os clientes enviam no banco de dados
(acesso via JDBC).
No site, pretende-se disponibilizar um applet para envio de dados do PDA ao
servidor, como segunda opção de comunicação – indireta. Assim, um PDA que não possui
modem ou cartão de acesso à rede poderá enviar os dados via serial, porta USB ou
infravermelho para um PC, que esteja acessando o site e enviar os dados através do applet,
atualizando os dados coletados na base central.
44
3.6. FERRAMENTAS UTILIZADAS
Para o desenvolvimento deste sistema estão sendo utilizada as seguintes
ferramentas:
-
Microsoft Visual Interdev: para o desenvolvimento do módulo web (baseado em
tecnologia ASP).
-
Java Creator: para o desenvolvimento dos módulos implementados em
linguagem Java.
-
J2ME, J2SE, Personal Java e Java RMI: para o desenvolvimento dos módulos
implementados em Java.
-
MSDE, ODBC e JDBC: ODBC e JDBC são utilizados para acessar o banco de
dados, que é armazenado no sistema de gerenciamento de banco de dados
MSDE (engine do SQL Server).
-
IIS (Internet Information Server): para executar as páginas ASP no servidor e
disponibiliza-las para acesso em uma intranet ou na internet.
Além destas ferramentas, está sendo utilizado para testes e simulações, um PDA do
tipo Pocket PC - HP Jornada 540, com dezesseis megabytes de memória.
Outras ferramentas como Microsoft Access para visualização e edição de dados em
tabelas e browser para acesso às páginas web também podem ser consideradas, auxiliando
no desenvolvimento do projeto.
45
4. CONCLUSÃO
A fase de especificação do projeto permitiu uma visualização do que seria
implementado como projeto final – um Sistema de Gerenciamento Customizável Baseado
em PDA’s. Já nesta segunda fase, de projeto, a idéia a mostrar algumas diretrizes de como
o projeto deverá ser implementado. A intenção é projetar o sistema antes da
implementação para que, nesta próxima fase, não existam erros conceituais no sistema.
Com a conclusão da etapa de projeto do sistema pode-se visualizar com mais
clareza os objetivos do sistema, bem como a forma como ele se relacionará com o meio
externo (usuários e dispositivos de hardware, neste caso os PDA’s).
A próxima etapa, na qual será apresentada a implementação do sistema servirá
como validação desta etapa de projeto, pois poderão ser verificados quais os pontos que
foram atendidos e os que não foram previstos nesta fase – ainda que a preocupação de
atingir todo o sistema tenha sido bastante grande.
Este documento está em sua segunda revisão, de um total de pelo menos quatro.
Ainda existem pontos a acrescentar e a alterar para que seja constituída a documentação
formal completa deste projeto.
46
5. ANEXO A – ANÁLISE DE CONCORRÊNCIA
A área de desenvolvimento de aplicações baseada em dispositivos móveis está em
grande expansão. Existem diversas software houses provendo soluções para este mercado,
mas nota-se que nenhuma destas soluções possui a característica da customização. A seguir
serão listados os principais concorrentes, bem como algumas informações adicionais.
1. Airgate:
Empresa de São Paulo. Foco de trabalho: wireless, energia, telecom e integração.
2. Bergen Mobile:
Situada em São Paulo, a Bergen Móbile atende várias empresas de grande porte e
tem os seus produtos voltados para a área de logística, exportação e importação.
3. Compusol:
A empresa, de São Paulo, é provedora de diversas soluções para PDA’s, além de
possuir uma linha completa de impressoras portáteis para os produtos da linha Palm. Todas
as aplicações são específicas, faltando apenas uma aplicação mais genérica.
4. Criterium:
Esta empresa do Rio Grande do Sul tem como clientes várias empresas de grande
porte e possui vários softwares disponíveis, como controle de vendas por PDA.
5. Eccelera do Brasil Ltda:
Um pouco diferenciada das demais empresas, a Eccelera trata de investimentos em
desenvolvimento de tecnologias na América Latina.
6. Hands:
Empresa do Rio de Janeiro. Possui soluções de integração PDA/WAP.
Interessante. Possui soluções para Palm / WAP. Destaca-se entre as soluções um
sincronizador, que possui:
47
-
Intercâmbio bidirecional, permitindo que servidores corporativos solicitem e
controlem o fluxo de informações de e para PDAs;
-
Protocolo de comunicação HTTP;
-
Padrão de intercâmbio de dados XML.
Esta empresa trabalha também no ramo de prover informações para dispositivos
portáteis.
7. HandSolutions:
Empresa de São Paulo. As aplicações são desenvolvidos em C com o Code
Warrior, o banco de dados é o Oracle, e soluções web são desenvolvidas em Linux e
Apache. O protocolo de comunicação utilizado é o TCP/IP. As páginas web são
desenvolvidas em PHP. Atua na área de força de vendas, logística, transporte,
gerenciamento de leads, coleta de dados, serviços financeiros, saúde, governo e Internet
wireless.
8. Logical Systems:
Sistuada no Rio de Janeiro, trabalha especificamente com computação móvel. Tem
soluções para automação de força de vendas, tomada de preços, fiscal de ponto, geração de
comandas eletrônicas, controle de frigobar, automação de diário de classe, simulador de
seguros previdenciários, vistoriador de seguros e pesquisa eletrônica.
10. Orbsystem:
Esta empresa de São Paulo alia computação móvel a sistemas de restreamento por
satélite (localização). Possui um sistema de restreamento pela web (Orb-soft web) bastante
interessante.
11. Palm Systeme:
Situada em Minas Gerais, a empresa desenvolve especificamente para PDA’s. Uma
aplicação interessante é um navegador UOL para Palm.
12. Portway:
Localizada em São Paulo, os produtos incluem soluções para: força de vendas,
visitação médica, gerência de bancos, seguros e previdência, logística, pesquisas e
manutenção em campo.
48
6. ANEXO B – ANÁLISE DE PDA’S
Existem diversos tipos de PDA’s disponíveis no mercado, com preços e
características variados. O objetivo para este sistema é permitir a utilização de todos estes
dispositivos, pois o software é baseado em uma solução Java, que é independente de
plataforma.
Na tabela I, a seguir, são apresentados alguns PDA’s pesquisados, com algumas
características básicas de cada solução.
Tabela I – Comparação de PDA’s
FABRICANTE
DO PDA
MODELO
DO PDA
PREÇO PARA A
AQUISIÇÃO
SISTEMA
OPERACIONAL
HP
Jornada 720
R$ 3799,00
MS Windows 2000 for
Haldheld PC
HP
Jornada 568
R$ 2199,00
MS Windows para
Pocket PC
HP
Jornada 548
R$ 1499,00
MS Windows para
Pocket PC
HP
Jornada 545
R$ 1499,00
MS Windows para
Pocket PC
HP
Jornada 525
R$ 999,00
MS Windows para
Pocket PC
Palm
i705
(indisponível no Brasil)
Palm OS 4.1
Palm
m515
R$ 1399,00
Palm OS 4.1
Palm
m505
R$ 1699,00
Palm OS 4.0
Palm
m500
R$ 1299,00
Palm OS 4.0
Palm
m130
R$ 899,00
Palm OS 4.1
Palm
m125
R$ 699,00
Palm OS 4.0
Palm
m100
R$ 459,00
Palm OS 3.5
Palm
Vx
R$ 783,00
Palm OS 3.3
Sharp
Zaurus – SL5000D
US$ 299,00 na JavaOne Feira anual de
desenvolvedores Java.
Linux 2.4 (Embedix) /
Personal Java (Jeode)
FUNCIONALIDADES
/ CARACTERÍSTICAS
O PDA vem com teclado
acoplado e é um dos
melhores da HP.
Não possui teclado
acoplado, mas é um dos
top de linha da HP.
Handheld com tela
colorida e recursos
multimídia.
Handheld com tela
colorida e recursos
multimídia.
Opção mais econoômica
e com menos memória
que os modelos 540.
Possui acesso a Internet
por wireless embutido.
Não disponível no Brasil.
Colorido e com bastante
memória em relação aos
demais da Palm.
Colorido e com a metade
da memória do m515.
Deixou de ser fabricado.
Opção monocromática e
com menos memória que
os superiores.
PDA mais simples, mas
com o atrativo da tela
coloriada.
PDA mais simples, com
tela monocromática e
utilização de pilhas.
PDA mais simples,
monocromático, pilhas.
Deixou de ser fabricado.
Opção intermediária
entre m100 e m500.
Deixou de ser fabricado.
Baseado em Java e Linux
com especificações
abertas.
49
Além destes, existem diversas outras soluções para computação móvel, desde
PDA’s mais simples e baratos a PDA’s com integração a telefones móveis.
Especial atenção deve ser dada ao Sharp Zaurus, que tem a plataforma aberta e é
baseado em Linux e Java. Este PDA possui um site para desenvolvedores com toda a
especificação de hardware e software necessárias para desenvolvimento, e é desenvolvido
por pessoas por todo o mundo.
Durante a JavaOne, evento anual de encontro de desenvolvedores Java., o
equipamento estava sendo vendido a US$ 299,00. A JavaOne aconteceu em março de
2002, em São Francisco – CA.
50
7. ANEXO C - CRONOGRAMA
Na tabela II é apresentado o cronograma básico do desenvolvimento deste projeto
final, com as atividades que serão desenvolvidas.
Tabela II - Cronograma
TAREFAS
Definição da Proposta de Projeto Final
Elaboração da Especificação de Projeto Final
Projeto e Análise de Sistema
Implementação do Sistema
Validação e Documentação
Reunião de Acompanhamento
INÍCIO
18/02/02
11/03/02
29/04/02
17/06/02
16/09/02
18/02/02
FINAL
04/03/02
15/04/02
24/06/02
23/09/02
25/11/02
25/11/02
DIAS
16
34
55
96
69
Este cronograma é baseado nas atividades macro do desenvolvimento do projeto.
Para estimativa de horas, devem ser consideradas 2 horas de trabalho por dia (14 horas
semanais), e trabalho sendo realizado por apenas 01 recurso.
Na figura 23 é apresentado um diagrama simplificado da distribuição das atividades
no tempo, no qual cada célula representa aproximadamente 10 dias de trabalho.
Figura 23 – Distribuição das Atividades no Tempo
51
8. ANEXO D – ESTIMATIVA DE CUSTOS
Para o desenvolvimento deste projetos estão sendo utilizados recursos que já não
estão disponíveis no mercado, como é o caso do PC Pentium 266 MHz. O próprio
Microsoft Visual Studio 6.0 já foi substituído pela nova versão .NET, que é
significativamente diferente.
Para efeitos de estimativa de custos, optou-se por considerar um computador atual,
com sistema operacional e ferramenta de desenvolvimento nas versões que estão sendo
comercializadas e um PDA intermediário.
Na tabela III são apresentadas as estimativas de custo do projeto.
Tabela III – Estimativa de Custos
RECURSO / INSUMO
PC Celeron 900MHz, 128MM RAM
PDA Palm M130
SGBD
J2ME / J2EE
Ms Windows Xp Professional
Ms Visual Studio .NET Professional
400 Horas de Desenvolvimento
TOTAL
CUSTO
Na figura 24 é apresentada a distribuição de custos do projeto.
Figura 24 – Distribuição de Custos
R$1799,00
R$899,00
R$0,00
R$0,00
R$859,00
R$3075,00
R$10000,00
R$16632,00
52
9. ANEXO E – SCRIPT DO BANCO DE DADOS
O script a seguir é utilizado para a criação do banco de dados e das tabelas de
administração de sistemas. Ainda devem ser incluídos os códigos das stored procedures.
DROP DATABASE dbSyGePDA
CREATE DATABASE dbSyGePDA
CREATE TABLE tblgeUsers(
usrID
integer
usrLogin
varchar(10)
usrPassword
varchar(10)
usrName
varchar(100)
usrCompany
varchar(100)
usrPosition
varchar(100)
usrMail
varchar(100)
usrPhone
varchar(20)
usrInputDate
datetime
)
PRIMARY KEY NONCLUSTERED,
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT GETDATE()
CREATE TABLE tblgeSystems(
sysID
integer
sysOwner
integer
sysName
varchar(100)
sysDescription
varchar(500)
sysInputDate
datetime
)
PRIMARY KEY NONCLUSTERED,
FOREIGN KEY REFERENCES tblgeUsers(usrID),
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT GETDATE()
CREATE TABLE tblgeStatus(
staID
integer
staName
varchar(50)
staInputDate
datetime
)
PRIMARY KEY NONCLUSTERED,
NOT NULL DEFAULT '',
NOT NULL DEFAULT GETDATE()
CREATE TABLE tblgeProfiles(
prfID
integer
prfName
varchar(50)
prfDescription
varchar(100)
prfInputDate
datetime
)
PRIMARY KEY NONCLUSTERED,
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT GETDATE()
CREATE TABLE tblgeSystemUserStatus(
susSystem
integer
susUser
integer
susStatus
integer
UNIQUE (susSystem, susUser)
)
FOREIGN KEY REFERENCES tblgeSystems(sysID),
FOREIGN KEY REFERENCES tblgeUsers(usrID),
FOREIGN KEY REFERENCES tblgeStatus(staID)
CREATE TABLE tblgeSystemUserProfile(
supSystem
integer
FOREIGN KEY REFERENCES tblgeSystems(sysID),
supUser
integer
FOREIGN KEY REFERENCES tblgeUsers(usrID),
supProfile
integer
FOREIGN KEY REFERENCES tblgeProfiles(prfID),
UNIQUE (supSystem, supUser, supProfile)
)
CREATE TABLE tblgePDAs(
pdaID
integer
pdaName
varchar(200)
pdaSerial
varchar(100)
pdaSO
varchar(50)
pdaMemory
integer
pdaInputDate
datetime
)
PRIMARY KEY NONCLUSTERED,
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT 0,
NOT NULL DEFAULT GETDATE()
53
CREATE TABLE tblgeUserPDAs(
updUser
integer
updPDA
integer
updStatus
integer
updInputDate
datetime
UNIQUE(updUser, updPDA)
)
FOREIGN KEY REFERENCES tblgeUsers(usrID),
FOREIGN KEY REFERENCES tblgePDAs(pdaID),
FOREIGN KEY REFERENCES tblgeStatus(staID),
NOT NULL DEFAULT GETDATE()
CREATE TABLE tblgeTableTypes(
ttyID
integer
ttyName
varchar(50)
ttyDescription
varchar(200)
ttyInputDate
datetime
)
PRIMARY KEY NONCLUSTERED,
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT GETDATE()
CREATE TABLE tblgeTables(
tabID
integer
tabTableType
integer
tabName
varchar(50)
tabDescription
varchar(200)
tabInputdate
datetime
tabUpdateDate
datetime
)
PRIMARY KEY NONCLUSTERED,
FOREIGN KEY REFERENCES tblgeTableTypes(ttyID),
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT GETDATE(),
NOT NULL DEFAULT GETDATE()
CREATE TABLE tblgeSystemTables(
sytSystem
integer
sytTable
integer
UNIQUE (sytSystem, sytTable)
)
FOREIGN KEY REFERENCES tblgeSystems(sysID),
FOREIGN KEY REFERENCES tblgeTables(tabID),
CREATE TABLE tblgeInterfaces(
intID
integer
intName
varchar(50)
intDescription
varchar(200)
fltInputdate
datetime
)
PRIMARY KEY NONCLUSTERED,
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT GETDATE()
CREATE TABLE tblgeFieldTypes(
fltID
integer
fltName
varchar(50)
fltDescription
varchar(200)
fltInputdate
datetime
)
PRIMARY KEY NONCLUSTERED,
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT GETDATE()
CREATE TABLE tblgeFieldTypeInterface(
ftiFieldType
integer
FOREIGN KEY REFERENCES tblgeFieldTypes(fltID),
ftiInterface
integer
FOREIGN KEY REFERENCES tblgeInterfaces(intID),
UNIQUE (ftiFieldType, ftiInterface)
)
CREATE TABLE tblgeFields(
fldID
integer
fldFieldType
integer
fldName
varchar(50)
fldDefault
varchar(200)
fldNotNull
bit
fldInputdate
datetim
)
PRIMARY KEY NONCLUSTERED,
FOREIGN KEY REFERENCES tblgeFieldTypes(fltID),
NOT NULL DEFAULT '',
NOT NULL DEFAULT '',
NOT NULL DEFAULT 0,
NOT NULL DEFAULT GETDATE()
CREATE TABLE tblgeSystemFieldInteface(
sfiID
integer
PRIMARY
sfiSystem
integer
FOREIGN
sfiField
integer
FOREIGN
sfiInterface
integer
FOREIGN
UNIQUE(sfiSystem, sfiField, sfiInterface)
)
KEY
KEY
KEY
KEY
NONCLUSTERED,
REFERENCES tblgeSystems(sysID),
REFERENCES tblgeFields(fldID),
REFERENCES tblgeInterfaces(intID)
CREATE TABLE tblgeTableFieldRelationship(
tfrID
integer
PRIMARY KEY NONCLUSTERED,
tfrParentTable
integer
FOREIGN KEY REFERENCES tblgeTables(tabID),
tfrChildTable
integer
FOREIGN KEY REFERENCES tblgeTables(tabID),
tfrParentField
integer
FOREIGN KEY REFERENCES tblgeFields(fldID),
tfrChildField
integer
FOREIGN KEY REFERENCES tblgeFields(fldID)
UNIQUE (tfrParentTable, tfrParentField, tfrChildTable, tfrChildField)
)
54
CREATE TABLE tblgeFieldInterfaceKey(
fikFieldInterface
integer
FOREIGN KEY REFERENCES tblgeSystemFieldInteface(sfiID),
fikRelationship
integer
FOREIGN KEY REFERENCES tblgeTableFieldRelationship(tfrID),
fikKey
integer
FOREIGN KEY REFERENCES tblgeFields(fldID),
fikDisplayOrder
integer
NOT NULL DEFAULT 0,
fikSortOrder
integer
NOT NULL DEFAULT 0,
fikDescendent
bit
NOT NULL DEFAULT 0
UNIQUE(fikFieldInterface, fikRelationship, fikKey)
)
CREATE TABLE tblgeTableFields(
tflTable
integer
tflField
integer
UNIQUE (tflTable, tflField)
)
CREATE TABLE tblgeReportQueries(
rpqID
integer
rpqSystem
integer
rpqQuery
varchar(5000)
rpqInputDate
datetime
)
FOREIGN KEY REFERENCES tblgeTables(tabID),
FOREIGN KEY REFERENCES tblgeFields(fldID)
PRIMARY KEY NONCLUSTERED,
FOREIGN KEY REFERENCES tblgeSystems(sysID),
NOT NULL DEFAULT '',
NOT NULL DEFAULT GETDATE()
55
10.
REFERÊNCIAS BIBLIOGRÁFICAS
DEITEL, H. M.; DEITEL, P. J. Java – Como Programar. 3.ed. Porto Alegre,
Bookman, 2001.
GRIMES, RICHARD. Professional DCOM Programming. Canadá, Wrox Press,
1997.
BATE BYTE – O ESTADO DA ARTE NA CELEPAR / Companhia de
Informática do Paraná. Curitiba, n. 118, Março 2002.
PALM, http://www.palm.com, Março/2002.
PALM OS EMULATOR,
http://webdev.apl.jhu.edu/~rbe/kvm/HowToInstallPOSE.html, Março/2002.
PALM OS, http://www.palmos.com/dev/tools/emulator/, Março/2002.
PALM DEVELOPERS, http://www.palm.com/br/developers/dev_index.html,
Março/2002
KVM, http://www.ajug.org/info/tech/KVM/kvm.html, Março/2002.
JAVA, http://www.javasoft.com, Março/2002.
MSDN, http://msdn.Microsoft.com/vstudio/downloads/addins/msde/default.asp,
Março/2002.
MYSQL, http://www.mysql.com, Março/2002.