Sistema de Gerenciamento Customizável Baseado em PDA`s
Propaganda
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.
