pesquisa e desenvolvimento para … e desenvolvimento... · satsa security and trust services api...
TRANSCRIPT
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
IGOR DA COSTA ROCHA ELIAS
JURANDIR LUCHINI VICTOR
MARCOS ANTONIO RAMPINELLI
PESQUISA E DESENVOLVIMENTO PARA
DISPOSITIVOS MÓVEIS
Trabalho de Conclusão de Curso apresen-tado ao Centro Univertário Vila Velha comorequisito parcial para a obtenção do graude Bacharel em Ciência da Computação.Orientador: Cristiano Biancardi
VILA VELHA
2009
IGOR DA COSTA ROCHA ELIAS
JURANDIR LUCHINI VICTOR
MARCOS ANTONIO RAMPINELLI
PESQUISA E DESENVOLVIMENTO PARA
DISPOSITIVOS MÓVEIS
BANCA EXAMINADORA
Prof. Msc. Cristiano BiancardiCentro Universitário Vila VelhaOrientador
Prof. Msc. Renato Elias N. deMoraesCentro Universitário Vila Velha
Prof. Msc. Sandro Tonini da SilvaCentro Universitário Vila Velha
Trabalho de Conclusão de Curso
aprovado em 04/06/2009.
Aos nossos pais e amigos...
AGRADECIMENTOS
Agradecemos a Deus, nossas famílias , familiares, namoradas, amigos, colegas, o
orientador e a banca examinadora.
“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
LISTA DE TABELAS
1 Comparação WAP x JME . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2 Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3 Requisitos para o módulo Web . . . . . . . . . . . . . . . . . . . . . . . 64
4 Requisitos para módulo Móvel . . . . . . . . . . . . . . . . . . . . . . . 64
5 Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6 Mensagens do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7 Eficiência dos Casos de Uso do Pacote Cliente . . . . . . . . . . . . . . 89
8 Eficiência dos Casos de Uso do Pacote Clinica . . . . . . . . . . . . . . 89
LISTA DE FIGURAS
1 Comparação entre o número de celulares e computadores no mundo . 21
2 Projeções para a internet móvel no mundo . . . . . . . . . . . . . . . . 22
3 Comparação entre WAP e Internet quando usado para acessar a Web . 27
4 Cliente WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5 Uso do Gateway WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6 Gateway WAP e elementos da rede sem fio . . . . . . . . . . . . . . . . 29
7 Gateway do proxy WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8 Codificador / Decodificador do Gateway WAP . . . . . . . . . . . . . . . 31
9 Pilha de Protocolos WAP . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10 Plataforma Java e suas edições . . . . . . . . . . . . . . . . . . . . . . 37
11 JME e seus componentes . . . . . . . . . . . . . . . . . . . . . . . . . . 38
12 JME dividida em camadas . . . . . . . . . . . . . . . . . . . . . . . . . . 39
13 Configurações do JME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14 Relacionamento entre as diferentes implementações do GCF . . . . . . 42
15 Diagrama de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
16 Diagrama de Caso de Uso do Pacote Cliente . . . . . . . . . . . . . . . 54
17 Diagrama de Caso de Uso do Pacote Clínica . . . . . . . . . . . . . . . 54
18 Diagrama de Classes do Pacote Cliente . . . . . . . . . . . . . . . . . . 58
19 Diagrama de Classes do Pacote Clínica . . . . . . . . . . . . . . . . . . 59
20 Diagrama de Estados da Classe Cheque . . . . . . . . . . . . . . . . . 59
21 Diagrama de Estados da Classe Parcela . . . . . . . . . . . . . . . . . . 60
22 Diagrama de Estados da Classe Consulta . . . . . . . . . . . . . . . . . 60
23 Diagrama de Seqüência do Caso de Uso Visualizar Consulta . . . . . . 61
24 Diagrama de Seqüência do Caso de Uso Sugerir Consulta . . . . . . . 61
25 Diagrama de Seqüência do Caso de Uso Visualizar Correio . . . . . . . 61
26 Diagrama de Seqüência do Caso de Uso Visualizar Agenda . . . . . . . 62
27 Diagrama de Seqüência do Caso de Uso Agendar Consulta . . . . . . . 62
28 Diagrama de Seqüência do Caso de Uso Emitir Relatório de Consultas 62
29 Comunicação entre as páginas Web e o servidor . . . . . . . . . . . . . 65
30 Arquitetura do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
31 Arquitetura em Camadas do Pacote Cliente . . . . . . . . . . . . . . . . 67
32 Arquitetura em Camadas do Pacote Clinica . . . . . . . . . . . . . . . . 68
33 Diagrama de Classes do Pacote DP_Cliente . . . . . . . . . . . . . . . 69
34 Diagrama de Classes do Pacote DP_Clínica . . . . . . . . . . . . . . . 70
35 Modelo baseado na escolha do endereço . . . . . . . . . . . . . . . . . 70
36 Modelo baseado na escolha do endereço e CEP . . . . . . . . . . . . . 71
37 Modelo baseado na escolha do CEP . . . . . . . . . . . . . . . . . . . . 72
38 Permissão de acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
39 Classe responsável pela auditoria . . . . . . . . . . . . . . . . . . . . . 73
40 Classe Tabela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
41 Diagrama de Classe do Pacote GT_Cliente . . . . . . . . . . . . . . . . 74
42 Diagrama de Classe do Pacote GT_Clinica . . . . . . . . . . . . . . . . 74
43 Exemplo de diagrama sem o uso do padrão Facade . . . . . . . . . . . 75
44 Exemplo de diagrama usando o padrão Facade . . . . . . . . . . . . . . 75
45 Diagrama de Classe do Pacote GT_Cliente reformulado . . . . . . . . . 75
46 Diagrama de Classe do Pacote GT_Clinica reformulado . . . . . . . . . 76
47 Diagrama de Classe do Pacote GD_Cliente . . . . . . . . . . . . . . . . 76
48 Diagrama de Classe do Pacote GD_Clínica . . . . . . . . . . . . . . . . 77
49 Diagrama de Classe do Pacote GD_Cliente reformulado . . . . . . . . . 77
50 Diagrama de Classe do Pacote GD_Clínica reformulado . . . . . . . . . 78
51 Modelo de Entidade e Relacionamento (MER): Parte A . . . . . . . . . 79
52 Modelo de Entidade e Relacionamento (MER): Parte B . . . . . . . . . 80
53 Diagrama de Classe do Pacote IU_Cliente . . . . . . . . . . . . . . . . . 81
54 Diagrama de Classe do Pacote IU_Clínica . . . . . . . . . . . . . . . . . 81
55 Diagrama de Classe do Pacote Banco . . . . . . . . . . . . . . . . . . . 82
56 Diagrama de Classe do Pacote Login . . . . . . . . . . . . . . . . . . . 82
57 Diagrama de Classe do Pacote Pessoa . . . . . . . . . . . . . . . . . . 83
58 Pacote Utilitário DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
59 Diagrama de Seqüência do Caso de Uso Visualizar Consulta . . . . . . 84
60 Diagrama de Seqüência do Caso de Uso Sugerir Consulta . . . . . . . 84
61 Diagrama de Seqüência do Caso de Uso Visualizar Correio . . . . . . . 84
62 Diagrama de Seqüência do Caso de Uso Visualizar Agenda . . . . . . . 85
63 Diagrama de Seqüência do Caso de Uso Agendar Consulta . . . . . . . 85
64 Diagrama de Seqüência do Caso de Uso Emitir Relatório de Consultas 85
65 Ícones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
66 Diagrama de Navegabilidade do Pacote Cliente . . . . . . . . . . . . . . 87
67 Diagrama de Navegabilidade do Pacote Clínica . . . . . . . . . . . . . . 88
68 Diagrama de Componentes do Sistema MobOdonto . . . . . . . . . . . 89
69 Diagrama de Implantação do Sistema MobOdonto . . . . . . . . . . . . 90
70 Funcionalidade Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
71 Funcionalidade Visualizar Correio . . . . . . . . . . . . . . . . . . . . . 91
72 Funcionalidade Visualizar Consultas . . . . . . . . . . . . . . . . . . . . 91
73 Funcionalidade Sugerir Consultas: Escolha do dia da semana . . . . . 91
74 Funcionalidade Sugerir Consultas: Escolha do horário disponível . . . . 91
75 Tela principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
76 Tela principal para seleção da funcionalidade . . . . . . . . . . . . . . . 92
77 Funcionalidade Visualizar Consultas: Escolha do horário . . . . . . . . 92
78 Funcionalidade Visualizar Consultas: Visualizando dados do cliente . . 93
79 Funcionalidade Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
80 Funcionalidade Visualizar Consultas . . . . . . . . . . . . . . . . . . . . 93
81 Componente Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
82 Estrutura do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
LISTA DE SIGLAS
3G Terceira Geração
AJAX Asynchronous JavaScript And XML
AMA All Mobile Alliance
API Application Programming Interface
ASP Active Server Pages
CDC Connected Device Configuration
CDMA Code Division Multiple Access
CLDC Connected Limited Device Configuration
CSS Cascading Style Sheets
CVM Compact Virtual Machine
FP Foundation Profile
GCF Generic Connection Framework
GUI Graphical User Interface
HDML Handheld Device Markup Language
HTML Hypertext Markup Language
http Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IDE Integrated Development Environment
IMP Information Mobile Profile
IP Internet Protocol
JCP Java Community Process
JEE Java Enterprise Edition
JME Java Micro Edition
JSE Java Standard Edition
JSP Java Server Pages
JSR Java Specification Request
JVM Java Virtual Machine
KVM Kilobyte Virtual Machine
LWUIT Lightweight User Interface Toolkit
MIDP Mobile Information Device Profile
PBP Personal Basis Profile
PDA Personal Digital Assistants
PNG Portable Network Graphics
PP Personal Profile
SATSA Security And Trust Services API
SDK Software Development Kit
SGBD Sistema Gerenciador de Banco de Dados
SMS Short Message Service
TCP Transmission Control Protocol
TIC Tecnologias de Informação e Comunicação
UML Unified Modeling Language
USSD Unstructured Supplementary Service
VM Virtual Machine
WAE Wireless Application Environment
WAP Wireless Application Protocol
WBMP Wireless Bitmap
WCSS Wireless Cascade Style Sheet
WDP Wireless Datagram Protocol
WML Wireless Markup Language
WSP Wireless Session Layer
WTA Wireless Telephony Application
WTLS Wireless Transport Layer Security
XHTML-MP eXtensible Hypertext Markup Language
XML eXtensible Markup Language
SUMÁRIO
RESUMO
ABSTRACT
1 INTRODUÇÃO 19
2 JUSTIFICATIVA 23
2.1 Motivações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 OBJETIVOS 24
4 TECNOLOGIAS 25
4.1 WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1 Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2 Arquitetura de Aplicativo WAP . . . . . . . . . . . . . . . . . . . 26
4.1.3 Cliente WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.4 Gateway WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.5 Funcionamento do Gateway WAP . . . . . . . . . . . . . . . . . 29
4.1.6 Servidor de Aplicativos WAP . . . . . . . . . . . . . . . . . . . . 31
4.1.7 Pilha de Protocolos WAP . . . . . . . . . . . . . . . . . . . . . . 32
4.1.7.1 Wireless Application Environment - WAE . . . . . . . . 32
4.1.7.2 Wireless Session Layer - WSP . . . . . . . . . . . . . . 33
4.1.7.3 Wireless Transaction Layer - WTP . . . . . . . . . . . . 33
4.1.7.4 Wireless Transport Layer Security - WTLS . . . . . . . 34
4.1.7.5 Wireless Application Environment - WAE . . . . . . . . 34
4.1.7.6 Wireless Datagram Protocol . . . . . . . . . . . . . . . 35
4.2 Linguagem e Plataforma Java . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Plataforma JME . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.2 Java Community Process (JCP) e Java Specification Request
(JSR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.3 Configurações . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.3.1 CLDC (Connected Limited Device Configuration) . . . . 40
4.2.3.2 CDC (Connected Device Configuration) . . . . . . . . . 42
4.2.4 Perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 WAP x JME 45
5.1 Ambientes de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Conectividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Segurança de Informação . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Acesso a Serviço Local do Dispositivo . . . . . . . . . . . . . . . . . . . 46
5.5 Disponibilidade em Dispositivo Móvel . . . . . . . . . . . . . . . . . . . 46
5.6 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.7 Persistência de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.8 Interface com Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.9 Comparação entre JME e WAP . . . . . . . . . . . . . . . . . . . . . . . 49
6 ESTUDO DE CASO: SISTEMA MOBODONTO 51
6.1 Modelo de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Especificação de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2.1 Descrição do Mini-Mundo . . . . . . . . . . . . . . . . . . . . . . 52
6.2.2 Modelo de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . 53
6.2.3 Diagramas de Casos de Uso . . . . . . . . . . . . . . . . . . . . 53
6.2.4 Descrição dos Casos de Uso . . . . . . . . . . . . . . . . . . . . 54
6.2.4.1 Visualizar Consultas . . . . . . . . . . . . . . . . . . . . 55
6.2.4.2 Sugerir Consultas . . . . . . . . . . . . . . . . . . . . . 55
6.2.4.3 Visualizar Correio . . . . . . . . . . . . . . . . . . . . . 55
6.2.4.4 Agendar Consulta . . . . . . . . . . . . . . . . . . . . . 56
6.2.4.5 Visualizar Agenda . . . . . . . . . . . . . . . . . . . . . 56
6.2.4.6 Emitir Relatório de Consultas . . . . . . . . . . . . . . . 57
6.3 Especificação de Análise . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.1 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.2 Diagrama de Estados . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.3 Diagrama de Seqüência . . . . . . . . . . . . . . . . . . . . . . . 60
6.4 Especificação de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.4.1 Tipo de Aplicação, Plataformas de Implementação, Tecnologias
de Apoio e Hardware . . . . . . . . . . . . . . . . . . . . . . . . 63
6.4.1.1 Framework Ajax . . . . . . . . . . . . . . . . . . . . . . 64
6.4.1.2 SSL e Certificado Digital . . . . . . . . . . . . . . . . . 65
6.4.2 Arquitetura do Sistema . . . . . . . . . . . . . . . . . . . . . . . 66
6.4.3 Arquitetura em Camadas . . . . . . . . . . . . . . . . . . . . . . 67
6.4.3.1 Domínio do Problema (DP) . . . . . . . . . . . . . . . . 68
6.4.3.1.1 Considerações . . . . . . . . . . . . . . . . . . 70
6.4.3.2 Gerência de Tarefas (GT) . . . . . . . . . . . . . . . . . 74
6.4.3.2.1 Padrão de Projeto Facade . . . . . . . . . . . 74
6.4.3.3 Gerência de Dados (GD) . . . . . . . . . . . . . . . . . 76
6.4.3.3.1 Padrão de Projeto Singleton . . . . . . . . . . 77
6.4.3.3.2 Modelo de Entidade e Relacionamento (MER) 78
6.4.3.4 Interface com Usuário (IU) . . . . . . . . . . . . . . . . 81
6.4.4 Pacote Utilitários . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.4.4.1 Banco . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.4.4.2 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.4.4.3 Pessoa . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.4.4.4 DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.4.5 Diagrama de Seqüência . . . . . . . . . . . . . . . . . . . . . . . 83
6.4.6 Padrões de Interface . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.4.6.1 Ícones . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.4.6.2 Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.4.6.3 Mensagens . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.4.6.4 Diagrama de Navegabilidade . . . . . . . . . . . . . . . 87
6.4.6.5 Aspectos de Usabilidade e Eficiência . . . . . . . . . . 88
6.4.7 Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . 89
6.4.8 Diagrama de Implantação . . . . . . . . . . . . . . . . . . . . . . 89
6.4.9 Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.4.10 Estrutura de Sistema . . . . . . . . . . . . . . . . . . . . . . . . 94
7 CONCLUSÃO 96
7.1 Conclusão dos Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.2 Dificuldades Encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.3 Retorno Para o Grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.4 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
REFERÊNCIAS 99
RESUMO
Nos últimos anos, a tendência no sentido de dispositivos menores e mais rápidos, jun-tamente com a necessidade de acesso à informação em movimento, tem moldado ocaminho 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 tudoque possivelmente precisariam em um dispositivo que caiba no bolso. Neste contexto,é proposto um sistema para auxílio dos controles administrativos em um consultórioortodôntico. Para tal, foram pesquisados e encontrados os melhores métodos e tec-nologias para o desenvolvimento deste sistema que suportará o acesso pela Webconvencional e por dispositivos móveis.
Palavras-chave: Wireless, WAP (Wireless Application Protocol), JME (Java Micro Edi-tion).
ABSTRACT
In recent years, the appearing of smaller and faster devices with the need to accessinformation everywhere has shaping a new technology that combines the Web and themobile technology. The new trend is to provide users the possibility to have everythingthey need in a device that fits in their pockets. For this purpose, we searched and foundthe best ways and technologies for this development. In this context, it was proposeda software that helps an orthodontic office to control their administrative tasks with ac-cess from the Web and mobile phones.
Keywords: Wireless, WAP (Wireless Application Protocol), JME (Java Micro Edition).
19
1 INTRODUÇÃO
O acesso à rede mundial de computadores tem crescido a taxas exorbitantes nos últi-
mos 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 Tec-
nologias 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 empre-
sas, 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, pre-
sente 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 celu-
lares, 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 Dy-
naTAC 8000x, da Motorola, ganhou logo o apelido de "tijolo". O preço também era
pesado: 3.995 dólares. Sua bateria permitia uma hora de conversação e a memória
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, den-
tre muitas outras funcionalidades. Como exemplo de grande sucesso dessas tecnolo-
gias, 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 operado-
ras 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].
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 celu-
lares devem chegar a 13,8 bilhões de dólares em 2011. 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 patroci-
nados como mostra a figura 2[9].
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 or-
todô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 facili-
dade de acesso como foi descrito.
23
2 JUSTIFICATIVA
O avanço rápido das Tecnologias de Informação e Comunicação - TICs, aliado à cres-
cente 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, diferenciando-
os 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.
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 den-
tro 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 re-
speito à implementação, usabilidade e às tendências do mercado de trabalho;
• Implementar aplicativos embarcados em aparelhos celulares utilizando ferramen-
tas CASE, UML (Unified Modelling Language, Linguagem de Modelagem Unifi-
cada) 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.
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 3.
4.1 WAP
WAP - Wireless Application Protocol, Protocolo de Aplicativos Sem Fio - é um pro-
tocolo 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]
4.1.1 Histórico
De acordo com [10], em 1995, nos EUA, a Unwired Planet apresentou a HDML (Hand-
held 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 1996. 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 vence-
dora. Seria aquela que fornecesse a melhor solução para determinado problema ou
aquela mais amplamente adotada? Essa foi uma questão respondida durante 1999.
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. En-
tretanto, em vez disso, ela optou por envolver os principais fabricantes de telefones
26
móveis em seu projeto, reconhecendo que quanto mais dispositivos existissem no mer-
cado 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 pro-
mover 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 lin-
guagem 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 apar-
elhos telefônicos representado no WAP Forum, o WAP será a principal maneira de
acessar a Internet.
4.1.2 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, en-
tretanto, é 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 difer-
ença mencionada anteriormente.
27
Figura 3: Comparação entre WAP e Internet quando usado para acessar a Web
4.1.3 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 Aplica-
tivos Sem Fio) é o micro-navegador que traz o conteúdo para exibição. Ele re-
cebe 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 implemen-
tar 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 Tele-
fonia 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 funcional-
idade de rede, como discagem de números, respostas às chamadas, gerencia-
mento 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.
28
A figura 4[10] ilustra o Cliente WAP:
Figura 4: Cliente WAP
4.1.4 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
29
4.1.5 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 pre-
sente 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;
30
• O gateway transforma e compacta a informação e a envia de volta para o micro-
navegador no dispositivo móvel.
A parte do gateway do proxy WAP cuida da transformação de todos os pedidos envia-
dos 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 dis-
cutido neste parágrafo.
Figura 7: Gateway do proxy WAP
A funcionalidade de codificação/decodificação dentro do gateway é usada para con-
verter 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 oper-
adora, que fornece a interface para acessar alguns dos serviços de rede que a op-
eradora queira oferecer. Como ele normalmente é o elemento da operadora de rede
que é contactado pelos clientes para acessar serviços, ele também precisa incluir fun-
cionalidade de tarifação e implementa uma interface para cada uma das portadoras
presentes na rede sem fio[10] .
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 oper-
adora, que fornece a interface para acessar alguns dos serviços de rede que a op-
eradora queira oferecer. Como ele normalmente é o elemento da operadora de rede
que é contatado pelos clientes para acessar serviços, ele também precisa incluir fun-
cionalidade de tarifação e implementa uma interface para cada uma das portadoras
presentes na rede sem fio [10].
4.1.6 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 en-
tre 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 é ape-
nas 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
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 simples-
mente incluir os tipos de arquivos WAP nos ajustes do servidor [10].
4.1.7 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].
4.1.7.1 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:
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.
4.1.7.2 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 pro-
tocolos 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/1.1.
4.1.7.3 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
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 responde-
dor, quando ele recebe a mensagem de reconhecimento.
4.1.7.4 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.
4.1.7.5 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 ex-
tremamente 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 forneci-
dos 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 comuni-
caçã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 Sup-
plementary Service Data ou Serviço Complementar de Dados Estruturados - trata-se
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).
4.1.7.6 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 ex-
tremamente 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 forneci-
dos 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 comuni-
caçã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 Sup-
plementary 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 ob-
jetivo principal criar um interpretador para dispositivos eletrônicos de consumo como
TVs, vídeos-cassete, torradeiras e liquidificadores. Em 1992 foi desenvolvido um pro-
tó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 pro-
cessador 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
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 1995. 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 pes-
soais (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:
4.2.1 Plataforma JME
Em tempos anteriores, os dispositivos não possuíam opções para download e insta-
laçã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].
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.
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, equipa-
mentos 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) repre-
senta 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 funcionali-
dades 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
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
4.2.2 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 Pro-
cess) 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 Ora-
cle.
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 Configu-
rações e Perfis presentes no JME são especificações mantidas pelo JCP [23].
40
4.2.3 Configurações
As configurações definem a base de funcionalidades para dispositivos com caracterís-
ticas 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 à imple-
mentaçã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 hard-
ware dos dispositivos que suportam: CLDC e CDC ilustrados na figura 13.
Figura 13: Configurações do JME
4.2.3.1 CLDC (Connected Limited Device Configuration)
A CLDC define as bibliotecas e especificações da VM com o objetivo de suportar dis-
positivos 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
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 car-
acterí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 al-
gumas 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 ex-
ceçõ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 reti-
radas 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
42
e datagramas. Ele foi definido e incluído na JSR 30 (CLDC 1.0), mas por ser am-
plamente 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
4.2.3.2 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 imple-
mentaçã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 de-
vem 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 ver-
sã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 1.4.2.
4.2.4 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-
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 con-
ceito de perfil.
O perfil traz bibliotecas mais específicas para um grupo de dispositivos em particu-
lar. 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 es-
pecí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ão-
volátil além da requerida pela CLDC), 8KB (memória não-volátil para dados armazena-
dos 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 pos-
suem capacidades gráficas avançadas como parquímetro, aparelho de medida indus-
trial e módulos wireless em alarmes residenciais [34]. Atualmente permanece na ver-
sã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].
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.
45
5 WAP x JME
Durante o decorrer deste trabalho foi feita uma análise minuciosa de cada tecnolo-
gia, 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 mer-
cado, 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.
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 conectivi-
dade 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 inte-
gridade 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 cer-
tificados digitais para identificação segura e criptografia de dados como, por ex-
emplo, 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 Apli-
caçã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;
47
• JME: Atualmente a maior parte dos celulares fabricados chega aos consum-
idores 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 desk-
top 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 per-
sistência de dados, entre outros.
5.7 Persistência de Dados
• WAP: A persistência de dados em aplicativos WAP é realizada através da in-
tegraçã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ên-
cia 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 da-
dos. Versões anteriores a 1.2.1 proviam textos e imagens (WBMP) em preto e
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:
49
WAP JMEAmbiente de
Desenvolvimento - NetBeans, EclipseRAD
Conectividade IP, TCP e HTTP HTTP, TCP, SMSBluetooth
Segurança de Camada WTLS - SSL 3 HTTPS e bibliotecasInformação externas
Acesso Serviço Interface WTAI JSR 75Local
Compatibilidade Aparelhos com mini-browser e KVMsuporte a WML/XHTML-MP
Framework - Mobile JUnit, MEChart,Floggy
Persistência de Interação com ASP, JSP e Frameworks, SGBDsInformaçã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 daInterface com sublinhado) SUN), JavaPolish,
Usuário J4ME, imagensvetoriais 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 mostra-
dos 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 aparel-
hos celulares. Para oferecer suporte à tecnologia, basta que o dispositivo possua
um simples micro-browser que interprete seus protocolos e, para JME, necessita da
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 tecnolo-
gia, 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.
51
6 ESTUDO DE CASO: SISTEMAMOBODONTO
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. Se-
gundo [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 soft-
ware 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 desen-
volvida 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.
52
6.2.1 Descrição do Mini-Mundo
O gestor da clínica necessita fazer um controle de seus funcionários e para isso de-
seja armazenar os dados como nome do funcionário, data de nascimento, telefone
residencial, telefone celular, endereço, email e a função exercida. Além disso, pre-
cisa 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
email.
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 ne-
cessidade 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 consul-
tas 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 infor-
maçõ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 val-
ores 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 en-
viando 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 refer-
entes a eles. Além disso, os clientes precisam visualizar seu correio de mensagens
onde serão recebidas mensagens enviadas pela clinica.
53
6.2.2 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 inter-
agem 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 sub-
sistemas, 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 po-
dendo 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.
6.2.3 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.
54
Figura 16: Diagrama de Caso de Uso do Pacote Cliente
Figura 17: Diagrama de Caso de Uso do Pacote Clínica
6.2.4 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.
55
6.2.4.1 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.
6.2.4.2 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.
6.2.4.3 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.
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 2.
6.2.4.4 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 sis-
tema.
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.
6.2.4.5 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 envolvi-
dos e o caso de uso termina.
Fluxo Alternativo (2) Cancelar consulta:
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.
6.2.4.6 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.
58
6.3 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.
6.3.1 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
59
Figura 19: Diagrama de Classes do Pacote Clínica
6.3.2 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
60
Figura 21: Diagrama de Estados da Classe Parcela
Figura 22: Diagrama de Estados da Classe Consulta
6.3.3 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 6.1.4.
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
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
63
6.4 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 re-
visados 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.
6.4.1 Tipo de Aplicação, Plataformas de Implementação, Tecnolo-gias de Apoio e Hardware
O MobOdonto será um aplicativo ambiente WEB com alguns módulos que serão ex-
ecutados a partir de dispositivos móveis. As funcionalidades discutidas na especifi-
cação de análise Visualizar Correio, Visualizar Consultas e Sugerir Consultas, perten-
centes 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 tec-
nologias apresentadas na tabela 2 abaixo.
Tecnologia SoluçãoLinguagem de Programação Java
Linguagem de Marcação XHTML, XHTML-MPSGBD 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.
64
HardwareSoftware RequisitoProcessador x86
Memória RAM 512MBServidor Web Apache 2.2
Servidor de Aplicação Java GlassFish v2
Tabela 3: Requisitos para o módulo Web
Tecnologia CompatibilidadeWAP WAP 2.0JME Nenhuma mensagem
Tabela 4: Requisitos para módulo Móvel
6.4.1.1 Framework Ajax
Para fins de melhorias nas requisições e respostas feitas pelas páginas Web ao servi-
dor, foi desenvolvido um framework Ajax de pequeno porte que viabiliza essa mel-
horia. 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 co-
munica 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 tra-
balhando em segundo plano. Em seguida, quando o servidor tiver terminado o pro-
cesso, o framework dará suporte para atualizar apenas a parte da página que re-
quer 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, indepen-
dente 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.
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. As-
sim, 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.
6.4.1.2 SSL e Certificado Digital
Visando maior segurança no tráfego das informações entre as páginas Web, as infor-
maçõ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-
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 segu-
ranç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 cal-
cular 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 ap-
resentem cada uma, as suas credenciais para comprovar, à outra parte, a sua real
identidade.
6.4.2 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.
67
Figura 30: Arquitetura do Sistema
6.4.3 Arquitetura em Camadas
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 Esten-
dido [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 con-
teúdo destes serão discutido nas próximas subseções.
Figura 31: Arquitetura em Camadas do Pacote Cliente
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 facili-
tando possíveis mudanças em qualquer uma das camadas.
6.4.3.1 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.
69
Figura 33: Diagrama de Classes do Pacote DP_Cliente
70
Figura 34: Diagrama de Classes do Pacote DP_Clínica
6.4.3.1.1 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
71
dados referentes à classe Complemento e os dados referentes ao CEP são bus-
cados automaticamente;
• Caso um número de CEP ou endereço não existam, estes poderão ser cadastra-
dos 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 da-
dos nulos ou redundantes;
• Eficiência por busca de dados pode ser comprometida por conseqüência da com-
plexidade da estrutura;
• Apresenta problemas em uma atualização da base disponibilizada pelos Cor-
reios. 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 cadastra-
dos 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 da-
dos nulos ou redundantes;
72
• Eficiência por busca de dados pode ser comprometida por conseqüência da com-
plexidade da estrutura;
• Apresenta problemas em uma atualização da base disponibilizada pelos Cor-
reios. 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 compro-
metimento 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 estru-
tura.
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.
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 con-
trole 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 aces-
sos à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 audito-
ria 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 de-
terminadas 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.
74
Figura 40: Classe Tabela
6.4.3.2 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
6.4.3.2.1 Padrão de Projeto Facade
Nos diagramas mostrados nas figuras acima, foi utilizado o padrão de projeto Fa-
cade. 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
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 fig-
uras 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
76
Figura 46: Diagrama de Classe do Pacote GT_Clinica reformulado
6.4.3.3 Gerência de Dados (GD)
No pacote gerência de dados estão as classes responsáveis por realizarem a per-
sistência das informações do sistema em um banco de dados.
Figura 47: Diagrama de Classe do Pacote GD_Cliente
77
Figura 48: Diagrama de Classe do Pacote GD_Clínica
6.4.3.3.1 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 con-
templar 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
78
Figura 50: Diagrama de Classe do Pacote GD_Clínica reformulado
6.4.3.3.2 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.
79
Figura 51: Modelo de Entidade e Relacionamento (MER): Parte A
80
Figura 52: Modelo de Entidade e Relacionamento (MER): Parte B
81
6.4.3.4 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
6.4.4 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.
6.4.4.1 Banco
Contém a classe cheque para tratar da manipulação de cheques. A figura 55 apre-
senta o pacote Banco.
82
Figura 55: Diagrama de Classe do Pacote Banco
Apesar de este pacote possuir apenas uma classe, novas classes podem ser incorpo-
radas para contemplarem outros contextos em outras aplicações.
6.4.4.2 Login
O pacote Login contém todas as classes que tratam os aspectos relacionados à segu-
rança dentro do sistema.
Figura 56: Diagrama de Classe do Pacote Login
83
6.4.4.3 Pessoa
O pacote Pessoa contém as classes para tratar as informações relacionadas ao en-
dereço de uma pessoa.
Figura 57: Diagrama de Classe do Pacote Pessoa
6.4.4.4 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
6.4.5 Diagrama de Seqüência
Os diagramas de seqüência apresentados na especificação de análise foram refor-
mulados para contemplar a arquitetura em camadas proposta na seção 6.3.3 deste
84
documento. Os diagramas para os casos de uso Sugerir Consulta, Visualizar Con-
sulta e Visualizar Correio do pacote Cliente e o caso de uso Visualizar Agenda, Agen-
dar 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
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
6.4.6 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.
86
6.4.6.1 Ícones
Para auxiliar na navegabilidade e identificação de funcionalidades presentes no sis-
tema, a figura 65 mostra os ícones utilizados e suas respectivas funcionalidades as
que estão relacionados.
Figura 65: Ícones
6.4.6.2 Cores
Para que o usuário esteja alerta e tenha facilidade de leitura sobre os dados apresen-
tados no sistema, a tabela 5 mostra uma lista de cores e suas respectivas funcionali-
dades utilizadas no desenvolvimento do sistema.
Item Código HexadecimalMensagens de alerta FF0000
Texto padrão 000000Plano de fundo FFFFFF
Hiperlink FFFFFFHiperlink visitado 0000CC
Tabela 5: Cores
As cores mostradas na tabela acima estão utilizando o padrão de cores no formato
RGB.
6.4.6.3 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 men-
sagens utilizadas.
87
Ação MensagemVisualizar Mensagem Erro ao exibir mensagemVisualizar Mensagem Nenhuma mensagem
Acesso ao Banco de Dados Erro ao acessar banco de dadosExcluir Mensagem Mensagem excluída com sucessoExcluir Mensagem Erro ao excluir mensagemVisualizar Agenda Erro ao exibir agendaVisualizar Agenda Nenhuma consulta agendada
Tabela 6: Mensagens do Sistema
6.4.6.4 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 funcionali-
dades 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
88
Figura 67: Diagrama de Navegabilidade do Pacote Clínica
6.4.6.5 Aspectos de Usabilidade e Eficiência
Segundo [53], os aspectos referentes à usabilidade são definidos para mostrar a re-
laçã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 sis-
tema 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 re-
alizar determinada tarefa e todas as ações do sistema possuem nomes diretos e sug-
estivos 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.
89
Caso de Uso Freqüência de Utilização Tempo Máximo EsperadoVisualizar correio 10dia 5 segundos
Visualizar consultas 50dia 5 segundosSugerir 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 EsperadoVisualizar agenda 5dia 3 segundosAgendar consulta 10dia 5 segundosEmitir relatório de 3mês 10 segundos
consultas
Tabela 8: Eficiência dos Casos de Uso do Pacote Clinica
6.4.7 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
6.4.8 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.
90
Figura 69: Diagrama de Implantação do Sistema MobOdonto
6.4.9 Protótipo
Nesta seção serão apresentados os protótipos das telas do sistema MobOdonto con-
templando 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, Vi-
sualizar 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 fig-
uras 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
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
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
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 fun-
cionalidades: 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
94
6.4.10 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 uti-
lizam 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 ilus-
trando a integração do novo componente no sistema proposto e em seguida é descrito
seu funcionamento.
95
Figura 82: Estrutura do Sistema
O funcionamento dá-se da seguinte forma: a partir de um dos módulos é feita a req-
uisição ao sistema para realização de determinada tarefa. Estas requisições são cen-
tralizadas em uma Servlet que as recebe e de acordo com o que foi solicitado, redi-
reciona 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 originou-
se 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.
96
7 CONCLUSÃO
Esta seção tem como objetivo apresentar as considerações finais do projeto proposto,
citar as dificuldades encontradas durante todo o processo de desenvolvimento do sis-
tema, mostrar os retornos de aprendizado e experiência obtidos, além de levantar
possíveis melhorias e incrementos de forma a tornar o projeto mais robusto.
7.1 Conclusão dos Objetivos
De acordo com as expectativas das pesquisas realizadas, foi utilizada a tecnologia
WAP para implementar as funcionalidades referentes ao paciente, a tecnologia JME
foi adotada para que o ortodontista tenha acesso e a tecnologia JSP para a Web, por
sua vez, contemplou toda a funcionalidade necessária para um controle administrativo
utilizando a mobilidade oferecida pela Internet.
Desta forma, a implementação de um ambiente de serviços via Web que aperfeiçoe e
flexibilize o atendimento aos pacientes do consultório tomando como base para a es-
colha das melhores práticas e ferramentas de desenvolvimento, através de pesquisas,
foi alcançada com sucesso superando, assim, o inicialmente almejado.
7.2 Dificuldades Encontradas
No desenvolvimento do módulo Web ocorreram dificuldades para encontrar ferramen-
tas e componentes visuais que utilizassem a tecnologia Ajax e, ao mesmo tempo, que
fossem passíveis de rápido aprendizado e de fácil manutenção. Assim como ocorreu
no desenvolvimento do módulo JME em encontrar componentes visuais que não com-
prometessem no desempenho da aplicação dando, ao mesmo tempo, uma agradável
experiência de uso do sistema ao usuário.
97
Outro percalço foi encontrar um software simulador do ambiente WAP que fosse gratu-
ito. A maioria encontrada no mercado oferece mais limitações do que funcionalidades
propriamente ditas restringindo, assim, a visualização dos resultados do desenvolvi-
mento desse módulo. Na comunicação dos módulos de celulares com o servidor de
aplicação houve um entrave no que se diz respeito ao formato dos dados trafegados.
Se estes seriam em formato texto, em XML ou outro criado apenas para este propósito.
7.3 Retorno Para o Grupo
Com o desenvolvimento deste projeto houve um ganho de conhecimento e de exper-
iência significativos na área de levantamento de requisitos, analise, projeto, implemen-
tação e testes no desenvolvimento de uma solução em Web, WAP e JME - tecnologias
em evidência nos dias atuais.
Além de ter existido a oportunidade de realização de pesquisa e desenvolvimento
da solução em ambiente real, o que acentua a curva de aprendizado dos membros do
grupo criando, também, como fruto de toda pesquisa uma ferramenta comercializável
destinada a consultórios odontológicos.
7.4 Trabalhos Futuros
Como continuidade das pesquisas e desenvolvimento é possível a adoção do uso de
tecnologias como o Bluetooth em um caso de uso adicional no pacote Clínica para
o ortodontista uma vez que a API da JSR-82 para JME seria a mais viável. Como
caso de uso para usufruir desta tecnologia, o cadastro de uma consulta poderá ser
feita com a persistência desses dados na memória do dispositivo móvel e, em um
momento oportuno, essas informações poderão ser transferidas para um computador
pessoal com acesso à Internet e, este, atualizar a agenda de consultas com a base.
Ainda no ambiente JME, pode-se realizar mais pesquisas a fim de encontrar padrões
comuns, ou que sejam próximos, em aparelhos que contemplem a tecnologia para
o desenvolvimento da solução destinado a estes padrões reconhecidos explorando,
assim, mais recursos que o aparelho oferece. E, desta forma, contemplar todas as
98
funcionalidades do sistema para esta tecnologia.
Para a Web pode-se fazer uso de tecnologias como o JSF para usufruir de seus com-
ponentes não comprometendo o desempenho do sistema.
99
REFERÊNCIAS
[1] UOL. Brasil é 11o país em número de internau-tas. Acessado em: 16 out. 2008. Disponível em:<http://tecnologia.uol.com.br/ultnot/bbc/2007/03/06/ult4449u5.jhtm>.
[2] FOLHA. Em dois anos, número de internautas residenciaiscresce 78% no Brasil. Acessado em 20/10/2008. Disponível em:<http://www1.folha.uol.com.br/folha/informatica/ult124u451040.shtml>.
[3] UOL. iPhone 3G: 11 aplicativos que você precisa conhecer. Acessado em20/10/2009. Disponível em: <http://idgnow.uol.com.br/telecom/2008/06/13/iPhone-3g-11-aplicativos-que-voce-precisa-conhecer>.
[4] UOL. Conheça 10 aplicativos que venceram o Android De-veloper Challenge. Acessado em 20/10/2009. Disponível em:<http://idgnow.uol.com.br/telecom/2008/09/10/conheca-10-aplicativos-que-venceram-o-android-developer-challenge>.
[5] UOL. A História do Celular. Acessado em 20/10/2008. Disponível em:<http://idgnow.uol.com.br/galerias/idgphotoalbum.2006-02-03.9367726313>.
[6] UOL. Celulares passam de 140 milhões noBrasil. Acessado em 20/10/2008. Disponível em:<http://www1.folha.uol.com.br/folha/informatica/ult124u451040.shtml>.
[7] UOL. Brasil lidera uso da web no celular na AméricaLatina, diz pesquisa. Acessado em 20/10/2008. Disponível em:<http://www1.folha.uol.com.br/folha/informatica/ult124u451040.shtml>.
[8] WIKIPEDIA. 3G. Acessado em 20/10/2008. Disponível em:<http://pt.wikipedia.org/wiki/3G>.
[9] UOL. Por que as empresas de internet querem invadir o seu celular? Acessadoem 16/10/2008. Disponível em: <http://idgnow.uol.com.br/telecom/2008/02/27/por-que-as-empresas-de-internet-querem-invadir-o-seu-celular>.
[10] AREHART, C. e. a. Professional WAP. [S.l.]: Birmingham: Wrox Press, 2000.
[11] WIKIPEDIA. Proxy. Acessado em 15/05/2009. Disponível em:<http://pt.wikipedia.org/wiki/Proxy>.
[12] MICROSYSTEMS, I. S. Developer Resources for Java Technology. Acessado em18/10/2008. Disponível em: <http://java.sun.com>.
100
[13] MICROSYSTEMS, I. S. Java Technology: The Early Years. Acessado em20/10/2008. Disponível em: <http://java.sun.com/features/1998/05/birthday.html>.
[14] TIOBE. Visual Programming Languages Pop-ular. Acessado em 20/10/2008. Disponível em:<http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html>.
[15] MICROSYSTEMS, I. S. Java SE Overview. Acessado em 20/10/2008. Disponívelem: <http://java.sun.com/javase/>.
[16] MICROSYSTEMS, I. S. Java EE at a Glance. Acessado em 20/10/2008.Disponível em: <http://java.sun.com/javaee>.
[17] MICROSYSTEMS, I. S. Java ME: the Most Ubiquitous ApplicationPlatform for Mobile Devices. Acessado em 20/10/2008. Disponível em:<http://java.sun.com/javame>.
[18] DEVMEDIA. CONCEITOS BASICOS DAS PLATAFORMASJAVA E J2ME. Acessado em 20/10/2008. Disponível em:<http://www.devmedia.com.br/articles/viewcomp.asp?comp=6484>.
[19] MUCHOW, J. W. Core J2ME Tecnologia e MIDP. [S.l.]: Makron Books, 2004.
[20] MICROSYSTEMS, I. S. Java ME Platform Overview. Acessado em 20/10/2008.Disponível em: <http://java.sun.com/javame/technology/index.jsp>.
[21] MICROSYSTEMS, I. S. Connected Limited Device Con-figuration (CLDC). Acessado em 25/10/2008. Disponível em:<http://java.sun.com/products/cldc/overview.html>.
[22] MICROSYSTEMS, I. S. Survey of Java ME To-day (Update). Acessado em 25/10/2008. Disponível em:<http://developers.sun.com/mobility/getstart/articles/survey/>.
[23] PROCESS, J. C. General JCP Questions. Acessado em 25/10/2008. Disponívelem: <http://jcp.org/en/introduction/faq>.
[24] MICROSYSTEMS, I. S. CLDC SPECIFICATION 1.0. 2006.
[25] MICROSYSTEMS, I. S. CLDC SPECIFICATION 1.1. Acessado em 27/10/2008.
[26] MICROSYSTEMS, I. S. The Generic ConnectionFramework. Acessado em 26/10/2008. Disponível em:<http://developers.sun.com/mobility/midp/articles/genericframework>.
[27] MICROSYSTEMS, I. S. Java ME Technology - CDC. Acessado em 26/10/2008.Disponível em: <http://java.sun.com/javame/technology/cdc/index.jsp>.
[28] MICROSYSTEMS, I. S. Personal profile overview. 2005.
[29] MICROSYSTEMS, I. S. MIDP (Mobile Information Device Profile). Acessado em27/10/2008. Disponível em: <http://java.sun.com/products/midp/>.
101
[30] MICROSYSTEMS, I. S. Summary of CLDC-Based Profiles. Acessado em26/10/2008. Disponível em: <http://developers.sun.com/mobility/midp/ttips/cldc>.
[31] MICROSYSTEMS, I. S. Midp jsr-37 jcp specification. 2000.
[32] MICROSYSTEMS, I. S. Midp jsr-118 jcp specification. 2006.
[33] MICROSYSTEMS, I. S. Information Module Profile (IMP) JSR-195. Acessado em27/10/2008. Disponível em: <http://java.sun.com/products/imp>.
[34] MICROSYSTEMS, I. S. Understanding the Java Plat-form Architecture. Acessado em 25/10/2008. Disponível em:<http://www.sun.com/software/opensource/java/intro_java_tech.jsp>.
[35] MICROSYSTEMS, I. S. Foundation Profile Overview. Acessado em 27/10/2008.Disponível em: <http://java.sun.com/products/foundation/overview.html>.
[36] PROCESS, J. C. JSR 46: Foundation Profile. Acessado em 27/10/2008.Disponível em: <http://jcp.org/en/jsr/detail?id=46>.
[37] PROCESS, J. C. JSR 219: Foundation Profile 1.1. Acessado em 27/10/2008.Disponível em: <http://jcp.org/en/jsr/detail?id=219>.
[38] MICROSYSTEMS, I. S. Personal Basis ProfileOverview. Acessado em 27/10/2008. Disponível em:<http://java.sun.com/products/personalbasis/overview.html>.
[39] MICROSYSTEMS, I. S. Personal Profile Overview. Acessado em 27/10/2008.Disponível em: <http://java.sun.com/products/personalprofile/overview.html>.
[40] WIKIPEDIA. WAP. Acessado em 20/10/2009. Disponível em:<http://pt.wikipedia.org/wiki/Wap>.
[41] MICROSYSTEMS, I. S. Security and Trust Services API for J2ME (SATSA). Aces-sado em 27/10/2008. Disponível em: <http://java.sun.com/products/satsa>.
[42] PRESSMAN, R. Engenharia de Software. [S.l.]: Makron Books, 2006.
[43] BEZERRA, E. Principios de Analise e Projeto de Sistemas Com UML. [S.l.]: El-sevier, 2006.
[44] PAGE-JONES, M. Fundamentos do Desenho Orientado a Objetos. [S.l.]: MakronBooks, 2001.
[45] WIKIPEDIA. JavaScript HTML DOM Objects. Acessado em 18/05/2009.Disponível em: <http://www.w3schools.com/js/js_obj_htmldom.asp>.
[46] MCLAUGHLIN, B. Use a Cabeça! Iniciação Rápida Ajax. [S.l.]: Alta Books, 2006.
[47] LANIWAY. Certificados Seguros SSL. Acessado em 21/02/2009. Disponível em:<http://www.laniway.com.br/br/corporativo/certificado>.
[48] ICPBRASIL. que é um Certificado Digital. Acessado em 21/02/2009. Disponívelem: <https://www.icpbrasil.gov.br/duvidas/faq/o-que-e-um-certificado-digital>.
102
[49] FRAGMENTAL. MVC e Camadas. Acessado em 20/04/2009. Disponível em:<http://www.fragmental.com.br/wiki/index.php?title=MVC_e_Camadas>.
[50] SHALLOWAY ALAN; TROTT, J. Design Patterns Explained: A New Perspectiveon Object-Oriented Design. [S.l.]: Bookman Companhia, 2001.
[51] JAVAFREE. Singleton. Acessado em 23/05/2009. Disponível em:<http://www.javafree.org/wiki/Singleton>.
[52] SOUZA CELSO ANDRé; ARAúJO FILHO, J. E. R. de. Estudo do paradigma ori-entado a objetos em sistemas de decisão e mineração de dados em ambientesdistribuídos através de ferramentas computacionais inteligentes. p. 10, 2008.
[53] WIKIPEDIA. Usabilidade. Acessado em 20/04/2009. Disponível em:<http://pt.wikipedia.org/wiki/Usabilidade>.