Anda di halaman 1dari 103

CENTRO UNIVERSITRIO VILA VELHA

CURSO DE CINCIA DA COMPUTAO

IGOR DA COSTA ROCHA ELIAS


JURANDIR LUCHINI VICTOR
MARCOS ANTONIO RAMPINELLI

PESQUISA E DESENVOLVIMENTO PARA


DISPOSITIVOS MVEIS

VILA VELHA
2009

IGOR DA COSTA ROCHA ELIAS


JURANDIR LUCHINI VICTOR
MARCOS ANTONIO RAMPINELLI

PESQUISA E DESENVOLVIMENTO PARA


DISPOSITIVOS MVEIS
Trabalho de Concluso de Curso apresentado ao Centro Univertrio Vila Velha como
requisito parcial para a obteno do grau
de Bacharel em Cincia da Computao.
Orientador: Cristiano Biancardi

VILA VELHA
2009

IGOR DA COSTA ROCHA ELIAS


JURANDIR LUCHINI VICTOR
MARCOS ANTONIO RAMPINELLI

PESQUISA E DESENVOLVIMENTO PARA


DISPOSITIVOS MVEIS
BANCA EXAMINADORA

Prof. Msc. Cristiano Biancardi


Centro Universitrio Vila Velha
Orientador

Prof. Msc. Renato Elias N. de


Moraes
Centro Universitrio Vila Velha

Prof. Msc. Sandro Tonini da Silva


Centro Universitrio Vila Velha

Trabalho de Concluso de Curso


aprovado em 04/06/2009.

Aos nossos pais e amigos...

AGRADECIMENTOS
Agradecemos a Deus, nossas famlias , 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.
Provrbio Chins

LISTA DE TABELAS
1

Comparao WAP x JME . . . . . . . . . . . . . . . . . . . . . . . . . .

49

Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

Requisitos para o mdulo Web . . . . . . . . . . . . . . . . . . . . . . .

64

Requisitos para mdulo Mvel . . . . . . . . . . . . . . . . . . . . . . .

64

Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

Mensagens do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

Eficincia dos Casos de Uso do Pacote Cliente . . . . . . . . . . . . . .

89

Eficincia dos Casos de Uso do Pacote Clinica . . . . . . . . . . . . . .

89

LISTA DE FIGURAS
1

Comparao entre o nmero de celulares e computadores no mundo .

21

Projees para a internet mvel no mundo . . . . . . . . . . . . . . . .

22

Comparao entre WAP e Internet quando usado para acessar a Web .

27

Cliente WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

Uso do Gateway WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

Gateway WAP e elementos da rede sem fio . . . . . . . . . . . . . . . .

29

Gateway do proxy WAP . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

Codificador / Decodificador do Gateway WAP . . . . . . . . . . . . . . .

31

Pilha de Protocolos WAP . . . . . . . . . . . . . . . . . . . . . . . . . .

32

10

Plataforma Java e suas edies

. . . . . . . . . . . . . . . . . . . . . .

37

11

JME e seus componentes . . . . . . . . . . . . . . . . . . . . . . . . . .

38

12

JME dividida em camadas . . . . . . . . . . . . . . . . . . . . . . . . . .

39

13

Configuraes do JME . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

14

Relacionamento entre as diferentes implementaes 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 Clnica . . . . . . . . . . . . . . .

54

18

Diagrama de Classes do Pacote Cliente . . . . . . . . . . . . . . . . . .

58

19

Diagrama de Classes do Pacote Clnica . . . . . . . . . . . . . . . . . .

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 Seqncia do Caso de Uso Visualizar Consulta . . . . . .

61

24

Diagrama de Seqncia do Caso de Uso Sugerir Consulta . . . . . . .

61

25

Diagrama de Seqncia do Caso de Uso Visualizar Correio . . . . . . .

61

26

Diagrama de Seqncia do Caso de Uso Visualizar Agenda . . . . . . .

62

27

Diagrama de Seqncia do Caso de Uso Agendar Consulta . . . . . . .

62

28

Diagrama de Seqncia do Caso de Uso Emitir Relatrio de Consultas

62

29

Comunicao entre as pginas 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_Clnica

. . . . . . . . . . . . . . .

70

35

Modelo baseado na escolha do endereo . . . . . . . . . . . . . . . . .

70

36

Modelo baseado na escolha do endereo e CEP . . . . . . . . . . . . .

71

37

Modelo baseado na escolha do CEP . . . . . . . . . . . . . . . . . . . .

72

38

Permisso de acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

39

Classe responsvel 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 padro Facade . . . . . . . . . . .

75

44

Exemplo de diagrama usando o padro 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_Clnica . . . . . . . . . . . . . . . .

77

49

Diagrama de Classe do Pacote GD_Cliente reformulado . . . . . . . . .

77

50

Diagrama de Classe do Pacote GD_Clnica 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_Clnica . . . . . . . . . . . . . . . . .

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 Utilitrio DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

59

Diagrama de Seqncia do Caso de Uso Visualizar Consulta . . . . . .

84

60

Diagrama de Seqncia do Caso de Uso Sugerir Consulta . . . . . . .

84

61

Diagrama de Seqncia do Caso de Uso Visualizar Correio . . . . . . .

84

62

Diagrama de Seqncia do Caso de Uso Visualizar Agenda . . . . . . .

85

63

Diagrama de Seqncia do Caso de Uso Agendar Consulta . . . . . . .

85

64

Diagrama de Seqncia do Caso de Uso Emitir Relatrio de Consultas

85

65

cones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

66

Diagrama de Navegabilidade do Pacote Cliente . . . . . . . . . . . . . .

87

67

Diagrama de Navegabilidade do Pacote Clnica . . . . . . . . . . . . . .

88

68

Diagrama de Componentes do Sistema MobOdonto . . . . . . . . . . .

89

69

Diagrama de Implantao 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 horrio disponvel . . . .

91

75

Tela principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92

76

Tela principal para seleo da funcionalidade . . . . . . . . . . . . . . .

92

77

Funcionalidade Visualizar Consultas: Escolha do horrio . . . . . . . .

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 Gerao

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 Informao e Comunicao

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

SUMRIO

RESUMO
ABSTRACT
1 INTRODUO

19

2 JUSTIFICATIVA

23

2.1 Motivaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3 OBJETIVOS

24

4 TECNOLOGIAS

25

4.1 WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Histrico

25

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 Configuraes . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 Segurana de Informao . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.4 Acesso a Servio Local do Dispositivo . . . . . . . . . . . . . . . . . . .

46

5.5 Disponibilidade em Dispositivo Mvel

. . . . . . . . . . . . . . . . . . .

46

5.6 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.7 Persistncia de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.8 Interface com Usurio . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.9 Comparao entre JME e WAP . . . . . . . . . . . . . . . . . . . . . . .

49

6 ESTUDO DE CASO: SISTEMA MOBODONTO

51

6.1 Modelo de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . .

51

6.2 Especificao de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . .

51

6.2.1 Descrio 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 Descrio 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 Relatrio de Consultas . . . . . . . . . . . . . . .

57

6.3 Especificao de Anlise . . . . . . . . . . . . . . . . . . . . . . . . . .

58

6.3.1 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . .

58

6.3.2 Diagrama de Estados . . . . . . . . . . . . . . . . . . . . . . . .

59

6.3.3 Diagrama de Seqncia . . . . . . . . . . . . . . . . . . . . . . .

60

6.4 Especificao de Projeto

. . . . . . . . . . . . . . . . . . . . . . . . . .

63

6.4.1 Tipo de Aplicao, Plataformas de Implementao, 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

Domnio do Problema (DP) . . . . . . . . . . . . . . . .

6.4.3.1.1
6.4.3.2

Consideraes . . . . . . . . . . . . . . . . . .

70

Gerncia de Tarefas (GT) . . . . . . . . . . . . . . . . .

74

6.4.3.2.1
6.4.3.3

68

Padro de Projeto Facade . . . . . . . . . . .

74

Gerncia de Dados (GD) . . . . . . . . . . . . . . . . .

76

6.4.3.3.1

Padro de Projeto Singleton . . . . . . . . . .

77

6.4.3.3.2

Modelo de Entidade e Relacionamento (MER)

78

Interface com Usurio (IU) . . . . . . . . . . . . . . . .

81

6.4.3.4

6.4.4 Pacote Utilitrios . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 Seqncia . . . . . . . . . . . . . . . . . . . . . . .

83

6.4.6 Padres 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 Eficincia . . . . . . . . . .

88

6.4.7 Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . .

89

6.4.8 Diagrama de Implantao . . . . . . . . . . . . . . . . . . . . . .

89

6.4.9 Prottipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

6.4.10 Estrutura de Sistema

94

. . . . . . . . . . . . . . . . . . . . . . . .

7 CONCLUSO

96

7.1 Concluso dos Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . .

96

7.2 Dificuldades Encontradas . . . . . . . . . . . . . . . . . . . . . . . . . .

96

7.3 Retorno Para o Grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97

7.4 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97

REFERNCIAS

99

RESUMO
Nos ltimos anos, a tendncia no sentido de dispositivos menores e mais rpidos, juntamente com a necessidade de acesso informao em movimento, tem moldado o
caminho para uma nova tecnologia que rene o mundo da Web e da telefonia mvel.
Essa tendncia na tecnologia fornecer aos usurios a capacidade de terem tudo
que possivelmente precisariam em um dispositivo que caiba no bolso. Neste contexto,
proposto um sistema para auxlio dos controles administrativos em um consultrio
ortodntico. Para tal, foram pesquisados e encontrados os melhores mtodos e tecnologias para o desenvolvimento deste sistema que suportar o acesso pela Web
convencional e por dispositivos mveis.
Palavras-chave: Wireless, WAP (Wireless Application Protocol), JME (Java Micro Edition).

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

19

INTRODUO

O acesso rede mundial de computadores tem crescido a taxas exorbitantes nos ltimos anos, especialmente no Brasil cujas taxas giram em torno de 16% anuais e, nos
ltimos dois anos, passou para 78% o aumento do nmero de internautas residenciais,
de acordo com [1] e [2]. Paralelamente ao crescimento da Internet, o avano das Tecnologias de Informao e Comunicao - TIC, especialmente a telefonia celular, tem
permitido uma maior aderncia das aplicaes comerciais s demandas de mercado,
tornando a mobilidade um fator primordial para aumento da lucratividade das empresas, principalmente em virtude de melhoria dos servios prestados a seus clientes.
O mercado de aplicaes mveis produz servios cada vez mais impressionantes
como o Google Maps que baseado em pesquisa e visualizao de mapas e imagens
de praticamente qualquer lugar do planeta via satlite podendo ser possvel, tambm,
visualizar a posio do usurio no mapa e de sua rede de amigos; o Modality, presente no iPhone, que uma ferramenta que permite ampliar e navegar por imagens
do corpo humano utilizando teclado touchscreen presente no aparelho; e o CallACab
permite que os usurios liguem para um txi prximo a sua localizao com um nico
clique e com viso detalhada do mapa onde ele se encontra presente na plataforma
Android - do Google. [3] [4].
Nesse sentido, a melhoria contnua das interfaces das aplicaes em aparelhos celulares, bem como a ampliao dos recursos oferecidos, permitidos pela miniaturizao
de componentes, telas coloridas e maiores, alm de baterias de longa durao, tem
revolucionado a telefonia sem fio. Muitas modificaes e inovaes foram introduzidas
na tecnologia utilizada pelos telefones celulares desde que a Motorola apresentou,
em 1973, seu prottipo do primeiro telefone celular. Pesando 794,16 gramas, o DynaTAC 8000x, da Motorola, ganhou logo o apelido de "tijolo". O preo tambm era
pesado: 3.995 dlares. Sua bateria permitia uma hora de conversao e a memria

20

armazenava 30 nmeros de telefones. Podia no ser exatamente bonito, mas permitia


comunicao mvel - ao menos para quem conseguisse carreg-lo. [5]
Em 35 anos de evoluo, houve um crescimento meterico na tecnologia e na adio
de funes nos aparelhos celulares. E o melhor: por um preo mais acessvel.
Os modelos, atualmente, podem vir acompanhados de telas sensveis ao toque, de
cmeras digitais, de acesso a Internet e a tecnologia Bluetooth, suportam jogos, dentre muitas outras funcionalidades. Como exemplo de grande sucesso dessas tecnologias, pode-se citar o iPhone, da Apple, e o G1, fabricado pela HTC o qual baseado
na plataforma Android, do Google - ambos com as funcionalidades descritas acima e
com os preos acessveis a uma boa parte da populao, principalmente em pases
de primeiro mundo.
Os custos de aquisio mais acessveis tm permitido um constante crescimento do
mercado de usurios de celular no Brasil e no mundo. Segundo dados da Agncia
Nacional de Telecomunicaes (Anatel), no ms de setembro de 2008, o mercado
brasileiro de aparelhos celulares j atingiu a marca de 140,6 milhes. [6]
Com o advento da tecnologia 3G (Terceira Gerao) na telefonia mvel, as operadoras de celular no Brasil podero oferecer a seus usurios servios como telefonia por
voz e a transmisso de dados a longas distncias com altas taxas de transmisso.
Importante ressaltar que mais de 25% da populao brasileira j mora em municpios
onde pelo menos uma operadora de celular oferece a tecnologia 3G. Isso faz com que
a Internet atravs do celular seja mais vivel e atrativa, tornando o Brasil o pas que
mais acessa internet via celular na Amrica Latina, seguido pelo Mxico e Venezuela,
de acordo com [7] [8].

21

Figura 1: Comparao entre o nmero de celulares e computadores no mundo


Interessante observar que, mesmo com as restries atuais nos custos de acesso
a dados pelo celular - especialmente nos mercados em estgio de desenvolvimento,
como o brasileiro -, os usurios de Internet mvel j passam de 400 milhes no mundo
- um tero dos internautas que navegam pelo PC - e a previso de que cheguem
prximo marca de um bilho dentro de trs anos, como mostra a figura 1[9].
Em mercados mais maduros como o Japo, o nmero de usurios 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 previses do eMarketer, os gastos com anncios em celulares devem chegar a 13,8 bilhes de dlares em 2011. Deste total, 17% viro do
mercado de aplicaes de buscas. Segundo [9], dos 982,4 milhes de usurios de
internet mvel previstos para 2011, mais de 90% vo utilizar os servios de busca,
fornecendo combustvel para um mercado de 2,3 bilhes de dlares em links patrocinados como mostra a figura 2[9].

22

Figura 2: Projees para a internet mvel no mundo


Tendo em vista todas as possibilidades de mobilidade discutidas at agora, a utilizao de computao mvel na rea de sade, especificamente na odontologia, pode
ser vista como elemento interessante para agilidade na gerao de informaes e
diagnsticos 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 sero tomados nas consultas. Desta maneira, um sistema de informao seria dito
ideal para o contexto se combinassem as garantias de estabilidade, de veracidade e
integridade da informao com a facilidade de acesso que a Internet oferece tanto em
dispositivos mveis como em computadores pessoais.
Este trabalho visa conceituar um sistema de informao, destinado s clnicas ortodnticas, que possa auxiliar na gesto do tratamento do paciente, abrangendo desde
a possibilidade de marcao e visualizao de consultas at o controle de pagamento
das parcelas, com a flexibilidade oferecida pela internet e telefonia mvel ter a facilidade de acesso como foi descrito.

23

JUSTIFICATIVA

O avano rpido das Tecnologias de Informao e Comunicao - TICs, aliado crescente necessidade de diferenciao dos servios oferecidos no mercado de sade
odontolgico so fatores catalisadores de solues em software. Nesse sentido, este
trabalho justificado pela ausncia no mercado de uma soluo especfica no setor
odontolgico, que contemple vrias funcionalidades dos servios prestados, diferenciandoos e tornando sua gesto mais otimizada. Adicionalmente, a possibilidade de estudo e
de convergncia de vrias tecnologias de computao mvel em um prottipo, aliado
ao estudo cientfico dessas tecnologias, torna-se um diferencial do trabalho proposto.

2.1 Motivaes
Por em prtica todo contedo aprendido nas disciplinas relacionadas programao
orientada a objetos, engenharia de software e banco de dados durante a graduao
foram uma das principais motivaes para a realizao deste projeto de pesquisa.
Alm disso, o contato com o desenvolvimento para dispositivos mveis, 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 possveis oportunidades de
negcios.

24

OBJETIVOS

Esta seo tem como objetivo principal apresentar o sistema proposto como estudo
de caso. Os itens que se seguem apresentam os principais processos e etapas dentro do desenvolvimento de software aplicados no projeto, alem de discusses sobre
arquiteturas, padres e as melhores solues adotadas. Como objetivos secundrios,
este trabalho pretende:
Realizar um estudo comparativo das tecnologias open-source mais difundidas
para o desenvolvimento de aplicativos mveis, WAP e JME, no que se diz respeito implementao, usabilidade e s tendncias do mercado de trabalho;
Implementar aplicativos embarcados em aparelhos celulares utilizando ferramentas CASE, UML (Unified Modelling Language, Linguagem de Modelagem Unificada) e Internet (como a linguagem de estilo CSS Mobile e as linguagens de
marcao XML, XHTML-MP);
Elaborar um estudo de caso aplicando os conceitos e tecnologias abordadas de
forma a construir um sistema, denominado MobOdonto.

25

TECNOLOGIAS

Nesta seo sero apresentadas as tecnologias escolhidas como base para as pesquisas
e suas principais definies para auxiliarem no cumprimento dos objetivos descritos
na seo 3.

4.1 WAP
WAP - Wireless Application Protocol, Protocolo de Aplicativos Sem Fio - um protocolo de comunicao e ambiente de aplicaes para distribuio de recursos de
informao, servios de telefonia avanado e acesso internet a partir de dispositivos
mveis. Ele representa um novo modo de olhar o fenmeno sem fio - permitindo aos
aplicativos "seguirem"seus clientes e fornecendo a eles servios inovadores. [10]

4.1.1 Histrico
De acordo com [10], em 1995, nos EUA, a Unwired Planet apresentou a HDML (Handheld Device Mark Up Language, Linguagem de Marcao para Dispositivos Sem Fio)
- que uma verso reduzida de HTML para ser usada em dispositivos sem fio. E, no
Japo, a operadora NTT DoCoMo apresentou um servio chamado i-mode, no incio
de 1996. Essa tecnologia se tornou muito popular com quase sete milhes de usurios
acessando servios de internet a partir de telefones mveis.
Essas duas tecnologias apresentaram questes interessantes como qual seria a vencedora. Seria aquela que fornecesse a melhor soluo para determinado problema ou
aquela mais amplamente adotada? Essa foi uma questo 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 Japo. Entretanto, em vez disso, ela optou por envolver os principais fabricantes de telefones

26

mveis em seu projeto, reconhecendo que quanto mais dispositivos existissem no mercado mundial oferecendo suporte tecnologia, mais ela poderia vender suas solues
de internet sem fio em todo o mundo. O envolvimento de outras empresas, cada uma
com uma grande base de clientes em diferentes partes do mundo, tem ajudado a promover a tecnologia.
Assim o WAP Forum (hoje a All Mobile Alliance) foi criada pela Phone.com (antiga
Unwired Planet), Ericsson, Nokia e Motorola. Com o advento do WAP Forum, a
Phone.com compartilhou seu conhecimento e a parceria logo evoluiu para as abrangentes
especificaes WAP, que incluem as camadas de aplicativo complementar, sesso,
transao, segurana e protocolo de transporte. Tambm foi criada uma nova linguagem de marcao, chamada WML, Wireless Markup Language ou Linguagem de
Marcao Sem Fio. Esses protocolos minimizam os problemas associados ao uso de
protocolos de internet para transferncia de dados sem fio. Eles fazem isso eliminando
transferncias de dados desnecessrias usando cdigo binrio para reduzir o volume
de dados que precisa ser enviado. Alm disso, as sesses sem fio so projetadas
para serem facilmente suspensas e retomadas, sem as cargas adicionais associadas
a protocolos de internet. Assim, os protocolos so muito convenientes para a baixa
largura de banda associada comunicao sem fio. Com 90% do mercado de aparelhos telefnicos 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 comunicao entre os provedores
de contedo e dispositivos mveis mais eficientes e com menos demora do que os
prprios 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 diferena, entretanto, a presena do gateway WAP para fazer a transformao entre o protocolo
HTTP e WAP. [10]. A abstrao representada pela figura 3[10] mostra a principal diferena mencionada anteriormente.

27

Figura 3: Comparao 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 compatvel com WAP
que ele deve implementar um agente usurio WAE, um agente usurio WTA e a Pilha
WAP.
O Agente de Usurio WAE (Wireless Application Environment, Ambiente de Aplicativos Sem Fio) o micro-navegador que traz o contedo para exibio. Ele recebe o cdigo WML compilado, o WMLScript e todas as imagens do gateway
WAP, e os executam ou os apresentam na tela. O navegador deve implementar toda a funcionalidade fornecida pelo cdigo WML e WMLScript. Ele tambm
deve gerenciar a interao com o usurio, como a entrada de sada de textos e
mensagens de erro ou aviso;
O Agente de Usurio WTA (Wireless Telephony Applications, Aplicaes de Telefonia Sem Fio) recebe arquivos WTA compilados do servidor WTA e os executam.
O Agente de Usurio WTA inclui acesso interface para o telefone e funcionalidade de rede, como discagem de nmeros, respostas s chamadas, gerenciamento de mensagens e servios de indicao de local;
A implementao 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 requisies repassando os dados a outros servidores [11]). Ele utilizado para
conectar o domnio sem fio com o da Internet. Entretanto, ele contm funcionalidades
de gateway de protocolos, alm de funcionalidades de codificao/decodificao. 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 servio completo.

Figura 6: Gateway WAP e elementos da rede sem fio


Segundo [10], quando se inicia uma sesso WAP em um telefone mvel, os seguintes
passos so executados.
Uma conexo criada, via WSP (Wireless Session Protocol, Protocolo de Sesso
Sem Fio), entre o dispositivo mvel e o gateway WAP, o qual se supe estar presente na rede da operadora;
Quando se introduz o endereo de um site WAP, enviado para o gateway um
pedido do micro-navegador do dispositivo, usando WSP. O WSP o protocolo
WAP responsvel por iniciar e terminar as conexes dos dispositivos mveis 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 informao solicitada, via
HTTP;

30

O gateway transforma e compacta a informao e a envia de volta para o micronavegador no dispositivo mvel.
A parte do gateway do proxy WAP cuida da transformao de todos os pedidos enviados e recebidos pelo cliente, usando WAP, para o que servidor de origem est usando
(HTTP, por exemplo). O provedor de contedo envia seu contedo para o gateway
usando o protocolo HTTP. Ento, ele encaminha todo o contedo recebido para os
dispositivos WAP, usando os protocolos WAP [10]. A figura 7[10] ilustra o que foi discutido neste pargrafo.

Figura 7: Gateway do proxy WAP


A funcionalidade de codificao/decodificao dentro do gateway usada para converter o contedo WML e WMLScript que transita no cliente para uma forma otimizada
para redes de banda baixa [10].
O gateway WAP tambm conectado ao servio WTA, presente na rede da operadora, que fornece a interface para acessar alguns dos servios de rede que a operadora queira oferecer. Como ele normalmente o elemento da operadora de rede
que contactado pelos clientes para acessar servios, ele tambm precisa incluir funcionalidade de tarifao e implementa uma interface para cada uma das portadoras
presentes na rede sem fio[10] .

31

Figura 8: Codificador / Decodificador do Gateway WAP


Outro servio que a funcionalidade CODEC (codificao/decodificao) pode fornecer
a transformao de cdigo HTML ou texto em WML.
O gateway WAP tambm conectado ao servio WTA, presente na rede da operadora, que fornece a interface para acessar alguns dos servios de rede que a operadora queira oferecer. Como ele normalmente o elemento da operadora de rede
que contatado pelos clientes para acessar servios, ele tambm precisa incluir funcionalidade de tarifao 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/contedo WAP tem exatamente a mesma funo que
um servidor Web e fornece os mesmos recursos para os clientes. A distino entre eles apenas lgica, pois os dois podem coexistir no mesmo dispositivo fsico,
e alguns servidores podem fornecer as duas funes usando o mesmo software. A
nica diferena, claro, o contedo que eles armazenam e enviam para os clientes.
Enquanto o servidor Web oferece suporte a HTML, JavaScript, multimdia e todos
os formatos de imagens, o servidor de aplicativos WAP armazena arquivos WML,
WMLScript e arquivos de imagem WBMP. Um servidor WAP normalmente apenas um servidor de aplicativos WAP com funcionalidades de gateway includas. Ele
fornecer todos os servios que um servidor de origem normal fornece, mas tambm
atuar como um gateway WAP [10].
O servidor de aplicativos WAP tambm pode, claro, conter todas as tecnologias
usadas para fornecer contedo dinmico. possvel usar XML em conjunto com ASP

32

e Servlets Java, para citar apenas algumas, para gerar contedo WML dinamicamente
[10].
Para permitir que um servidor Web contenha aplicativos WAP necessrio simplesmente 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 referncia OSI ISO [ISO7498] e herdou a
maior parte de suas caractersticas. A principal diferena 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 descrio das camadas da pilha WAP segundo [10].
4.1.7.1

Wireless Application Environment - WAE

A camada de aplicao do WAP fornece um ambiente que inclui todos os elementos


relacionados ao desenvolvimento e execuo de aplicativos.Os principais blocos de
construo do WAE so os seguintes:

33

Uma linguagem de marcao leve: WML;


Uma linguagem de script leve: WMLScript;
Uma interface para servios locais e servios de telefonia avanados: WTA.
4.1.7.2

Wireless Session Layer - WSP

O WSP (Wireless Session Protocol, Protocolo de Sesso Sem Fio), permite que
servios troquem dados entre aplicativos de forma organizada. Ele inclui dois protocolos diferentes:
Servios de sesso conexo: Operam atravs do WTP (Wireless Transaction
Protocol ou Protocolo de Transao Sem Fio);
Servios de sesso sem conexo: Operam diretamente atravs da camada de
transporte (WDP, Wireless Datagram Protocol, Protocolo de Datagrama Sem
Fio).
Sob alguns aspectos, a camada de sesso WSP basicamente uma forma binria de
HTTP. A transmisso binria de dados entre o servidor e um cliente uma adaptao
essencial feita para rede mvel de largura de banda estreita. O WSP fornece todos
os mtodos definidos por HTTP/1.0 e permite a capacidade de negociao para obter
total compatibilidade com HTTP/1.1.
4.1.7.3

Wireless Transaction Layer - WTP

O WTP (Wireless Transport Layer, protocolo de transmisso sem Fio) fornece servios
para realizar transaes confiveis e no confiveis e opera por intermdio da camada
WDP ou por meio da camada de segurana opcional, WTLS. A WTP, assim como as
outras camadas no WAP, otimizada para se adaptar pequena largura de banda
da interface de rdio, tentando reduzir o volume total de transaes repetidas entre o
cliente e o servidor. Em particular, trs classes diferentes de servio so fornecidas
para as camadas superiores:
Pedidos No Confiveis: O iniciador (neste caso, um servidor de contedo)
envia um pedido para o respondedor( agente de usurio ) que no responde com

34

um reconhecimento. A transao na tem estado e termina quando a mensagem


chamada for enviada.
Pedidos Confiveis: O iniciador envia um pedido para o respondedor, que o
reconhece. O respondedor armazena as informaes de estado da transao
por algum tempo, para que possa retransmitir a mensagem de reconhecimento,
caso o servidor a pea novamente. A transao termina no iniciador, quando
este recebe a mensagem de reconhecimento.
Pedidos Confiveis com uma mensagem de resultado: O iniciador envia um
pedido para o respondedor que o reconhece implicitamente com uma mensagem
de resultado. O iniciador ento, reconhece a mensagem de resultado, mantendo
a informao de estado da transao por algum tempo, aps o reconhecimento
ter sido enviado, no caso de ele no chegar. A transao termina no respondedor, quando ele recebe a mensagem de reconhecimento.
4.1.7.4

Wireless Transport Layer Security - WTLS

O TLS (Wireless Transport Layer Security, Segurana de Camada de Transporte Sem


Fio) a soluo para o problema de segurana fornecida pelo WAP Forum. WTLS
uma camada opcional e tem por base a TLS (Transport Layer Security, Segurana
de Camada de Transporte) v1.0, que por sua vez baseada na SSL (Secure Sockets
Layer, Camada de Soquetes Seguros) v3.0, que so protocolos de Internet. O WTLS
opera atravs da camada de transporte (WDP). Ela fornece servios que garantem
privacidade, autenticao de servidor, autenticao 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 extremamente porttil que , possvel de ser usado em redes mveis extremamente
diferentes. O WDP isola as camadas superiores dos servios de portadoras fornecidos pela rede, permitindo aos aplicativos uma transmisso de dados transparente por
meio de diferentes portadoras. Os servios de portadora so o mago da comunicao entre o telefone mvel e as estaes rdio-base. Eles incluem SMS (Short
Message Service ou Servio de Mensagens Curtas), CSD, USSD (Unstructured Supplementary Service Data ou Servio Complementar de Dados Estruturados - trata-se

35

de uma modalidade de servio de envio de mensagens curtas para o celular) e CDMA


(Code Division Multiple Access ou Acesso Mltiplo por Diviso de Cdigo).
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 extremamente porttil que , possvel de ser usado em redes mveis extremamente
diferentes. O WDP isola as camadas superiores dos servios de portadoras fornecidos pela rede, permitindo aos aplicativos uma transmisso de dados transparente por
meio de diferentes portadoras. Os servios de portadora so o mago da comunicao entre o telefone mvel e as estaes rdio-base. Eles incluem SMS (Short
Message Service ou Servio de Mensagens Curtas), CSD, USSD (Unstructured Supplementary Service Data ou Servio Complementar de Dados Estruturados - trata-se
de uma modalidade de servio de envio de mensagens curtas para o celular) e CDMA
(Code Division Multiple Access ou Acesso Mltiplo por Diviso de Cdigo).

4.2 Linguagem e Plataforma Java


Java uma plataforma desenvolvida pela Sun Microsystems, na dcada de 1990, com
a idia de que aplicaes criadas para ela pudessem ser executadas em diferentes
ambientes computacionais [12].
Tudo comeou em 1991 com um projeto, conhecido como Green Project, iniciado por
uma equipe da empresa. Essa equipe, liderada por James Gosling, tinha como objetivo principal criar um interpretador para dispositivos eletrnicos de consumo como
TVs, vdeos-cassete, torradeiras e liquidificadores. Em 1992 foi desenvolvido um prottipo chamado *7 (StarSeven), que era uma espcie de controle remoto para esses
eletrnicos, 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 caracterstica era ser independente de arquitetura de processador onde seria executada. Toda essa idia teria sido perfeita se no fosse um
pequeno problema: inexistncia de mercado [13].
No incio da dcada, as empresas estavam comeando e ainda buscavam modelos

36

de negcios viveis fazendo com que o crescimento neste setor no atingisse o nvel
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 caractersticas e idias 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 adaptao o nome da linguagem foi modificado para Java, como hoje conhecido
[13].
A primeira verso da linguagem foi lanada em 1996 e a partir dela, a plataforma
foi crescendo e ganhando fora tornando-se hoje uma das mais usadas no mundo
[14]. Com o tempo, o Java foi amadurecendo e vislumbrando possibilidades em outros
setores da indstria alm 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 trs edies, cada uma visando segmentos especficos
de negcio:
JSE (Java Standard Edition) [15] - projetada para rodar em computadores pessoais (desktops) e estaes de trabalho.
JEE (Java Enterprise Edition) [16] - projetada com foco em aplicaes para
serem executadas no servidor.
JME (Java Micro Edition) [17] - especializada em pequenos dispositivos com
memria, tela e poder de processamento limitados.
A figura 10 [18] mostra um diagrama com uma viso geral da plataforma Java:

4.2.1 Plataforma JME


Em tempos anteriores, os dispositivos no possuam opes para download e instalao de softwares alm dos pr-configurados pelos fabricantes. Com a introduo
do JME, os aparelhos que o implementavam deixaram de ser estticos e tornaram-se
mais atrativos medida que os usurios poderiam adapt-los instalando ou mesmo
escrevendo suas prprias aplicaes[19].

37

Figura 10: Plataforma Java e suas edies


A plataforma JME define um conjunto de tecnologias e especificaes para ampliar
o alcance do Java em direo aos pequenos aparelhos. Desta maneira, seu foco est
nos dispositivos de consumo com limitaes de memria, tela e processamento, como
celulares, PDAs, pagers, entre outros. A plataforma baseada em trs elementos [20]:
As configuraes, que contm um conjunto bsico de bibliotecas e definies de
capacidades da JVM (Java Virtual Machine ou Mquina Virtual Java) para uma
ampla quantidade de dispositivos;
Os perfis, que definem um conjunto de APIs (Application Programming Interface
ou Interface de Programao de Aplicativos) para suporte a uma quantidade
mais restrita e especfica 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 diferena dos aparelhos em termos de capacidades de hardware, a
Sun os subdividiu em duas categorias: a dos pequenos dispositivos, ou seja, equipamentos com limitao de processamento e memria e a dos dispositivos com maiores
capacidades como smartphones e set-top boxes.
A categoria dos pequenos dispositivos est representada pela configurao CLDC
(Connected Limited Device Configuration, Configurao para dispositivos Conectados
e Limitados), onde esto includos pagers, celulares e PDAs. A configurao CDC
(Connected Device Configuration, Configurao para Dispositivos Conectados) representa os aparelhos mais robustos, normalmente set-top boxes para TVs, sistemas de
navegao para automveis e alguns PDAs com mais recursos [20].
Como as configuraes no provem suporte para o gerenciamento da aplicao,
como o controle da interface e acessos a informaes 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 especficas do que as presentes nas
configuraes. [17] O MIDP (Mobile Information Device Profile, Perfil de Dispositivo
de Informaes Mvel), por exemplo, o mais utilizado e complementa as funcionalidades da CLDC [21].
Alm dos perfis, existem os pacotes opcionais que so independentes de qualquer
tipo de dispositivo. Eles trazem APIs especficas 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 caracterstica. A figura 12[22]
mostra a diviso 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 atravs de
especificaes e para que elas sejam criadas necessria uma entidade que controle
todo o processo. Baseado nestas premissas existem o JCP (Java Community Process) e a JSR (Java Specification Request).
O JCP (Java Community Process) [22] uma comunidade representada pela Sun
e outros parceiros da indstria, que tem como objetivo manter a padronizao das
tecnologias que compem a plataforma. Atualmente, o JCP possui mais de 1200
membros, entre eles grandes empresas como IBM, Fujistu, Motorola, Borland e Oracle.
A JSR (Java Specification Request) um documento criado e enviado pelos membros
do JCP com proposta de desenvolvimento ou melhoria de uma tecnologia. Uma JSR
contm todas as caractersticas de determinado produto informando o que ele deve
contemplar. De posse dessas informaes, qualquer empresa pode definir sua prpria
implementao, desde que esteja condizente com sua respectiva especificao.
Todas as tecnologias que fazem parte da plataforma Java, desde a JVM passando
pelos servidores de aplicao, JSPs (JavaServer Pages) e Servlets at as Configuraes e Perfis presentes no JME so especificaes mantidas pelo JCP [23].

40

4.2.3 Configuraes
As configuraes definem a base de funcionalidades para dispositivos com caractersticas comuns, isto , especificam os recursos e classes presentes na JVM. Desta
forma, intermediam a comunicao entre o Perfil e a VM (Virtual Machine, sinnimo
de Java Virtual Machine - JVM) e sua especificao est diretamente ligada implementao de uma mquina virtual. Assim, cada configurao tem sua prpria VM [19].
A plataforma JME as divide em duas partes, separadas por capacidades de hardware dos dispositivos que suportam: CLDC e CDC ilustrados na figura 13.

Figura 13: Configuraes do JME

4.2.3.1 CLDC (Connected Limited Device Configuration)


A CLDC define as bibliotecas e especificaes da VM com o objetivo de suportar dispositivos com restries de processamento, memria, tela, entrada de dados e bateria
como celulares e PDAs. A CLDC trabalha em cima da KVM (Kilobyte Virtual Machine
- uma mquina virtual Java limitada), que foi projetada para consumir uma quantidade
mnima de memria por no poder implementar boa parte das caractersticas da JVM
padro [19] e [22].
Assim como toda tecnologia Java, a CLDC tambm uma especificao. Devido s
grandes mudanas no mercado mvel, tendo em vista o surgimento de novos recursos
e o aumento das capacidades dos aparelhos, sua especificao precisa acompanhar
esta evoluo. Atualmente, a CLDC est definida em duas especificaes: 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) no definiu qualquer

41

requisito mnimo de hardware alm do requisito de memria. Nesta especificao


esperado que a VM, as bibliotecas de Configuraes e Perfis e a aplicao tenham
entre 160KB e 512KB de memria. Mais especificamente possuam as seguintes caractersticas:
128KB de memria no-voltil para a VM e classes presentes na configurao.
32KB de memria voltil para suportar o armazenamento dos objetos durante a
execuo da aplicao.
Assim como a CDC, a CLDC baseada na plataforma JavaSE, logo, implementa algumas funes presentes nela. Porm, devido a limitaes impostas pelos aparelhos,
algumas tiveram que ser retiradas da verso 1.0 para economia de memria. Entre
elas: reflection, suporte a ponto flutuante, finalizao de objetos e tratamentos de excees derivadas da classe java.lang.Error. [24]
Para a verso 1.1 algumas caractersticas da especificao foram alteradas para se
adaptar s novas capacidades dos aparelhos. Para os requisitos mnimos de hardware
foi definido pelo menos 192KB de memria. Mais especificamente:
pelo menos 160KB de memria no-voltil para a VM e as bibliotecas definidas
na CLDC.
pelo menos 32KB de memria voltil para os objetos da aplicao.
Durante o tempo de uso da CLDC 1.0, percebeu-se que algumas caractersticas retiradas dessa JSR eram de extrema importncia para o desenvolvimento das aplicaes
e, logo, foram incorporadas verso 1.1. Entre elas, destaca-se o suporte a dados de
ponto flutuante. [25]
Por serem considerados muito grandes e complexos para dispositivos mveis, os
pacotes java.io e java.net presentes na plataforma JavaSE no 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 Sada de dados).
O GCF um framework usado para fazer conexes como HTTP, HTTPS, streams

42

e datagramas. Ele foi definido e includo na JSR 30 (CLDC 1.0), mas por ser amplamente flexvel possibilita que outros perfis e pacotes opcionais estendam sua base
e definam sua prpria implementao de conectividade, como mostrado na figura 14
[26].

Figura 14: Relacionamento entre as diferentes implementaes 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 implementao executada sobre a CVM (Compact Virtual Machine ou Mquina Virtual
Compacta), mquina virtual baseada na VM Java.
Por abranger dispositivos com maiores capacidades ela possui suporte completo da
plataforma JSE o que torna mais simples a adaptao de quem desenvolve e utiliza
ferramentas e recursos para desktops. Basicamente, os dispositivos suportados devem possuir um processador de 32bits, 2MB de memria voltil e 2.5MB de memria
no-voltil como requisito mnimo [28].
A CDC est especificada em duas JSRs, onde cada uma est baseada em uma verso do JavaSE. A JSR 36 (CDC 1.0) possui caractersticas da verso 1.3 e a JSR 218
(CDC 1.1.2) da 1.4.2.

4.2.4 Perfis
Mesmo pertencendo mesma configurao, os dispositivos ainda possuem algumas
diferenas entre si. Por exemplo, um celular e um PDA se encaixam nas especifi-

43

caes da CLDC, o que significa que compartilham caractersticas em comum. Porm,


mesmo sendo definidos como parte de uma mesma famlia ainda possuem tamanho
de tela diferente. Como soluo para esse problema foi introduzido pela Sun o conceito de perfil.
O perfil traz bibliotecas mais especficas para um grupo de dispositivos em particular. Existem diferentes perfis associados s configuraes 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 manipulao de interface, persistncia de dados e outros recursos especficos para o uso da aplicao. Atualmente, sua combinao com a configurao
CLDC define o ambiente mais utilizado nos aparelhos. [30]
O MIDP possui duas verses, 1.0 e 2.0, definidas nas especificaes JSR 37 e JSR
118. Ambas definem os mesmos requisitos mnimos de display e entrada de dados:
96x54 pixels e teclado ou tela touchscreen, respectivamente. A diferena fica com
base na disponibilidade de memria, onde o MIDP 1.0 define 128KB (memria novoltil alm da requerida pela CLDC), 8KB (memria no-voltil para dados armazenados pela aplicao) e 32KB (memria voltil para execuo) e a verso 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 no possuem capacidades grficas avanadas como parqumetro, aparelho de medida industrial e mdulos wireless em alarmes residenciais [34]. Atualmente permanece na verso 1.0 definida pela JSR 195. Os perfis associados CDC:
FP (Foundation Profile) [35]
Perfil sem muitas funcionalidades e o mais bsico da CDC, define API para dispositivos
desprovidos de interface grfica como impressoras de rede, roteadores e gateways e
em caso de necessidade de uma GUI (Graphical User Interface ou Interface Grfica do
Usurio), o FP pode ser integrado a um sistema que faa 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 grfica simples, como dispositivos para
automveis, incluindo uma verso leve da biblioteca grfica 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

WAP x JME

Durante o decorrer deste trabalho foi feita uma anlise minuciosa de cada tecnologia, buscando uma maior explorao de suas arquiteturas e funcionamentos para fins
comparativos. Com base nessas informaes 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 adoo:

5.1 Ambientes de Desenvolvimento


WAP: H vrias .ferramentas disponveis no mercado como Wapalize! WAP
Development Kit e WAPTor. Como h variao de caractersticas entre celulares
com suporte as diferentes verses do WAP e recursos do prprio aparelho, os
SDKs (Software Development Kit ou Kit de Desenvolvimento de Software) dos
fabricantes, como o Mobile Internet Toolkit 3.1 da Nokia.
JME: Possui suporte para desenvolvimento nas duas principais IDEs (Integrated
Development Environment ou Ambiente Integrado de Desenvolvimento) do mercado, NetBeans e Eclipse. Ambas oferecem excelente suporte aos emuladores
e disponibilizam ferramentas que auxiliam a criao de projetos. Alm desses
ambientes, a maior parte dos fabricantes de celulares disponibiliza seus SDKs
proprietrios oferecendo possibilidade de teste da aplicao 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 comunicao de diferentes formas,


desde HTTP e Sockets TCP a SMS e Bluetooth. Os tipos bsicos de conectividade so definidos no framework GCF, presente na plataforma.

5.3 Segurana de Informao


WAP: O WAP possui a camada WTLS que uma camada opcional que baseada
na SSL 3.0 que so protocolos da Internet. Esta camada fornece servios que
garantem privacidade, autenticao de servidor, autenticao de clientes e integridade de dados[40].
JME: Possui suporte a HTTPS, o que possibilita uso de comunicao segura
com SSL habilitada no servidor alm de disponibilizar APIs com suporte a certificados digitais para identificao segura e criptografia de dados como, por exemplo, o SATSA [41].

5.4 Acesso a Servio Local do Dispositivo


WAP: Os aplicativos WAP podem acessar os servios do aparelho por intermdio da WTAI (Wireless Telephony Application Interface ou Interface para Aplicao para Telefonia Sem Fio). "WTAI usada para acessar os servios que
esto presentes localmente no dispositivo-cliente ou na rede mvel"[40].
JME: A plataforma JME oferece um amplo suporte a acesso a recursos disponveis
em aparelhos que, so oferecidos por APIs especficas 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 Mvel


WAP: Desde a criao do WAP, as empresas associadas OMA (All Mobile
Alliance) provem em seus dispositivos suportes ao WAP. Atualmente, suportam
a verso 2.0 do WAP, mas mantendo compatibilidade com verses anteriores.
Entretanto, esta compatibilidade pode variar entre aparelhos ficando a deciso
por parte do fabricante;

47

JME: Atualmente a maior parte dos celulares fabricados chega aos consumidores com alguma implementao do JME, porm, dispositivos mais antigos
no provem esse suporte o que evita o uso da tecnologia para quem possui
modelos pouco recentes.

5.6 Frameworks
WAP: At o presente momento de realizao da pesquisa no foi encontrado
framework relevante para auxilio na construo de aplicativo WAP.
JME: Possui vrios frameworks disponveis para melhorar a produtividade no
processo de desenvolvimento. Alguns dos mais utilizados para aplicaes desktop e Web possuem verses ou semelhantes para JME. Por exemplo, Mobile
JUnit para testes unitrios, MEChart para gerao de grficos, Floggy para persistncia de dados, entre outros.

5.7 Persistncia de Dados


WAP: A persistncia de dados em aplicativos WAP realizada atravs da integrao de tecnologias como ASP (Active Server Pages), JSP (Java Server
Pages) e ColdFusion. A verso 2.0 do WAP possui uma interface de persistncia de dados para gravar e recuperar dados tanto do dispositivo mvel quanto de
um dispositivo de memria instalada.
JME: Amplas alternativas para persistncia. A CLDC trabalha com API do RMS
por padro, mas existe a possibilidade de utilizao do Floggy, framework que
abstrai a complexidade existente no seu uso. Para CDC as possibilidades so
ainda maiores como a utilizao de SGBDs (Sistema Gerenciador de Banco de
Dados) otimizados Oracle, Sybase e outros.

5.8 Interface com Usurio


WAP: A camada WAE prov elementos para o desenvolvimento visual como
WML que possui textos formatados (itlico, negrito e sublinhado) entrada de dados. Verses anteriores a 1.2.1 proviam textos e imagens (WBMP) em preto e

48

branco. A partir da verso 2.0 possvel 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 (verso mvel do CSS).
JME: Alm da API bsica, a plataforma tambm possui algumas bibliotecas de
componentes com recursos mais avanados como o LWUIT (oficial da SUN),
JavaPolish, J4ME. Outro recurso muito utilizado e, uma alternativa as citadas
bibliotecas, a criao de telas atravs de imagens vetoriais em SVG, onde os
componentes podem ser gerados atravs do mapeamento da imagem.
Para uma melhor visualizao das caractersticas das tecnologias apresentadas, a
tabela 1 exibe as comparaes:

49

Ambiente de
Desenvolvimento
RAD
Conectividade
Segurana de
Informao
Acesso Servio
Local
Compatibilidade

WAP

JME

NetBeans, Eclipse

IP, TCP e HTTP

HTTP, TCP, SMS


Bluetooth
HTTPS e bibliotecas
externas
JSR 75

Camada WTLS - SSL 3


Interface WTAI

Framework

Aparelhos com mini-browser e


suporte a WML/XHTML-MP
-

Persistncia de
Informao

Interao com ASP, JSP e


ColdFusion

Interface com
Usurio

KVM
Mobile JUnit, MEChart,
Floggy
Frameworks, SGBDs
otimizados

Verses anteriores a 1.2.1:


Linguagem WML, imagens WBMP
(imagem preto-e-branco), textos
formatados (itlico, negrito e
sublinhado)

LWUIT (oficial da
SUN), JavaPolish,
J4ME, imagens
vetoriais em SVG

A partir da verso 2.0:


Imagens GIF, JPEG e PNG, CSS
Mobile, linguagem xHTML-MP
Tabela 1: Comparao WAP x JME

5.9 Comparao entre JME e WAP


Tanto JME quanto WAP possuem pontos fortes e fracos. Alguns dos recursos mostrados na tabela 1 cumprem muito bem o seu papel para cada tecnologia, levando em
considerao suas diferenas. Tanto o WAP quanto o JME oferecem bons ambientes
de desenvolvimento, acesso a recursos especficos do aparelho celular e um slido
suporte conectividade.
A principal vantagem do WAP a sua disponibilidade na maior parte dos aparelhos celulares. Para oferecer suporte tecnologia, basta que o dispositivo possua
um simples micro-browser que interprete seus protocolos e, para JME, necessita da

50

implementao de suas especificaes, o que seria invivel para alguns com poucos
recursos de hardware. O ponto forte do JME a quantidade de recursos oferecidos
pela plataforma. Uma vez que o aparelho possui capacidade para suportar a tecnologia, pode-se explorar muitas caractersticas do dispositivo e, com WAP, seu leque de
possibilidades mais restrito.
Embasado por esta anlise comparativa decidiu-se adotar as duas tecnologias, de
forma a aproveitar suas caractersticas para alcanar reas distintas. Como um dos
principais objetivos do projeto tornar a aplicao disponvel para acesso na maior
parte dos celulares, uma vez que existem diferentes modelos de diferentes fabricantes
disponveis no mercado, o WAP foi escolhido para implementar uma soluo destinada
aos clientes da clnica. E, como os casos de uso para o ortodontista so diferentes
dos clientes, o JME ser adotado para desenvolver uma soluo especfica para o
mesmo, possibilitando focar maiores recursos s suas necessidades.

51

ESTUDO DE CASO: SISTEMA


MOBODONTO

Esta seo tem como objetivo apresentar o sistema proposto como estudo de caso.
Desta forma, sero descritos os principais processos, e etapas, envolvidos no seu
desenvolvimento, assim como uma discusso sobre arquitetura, padres e melhores
solues adotadas. Dentro dos processos citados incluem-se a fase de levantamento
de requisitos, anlise e projeto, responsveis por estabelecer um conhecimento maior
a respeito das particularidades do negcio.

6.1 Modelo de Desenvolvimento


Para auxiliar o desenvolvimento do sistema foi adotado o modelo em cascata. Segundo [42], o modelo em cascata define uma abordagem sistemtica e seqencial
que se inicia com a especificao dos requisitos pelo cliente e evolui ao longo do
planejamento passando pelas fases de modelagem, construo e implantao do software buscando garantir, ao final do processo, a qualidade do sistema. Este modelo
foi escolhido por ser um paradigma j consolidado no mercado alm de satisfazer as
necessidades do projeto devido baixa complexidade do sistema proposto aliado ao
fato dos requisitos serem bem definidos e pouco variveis.

6.2 Especificao de Requisitos


Segundo [43], a especificao de requisitos busca compreender o problema e levantar
todas as necessidades do futuro sistema a ser desenvolvido. Esta seo foi desenvolvida usando a tcnica de modelagem de casos de uso apresentando os diagramas
de caso de uso, descrio dos casos de usos identificados e o mini-mundo, sendo este
uma breve descrio do domnio do problema.

52

6.2.1 Descrio do Mini-Mundo


O gestor da clnica necessita fazer um controle de seus funcionrios e para isso deseja armazenar os dados como nome do funcionrio, data de nascimento, telefone
residencial, telefone celular, endereo, email e a funo exercida. Alm disso, precisa controlar seus parceiros mantendo seus dados armazenados como razo social,
nome fantasia, CNPJ, telefone, fax, endereo e contatos. A clnica tambm necessita
de um controle de seus clientes e, portanto deseja guardar o nome do cliente, data
de nascimento, telefone residencial, telefone comercial, telefone celular, endereo e
email.
Para melhor organizar os atendimentos aos clientes ser necessrio um agendamento
de consultas e, para tal objetivo, ser preciso conhecer o nome do cliente, o telefone,
o horrio e a data da realizao da consulta. Dessa maneira, complementando a necessidade citada acima, a clnica necessita visualizar uma agenda com as consultas
marcadas exibindo os horrios e pacientes envolvidos. Alm disso, preciso gerar
um relatrio de consultas e pacientes, como uma forma de agregao de informaes
para controle e possveis tomadas de decises estratgicas. O relatrio de consultas deve mostrar as consultas com suas respectivas datas e horrios, procedimento
realizado e nome do paciente. No relatrio de pacientes, devem ser mostradas informaes a respeito do mesmo como nome, telefone e endereo.
O gestor tambm requer um controle do seu financeiro. Para isso, precisa registrar
os pagamentos de consultas dos clientes e visualizar um relatrio contendo os valores pagos mensalmente.
A clnica necessita dispor uma forma de acesso para os clientes. Desta maneira, os
clientes devem poder visualizar suas consultas contendo as informaes sobre a data
e horrio marcados. Alm disso, como uma alternativa ao agendamento convencional
efetuado por telefone, devem poder sugerir o agendamento de consultas clnica enviando as datas e horrios disponveis para a marcao. Como forma de controlar
seus pagamentos, os clientes tambm precisam visualizar seu financeiro onde sero
mostrados os tratamentos atuais e um histrico dos pagamentos das parcelas referentes a eles. Alm disso, os clientes precisam visualizar seu correio de mensagens
onde sero recebidas mensagens enviadas pela clinica.

53

6.2.2 Modelo de Casos de Uso


Segundo [43], o modelo de caso de uso uma representao das funcionalidades
externamente observveis do sistema e dos elementos externos ao sistema que interagem com ele.
O sistema proposto foi subdividido em diagramas de pacotes que tem como propsito
prover uma viso de nvel mais alto do sistema mostrando sua decomposio em subsistemas, como mostrado na figura 15.

Figura 15: Diagrama de Pacotes


O sistema foi dividido em dois pacotes como uma forma de separar os elementos
relacionados ao Cliente dos relacionados Clnica. A diviso auxilia numa melhor
compreenso do domnio do problema, na reutilizao de componentes e tambm podendo ser tratados de forma separada na fase de projeto.
Pacote Cliente: contm todas as funcionalidades que sero utilizadas pelo cliente.
Pacote Clnica: contm todas as funcionalidades que sero utilizadas pela clnica.

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 Clnica.

54

Figura 16: Diagrama de Caso de Uso do Pacote Cliente

Figura 17: Diagrama de Caso de Uso do Pacote Clnica

6.2.4 Descrio dos Casos de Uso


Nesta seo os casos de uso de maior relevncia, mostrados nos diagramas da seo
6.1.3, so descritos.

55

6.2.4.1 Visualizar Consultas


Sumrio: Ator usa o sistema para visualizar todas as suas consultas marcadas.
Ator: Cliente.
Precondies: O ator estar identificado no sistema.
Fluxo Principal:
1. O ator solicita ao sistema a visualizao de suas consultas agendadas.
2. O sistema exibe as consultas com suas datas e horrios e o caso de uso termina.
6.2.4.2 Sugerir Consultas
Sumrio: Ator envia sugesto de data e horrio para agendamento de uma nova
consulta.
Ator: Cliente.
Precondies: O ator estar identificado no sistema.
Fluxo Principal:
1. O ator solicita ao sistema os horrios livres da semana para agendamento de
consulta.
2. O sistema exibe as datas e horrios disponveis para uma nova consulta.
3. O ator seleciona o dia e o horrio desejado.
4. O sistema armazena as informaes e o caso de uso termina.
6.2.4.3 Visualizar Correio
Sumrio: Ator visualiza seu correio contendo as mensagens enviadas pela clnica.
Ator: Cliente.
Precondies: O ator estar identificado no sistema.
Fluxo Principal:
1. O ator solicita ao sistema a visualizao do seu correio.
2. O sistema exibe a lista de mensagens existentes com seus respectivos ttulos.
3. O ator seleciona a mensagem que deseja visualizar.

56

4. O sistema exibe o contedo 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
Sumrio: Ator agenda consulta para um cliente no sistema.
Ator: Funcionrio/Dentista
Precondies: Ator estar identificado no sistema o cliente estar cadastrado no sistema.
Fluxo Principal:
1. O ator informa data e hora livres para agendamento e o nome do cliente que
deseja marcar a consulta.
2. O sistema armazena as informaes sobre a consulta.
3. O sistema envia mensagem de confirmao e caso de uso termina.
Pos-condies: A consulta desejada foi efetuada no sistema.
6.2.4.5 Visualizar Agenda
Sumrio: Ator visualiza todas as consultas que sero realizadas no dia.
Ator: Funcionrio/Dentista.
Precondies: O ator estar identificado no sistema.
Fluxo Principal:
1. O ator solicita ao sistema a visualizao das consultas do dia.
2. O sistema retorna a lista das consultas do dia com os horrios e clientes envolvidos 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-condies: As consultas solicitadas foram exibidas e podem ou no terem sido
excludas.
6.2.4.6 Emitir Relatrio de Consultas
Sumrio: Ator visualiza todas as consultas que sero realizadas no dia.
Ator: Funcionrio/Dentista.
Precondies: O ator estar identificado no sistema.
Fluxo Principal:
1. O ator solicita ao sistema a visualizao do relatrio de consultas agendadas em
um determinado intervalo de data.
2. O sistema retorna a lista das consultas com os horrios e clientes envolvidos.
Fluxo Alternativo (1) Visualizar consultas sugeridas:
1. O ator solicita ao sistema a visualizao do relatrio de consultas sugeridas em
um determinado intervalo de data.
2. O sistema retorna a lista das consultas com os horrios e clientes envolvidos.
Fluxo Alternativo (1) Visualizar consultas canceladas
1. O ator solicita ao sistema a visualizao do relatrio de consultas canceladas em
um determinado intervalo de data.
2. O sistema retorna a lista das consultas com os horrios e clientes envolvidos.
Pos-condies: As consultas solicitadas foram exibidas.

58

6.3 Especificao de Anlise


Segundo [43], a anlise corresponde fase onde realizado um estudo detalhado
dos requisitos levantados e ento construdos modelos que representam o sistema e
no sistema proposto ser utilizada a abordagem da Anlise Orientada a Objetos. Esta
seo ser dividida em trs partes: Diagramas de Classes, Diagramas de Estados e
Diagramas de Seqncias.

6.3.1 Diagrama de Classes


Segundo [43], o diagrama de classes representa a estrutura das classes de objetos
do sistema e suas relaes. As figuras 18 e 19 ilustram os diagramas de classes dos
pacotes Cliente e Clnica.

Figura 18: Diagrama de Classes do Pacote Cliente

59

Figura 19: Diagrama de Classes do Pacote Clnica

6.3.2 Diagrama de Estados


Segundo [44], o diagrama de estado mostra os estados e as transies 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 Seqncia


Segundo [44], o diagrama de seqncia define a interao entre objetos e enfatiza
mais a seqncia temporal que os relacionamentos estticos do objeto. As figuras 23,
24, 25, 26, 27 e 28 ilustram os diagramas de seqncia dos casos de usos descritos
na seo 6.1.4.

61

Figura 23: Diagrama de Seqncia do Caso de Uso Visualizar Consulta

Figura 24: Diagrama de Seqncia do Caso de Uso Sugerir Consulta

Figura 25: Diagrama de Seqncia do Caso de Uso Visualizar Correio

62

Figura 26: Diagrama de Seqncia do Caso de Uso Visualizar Agenda

Figura 27: Diagrama de Seqncia do Caso de Uso Agendar Consulta

Figura 28: Diagrama de Seqncia do Caso de Uso Emitir Relatrio de Consultas

63

6.4 Especificao de Projeto


Esta seo contm a Especificao de Projeto para o sistema MobOdonto. Esta seo
foi divida em seis partes. A primeira parte apresenta a uma viso das tecnologias
utilizadas pelo sistema. A segunda parte apresenta a arquitetura do sistema e sua
diviso em camadas, alm da discusso 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 seqncias revisados para a fase de projeto. A quinta parte apresenta o projeto de interface com
usurio onde sero apresentados cones, cores e mensagens utilizados no sistema.
A ltima parte mostra os diagramas de componente e implantao.

6.4.1 Tipo de Aplicao, Plataformas de Implementao, Tecnologias de Apoio e Hardware


O MobOdonto ser um aplicativo ambiente WEB com alguns mdulos que sero executados a partir de dispositivos mveis. As funcionalidades discutidas na especificao de anlise Visualizar Correio, Visualizar Consultas e Sugerir Consultas, pertencentes ao pacote Cliente, sero implementadas em WAP e a funcionalidade Visualizar
Agenda do pacote Clnica em JME. Essas implementaes tero como apoio as tecnologias apresentadas na tabela 2 abaixo.

Tecnologia
Linguagem de Programao
Linguagem de Marcao
SGBD
Tecnologias Auxiliares

Soluo
Java
XHTML, XHTML-MP
MySQL 5.0
Ajax

Tabela 2: Tecnologias

Para que o sistema funcione de maneira eficiente so necessrios alguns requisitos de


hardware e software. Abaixo so exibidas as tabelas que mostram todos os requisitos
que devem ser obedecidos para tal.

64

HardwareSoftware
Processador
Memria RAM
Servidor Web
Servidor de Aplicao Java

Requisito
x86
512MB
Apache 2.2
GlassFish v2

Tabela 3: Requisitos para o mdulo Web

Tecnologia
WAP
JME

Compatibilidade
WAP 2.0
Nenhuma mensagem

Tabela 4: Requisitos para mdulo Mvel

6.4.1.1

Framework Ajax

Para fins de melhorias nas requisies e respostas feitas pelas pginas Web ao servidor, foi desenvolvido um framework Ajax de pequeno porte que viabiliza essa melhoria. Como conseqncia, a aplicao estar se livrando de recargas de pginas
inteiras quando se pressiona um boto ou se digita um valor tornando-se, assim, em
um aplicativo mais rpido fazendo o usurio sentir-se como se estivesse trabalhando
em um sistema desktop dinmico.
Alm de eliminar as incmodas recargas de pginas, o JavaScript do framework se comunica com o servidor Web assincronamente. Em outras palavras, o cdigo JavaScript
far uma solicitao ao servidor, mas o usurio poder inserir dados em formulrios
Web e at mesmo clicar em botes - tudo isso enquanto o servidor Web estiver trabalhando em segundo plano. Em seguida, quando o servidor tiver terminado o processo, o framework dar suporte para atualizar apenas a parte da pgina que requer mudanas. Assim, o framework combina o poder das solicitaes assncronas
com a atualizao de pginas sem recargas tendo um aplicativo Web responsivo e
dinmico.Assim como mostra a figura 29, o framework envia as solicitaes, independente do navegador de Internet, via JavaScript para o servidor e sua resposta s ter
os dados que a pgina precisa, sem qualquer marcao ou apresentao.

65

Figura 29: Comunicao entre as pginas Web e o servidor


A comunicao entre as pginas Web e o servidor realizada com uso do formato
JSON (Javascript Object Notation), que, em linhas gerais, construdo com base em
uma coleo de pares chave/valor que definem propriedades e seus valores e, que
uma alternativa ao tradicional XML (eXtensible Markup Language). Segundo [45],
para enviar informaes entre uma pgina Web e um servidor, precisar de alguma
maneira de format-las sendo o JSON uma maneira de enviar e retornar dados e sua
escolha dada pela complexidade do aplicativo e pela equipe de desenvolvedores. Assim, foi adotado o formato JSON por apresentar maior facilidade de montagem dos
pacotes de dados em relao ao formato XML.
A atualizao das pginas Web realizada utilizando o HTML DOM (Document Object
Model) que um padro W3C (World Wide Web Consortium). Segundo [46], o HTML
DOM define um conjunto padro de objetos de HTML, e uma forma padro de acessar
e manipular documentos HTML. Todos os elementos HTML, juntamente com os seus
atributos, podem ser acessados atravs do DOM. O contedo pode ser alterado ou
suprimido, e novos elementos podem ser criados, independente da plataforma.
6.4.1.2 SSL e Certificado Digital
Visando maior segurana no trfego das informaes entre as pginas Web, as informaes sero criptografadas por certificados digitais SSL (Secure Sockets Layer ).
Segundo [47], SSL uma tecnologia de segurana que comumente utilizada para
codificar os dados trafegados entre o computador do usurio e um site da Internet.
O protocolo SSL, atravs 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 usurio e o site com o qual ele est se relacionando,
garantindo desta forma que informaes sigilosas possam ser trafegadas com segurana.
Segundo [48], O certificado digital um documento eletrnico que tem como aspecto
principal duas chaves: uma pblica, que de conhecimento geral, e outra privada,
que deve ser mantida em sigilo e com toda a segurana pelo titular do certificado.
Esse par de chaves tem uma srie de caractersticas importantes. Primeiramente, a
tecnologia utilizada na gerao dessas chaves a chamada "criptografia assimtrica",
que o mtodo mais comum para autenticar transaes conduzidas pela Internet. Em
segundo lugar, embora elas sejam matematicamente relacionadas, impossvel calcular uma chave a partir da outra. Da, a denominao de "assimtricas". Terceiro,
uma chave desempenha a funo inversa da outra: o que uma delas faz, somente a
outra pode desfazer. Por exemplo, a chave privada usada para assinar o contedo
de um documento, enquanto a chave pblica usada para validar essa assinatura.
O certificado digital obtido de uma autoridade certificadora e contm o nome do
titular (pessoa fsica ou jurdica), o nmero de srie, a data da sua validade, a chave
pblica do titular e a assinatura (eletrnica) da Autoridade Certificadora, que garante o
prprio certificado. Ou seja, devido aos certificados digitais, uma transao eletrnica
realizada via internet torna-se mais segura, pois permite que as partes envolvidas apresentem cada uma, as suas credenciais para comprovar, outra parte, a sua real
identidade.

6.4.2 Arquitetura do Sistema


A figura 30 ilustra a arquitetura do sistema utilizando diviso em pacotes. O diagrama
de pacotes o mesmo ilustrado na especificao de anlise com a nica diferena de
que foi inserido o novo pacote Utilitrio que ajudar na reutilizao de componentes no
sistema proposto e em outros contextos. As dependncias entre os pacotes tambm
so as mesmas com diferena de que os pacotes Cliente e Clnica fazem requisio
de servios para o novo pacote incorporado ao diagrama.

67

Figura 30: Arquitetura do Sistema

6.4.3 Arquitetura em Camadas


Os pacotes Clnica e Cliente, ilustrados na figura 30, foram decompostos em novos
pacotes sendo eles: Domnio do Problema (DP), Gerncia de Tarefas (GT), Gerncia
de Dados (GD) e Interface com o Usurio (IU) de acordo com o modelo MVC Estendido [49] e tendo suas classes identificadas por esteretipos. Essa abordagem deu
origem a novos diagramas de pacotes, ilustrados nas figuras 31 e 32, e que o contedo destes sero discutido nas prximas subsees.

Figura 31: Arquitetura em Camadas do Pacote Cliente

68

Figura 32: Arquitetura em Camadas do Pacote Clinica


A dependncia entre os pacotes, ilustrados nas figuras 31 e 32, mostram a requisio
de servios para realizao das funcionalidades do sistema. Esta diviso em pacotes
foi baseada usando o padro arquitetural MVC Estendido que tem como objetivo criar
uma independncia e diviso de responsabilidades entre as partes que envolvem o
sistema. Desta forma obtm-se uma maior coeso entre as classes do sistema facilitando possveis mudanas em qualquer uma das camadas.
6.4.3.1 Domnio do Problema (DP)
O pacote de domnio do problema o local onde esto contidas as classes, suas
multiplicidades e associaes que modelam o domnio do problema. As figuras 33 e 34
apresentam o diagrama de classes do domnio do problema DP_Cliente e DP_Clnica
sendo relativos aos pacotes Cliente e Clnica, respectivamente.

69

Figura 33: Diagrama de Classes do Pacote DP_Cliente

70

Figura 34: Diagrama de Classes do Pacote DP_Clnica

6.4.3.1.1 Consideraes
A modelagem de classes para o contexto de endereo pode ser construda de vrias
maneiras, mas, preferencialmente, deve ser passvel de atualizao com a base dos
Correios. As atualizaes so realizadas freqentemente e uma possvel modelagem
seria essa como apresentada na figura 35.

Figura 35: Modelo baseado na escolha do endereo


O modelo acima apresenta algumas caractersticas como:
necessria a escolha do endereo manualmente bem como a insero dos

71

dados referentes classe Complemento e os dados referentes ao CEP so buscados automaticamente;


Caso um nmero de CEP ou endereo no existam, estes podero ser cadastrados na base
Evita dados redundantes entre Endereo e Complemento, pois um endereo
pode ou no possuir um complemento associado. Diferente se os campos da
classe Complemento estivessem na classe Endereo, neste caso, existiriam dados nulos ou redundantes;
Eficincia por busca de dados pode ser comprometida por conseqncia da complexidade da estrutura;
Apresenta problemas em uma atualizao da base disponibilizada pelos Correios. Os nmeros de CEP cadastrados manualmente podem ser sobrescritos
ou no pelos novos.
Outra forma de modelagem dessa estrutura a mostrada na figura 36.

Figura 36: Modelo baseado na escolha do endereo e CEP


Este modelo apresenta algumas caractersticas como:
So necessrias as escolhas do nmero do CEP e do Endereo manualmente
bem como a insero dos dados referentes classe Complemento;
Caso um nmero de CEP ou endereo no existam, estes podero ser cadastrados na base
Evita dados redundantes entre Endereo e Complemento, pois um endereo
pode ou no possuir um complemento associado. Diferente se os campos da
classe Complemento estivessem na classe Endereo, neste caso, existiriam dados nulos ou redundantes;

72

Eficincia por busca de dados pode ser comprometida por conseqncia da complexidade da estrutura;
Apresenta problemas em uma atualizao da base disponibilizada pelos Correios. Os nmeros de CEP cadastrados manualmente podem ser sobrescritos
ou no pelos novos.
Aps estudos realizados, a modelagem que apresentou mais eficincia com atualizaes e respostas s buscas mostrado na figura 37.

Figura 37: Modelo baseado na escolha do CEP


Este modelo apresenta algumas caractersticas como:
necessria apenas a escolha do nmero do CEP. Os dados referentes s
classes de Cidade, Bairro e CEP so armazenados na classe Cliente;
A redundncia dos dados, nas classes Funcionrio e Cliente, tm por finalidade
deixar a base de CEP atualizada de acordo com a fornecida pelos Correios.
Assim, atualizaes fornecidas pelo rgo podem ser realizadas sem comprometimento dos dados j utilizados;
Caso um nmero de CEP no exista, os novos dados podem ser cadastrados na
classe Cliente deixando a base de acordo com a fornecida pelos Correios;
Alta eficincia na busca de dados por conseqncia da complexidade da estrutura.
Visando a segurana da informao 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: Permisso de acesso

Figura 39: Classe responsvel pela auditoria


Uma forma de proteo contra divulgao indevida de informaes fazer uso do controle de acesso dos usurios s funcionalidades do sistema. Como mostra a figura 38,
as classes de Rotina, de Funo e de Permisso fazem o controle de todos os acessos s funcionalidades para cada grupo de acesso. Desta forma, possvel controlar
o contedo que cada grupo ter acesso com facilidade de manuteno dessas regras.
Uma prtica comum de segurana em sistemas de informao a adoo de auditoria que, no sistema proposto, consiste em armazenar as alteraes feitas pelo usurio
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 alterao bem como o tipo
de funcionalidade que foi acessada - incluso, alterao ou excluso. A classe guarda
ainda a descrio dos dados alterados, o horrio que o evento ocorreu e o usurio
que realizou o acesso atravs de seu cdigo atribudo pela classe Token. Classe essa
responsvel por armazenar o cdigo do usurio e o seu horrio de entrada no sistema.
A auditoria pode ser implantada em funcionalidades que forem necessrias e por determinadas aes. A classe Tabela, como mostra a figura 40, tem a especialidade de
controlar o ltimo cdigo da chave primria de cada tabela do banco de dados, bem
como sinalizar qual mtodo ser auditado, ou seja, qual dentre os mtodos de incluir,
alterar e excluir a auditoria armazenar informaes.

74

Figura 40: Classe Tabela


6.4.3.2 Gerncia de Tarefas (GT)
No pacote de gerncia de tarefas esto as classes que lidam com as regras de negcio
do sistema. As figuras 41 e 42 apresentam as classes para os pacotes GT_Cliente e
GT_Clnica respectivamente.

Figura 41: Diagrama de Classe do Pacote GT_Cliente

Figura 42: Diagrama de Classe do Pacote GT_Clinica

6.4.3.2.1 Padro de Projeto Facade


Nos diagramas mostrados nas figuras acima, foi utilizado o padro de projeto Facade. Segundo [50], o padro Facade busca simplificar o uso de um sistema complexo
definindo uma interface especializada e simples, reduzindo o nmero de objetos com
os quais o objeto cliente deve lidar. Seu uso reduz problemas futuros na manuteno
da aplicao, uma vez que o cliente ter apenas a viso da classe responsvel pela
implementao do Facade, no sofrendo impacto por possveis alteraes nas classes
de controle. Abaixo so exibidos dois diagramas onde a figura 43[50] representa um

75

diagrama onde no utilizado o padro e a figura 44[50] outro em que includo seu
uso.

Figura 43: Exemplo de diagrama sem o uso do padro Facade

Figura 44: Exemplo de diagrama usando o padro Facade


Como resultado de estudo do padro de projeto facade, os diagramas ilustrados nas
figuras 41 e 42 foram reformulados para contemplar a utilizao deste padro. As figuras 45 e 46 ilustram respectivamente os diagramas de classe dos pacotes GT_Cliente
e GT_Clinica.

Figura 45: Diagrama de Classe do Pacote GT_Cliente reformulado

76

Figura 46: Diagrama de Classe do Pacote GT_Clinica reformulado

6.4.3.3 Gerncia de Dados (GD)


No pacote gerncia de dados esto as classes responsveis por realizarem a persistncia das informaes 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_Clnica

6.4.3.3.1 Padro de Projeto Singleton


O padro de projeto Singleton tem como objetivo garantir a existncia de apenas uma
instncia de uma determinada classe em qualquer ponto do sistema [51]. Baseado
nesta definio, o padro foi adotado para evitar a criao desnecessria de objetos,
pois a cada conexo realizada com o banco de dados um objeto diferente era criado
causando desperdcio de memria. Como resultado de estudo do padro de projeto
Singleton, os diagramas ilustrados nas figuras 47 e 48 foram reformulados para contemplar a utilizao deste padro. 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_Clnica reformulado

6.4.3.3.2 Modelo de Entidade e Relacionamento (MER)


O sistema MobOdonto utilizar um banco de dados relacional para a persistncia de
dados e, assim, foi necessrio realizar o mapeamento Objeto-Relacional. O Modelo
de Entidade e Relacionamento foi dividido em duas figuras para melhor interpretao
de seu contedo. As figuras 51 e 52 ilustram o modelo de entidade e relacionamento.
Para a criao 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 Usurio (IU)


As figuras 53 e 54, respectivamente, apresentam os diagramas de classes referentes
ao componente de Interface com o Usurio do pacote Clnica e Cliente.

Figura 53: Diagrama de Classe do Pacote IU_Cliente

Figura 54: Diagrama de Classe do Pacote IU_Clnica

6.4.4 Pacote Utilitrios


Este pacote contm as classes e pacotes comuns aos pacotes Cliente e Clnica e
sero descritos a seguir de forma breve.
6.4.4.1 Banco
Contm a classe cheque para tratar da manipulao de cheques. A figura 55 apresenta o pacote Banco.

82

Figura 55: Diagrama de Classe do Pacote Banco


Apesar de este pacote possuir apenas uma classe, novas classes podem ser incorporadas para contemplarem outros contextos em outras aplicaes.
6.4.4.2 Login
O pacote Login contm todas as classes que tratam os aspectos relacionados segurana dentro do sistema.

Figura 56: Diagrama de Classe do Pacote Login

83

6.4.4.3 Pessoa
O pacote Pessoa contm as classes para tratar as informaes relacionadas ao endereo de uma pessoa.

Figura 57: Diagrama de Classe do Pacote Pessoa

6.4.4.4 DAO
O pacote DAO contm as classes reutilizveis que so responsveis pela persistncia
de dados e auxiliam a execuo 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 Utilitrio DAO

6.4.5 Diagrama de Seqncia


Os diagramas de seqncia apresentados na especificao de anlise foram reformulados para contemplar a arquitetura em camadas proposta na seo 6.3.3 deste

84

documento. Os diagramas para os casos de uso Sugerir Consulta, Visualizar Consulta e Visualizar Correio do pacote Cliente e o caso de uso Visualizar Agenda, Agendar Consulta e Emitir Relatrio de Consultas do pacote Clnica sero apresentados
respectivamente nas figuras 59, 60, 61, 62, 63 e 64.

Figura 59: Diagrama de Seqncia do Caso de Uso Visualizar Consulta

Figura 60: Diagrama de Seqncia do Caso de Uso Sugerir Consulta

Figura 61: Diagrama de Seqncia do Caso de Uso Visualizar Correio

85

Figura 62: Diagrama de Seqncia do Caso de Uso Visualizar Agenda

Figura 63: Diagrama de Seqncia do Caso de Uso Agendar Consulta

Figura 64: Diagrama de Seqncia do Caso de Uso Emitir Relatrio de Consultas

6.4.6 Padres de Interface


Para auxiliar a usabilidade do sistema por parte do usurio, textos, cones, cores e
mensagem podem ser utilizados. Esta seo mostrar os itens, citados anteriormente,
que sero utilizados no sistema proposto. Esta seo foi dividida em trs partes sendo
elas: cones, Cores e Mensagem.

86

6.4.6.1 cones
Para auxiliar na navegabilidade e identificao de funcionalidades presentes no sistema, a figura 65 mostra os cones utilizados e suas respectivas funcionalidades as
que esto relacionados.

Figura 65: cones

6.4.6.2 Cores
Para que o usurio esteja alerta e tenha facilidade de leitura sobre os dados apresentados no sistema, a tabela 5 mostra uma lista de cores e suas respectivas funcionalidades utilizadas no desenvolvimento do sistema.

Item
Mensagens de alerta
Texto padro
Plano de fundo
Hiperlink
Hiperlink visitado

Cdigo Hexadecimal
FF0000
000000
FFFFFF
FFFFFF
0000CC

Tabela 5: Cores

As cores mostradas na tabela acima esto utilizando o padro de cores no formato


RGB.
6.4.6.3 Mensagens
O usurio precisa estar ciente de que todas suas funcionalidades foram executadas
e tambm se toda informao apresentada, persistida, excluda e alteradas obtiveram
sucesso ou insucesso em suas execues no sistema. A tabela 6 apresenta as mensagens utilizadas.

87

Ao
Visualizar Mensagem
Visualizar Mensagem
Acesso ao Banco de Dados
Excluir Mensagem
Excluir Mensagem
Visualizar Agenda
Visualizar Agenda

Mensagem
Erro ao exibir mensagem
Nenhuma mensagem
Erro ao acessar banco de dados
Mensagem excluda com sucesso
Erro ao excluir mensagem
Erro ao exibir agenda
Nenhuma consulta agendada

Tabela 6: Mensagens do Sistema

6.4.6.4 Diagrama de Navegabilidade


Segundo [52], o diagrama de navegabilidade mostra a navegao entre as diferentes
funcionalidades do sistema, isto , apresenta a seqncia em que as telas ou janelas
do sistema podem ser navegadas pelo usurio para o mesmo realize as funcionalidades representadas pelos casos de uso definidos para cada pacote do sistema. A
figura 66 apresenta o diagrama para o pacote Cliente e a figura 67 para o pacote
Clnica.

Figura 66: Diagrama de Navegabilidade do Pacote Cliente

88

Figura 67: Diagrama de Navegabilidade do Pacote Clnica


6.4.6.5 Aspectos de Usabilidade e Eficincia
Segundo [53], os aspectos referentes usabilidade so definidos para mostrar a relao de interao entre o usurio e o sistema mostrando os nveis de efetividade,
satisfao, facilidade de uso e aprendizado do sistema desenvolvido.
Devido s vrias limitaes provenientes da utilizao dos dispositivos mveis, o sistema procura empregar o uso de boas prticas que auxiliem usabilidade. Todos os
componentes buscam ser objetivos procurando diminuir o esforo necessrio para realizar determinada tarefa e todas as aes do sistema possuem nomes diretos e sugestivos para uma maior compreenso do que ser feito quando o mesmo for acionado
evitando um tempo maior na resposta e na realizao da tarefa desejada pelo usurio.
As tabelas 7 e 8, mostram as estimativas de eficincia relacionadas ao tempo de
resposta dos casos de uso dos pacotes Cliente e Clnica.

89

Caso de Uso
Visualizar correio
Visualizar consultas
Sugerir consultas

Freqncia de Utilizao
10dia
50dia
5ms

Tempo Mximo Esperado


5 segundos
5 segundos
3 segundos

Tabela 7: Eficincia dos Casos de Uso do Pacote Cliente


Caso de Uso
Visualizar agenda
Agendar consulta
Emitir relatrio de
consultas

Freqncia de Utilizao
5dia
10dia
3ms

Tempo Mximo Esperado


3 segundos
5 segundos
10 segundos

Tabela 8: Eficincia dos Casos de Uso do Pacote Clinica

6.4.7 Diagrama de Componentes


Segundo [43], o diagrama de componentes mostra os vrios componentes de software
do sistema e suas respectivas dependncias. Cada componente possui elementos
que definem uma funcionalidade dentro do sistema visando reutilizao. A figura 68
ilustra o diagrama de componentes do sistema.

Figura 68: Diagrama de Componentes do Sistema MobOdonto

6.4.8 Diagrama de Implantao


Segundo [43], o diagrama de implantao representa a topologia fsica do sistema e,
opcionalmente, os componentes que so executados nela. Atravs deste diagrama
possvel ter uma viso da estrutura necessria para implantao do sistema.

90

Figura 69: Diagrama de Implantao do Sistema MobOdonto

6.4.9 Prottipo
Nesta seo sero apresentados os prottipos das telas do sistema MobOdonto contemplando as funcionalidades escolhidas e estudas para o cumprimento dos objetivos
discutidos na seo 3 deste documento. Para a verso WAP, as figuras 70, 71, 72
ilustram as telas para as respectivas as funcionalidades: Login, Visualizar Correio, Visualizar Consultas. As figuras 73 e 74 ilustram a funcionalidade Sugerir Consulta. A
tela principal que d acesso a essas funcionalidades ilustrada na figura 74. As figuras foram feitas com auxlio do simulador WAP Proof. A figura 71 ilustra a utilizao
de abreviao de informao devido resoluo 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 horrio disponvel

92

Figura 75: Tela principal


Para a verso 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 auxlio da IDE Eclipse utilizando o
emulador disponvel no JME SDK 3.0.

Figura 76: Tela principal para seleo da funcionalidade

Figura 77: Funcionalidade Visualizar Consultas: Escolha do horrio

93

Figura 78: Funcionalidade Visualizar Consultas: Visualizando dados do cliente


Para a verso Web, as figuras 79 e 80 ilustram as telas para as respectivas as funcionalidades: Login e Visualizar Consultas. Todas as figuras foram feitas com auxlio
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 trs tecnologias distintas para apresentar
suas informaes geradas ao usurio. Os mdulos propostos WEB, WAP e JME utilizam respectivamente JSON, HTML e XML para representao dessas informaes.
Neste contexto foi identificada a necessidade do desenvolvimento de um componente
(wrapper ), que possui a responsabilidade na identificao, interpretao, converso
e o envio das informaes que devem ser apresentadas em cada um dos mdulos
mencionados, como sendo a soluo para a situao. 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 incio nesta seo at agora, temos a figura 82 ilustrando a integrao 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 mdulos feita a requisio ao sistema para realizao de determinada tarefa. Estas requisies so centralizadas em uma Servlet que as recebe e de acordo com o que foi solicitado, redireciona para a camada de controle que contm a implementao correta do padro
Facade para que o sistema que realiza a tarefa. O resultado da requisio feita por um
dos mdulos ento retornada para a Servlet que identifica de qual mdulo originouse a requisio acionando assim a respectivo wrappers (empacotador) para realizar
o tratamento dos dados resultantes da requisio para que o mdulo apresente as
informaes ao usurio.

96

CONCLUSO

Esta seo tem como objetivo apresentar as consideraes finais do projeto proposto,
citar as dificuldades encontradas durante todo o processo de desenvolvimento do sistema, mostrar os retornos de aprendizado e experincia obtidos, alm de levantar
possveis melhorias e incrementos de forma a tornar o projeto mais robusto.

7.1 Concluso 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 necessria para um controle administrativo
utilizando a mobilidade oferecida pela Internet.
Desta forma, a implementao de um ambiente de servios via Web que aperfeioe e
flexibilize o atendimento aos pacientes do consultrio tomando como base para a escolha das melhores prticas e ferramentas de desenvolvimento, atravs de pesquisas,
foi alcanada com sucesso superando, assim, o inicialmente almejado.

7.2 Dificuldades Encontradas


No desenvolvimento do mdulo Web ocorreram dificuldades para encontrar ferramentas e componentes visuais que utilizassem a tecnologia Ajax e, ao mesmo tempo, que
fossem passveis de rpido aprendizado e de fcil manuteno. Assim como ocorreu
no desenvolvimento do mdulo JME em encontrar componentes visuais que no comprometessem no desempenho da aplicao dando, ao mesmo tempo, uma agradvel
experincia de uso do sistema ao usurio.

97

Outro percalo foi encontrar um software simulador do ambiente WAP que fosse gratuito. A maioria encontrada no mercado oferece mais limitaes do que funcionalidades
propriamente ditas restringindo, assim, a visualizao dos resultados do desenvolvimento desse mdulo. Na comunicao dos mdulos de celulares com o servidor de
aplicao 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 propsito.

7.3 Retorno Para o Grupo


Com o desenvolvimento deste projeto houve um ganho de conhecimento e de experincia significativos na rea de levantamento de requisitos, analise, projeto, implementao e testes no desenvolvimento de uma soluo em Web, WAP e JME - tecnologias
em evidncia nos dias atuais.
Alm de ter existido a oportunidade de realizao de pesquisa e desenvolvimento
da soluo em ambiente real, o que acentua a curva de aprendizado dos membros do
grupo criando, tambm, como fruto de toda pesquisa uma ferramenta comercializvel
destinada a consultrios odontolgicos.

7.4 Trabalhos Futuros


Como continuidade das pesquisas e desenvolvimento possvel a adoo do uso de
tecnologias como o Bluetooth em um caso de uso adicional no pacote Clnica para
o ortodontista uma vez que a API da JSR-82 para JME seria a mais vivel. Como
caso de uso para usufruir desta tecnologia, o cadastro de uma consulta poder ser
feita com a persistncia desses dados na memria do dispositivo mvel e, em um
momento oportuno, essas informaes podero 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 padres
comuns, ou que sejam prximos, em aparelhos que contemplem a tecnologia para
o desenvolvimento da soluo destinado a estes padres 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 componentes no comprometendo o desempenho do sistema.

99

REFERNCIAS
[1] UOL.
Brasil

11o
pas
em
nmero
de
internautas.
Acessado
em:
16
out.
2008.
Disponvel
em:
<http://tecnologia.uol.com.br/ultnot/bbc/2007/03/06/ult4449u5.jhtm>.
Em
dois
anos,
nmero
de
internautas
residenciais
[2] FOLHA.
cresce 78% no Brasil. Acessado em 20/10/2008. Disponvel em:
<http://www1.folha.uol.com.br/folha/informatica/ult124u451040.shtml>.
[3] UOL. iPhone 3G: 11 aplicativos que voc precisa conhecer. Acessado em
20/10/2009. Disponvel em: <http://idgnow.uol.com.br/telecom/2008/06/13/iPhone3g-11-aplicativos-que-voce-precisa-conhecer>.
[4] UOL.
Conhea
10
aplicativos
que
venceram
o
Android
veloper
Challenge.
Acessado
em
20/10/2009.
Disponvel
<http://idgnow.uol.com.br/telecom/2008/09/10/conheca-10-aplicativos-quevenceram-o-android-developer-challenge>.

Deem:

[5] UOL. A Histria do Celular. Acessado em 20/10/2008. Disponvel em:


<http://idgnow.uol.com.br/galerias/idgphotoalbum.2006-02-03.9367726313>.
[6] UOL.
Celulares
passam
de
140
milhes
Brasil.
Acessado
em
20/10/2008.
Disponvel
<http://www1.folha.uol.com.br/folha/informatica/ult124u451040.shtml>.

no
em:

[7] UOL.
Brasil
lidera
uso
da
web
no
celular
na
Amrica
Latina,
diz
pesquisa.
Acessado
em
20/10/2008.
Disponvel
em:
<http://www1.folha.uol.com.br/folha/informatica/ult124u451040.shtml>.
3G.
Acessado
[8] WIKIPEDIA.
<http://pt.wikipedia.org/wiki/3G>.

em

20/10/2008.

Disponvel

em:

[9] UOL. Por que as empresas de internet querem invadir o seu celular? Acessado
em 16/10/2008. Disponvel em: <http://idgnow.uol.com.br/telecom/2008/02/27/porque-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
<http://pt.wikipedia.org/wiki/Proxy>.

em

15/05/2009.

Disponvel

em:

[12] MICROSYSTEMS, I. S. Developer Resources for Java Technology. Acessado em


18/10/2008. Disponvel em: <http://java.sun.com>.

100

[13] MICROSYSTEMS, I. S. Java Technology: The Early Years. Acessado em


20/10/2008. Disponvel em: <http://java.sun.com/features/1998/05/birthday.html>.
[14] TIOBE.
Visual
Programming
Languages
ular.
Acessado
em
20/10/2008.
Disponvel
<http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html>.

Popem:

[15] MICROSYSTEMS, I. S. Java SE Overview. Acessado em 20/10/2008. Disponvel


em: <http://java.sun.com/javase/>.
[16] MICROSYSTEMS, I. S. Java EE at a Glance. Acessado em 20/10/2008.
Disponvel em: <http://java.sun.com/javaee>.
[17] MICROSYSTEMS, I. S. Java ME: the Most Ubiquitous Application
Platform for Mobile Devices. Acessado em 20/10/2008. Disponvel em:
<http://java.sun.com/javame>.
[18] DEVMEDIA.
CONCEITOS
BASICOS
DAS
PLATAFORMAS
JAVA
E
J2ME.
Acessado
em
20/10/2008.
Disponvel
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.
Disponvel em: <http://java.sun.com/javame/technology/index.jsp>.
[21] MICROSYSTEMS,
I.
S.
Connected
Limited
figuration
(CLDC).
Acessado
em
25/10/2008.
<http://java.sun.com/products/cldc/overview.html>.

Device
Disponvel

Conem:

[22] MICROSYSTEMS,
I.
S.
Survey
of
Java
ME
day
(Update).
Acessado
em
25/10/2008.
Disponvel
<http://developers.sun.com/mobility/getstart/articles/survey/>.

Toem:

[23] PROCESS, J. C. General JCP Questions. Acessado em 25/10/2008. Disponvel


em: <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
Connection
Framework.
Acessado
em
26/10/2008.
Disponvel
em:
<http://developers.sun.com/mobility/midp/articles/genericframework>.
[27] MICROSYSTEMS, I. S. Java ME Technology - CDC. Acessado em 26/10/2008.
Disponvel 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 em
27/10/2008. Disponvel em: <http://java.sun.com/products/midp/>.

101

[30] MICROSYSTEMS, I. S. Summary of CLDC-Based Profiles. Acessado em


26/10/2008. Disponvel 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 em
27/10/2008. Disponvel em: <http://java.sun.com/products/imp>.
I.
S.
Understanding
the
Java
[34] MICROSYSTEMS,
form
Architecture.
Acessado
em
25/10/2008.
Disponvel
<http://www.sun.com/software/opensource/java/intro_java_tech.jsp>.

Platem:

[35] MICROSYSTEMS, I. S. Foundation Profile Overview. Acessado em 27/10/2008.


Disponvel em: <http://java.sun.com/products/foundation/overview.html>.
[36] PROCESS, J. C. JSR 46: Foundation Profile. Acessado em 27/10/2008.
Disponvel em: <http://jcp.org/en/jsr/detail?id=46>.
[37] PROCESS, J. C. JSR 219: Foundation Profile 1.1. Acessado em 27/10/2008.
Disponvel em: <http://jcp.org/en/jsr/detail?id=219>.
[38] MICROSYSTEMS,
I.
S.
Personal
Basis
Overview.
Acessado
em
27/10/2008.
Disponvel
<http://java.sun.com/products/personalbasis/overview.html>.

Profile
em:

[39] MICROSYSTEMS, I. S. Personal Profile Overview. Acessado em 27/10/2008.


Disponvel em: <http://java.sun.com/products/personalprofile/overview.html>.
[40] WIKIPEDIA.
WAP.
Acessado
<http://pt.wikipedia.org/wiki/Wap>.

em

20/10/2009.

Disponvel

em:

[41] MICROSYSTEMS, I. S. Security and Trust Services API for J2ME (SATSA). Acessado em 27/10/2008. Disponvel 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.]: Elsevier, 2006.
[44] PAGE-JONES, M. Fundamentos do Desenho Orientado a Objetos. [S.l.]: Makron
Books, 2001.
[45] WIKIPEDIA. JavaScript HTML DOM Objects. Acessado em 18/05/2009.
Disponvel em: <http://www.w3schools.com/js/js_obj_htmldom.asp>.
[46] MCLAUGHLIN, B. Use a Cabea! Iniciao Rpida Ajax. [S.l.]: Alta Books, 2006.
[47] LANIWAY. Certificados Seguros SSL. Acessado em 21/02/2009. Disponvel em:
<http://www.laniway.com.br/br/corporativo/certificado>.
[48] ICPBRASIL. que um Certificado Digital. Acessado em 21/02/2009. Disponvel
em: <https://www.icpbrasil.gov.br/duvidas/faq/o-que-e-um-certificado-digital>.

102

[49] FRAGMENTAL. MVC e Camadas. Acessado em 20/04/2009. Disponvel em:


<http://www.fragmental.com.br/wiki/index.php?title=MVC_e_Camadas>.
[50] SHALLOWAY ALAN; TROTT, J. Design Patterns Explained: A New Perspective
on Object-Oriented Design. [S.l.]: Bookman Companhia, 2001.
[51] JAVAFREE. Singleton. Acessado
<http://www.javafree.org/wiki/Singleton>.

em

23/05/2009.

Disponvel

em:

[52] SOUZA CELSO ANDR; ARAJO FILHO, J. E. R. de. Estudo do paradigma orientado a objetos em sistemas de deciso e minerao de dados em ambientes
distribudos atravs de ferramentas computacionais inteligentes. p. 10, 2008.
[53] WIKIPEDIA. Usabilidade. Acessado
<http://pt.wikipedia.org/wiki/Usabilidade>.

em

20/04/2009.

Disponvel

em:

Anda mungkin juga menyukai