PESQUISA E DESENVOLVIMENTO PARA DISPOSITIVOS MÓVEIS

Transcrição

1 CENTRO UNIVERSITÁRIO VILA VELHA CURSO DE CIÊNCIA DA COMPUTAÇÃO IGOR DA COSTA ROCHA ELIAS JURANDIR LUCHINI VICTOR MARCOS ANTONIO RAMPINELLI PESQUISA E DESENVOLVIMENTO PARA DISPOSITIVOS MÓVEIS VILA VELHA 2009

2 IGOR DA COSTA ROCHA ELIAS JURANDIR LUCHINI VICTOR MARCOS ANTONIO RAMPINELLI PESQUISA E DESENVOLVIMENTO PARA DISPOSITIVOS MÓVEIS Trabalho de Conclusão de Curso apresentado ao Centro Univertário Vila Velha como requisito parcial para a obtenção do grau de Bacharel em Ciência da Computação. Orientador: Cristiano Biancardi VILA VELHA 2009

3 IGOR DA COSTA ROCHA ELIAS JURANDIR LUCHINI VICTOR MARCOS ANTONIO RAMPINELLI PESQUISA E DESENVOLVIMENTO PARA DISPOSITIVOS MÓVEIS BANCA EXAMINADORA Prof. Msc. Cristiano Biancardi Centro Universitário Vila Velha Orientador Prof. Msc. Renato Elias N. de Moraes Centro Universitário Vila Velha Prof. Msc. Sandro Tonini da Silva Centro Universitário Vila Velha Trabalho de Conclusão de Curso aprovado em 04/06/2009.

4 Aos nossos pais e amigos...

5 AGRADECIMENTOS Agradecemos a Deus, nossas famílias, familiares, namoradas, amigos, colegas, o orientador e a banca examinadora.

6 Uma das causas do fracasso na vida é deixar para amanhã o que se pode fazer hoje, e depois fazê-lo apressadamente. Provérbio Chinês

7 LISTA DE TABELAS 1 Comparação WAP x JME Tecnologias Requisitos para o módulo Web Requisitos para módulo Móvel Cores Mensagens do Sistema Eficiência dos Casos de Uso do Pacote Cliente Eficiência dos Casos de Uso do Pacote Clinica

8 LISTA DE FIGURAS 1 Comparação entre o número de celulares e computadores no mundo Projeções para a internet móvel no mundo Comparação entre WAP e Internet quando usado para acessar a Web Cliente WAP Uso do Gateway WAP Gateway WAP e elementos da rede sem fio Gateway do proxy WAP Codificador / Decodificador do Gateway WAP Pilha de Protocolos WAP Plataforma Java e suas edições JME e seus componentes JME dividida em camadas Configurações do JME Relacionamento entre as diferentes implementações do GCF Diagrama de Pacotes Diagrama de Caso de Uso do Pacote Cliente Diagrama de Caso de Uso do Pacote Clínica Diagrama de Classes do Pacote Cliente Diagrama de Classes do Pacote Clínica Diagrama de Estados da Classe Cheque Diagrama de Estados da Classe Parcela Diagrama de Estados da Classe Consulta

9 23 Diagrama de Seqüência do Caso de Uso Visualizar Consulta Diagrama de Seqüência do Caso de Uso Sugerir Consulta Diagrama de Seqüência do Caso de Uso Visualizar Correio Diagrama de Seqüência do Caso de Uso Visualizar Agenda Diagrama de Seqüência do Caso de Uso Agendar Consulta Diagrama de Seqüência do Caso de Uso Emitir Relatório de Consultas Comunicação entre as páginas Web e o servidor Arquitetura do Sistema Arquitetura em Camadas do Pacote Cliente Arquitetura em Camadas do Pacote Clinica Diagrama de Classes do Pacote DP_Cliente Diagrama de Classes do Pacote DP_Clínica Modelo baseado na escolha do endereço Modelo baseado na escolha do endereço e CEP Modelo baseado na escolha do CEP Permissão de acesso Classe responsável pela auditoria Classe Tabela Diagrama de Classe do Pacote GT_Cliente Diagrama de Classe do Pacote GT_Clinica Exemplo de diagrama sem o uso do padrão Facade Exemplo de diagrama usando o padrão Facade Diagrama de Classe do Pacote GT_Cliente reformulado Diagrama de Classe do Pacote GT_Clinica reformulado Diagrama de Classe do Pacote GD_Cliente Diagrama de Classe do Pacote GD_Clínica

10 49 Diagrama de Classe do Pacote GD_Cliente reformulado Diagrama de Classe do Pacote GD_Clínica reformulado Modelo de Entidade e Relacionamento (MER): Parte A Modelo de Entidade e Relacionamento (MER): Parte B Diagrama de Classe do Pacote IU_Cliente Diagrama de Classe do Pacote IU_Clínica Diagrama de Classe do Pacote Banco Diagrama de Classe do Pacote Login Diagrama de Classe do Pacote Pessoa Pacote Utilitário DAO Diagrama de Seqüência do Caso de Uso Visualizar Consulta Diagrama de Seqüência do Caso de Uso Sugerir Consulta Diagrama de Seqüência do Caso de Uso Visualizar Correio Diagrama de Seqüência do Caso de Uso Visualizar Agenda Diagrama de Seqüência do Caso de Uso Agendar Consulta Diagrama de Seqüência do Caso de Uso Emitir Relatório de Consultas Ícones Diagrama de Navegabilidade do Pacote Cliente Diagrama de Navegabilidade do Pacote Clínica Diagrama de Componentes do Sistema MobOdonto Diagrama de Implantação do Sistema MobOdonto Funcionalidade Login Funcionalidade Visualizar Correio Funcionalidade Visualizar Consultas Funcionalidade Sugerir Consultas: Escolha do dia da semana Funcionalidade Sugerir Consultas: Escolha do horário disponível

11 75 Tela principal Tela principal para seleção da funcionalidade Funcionalidade Visualizar Consultas: Escolha do horário Funcionalidade Visualizar Consultas: Visualizando dados do cliente Funcionalidade Login Funcionalidade Visualizar Consultas Componente Wrapper Estrutura do Sistema

12 LISTA DE SIGLAS 3G AJAX AMA API ASP CDC CDMA CLDC CSS CVM FP GCF GUI HDML HTML http HTTPS IDE IMP IP JCP JEE JME JSE JSP JSR JVM KVM LWUIT Terceira Geração Asynchronous JavaScript And XML All Mobile Alliance Application Programming Interface Active Server Pages Connected Device Configuration Code Division Multiple Access Connected Limited Device Configuration Cascading Style Sheets Compact Virtual Machine Foundation Profile Generic Connection Framework Graphical User Interface Handheld Device Markup Language Hypertext Markup Language Hypertext Transfer Protocol Hypertext Transfer Protocol Secure Integrated Development Environment Information Mobile Profile Internet Protocol Java Community Process Java Enterprise Edition Java Micro Edition Java Standard Edition Java Server Pages Java Specification Request Java Virtual Machine Kilobyte Virtual Machine Lightweight User Interface Toolkit

13 MIDP PBP PDA PNG PP SATSA SDK SGBD SMS TCP TIC UML USSD VM WAE WAP WBMP WCSS WDP WML WSP WTA WTLS XHTML-MP XML Mobile Information Device Profile Personal Basis Profile Personal Digital Assistants Portable Network Graphics Personal Profile Security And Trust Services API Software Development Kit Sistema Gerenciador de Banco de Dados Short Message Service Transmission Control Protocol Tecnologias de Informação e Comunicação Unified Modeling Language Unstructured Supplementary Service Virtual Machine Wireless Application Environment Wireless Application Protocol Wireless Bitmap Wireless Cascade Style Sheet Wireless Datagram Protocol Wireless Markup Language Wireless Session Layer Wireless Telephony Application Wireless Transport Layer Security extensible Hypertext Markup Language extensible Markup Language

14 SUMÁRIO RESUMO ABSTRACT 1 INTRODUÇÃO 19 2 JUSTIFICATIVA Motivações OBJETIVOS 24 4 TECNOLOGIAS WAP Histórico Arquitetura de Aplicativo WAP Cliente WAP Gateway WAP Funcionamento do Gateway WAP Servidor de Aplicativos WAP Pilha de Protocolos WAP Wireless Application Environment - WAE Wireless Session Layer - WSP Wireless Transaction Layer - WTP Wireless Transport Layer Security - WTLS

15 Wireless Application Environment - WAE Wireless Datagram Protocol Linguagem e Plataforma Java Plataforma JME Java Community Process (JCP) e Java Specification Request (JSR) Configurações CLDC (Connected Limited Device Configuration) CDC (Connected Device Configuration) Perfis WAP x JME Ambientes de Desenvolvimento Conectividade Segurança de Informação Acesso a Serviço Local do Dispositivo Disponibilidade em Dispositivo Móvel Frameworks Persistência de Dados Interface com Usuário Comparação entre JME e WAP ESTUDO DE CASO: SISTEMA MOBODONTO Modelo de Desenvolvimento Especificação de Requisitos Descrição do Mini-Mundo Modelo de Casos de Uso Diagramas de Casos de Uso

16 6.2.4 Descrição dos Casos de Uso Visualizar Consultas Sugerir Consultas Visualizar Correio Agendar Consulta Visualizar Agenda Emitir Relatório de Consultas Especificação de Análise Diagrama de Classes Diagrama de Estados Diagrama de Seqüência Especificação de Projeto Tipo de Aplicação, Plataformas de Implementação, Tecnologias de Apoio e Hardware Framework Ajax SSL e Certificado Digital Arquitetura do Sistema Arquitetura em Camadas Domínio do Problema (DP) Considerações Gerência de Tarefas (GT) Padrão de Projeto Facade Gerência de Dados (GD) Padrão de Projeto Singleton Modelo de Entidade e Relacionamento (MER) Interface com Usuário (IU)

17 6.4.4 Pacote Utilitários Banco Login Pessoa DAO Diagrama de Seqüência Padrões de Interface Ícones Cores Mensagens Diagrama de Navegabilidade Aspectos de Usabilidade e Eficiência Diagrama de Componentes Diagrama de Implantação Protótipo Estrutura de Sistema CONCLUSÃO Conclusão dos Objetivos Dificuldades Encontradas Retorno Para o Grupo Trabalhos Futuros REFERÊNCIAS 99

18 RESUMO Nos últimos anos, a tendência no sentido de dispositivos menores e mais rápidos, juntamente com a necessidade de acesso à informação em movimento, tem moldado o caminho para uma nova tecnologia que reúne o mundo da Web e da telefonia móvel. Essa tendência na tecnologia é fornecer aos usuários a capacidade de terem tudo que possivelmente precisariam em um dispositivo que caiba no bolso. Neste contexto, é proposto um sistema para auxílio dos controles administrativos em um consultório ortodôntico. Para tal, foram pesquisados e encontrados os melhores métodos e tecnologias para o desenvolvimento deste sistema que suportará o acesso pela Web convencional e por dispositivos móveis. Palavras-chave: Wireless, WAP (Wireless Application Protocol), JME (Java Micro Edition).

19 ABSTRACT In recent years, the appearing of smaller and faster devices with the need to access information everywhere has shaping a new technology that combines the Web and the mobile technology. The new trend is to provide users the possibility to have everything they need in a device that fits in their pockets. For this purpose, we searched and found the best ways and technologies for this development. In this context, it was proposed a software that helps an orthodontic office to control their administrative tasks with access from the Web and mobile phones. Keywords: Wireless, WAP (Wireless Application Protocol), JME (Java Micro Edition).

20 19 1 INTRODUÇÃO O acesso à rede mundial de computadores tem crescido a taxas exorbitantes nos últimos anos, especialmente no Brasil cujas taxas giram em torno de 16% anuais e, nos últimos dois anos, passou para 78% o aumento do número de internautas residenciais, de acordo com [1] e [2]. Paralelamente ao crescimento da Internet, o avanço das Tecnologias de Informação e Comunicação - TIC, especialmente a telefonia celular, tem permitido uma maior aderência das aplicações comerciais às demandas de mercado, tornando a mobilidade um fator primordial para aumento da lucratividade das empresas, principalmente em virtude de melhoria dos serviços prestados a seus clientes. O mercado de aplicações móveis produz serviços cada vez mais impressionantes como o Google Maps que é baseado em pesquisa e visualização de mapas e imagens de praticamente qualquer lugar do planeta via satélite podendo ser possível, também, visualizar a posição do usuário no mapa e de sua rede de amigos; o Modality, presente no iphone, que é uma ferramenta que permite ampliar e navegar por imagens do corpo humano utilizando teclado touchscreen presente no aparelho; e o CallACab permite que os usuários liguem para um táxi próximo a sua localização com um único clique e com visão detalhada do mapa onde ele se encontra presente na plataforma Android - do Google. [3] [4]. Nesse sentido, a melhoria contínua das interfaces das aplicações em aparelhos celulares, bem como a ampliação dos recursos oferecidos, permitidos pela miniaturização de componentes, telas coloridas e maiores, além de baterias de longa duração, tem revolucionado a telefonia sem fio. Muitas modificações e inovações foram introduzidas na tecnologia utilizada pelos telefones celulares desde que a Motorola apresentou, em 1973, seu protótipo do primeiro telefone celular. Pesando 794,16 gramas, o DynaTAC 8000x, da Motorola, ganhou logo o apelido de "tijolo". O preço também era pesado: dólares. Sua bateria permitia uma hora de conversação e a memória

21 20 armazenava 30 números de telefones. Podia não ser exatamente bonito, mas permitia comunicação móvel - ao menos para quem conseguisse carregá-lo. [5] Em 35 anos de evolução, houve um crescimento meteórico na tecnologia e na adição de funções nos aparelhos celulares. E o melhor: por um preço mais acessível. Os modelos, atualmente, podem vir acompanhados de telas sensíveis ao toque, de câmeras digitais, de acesso a Internet e a tecnologia Bluetooth, suportam jogos, dentre muitas outras funcionalidades. Como exemplo de grande sucesso dessas tecnologias, pode-se citar o iphone, da Apple, e o G1, fabricado pela HTC o qual é baseado na plataforma Android, do Google - ambos com as funcionalidades descritas acima e com os preços acessíveis a uma boa parte da população, principalmente em países de primeiro mundo. Os custos de aquisição mais acessíveis têm permitido um constante crescimento do mercado de usuários de celular no Brasil e no mundo. Segundo dados da Agência Nacional de Telecomunicações (Anatel), no mês de setembro de 2008, o mercado brasileiro de aparelhos celulares já atingiu a marca de 140,6 milhões. [6] Com o advento da tecnologia 3G (Terceira Geração) na telefonia móvel, as operadoras de celular no Brasil poderão oferecer a seus usuários serviços como telefonia por voz e a transmissão de dados a longas distâncias com altas taxas de transmissão. Importante ressaltar que mais de 25% da população brasileira já mora em municípios onde pelo menos uma operadora de celular oferece a tecnologia 3G. Isso faz com que a Internet através do celular seja mais viável e atrativa, tornando o Brasil o país que mais acessa internet via celular na América Latina, seguido pelo México e Venezuela, de acordo com [7] [8].

22 21 Figura 1: Comparação entre o número de celulares e computadores no mundo Interessante observar que, mesmo com as restrições atuais nos custos de acesso a dados pelo celular - especialmente nos mercados em estágio de desenvolvimento, como o brasileiro -, os usuários de Internet móvel já passam de 400 milhões no mundo - um terço dos internautas que navegam pelo PC - e a previsão é de que cheguem próximo à marca de um bilhão dentro de três anos, como mostra a figura 1[9]. Em mercados mais maduros como o Japão, o número de usuários de internet pelo celular já é superior ao de internautas que navegam pelo desktop. Para as empresas de internet - como Microsoft, Google e Yahoo! -, trata-se de um novo universo de oportunidades. Segundo previsões do emarketer, os gastos com anúncios em celulares devem chegar a 13,8 bilhões de dólares em Deste total, 17% virão do mercado de aplicações de buscas. Segundo [9], dos 982,4 milhões de usuários de internet móvel previstos para 2011, mais de 90% vão utilizar os serviços de busca, fornecendo combustível para um mercado de 2,3 bilhões de dólares em links patrocinados como mostra a figura 2[9].

23 22 Figura 2: Projeções para a internet móvel no mundo Tendo em vista todas as possibilidades de mobilidade discutidas até agora, a utilização de computação móvel na área de saúde, especificamente na odontologia, pode ser vista como elemento interessante para agilidade na geração de informações e diagnósticos nos tratamentos dos pacientes. A área da odontologia é marcada por processos minuciosos que necessitam de um rigoroso controle a fim de promover um acompanhamento mais preciso no tratamento do paciente. Processos esses como acompanhamento constante do tratamento do paciente e os procedimentos que foram e serão tomados nas consultas. Desta maneira, um sistema de informação seria dito ideal para o contexto se combinassem as garantias de estabilidade, de veracidade e integridade da informação com a facilidade de acesso que a Internet oferece tanto em dispositivos móveis como em computadores pessoais. Este trabalho visa conceituar um sistema de informação, destinado às clínicas ortodônticas, que possa auxiliar na gestão do tratamento do paciente, abrangendo desde a possibilidade de marcação e visualização de consultas até o controle de pagamento das parcelas, com a flexibilidade oferecida pela internet e telefonia móvel ter a facilidade de acesso como foi descrito.

24 23 2 JUSTIFICATIVA O avanço rápido das Tecnologias de Informação e Comunicação - TICs, aliado à crescente necessidade de diferenciação dos serviços oferecidos no mercado de saúde odontológico são fatores catalisadores de soluções em software. Nesse sentido, este trabalho é justificado pela ausência no mercado de uma solução específica no setor odontológico, que contemple várias funcionalidades dos serviços prestados, diferenciandoos e tornando sua gestão mais otimizada. Adicionalmente, a possibilidade de estudo e de convergência de várias tecnologias de computação móvel em um protótipo, aliado ao estudo científico dessas tecnologias, torna-se um diferencial do trabalho proposto. 2.1 Motivações Por em prática todo conteúdo aprendido nas disciplinas relacionadas à programação orientada a objetos, engenharia de software e banco de dados durante a graduação foram uma das principais motivações para a realização deste projeto de pesquisa. Além disso, o contato com o desenvolvimento para dispositivos móveis, por ser um mercado novo, em crescimento, estando cada vez mais presente na vida das pessoas, nos motivou ainda mais pelo retorno de aprendizado e possíveis oportunidades de negócios.

25 24 3 OBJETIVOS Esta seção tem como objetivo principal apresentar o sistema proposto como estudo de caso. Os itens que se seguem apresentam os principais processos e etapas dentro do desenvolvimento de software aplicados no projeto, alem de discussões sobre arquiteturas, padrões e as melhores soluções adotadas. Como objetivos secundários, este trabalho pretende: Realizar um estudo comparativo das tecnologias open-source mais difundidas para o desenvolvimento de aplicativos móveis, WAP e JME, no que se diz respeito à implementação, usabilidade e às tendências do mercado de trabalho; Implementar aplicativos embarcados em aparelhos celulares utilizando ferramentas CASE, UML (Unified Modelling Language, Linguagem de Modelagem Unificada) e Internet (como a linguagem de estilo CSS Mobile e as linguagens de marcação XML, XHTML-MP); Elaborar um estudo de caso aplicando os conceitos e tecnologias abordadas de forma a construir um sistema, denominado MobOdonto.

26 25 4 TECNOLOGIAS Nesta seção serão apresentadas as tecnologias escolhidas como base para as pesquisas e suas principais definições para auxiliarem no cumprimento dos objetivos descritos na seção WAP WAP - Wireless Application Protocol, Protocolo de Aplicativos Sem Fio - é um protocolo de comunicação e ambiente de aplicações para distribuição de recursos de informação, serviços de telefonia avançado e acesso à internet a partir de dispositivos móveis. Ele representa um novo modo de olhar o fenômeno sem fio - permitindo aos aplicativos "seguirem"seus clientes e fornecendo a eles serviços inovadores. [10] Histórico De acordo com [10], em 1995, nos EUA, a Unwired Planet apresentou a HDML (Handheld Device Mark Up Language, Linguagem de Marcação para Dispositivos Sem Fio) - que é uma versão reduzida de HTML para ser usada em dispositivos sem fio. E, no Japão, a operadora NTT DoCoMo apresentou um serviço chamado i-mode, no início de Essa tecnologia se tornou muito popular com quase sete milhões de usuários acessando serviços de internet a partir de telefones móveis. Essas duas tecnologias apresentaram questões interessantes como qual seria a vencedora. Seria aquela que fornecesse a melhor solução para determinado problema ou aquela mais amplamente adotada? Essa foi uma questão respondida durante Ela poderia ter se mantido no enfoque apenas do desenvolvimento do HDML, o que permitiria crescer no EUA como a NTT DoCoMo fez com o i-mode no Japão. Entretanto, em vez disso, ela optou por envolver os principais fabricantes de telefones

27 26 móveis em seu projeto, reconhecendo que quanto mais dispositivos existissem no mercado mundial oferecendo suporte à tecnologia, mais ela poderia vender suas soluções de internet sem fio em todo o mundo. O envolvimento de outras empresas, cada uma com uma grande base de clientes em diferentes partes do mundo, tem ajudado a promover a tecnologia. Assim o WAP Forum (hoje a All Mobile Alliance) foi criada pela Phone.com (antiga Unwired Planet), Ericsson, Nokia e Motorola. Com o advento do WAP Forum, a Phone.com compartilhou seu conhecimento e a parceria logo evoluiu para as abrangentes especificações WAP, que incluem as camadas de aplicativo complementar, sessão, transação, segurança e protocolo de transporte. Também foi criada uma nova linguagem de marcação, chamada WML, Wireless Markup Language ou Linguagem de Marcação Sem Fio. Esses protocolos minimizam os problemas associados ao uso de protocolos de internet para transferência de dados sem fio. Eles fazem isso eliminando transferências de dados desnecessárias usando código binário para reduzir o volume de dados que precisa ser enviado. Além disso, as sessões sem fio são projetadas para serem facilmente suspensas e retomadas, sem as cargas adicionais associadas a protocolos de internet. Assim, os protocolos são muito convenientes para a baixa largura de banda associada à comunicação sem fio. Com 90% do mercado de aparelhos telefônicos representado no WAP Forum, o WAP será a principal maneira de acessar a Internet Arquitetura de Aplicativo WAP Os protocolos WAP foram projetados tendo em vista os protocolos Web. O objetivo era usar a estrutura da Web subjacente, mas tornar a comunicação entre os provedores de conteúdo e dispositivos móveis mais eficientes e com menos demora do que os próprios protocolos da Web se fossem usados [10]. Como a arquitetura WAP foi projetada para ser parecida com a da Web, o paradigma cliente-servidor usado pela Internet foi herdado pelo WAP. A principal diferença, entretanto, é a presença do gateway WAP para fazer a transformação entre o protocolo HTTP e WAP. [10]. A abstração representada pela figura 3[10] mostra a principal diferença mencionada anteriormente.

28 27 Figura 3: Comparação entre WAP e Internet quando usado para acessar a Web Cliente WAP Segundo [10], o único requisito para que um dispositivo seja compatível com WAP é que ele deve implementar um agente usuário WAE, um agente usuário WTA e a Pilha WAP. O Agente de Usuário WAE (Wireless Application Environment, Ambiente de Aplicativos Sem Fio) é o micro-navegador que traz o conteúdo para exibição. Ele recebe o código WML compilado, o WMLScript e todas as imagens do gateway WAP, e os executam ou os apresentam na tela. O navegador deve implementar toda a funcionalidade fornecida pelo código WML e WMLScript. Ele também deve gerenciar a interação com o usuário, como a entrada de saída de textos e mensagens de erro ou aviso; O Agente de Usuário WTA (Wireless Telephony Applications, Aplicações de Telefonia Sem Fio) recebe arquivos WTA compilados do servidor WTA e os executam. O Agente de Usuário WTA inclui acesso à interface para o telefone e funcionalidade de rede, como discagem de números, respostas às chamadas, gerenciamento de mensagens e serviços de indicação de local; A implementação da Pilha WAP permite ao telefone se conectar com o gateway WAP usando os protocolos WAP.

29 28 A figura 4[10] ilustra o Cliente WAP: Figura 4: Cliente WAP Gateway WAP De acordo com [10], o gateway WAP é, na verdade um proxy (servidor que atende a requisições repassando os dados a outros servidores [11]). Ele é utilizado para conectar o domínio sem fio com o da Internet. Entretanto, ele contém funcionalidades de gateway de protocolos, além de funcionalidades de codificação/decodificação. A figura 5[10] ilustra o uso de um proxy/gateway WAP. Figura 5: Uso do Gateway WAP

30 Funcionamento do Gateway WAP A figura 6[10] apresenta um gateway WAP e outros elementos na rede sem fio mostrando como o gateway WAP colabora e faz a interface com todos os outros elementos para fornecer um serviço completo. Figura 6: Gateway WAP e elementos da rede sem fio Segundo [10], quando se inicia uma sessão WAP em um telefone móvel, os seguintes passos são executados. Uma conexão é criada, via WSP (Wireless Session Protocol, Protocolo de Sessão Sem Fio), entre o dispositivo móvel e o gateway WAP, o qual se supõe estar presente na rede da operadora; Quando se introduz o endereço de um site WAP, é enviado para o gateway um pedido do micro-navegador do dispositivo, usando WSP. O WSP é o protocolo WAP responsável por iniciar e terminar as conexões dos dispositivos móveis com o gateway WAP; O gateway transforma o pedido WSP em um pedido HTTP e o envia para o servidor de origem apropriado; O servidor de origem envia de volta para o gateway a informação solicitada, via HTTP;

31 30 O gateway transforma e compacta a informação e a envia de volta para o micronavegador no dispositivo móvel. A parte do gateway do proxy WAP cuida da transformação de todos os pedidos enviados e recebidos pelo cliente, usando WAP, para o que servidor de origem está usando (HTTP, por exemplo). O provedor de conteúdo envia seu conteúdo para o gateway usando o protocolo HTTP. Então, ele encaminha todo o conteúdo recebido para os dispositivos WAP, usando os protocolos WAP [10]. A figura 7[10] ilustra o que foi discutido neste parágrafo. Figura 7: Gateway do proxy WAP A funcionalidade de codificação/decodificação dentro do gateway é usada para converter o conteúdo WML e WMLScript que transita no cliente para uma forma otimizada para redes de banda baixa [10]. O gateway WAP também é conectado ao serviço WTA, presente na rede da operadora, que fornece a interface para acessar alguns dos serviços de rede que a operadora queira oferecer. Como ele normalmente é o elemento da operadora de rede que é contactado pelos clientes para acessar serviços, ele também precisa incluir funcionalidade de tarifação e implementa uma interface para cada uma das portadoras presentes na rede sem fio[10].

32 31 Figura 8: Codificador / Decodificador do Gateway WAP Outro serviço que a funcionalidade CODEC (codificação/decodificação) pode fornecer é a transformação de código HTML ou texto em WML. O gateway WAP também é conectado ao serviço WTA, presente na rede da operadora, que fornece a interface para acessar alguns dos serviços de rede que a operadora queira oferecer. Como ele normalmente é o elemento da operadora de rede que é contatado pelos clientes para acessar serviços, ele também precisa incluir funcionalidade de tarifação e implementa uma interface para cada uma das portadoras presentes na rede sem fio [10] Servidor de Aplicativos WAP O servidor de aplicativos/origem/conteúdo WAP tem exatamente a mesma função que um servidor Web e fornece os mesmos recursos para os clientes. A distinção entre eles é apenas lógica, pois os dois podem coexistir no mesmo dispositivo físico, e alguns servidores podem fornecer as duas funções usando o mesmo software. A única diferença,é claro, o conteúdo que eles armazenam e enviam para os clientes. Enquanto o servidor Web oferece suporte a HTML, JavaScript, multimídia e todos os formatos de imagens, o servidor de aplicativos WAP armazena arquivos WML, WMLScript e arquivos de imagem WBMP. Um servidor WAP normalmente é apenas um servidor de aplicativos WAP com funcionalidades de gateway incluídas. Ele fornecerá todos os serviços que um servidor de origem normal fornece, mas também atuará como um gateway WAP [10]. O servidor de aplicativos WAP também pode, é claro, conter todas as tecnologias usadas para fornecer conteúdo dinâmico. É possível usar XML em conjunto com ASP

33 32 e Servlets Java, para citar apenas algumas, para gerar conteúdo WML dinamicamente [10]. Para permitir que um servidor Web contenha aplicativos WAP é necessário simplesmente incluir os tipos de arquivos WAP nos ajustes do servidor [10] Pilha de Protocolos WAP A pilha WAP foi baseada no modelo de referência OSI ISO [ISO7498] e herdou a maior parte de suas características. A principal diferença entre as duas é o numero de camadas: o WAP tem apenas cinco camadas, enquanto o modelo OSI possui sete [10]. A figura 9 [10] ilustra a pilha WAP. Figura 9: Pilha de Protocolos WAP A seguir, a descrição das camadas da pilha WAP segundo [10] Wireless Application Environment - WAE A camada de aplicação do WAP fornece um ambiente que inclui todos os elementos relacionados ao desenvolvimento e à execução de aplicativos.os principais blocos de construção do WAE são os seguintes:

34 33 Uma linguagem de marcação leve: WML; Uma linguagem de script leve: WMLScript; Uma interface para serviços locais e serviços de telefonia avançados: WTA Wireless Session Layer - WSP O WSP (Wireless Session Protocol, Protocolo de Sessão Sem Fio), permite que serviços troquem dados entre aplicativos de forma organizada. Ele inclui dois protocolos diferentes: Serviços de sessão à conexão: Operam através do WTP (Wireless Transaction Protocol ou Protocolo de Transação Sem Fio); Serviços de sessão sem conexão: Operam diretamente através da camada de transporte (WDP, Wireless Datagram Protocol, Protocolo de Datagrama Sem Fio). Sob alguns aspectos, a camada de sessão WSP é basicamente uma forma binária de HTTP. A transmissão binária de dados entre o servidor e um cliente é uma adaptação essencial feita para rede móvel de largura de banda estreita. O WSP fornece todos os métodos definidos por HTTP/1.0 e permite a capacidade de negociação para obter total compatibilidade com HTTP/ Wireless Transaction Layer - WTP O WTP (Wireless Transport Layer, protocolo de transmissão sem Fio) fornece serviços para realizar transações confiáveis e não confiáveis e opera por intermédio da camada WDP ou por meio da camada de segurança opcional, WTLS. A WTP, assim como as outras camadas no WAP, é otimizada para se adaptar à pequena largura de banda da interface de rádio, tentando reduzir o volume total de transações repetidas entre o cliente e o servidor. Em particular, três classes diferentes de serviço são fornecidas para as camadas superiores: Pedidos Não Confiáveis: O iniciador (neste caso, um servidor de conteúdo) envia um pedido para o respondedor( agente de usuário ) que não responde com

35 34 um reconhecimento. A transação na tem estado e termina quando a mensagem chamada for enviada. Pedidos Confiáveis: O iniciador envia um pedido para o respondedor, que o reconhece. O respondedor armazena as informações de estado da transação por algum tempo, para que possa retransmitir a mensagem de reconhecimento, caso o servidor a peça novamente. A transação termina no iniciador, quando este recebe a mensagem de reconhecimento. Pedidos Confiáveis com uma mensagem de resultado: O iniciador envia um pedido para o respondedor que o reconhece implicitamente com uma mensagem de resultado. O iniciador então, reconhece a mensagem de resultado, mantendo a informação de estado da transação por algum tempo, após o reconhecimento ter sido enviado, no caso de ele não chegar. A transação termina no respondedor, quando ele recebe a mensagem de reconhecimento Wireless Transport Layer Security - WTLS O TLS (Wireless Transport Layer Security, Segurança de Camada de Transporte Sem Fio) é a solução para o problema de segurança fornecida pelo WAP Forum. WTLS é uma camada opcional e tem por base a TLS (Transport Layer Security, Segurança de Camada de Transporte) v1.0, que por sua vez é baseada na SSL (Secure Sockets Layer, Camada de Soquetes Seguros) v3.0, que são protocolos de Internet. O WTLS opera através da camada de transporte (WDP). Ela fornece serviços que garantem privacidade, autenticação de servidor, autenticação de cliente e integridade de dados Wireless Application Environment - WAE O WDP (Wireless Datagram Protocol, Protocolo de Datagramas Sem Fio) é a camada inferior da pilha WAP e é aquela dos elementos que tornam o WAP, o protocolo extremamente portátil que é, possível de ser usado em redes móveis extremamente diferentes. O WDP isola as camadas superiores dos serviços de portadoras fornecidos pela rede, permitindo aos aplicativos uma transmissão de dados transparente por meio de diferentes portadoras. Os serviços de portadora são o âmago da comunicação entre o telefone móvel e as estações rádio-base. Eles incluem SMS (Short Message Service ou Serviço de Mensagens Curtas), CSD, USSD (Unstructured Supplementary Service Data ou Serviço Complementar de Dados Estruturados - trata-se

36 35 de uma modalidade de serviço de envio de mensagens curtas para o celular) e CDMA (Code Division Multiple Access ou Acesso Múltiplo por Divisão de Código) Wireless Datagram Protocol O WDP (Wireless Datagram Protocol, Protocolo de Datagramas Sem Fio) é a camada inferior da pilha WAP e é aquela dos elementos que tornam o WAP, o protocolo extremamente portátil que é, possível de ser usado em redes móveis extremamente diferentes. O WDP isola as camadas superiores dos serviços de portadoras fornecidos pela rede, permitindo aos aplicativos uma transmissão de dados transparente por meio de diferentes portadoras. Os serviços de portadora são o âmago da comunicação entre o telefone móvel e as estações rádio-base. Eles incluem SMS (Short Message Service ou Serviço de Mensagens Curtas), CSD, USSD (Unstructured Supplementary Service Data ou Serviço Complementar de Dados Estruturados - trata-se de uma modalidade de serviço de envio de mensagens curtas para o celular) e CDMA (Code Division Multiple Access ou Acesso Múltiplo por Divisão de Código). 4.2 Linguagem e Plataforma Java Java é uma plataforma desenvolvida pela Sun Microsystems, na década de 1990, com a idéia de que aplicações criadas para ela pudessem ser executadas em diferentes ambientes computacionais [12]. Tudo começou em 1991 com um projeto, conhecido como Green Project, iniciado por uma equipe da empresa. Essa equipe, liderada por James Gosling, tinha como objetivo principal criar um interpretador para dispositivos eletrônicos de consumo como TVs, vídeos-cassete, torradeiras e liquidificadores. Em 1992 foi desenvolvido um protótipo chamado *7 (StarSeven), que era uma espécie de controle remoto para esses eletrônicos, com interface intuitiva e tela touchscreen. Para que o dispositivo pudesse controlar uma ampla quantidade de aparelhos, foi criada uma linguagem denominada Oak, onde sua principal característica era ser independente de arquitetura de processador onde seria executada. Toda essa idéia teria sido perfeita se não fosse um pequeno problema: inexistência de mercado [13]. No início da década, as empresas estavam começando e ainda buscavam modelos

37 36 de negócios viáveis fazendo com que o crescimento neste setor não atingisse o nível esperado pela Sun. Quase que em paralelo a esses acontecimentos, em 1993, surge o navegador Mosaic revolucionando a maneira como as pessoas enxergavam a Web. De certa forma, todas as principais características e idéias que a Sun havia buscado com o Green Project estavam coincidentemente sendo aplicadas à Internet e, vendo todo esse potencial, a equipe adaptou o projeto para a grande rede em Com esta adaptação o nome da linguagem foi modificado para Java, como hoje é conhecido [13]. A primeira versão da linguagem foi lançada em 1996 e a partir dela, a plataforma foi crescendo e ganhando força tornando-se hoje uma das mais usadas no mundo [14]. Com o tempo, o Java foi amadurecendo e vislumbrando possibilidades em outros setores da indústria além da Internet e, reconhecendo a impossibilidade de criar uma plataforma única capaz de abranger completamente as demais áreas de mercado, a Sun dividiu a tecnologia em três edições, cada uma visando segmentos específicos de negócio: JSE (Java Standard Edition) [15] - projetada para rodar em computadores pessoais (desktops) e estações de trabalho. JEE (Java Enterprise Edition) [16] - projetada com foco em aplicações para serem executadas no servidor. JME (Java Micro Edition) [17] - especializada em pequenos dispositivos com memória, tela e poder de processamento limitados. A figura 10 [18] mostra um diagrama com uma visão geral da plataforma Java: Plataforma JME Em tempos anteriores, os dispositivos não possuíam opções para download e instalação de softwares além dos pré-configurados pelos fabricantes. Com a introdução do JME, os aparelhos que o implementavam deixaram de ser estáticos e tornaram-se mais atrativos à medida que os usuários poderiam adaptá-los instalando ou mesmo escrevendo suas próprias aplicações[19].

38 37 Figura 10: Plataforma Java e suas edições A plataforma JME define um conjunto de tecnologias e especificações para ampliar o alcance do Java em direção aos pequenos aparelhos. Desta maneira, seu foco está nos dispositivos de consumo com limitações de memória, tela e processamento, como celulares, PDAs, pagers, entre outros. A plataforma é baseada em três elementos [20]: As configurações, que contém um conjunto básico de bibliotecas e definições de capacidades da JVM (Java Virtual Machine ou Máquina Virtual Java) para uma ampla quantidade de dispositivos; Os perfis, que definem um conjunto de APIs (Application Programming Interface ou Interface de Programação de Aplicativos) para suporte a uma quantidade mais restrita e específica de dispositivos; Os pacotes opcionais, que definem um conjunto de APIs para uma tecnologia em particular. A figura 11 [18] ilustra o que foi discutido.

39 38 Figura 11: JME e seus componentes Devido à grande diferença dos aparelhos em termos de capacidades de hardware, a Sun os subdividiu em duas categorias: a dos pequenos dispositivos, ou seja, equipamentos com limitação de processamento e memória e a dos dispositivos com maiores capacidades como smartphones e set-top boxes. A categoria dos pequenos dispositivos está representada pela configuração CLDC (Connected Limited Device Configuration, Configuração para dispositivos Conectados e Limitados), onde estão incluídos pagers, celulares e PDAs. A configuração CDC (Connected Device Configuration, Configuração para Dispositivos Conectados) representa os aparelhos mais robustos, normalmente set-top boxes para TVs, sistemas de navegação para automóveis e alguns PDAs com mais recursos [20]. Como as configurações não provêem suporte para o gerenciamento da aplicação, como o controle da interface e acessos a informações em um servidor ou a dados persistentes no dispositivo, necessita-se dos perfis e pacotes opcionais para fazerem esse trabalho. Os perfis trazem classes mais específicas do que as presentes nas configurações. [17] O MIDP (Mobile Information Device Profile, Perfil de Dispositivo de Informações Móvel), por exemplo, é o mais utilizado e complementa as funcionalidades da CLDC [21]. Além dos perfis, existem os pacotes opcionais que são independentes de qualquer tipo de dispositivo. Eles trazem APIs específicas para determinada funcionalidade. O

40 39 Bluetooth, por exemplo, pode ser citado como um destes recursos e, portanto, existe um conjunto de classes definidas para explorarem esta característica. A figura 12[22] mostra a divisão do pacote JME: Figura 12: JME dividida em camadas Java Community Process (JCP) e Java Specification Request (JSR) Todo desenvolvimento de tecnologia para a plataforma Java se estabelece através de especificações e para que elas sejam criadas é necessária uma entidade que controle todo o processo. Baseado nestas premissas existem o JCP (Java Community Process) e a JSR (Java Specification Request). O JCP (Java Community Process) [22] é uma comunidade representada pela Sun e outros parceiros da indústria, que tem como objetivo manter a padronização das tecnologias que compõem a plataforma. Atualmente, o JCP possui mais de 1200 membros, entre eles grandes empresas como IBM, Fujistu, Motorola, Borland e Oracle. A JSR (Java Specification Request) é um documento criado e enviado pelos membros do JCP com proposta de desenvolvimento ou melhoria de uma tecnologia. Uma JSR contém todas as características de determinado produto informando o que ele deve contemplar. De posse dessas informações, qualquer empresa pode definir sua própria implementação, desde que esteja condizente com sua respectiva especificação. Todas as tecnologias que fazem parte da plataforma Java, desde a JVM passando pelos servidores de aplicação, JSPs (JavaServer Pages) e Servlets até as Configurações e Perfis presentes no JME são especificações mantidas pelo JCP [23].

41 Configurações As configurações definem a base de funcionalidades para dispositivos com características comuns, isto é, especificam os recursos e classes presentes na JVM. Desta forma, intermediam a comunicação entre o Perfil e a VM (Virtual Machine, sinônimo de Java Virtual Machine - JVM) e sua especificação está diretamente ligada à implementação de uma máquina virtual. Assim, cada configuração tem sua própria VM [19]. A plataforma JME as divide em duas partes, separadas por capacidades de hardware dos dispositivos que suportam: CLDC e CDC ilustrados na figura 13. Figura 13: Configurações do JME CLDC (Connected Limited Device Configuration) A CLDC define as bibliotecas e especificações da VM com o objetivo de suportar dispositivos com restrições de processamento, memória, tela, entrada de dados e bateria como celulares e PDAs. A CLDC trabalha em cima da KVM (Kilobyte Virtual Machine - uma máquina virtual Java limitada), que foi projetada para consumir uma quantidade mínima de memória por não poder implementar boa parte das características da JVM padrão [19] e [22]. Assim como toda tecnologia Java, a CLDC também é uma especificação. Devido às grandes mudanças no mercado móvel, tendo em vista o surgimento de novos recursos e o aumento das capacidades dos aparelhos, sua especificação precisa acompanhar esta evolução. Atualmente, a CLDC está definida em duas especificações: JSR 30 (CLDC 1.0) e JSR 139 (CLDC 1.1). Como as capacidades dos dispositivos que a CLDC abrange variam consideravelmente, a JSR 30 (CLDC 1.0) não definiu qualquer

42 41 requisito mínimo de hardware além do requisito de memória. Nesta especificação é esperado que a VM, as bibliotecas de Configurações e Perfis e a aplicação tenham entre 160KB e 512KB de memória. Mais especificamente possuam as seguintes características: 128KB de memória não-volátil para a VM e classes presentes na configuração. 32KB de memória volátil para suportar o armazenamento dos objetos durante a execução da aplicação. Assim como a CDC, a CLDC é baseada na plataforma JavaSE, logo, implementa algumas funções presentes nela. Porém, devido a limitações impostas pelos aparelhos, algumas tiveram que ser retiradas da versão 1.0 para economia de memória. Entre elas: reflection, suporte a ponto flutuante, finalização de objetos e tratamentos de exceções derivadas da classe java.lang.error. [24] Para a versão 1.1 algumas características da especificação foram alteradas para se adaptar às novas capacidades dos aparelhos. Para os requisitos mínimos de hardware foi definido pelo menos 192KB de memória. Mais especificamente: pelo menos 160KB de memória não-volátil para a VM e as bibliotecas definidas na CLDC. pelo menos 32KB de memória volátil para os objetos da aplicação. Durante o tempo de uso da CLDC 1.0, percebeu-se que algumas características retiradas dessa JSR eram de extrema importância para o desenvolvimento das aplicações e, logo, foram incorporadas à versão 1.1. Entre elas, destaca-se o suporte a dados de ponto flutuante. [25] Por serem considerados muito grandes e complexos para dispositivos móveis, os pacotes java.io e java.net presentes na plataforma JavaSE não foram colocados na CLDC. Em detrimento, foi criado o GCF (Generic Connection Framework) que, baseado nas reais necessidades e capacidades dos aparelhos, define em algumas classes e interfaces formas de conectividade e I/O (Input/Output ou Entrada e Saída de dados). O GCF é um framework usado para fazer conexões como HTTP, HTTPS, streams

43 42 e datagramas. Ele foi definido e incluído na JSR 30 (CLDC 1.0), mas por ser amplamente flexível possibilita que outros perfis e pacotes opcionais estendam sua base e definam sua própria implementação de conectividade, como mostrado na figura 14 [26]. Figura 14: Relacionamento entre as diferentes implementações do GCF CDC (Connected Device Configuration) A CDC [27] especifica recursos de VM e bibliotecas com foco em aparelhos mais robustos como smartphones, set-top boxes e PDAs com mais recursos. Sua implementação é executada sobre a CVM (Compact Virtual Machine ou Máquina Virtual Compacta), máquina virtual baseada na VM Java. Por abranger dispositivos com maiores capacidades ela possui suporte completo da plataforma JSE o que torna mais simples a adaptação de quem desenvolve e utiliza ferramentas e recursos para desktops. Basicamente, os dispositivos suportados devem possuir um processador de 32bits, 2MB de memória volátil e 2.5MB de memória não-volátil como requisito mínimo [28]. A CDC está especificada em duas JSRs, onde cada uma está baseada em uma versão do JavaSE. A JSR 36 (CDC 1.0) possui características da versão 1.3 e a JSR 218 (CDC 1.1.2) da Perfis Mesmo pertencendo à mesma configuração, os dispositivos ainda possuem algumas diferenças entre si. Por exemplo, um celular e um PDA se encaixam nas especifi-

44 43 cações da CLDC, o que significa que compartilham características em comum. Porém, mesmo sendo definidos como parte de uma mesma família ainda possuem tamanho de tela diferente. Como solução para esse problema foi introduzido pela Sun o conceito de perfil. O perfil traz bibliotecas mais específicas para um grupo de dispositivos em particular. Existem diferentes perfis associados às configurações e abaixo segue uma lista: Os perfis associados à CLDC: MIDP (Mobile Information Device Profile) [29] Perfil definido para pequenos dispositivos, como celulares e PDAs. Sua API define classes para manipulação de interface, persistência de dados e outros recursos específicos para o uso da aplicação. Atualmente, sua combinação com a configuração CLDC define o ambiente mais utilizado nos aparelhos. [30] O MIDP possui duas versões, 1.0 e 2.0, definidas nas especificações JSR 37 e JSR 118. Ambas definem os mesmos requisitos mínimos de display e entrada de dados: 96x54 pixels e teclado ou tela touchscreen, respectivamente. A diferença fica com base na disponibilidade de memória, onde o MIDP 1.0 define 128KB (memória nãovolátil além da requerida pela CLDC), 8KB (memória não-volátil para dados armazenados pela aplicação) e 32KB (memória volátil para execução) e a versão 2.0 assume 256KB, 8KB e 128KB [31] [32]. IMP (Information Mobile Profile) [33] Perfil baseado no MIDP 1.0 que tem como objetivo suportar dispositivos que não possuem capacidades gráficas avançadas como parquímetro, aparelho de medida industrial e módulos wireless em alarmes residenciais [34]. Atualmente permanece na versão 1.0 definida pela JSR 195. Os perfis associados à CDC: FP (Foundation Profile) [35] Perfil sem muitas funcionalidades e o mais básico da CDC, define API para dispositivos desprovidos de interface gráfica como impressoras de rede, roteadores e gateways e em caso de necessidade de uma GUI (Graphical User Interface ou Interface Gráfica do Usuário), o FP pode ser integrado a um sistema que faça esse controle. Está definida na JSR 46 (FP 1.0) [36] e JSR 219 (FP 1.1.2) [37].

45 44 PBP (Personal Basis Profile) [38] Fornece suporte a aparelhos com interface gráfica simples, como dispositivos para automóveis, incluindo uma versão leve da biblioteca gráfica AWT presente no JavaSE. PP (Personal Profile) [39] Perfil que oferece suporte completo a biblioteca AWT, abrangendo aparelhos com GUI mais refinada como PDAs com mais recursos e browsers em dispositivos embarcados.

46 45 5 WAP x JME Durante o decorrer deste trabalho foi feita uma análise minuciosa de cada tecnologia, buscando uma maior exploração de suas arquiteturas e funcionamentos para fins comparativos. Com base nessas informações é mostrada uma tabela comparativa, ilustrada na tabela 1, com foco em recursos relevantes para ambas, com intuito de mostrar vantagens e desvantagens de cada uma como forma de justificativa daquela de tal adoção: 5.1 Ambientes de Desenvolvimento WAP: Há várias.ferramentas disponíveis no mercado como Wapalize! WAP Development Kit e WAPTor. Como há variação de características entre celulares com suporte as diferentes versões do WAP e recursos do próprio aparelho, os SDKs (Software Development Kit ou Kit de Desenvolvimento de Software) dos fabricantes, como o Mobile Internet Toolkit 3.1 da Nokia. JME: Possui suporte para desenvolvimento nas duas principais IDEs (Integrated Development Environment ou Ambiente Integrado de Desenvolvimento) do mercado, NetBeans e Eclipse. Ambas oferecem excelente suporte aos emuladores e disponibilizam ferramentas que auxiliam a criação de projetos. Além desses ambientes, a maior parte dos fabricantes de celulares disponibiliza seus SDKs proprietários oferecendo possibilidade de teste da aplicação nos emuladores de cada modelo de aparelho. 5.2 Conectividade WAP: O WAP possui suporte a protocolos como IP, TCP e HTTP provendo a um aplicativo a possibilidade de usufruir tecnologias utilizadas na internet.

47 46 JME: O JME possibilita o estabelecimento de comunicação de diferentes formas, desde HTTP e Sockets TCP a SMS e Bluetooth. Os tipos básicos de conectividade são definidos no framework GCF, presente na plataforma. 5.3 Segurança de Informação WAP: O WAP possui a camada WTLS que é uma camada opcional que é baseada na SSL 3.0 que são protocolos da Internet. Esta camada fornece serviços que garantem privacidade, autenticação de servidor, autenticação de clientes e integridade de dados[40]. JME: Possui suporte a HTTPS, o que possibilita uso de comunicação segura com SSL habilitada no servidor além de disponibilizar APIs com suporte a certificados digitais para identificação segura e criptografia de dados como, por exemplo, o SATSA [41]. 5.4 Acesso a Serviço Local do Dispositivo WAP: Os aplicativos WAP podem acessar os serviços do aparelho por intermédio da WTAI (Wireless Telephony Application Interface ou Interface para Aplicação para Telefonia Sem Fio). "WTAI é usada para acessar os serviços que estão presentes localmente no dispositivo-cliente ou na rede móvel"[40]. JME: A plataforma JME oferece um amplo suporte a acesso a recursos disponíveis em aparelhos que, são oferecidos por APIs específicas definidas no celular. A JSR 75, por exemplo, quando implementada no dispositivo possibilita acesso ao seu sistema de arquivos e a recursos como lista de contatos, entre outros. 5.5 Disponibilidade em Dispositivo Móvel WAP: Desde a criação do WAP, as empresas associadas à OMA (All Mobile Alliance) provêem em seus dispositivos suportes ao WAP. Atualmente, suportam a versão 2.0 do WAP, mas mantendo compatibilidade com versões anteriores. Entretanto, esta compatibilidade pode variar entre aparelhos ficando a decisão por parte do fabricante;

48 47 JME: Atualmente a maior parte dos celulares fabricados chega aos consumidores com alguma implementação do JME, porém, dispositivos mais antigos não provêem esse suporte o que evita o uso da tecnologia para quem possui modelos pouco recentes. 5.6 Frameworks WAP: Até o presente momento de realização da pesquisa não foi encontrado framework relevante para auxilio na construção de aplicativo WAP. JME: Possui vários frameworks disponíveis para melhorar a produtividade no processo de desenvolvimento. Alguns dos mais utilizados para aplicações desktop e Web possuem versões ou semelhantes para JME. Por exemplo, Mobile JUnit para testes unitários, MEChart para geração de gráficos, Floggy para persistência de dados, entre outros. 5.7 Persistência de Dados WAP: A persistência de dados em aplicativos WAP é realizada através da integração de tecnologias como ASP (Active Server Pages), JSP (Java Server Pages) e ColdFusion. A versão 2.0 do WAP possui uma interface de persistência de dados para gravar e recuperar dados tanto do dispositivo móvel quanto de um dispositivo de memória instalada. JME: Amplas alternativas para persistência. A CLDC trabalha com API do RMS por padrão, mas existe a possibilidade de utilização do Floggy, framework que abstrai a complexidade existente no seu uso. Para CDC as possibilidades são ainda maiores como a utilização de SGBDs (Sistema Gerenciador de Banco de Dados) otimizados Oracle, Sybase e outros. 5.8 Interface com Usuário WAP: A camada WAE provê elementos para o desenvolvimento visual como WML que possui textos formatados (itálico, negrito e sublinhado) entrada de dados. Versões anteriores a proviam textos e imagens (WBMP) em preto e

49 48 branco. A partir da versão 2.0 é possível utilizar textos coloridos, assim como imagens GIF, JPEG e PNG, e outros recursos que tornam um aplicativo mais atraente como o uso da linguagem de estilo CSS Mobile (versão móvel do CSS). JME: Além da API básica, a plataforma também possui algumas bibliotecas de componentes com recursos mais avançados como o LWUIT (oficial da SUN), JavaPolish, J4ME. Outro recurso muito utilizado e, uma alternativa as citadas bibliotecas, é a criação de telas através de imagens vetoriais em SVG, onde os componentes podem ser gerados através do mapeamento da imagem. Para uma melhor visualização das características das tecnologias apresentadas, a tabela 1 exibe as comparações:

50 49 WAP JME Ambiente de Desenvolvimento - NetBeans, Eclipse RAD Conectividade IP, TCP e HTTP HTTP, TCP, SMS Bluetooth Segurança de Camada WTLS - SSL 3 HTTPS e bibliotecas Informação externas Acesso Serviço Interface WTAI JSR 75 Local Compatibilidade Aparelhos com mini-browser e KVM suporte a WML/XHTML-MP Framework - Mobile JUnit, MEChart, Floggy Persistência de Interação com ASP, JSP e Frameworks, SGBDs Informação ColdFusion otimizados Versões anteriores a 1.2.1: Linguagem WML, imagens WBMP (imagem preto-e-branco), textos formatados (itálico, negrito e LWUIT (oficial da Interface com sublinhado) SUN), JavaPolish, Usuário J4ME, imagens vetoriais em SVG A partir da versão 2.0: Imagens GIF, JPEG e PNG, CSS Mobile, linguagem xhtml-mp Tabela 1: Comparação WAP x JME 5.9 Comparação entre JME e WAP Tanto JME quanto WAP possuem pontos fortes e fracos. Alguns dos recursos mostrados na tabela 1 cumprem muito bem o seu papel para cada tecnologia, levando em consideração suas diferenças. Tanto o WAP quanto o JME oferecem bons ambientes de desenvolvimento, acesso a recursos específicos do aparelho celular e um sólido suporte à conectividade. A principal vantagem do WAP é a sua disponibilidade na maior parte dos aparelhos celulares. Para oferecer suporte à tecnologia, basta que o dispositivo possua um simples micro-browser que interprete seus protocolos e, para JME, necessita da

51 50 implementação de suas especificações, o que seria inviável para alguns com poucos recursos de hardware. O ponto forte do JME é a quantidade de recursos oferecidos pela plataforma. Uma vez que o aparelho possui capacidade para suportar a tecnologia, pode-se explorar muitas características do dispositivo e, com WAP, seu leque de possibilidades é mais restrito. Embasado por esta análise comparativa decidiu-se adotar as duas tecnologias, de forma a aproveitar suas características para alcançar áreas distintas. Como um dos principais objetivos do projeto é tornar a aplicação disponível para acesso na maior parte dos celulares, uma vez que existem diferentes modelos de diferentes fabricantes disponíveis no mercado, o WAP foi escolhido para implementar uma solução destinada aos clientes da clínica. E, como os casos de uso para o ortodontista são diferentes dos clientes, o JME será adotado para desenvolver uma solução específica para o mesmo, possibilitando focar maiores recursos às suas necessidades.

52 51 6 ESTUDO DE CASO: SISTEMA MOBODONTO Esta seção tem como objetivo apresentar o sistema proposto como estudo de caso. Desta forma, serão descritos os principais processos, e etapas, envolvidos no seu desenvolvimento, assim como uma discussão sobre arquitetura, padrões e melhores soluções adotadas. Dentro dos processos citados incluem-se a fase de levantamento de requisitos, análise e projeto, responsáveis por estabelecer um conhecimento maior a respeito das particularidades do negócio. 6.1 Modelo de Desenvolvimento Para auxiliar o desenvolvimento do sistema foi adotado o modelo em cascata. Segundo [42], o modelo em cascata define uma abordagem sistemática e seqüencial que se inicia com a especificação dos requisitos pelo cliente e evolui ao longo do planejamento passando pelas fases de modelagem, construção e implantação do software buscando garantir, ao final do processo, a qualidade do sistema. Este modelo foi escolhido por ser um paradigma já consolidado no mercado além de satisfazer as necessidades do projeto devido à baixa complexidade do sistema proposto aliado ao fato dos requisitos serem bem definidos e pouco variáveis. 6.2 Especificação de Requisitos Segundo [43], a especificação de requisitos busca compreender o problema e levantar todas as necessidades do futuro sistema a ser desenvolvido. Esta seção foi desenvolvida usando a técnica de modelagem de casos de uso apresentando os diagramas de caso de uso, descrição dos casos de usos identificados e o mini-mundo, sendo este uma breve descrição do domínio do problema.

53 Descrição do Mini-Mundo O gestor da clínica necessita fazer um controle de seus funcionários e para isso deseja armazenar os dados como nome do funcionário, data de nascimento, telefone residencial, telefone celular, endereço, e a função exercida. Além disso, precisa controlar seus parceiros mantendo seus dados armazenados como razão social, nome fantasia, CNPJ, telefone, fax, endereço e contatos. A clínica também necessita de um controle de seus clientes e, portanto deseja guardar o nome do cliente, data de nascimento, telefone residencial, telefone comercial, telefone celular, endereço e . Para melhor organizar os atendimentos aos clientes será necessário um agendamento de consultas e, para tal objetivo, será preciso conhecer o nome do cliente, o telefone, o horário e a data da realização da consulta. Dessa maneira, complementando a necessidade citada acima, a clínica necessita visualizar uma agenda com as consultas marcadas exibindo os horários e pacientes envolvidos. Além disso, é preciso gerar um relatório de consultas e pacientes, como uma forma de agregação de informações para controle e possíveis tomadas de decisões estratégicas. O relatório de consultas deve mostrar as consultas com suas respectivas datas e horários, procedimento realizado e nome do paciente. No relatório de pacientes, devem ser mostradas informações a respeito do mesmo como nome, telefone e endereço. O gestor também requer um controle do seu financeiro. Para isso, precisa registrar os pagamentos de consultas dos clientes e visualizar um relatório contendo os valores pagos mensalmente. A clínica necessita dispor uma forma de acesso para os clientes. Desta maneira, os clientes devem poder visualizar suas consultas contendo as informações sobre a data e horário marcados. Além disso, como uma alternativa ao agendamento convencional efetuado por telefone, devem poder sugerir o agendamento de consultas à clínica enviando as datas e horários disponíveis para a marcação. Como forma de controlar seus pagamentos, os clientes também precisam visualizar seu financeiro onde serão mostrados os tratamentos atuais e um histórico dos pagamentos das parcelas referentes a eles. Além disso, os clientes precisam visualizar seu correio de mensagens onde serão recebidas mensagens enviadas pela clinica.

54 Modelo de Casos de Uso Segundo [43], o modelo de caso de uso é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com ele. O sistema proposto foi subdividido em diagramas de pacotes que tem como propósito prover uma visão de nível mais alto do sistema mostrando sua decomposição em subsistemas, como mostrado na figura 15. Figura 15: Diagrama de Pacotes O sistema foi dividido em dois pacotes como uma forma de separar os elementos relacionados ao Cliente dos relacionados à Clínica. A divisão auxilia numa melhor compreensão do domínio do problema, na reutilização de componentes e também podendo ser tratados de forma separada na fase de projeto. Pacote Cliente: contém todas as funcionalidades que serão utilizadas pelo cliente. Pacote Clínica: contém todas as funcionalidades que serão utilizadas pela clínica Diagramas de Casos de Uso Segundo [43], um diagrama de caso de uso representa graficamente os atores, casos de uso e relacionamentos entre esses elementos e tem o objetivo de ilustrar quais elementos externos interagem com que funcionalidades do sistema. As figuras 16 e 17 ilustram os diagramas de casos de uso referentes aos pacotes Cliente e Clínica.

55 54 Figura 16: Diagrama de Caso de Uso do Pacote Cliente Figura 17: Diagrama de Caso de Uso do Pacote Clínica Descrição dos Casos de Uso Nesta seção os casos de uso de maior relevância, mostrados nos diagramas da seção 6.1.3, são descritos.

56 Visualizar Consultas Sumário: Ator usa o sistema para visualizar todas as suas consultas marcadas. Ator: Cliente. Precondições: O ator estar identificado no sistema. Fluxo Principal: 1. O ator solicita ao sistema a visualização de suas consultas agendadas. 2. O sistema exibe as consultas com suas datas e horários e o caso de uso termina Sugerir Consultas Sumário: Ator envia sugestão de data e horário para agendamento de uma nova consulta. Ator: Cliente. Precondições: O ator estar identificado no sistema. Fluxo Principal: 1. O ator solicita ao sistema os horários livres da semana para agendamento de consulta. 2. O sistema exibe as datas e horários disponíveis para uma nova consulta. 3. O ator seleciona o dia e o horário desejado. 4. O sistema armazena as informações e o caso de uso termina Visualizar Correio Sumário: Ator visualiza seu correio contendo as mensagens enviadas pela clínica. Ator: Cliente. Precondições: O ator estar identificado no sistema. Fluxo Principal: 1. O ator solicita ao sistema a visualização do seu correio. 2. O sistema exibe a lista de mensagens existentes com seus respectivos títulos. 3. O ator seleciona a mensagem que deseja visualizar.

57 56 4. O sistema exibe o conteúdo da mensagem escolhida e o caso de uso termina. Fluxo Alternativo (2) Excluir Mensagem: 1. O ator seleciona a mensagem que deseja excluir. 2. O sistema exclui a mensagem e volta ao passo Agendar Consulta Sumário: Ator agenda consulta para um cliente no sistema. Ator: Funcionário/Dentista Precondições: Ator estar identificado no sistema o cliente estar cadastrado no sistema. Fluxo Principal: 1. O ator informa data e hora livres para agendamento e o nome do cliente que deseja marcar a consulta. 2. O sistema armazena as informações sobre a consulta. 3. O sistema envia mensagem de confirmação e caso de uso termina. Pos-condições: A consulta desejada foi efetuada no sistema Visualizar Agenda Sumário: Ator visualiza todas as consultas que serão realizadas no dia. Ator: Funcionário/Dentista. Precondições: O ator estar identificado no sistema. Fluxo Principal: 1. O ator solicita ao sistema a visualização das consultas do dia. 2. O sistema retorna a lista das consultas do dia com os horários e clientes envolvidos e o caso de uso termina. Fluxo Alternativo (2) Cancelar consulta:

58 57 1. O ator seleciona a consulta que deseja cancelar. 2. O sistema cancela a consulta. 3. O sistema envia uma mensagem informando o cliente sobre o cancelamento e retorna ao passo 2. Pos-condições: As consultas solicitadas foram exibidas e podem ou não terem sido excluídas Emitir Relatório de Consultas Sumário: Ator visualiza todas as consultas que serão realizadas no dia. Ator: Funcionário/Dentista. Precondições: O ator estar identificado no sistema. Fluxo Principal: 1. O ator solicita ao sistema a visualização do relatório de consultas agendadas em um determinado intervalo de data. 2. O sistema retorna a lista das consultas com os horários e clientes envolvidos. Fluxo Alternativo (1) Visualizar consultas sugeridas: 1. O ator solicita ao sistema a visualização do relatório de consultas sugeridas em um determinado intervalo de data. 2. O sistema retorna a lista das consultas com os horários e clientes envolvidos. Fluxo Alternativo (1) Visualizar consultas canceladas 1. O ator solicita ao sistema a visualização do relatório de consultas canceladas em um determinado intervalo de data. 2. O sistema retorna a lista das consultas com os horários e clientes envolvidos. Pos-condições: As consultas solicitadas foram exibidas.

59 Especificação de Análise Segundo [43], a análise corresponde à fase onde é realizado um estudo detalhado dos requisitos levantados e então construídos modelos que representam o sistema e no sistema proposto será utilizada a abordagem da Análise Orientada a Objetos. Esta seção será dividida em três partes: Diagramas de Classes, Diagramas de Estados e Diagramas de Seqüências Diagrama de Classes Segundo [43], o diagrama de classes representa a estrutura das classes de objetos do sistema e suas relações. As figuras 18 e 19 ilustram os diagramas de classes dos pacotes Cliente e Clínica. Figura 18: Diagrama de Classes do Pacote Cliente

60 59 Figura 19: Diagrama de Classes do Pacote Clínica Diagrama de Estados Segundo [44], o diagrama de estado mostra os estados e as transições que o objeto de uma determinada classe pode assumir. As figuras 20, 21 e 22 ilustram o diagrama de estados das classes Cheque, Parcela e Consulta. Figura 20: Diagrama de Estados da Classe Cheque

61 60 Figura 21: Diagrama de Estados da Classe Parcela Figura 22: Diagrama de Estados da Classe Consulta Diagrama de Seqüência Segundo [44], o diagrama de seqüência define a interação entre objetos e enfatiza mais a seqüência temporal que os relacionamentos estáticos do objeto. As figuras 23, 24, 25, 26, 27 e 28 ilustram os diagramas de seqüência dos casos de usos descritos na seção

62 61 Figura 23: Diagrama de Seqüência do Caso de Uso Visualizar Consulta Figura 24: Diagrama de Seqüência do Caso de Uso Sugerir Consulta Figura 25: Diagrama de Seqüência do Caso de Uso Visualizar Correio

63 62 Figura 26: Diagrama de Seqüência do Caso de Uso Visualizar Agenda Figura 27: Diagrama de Seqüência do Caso de Uso Agendar Consulta Figura 28: Diagrama de Seqüência do Caso de Uso Emitir Relatório de Consultas

64 Especificação de Projeto Esta seção contém a Especificação de Projeto para o sistema MobOdonto. Esta seção foi divida em seis partes. A primeira parte apresenta a uma visão das tecnologias utilizadas pelo sistema. A segunda parte apresenta a arquitetura do sistema e sua divisão em camadas, além da discussão sobre cada uma delas e seus respectivos diagramas de classe. A terceira apresenta o pacote utilizado para reusabilidade de componentes no sistema. A quarta parte apresenta os diagramas de seqüências revisados para a fase de projeto. A quinta parte apresenta o projeto de interface com usuário onde serão apresentados ícones, cores e mensagens utilizados no sistema. A última parte mostra os diagramas de componente e implantação Tipo de Aplicação, Plataformas de Implementação, Tecnologias de Apoio e Hardware O MobOdonto será um aplicativo ambiente WEB com alguns módulos que serão executados a partir de dispositivos móveis. As funcionalidades discutidas na especificação de análise Visualizar Correio, Visualizar Consultas e Sugerir Consultas, pertencentes ao pacote Cliente, serão implementadas em WAP e a funcionalidade Visualizar Agenda do pacote Clínica em JME. Essas implementações terão como apoio as tecnologias apresentadas na tabela 2 abaixo. Tecnologia Solução Linguagem de Programação Java Linguagem de Marcação XHTML, XHTML-MP SGBD MySQL 5.0 Tecnologias Auxiliares Ajax Tabela 2: Tecnologias Para que o sistema funcione de maneira eficiente são necessários alguns requisitos de hardware e software. Abaixo são exibidas as tabelas que mostram todos os requisitos que devem ser obedecidos para tal.

65 64 HardwareSoftware Requisito Processador x86 Memória RAM 512MB Servidor Web Apache 2.2 Servidor de Aplicação Java GlassFish v2 Tabela 3: Requisitos para o módulo Web Tecnologia Compatibilidade WAP WAP 2.0 JME Nenhuma mensagem Tabela 4: Requisitos para módulo Móvel Framework Ajax Para fins de melhorias nas requisições e respostas feitas pelas páginas Web ao servidor, foi desenvolvido um framework Ajax de pequeno porte que viabiliza essa melhoria. Como conseqüência, a aplicação estará se livrando de recargas de páginas inteiras quando se pressiona um botão ou se digita um valor tornando-se, assim, em um aplicativo mais rápido fazendo o usuário sentir-se como se estivesse trabalhando em um sistema desktop dinâmico. Além de eliminar as incômodas recargas de páginas, o JavaScript do framework se comunica com o servidor Web assincronamente. Em outras palavras, o código JavaScript fará uma solicitação ao servidor, mas o usuário poderá inserir dados em formulários Web e até mesmo clicar em botões - tudo isso enquanto o servidor Web estiver trabalhando em segundo plano. Em seguida, quando o servidor tiver terminado o processo, o framework dará suporte para atualizar apenas a parte da página que requer mudanças. Assim, o framework combina o poder das solicitações assíncronas com a atualização de páginas sem recargas tendo um aplicativo Web responsivo e dinâmico.assim como mostra a figura 29, o framework envia as solicitações, independente do navegador de Internet, via JavaScript para o servidor e sua resposta só terá os dados que a página precisa, sem qualquer marcação ou apresentação.

66 65 Figura 29: Comunicação entre as páginas Web e o servidor A comunicação entre as páginas Web e o servidor é realizada com uso do formato JSON (Javascript Object Notation), que, em linhas gerais, é construído com base em uma coleção de pares chave/valor que definem propriedades e seus valores e, que é uma alternativa ao tradicional XML (extensible Markup Language). Segundo [45], para enviar informações entre uma página Web e um servidor, precisará de alguma maneira de formatá-las sendo o JSON uma maneira de enviar e retornar dados e sua escolha dada pela complexidade do aplicativo e pela equipe de desenvolvedores. Assim, foi adotado o formato JSON por apresentar maior facilidade de montagem dos pacotes de dados em relação ao formato XML. A atualização das páginas Web é realizada utilizando o HTML DOM (Document Object Model) que é um padrão W3C (World Wide Web Consortium). Segundo [46], o HTML DOM define um conjunto padrão de objetos de HTML, e uma forma padrão de acessar e manipular documentos HTML. Todos os elementos HTML, juntamente com os seus atributos, podem ser acessados através do DOM. O conteúdo pode ser alterado ou suprimido, e novos elementos podem ser criados, independente da plataforma SSL e Certificado Digital Visando maior segurança no tráfego das informações entre as páginas Web, as informações serão criptografadas por certificados digitais SSL (Secure Sockets Layer). Segundo [47], SSL é uma tecnologia de segurança que é comumente utilizada para codificar os dados trafegados entre o computador do usuário e um site da Internet. O protocolo SSL, através de um processo de criptografia dos dados, previne que os dados trafegados possam ser capturados, ou mesmo alterados no seu curso en-

67 66 tre o navegador (browser) do usuário e o site com o qual ele está se relacionando, garantindo desta forma que informações sigilosas possam ser trafegadas com segurança. Segundo [48], O certificado digital é um documento eletrônico que tem como aspecto principal duas chaves: uma pública, que é de conhecimento geral, e outra privada, que deve ser mantida em sigilo e com toda a segurança pelo titular do certificado. Esse par de chaves tem uma série de características importantes. Primeiramente, a tecnologia utilizada na geração dessas chaves é a chamada "criptografia assimétrica", que é o método mais comum para autenticar transações conduzidas pela Internet. Em segundo lugar, embora elas sejam matematicamente relacionadas, é impossível calcular uma chave a partir da outra. Daí, a denominação de "assimétricas". Terceiro, uma chave desempenha a função inversa da outra: o que uma delas faz, somente a outra pode desfazer. Por exemplo, a chave privada é usada para assinar o conteúdo de um documento, enquanto a chave pública é usada para validar essa assinatura. O certificado digital é obtido de uma autoridade certificadora e contém o nome do titular (pessoa física ou jurídica), o número de série, a data da sua validade, a chave pública do titular e a assinatura (eletrônica) da Autoridade Certificadora, que garante o próprio certificado. Ou seja, devido aos certificados digitais, uma transação eletrônica realizada via internet torna-se mais segura, pois permite que as partes envolvidas apresentem cada uma, as suas credenciais para comprovar, à outra parte, a sua real identidade Arquitetura do Sistema A figura 30 ilustra a arquitetura do sistema utilizando divisão em pacotes. O diagrama de pacotes é o mesmo ilustrado na especificação de análise com a única diferença de que foi inserido o novo pacote Utilitário que ajudará na reutilização de componentes no sistema proposto e em outros contextos. As dependências entre os pacotes também são as mesmas com diferença de que os pacotes Cliente e Clínica fazem requisição de serviços para o novo pacote incorporado ao diagrama.

68 Arquitetura em Camadas Figura 30: Arquitetura do Sistema Os pacotes Clínica e Cliente, ilustrados na figura 30, foram decompostos em novos pacotes sendo eles: Domínio do Problema (DP), Gerência de Tarefas (GT), Gerência de Dados (GD) e Interface com o Usuário (IU) de acordo com o modelo MVC Estendido [49] e tendo suas classes identificadas por estereótipos. Essa abordagem deu origem a novos diagramas de pacotes, ilustrados nas figuras 31 e 32, e que o conteúdo destes serão discutido nas próximas subseções. Figura 31: Arquitetura em Camadas do Pacote Cliente

69 68 Figura 32: Arquitetura em Camadas do Pacote Clinica A dependência entre os pacotes, ilustrados nas figuras 31 e 32, mostram a requisição de serviços para realização das funcionalidades do sistema. Esta divisão em pacotes foi baseada usando o padrão arquitetural MVC Estendido que tem como objetivo criar uma independência e divisão de responsabilidades entre as partes que envolvem o sistema. Desta forma obtêm-se uma maior coesão entre as classes do sistema facilitando possíveis mudanças em qualquer uma das camadas Domínio do Problema (DP) O pacote de domínio do problema é o local onde estão contidas as classes, suas multiplicidades e associações que modelam o domínio do problema. As figuras 33 e 34 apresentam o diagrama de classes do domínio do problema DP_Cliente e DP_Clínica sendo relativos aos pacotes Cliente e Clínica, respectivamente.

70 Figura 33: Diagrama de Classes do Pacote DP_Cliente 69

71 70 Figura 34: Diagrama de Classes do Pacote DP_Clínica Considerações A modelagem de classes para o contexto de endereço pode ser construída de várias maneiras, mas, preferencialmente, deve ser passível de atualização com a base dos Correios. As atualizações são realizadas freqüentemente e uma possível modelagem seria essa como apresentada na figura 35. Figura 35: Modelo baseado na escolha do endereço O modelo acima apresenta algumas características como: É necessária a escolha do endereço manualmente bem como a inserção dos

72 71 dados referentes à classe Complemento e os dados referentes ao CEP são buscados automaticamente; Caso um número de CEP ou endereço não existam, estes poderão ser cadastrados na base Evita dados redundantes entre Endereço e Complemento, pois um endereço pode ou não possuir um complemento associado. Diferente se os campos da classe Complemento estivessem na classe Endereço, neste caso, existiriam dados nulos ou redundantes; Eficiência por busca de dados pode ser comprometida por conseqüência da complexidade da estrutura; Apresenta problemas em uma atualização da base disponibilizada pelos Correios. Os números de CEP cadastrados manualmente podem ser sobrescritos ou não pelos novos. Outra forma de modelagem dessa estrutura é a mostrada na figura 36. Figura 36: Modelo baseado na escolha do endereço e CEP Este modelo apresenta algumas características como: São necessárias as escolhas do número do CEP e do Endereço manualmente bem como a inserção dos dados referentes à classe Complemento; Caso um número de CEP ou endereço não existam, estes poderão ser cadastrados na base Evita dados redundantes entre Endereço e Complemento, pois um endereço pode ou não possuir um complemento associado. Diferente se os campos da classe Complemento estivessem na classe Endereço, neste caso, existiriam dados nulos ou redundantes;

73 72 Eficiência por busca de dados pode ser comprometida por conseqüência da complexidade da estrutura; Apresenta problemas em uma atualização da base disponibilizada pelos Correios. Os números de CEP cadastrados manualmente podem ser sobrescritos ou não pelos novos. Após estudos realizados, a modelagem que apresentou mais eficiência com atualizações e respostas às buscas é mostrado na figura 37. Figura 37: Modelo baseado na escolha do CEP Este modelo apresenta algumas características como: É necessária apenas a escolha do número do CEP. Os dados referentes às classes de Cidade, Bairro e CEP são armazenados na classe Cliente; A redundância dos dados, nas classes Funcionário e Cliente, têm por finalidade deixar a base de CEP atualizada de acordo com a fornecida pelos Correios. Assim, atualizações fornecidas pelo órgão podem ser realizadas sem comprometimento dos dados já utilizados; Caso um número de CEP não exista, os novos dados podem ser cadastrados na classe Cliente deixando a base de acordo com a fornecida pelos Correios; Alta eficiência na busca de dados por conseqüência da complexidade da estrutura. Visando a segurança da informação existem algumas classes especializadas para tratamento de controle de acesso e de auditoria. As figuras 38 e 39 mostram essas classes, respectivamente.

74 73 Figura 38: Permissão de acesso Figura 39: Classe responsável pela auditoria Uma forma de proteção contra divulgação indevida de informações é fazer uso do controle de acesso dos usuários às funcionalidades do sistema. Como mostra a figura 38, as classes de Rotina, de Função e de Permissão fazem o controle de todos os acessos às funcionalidades para cada grupo de acesso. Desta forma, é possível controlar o conteúdo que cada grupo terá acesso com facilidade de manutenção dessas regras. Uma prática comum de segurança em sistemas de informação é a adoção de auditoria que, no sistema proposto, consiste em armazenar as alterações feitas pelo usuário nos dados do sistema. Como ilustra a figura 39, a classe Auditoria armazena dados como o nome da tabela da base de dados em que ocorreu a alteração bem como o tipo de funcionalidade que foi acessada - inclusão, alteração ou exclusão. A classe guarda ainda a descrição dos dados alterados, o horário que o evento ocorreu e o usuário que realizou o acesso através de seu código atribuído pela classe Token. Classe essa responsável por armazenar o código do usuário e o seu horário de entrada no sistema. A auditoria pode ser implantada em funcionalidades que forem necessárias e por determinadas ações. A classe Tabela, como mostra a figura 40, tem a especialidade de controlar o último código da chave primária de cada tabela do banco de dados, bem como sinalizar qual método será auditado, ou seja, qual dentre os métodos de incluir, alterar e excluir a auditoria armazenará informações.

75 74 Figura 40: Classe Tabela Gerência de Tarefas (GT) No pacote de gerência de tarefas estão as classes que lidam com as regras de negócio do sistema. As figuras 41 e 42 apresentam as classes para os pacotes GT_Cliente e GT_Clínica respectivamente. Figura 41: Diagrama de Classe do Pacote GT_Cliente Figura 42: Diagrama de Classe do Pacote GT_Clinica Padrão de Projeto Facade Nos diagramas mostrados nas figuras acima, foi utilizado o padrão de projeto Facade. Segundo [50], o padrão Facade busca simplificar o uso de um sistema complexo definindo uma interface especializada e simples, reduzindo o número de objetos com os quais o objeto cliente deve lidar. Seu uso reduz problemas futuros na manutenção da aplicação, uma vez que o cliente terá apenas a visão da classe responsável pela implementação do Facade, não sofrendo impacto por possíveis alterações nas classes de controle. Abaixo são exibidos dois diagramas onde a figura 43[50] representa um

76 75 diagrama onde não é utilizado o padrão e a figura 44[50] outro em que é incluído seu uso. Figura 43: Exemplo de diagrama sem o uso do padrão Facade Figura 44: Exemplo de diagrama usando o padrão Facade Como resultado de estudo do padrão de projeto facade, os diagramas ilustrados nas figuras 41 e 42 foram reformulados para contemplar a utilização deste padrão. As figuras 45 e 46 ilustram respectivamente os diagramas de classe dos pacotes GT_Cliente e GT_Clinica. Figura 45: Diagrama de Classe do Pacote GT_Cliente reformulado

77 76 Figura 46: Diagrama de Classe do Pacote GT_Clinica reformulado Gerência de Dados (GD) No pacote gerência de dados estão as classes responsáveis por realizarem a persistência das informações do sistema em um banco de dados. Figura 47: Diagrama de Classe do Pacote GD_Cliente

78 77 Figura 48: Diagrama de Classe do Pacote GD_Clínica Padrão de Projeto Singleton O padrão de projeto Singleton tem como objetivo garantir a existência de apenas uma instância de uma determinada classe em qualquer ponto do sistema [51]. Baseado nesta definição, o padrão foi adotado para evitar a criação desnecessária de objetos, pois a cada conexão realizada com o banco de dados um objeto diferente era criado causando desperdício de memória. Como resultado de estudo do padrão de projeto Singleton, os diagramas ilustrados nas figuras 47 e 48 foram reformulados para contemplar a utilização deste padrão. As figuras 49 e 50 ilustram respectivamente os diagramas de classe dos pacotes GD_Cliente e GD_Clinica. Figura 49: Diagrama de Classe do Pacote GD_Cliente reformulado

79 78 Figura 50: Diagrama de Classe do Pacote GD_Clínica reformulado Modelo de Entidade e Relacionamento (MER) O sistema MobOdonto utilizará um banco de dados relacional para a persistência de dados e, assim, foi necessário realizar o mapeamento Objeto-Relacional. O Modelo de Entidade e Relacionamento foi dividido em duas figuras para melhor interpretação de seu conteúdo. As figuras 51 e 52 ilustram o modelo de entidade e relacionamento. Para a criação do MER mencionado foi utilizada a ferramenta DBDesigner 4.

80 Figura 51: Modelo de Entidade e Relacionamento (MER): Parte A 79

81 Figura 52: Modelo de Entidade e Relacionamento (MER): Parte B 80

82 Interface com Usuário (IU) As figuras 53 e 54, respectivamente, apresentam os diagramas de classes referentes ao componente de Interface com o Usuário do pacote Clínica e Cliente. Figura 53: Diagrama de Classe do Pacote IU_Cliente Figura 54: Diagrama de Classe do Pacote IU_Clínica Pacote Utilitários Este pacote contém as classes e pacotes comuns aos pacotes Cliente e Clínica e serão descritos a seguir de forma breve Banco Contém a classe cheque para tratar da manipulação de cheques. A figura 55 apresenta o pacote Banco.

83 82 Figura 55: Diagrama de Classe do Pacote Banco Apesar de este pacote possuir apenas uma classe, novas classes podem ser incorporadas para contemplarem outros contextos em outras aplicações Login O pacote Login contém todas as classes que tratam os aspectos relacionados à segurança dentro do sistema. Figura 56: Diagrama de Classe do Pacote Login

84 Pessoa O pacote Pessoa contém as classes para tratar as informações relacionadas ao endereço de uma pessoa. Figura 57: Diagrama de Classe do Pacote Pessoa DAO O pacote DAO contém as classes reutilizáveis que são responsáveis pela persistência de dados e auxiliam a execução de tarefas na camada de Gerencia de Dados dos pacotes Cliente e Clinica. A figura 58 ilustra o diagrama de classe para o pacote DAO. Figura 58: Pacote Utilitário DAO Diagrama de Seqüência Os diagramas de seqüência apresentados na especificação de análise foram reformulados para contemplar a arquitetura em camadas proposta na seção deste

85 84 documento. Os diagramas para os casos de uso Sugerir Consulta, Visualizar Consulta e Visualizar Correio do pacote Cliente e o caso de uso Visualizar Agenda, Agendar Consulta e Emitir Relatório de Consultas do pacote Clínica serão apresentados respectivamente nas figuras 59, 60, 61, 62, 63 e 64. Figura 59: Diagrama de Seqüência do Caso de Uso Visualizar Consulta Figura 60: Diagrama de Seqüência do Caso de Uso Sugerir Consulta Figura 61: Diagrama de Seqüência do Caso de Uso Visualizar Correio

86 85 Figura 62: Diagrama de Seqüência do Caso de Uso Visualizar Agenda Figura 63: Diagrama de Seqüência do Caso de Uso Agendar Consulta Figura 64: Diagrama de Seqüência do Caso de Uso Emitir Relatório de Consultas Padrões de Interface Para auxiliar a usabilidade do sistema por parte do usuário, textos, ícones, cores e mensagem podem ser utilizados. Esta seção mostrará os itens, citados anteriormente, que serão utilizados no sistema proposto. Esta seção foi dividida em três partes sendo elas: Ícones, Cores e Mensagem.

87 Ícones Para auxiliar na navegabilidade e identificação de funcionalidades presentes no sistema, a figura 65 mostra os ícones utilizados e suas respectivas funcionalidades as que estão relacionados. Figura 65: Ícones Cores Para que o usuário esteja alerta e tenha facilidade de leitura sobre os dados apresentados no sistema, a tabela 5 mostra uma lista de cores e suas respectivas funcionalidades utilizadas no desenvolvimento do sistema. Item Código Hexadecimal Mensagens de alerta FF0000 Texto padrão Plano de fundo FFFFFF Hiperlink FFFFFF Hiperlink visitado 0000CC Tabela 5: Cores As cores mostradas na tabela acima estão utilizando o padrão de cores no formato RGB Mensagens O usuário precisa estar ciente de que todas suas funcionalidades foram executadas e também se toda informação apresentada, persistida, excluída e alteradas obtiveram sucesso ou insucesso em suas execuções no sistema. A tabela 6 apresenta as mensagens utilizadas.

88 87 Ação Visualizar Mensagem Visualizar Mensagem Acesso ao Banco de Dados Excluir Mensagem Excluir Mensagem Visualizar Agenda Visualizar Agenda Mensagem Erro ao exibir mensagem Nenhuma mensagem Erro ao acessar banco de dados Mensagem excluída com sucesso Erro ao excluir mensagem Erro ao exibir agenda Nenhuma consulta agendada Tabela 6: Mensagens do Sistema Diagrama de Navegabilidade Segundo [52], o diagrama de navegabilidade mostra a navegação entre as diferentes funcionalidades do sistema, isto é, apresenta a seqüência em que as telas ou janelas do sistema podem ser navegadas pelo usuário para o mesmo realize as funcionalidades representadas pelos casos de uso definidos para cada pacote do sistema. A figura 66 apresenta o diagrama para o pacote Cliente e a figura 67 para o pacote Clínica. Figura 66: Diagrama de Navegabilidade do Pacote Cliente

89 88 Figura 67: Diagrama de Navegabilidade do Pacote Clínica Aspectos de Usabilidade e Eficiência Segundo [53], os aspectos referentes à usabilidade são definidos para mostrar a relação de interação entre o usuário e o sistema mostrando os níveis de efetividade, satisfação, facilidade de uso e aprendizado do sistema desenvolvido. Devido às várias limitações provenientes da utilização dos dispositivos móveis, o sistema procura empregar o uso de boas práticas que auxiliem usabilidade. Todos os componentes buscam ser objetivos procurando diminuir o esforço necessário para realizar determinada tarefa e todas as ações do sistema possuem nomes diretos e sugestivos para uma maior compreensão do que será feito quando o mesmo for acionado evitando um tempo maior na resposta e na realização da tarefa desejada pelo usuário. As tabelas 7 e 8, mostram as estimativas de eficiência relacionadas ao tempo de resposta dos casos de uso dos pacotes Cliente e Clínica.

90 89 Caso de Uso Freqüência de Utilização Tempo Máximo Esperado Visualizar correio 10dia 5 segundos Visualizar consultas 50dia 5 segundos Sugerir consultas 5mês 3 segundos Tabela 7: Eficiência dos Casos de Uso do Pacote Cliente Caso de Uso Freqüência de Utilização Tempo Máximo Esperado Visualizar agenda 5dia 3 segundos Agendar consulta 10dia 5 segundos Emitir relatório de 3mês 10 segundos consultas Tabela 8: Eficiência dos Casos de Uso do Pacote Clinica Diagrama de Componentes Segundo [43], o diagrama de componentes mostra os vários componentes de software do sistema e suas respectivas dependências. Cada componente possui elementos que definem uma funcionalidade dentro do sistema visando à reutilização. A figura 68 ilustra o diagrama de componentes do sistema. Figura 68: Diagrama de Componentes do Sistema MobOdonto Diagrama de Implantação Segundo [43], o diagrama de implantação representa a topologia física do sistema e, opcionalmente, os componentes que são executados nela. Através deste diagrama é possível ter uma visão da estrutura necessária para implantação do sistema.

91 90 Figura 69: Diagrama de Implantação do Sistema MobOdonto Protótipo Nesta seção serão apresentados os protótipos das telas do sistema MobOdonto contemplando as funcionalidades escolhidas e estudas para o cumprimento dos objetivos discutidos na seção 3 deste documento. Para a versão WAP, as figuras 70, 71, 72 ilustram as telas para as respectivas as funcionalidades: Login, Visualizar Correio, Visualizar Consultas. As figuras 73 e 74 ilustram a funcionalidade Sugerir Consulta. A tela principal que dá acesso a essas funcionalidades é ilustrada na figura 74. As figuras foram feitas com auxílio do simulador WAP Proof. A figura 71 ilustra a utilização de abreviação de informação devido à resolução do aparelho simulado. Figura 70: Funcionalidade Login

92 91 Figura 71: Funcionalidade Visualizar Correio Figura 72: Funcionalidade Visualizar Consultas Figura 73: Funcionalidade Sugerir Consultas: Escolha do dia da semana Figura 74: Funcionalidade Sugerir Consultas: Escolha do horário disponível

93 92 Figura 75: Tela principal Para a versão JME, as figuras 76, 77, 78 ilustram as telas para a funcionalidade de Visualizar Consultas. A tela principal que dá acesso a essa funcionalidade é ilustrada na figura 76. Todas as figuras foram feitas com auxílio da IDE Eclipse utilizando o emulador disponível no JME SDK 3.0. Figura 76: Tela principal para seleção da funcionalidade Figura 77: Funcionalidade Visualizar Consultas: Escolha do horário

94 93 Figura 78: Funcionalidade Visualizar Consultas: Visualizando dados do cliente Para a versão Web, as figuras 79 e 80 ilustram as telas para as respectivas as funcionalidades: Login e Visualizar Consultas. Todas as figuras foram feitas com auxílio do software Macromedia Dreamweaver 8. Figura 79: Funcionalidade Login Figura 80: Funcionalidade Visualizar Consultas

95 Estrutura de Sistema O sistema discutido neste documento utiliza três tecnologias distintas para apresentar suas informações geradas ao usuário. Os módulos propostos WEB, WAP e JME utilizam respectivamente JSON, HTML e XML para representação dessas informações. Neste contexto foi identificada a necessidade do desenvolvimento de um componente (wrapper), que possui a responsabilidade na identificação, interpretação, conversão e o envio das informações que devem ser apresentadas em cada um dos módulos mencionados, como sendo a solução para a situação. A figura 81 ilustra o diagrama de classe para ilustrar este componente. Figura 81: Componente Wrapper É importante ressaltar que mais classes(wrappers) podem ser adicionadas tornando assim o sistema mais robusto. Aplicando o que foi discutido no início nesta seção até agora, temos a figura 82 ilustrando a integração do novo componente no sistema proposto e em seguida é descrito seu funcionamento.

96 95 Figura 82: Estrutura do Sistema O funcionamento dá-se da seguinte forma: a partir de um dos módulos é feita a requisição ao sistema para realização de determinada tarefa. Estas requisições são centralizadas em uma Servlet que as recebe e de acordo com o que foi solicitado, redireciona para a camada de controle que contém a implementação correta do padrão Facade para que o sistema que realiza a tarefa. O resultado da requisição feita por um dos módulos é então retornada para a Servlet que identifica de qual módulo originouse a requisição acionando assim a respectivo wrappers (empacotador) para realizar o tratamento dos dados resultantes da requisição para que o módulo apresente as informações ao usuário.