PROVEW - PROGRAMA DE VENDAS COM CONEXÃO WIRELESS DESTINADO ÀS EMPRESAS DE DEFENSIVOS AGRÍCOLAS

Transcrição

1 CENTRO UNIVERSITARIO DE VILA VELHA CURSO DE CIÊNCIA DA COMPUTAÇÃO CRISTIANO FIORESI ANDREÃO IGOR TOMAZ GRAVEL PROVEW - PROGRAMA DE VENDAS COM CONEXÃO WIRELESS DESTINADO ÀS EMPRESAS DE DEFENSIVOS AGRÍCOLAS VILA VELHA 2008

2 1 CENTRO UNIVERSITARIO DE VILA VELHA CURSO DE CIÊNCIA DA COMPUTAÇÃO CRISTIANO FIORESI ANDREÃO IGOR TOMAZ GRAVEL PROVEW - PROGRAMA DE VENDAS COM CONEXÃO WIRELESS DESTINADO ÀS EMPRESAS DE DEFENSIVOS AGRÍCOLAS Monografia do Trabalho de Conclusão de Curso de Graduação em Ciência da Computação apresentada ao Centro Universitário Vila Velha, como requisito parcial para a obtenção do título de Bacharel em Ciência da Computação, sob orientação do (a) prof. (a) Vinicius Rosalen da Silva e coorientação de Carlos Eduardo Andreao. VILA VELHA 2008

3 2 RESUMO Cada vez mais as empresas buscam ganhar fatias de mercado, incorporando melhorias em seus processos de funcionamento. Para obter isso procuram investem em novas tecnologias e métodos segurança, ação que gera resultados satisfatórios referentes a todos os setores de uma empresa. Particularmente, para empresas de vendas de defensivos agrícolas de locais afastados de centros urbanos, existe um problema para a implantação de um sistema Web convencional: a falta de conectividade com a Internet para que o vendedor de campo possa efetuar um pedido. Sendo assim as empresas acabam tendo que realizar suas vendas, por exemplo, com notas de papel, que por sua vez não é um processo ágil, eficaz e seguro. Para minimizar esses problemas foi proposto um programa de vendas com conexão wireless destinado a estas empresas (PROVEW), onde os vendedores poderão efetuar vendas seguramente através de dispositivos móveis. Para desenvolvimento de tal sistema foi utilizada a tecnologia Java que abrangeu o uso de algumas API s de JEE como JSP, JSF, Servlets entre outros, além de JME para o desenvolvimento do sistema móvel. Na parte de segurança foram analisadas várias técnicas tanto na parte web quanto na parte móvel visando maior segurança das informações contidas no sistema. O banco de dados escolhido para desenvolvimento do sistema foi o MySQL devido a sua gratuidade e seu uso bastante difundido. Para persistência no banco foram utilizado conceitos do padrão DAO (Data Access Object). Para o projeto do sistema, a arquitetura escolhida foi o padrão MVC. Na composição dos relatórios foi feito uso do ireport/jasperreport. O servidor de aplicação utilizado para desenvolvimento do sistema foi o Apache Tomcat 6.0.

4 3 LISTA DE FIGURAS Figura 1 - Edições da linguagem Java e seus respectivos alvos de aplicação...11 Figura 2 - Camadas da Arquitetura JEE...12 Figura 3 - A Arquitetura Java Micro Edition (JME)...16 Figura 4 - Máquina de Estados do ciclo de vida de um MIDlet...18 Figura 5 - SGBD x RMS x Arquivo...20 Figura 6 - Hierarquia das interfaces no GCF e Classes relacionadas...21 Figura 7 - Modelo de Criptografia de Chave Simétrica...27 Figura 8 - Modelo de Criptografia de Chave Pública...28 Figura 9 Estrutura do https...30 Figura 10 - Camadas adicionais do SSL...30 Figura 11- SSL Handshake Protocol...31 Figura 12 - Diagrama de Pacotes do Sistema PROVEW...37 Figura 13 Atores do Sistema PROVEW...38 Figura 14. Diagrama de Casos de Uso do pacote Web...39 Figura 15. Diagrama de Casos de Uso do pacote Móvel...41 Figura 16 - Estrutura de Camada...42 Figura 17 Modelo Conceitual do sistema PROVEW...43 Figura 18 Modelo de Persistência do sistema PROVEW (WEB)...44 Figura 19 Modelo de navegação do pacote WEB...45 Figura 20 Modelo de navegação do pacote móvel...46

5 4 LISTA DE SIGLAS A API - Application Programming Interface C CDC Connected Device Configuration CLDC Connected Limited Device Configuration D DAO Data Access Object G GCF - Generic Connection Framework H HTML HiperText Markup Language HTTP HyperText Transfer Protocol HTTPS HyperText Transfer Protocol Secure I IDE Integrated Development Environment IMP Information Module Profile IPP - Internet Printing Protocol J JSF JavaServer Faces JSP JavaServer Pages JEE Java Enterprise Edition JME Java Micro Edition K KVM Kilobyte Virtual Machine M MIDP Mobile Information Device Profile O OO Orientação a Objetos P PDA Personal Digital Assistant PROVEW Programa de Vendas com Conexão Wireless R RMS Record Management System

6 5 S SQL Structure Query Language SGBD Sistema Gerenciador de Banco de Dados SSL Secure Sockets Layer T TLS - Transport Layer Security U UML Unified Modeling Language X XHTML Extensible Hipertext Markup Language XML Extensible Markup Language

7 6 SUMÁRIO 1 INTRODUÇÃO TECNOLOGIAS A TECNOLOGIA JAVA A PLATAFORMA ENTERPRISE EDITION JAVA EE A Tecnologia Servlets e Javaserver Pages A Tecnologia Javaserver Faces A PLATAFORMA JAVA MICRO EDITION JAVA ME A Arquitetura Java Me MIDlets RMS - Record Management System GCF - Generic Connection Framework O IREPORT E O JASPER REPORTS BANCO DE DADOS MYSQL SEGURANÇA REQUISITOS PARA UMA APLICAÇÃO SEGURA CRIPTOGRAFIA Chave Simétrica Chave Assimétrica ASSINATURA DIGITAL CERTIFICADO DIGITAL CONEXÕES SEGURAS SSL TLS MECANISMOS DE SEGURANÇA EM JAVA ME APIs do MIDP SATSA Bouncy Castle (LIGHT EDITION) O SISTEMA PROVEW ARQUITETURA DA APLICAÇÃO...35

8 7 4.2 DESCRIÇÃO DO MINI-MUNDO DIAGRAMAS DE PACOTES DO DOMÍNIO Modelo de Casos de Uso Pacote Web Pacote Móvel PROJETO DO SISTEMA Modelo Conceitual Modelo de Persistência Modelo de Navegação IMPLEMENTAÇÃO E TESTES CONSIDERAÇÕES FINAIS...48 REFERÊNCIAS BIBLIOGRAFICAS...50 ANEXOS...53

9 8 1. Introdução Nos últimos anos pode ser observado um notável aumento na utilização de dispositivos móveis, que fazem uso da tecnologia de comunicação sem fio, em especial dos telefones celulares. Tais aparelhos apesar do poder computacional limitado, a cada momento possuem uma nova forma, tamanho, aumento na capacidade de processamento, além de novos aplicativos agregados. À medida que a demanda por funcionalidades aumenta, as empresas de telefonia celular vêm acrescentando novas tecnologias a tais aparelhos, estimulando nos consumidores o desejo de possuir o mais recente modelo de uma determinada marca. Em contradição a todos estes benefícios, um grande problema vem agregado com este avanço, sendo este: a falta de mecanismos segurança para tais aplicações. Particularmente, para empresas de vendas de defensivos agrícolas, distantes de centros urbanos, existe um problema para a implantação de um sistema web convencional: a falta de conectividade com a Internet para que o vendedor de campo possa efetuar um pedido, sendo assim as empresas acabam tendo que realizar suas vendas, por exemplo, com notas de papel, que por sua vez não é um processo ágil, eficaz e seguro. Sabendo que o sinal dos celulares permite um maior alcance do que o da Internet foi proposto um projeto denominado PROVEW, que fará o uso de algumas tecnologias para o desenvolvimento de um sistema móvel seguro destinado às empresas de defensivos agrícolas com o objetivo de auxiliar um vendedor a estar sempre atualizado com a disponibilidade do estoque e reajustes de preços, assim podendo haver uma diminuição dos custos, e também diminuir o tempo de resposta para que a empresa possa encaminhar o produto para o cliente. Este trabalho tem por finalidade conceituar o desenvolvimento desse sistema, fazendo o uso de tecnologias atuais associado a mecanismos de segurança. Com

10 9 isso espera-se obter um esclarecimento aplicado a uma situação real deste conceito. A aplicação proverá aos usuários o serviço de vendas e gerenciamento de vendas. Um funcionário que possuir um aplicativo instalado em seu celular pode, por exemplo, acessar dados cadastrados pela empresa em um sistema web e por sua vez realizar vendas com dados atualizados instantaneamente. Além disso, o sistema disponibilizará em sua parte web todo o gerenciamento de vendas realizadas nos dispositivos. O sistema está dividido em um módulo cliente e um módulo servidor. O cliente é o aplicativo que estará rodando no celular e terá como uma de suas responsabilidades, receber a entrada de dados informados pelo usuário. Uma comunicação com o servidor deve ser estabelecida para que os dados sejam transmitidos. Ao receber os dados, o servidor deve processá-los e armazená-los. A estrutura deste trabalho foi dividida em cinco capítulos, Os Capítulos 2 e 3 respectivamente explicam as tecnologias e técnicas de segurança que foram utilizadas no desenvolvimento, tanto do lado cliente quando do lado servidor. O Capítulo 4 mostra como foi implementado e estruturado todo o sistema. No Capitulo 5 são apresentadas as conclusões sobre o presente trabalho, as dificuldades enfrentadas e as perspectivas sobre possíveis trabalhos futuros.

11 10 2. Tecnologias Neste capítulo são abordados os elementos necessários para atender todos os requisitos do sistema e o objetivo do projeto. Em cada elemento foi feito um estudo de algumas tecnologias que possam dar-lhe suporte. 2.1 A Tecnologia Java A crescente evolução tecnológica vem permitindo inúmeros avanços, inclusive quando se faz referência a utilização de dispositivos móveis, que não se destinam somente a finalidades de comunicação oral. Neste contexto, a utilização da tecnologia Java torna-se importante aliada, como suporte, para o sucesso desse crescimento. O surgimento da tecnologia Java se deu em 1991, na empresa Sun Microsystems, que fundou uma corporação internacional composta por quatro integrantes para a elaboração de um projeto cujo codinome era Green. Esse projeto resultou no desenvolvimento de uma linguagem de programação baseada em C e C++ [1]. A linguagem Java foi projetada tendo em vista as seguintes características [1]: Orientada para objetos. Interpretada e compilada. Neutra em relação à arquitetura e portável. Dinâmica e distribuída. Robusta. Segura. Multithreading. A versão atual Java está dividida em:

12 11 Java Standard Edition (Java SE) [2]: Tecnologia projetada para computadores pessoais e ambientes de trabalho desktops. Java Micro Edition (Java ME) [3] Tecnologia direcionada para dispositivos com recursos computacionais limitados como, por exemplo, palms e telefones celulares. Java Enterprise Edition (Java EE) [4]: É um conjunto de tecnologias e práticas que permitem soluções para o controle de aplicações servidoras. A Figura 1 apresenta as edições da linguagem Java de acordo com seus alvos e aplicações. Figura 1- Edições da linguagem Java e seus respectivos alvos de aplicação. 2.2 A Plataforma Enterprise Edition Java EE A arquitetura JEE foi desenvolvida sobre a plataforma JSE (Java Standard Edition) [2] utilizando assim as APIs básicas para o desenvolvimento de programas e aplicações. Logo, é baseada na linguagem Java e segue a mesma lógica de escrever apenas uma vez e conseguir rodar em qualquer plataforma. JEE faz uso do modelo de aplicação multicamadas onde cada aplicação lógica é dividida em componentes de acordo com sua funcionalidade e vários

13 12 componentes das aplicações podem ser instalados em diferentes máquinas dependendo da camada em que ele se encontra. As camadas podem ser divididas da seguinte forma[5]: A camada cliente que roda em uma máquina cliente; A camada de componentes WEB, aplicações JEE que rodam no servidor; A camada de informações (EIS Enterprise Information System) que também roda no servidor; Essas camadas podem ser mais bem observadas na Figura 2. Figura 2 - Camadas da Arquitetura JEE O lado cliente pode ser dividido em duas partes: Páginas web dinâmicas como, por exemplo, HTML (Hiper Text Markup Language) ou XML (Extensible Markup Language) [5] que são geradas pelos componentes web presentes na camada web.

14 13 Web browser que são os responsáveis por redirecionar as páginas a medida que são recebidas pelo servidor A Tecnologia Servlets e JavaServer Pages No relacionamento cliente-servidor, o cliente solicita que alguma ação seja realizada e o servidor realiza a ação e responde para o cliente. Esse modelo de comunicação de solicitação-resposta é a base para as visualizações de nível mais alto de rede no Java Servlets e JavaServer Pages (JSP) [6]. Um Servlet estende a funcionalidade de um servidor, como um Servidor Web que serve páginas da Web para um navegador do usuário com o protocolo HTTP. Utilizando uma sintaxe especial, o JSP permite que implementadores de páginas Web criem páginas que encapsulem a funcionalidade Java e até mesmo escrevam código real Java dentro da própria página. As JSP s são uma maneira eficiente de implementar o mecanismo de solicitaçãoresposta da Web sem entrar nos detalhes de nível mais baixo dos servlets. Juntos, os servlets e JSP s formam os componentes Web do Java Enterprise Edition (JEE) que executam em um servidor JEE. A tecnologia JavaServer Pages, uma extensão da tecnologia dos Servlets, simplifica o processo da criação das páginas, separando a apresentação do conteúdo. Normalmente, as JSP s são utilizadas quando a maior parte do conteúdo enviado ao cliente é texto estático e marcação; e somente uma pequena parte do conteúdo é gerada dinamicamente como código Java. Os servlets são comumente utilizados quando uma pequena parte do conteúdo enviado ao cliente é texto estático ou marcação. Na verdade, alguns servlets não produzem conteúdo. Em vez disso, realizam uma tarefa em favor do cliente e então invocam outros servlets ou JSP s para fornecerem uma resposta. Na maioria dos casos as tecnologias de servlets e JSP são intercambiáveis. O servidor que executa um servlet é chamado de Contêiner de Servlet.

15 14 Os servlets fazem a comunicação entre clientes e servidores através do protocolo HTTP. Um cliente faz uma solicitação de HTTP ao servidor. O contêiner de servlets recebe a solicitação e a redireciona para ser processada pelo servlet apropriado. O servlet faz seu processamento, que pode interagir com o banco de dados ou com outros servlets ou JSP no servidor. O servlet retorna seus resultados ao cliente, normalmente na forma de documentos HTML, XHTML ou XML para exibir em um navegador A Tecnologia JSF JavaServer Faces JSF (JavaServer Faces) [7] é uma tecnologia que incorpora características de um framework MVC para WEB e de um modelo de interfaces gráficas baseado em eventos. Por basear-se no padrão de projeto MVC, uma de suas melhores vantagens é a clara separação entre a visualização e regras de negócio (modelo). A idéia do padrão MVC é dividir uma aplicação em três camadas: modelo, visualização e controle. O modelo é responsável por representar os objetos de negócio, manter o estado da aplicação e fornecer ao controlador o acesso aos dados. A visualização representa a interface com o usuário, sendo responsável por definir a forma como os dados serão apresentados e encaminhar as ações dos usuários para o controlador. Já a camada de controle é responsável por fazer a ligação entre o modelo e a visualização, além de interpretar as ações do usuário e as traduzir para uma operação sobre o modelo, onde são realizadas mudanças e, então, gerar uma visualização apropriada. JavaServer Faces oferece ganhos no desenvolvimento de aplicações Web por diversos motivos[7]: Permite que o desenvolvedor crie interfaces através de um conjunto de componentes pré-definidos; Fornece um conjunto de tags JSP para acessar os componentes;

16 15 Reusa componentes da página; Associa os eventos do lado cliente com os manipuladores dos eventos do lado servidor (os componentes de entrada possuem um valor local representando o estado no lado servidor); Fornece separação de funções que envolvem a construção de aplicações WEB. Embora JavaServer Faces forneça tags JSP para representar os componentes em uma página, ele foi projetado para ser flexível, sem limitar-se a nenhuma linguagem markup em particular, nem a protocolos ou tipo de clientes. Ele também permite a criação de componentes próprios a partir de classes de componentes, conforme mencionado anteriormente. JSF possui dois principais componentes: Java APIs para a representação de componentes de interface e o gerenciamento de seus estados, manipulação/observação de eventos, validação de entrada, conversão de dados, internacionalização e acessibilidade; e taglibs JSP que expressam a interface JSF em uma página JSP e que realizam a conexão dos objetos no lado servidor. No JSF, o controle é composto por um Servlet denominado FacesServlet [7], por arquivos de configuração e por um conjunto de manipuladores de ações e observadores de eventos. O FacesServlet é responsável por receber requisições da WEB, redirecioná-las para o modelo e então remeter uma resposta. Os arquivos de configuração são responsáveis por realizar associações e mapeamentos de ações e pela definição de regras de navegação. Os manipuladores de eventos são responsáveis por receber os dados vindos da camada de visualização, acessar o modelo, e então devolver o resultado para o FacesServlet.

17 A Plataforma Java Micro Edition Java ME A plataforma JME foi introduzida em Junho de 1999 na convenção anual JavaOne. Inicialmente, foi projetada para dispositivos com potência limitada e conectividade de rede (na maioria das vezes sem fios) [8] A arquitetura Java ME A arquitetura da plataforma Java ME é dividida em quatro camadas: Máquina Virtual (KVM), Configurações (CLDC, CDC) e Perfis (MIDP, IMP), como apresentado na Figura 3. Figura 3 - A Arquitetura Java Micro Edition (JME) Configuração A Configuração é um conjunto de bibliotecas básicas disponíveis para o programador. Ela também define qual o nível de serviços e funcionalidades oferecidos pela Máquina Virtual. Uma configuração é definida para uma classe horizontal de dispositivos, ou seja, uma gama de dispositivos com diferentes aplicações, mas com características em comum. Por exemplo, dispositivos com comunicação wireless, abrangendo celulares, PDA s, pagers, etc. No momento existem duas configurações definidas: O CLDC (Connected Limited Device Configuration) [9], utilizado em dispositivos limitados como celulares, PDA s, pagers, etc e o CDC (Connected Devide Configuration) [9], utilizado em

18 17 dispositivos com maior capacidade (de memória e processamento) como Sistemas de Navegação de Carros, Televisores com Conexão à Internet, etc. Perfil O Perfil define um conjunto de bibliotecas específicas para classes verticais de dispositivos, ou seja, poderíamos ter um perfil para celulares, outro para PDA s, etc. Um perfil é sempre especificado para uma determinada configuração, mas uma configuração pode dar suporte a vários perfis. Existem dois perfis definidos para o CLDC: o MIDP (Mobile Information Device Profile) [10], e o IMP (Information Module Profile) [10]. O IMP é mais recente e é basicamente um subconjunto do MIDP e é utilizado em dispositivos com uma interface mais limitada. Máquina Virtual A Máquina Virtual fica diretamente acima do sistema operacional do dispositivo. É ela quem define quais as limitações dos programas que executarão no dispositivo. A máquina virtual correspondente ao CLDC é chamada KVM (Kilobyte Virtual Machine), desenhada especialmente para dispositivos pequenos e com recursos limitados. A KVM mantém os aspectos centrais da Máquina Virtual Java e tem tamanho reduzido a algumas centenas de kilobytes [10]. Pacotes Opcionais Além das configurações e dos perfis, ainda existem as bibliotecas chamadas: Pacotes Opcionais, que são bibliotecas de programação específicas a uma determinada tecnologia. Elas aumentam a capacidade do ambiente, caso estejam implementadas no dispositivo.

19 MIDlets MIDlet é um aplicativo Java para executar em um dispositivo móvel. A classe MIDlet constrói um aplicativo MIDlet, onde o método dessa classe é acessada pelo gerenciador de aplicações. Quando mais de uma MIDlet se encontram em uma mesma aplicação, dá-se o nome de MIDlet Suite [10]. Seu ciclo de vida é dividido em três estados: Pausada, Ativa e Destruída [10]. A MIDlet pode passar por cada um desses estados. A Figura 4 abaixo apresenta a máquina de estados que compõem o ciclo de vida de uma MIDlet. Figura 4 - Máquina de Estados do ciclo de vida de um MIDlet. Na classe MIDlet podemos encontrar um método para cada mudança de estado de seu aplicativo. Esses métodos devem ser implementados sempre na classe principal de seu aplicativo, pois esta classe deverá estender a classe MIDLet [8]. Assim que o usuário fizer uma chamada a um MIDlet, este aplicativo usará o método startapp() para mudar o estado deste MIDlet, neste caso para ativo. Suponha agora que com o aplicativo no estado ativo, o usuário receba uma ligação. Neste momento o método pauseapp() será invocado para que o estado do aplicativo seja alterado para pausado, e assim que esta ação for concretizada o método notifypaused() será chamado. Após finalizar a ligação o usuário poderá voltar ao aplicativo que estava pausado. Neste momento o método startapp() modifica o estado do aplicativo que estava pausado, voltando agora para ativo.

20 19 Após a mudança do estado, o método resumerequest() será chamado. E finalmente quando o usuário deseja fechar o aplicativo, o método destroyapp() passa o MiDlet para o estado destruído. Quando ocorre esta mudança o método notifydestroyed() é invocado. No caso em que ocorre algum problema na mudança entre estados, a Exception MIDletStateChangeException é lançada RMS - Record Management System Normalmente, os dispositivos móveis possuem dois tipos de memória: uma volátil, onde os aplicativos são carregados, e a segunda é a memória persistente, onde são gravadas informações que devem permanecer para consultas futuras. Atualmente, celulares estão vindo com cartões de memória, algo como Memory Stick da Sony, ou o Compact Flash. Assim, a capacidade de armazenamento do celular cresceu muito, e para facilitar essa persistência foi desenvolvida API RMS. RMS é um mecanismo de persistência baseado em registros definidos pela MIDP do JME que por sua vez disponibiliza uma API que permite a leitura, escrita e atualização de registros persistentes em memória. A API RMS [9] está localizada no pacote javax.microedition.rms e possui as seguintes classes e interfaces: RecordStore, RecordEnumeration, RecordComparator, RecordFilter e RecordLister. Sua estrutura é bastante enxuta e suas funcionalidades estão concentradas na classe RecordStore que nada mais é que um repositório de registros com métodos de acesso e manipulação dos mesmos. Vejamos algumas regras para o uso dos RecordStores [9]: Os nomes dos RecordStores são Case Sensitive, devem ter entre 1 e 32 caracteres Unicode. Quando um MIDlets suíte é removida, todos os RecordStores associados à ela também serão removidos.

21 20 Vejamos agora alguns métodos da classe RecordStore [9]: getlastmodified: informa a data (retorna um long) da última modificação; getsize: retorna o tamanho ocupado (em bytes); getsizeavailable: retorna o tamanho disponível (em bytes); getversion: retorna o número da versão. Para cada operação realizada (inclusão, alteração, deleção) é atualizado o número de versão. addrecordlistener e removerecordlistener: para gerenciar os eventos gerados com o RecordStore listrecordstores: método static que retorna um array de Strings com os nomes de todos os RecordStores dentro de uma suíte de MIDlets. O RMS não pode ser confundido como um sistema de arquivos nem como um sistema de SGBD, seus registros não possuem uma estrutura organizada, não possuem controle de acesso e nem linguagem de acesso (SQL). A figura a seguir representa a estrutura de cada um dos sistemas (SGBD x RMS x Arquivo): Figura 5 - SGBD x RMS x Arquivo

22 GCF - Generic Connection Framework Na configuração CLDC do Java ME há um framework de conexão denominado Generic Connection Framework (GCF) [8], que está presente no pacote javax.microedition.io. O GCF tem como objetivo adequar os recursos de conexões oferecidos pelo Java SE para aplicações que implementam o Java ME. O Generic Connection Framework fica localizado no pacote javax.microedition.io e possui uma classe (Connector), um exceção (ConnectionNotFoundException) e oito interfaces, como pode ser vista na Figura 6. Figura 6 - Hierarquia das interfaces no GCF e Classes relacionadas Fonte: [11] A seguir serão apresentadas as classes quem compõem o GCF, referentes aos perfis do MIDP 1.0 e o MIDP 2.0 [13]:

23 22 MIDP Connnection: define o tipo mais básico de conexão genérica. - ContentConnection: define o fluxo através do qual o conteúdo da conexão é enviado. - Datagram: interface de datagrama genérica. Representa um objeto capaz de receber e enviar dados através de uma conexão datagrama. Essa conexão pode ser cliente ou servidora. - DatagramConnection: define as características de uma conexão datagrama, que pode ser cliente ou servidor. - HttpConnection: define os métodos e constantes necessários para uma conexão HTTP. - InputConnection: essa interface define as características que uma conexão de entrada de dados deve possuir. - OutputConnection: essa interface define as características que uma conexão e saída de dados deve possuir. - StreamConnection: estende as interfaces InputConnection e OutputConnection, definindo uma conexão capaz de receber e enviar dados. - StreamConnectionNotifier : define as características que um notificador de conexões deve ter. - Connector : é o ponto central do GCF. A classe Connector é uma classe factory usada para criar as conexões. O método Connector.open() retorna um objeto de conexão cujo tipo é definido por um dos tipos de protocolo (socket (TCP), datagram(udp), entre outros). Esse método recebe como parâmetro uma string URL da forma { protocol } : [ {address } ] [ { params } ], em que protocolo define o tipo de conexão; address define o endereço-alvo da conexão (um host, uma porta, um arquivo, entre outros) e params (opcional) são as informações adicionais que complementam a string de conexão.

24 23 MIDP ServerSocketConnection: define o socket servidor de uma conexão. O socket é criado através da chamada ao método Connector.open("socket://:port"). O nome do host é omitido na chamada, indicando a criação de um socket passivo. O método ServerSocketConnection.acceptAndOpen() recebe os pedidos de conexão e retorna uma instância da classe SocketConnection, estabelecendo uma conexão cliente-servidor. O acesso ao servidor pode ser restringido pela política de segurança do dispositivo. - UDPDatagramConnection: cria uma conexão do tipo datagrama que permite conhecer seu número de porta local (diferentemente da conexão criada com a interface Datagram). A conexão do tipo UDPDatagramConnection possui as vantagens e limitações do protocolo UDP. - SecurityInfo: provê métodos para acesso a informações sobre uma conexão de rede segura. Pode ser usado para identificar os parâmetros de segurança de uma conexão, como o certificado usado para estabelecer uma conexão segura. - HttpsConnection: O HTTPS é o mesmo protocolo HTTP, porém, sendo transportado sobre uma camada de segurança (SSL). Sua comunicação é mais lenta que o HTTP e o processamento no dispositivo móvel aumentam consideravelmente devido aos bytes de controle e à necessidade de processar os algoritmos de criptografia. - PushRegistry: mantêm uma lista das conexões de entrada (clientes). - CommConnection: define uma conexão de porta serial lógica, que transmite bytes serialmente. 2.4 O ireport e o JasperReports

25 24 O ireport [14] é um programa OpenSource que pode criar complexos relatórios. O ireport é escrito em sua totalidade pela linguagem JAVA e é distribuído com o código fonte de acordo com a distribuição GNU GPL General Public License. Através de uma interface gráfica intuitiva e rica, pode-se criar qualquer tipo de relatório de maneira simples e rápida. O ireport permite que pessoas que tenham pouca habilidade com esta tecnologia diminuam as dificuldades no processo de aprendizagem da sintaxe de XML de JasperReports[14] e para os usuários hábeis que conhecem bem esta sintaxe, que diminuam em muitas horas o desenvolvimento de relatórios muito elaborados. Abaixo seguem algumas das mais importantes características do ireport [15]: 99% de suporte ao JasperReport XML tags; WYSIWYG Editor para criação de relatórios. Esta é uma completa ferramenta para desenhar retângulos, linhas, elipses, campos de texto, etiquetas, cartas, subrelatórios etc; Navegador para estrutura do documento; Suporte para todos os bancos de dados acessíveis por JDBC; Suporte a sub-relatórios; Ilimitado Undo/Redo; O coração do ireport é uma biblioteca OpenSource chamada JasperReports [14], desenvolvida e mantida por Teodor Danciu, um desenvolvedor Romeno. O JasperReport é a distribuição mais completa e um dos softwares mais poderosos para criação de relatórios atualmente. Essa integração por completo entre o ireport e a biblioteca JasperReport, e o grande suporte dado por essas ferramentas/api s, faz deste conjunto uma grande opção para a implementação dos relatórios do sistema PROVEW.

26 Banco de Dados MySQL O programa MySQL é um servidor robusto de banco de dados SQL (Structure Query Language Linguagem Estruturada para Pesquisa) muito rápido, multitarefa e multi-usuário (MySQL Reference Manual)[16]. Além disso, este banco de dados relacional é gratuito, muito eficiente e otimizado para aplicações Web [16]. Sendo que ele possui menos recursos se comparado ao PostgreSQL [17] - outro banco relacional gratuito muito utilizado. Esse SGBD também é multi-plataforma, sendo compatível com o Windows, Linux, entre outros sistemas operacionais e também é compatível com várias linguagens de programação, tais como PHP, C, Java, Visual Basic, C#, entre outras. Como a evolução do MySQL nas suas últimas versões foi grande, podendo ser utilizado até para aplicações complexas, ele é uma ótima indicação para o desenvolvimento de aplicação que necessita de confiabilidade como o PROVEW. Além disso, o fato de ser um software Open Source de banco de dados mais utilizado no mundo, existe um grande suporte para auxiliar no desenvolvimento do sistema.

27 26 3. Segurança Com a crescente utilização da telefonia móvel entre as pessoas para a troca de informações, desde textos, imagem, som, torna-se necessária a utilização de mecanismos que possibilitem que o tráfego de informações nessa rede esteja protegido do ponto de vista da segurança. Neste capitulo é apresentada uma análise de métodos de segurança encontrados atualmente. A seguir veremos os principais requisitos para uma comunicação segura: 3.1 Requisitos para uma aplicação segura Para uma comunicação segura são necessários os seguintes requisitos [18]: Controle de acesso: Somente pessoas autorizadas protegem e acessam recursos. Autenticidade: Você sabe com quem está falando e que pode confiar nesta pessoa. Integridade de informações: As mensagens não são alteradas durante a transmissão. Sem integridade de informações, você não tem garantia que a mensagem enviada corresponde à mensagem recebida. Privacidade e confidencialidade: As informações transportadas de pessoa para pessoa durante uma transação permanecem privadas e confidenciais, mesmo que sejam entregues para a pessoa errada. 3.2 Criptografia Criptografia é a arte de codificar informação em um formato que apenas os destinatários apropriados possam acessá-las. Para isso, uma serie de técnicas são usadas e muitas outras surgem com o passar do tempo. Na computação as técnicas mais conhecidas envolvem o conceito de chaves, as chamadas chaves criptográficas. Trata-se de um parâmetro usado em um algoritmo de criptografia

28 27 de tal maneira que a criptografia não possa ser revertida sem o conhecimento da chave. [19] Chave Simétrica Apesar de os computadores terem mudado o campo da criptografia, seus princípios fundamentais permaneceram os mesmos; as mensagens eram codificadas com uma chave secreta ou compartilhadas e eram decodificadas com a mesma chave. Esse método, conhecido como criptografia tradicional, ou criptografia com chave simétrica, funciona bem em aplicações limitadas, como as militares, em que o emissor e o receptor podem se preparar antecipadamente para trocar a chave. Conforme ilustrado na Figura 7, o modelo de criptografia convencional envolve o compartilhamento da chave K entre as entidades comunicantes ( A e B ). Assim, quando a entidade A deseja enviar uma mensagem M confidencial para B, A deve primeiro gerar a chave K e depois passá-la de forma segura para B (canal seguro). Somente depois que ambas as entidades comunicantes A e B possuam a mesma chave criptográfica K é que a mensagem M pode ser enviada com sigilo [9]. Figura 7 - Modelo de Criptografia de Chave Simétrica. Fonte [20] Chave Assimétrica Criptografia assimétrica conhecida também por criptografia de chave pública utiliza duas chaves criptográficas por cada entidade, sendo uma para cifrar e outra para decifrar como ilustrado na Figura 8. Neste caso, a regra geral do modelo de criptografia de chave pública estabelece que, se uma mensagem M for cifrada

29 28 com uma chave, a única chave que permite restaurar a mensagem original é a chave parceira, ou seja, caso tenha cifrado uma mensagem M com a chave privada de uma entidade A, será necessário utilizar a chave pública da entidade A para restaurar a mensagem M, ou vice-versa. Assim, conforme mostra a Figura 8, cada entidade possui um par de chaves sendo uma a chave pública e a outra a chave privada. A chave pública pode ser de conhecimento de todos, enquanto que a chave privada deve ser mantida de forma secreta pela entidade [9]. Figura 8 - Modelo de Criptografia de Chave Pública. Fonte: [9] Assinatura Digital A Assinatura Digital nada mais é que a mensagem cifrada através da chave privada do assinante. O algoritmo de chave pública garante que se um determinado texto for cifrado com a chave privada somente poderá ser decifrada com a chave pública correspondente. Como a chave privada é mantida em segredo sendo somente conhecida pelo proprietário essas operações constituem uma assinatura digital, pois garante que ela fica atrelada ao texto e somente o possuidor da chave privada poderia efetuar aquela operação. Da mesma forma o processo de verificação passa por decifrar a mensagem utilizando a chave pública. Assim a pessoa que verifica pode ter certeza de que quem realmente gerou a assinatura foi a pessoa correta. O processo é muito simples e pode ser aplicado não somente a um texto, mas também a qualquer tipo de arquivo digital (imagem, som, etc.). [21]. 3.4 Certificado Digital 1 KPUB Chave Publica, KPRI Chave Privada.

30 29 Certificado Digital é um documento eletrônico que identifica pessoas e empresas no mundo digital, provando sua identidade e permitindo acessar serviços on-line com a garantia de autenticidade, integridade e não-repúdio. Atualmente os certificados digitais estão sendo utilizados principalmente na Internet para [22]: Acesso à Receita Federal para obtenção de certidões on-line e declarações seguras, como exemplo o imposto de renda de pessoa física; Transações bancárias com alto nível de segurança; Comércio Eletrônico com maior segurança para o cliente e para o comerciante; Correio Eletrônico Seguro garantindo a identidade e integridade do conteúdo; Assinaturas de documentos eletrônicos, cifrações de documentos eletrônicos, e outros. 3.5 Conexões Seguras O rápido crescimento de comércio eletrônico levou a um aumento na demanda de comunicações de rede seguras. Além disso, comunicações internas de empresas através de redes privadas geralmente contêm informações confidenciais que precisam de proteção. Para isso são apresentados alguns protocolos que asseguram tais conexões SSL O Secure Socket layer é um protocolo de comunicação que implementa um duto seguro para comunicação de aplicações na Internet, de forma transparente e independente da plataforma. Sua proposta é permitir a autenticação de servidores, encriptação de dados, integridade de mensagens e, como opção, a autenticação do cliente, operando nas comunicações entre aplicativos de forma interoperável [23].

31 30 O SSL irá garantir os seguintes objetivos: Segurança criptográfica para o estabelecimento de uma ligação segura entre duas máquinas/aplicativos, assegurando a privacidade na conexão, com a utilização de algoritmos simétricos (como o DES ou RC4) [9] que negociam uma chave secreta na primeira fase do handshaking (usando chaves públicas assimétricas); Autenticação do Servidor (e, opcionalmente do Cliente) por meio de algoritmos assimétricos; Confiabilidade na conexão, conseguida com o uso de Códigos de Autenticação de Mensagens. O SSL também permite a montagem de um framework onde outras chaves públicas e métodos de encriptação podem ser utilizados, evitando a necessidade de implementação de toda uma pilha de protocolos (com os riscos da introdução de fraquezas). Com uma vantagem adicional, a questão do desempenho foi levada em consideração no projeto, para reduzir o número de conexões e minimizar o tráfego na rede pode ser usado opcionalmente um esquema de cache em memória durante o estabelecimento da sessão, com a finalidade de reduzir o número de conexões e reduzir a atividade no acesso à rede. O SSL atua entre as camadas transporte (TCP) [12] e aplicação, sendo independente do protocolo de alto nível podendo rodar sob HTTP, Telnet, FTP, SMTP [12] e outras, de forma transparente. A Figura abaixo apresenta a relação do http com o SSL em suas respectivas camadas que por sua vez gera o protocolo https: Figura 9 Estrutura do https. Fonte: [9].

32 31 O SSL implementa duas novas camadas, sobre o TCP/IP, conforme o esquema e as descrições abaixo: Figura 10 Camadas adicionais do SSL. Fonte: [9]. SSL Handshake Protocol [24]: Faz a autenticação entre cliente e servidor, cuidando da inicialização da comunicação, permitindo a negociação do algoritmo de encriptação e as chaves criptográficas iniciais. Utiliza as chaves assimétricas para fazer a negociação inicial, abrindo um canal seguro para o envio da chave simétrica de sessão, criada de forma aleatória. Opera sobre o Record Layer [24]. Todas as mensagens da negociação utilizam o MAC e funções de hash (como SHA, MD5 e outras)[24] para aumentar a segurança do processo inicial. A ordem das mensagens é absoluta e seus conteúdos são manuseados pela Record Layer. Segue abaixo uma descrição simplificada desde protocolo:

33 32 Figura 11 SSL Handshake Protocol. Fonte: [24]. As mensagens Client Hello e Server Hello, estabelecem os seguintes atributos: Versão de protocolo, Identificação de Sessão. Cipher Suite e Método de Compressão. Adicionalmente, dois valores randômicos são gerados e intercambiados entre cliente e servidor. Ao estabelecer a conexão, o Handshake Protocol estabeleceu o identificador de sessão, o conjunto criptográfico (cypher suite) a ser adotado e o método de compressão a ser utilizado. O conjunto criptográfico negociado define três algoritmos: Um algoritmo para troca de chaves, um algoritmo para cifragem de dados e um algoritmo para inserção de redundância nas mensagens. Vantagens do uso do SSL [25]: Um dos protocolos mais convenientes e utilizados para implementação de transações seguras. A implementação é relativamente simples, colocando-se o SSL no topo da pilha TCP/Ip e substituindo as chamadas TCP pelas chamadas SSL;

34 33 Trabalha independente das aplicações utilizadas e, após o handshake inicial, comporta-se como um canal seguro que permite que se execute todas as funções que normalmente estão disponíveis no TCP/IP. Existem várias implementações gratuitas e comerciais, disponíveis para UNIX, Linux, Win 95/98/NT/2000 e outros; A maioria dos servidores e clientes (browsers) WEB já tem suporte nativo para ele, fazendo do SSL um padrão de fato; Disponibiliza todas as primitivas necessárias para conexões seguras, a saber: Autenticação, troca de chaves de sessão com o uso de criptografia assimétrica prévia, encriptação com métodos simétricos, MAC e certificação TLS O protocolo TLS (Transport Layer Security) é um protocolo de segurança de rede usado para criptografar e transmitir dados HTTP e IPP (Internet Printing Protocol) por uma rede TCP/IP. Ele é baseado e similar ao protocolo SSL, analisado acima. Embora algumas vezes o TLS seja comparado com o SSL, os dois protocolos são diferentes o bastante para impedir sua interoperabilidade. Como parte do processo de comunicação, o cliente da rede e o sistema de impressão (servidor) determinam o protocolo a ser usado (TLS ou SSL) para a comunicação e transferência de dados [7]. 3.6 Mecanismos de segurança em Java ME Sendo a plataforma Java ME dotada de poucas funcionalidades criptográficas é necessário recorrer a mecanismos adicionais para desempenhar este papel. Para o efeito, existem várias soluções possíveis cuja utilização se torna plausível. A seguir são listadas três possíveis soluções.

35 APIs do MIDP O MIDP está acompanhado (na versão 2.0 e 2.1) de uma interface Java para lidar com certificados digitais. Esta disponibiliza métodos que permitem obter os dados dos certificados, tais como a Autoridade de Certificação envolvida, a entidade a que o certificado está associado, o número de série, o algoritmo com o qual foi assinado, e a data de validade. Apesar de o MIDP permitir a utilização de comunicação segura, não oferece nenhuma função criptográfica que permita assegurar uma cifra de dados. Como tal, a sua utilização deve ser sempre feita em conjunto com outra (ou outras) das soluções apresentadas nas próximas sessões SATSA A SATSA (Security and Trusted Services API) [26] é um pacote opcional que estende as funcionalidades de segurança para a plataforma Java ME. Esta extensão adiciona APIs criptográficas, de serviços de assinaturas digitais e de gestão de certificados. A SATSA é composta por vários módulos opcionais, dispondo de dois deles para lidar com problemas de segurança Bouncy Castle (Light Edition) O Bouncy Castle Cryptography [27] é um pacote que oferece suporte para criptografia através do Java Cryptography Architecture (JCA) e do Java Cryptography Extension (JCE). O problema, naturalmente, é que o JCA e JCE são pacotes pesados para a plataforma MIDP. Existem vários outros pacotes de fonte aberta para o uso de criptografia em todo o mundo, mas especialmente Bouncy Castle oferece APIs compactadas voltadas para aparelhos com limitações de processamento e memória. Vantagens de se usar o pacote do Bouncy Castle [27]: Bouncy Castle dá suporte uma série de algoritmos criptográficos.

36 35 O Bouncy Castle está constantemente otimizando implementações existentes. É gratuito. No entanto, o modelo de desenvolvimento pontual também traz alguns problemas [27]: Há demasiados algoritmos e poucos desenvolvedores voluntários para otimizar tudo. O Bouncy Castle é flexível, mas bastante complexo, e novatos têm dificuldade em aprender. As fontes de pesquisas atualmente são poucas.

37 36 4. O Sistema PROVEW No nível técnico, a análise de software começa com uma série de tarefas de modelagem que levam a uma especificação completa dos requisitos e uma representação abrangente para o software a ser construído [28]. Neste capitulo apresentar-se-á todas estas tarefas de modelagem. Para isso, antes veremos de que forma que o sistema foi arquiteturado, para que depois sim, possamos aplicas todas estas modelagens. 4.1 Tecnologias Utilizadas O PROVEW foi implementado utilizando a linguagem de programação Java, especificamente à plataforma Java EE (Enterprise Edition) e Plataforma Java ME (Java Micro Edition) em conjunto com alguns frameworks gratuitos e de código aberto que auxiliarão no desenvolvimento do sistema Web. Além disso, um banco de dados relacional para persistência, por ainda ser considerada uma das melhores tecnologias para armazenamento de dados. O aplicativo foi desenvolvido baseado na arquitetura cliente/servidor, onde o cliente estabelece uma conexão através do protocolo HTTPS (http + ssl) fazendo o uso do GFC e então as requisições são enviadas para o servidor Tomcat onde se encontra um servlet que processa e trata toda a informação que em seguida atualiza o banco de dados. Depois de obtido o resultado, uma mensagem com resposta da requisição é devolvida para o módulo cliente da aplicação e então exibida na tela do emulador. No escopo da aplicação, o cliente é um aparelho celular com a característica MIDP 2.0, rodando o aplicativo desenvolvido na plataforma JME. Já o servidor é um PC com o Tomcat instalado rodando a aplicação JEE. Além destas características o PROVEW dispõe de uma interface Web feita em JSF para gerencia todo o conteúdo de vendas. Além destas tecnologias o sistemas também utiliza o RMS (Record Management System) para persistência de dados no

38 37 aplicativo móvel, O ireport e o JasperReports para criação de relatórios e o banco de dados My-SQL ambos no ambiente Web. 4.2 Descrição do Mini-Mundo O Sistema fornece um ambiente de vendas seguro que, a qualquer momento e em qualquer lugar (desde que haja sinal da operadora de telefonia móvel utilizada), um funcionário de uma empresa de defensivos agrícolas poderá realizar consultas e vendas. Este sistema poderá ser acessado por dois modos: VENDAS: As vendas serão realizadas de um dispositivo móvel, por um funcionário da empresa. CONTROLE: Os cadastros serão realizados via web, por um funcionário responsável. O PROVEW disponibilizará alguns cadastros fundamentais para o perfeito funcionamento do sistema, sendo estes realizados somente pela Web. São eles: Cadastro de Funcionário; Cadastro de Cliente; Cadastro de Produtos; Cadastro de Fornecedores; Todos os dados que se encontram nas transações realizadas no decorrer dos processos deverão possuir sigilo máximo, e todas as pessoas envolvidas no sistema deverão conter obrigatoriamente um login e uma senha. O sistema será responsável pela armazenagem e gerenciamento do estoque de produtos. Todo controle de estoque e feito via sistema, onde será atualizado todo produto que entra e sai do estoque sem interferência humana.

39 38 A uma venda serão associados um cliente, um vendedor e um pedido, sendo este composto por um ou mais produtos. O vendedor poderá acessar o sistema por um dispositivo móvel e para efetuar uma venda é obrigatório, inicialmente, verificar se a quantidade de produto está disponível no estoque, em seguida será pedido o cadastro do cliente, caso já possua este cadastro é necessário apenas informar os dados da venda (cliente, vendedor, produto, quantidade, forma de pagamento). Uma venda poderá estar em vários estados (cancelada, aguardando pagamento, concluída, em entrega). Estes estados poderão ser alterados bem como consultados por um funcionário ou pelo gerente, ambos logados no sistema de controle. Por fim, o PROVEW terá uma hierarquização para a permissão de acesso às aplicações. Por exemplo: o vendedor poderá somente efetuar vendas, e os funcionários terão acesso somente aos cadastros, exclusões, relatórios. 4.3 Arquitetura do Sistema Na Figura 12 é mostrado como fica a divisão por pacotes do sistema, visando o agrupamento de funcionalidades relativas a um mesmo escopo em um pacote. Móvel: este pacote engloba as funcionalidades relacionadas ao sistema móvel, abrangendo todo conteúdo para vendas. Web: engloba as funcionalidades relacionadas ao gerenciamento de vendas, abrangendo o cadastro das mesmas. Intermediário: engloba as funcionalidades de comunicação entre o sistema Web e o banco de dados. Por conter apenas um servlet implementando um protocolo de comunicação, para este pacote não será feito a diagramação da UML.

40 39 Figura 12 - Diagrama de Pacotes do Sistema PROVEW. 4.4 Modelo de Casos de Uso O diagrama de Caso de Uso é um diagrama da UML (Unified Modeling Language) cujo objetivo é representar o requisito do sistema que será automatizado definindo todo seu contexto [28]. Visando este objetivo serão apresentados os diagramas referentes ao sistema desenvolvido. O PROVEW será operado conforme o tipo de usuário. Esses usuários são divididos nas seguintes categorias: funcionário, vendedor. Figura 13 Atores do Sistema PROVEW Os atores estão dispostos segundo as seguintes funcionalidades: Funcionário: Pessoa responsável pelo cadastro de produtos, cadastro de vendedores e todo o gerenciamento da venda e da entrega. Vendedor: Pessoa responsável pelas funções de orçamento e venda.

41 Pacote Web A figura a seguir mostra o diagrama de caso de uso referente ao pacote Web. Na seqüência, os casos de usos identificados são descritos resumidamente uma vez que no documento em anexo encontra-se toda a documentação destes. Figura 14. Diagrama de Casos de Uso do pacote Web. A seguir será apresentada uma breve descrição de cada caso de uso apresentado: Cadastrar Produto: Caso de uso responsável pelo cadastro de produto bem como alteração, exclusão e consulta. De um produto deseja-se saber (Nome, preço, quantidade em estoque, descrição, quantidade, medida, fabricante)

42 41 Cadastrar Vendedor: Caso de uso responsável pelo cadastro de vendedores bem como alteração exclusão e consulta. De um vendedor deseja-se saber (Nome, RG, CPF, Endereço, UF, telefone, área de venda, vendas realizadas, login, senha). Cadastrar Funcionário: Caso de uso responsável pelo cadastro de funcionários bem como alteração exclusão e consulta. De um vendedor deseja-se saber (Nome, RG, CPF, Endereço, telefone, login, senha). Cadastrar Cliente: Caso de uso responsável pelo cadastro de clientes bem como alteração exclusão e consulta. De um cliente deseja-se saber (Nome, RG, CPF, Endereço, telefone, ). Cadastrar Fornecedor: Caso de uso responsável pelo cadastro de fornecedores bem como alteração exclusão e consulta. De um fornecedor deseja-se saber (Razão Social, CNPJ, Endereço, telefone). Emitir relatório de vendas: Caso de uso responsável por gerar um relatório contendo os dados de todas as vendas realizadas em uma data ou em um intervalo entre datas. Emitir relatórios de Entregas: Caso de uso responsável por gerar um relatório contendo os dados produtos a serem entregues e seus respectivos endereços. Alterar estado da entrega: Caso de uso responsável pela alteração do estado de uma entrega (cancelada, aguardando pagamento, concluída, em entrega). Autenticar usuário: Caso de uso responsável pela validação de login e senha do usuário.

43 Pacote Móvel A figura a seguir mostra o diagrama de caso de uso referente ao pacote móvel. Na seqüência, os casos de usos identificados são descritos resumidamente uma vez que no documento em anexo encontra-se toda a documentação destes. Figura 15. Diagrama de Casos de Uso do pacote Móvel. A seguir será apresentada uma breve descrição de cada caso de uso apresentado: Efetuar Venda: Caso de uso responsável pela ação de vender. De uma venda deseja-se saber (cliente, vendedor, produtos, quantidade, forma de pagamento) Consultar Produtos ou Clientes: Caso de uso responsável pela consulta por nome do produto ou nome do cliente. De uma consulta pretende-se obter como resposta todos os dados referente a opção escolhida. Importar Produtos ou Clientes: Este caso de uso é responsável por buscar todos os dados dos clientes ou dos produtos e armazena-los no dispositivo.

44 43 Autenticar usuário: Caso de uso responsável pela validação de login e senha do usuário. 4.5 Projeto do Sistema O projeto é uma atividade que leva a um produto de alta qualidade. As características mais relevantes em termos de qualidade de uma WebApp são: usabilidade, funcionalidade, confiabilidade, eficiência e manutenibilidade. Ainda são adicionados outros cinco principais atributos de qualidade: segurança, disponibilidade, escalabilidade e prazo de colocação no mercado. O documento de projeto, que se encontra na documentação do sistema, em anexo, especifica a arquitetura utilizada, descrevendo a plataforma de implementação. Uma arquitetura de camadas básica foi definida conforme a Figura 16. Figura 16 - Estrutura de Camada

45 44 A seguir serão apresentados três modelos que foram desenvolvidos no projeto do sistema: O Modelo Conceitual, o Modelo de Persistência, o Modelo de Navegação Modelo Conceitual O modelo conceitual é um diagrama de classes da UML que representa os objetos de domínio do problema e seu mapeamento para a persistência em banco de dados relacional [28]. A partir dele serão implementadas as classes da camada de domínio na atividade de implementação. A seguir é apresentado o modelo conceitual para o sistema PROVEW, para ambos os pacotes que por sinal possuem a mesma estrutura de classe. Figura 17 Modelo Conceitual do sistema PROVEW

46 Modelo de Persistência Conceitos do padrão de projeto DAO (Data Access Object) [30] foram usados para criar a camada entre o domínio e a tecnologia de persistência. O modelo de persistência é um diagrama de classes da UML que apresenta as classes DAO que compõem a camada de persistência de um determinado pacote do sistema [28]. Para cada classe de domínio que precisa de lógica de persistência, o diagrama apresenta uma classe DAO. Existe também uma classe base que contém os métodos básicos, que definem a conexão. As classes específicas devem mostrar no diagrama os métodos específicos de persistência das classes que elas representam. Em geral, tais métodos são referentes às consultas específicas que devem ser feitas ao banco de dados, por exemplo recuperar objeto por nome. A seguir é apresentado o modelo de persistência para o pacote Web.

47 46 Figura 18 Modelo de Persistência do sistema PROVEW (WEB) Modelo de Navegação O modelo de navegação é um diagrama de classes da UML que espelha os diferentes elementos que interagem nas camadas de visão e controle e são específicos para a plataforma Web. Os elementos podem ser: Classes de Ação, Páginas Web, Modelos de Página e Formulário Web [28]. Para desenvolvimento do projeto móvel e do projeto web foi feito antes um diagrama de navegação este realizado na ferramenta NetBeans IDE 6.1 [32]. O diagrama de navegação do projeto Web é mostrado na figura a seguir. Figura 19 Modelo de navegação do pacote WEB

48 47 O diagrama de navegação do projeto móvel é mostrado na figura a seguir. Figura 20 Modelo de navegação do pacote móvel.

49 Implementação e Testes Para implementação do sistema foram utilizadas as ferramentas: Wireless Toolkit 2.5.1[31] e o Netbeans IDE 6.1 [32], utilizando como servidor o Apache Tomcat 6.0 [33]. Através do modelo conceitual foram definidas as tabelas do banco de dados e seus relacionamentos. De posse disso foi feito um script para criar banco de dados do sistema no MySQL. Pelo diagrama de pacotes definido no projeto do sistema, as classes foram sendo implementadas. Primeiro as classes de domínio, ou seja, as classes definidas na análise do projeto. Posteriormente foram feitos seus mapeamentos no banco e implementadas suas classes DAO. A partir daí os casos de uso foram implementados incluídos no pacote de controle. Finalmente as páginas JSP e JSF foram geradas. O projeto móvel foi o último a ser implementado. Ele consiste apenas da camada de apresentação que agora é a de um dispositivo portátil. Com o projeto implementado foram feitos testes de integração sobre os casos de uso. Durante a implementação foram feitos alguns casos isolados de teste de unidade sobre classes de maior complexidade.

50 49 5. Considerações finais O presente trabalho foi realizado com o intuito de propor uma solução para o problema encontrado pelas empresas de defensivos agrícolas. Foi proposto um sistema em que os vendedores pudessem realizar vendas seguras acessando dados atualizados instantaneamente. Com isso as empresas têm a possibilidade de melhorar a qualidade do serviço, diminuir a margem de erro e aumentar integridade dos dados envolvidos. Para atender aos requisitos proposto pelo sistema foram observadas algumas experiências interessantes como à utilização de frameworks muito poderosos e o contato com aplicação para dispositivos móveis, além de utilização de padrões de projetos. Com a intenção de aumentar a qualidade do software e de aproveitar a oportunidade de colocarmos em prática algum conhecimento em determinadas tecnologias, adotamos o framework GFC (Generic Connection Framework) que pode ser utilizada para facilitar a conexão entre as plataformas JME e JEE. A adoção desse framework nos trouxe uma complexidade muito grande, pois necessitamos adquirir o conhecimento de sua API e também adquirir conhecimento de protocolos de segurança em redes. Outro fator que contribuiu para nossa dificuldade no desenvolvimento do projeto foi a disponibilidade de um ambiente móvel para os usuários. Por se tratar de uma tecnologia pouco utilizada por nós, encontramos barreiras que levamos tempo considerável para vencer. Em contrapartida, a adoção da modelagem realizada foi um dos pontos fortes para o sucesso do sistema, pois agilizou as demais fases do sistema. O padrão de desenvolvimento utilizado foi muito interessante, pois com algumas poucas modificações podemos migrar o sistema de uma plataforma web para uma plataforma desktop e, da mesma forma, a reutilização dos componentes das camadas de aplicação, persistência e parte das camadas de controle foi um facilitador para a adaptação ao ambiente móvel.

51 50 No sistema web ainda há espaço para melhorias significativas. Como trabalhos futuros, podemos citar a implementação de relatórios mais complexos e restrições de acesso e partes do sistema.

52 51 REFERÊNCIAS [1] COSTA, Luis Carlos Moreira. Java Avançado. Rio de Janeiro - RJ. Edição 01, Editora Moderna, [2] Plataforma Java Standard Edition - Acessado em: 24/03/08 [3] Plataforma Java Micro Edition - Acessado em: 24/10/08 [4] Plataforma Java Enterprise Edition- Acessado em: 24/03/08 [5] TITTLEL. São Paulo: Ed. XML. Bookman, [6] Deitel, Java Como programar, 6ª Edição, Pearson Prentice Hall, 2005 [7] PERRONE, KRISHNA, Paul e Venkata, Building Java Enterprise Systems with J2EE Edição 01, Sams Publishing. [8] JAMES WHITE, DAVID HEMPHILL, Java 2 Micro Edition Java in Small Things 2002 by Manning Publications. [9] MIRANDA, Cláudio. Dados em J2ME. Curitiba PR. Java Magazine. Edição 03, editora Neofício [10] MUCHOW, John W. Core J2ME Tecnologia & MIDP. São Paulo SP. Editora Makron Books, [11] Sun - Acessado em: 24/03/08 [12] TANENBAUM, Tanenbaum, Andrew S. Redes de Computadores Tradução da 4ª Edição, Ed. Campus, [13] KNUDSEN, Jonathan.Wireless Java Developing with J2ME, Edição 02, [14] A ferramenta irepot for JasperReports -

53 52 [15] ireport User Manual, Giulio Toffoli, 2005 [16] Banco de dados MySQL [17] Banco de dados PostgreSQL - [18] KNUDSEN, Jonathan.Wireless Java Developing with J2ME, Edição 02, [19] COULORIS, George, Sistemas Distribuidos: Conceito e Projeto Edição 04 Porto Alegre: Bookman, [20] GUELFI, Adilson Eduardo, Criptografia. São Paulo, [21] BERNSTEIN, Bhimani, Schultz e Siegel.: Segurança na Internet. Ed.Campus [22] REZENDE, Pedro Antonio. Certificados Digitais, Chaves e Assinatura [23] Netscape - Transport Layer Security Working Group - INTERNET-DRAFT, The SSL Protocol Version 3.0, Acessado em: 01 de fevereiro de [24] Araújo, Gorgonio Transações Seguras Via WEB, Acessado em: 01 de fevereiro de [25] Rezende, Pedro A. D. Material de Estudo do Curso de Criptografia e Segurança Computacional e Página de Tópicos em Segurança Computacional / Publicações Acessado em: 01 de fevereiro de [26] ORTIZ, Enrique, The Security and Trusted Services API for J2ME. Sun Microsystems, March Acessado em: 24 de outubro de

54 53 [27] The Legion of the Bouncy Castle. Acessado em: 24 de outubro de [28] Pressman, R. S., Software Engineering A practitioner s Approach 6th Edition, 2005 [29] Ambler, S., What Is Agile Modeling (AM)?, Acessado em: 02 de maio de [30] Core J2EE Patterns Padrão DAO - html [31] Sun Java Wireless Toolkit - Acessado em: 08 de maio de [32] Netbeans - Acessado em: 08 de maio de [33] Projeto Jakarta da Apache Acessado em: 08 de maio de 2008.

55 54 CENTRO UNIVERSITARIO DE VILA VELHA CURSO DE CIÊNCIA DA COMPUTAÇÃO PROVEW - PROGRAMA DE VENDAS COM CONEXÃO WIRELESS DESTINADO ÀS EMPRESAS DE DEFENSIVOS AGRÍCOLAS ANEXO DOCUMENTAÇÃO VILA VELHA 2008

56 55 1. Documento de Especificação de Requisitos 1.1 Diagramas de pacotes Na Figura a seguir é mostrado como fica a divisão por pacotes do sistema, visando o agrupamento de funcionalidades relativas a um mesmo escopo em um pacote. Móvel: este pacote engloba as funcionalidades relacionadas ao sistema móvel, abrangendo o que o conteúdo para vendas. Web: engloba as funcionalidades relacionadas ao gerenciamento de vendas, abrangendo o cadastro das mesmas. Intermediário: engloba as funcionalidades de comunicação entre o sistema Web e o banco de dados, por conter apenas um servlet implementando um protocolo de comunicação, este pacote não será feito a diagramação da UML.

57 Modelo de Casos de Uso O PROVEW será operado conforme o tipo de usuário. Esses usuários são divididos nas seguintes categorias: funcionário, vendedor. Os atores estão dispostos segundo as seguintes funcionalidades: Funcionário: Pessoa responsável pelo cadastro de produtos, cadastro de vendedores e todo o gerenciamento da venda e da entrega. Vendedor: Pessoa responsável pelas funções de orçamento e venda Pacote Web A figura a seguir mostra o diagrama de caso de uso referente ao pacote Web. Na seqüência, os casos de usos identificados são descritos.

58 57

59 58 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Web Nome do Caso de Uso: Autenticar Usuário Analista: Igor Tomaz Gravel e Cristiano Andreao Fioresi Data: 19/04/2008 Descrição: Este caso de uso é responsável pela autenticação do usuário no PROVEW, abrangendo a efetuação de login. Curso Normal: Efetuar Login O usuário padrão informa seu login e sua senha. Verifica-se se o login existe. Caso exista, verifica-se se a senha corresponde ao login informado. Caso corresponda, o login é efetuado e o sistema disponibilizará as funcionalidades que o funcionario tem direito de acesso. Cursos Alternativos: Efetuar Login Caso o login não exista no sistema ou a senha não corresponda ao login informado, uma mensagem de erro é exibida. Enviar Senha Caso o login não exista, uma mensagem de erro é exibida.

60 59 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Web Nome do Caso de Uso: Cadastrar Produto Analista: Igor Tomaz Gravel e Cristiano Fioresi Andreao Data: 15/04/2008 Descrição: Este caso de uso é responsável pelo cadastro de Produto, abrangendo a criação de um novo Produto pelo Funcionário, podendo criar, consultar, alterar e excluir. Caso Uso Criar Alterar Consultar Excluir Observações Cadastrar X Informar: Produto Nome*; Fornecedor*; Preço de Custo*; Preço de Venda*; Descrição; Margem de Lucro; Medida; Estoque; *Campos Obrigatórios X X X

61 60 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Web Nome do Caso de Uso: Cadastrar Vendedor Analista: Igor Tomaz Gravel e Cristiano Fioresi Andreao Data: 15/04/2008 Descrição: Este caso de uso é responsável pelo cadastro de vendedores, abrangendo a criação de um novo membro pelo Funcionário, podendo criar, consultar, alterar e excluir de vendedores existentes. Caso Uso Criar Alterar Consultar Excluir Observações Cadastrar X Informar: Vendedor Nome* Telefone*; RG*; CPF; Sexo; Data de Nascimento; Salário*; ; Cidade; UF; Rua; Numero; Bairro; CEP; *Campos Obrigatórios X X X

62 61 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Web Nome do Caso de Uso: Cadastrar Funcionário Analista: Igor Tomaz Gravel e Cristiano Fioresi Andreao Data: 15/04/2008 Descrição: Este caso de uso é responsável pelo cadastro de Funcionários, abrangendo a criação de um novo membro por um outro funcionário, podendo criar, consultar, alterar e excluir dados existentes. Caso Uso Criar Alterar Consultar Excluir Observações Cadastrar X Informar: Funcionários Nome* Telefone*; RG*; CPF; Sexo; Cargo; Data de Nascimento; Salário*; ; Cidade; UF; Rua; Numero; Bairro; CEP; *Campos Obrigatórios X X X

63 62 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Web Nome do Caso de Uso: Cadastrar Cliente Analista: Igor Tomaz Gravel e Cristiano Fioresi Andreao Data: 15/04/2008 Descrição: Este caso de uso é responsável pelo cadastro de clientes, abrangendo a criação de um novo membro pelo Funcionário, podendo criar, consultar, alterar e excluir de clientes existentes. Caso Uso Criar Alterar Consultar Excluir Observações Cadastrar X Informar Cliente Nome* RG* CPF* Sexo* Telefone Data de Nascimento Tipo de Cliente. X X X *Campos Obrigatório

64 63 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Web Nome do Caso de Uso: Cadastrar Fornecedor Analista: Igor Tomaz Gravel e Cristiano Fioresi Andreao Data: 15/04/2008 Descrição: Este caso de uso é responsável pelo cadastro de Fornecedores, abrangendo a criação de um novo membro pelo Funcionário, podendo criar, consultar, alterar e excluir de clientes existentes. Caso Uso Criar Alterar Consultar Excluir Observações Cadastrar X Informar Fornecedor Razão Social*, CNPJ* Observação Telefone . X X X *Campos Obrigatório

65 64 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Web Nome do Caso de Uso: Alterar Estados de Entregas Analista: Igor Tomaz Gravel e Cristiano Fioresi Andreao Data: 15/04/2008 Descrição: Este Caso de uso é responsável pela modificação do estado da entrega. Curso Normal: Consulta de Registro O Funcionário seleciona a venda desejada através de seu código, em seguida todos os dados da venda são lhe apresentados. A partir daí através de um combobox, o funcionário poderá selecionar o novo estado para aquela venda.

66 65 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Web Nome do Caso de Uso: Gerar Relatórios de Vendas Analista: Igor Tomaz Gravel e Cristiano Fioresi Andreao Data: 15/04/2008 Descrição: Este Caso de uso é responsável pelo acompanhamento das Vendas através de relatórios. Curso Normal: Gerar Relatório O funcionário pode gerar relatórios sobre suas vendas. Ao fazer a requisição, será apresentada uma tabela contendo todos os dados de uma venda, desde o ato da venda ate a entrega.

67 66 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Web Nome do Caso de Uso: Gerar Relatórios de Entrega Analista: Igor Tomaz Gravel e Cristiano Fioresi Andreao Data: 15/04/2008 Descrição: Este Caso de uso é responsável pelo acompanhamento das entregas através de relatórios. Curso Normal: Gerar Relatório O funcionário pode gerar relatórios sobre suas entregas, ao fazer a requisição, será apresentada uma tabela contendo todos os dados de entregas por estados de entrega.

68 Pacote Móvel A figura a seguir mostra o diagrama de caso de uso referente ao pacote Móvel. Na seqüência, os casos de usos identificados são descritos.

69 68 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Móvel Nome do Caso de Uso: Autenticar Usuário Analista: Igor Tomaz Gravel e Cristiano Fioresi Andreao Data: 19/04/2008 Descrição: Este caso de uso é responsável pela autenticação do usuário no PROVEW, abrangendo a efetuação de login. Curso Normal: Efetuar Login O usuário padrão informa seu login e sua senha. Verifica-se se o login existe. Caso exista, verifica-se se a senha corresponde ao login informado. Caso corresponda, o login é efetuado e o sistema disponibilizará as funcionalidades que o vendedor tem direito de acesso. Cursos Alternativos: Efetuar Login Caso o login não exista no sistema ou a senha não corresponda ao login informado, uma mensagem de erro é exibida. Enviar Senha Caso o login não exista, uma mensagem de erro é exibida.

70 69 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Móvel Nome do Caso de Uso: Efetuar Venda Analista: Igor Tomaz Gravel e Cristiano Andreao Fioresi Data: 19/04/2008 Descrição: Este caso de uso é responsável para efetuar uma venda através do dispositivo móvel. Curso Normal: Efetuar Venda O vendedor informa os códigos (Vendedor, Cliente), depois seleciona a forma de pagamento, a seguir ele adiciona os produtos desejados para efetuar uma venda. Cursos Alternativos: Efetuar Venda Caso não exista produto em estoque o sistema, uma mensagem de erro será exibida.

71 70 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Móvel Nome do Caso de Uso: Importar cadastros. Analista: Igor Tomaz Gravel e Cristiano Fioresi Andreao Data: 19/04/2008 Descrição: Este caso de uso é responsável por buscar dados de cliente ou produto. Curso Normal: Importar Cadastros O vendedor seleciona a opção entre (Cliente ou Produto) em seguida é exibido uma lista contendo todos os registros existentes referente à opção escolhida.

72 71 DESCRIÇÃO DE CASO DE USO Projeto: PROVEW Programa de Vendas Com Conexão Wireless Sub-Sistema: Móvel Nome do Caso de Uso: Efetuar Pesquisa. Analista: Igor Tomaz Gravel e Cristiano Fioresi Andreao Data: 19/04/2008 Descrição: Este caso de uso é responsável por pesquisar dados de cliente ou produto. Curso Normal: Importar Cadastros O vendedor seleciona a opção entre (Cliente ou Produto) em seguida é exibido um campo onde ele digitará as iniciais para realizar um filtro que retornará os dados referentes à opção selecionada anteriormente.

73 72 2. Documento de Especificação do Projeto Projeto: PROVEW Programa de Vendas Com Conexão Wireless Data: 19/04/2008 Analistas: Igor Tomaz Gravel, Cristiano Fioresi Andreao 2.1 Introdução Este documento contém a especificação do projeto PROVEW Programa de Vendas Com Conexão Wireless, onde será apresentada a especificação da arquitetura, modelo de persistência e o modelo de navegação. 2.2 Especificação da arquitetura O PROVEW foi implementado utilizando a linguagem de programação Java, especificamente à plataforma Java EE (Enterprise Edition) e Plataforma Java ME (Java Micro Edition) em conjunto com alguns frameworks gratuitos e de código aberto que auxiliarão no desenvolvimento do sistema Web. Além disso, foi um banco de dados relacional para persistência, por ainda ser considerada uma das melhores tecnologias para armazenamento de dados. O aplicativo foi desenvolvido baseado na arquitetura cliente/servidor, onde o cliente estabelece uma conexão através do protocolo HTTPS (http + ssl) fazendo o uso do GFC e então as requisições são enviadas para o servidor Tomcat onde se encontra um servlet que processa e trata toda a informação que em seguida atualiza o banco de dados. Depois de obtido o resultado, uma mensagem com resposta da requisição é devolvida para o módulo cliente da aplicação e então exibida na tela do emulador.

74 73 No escopo da aplicação, o cliente é um aparelho celular com a característica MIDP 2.0, rodando o aplicativo desenvolvido na plataforma JME. Já o servidor é um PC com o Tomcat instalado rodando a aplicação JEE. Alem destas características o PROVEW dispõe de uma interface Web feita em JSF para gerencia todo o conteúdo de vendas. Alem destas tecnologias o sistemas também utiliza o RMS (Record Management System) para persistência de dados no aplicativo móvel, O ireport e o JasperReports para criação de relatórios e o banco de dados My-SQL ambos no ambiente WEB. Uma arquitetura de camadas básica para o sistema web foi definida conforme a figura a seguir: O figura a seguir mostra a divisão do sistema web em módulos (pacotes Java). A divisão foi feita, primeiramente, com relação à divisão em subsistemas da Especificação de Requisitos e à divisão em pacotes da Especificação de Análise. As seções a seguir descrevem classes que pertencem às camadas de modelo, persistência, controle e visão.

75 Modelo No pacote modelo encontra-se todas as classes de objetos com seus respectivos construtores, métodos e atributos. A figura a seguir mostra as classes que incorporam o pacote de Modelo.