1 introdução

UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
MARCIANE SCHOTTEN
PROTÓTIPO DE UMA APLICAÇÃO MÓVEL PARA
LOCAÇÃO DE VEÍCULOS UTILIZANDO JME:
Proposta de Trabalho de Conclusão de Curso
submetida à Universidade Regional de
Blumenau para a obtenção dos créditos na
disciplina Trabalho de Conclusão de Curso I
do curso de Sistemas de Informação —
Bacharelado.
Prof. Ricardo Alencar de Azambuja - Orientador
BLUMENAU
2010/II
3
LISTA DE SIGLAS
API – Application Programming Interface
CDC – Connected Device Configuration
CLCD – Connected Limited Device Configuration
EJB – Enterprise Java Beans
HTTP – Hypertext Transfer Protocol
J2EE – Java 2 Enterprise Edition
J2ME – Java 2 Micro Edition
J2SE – Java 2 Standart Edition
JAD – Java Application Descriptor
JAR – Java Archive
JVM – Java Virtual Machine
KVM – Kilo Virtual Machine
MIDP – Mobile Information Device Profile
PC – Personal Computer
PDA – Personal Digital Assistant
RMS – Record Management System
UML – Unified Modeling Language
XML – eXtensible Markup Language
4
1
INTRODUÇÃO
Mundialmente a telefonia celular tornou-se popular tanto no ambiente de trabalho
quanto na vida privada. De acordo com Teixeira (2005, p. 1), há dois bilhões de celulares no
mundo, marca alcançada em setembro de 2005. Segundo Alencar (2006, p. 1), a base de celulares
no Brasil alcançou a marca de 89,4 milhões em março de 2006. Hoje o aparelho celular é bastante
diferente de 10 anos atrás, conforme Menezes (2003, p. 2), pois além de celular é também
máquina fotográfica, Mpeg Layer 3 (MP3) Player, Personal Digital Assistant (PDA), rádio,
internet, executor de aplicativos.
Segundo Almeida (2004, p. 21), para a execução de aplicativos dentro dos celulares, é
necessário algo para desenvolver os aplicativos. A tecnologia Java possui a edição Java 2 Micro
Edition (J2ME) para pequenos dispositivos como pagers, telefones celulares, set-top boxes de
TVs a cabo, PDA, sendo uma versão específica da máquina virtual criada para ser executada em
um ambiente com recursos limitados de memória e processamento. Os desenvolvedores são livres
para criar aplicações e executá-las em qualquer dispositivo de qualquer fabricante que possua
uma máquina virtual, não sendo necessário se prender a um dos fabricantes ou a uma tecnologia.
Também é livre a escolha do modelo de telefone celular que possa executar o aplicativo desejado.
Este trabalho propõe a construção de um protótipo de aplicação móvel, para reserva de
veículos, acessível a partir de um aparelho celular com acesso a internet, que atenda a
especificação Java (J2ME). Partindo da premissa de que quem precisa de um veículo de aluguel
está fora de seu domicílio, geralmente em viagem, e nem sempre conhece a localização dos
serviços do local, o que gera transtorno na hora de locar qualquer bem, inclusive um veículo,
5
aponta-se a necessidade de apresentar a possibilidade de locar este veículo em ambiente móvel,
disponibilizando esse serviço em qualquer momento e lugar onde o usuário necessitar dele.
1.1
PROBLEMA
Nos tempos atuais, a locação de veículos tem se mostrado uma opção acessível a
população. Assim como o “boom” dos telefones celulares, o que se observa é que existe uma
tendência em curso: a da mobilidade. Pensando nesta mobilidade, surgiu a ideia de associar as
duas áreas: a da telefonia móvel para agilizar a reserva de veículos de locadoras, sem necessidade
de contato pessoal com telefonistas ou outros operadores de locação. Acredita-se que, com a
disponibilização de um sistema de reserva de veículos, via dispositivo móvel, serão solucionados
alguns entraves, como congestionamento da centrais telefônicas, deslocamentos até os escritórios
de locadoras, o do acesso ao recurso pelas pessoas fora do domicílio que não têm acesso a um
computador. Com este cenário em mente, surgiu a ideia de utilizar o conceito da mobilidade,
considerando a facilidade e agilidade na hora de locar um veículo.
1.2
JUSTIFICATIVA
A intenção de desenvolver um protótipo de aplicação móvel para reserva de veículos,
surgiu após algumas pesquisas informais, que identificam carência de um produto adequado,
Considerando também que:
a) aplicações móveis têm boa receptividade aos usuários de dispositivos móveis;
6
b) uma empresa de locação poderia distribuir esse aplicativo a seus clientes, como
diferencial competitivo, e até utilizar o marketing, para agregar valor aos negócios;
1.3
OBJETIVOS
O objetivo deste trabalho é construir um protótipo de aplicação móvel para reserva de
veículos acessível a partir de um aparelho celular e que atenda a especificação Java (J2ME).
Os objetivos específicos do trabalho são:
a) desenvolver um sistema que permita ao usuário efetuar a locação de veículos de sua
preferência junto à empresa locadora utilizando-se de conexões com o servidor da mesma e
formalizando a transação a partir de critérios definidos pela empresa locadora;
b) executar a aplicação no telefone celular interagindo com um servidor de aplicações;
c) efetuar o sincronismo entre os dados registrados no celular e os dados residentes em
um servidor;
d) emitir comprovantes de transação devidamente autenticados e relatórios de controle e
estatísticas para o usuário.
1.4
RELEVÂNCIA DO TRABALHO
Este trabalho é relevante porque consiste no desenvolvimento de um protótipo de
aplicação móvel para reserva de veículos, acessível a partir de um aparelho celular e que atenda a
especificação Java (J2ME).
7
Segundo Castro, Gimenes e Maldonado (2000, p. 252), engenharia de requisitos integra
o ciclo de vida de desenvolvimento de software, responsável pelo processo de levantamento e
compreensão dos requisitos. Este processo compreende atividades como:
a) elicitação de requisitos: trata do levantamento dos requisitos;
b) análise de requisitos: rotinas para perceber e solucionar conflitos entre requisitos;
c) validação de requisitos: verifica duplicidade, inconsistências e inconcluso;
d) gerenciamento de requisitos: gerencia as alterações dos requisitos.
Neste trabalho, será utilizada a ferramenta Enterprise Architect (EA), para a modelagem
dos dados, esta é uma ferramenta Computer-Aided Software Engineering (CASE) baseada na
Unified Modeling Language (UML). O protótipo de aplicação móvel será desenvolvido na
linguagem JAVA.
Considerando que estas aplicações têm boa receptividade aos usuários de dispositivos
móveis, empresas de aluguéis de veículos podem estar utilizando a aplicação como meio de
agregar valor aos negócios, melhorando consideravelmente à rentabilidade.
8
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta os principais temas relacionados com esta proposta. São
apresentados assuntos como dispositivos móveis, plataforma JAVA, J2ME, configuração CLDC,
perfil MIDP e trabalhos correlatos.
2.1
DISPOSITIVOS MÓVEIS
Segundo Laudon e Laudon (1999, p. 160), novas formas de comunicações estão sendo
proporcionadas por redes móveis de dados, usando dispositivos móveis, como telefones celulares
e PDAs - um computador manual composto de uma caneta, com recursos internos e
organizacionais de comunicações. Muito mais do que assistentes pessoais ou agendas eletrônicas,
os dispositivos móveis passaram a ser computadores que podem ser facilmente levados a
qualquer lugar, criados para atender profissionais e pessoas em movimento que necessitam de
rapidez, facilidade e segurança no acesso a informações corporativas e pessoais.
Segundo Pamplona (2005 p. 17), a computação móvel é caracterizada por um
dispositivo móvel com capacidade de processamento em um ambiente sem fio. Exemplos destes
equipamentos são os PDAs, Pocket PCs, Smartphones e celulares, tais como os apresentados na
figura 1.
9
Fonte: Yoshimura (2006).
Figura 1 – Exemplos de dispositivos móveis
Além disso, as inovações trazidas pela tecnologia wireless fizeram com que a indústria
deste setor tenha tido um crescimento explosivo nos últimos anos, permitindo que as pessoas
comuniquem-se de forma barata e fácil sem ficarem presas aos seus telefones ou computadores
de mesa.
2.2 PLATAFORMA JAVA
Segundo Montenegro e Pereira (2005, p. 28), as aplicações Java existentes englobam as
variadas áreas do conhecimento e rodam nas mais diversas plataformas e sistemas operacionais,
desde equipamentos bastante limitados (como celulares, PDAs, computadores de bordo) até
poderosos clusters de servidores, atendendo a centenas ou milhares de clientes simultâneos. A
plataforma Java foi dividida em três edições:
a) Java 2 Standard Edition (J2SE): o núcleo da plataforma, com a máquina virtual e as
Application Programming Interface (APIs) básicas;
10
b) Java 2 Enterprise Edition (J2EE): complementando a J2SE e fornecendo recursos
para o desenvolvimento de aplicações Web e corporativos;
c) Java 2 Micro Edition (J2ME): definindo um ambiente Java para dispositivos móveis.
2.3 J2ME
De acordo com a Sun Microsystems (2010), a JME foi criada para o desenvolvimento de
aplicações para dispositivos que possuíssem limitações de hardware. Com isso, a tecnologia Java
deveria ser adaptada para funcionar em um dispositivo limitado, tornando possível a criação de
aplicações Java que fossem perfeitamente portáveis para dispositivos com memória, display e
capacidade de energia reduzida.
Conforme Fonseca (2002, p. 07), a Máquina Virtual Java do J2ME, normalmente
chamada de Kilobyte Virtual Machine (KVM), a qual é implementada de acordo com a
especificação da comunidade Java, não é a mesma utilizada pelas versões J2EE e J2SE, sendo
quase sempre um conjunto menor dessas versões. Por isso, códigos não podem ser portados
diretamente de uma versão maior de Java para o J2ME. A relação entre os dispositivos móveis e
J2ME está representada na Figura 2.
11
Fonte: Knudsen (2003, p. 2)
Figura 2 – Dispositivos Móveis e J2ME
Conforme a Sun Microsystems (2010), atualmente a plataforma J2ME consiste de um
conjunto de configurações (configurations) e perfis (profiles). Uma configuração define
características mínimas de um ambiente de execução Java completo. onde uma mesma
configuração atende vários dispositivos diferentes, não possuindo detalhes específicos do
dispositivo. A Application Programming Interface (API) de uma configuração pode ter
subconjuntos da API de J2SE. No momento existem duas configurações: Connected Device
Configuration (CDC) e Connected Limited Device Configuration (CLDC). A configuração CDC
possui um conjunto de APIs que suportam equipamentos fixos de porte médio, tal como
televisores. A configuração CLDC é um conjunto de APIs destinadas a aparelhos cujo poder de
processamento, display e memória são limitados.
Um perfil define um conjunto adicional de bibliotecas e características de empresas, de
categoria, de dispositivo ou de indústria. Enquanto uma configuração define uma base de
bibliotecas, perfis definem as bibliotecas que são importantes para construir aplicações efetivas.
12
Estas bibliotecas incluem a interface com o usuário, comunicação em rede e classes de
armazenamento.
Alguns dos perfis existentes são: Mobile Information Device Profile (MIDP),
Foundation Profile, PDA Profile, PersonalJava, etc. Cada perfil é destinado a uma categoria
específica de dispositivos, e consiste num conjunto mínimo de bibliotecas de classes que
determinado aparelho deve suportar.
As configurações do J2ME definem uma plataforma Java para uma determinada faixa de
dispositivos definidos por uma série de características como:
a) informações sobre a memória do dispositivo;
b) tipo e velocidade do processador;
c) conectividade do aparelho.
Uma configuração obrigatoriamente representa as mínimas características de uma
plataforma para um dispositivo (Topley, 2002). Com isso, os fabricantes são obrigados a
implementar por total a especificação de uma configuração almejada para tal dispositivo. Isso
garante que programadores possam desenvolver aplicações sem se preocupar em qual dispositivo
específico elas irão rodar, apenas precisam da certeza que o dispositivo implementa a
configuração escolhida. Há duas configurações disponíveis para a utilização do J2ME, a
Connected Device Configuration (CDC), voltada para dispositivos com maior poder operacional
e recursos de memória e conectividade, e a Connected Limited Device Configuration (CLDC),
voltada para dispositivos com recursos limitados e que é a configuração escolhida neste trabalho.
De acordo com Topley (2002), os perfis complementam as configurações com a adição
de classes que provêm características específicas para um determinado tipo de dispositivo ou um
13
determinado segmento de aplicação, como recursos de interface gráfica, armazenamento
persistente, segurança e conectividade. Cada configuração da J2ME tem um ou mais perfis
associados. Segundo White (2002), alguns perfis associados à configuração CDC são:
a) Foundation Profile;
b) Personal Profile;
c) Remote Method Invocation (RMI) Profile;
d) Personal Basis Profile.
White (2002) descreve também que os seguintes perfis são referentes a configuração
CLDC:
a) Mobile Information Device Profile (MIDP);
b) Personal Digital Assistant Profile (PDAP).
Os perfis Multimedia, Gaming e Telephony Profile atendem tanto a configuração CDC
como CLDC.
2.4
CONFIGURAÇÃO CLDC
Conforme Schmitt Junior (2004), A Connected Limited Device Configuration (CLDC) é
destinada para os dispositivos com as mais limitadas configurações do mercado, como telefones
celulares, pagers, simples PDAs, entre outros dispositivos, que são caracterizados pelos baixos
recursos de memória, processamento e conectividade. A CLDC é a configuração que provê
funções de núcleo que são usadas como base para alguns perfis.
Como características principais, os dispositivos que suportam a CLDC devem ter:
14
a) no mínimo 192 kb de memória total disponível para a plataforma Java;
b) um processador de 16 ou 32 bits;
c) conectividade a algum tipo de rede por meio de tecnologia sem fio, conexão
intermitente e com banda limitada.
Cada configuração do J2ME consiste de um conjunto de bibliotecas e de uma máquina
virtual Java. A CLDC define uma máquina virtual que pode ser considerada uma versão
simplificada da Java Virtual Machine (JVM) utilizada na edição J2SE. A Sun especifica como
deve trabalhar uma máquina virtual para a configuração CLDC e também oferece uma máquina
virtual junto ao kit de desenvolvimento para J2ME chamada Kilobyte Virtual Machine (KVM).
Porém, a utilização da KVM em aplicações J2ME não é obrigatória, podendo assim cada
fabricante de dispositivos móveis implementar a sua máquina virtual que atenda à especificação.
Pela simplificação da máquina virtual na CLDC, alguns dos recursos da linguagem Java
e funções da máquina virtual usadas na J2SE não são suportados. Muitos dispositivos, pela baixa
disponibilidade de memória, não suportam operações com ponto flutuante, e por padrão a
utilização do ponto flutuante não é suportada pela CLDC. O baixo recurso de memória nos
dispositivos é a principal causa de algumas omissões na linguagem Java da configuração CLDC
como inviabilidade de recursos de reflexão, não implementação de finalização de objetos,
restrições na utilização de threads, não suporte de várias classes de erros e exceções e omissão do
recurso de interface nativa.
15
2.4 PERFIL MIDP
O perfil Mobile Information Device Profile (MIDP) trabalha sobre a configuração
CLDC e habilita recursos de conectividade, armazenamento de dados local e interface gráfica
com usuário. Por padrão, o perfil MIDP carece de recursos avançados de segurança e interface
gráfica, porém os fabricantes dos dispositivos podem oferecer recursos opcionais que
customizam essas carências. Uma aplicação que implementa o perfil MIDP é chamada de MIDlet
e roda sobre a máquina virtual KVM proposta pela configuração CLDC. Um MIDlet pode utilizar
tanto funções oferecidas no perfil MIDP como funções que o MIDP herda da CLDC. Schmitt
Junior (2004).
Os dispositivos atendidos pelo perfil MIDP são normalmente telefones celulares e
PDAs. De acordo com a especificação deste perfil, o dispositivo deve ter:
a) 128 kb de memória não volátil necessária para armazenamento da implementação;
b) 32 kb de memória volátil para a pilha Java;
c) 8 kb de memória não volátil necessária para armazenamento local persistente;
d) visor de pelo menos 96 x 54 pixels;
e) algum recurso para entrada de dados como teclado, tela por toque ou área de teclas
conforme telefones celulares;
f) possibilidade de conexão a algum tipo de rede.
Uma aplicação MIDP contém no mínimo uma classe MIDlet. Porém pode haver casos
em que uma aplicação contém mais de um MIDlet, e neste caso a aplicação é chamada de MIDlet
Suite. Ao ser carregada no dispositivo, a MIDlet Suite, faz a varredura de todos os MIDlets
16
existentes e dispõe ao usuário escolher qual MIDlet lançar. A aplicação MIDP, para ser instalada
no dispositivo, precisa ser empacotada, construindo um Java Archive (JAR). O JAR
obrigatoriamente contém um arquivo de manifesto que engloba informações sobre o MIDlet ou
conjunto de MIDlets contidos no pacote JAR. O JAR trabalha em conjunto com um Java
Application Descriptor (JAD). O descritor contém informações sobre a aplicação, principalmente
sobre a configuração e perfil utilizados pela mesma. Schmitt Junior (2004).
2.5 TRABALHOS CORRELATOS
Schmitt Junior (2004) desenvolveu um protótipo de front end de Controle de Acesso,
utilizando J2ME, onde tem como objetivo principal automatizar o controle de segurança
patrimonial, oferecendo flexibilidade na aplicação, em relação ao modo de armazenamento das
informações e a interface com o usuário, se beneficiando com os recursos de um dispositivo
móvel, baseado na tecnologia J2ME. No desenvolvimento do trabalho, são explorados recursos
avançados do J2ME, como por exemplo, o Record Management System (RMS), para o
armazenamento das informações no dispositivo e a troca de informações com base no protocolo
HTTP, utilizando o formato XML para a troca de dados com um servidor.
Schaefer (2004) desenvolveu como Trabalho de Conclusão de Curso, um protótipo de
um sistema de troca de informações via dispositivos móveis aplicado a empresas de transporte. O
mesmo faz a coleta dos dados das atividades externas à empresa de transportes e disponibiliza
para um sistema interno da empresa. O protótipo foi desenvolvido utilizando a plataforma de
desenvolvimento J2ME para implementação em celulares e no PC foi desenvolvido utilizando o
ambiente Delphi 6, permitindo a consulta a relatórios e gráficos. O sistema demonstra uma
inovação na maneira de analisar os dados e no auxilio à tomada de decisões.
17
2 DESENVOLVIMENTO
Neste capítulo está descrito o desenvolvimento do protótipo de aplicação para reserva de
veículos a especificação dos principais requisitos e a sua modelagem.
2.6 3.1 SISTEMA PROPOSTO
Este trabalho propõe o desenvolvimento de um protótipo de aplicação móvel para
reserva de veículos utilizando a especificação J2ME da Linguagem Java. Este sistema será
disponibilizado para execução em diversas configurações de celulares, e personal digital
assistants (PDAs) e é constituído de apenas um módulo que será utilizado pelo usuário para
proceder a escolha do veículo de aluguel disponível a partir de informações adquiridas pelo
aplicativo, através da internet, do site da empresa de locação. O usuário terá a possibilidade de
configurar suas pesquisas favoritas e gravá-las para facilitar acessos futuros.
O processo se inicia com a execução do aplicativo e abertura do painel de configuração
para que o usuário defina seu login e senha cadastrados junto à empresa de locação de veículos,
em seguida o usuário cria um perfil de pesquisa definindo condições e informações do veículo
que pretende locar tais como modelo, ano, cor, etc... Se houver perfis já criados o usuário poderá
apenas selecionar um perfil já criado e até defini-lo como padrão para uma pesquisa imediata ao
iniciar o aplicativo. Em virtude da reduzida estrutura que os perfis devem exigir, foi entendido
que poderão ser gravados em arquivos de texto ou como registros RMS sem grande perda de
performance do sistema.
Comandada a pesquisa, o aplicativo se conecta ao site servidor e adquire a lista atual de veículos
disponíveis, compatíveis com o perfil definido pelo usuário, apresentando ao usuário para que
18
faça sua escolha, escolhido o veículo, o usuário fará o agendamento dos prazos de uso, da forma
de retirada e demais informações necessárias a empresa locadora para efetivar a transação. O
sistema enviará ao site a requisição de locação e receberá comprovante de que o processo foi
autorizado e o veículo estará disponível no prazo definido pelo usuário. Este comprovante ficará
arquivado no sistema e poderá ser apresentado na tela, ou impresso caso seja necessário. Cada
comprovante deverá ter um autenticador fornecido pelo site servidor para garantia de uso do
usuário de que sua locação está devidamente registrada. Como cada comprovante representa uma
quantidade reduzida de informação pode ser gravado em um arquivo texto sem maiores
problemas. O usuário poderá a qualquer tempo exigir relatórios em tela de todas as operações
efetivadas.
3.2
REQUISITOS PRINCIPAIS DO SISTEMA PROPOSTO
Os requisitos descrevem o que o sistema deve fazer. Eles estão classificados em
requisitos funcionais e requisitos não funcionais. Requisitos funcionais são funcionalidades que o
sistema deve possuir e o comportamento do sistema em determinadas situações, podendo também
explicitar o que o sistema não deve fazer. Requisitos não funcionais são restrições sobre os
serviços ou as funções oferecidas pelo sistema, como usabilidade, hardware, segurança.
O Quadro 1 apresenta os requisitos funcionais previstos para o sistema e sua
rastreabilidade, ou seja, vinculação com o(s) caso(s) de uso associado(s).
Requisitos Funcionais
RF01 O sistema deverá possibilitar a reserva do veículo pelo Cliente.
RF02 O sistema deverá permitir o Cliente incluir/alterar/excluir a
reserva
RF03 O sistema deverá permitir ao Cliente manter seu cadastro
RF04 O sistema de retaguarda deverá permitir incluir/alterar os
Caso de Uso
UC01
UC01
UC02
UC03
19
RF05
RF06
RF07
RF08
RF09
veículos para locação
O sistema de retaguarda deverá incluir/alterar a tabela de preços
das locações
O sistema de retaguarda deverá incluir/alterar a tabela de tipo de
veículo
O sistema de retaguarda deverá permitir efetuar consultas e
fechar reservas efetuadas pelos clientes
O sistema de retaguarda deverá permitir gerar relatórios
O sistema de retaguarda deverá permitir incluir/alterar/excluir
Cliente
UC04
UC05
UC07
UC08
UC09
Quadro 1: Requisitos funcionais
O Quadro 2 lista os requisitos não funcionais previstos para o sistema.
Requisitos Não Funcionais
RNF01
O sistema deve ser acessível via os mais populares browsers do mercado.
RNF02
A ferramenta deve ser desenvolvida utilizando a linguagem JAVA e banco
de dados através de texto ou RMS.
RNF03
O sistema deverá enviar e-mail ao Cliente confirmando a reserva efetuada.
Quadro 2: Requisitos não funcionais
2.7 MODELAGEM
Esta seção apresenta o diagrama de casos de uso e o diagrama de classes.
2.8 DIAGRAMAS DE CASO DE USO
Esta sub-seção apresenta na figura 3, o diagrama de caso de uso do sistema proposto.
Para um melhor entendimento do sistema o detalhamento dos principais casos de uso encontra-se
no Apêndice A.
20
Figura 3 - Caso de Uso
2.9 DIAGRAMAS DE CLASSE
Na Figura 4 tem-se o diagrama de classes com as classes que representam as entidades.
21
Figura 4– Diagrama de classes das entidades
A função de cada classe de entidade está descrita a seguir:
a) classe Cliente - classe que possui os atributos referentes aos Clientes do sistema;
b) classe Veículo - classe que possui os atributos referentes aos veículos da locadora;
c) classe Preço - classe que possui os atributos referentes aos preços de locação dos
veículos;
d) classe Tipo Veículo - classe que possui os atributos referentes aos tipos de veículos;
e) classe Reserva - classe que possui os atributos referentes as reservas dos veículos;
22
REFERÊNCIAS
ALENCAR, P. Brasil tem 89,4 milhões de celulares. Plantão INFO, São Paulo, abr. 2006.
Disponível em: <http://info.abril.com.br/aberto/infonews/042006/24042006-5.shl>. Acesso
em: 23 outubro 2010.
ALMEIDA, Leandro Batista de. et al. Introdução à J2ME e programação MIDP. Mundo Java,
Rio de Janeiro, n. 5, p. 20-27, 2004.
CASTRO, Jaelson Freire Brelaz de; GIMENES, Itana Maria de Souza; MALDONADO, José
Carlos. Uma proposta de plano pedagógico para a matéria engenharia de software. In:
CURSO DE QUALIDADE DE CURSOS DE GRADUAÇÃO DA ÁREA DE
COMPUTAÇÃO E INFORMÁTICA, 2., 2000, Curitiba. Anais... Curitiba: Champagnat, 2000.
p. 251-270.
FONSECA, Jorge Cavalcanti. Portando a KVM. 2002. 64 f. Trabalho de Conclusão de Curso
(Graduação em Ciências da Computação) – Centro de Informática, Universidade Federal de
Pernambuco, Recife.
KNUDSEN, Jonathan. Wireless Java: developing with J2ME. 2.ed. New York: Apress, 2003,
xviii, 364 p.
LAUDON, Kenneth C.; LAUDON, Jane Price. Sistemas de informação. Tradução Dalton
Conde de Alencar. Rio de Janeiro: LTC, 1999.
MENEZES, R. Câmara Brasileira de Comércio Eletrônico. São Paulo, [2003?]. Disponível
em: <http://www.camara-e.net/newsletter/2004/newsletter01setembro04.htm>. Acesso em: 12
set. 2005.
MONTENEGRO, C.; PEREIRA, C. Java de ponta a ponta do J2ME ao J2EE. Mundo Java,
Rio de Janeiro, n. 12, p. 28-43, 2005.
PAMPLONA, V. F. Um protótipo de motor de jogos 3D para dispositivos móveis com
suporte a especificação mobile 3D graphics API for J2ME. 2005. 83 f. Trabalho de
Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas
e Naturais, Universidade Regional de Blumenau, Blumenau.
SCHAEFER, Carine. Protótipo de aplicativo para transmissão de dados a partir de
dispositivos móveis aplicado a uma empresa de transportes. 2004. 52 p. Trabalho de
conclusão de Curso (Bacharelado em Ciência da Computação) – Centro de Ciências Exatas e
Naturais, Universidade Regional de Blumenau, Blumenau.
23
SCHMITT JUNIOR, Arno José. Protótipo de front end de controle de acesso usando J2ME.
2004. 69 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) -Centro
de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
[SUN] Java Micro Edition. Disponível em: <http://java.sun.com/javame/technology/index.jsp >.
Acesso em 24 de outubro de 2010.
TEIXEIRA, C. A. Dois bilhões de celulares no mundo. [S.l], out. 2005. Disponível em:
<http://www.torque.com.br/index.php?modulo=textos&secao=artigos&codTexto=1653&pagi
na=1&sequencia=1&codCategoria=#>. Acesso em 23 outubro 2010.
TOPLEY, Kim. J2ME in a nutshell : a desktop quick reference. Cambridge: O`Reilly, c2002.
xv, 450 p.
WHITE, James, HEMPHILL, David. Java 2 Micro Edition: Java in small things.
Greenwich:Manning, 2002, 479 p.
YOSHIMURA, B. H. O que é smartphone?. [S.l.], 2006. Disponível em:
<http://www.linkgratis.com.br/materia/O_Que_e_Smartphone/>. Acesso em: 27 outubro 2010.
24
APÊNDICE A –Detalhamento dos casos de uso
Esta seção do documento contém o detalhamento dos casos de uso previstos no(s)
diagrama(s) apresentado(s) na seção 3.4 Veja exemplo abaixo.
No Quadro 3 apresenta-se o caso de uso "Efetua Login".
Nome do Caso de Uso
Efetua Login
Descrição
Cliente acessa aplicação via celular e informa dados para login e senha armazenados
no cadastro do usuário.
Ator
Cliente
Pré-condição
Usuário deve estar cadastrado no banco de dados.
Fluxo principal
1.
Cliente preenche seu login e sua senha;
2.
Sistema valida os dados de login e senha do usuário;
3.
Sistema direciona o Cliente para a página de menu do protótipo.
Fluxo alternativo (a)
Pós-condição

nome de usuário e/ou senha inválido(s)

alerta com mensagem “usuário ou senha inválida” é mostrada.
Cliente entra conectado ao sistema.
Quadro 3 – Descrição do caso de uso Login
No Quadro 4 apresenta-se o caso de uso "Manter Cadastro de Cliente".
Nome do Caso de Uso
Manter Cadastro de Usuário
Descrição
Cliente acessa o Cadastro de Usuário para manter dados do Usuário. Serão
mantidos os dados: nome, telefone, celular, cart. motorista, endereço, bairro, cep,
cidade, UF, lembrete, e-mail
Ator
Cliente
Pré-condição
Cliente deve fazer login no sistema.
Fluxo principal
1.
Sistema informa o Cliente cadastrado;
2.
Cliente opta por editar, apagar ou cadastrar os dados;
Cenário – Visualização
Cenário – Edição
Sistema mostra os registros do usuário cadastrado pelo Cliente
1.
Sistema mostra registros cadastrados;
2.
Cliente seleciona um registro para edição;
3.
nome, telefone, celular, cart. motorista, endereço, bairro, cep, cidade, UF,
lembrete, e-mail
4.
Cliente altera registro e seleciona opção para atualizar os dados (nome, telefone,
25
celular, cart. motorista, endereço, bairro, cep, cidade, UF, lembrete, e-mail
Cenário – Inclusão
Cenário – Exclusão
Pós-condição
5.
Sistema mostra os registros cadastrados com o registro alterado.
1.
Sistema mostra registros cadastrados;
2.
Cliente inclui um novo registro;
3.
Sistema mostra os registros cadastrados.
1.
Sistema mostra registros cadastrados;
2.
Cliente seleciona um registro para exclusão;
3.
Sistema exclui o registro e mostra os registros restantes.
Cliente visualizou, editou, apagou ou cadastrou um usuário.
Quadro 4 – Descrição do caso de uso Manter Cadastro de Cliente
No Quadro 5 apresenta-se o caso de uso "Gera solicitação de Reserva".
Nome do Caso de Uso
Gera solicitação de Reserva
Descrição
Cliente acessa Solicitação de Reserva para gerar uma solicitação de reserva. Serão
mantidos os dados: data da reserva, hora da reserva, data da retirada, hora da
retirada, data da devolução, hora da devolução.
Ator
Cliente
Pré-condição
Cliente deve fazer login no sistema.
Fluxo principal
a) o sistema informa os veículos disponíveis;
Cenário – Visualização
Cenário – Edição
Sistema mostra os registros de veículos disponíveis para reserva;
1.
Sistema mostra registros da reserva;
2.
Usuário seleciona um registro para edição;
3.
Sistema mostra data da reserva, hora da reserva, data da retirada, hora da
retirada, data da devolução, hora da devolução;
4.
Usuário altera registro e seleciona opção para atualizar os dados (data da
reserva, hora da reserva, data da retirada, hora da retirada, data da devolução,
hora da devolução).
Cenário – Inclusão
Cenário – Exclusão
Pós-condição
5.
Sistema mostra os registros de reserva com os dados alterado.
1.
Sistema mostra registros reservados;
2.
Usuário inclui um novo registro;
3.
Sistema mostra os registros cadastrados.
1.
Sistema mostra registros cadastrados;
2.
Usuário seleciona um registro para exclusão;
3.
Sistema exclui o registro.
Cliente visualizou, editou, apagou ou Incluiu uma reserva.
Quadro 5 – Descrição do caso de uso Gera solicitação de Reserva