Upload
diogo-moreira
View
81
Download
0
Embed Size (px)
DESCRIPTION
Minha monografia apresentada ao IFPB para obtenção do título de tecnólogo em Análise e Desenvolvimento de Sistemas. Neste trabalho foi desenvolvido uma solução para as transações comerciais entre pessoas físicas nomeado como LOOCALIZA
Citation preview
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DA
PARAÍBA – IFPB – CAMPUS CAJAZEIRAS.
CURSO SUPERIOR DE TECNOLOGIA DE ANÁLISE E
DESENVOLVIMENTO DE SISTEMAS
DIOGO DANTAS MOREIRA
LOOCALIZA
SISTEMA DE COMPRAS GEOGRÁFICO
CAJAZEIRAS, PB
MARÇO DE 2012
DIOGO DANTAS MOREIRA
LOOCALIZA
SISTEMA DE COMPRAS GEOGRÁFICO
Monografia apresentada ao Instituto Federal
de Educação, Ciência e Tecnologia da Paraíba,
Campus Cajazeiras como requisito para
obtenção do título de tecnólogo no Curso
Superior de Tecnologia em Análise e
Desenvolvimento de Sistemas.
Orientadora:
Profa. Valéria Maria Bezerra Cavalcanti
Co-orientador:
Prof. Diego Ernesto Rosa Pessoa
CAJAZEIRAS, PB
MARÇO, 2012
M 835 l Moreira, Diogo Dantas. Loocaliza: sistema de compras geográfico. / Diogo Dantas Moreira ; -- Cajazeiras , 2012. 73f. Orientador: Valéria Maria Bezerra Cavalcanti 1. Automação. 2. Comércio eletrônico. I. Título. Biblioteca Prof. Ribamar da Silva /IFPB - Cajazeiras CDU – 681.5
DIOGO DANTAS MOREIRA
LOOCALIZA
SISTEMA DE COMPRAS GEOGRÁFICO
Monografia submetida ao Instituto Federal de Educação, Ciência e Tecnologia da Paraíba,
Campus Cajazeiras, Curso Superior de Tecnologia em Análise e Desenvolvimento de
Sistemas, como pré-requisitos para obtenção do título de Tecnólogo em Análise e
Desenvolvimento de Sistemas, apreciada pela banca examinadora composta pelos seguintes
membros:
Aprovada em: ____/____/2012
BANCA EXAMINADORA
________________________________________________________________________
Profª. Msc. Valéria Maria Bezerra Cavalcante – IFPB
________________________________________________________________________
Profª. Msc. Nadja da Nobrega Rodrigues – IFPB
________________________________________________________________________
Profª. Msc. Elaine Cristina Juvino Araújo – IFPB
________________________________________________________________________
Prof. Msc. Diego Ernesto Rosa Pessoa – IFPB
A minha mãe, Norma Moreira da Costa Dantas, por sempre estar presente na minha vida e que nunca
mediu esforços para que eu tivesse uma boa educação e uma formação de qualidade, e que sempre me
guiou pelos melhores caminhos da vida.
Agradecimentos
Antes de tudo, agradecer a meus pais Norma Moreira da Costa Dantas e Nivaldo Dantas, que
muitas vezes abriram mão de seus sonhos em favor dos meus, que estiveram comigo nos bons
e maus momentos, que reconheceram meus esforços e acreditaram que eu seria capaz. Que
sempre me apoiaram e me incentivaram aos estudos, ensinando-me que o conhecimento é a
maior riqueza que um homem pode ter.
Ao meu irmão, Douglas Dantas Moreira, meu melhor amigo e confidente, que sempre esteve
presente apoiando as minhas decisões e dando conselhos, seja qual fosse a situação.
A minha tia Maria de Fátima Moreira, que por muitas vezes fez o papel de mãe quando a
mesma não pode estar presente e que sempre me deu puxões de orelha quando era necessário.
Ao meu primo, Diego Moreira, por ter me escutado e me ajudado em uma decisão muito
importante, fazer este curso, mostrando que poderia ser de grande valor na minha vida.
Aos demais familiares que de alguma maneira ajudaram a construir o meu alicerce.
A todos os meus amigos, os que já passaram pela minha vida e aqueles que continuam nela.
Os amigos de farra, os amigos de estudos, os amigos de conhecimento, amigos da vida.
Amigos e amigas conquistados em tantos anos de convivência diária da graduação, em
especial a: Fernando Ítallo, Nathally Uchôa, Naylla Estrela, João Paulo, Wagner Abreu,
Wagner Silva, Fidélis Moura, José Roberto, Mardocê Neto e Izabel Mangueira. Sei que vocês
estiveram torcendo por mim! À distância e o tempo nunca irão nos separar, vocês fazem parte
do meu coração!
Aos professores e funcionários da instituição IFPB – Campus Cajazeiras, pela atenção,
carinho e confiança no meu potencial.
Ao professor Fábio Andrade, aquele que me apresentou ao mundo da programação, que
depositou uma grande confiança na minha pessoa e nas minhas habilidades, apoiando e
repreendendo quando necessário. E que lançou a frase de minha vida: “Escreva um programa
que leia”.
Ao professor Thiago Moura, que me deu a injeção de ânimo necessária para seguir em frente
quando eu estive prestes a desistir deste sonho.
Ao professor e amigo Ricardo Job, que foi paciente enquanto fui seu aluno e que por muitas
vezes tirou minhas dúvidas mesmo em horários extraclasse.
Ao professor e amigo André Rolim, por me dar conselhos valorosos para minha vida
acadêmica, profissional e pessoal ao longo da minha graduação.
Ao meu amigo e co-orientador Diego Pessoa, que mesmo sem ter sido meu professor durante
a graduação, foi de grande ajuda durante o desenvolvimento deste trabalho.
A professora e minha orientadora Valéria Cavalcanti, que sempre insistiu para que eu não
desistisse dos meus objetivos durante a graduação, sempre depositando confiança na minha
pessoa, me motivando sempre que fosse necessário. E que me falou, certa vez, uma frase que
sempre vou levar comigo: “Quem espera, nunca alcança”.
“Stay hungry, stay foolish”.
Steve Jobs
Resumo
O comércio eletrônico dos mais diversos tipos tem se expandido cada vez mais nos últimos
anos, abrangendo uma extensa gama de produtos e serviços oferecidos através da rede. A
facilidade de comprar e vender produtos a partir de seu próprio computador atraiu tanto
grandes redes de lojas físicas quanto pequenos empreendedores que buscam divulgar seus
produtos em meio a tantas ofertas. Apesar de o comércio eletrônico estar em evidência,
existem fatores que dificultam as negociações por meio de comércio eletrônico. Entre elas “A
insegurança durante a transação” e “A impossibilidade de visualizar o produto” dificulta a
compra pela internet. Neste projeto foi desenvolvida uma solução para as transações
comerciais entre pessoas físicas nomeado como LOOCALIZA. O sistema provê um ambiente
onde os usuários podem comprar e vender produtos de forma fácil e rápida e com a
possibilidade de concluírem a compra de forma presencial, evitando várias etapas de um
comércio eletrônico comum que muitas vezes são desnecessárias.
Palavras-chave: google maps, postgis, jsf, ejb, jpa, sig.
Abstract
The e-commerce of all kinds has been expanding increasingly in recent years, covering a wide
range of products and services that is offered through the network. The ease of buying and
selling products from their own computer has attracted both large retail stores and small
entrepreneurs who seek to spread their wares between many offers. Although evidence of e-
commerce, there are factors that make difficult to trade through electronic commerce. Among
them "The uncertainty during the transaction" and "The impossibility of visualizing the
product” makes it difficult to purchase over the Internet. In this project, a solution for business
transactions between individuals named LOOCALIZA was developed. The system provides
an environment where user can buy and sell products quickly and easily and with the
possibility of complete the transaction in person, avoiding many steps of a common e-
commerce that are often unnecessary.
Palavras-chave: google maps, postgis, jsf, ejb, jpa, sig.
Lista de Figuras
Figura 1 - Faturamento nas compras pela internet de 2001 a 2011 .......................................... 17
Figura 2 - Faturamento do e-commerce na época de Natal nos últimos anos .......................... 17
Figura 3 – Arquitetura de sistemas de informação geográfica (SIG). ...................................... 26
Figura 4 – Paradigma dos quatro universos. ............................................................................ 26
Figura 5 - Casos de uso do sistema LOOCALIZA ................................................................... 34
Figura 6 – Caso de uso “Realizar Cadastro” ............................................................................ 35
Figura 7 - Diagrama de atividades "Cadastrar Produto" .......................................................... 36
Figura 8 – Caso de uso “Manter Produto” ................................................................................ 36
Figura 9 - Caso de uso "Manter anúncio" ................................................................................. 37
Figura 10 - Caso de uso "Consultar Anúncio" ......................................................................... 38
Figura 11 - Diagrama de atividades "Qualificar Vendedor" .................................................... 38
Figura 12 - Caso de uso "Comentar anúncio" .......................................................................... 39
Figura 13 – Visão gráfica da arquitetura do sistema LOOCALIZA ........................................ 40
Figura 14 - URL mapeada no pretty-config.xml ...................................................................... 41
Figura 15 - Componente "Password" do Primefaces em ação ................................................. 43
Figura 16 - Tela de Cadastro do LOOCALIZA ....................................................................... 44
Figura 17 - Tela de cadastro de Vendedor ................................................................................ 45
Figura 18 - Tela de definição de local ...................................................................................... 46
Figura 19 - Tela de cadastro de produtos com componente FileUpload em ação .................... 47
Figura 20 - Tela de Listagem de Produtos ................................................................................ 47
Figura 21 - Tela parcial de "Cadastro de anúncios" ................................................................. 48
Figura 22 - Componentes GMap e Calendar em ação .............................................................. 49
Figura 23 - Caixa de consulta isolada ....................................................................................... 49
Figura 24 - Formulário de consulta em conjunto ..................................................................... 50
Figura 25 - Consulta SQL de anúncios em conjuntos .............................................................. 50
Figura 26 - Tela de visualização de anúncio ............................................................................ 51
Figura 27 - Tela de visualização de rota ................................................................................... 52
Figura 28 - Qualificação de vendedor ...................................................................................... 52
Figura 29 - Comentários em anúncio ....................................................................................... 53
Figura 30 - Comparativo entre sistemas operacionais móveis ................................................. 54
Figura 31 - Diagrama Entidade-Relacionamento do Sistema LOOCALIZA........................... 59
Figura 32 - Diagrama de classes do sistema LOOCALIZA ..................................................... 73
Lista de Quadros
Quadro 1 - Requisitos implementados no TCC1 ...................................................................... 23
Quadro 2 - Requisitos implementados no TCC2 ...................................................................... 23
Quadro 3 – Requisitos funcionais do sistema LOOCALIZA ................................................... 33
Quadro 4 - User Story 1 - Cadastrar Usuário ........................................................................... 67
Quadro 5 - User Story 2 - Definir Localização ........................................................................ 67
Quadro 6 - User Story 3 - Cadastrar Produtos .......................................................................... 68
Quadro 7 - User Story 4 - Cadastrar Anúncio .......................................................................... 68
Quadro 8 - User Story 5 - Consultar Anúncio Isoladamente .................................................... 69
Quadro 9 - User Story 6 - Consultar Anúncios em Conjunto ................................................... 69
Quadro 10 - User Story 7 – Visualização de anúncios ............................................................. 70
Quadro 11 - User Story 8 – Verificar rota ................................................................................ 70
Quadro 12 - User Story 9 - Comentar em anúncios ................................................................. 70
Quadro 13 - User Story 10 - Favoritar anúncios ...................................................................... 71
Quadro 14 - User Story 11 - Qualificar Vendedor ................................................................... 71
Quadro 15 - User Story 12 - Visualizar histórico de qualificações .......................................... 72
Lista de Tabelas
Tabela 1 - Cronograma de trabalho .......................................................................................... 22
Tabela 2 - Plano de releases ..................................................................................................... 61
Tabela 3 - Plano de iterações da release 1 ................................................................................ 63
Tabela 4 - Plano de iterações da release 2 ................................................................................ 64
Tabela 5 - Plano de iterações da release 3 ................................................................................ 66
Lista de abreviaturas e siglas
B2B - Business-to-Business (Negócio para negócio)
B2C - Business-to-Consumer (Negócio para consumidor)
C2B - Consumer-to-Business (Consumidor para Negócio)
C2C - Consumer-to-Consumer (Consumidor para Consumidor)
GIS - Geographic Information System (SIG)
SIG - Sistema de Informação Geográfica (GIS)
OGC - Open Geospatial Consortium
GML - Geography Markup Language (Linguagem de Marcação de Geografias)
W3C - World Wide Web Consortium
IBGE - Instituto Brasileiro de Geografia e Estatística
SGBDE - Sistema de Gerenciamento de Banco de Dados Espaciais
API - Application Programming Interface (Interface de Programação de Aplicativos)
JEE - Java Enterprise Edition
EJB - Enterprise Java Beans
JPA - Java Persistence API
JSF - Java Server Faces
POJO - Plain Old Java Objects
HTML - Hyper Text Markup Language
CSS - Cascading Style Sheets
KML - Keyhole Markup Language
GEORSS - Geographic Really Simple Syndication
UML - Unified Modeling Language
IDE - Integrated Development Environment
DER - Diagrama Entidade-Relacionamento
Sumário
1. INTRODUÇÃO .............................................................................................................. 16
1.1. Motivação .................................................................................................................. 16
1.2. Objetivos .................................................................................................................... 18
1.2.1. Objetivo Geral .................................................................................................... 18
1.2.2. Objetivos específicos .......................................................................................... 18
1.3. Organização do trabalho ............................................................................................ 18
2. METODOLOGIA ........................................................................................................... 19
2.1. Pesquisa sobre o contexto .......................................................................................... 19
2.2. Análise e desenvolvimento do sistema ...................................................................... 19
3. ROTEIRO E EXECUÇÃO ............................................................................................ 22
3.1. Cronograma de Trabalho ........................................................................................... 22
3.1.1. Descrição das atividades ..................................................................................... 22
3.2. O que foi feito no TCC 1 ........................................................................................... 22
3.3. O que foi feito no TCC 2 ........................................................................................... 23
4. O SISTEMA DE COMPRAS GEOGRÁFICO LOOCALIZA .................................. 24
4.1. O contexto geográfico ................................................................................................ 24
4.1.1. Sistemas de Informação Geográfica (SIG) ......................................................... 24
4.2. Comércio Eletrônico .................................................................................................. 29
4.2.1. Business-to-Business (B2B) ............................................................................... 29
4.2.2. Business-to-Consumer (B2C) ............................................................................. 30
4.2.3. Consumer-to-Business (C2B) ............................................................................. 32
4.2.4. Consumer-to-Consumer (C2C) .......................................................................... 32
5. PROCESSO, DISCIPLINAS, ARTEFATOS E TECNOLOGIAS ............................ 33
5.1. Entendimento do negócio e requisitos ....................................................................... 33
5.1.1. Requisitos Funcionais ......................................................................................... 33
5.1.2. Requisitos Não Funcionais ................................................................................. 39
5.2. Análise e projeto ........................................................................................................ 39
5.2.1. Projeto Arquitetural ............................................................................................ 39
5.2.2. Diagrama de Classes ........................................................................................... 43
5.2.3. Esquema de Banco de Dados.............................................................................. 43
5.3. Implementação das funcionalidades .......................................................................... 43
5.3.1. Atividades Futuras .............................................................................................. 53
6. CONCLUSÃO ................................................................................................................. 55
REFERÊNCIAS ..................................................................................................................... 56
Apêndice A – Diagrama Entidade-Relacionamento ............................................................ 59
Apêndice B – Plano de Release .............................................................................................. 60
Apêndice C – Plano de Iterações ........................................................................................... 62
Apêndice D – Documento de User Stories ............................................................................ 67
Apêndice E – Diagrama de Classes ....................................................................................... 73
16
1. INTRODUÇÃO
O comércio eletrônico dos mais diversos tipos tem se expandido cada vez mais nos
últimos anos, abrangendo uma extensa gama de produtos e serviços oferecidos através da
rede. Segundo FELIPINI, no Brasil, o faturamento evoluiu de meio bilhão de reais em 2001,
para mais de R$ 13 bilhões de reais em 2010. Isso representa um crescimento superior a
2.300% em apenas uma década. A facilidade de comprar e vender produtos a partir de seu
próprio computador atraiu tanto grandes redes de lojas físicas quanto pequenos
empreendedores que buscam divulgar seus produtos em meio a tantas ofertas.
O Sistema de Compras Geográfico, denominado LOOCALIZA, provê um ambiente
onde o anunciante pode divulgar seu produto juntamente com sua localização, que será
representada em formato de mapa, para que assim a negociação possa ser concluída
pessoalmente, trazendo praticidade para negociantes nos diversos ramos onde sistemas de
comércio eletrônico comuns não atenderiam as expectativas.
Para o cliente, o sistema oferece a facilidade de pesquisar produtos a partir de sua
localização, podendo assim encontrar ofertas que estão próximas ou que estão em um
determinado raio de alcance, além de poder traçar rotas de compras, como por exemplo:
encontrar ofertas de carros próximos a postos de gasolina.
As possibilidades de uso do sistema são enormes. Desde vender produtos triviais até a
possibilidade de grandes redes de lojas venderem seus produtos por meio de compra coletiva.
1.1. Motivação
A cada ano que passa o e-commerce no Brasil e no mundo cresce exponencialmente,
os consumidores estão adquirindo maior confiança no comércio eletrônico, o que faz com que
eles efetuem mais compras, e indiquem os canais que já estão acostumados a comprar,
atraindo assim novos consumidores, que por sua vez, efetuam mais compras, gerando uma
maior credibilidade ao e-commerce como um todo.
Nas compras realizadas pela internet em 2010, R$ 14,8 bilhões foram movimentados,
o que representa um aumento de 40% em relação ao ano de 2009, quando o segmento faturou
R$ 10,6 bilhões. A Figura 1 mostra o faturamento anual entre o ano 2001 e 2010 e uma
previsão para o faturamento de 2011.
17
Figura 1 - Faturamento nas compras pela internet de 2001 a 2011
De acordo com a e-bit1, empresa especializada no setor de e-commerce, no mês de
novembro de 2010 foram movimentados R$ 2,2 bilhões em vendas de bens de consumo, no
Brasil! No dia das mães do ano de 2011, o setor de e-commerce registrou faturamento de R$
760 milhões. Um aumento de 22% em relação a 2010. Enquanto o comércio varejista de rua
cresceu 6,53%. Ou seja, o crescimento do comércio eletrônico foi maior do que o do varejista
de rua. A Figura 2 mostra a comparação de faturamento na época natalina entre os anos 2004
e 2010.
Figura 2 - Faturamento do e-commerce na época de Natal nos últimos anos
FONTE: e-bit, 2010.
1 http://www.e-bit.com.br
18
Segundo LÖBLER (2006), os fatores que mais contribuem para dificultar as
negociações por meio de comércio eletrônico estão “A insegurança durante a transação
através do comércio eletrônico é maior que o modo tradicional” e “A impossibilidade de
visualizar o produto dificulta a compra pela internet”.
O LOOCALIZA busca resolver os problemas de localização de produtos ou ofertas de
produtos para quem está comprando com a comodidade de se utilizar um sistema
computacional e facilidade de divulgação para pequenos empreendedores que estão vendendo
seus produtos na rede e precisam de visibilidade.
1.2. Objetivos
1.2.1. Objetivo Geral
Criar um sistema que disponibilize as funcionalidades de um comércio eletrônico nos
moldes C2C (Consumer-to-Consumer, ou Consumidor para Consumidor) onde anunciantes
podem disponibilizar produtos a venda junto com a localização de onde a oferta está
disponibilizada e o cliente possa busca-los, facilitando os processos de venda e compra de
produtos, disponibilizando informações geográficas sobre eles.
1.2.2. Objetivos específicos
Facilitar os processos de venda e compra de produtos, disponibilizando informações
geográficas sobre eles.
Resolver os problemas de localização geográfica de produtos para os clientes.
Possibilitar transações comerciais em presença física para que os clientes e vendedores
possam negociar preços e prazos.
1.3. Organização do trabalho
Este trabalho é organizado em quatro capítulos, incluindo esta introdução.
No capítulo dois será apresentado a metodologia empregada neste trabalho.
No capítulo três serão mostrados os contextos em que o sistema está inserido, como os
SIGs (Sistemas de Informações Geográficas) e comércio eletrônico.
No capítulo quatro, serão apresentados os requisitos do sistema LOOCALIZA e como
eles foram implementados, apresentando as tecnologias envolvidas no processo.
No capítulo cinco, serão apresentadas as conclusões sobre o trabalho desenvolvido.
19
2. METODOLOGIA
No desenvolvimento do projeto, foi importante que os requisitos tenham sido colhidos,
analisados, projetados e desenvolvidos de forma mais correta possível para que o resultado
alcançado seja o mais próximo do esperado. Para isso, o projeto se baseou em duas etapas
principais: pesquisa sobre o contexto ao qual a aplicação está inserida e análise e
desenvolvimento.
2.1. Pesquisa sobre o contexto
Nesta etapa foi realizado o levantamento bibliográfico sobre os contextos em que a
aplicação está inserida. Inicialmente, foi feita a pesquisa sobre os Sistemas de Informação
Geográfica para compreender os conceitos, como funcionam e como ocorre a implementação
de um SIG. Em seguida, uma pesquisa sobre os conceitos do comércio eletrônico.
Após o levantamento bibliográfico, foi necessário refinar os requisitos para que
fossem compatíveis com a pesquisa feita sobre SIGs e Comércio Eletrônico.
2.2. Análise e desenvolvimento do sistema
O sistema LOOCALIZA trata-se de um sistema web que foi desenvolvido utilizando a
plataforma Java Enterprise Edition2, que será apresentada no capítulo 4.
As etapas da implementação do software LOOCALIZA foram baseadas no processo
XP13 com algumas adaptações.
Este processo foi escolhido para este trabalho por oferecer uma metodologia ágil,
baseada no XP que segue os valores do manifesto ágil e indicada quando os requisitos
funcionais do software a ser desenvolvido não estiverem muito bem definidos e são
modificados rapidamente e devem ser definidos junto com o cliente ao longo do projeto.
O processo de desenvolvimento de software utilizado foi o XP1, que busca incorporar
tarefas que são imprescindíveis, ou seja, aquelas que precisam ser executadas em qualquer
processo de desenvolvimento de software. Além disso, o XP1 foi projetado com visão para
ambientes universitários, onde os alunos não trabalham 40 por semana horas em um projeto.
[XP01]
2 http://java.sun.com/j2ee/overview.html
3 http://www.dsc.ufcg.edu.br/~jacques/projetos/common/xp1/xp1.html
20
O XP1 define três papéis distintos que serão assumidos pelos stakeholders4: Cliente,
Desenvolvedor e o Gerente de Projeto. O Cliente tem como responsabilidade descrever as
funcionalidades desejadas (Requisitos), descrever os requisitos não funcionais, definir as
prioridades. Ao desenvolvedor, cabe a responsabilidade de ajudar a levantar as User Stories e
requisitos não funcionais junto ao cliente. Ao decorrer da fase do planejamento de iteração,
ele deve dividir as User Stories em tarefas, estimando “tempo ideal” para o desenvolvimento
de cada uma. Também é responsabilidade do desenvolvedor: elaborar o esquema lógico dos
dados, se necessário; escrever o código das tarefas; executar atividades de integração de
tarefas realizadas ao repositório de código; conversar com o cliente antes do desenvolvimento
de cada User Story para detalhar o que deverá ser implementado. As responsabilidades do
gerente são: conduzir atividades de planejamento, avaliar riscos e lidar com os riscos
descobertos, manter o progresso do projeto e auxiliar na coleta de informações auxiliares com
desenvolvedores e cliente.
Os requisitos que foram levantados na aplicação foram derivados em User Stories,
para que seja fácil para o cliente definir o business value5 de cada uma e, consequentemente, a
ordem do desenvolvimento de cada uma, respeitando as dependências, que foram levantadas
pelo desenvolvedor. Ao final do levantamento das User Stories, um Plano de Release foi
desenvolvido, que pode ser visualizado na Tabela 2 do Apêndice B. Neste projeto, todos os
papéis foram assumidos pelo autor do trabalho, pois se trata de um software que será
destinado ao público aberto e que, à medida que o sistema for utilizado, seus requisitos serão
refinados. As tarefas que foram executadas durante o desenvolvimento do projeto estão
documentadas no Plano de Iterações (Apêndice C).
Além dos artefatos já previstos no XP1, foram gerados os seguintes artefatos:
Diagramas de Caso de Uso
O diagrama de caso de uso descreve um cenário que mostra as funcionalidades do
sistema do ponto de vista do usuário. O cliente deve ver no diagrama de casos de uso as
principais funcionalidades de seu sistema. [UML01]
4 Stakeholders: pessoas ligadas ao desenvolvimento do projeto, interessados diretos ou indiretos.
5 Business Value: Valor de negócios, importante para definir a prioridade
21
Diagramas de Atividades
O objetivo do diagrama de atividades é mostrar o fluxo de atividades em um único processo.
O diagrama mostra como uma atividade depende de outras. [UML02]
22
3. ROTEIRO E EXECUÇÃO
3.1. Cronograma de Trabalho
A Tabela 1 mostra o cronograma de trabalho do projeto.
Atividade
fev/1
1
ma
r/11
ab
r/11
ma
i/11
jun
/11
jul/1
1
ag
o/1
1
set/1
1
ou
t/11
no
v/1
1
dez/1
1
jan
/12
fev/1
2
ma
r/12
A1
A2
A3
A4
A5
A6
A7
A8
A9
Tabela 1 - Cronograma de trabalho
3.1.1. Descrição das atividades
A1 - Estudo de Viabilidade: Sistemas de Compras Geográficos
A2 – Pesquisa sobre o contexto
A3 - Definição do Escopo do Sistema
A4 - Especificação de Requisitos
A5 - Análise e Modelagem do Sistema
A6 - Elaboração do Plano de Testes
A7 - Definição das Tecnologias que serão usadas
A8 - Implementação do sistema
A9 - Documento – TCC 1
3.2. O que foi feito no TCC 1
O Quadro 1 mostra os requisitos que foram desenvolvidos no TCC1:
23
ID Requisito
RF01 Realizar cadastro
RF02 Definir localização
RF03 Manter Produto
Quadro 1 - Requisitos implementados no TCC1
3.3. O que foi feito no TCC 2
No TCC2, os requisitos que não foram implementados no TCC1 entraram no
planejamento para serem desenvolvidos. O Quadro 2 mostra os requisitos que foram
implementados:
ID Requisito
RF04 Manter anúncio
RF05 Consultar anúncio
RF06 Definir favoritos
RF07 Qualificar vendedor
RF08 Visualizar histórico de qualificações
RF09 Comentar anúncio
Quadro 2 - Requisitos implementados no TCC2
24
4. O SISTEMA DE COMPRAS GEOGRÁFICO LOOCALIZA
O Sistema de Compras Geográfico LOOCALIZA é um SIG (Sistema de Informação
Geográfica) que implementa os conceitos de um comércio eletrônico em representações
computacionais.
4.1. O contexto geográfico
Trabalhar com geoinformação significa utilizar computadores como instrumentos de
representação de dados espacialmente referenciados. (CÂMARA et alli, 2004)
Deste modo, o problema fundamental da Ciência da Geoinformação é o estudo e a
implementação de diferentes formas de representação computacional do espaço geográfico.
4.1.1. Sistemas de Informação Geográfica (SIG)
Chamamos de Sistemas de Informação Geográfica (GIS) as ferramentas
computacionais usadas para Geoprocessamento. Essas ferramentas permitem realizar análises
complexas integrando dados de várias fontes e criando bancos de dados geo-referenciados.
Ainda possibilitam a automatização da produção de documentos cartográficos.
a. Geoprocessamento
A coleta de informações geográficas é uma parte importante das atividades das
sociedades organizadas. Até algum tempo atrás isto era feito apenas em documentos e mapas
impressos em papel. Um dos problemas com estes tipos de informações é que impedia uma
análise combinada de diversos mapas.
Com o avanço das tecnologias relacionadas à informática a partir dos anos 70, tornou-
se possível armazenar e representar informações geográficas em ambientes computacionais,
tornando possível o que chamamos de Geoprocessamento.
A década de 80 representa o momento quando a tecnologia de sistemas de informação
geográfica inicia um período de acelerado crescimento que dura até os dias de hoje. Até então
limitados pelo alto custo do hardware e pela pouca quantidade de pesquisa específica sobre o
tema, os GIS se beneficiaram grandemente da massificação causada pelos avanços da
microinformática e do estabelecimento de centros de estudos sobre o assunto.
O termo Geoprocessamento refere-se à disciplina do conhecimento que utiliza técnicas
matemáticas e computacionais para o tratamento da informação geográfica.
25
b. Conceitos básicos em ciência da geoinformação
É costume dizer-se que Geoprocessamento é uma tecnologia interdisciplinar, que
permite a convergência de diferentes disciplinas científicas para o estudo de fenômenos
ambientais e urbanos. Ou ainda, que “o espaço é uma linguagem comum” para as diferentes
disciplinas do conhecimento.
Apesar de aplicáveis, estas noções escondem um problema conceitual: a pretensa
interdisciplinaridade dos SIGs é obtida pela redução dos conceitos de cada disciplina a
algoritmos e estruturas de dados utilizados para armazenamento e tratamento dos dados
geográficos.
Para utilizar um SIG, é preciso que cada especialista transforme conceitos de sua
disciplina em representações computacionais. Após esta tradução, torna-se viável
compartilhar os dados de estudo com outros especialistas (eventualmente de disciplinas
diferentes). Em outras palavras, quando falamos que o espaço é uma linguagem comum no
uso de SIG, estamos nos referindo ao espaço computacionalmente representado e não aos
conceitos abstratos de espaço geográfico.
Do ponto de vista da aplicação, utilizar um SIG implica em escolher
as representações computacionais mais adequadas para capturar a
semântica de seu domínio de aplicação. Do ponto de vista da
tecnologia, desenvolver um SIG significa oferecer o conjunto mais
amplo possível de estruturas de dados e algoritmos capazes de
representar a grande diversidade de concepções do espaço.
(CÂMARA et ali, 2004, p.2)
c. Representação computacional de dados geográficos
Na Figura 3, estão mostrados os componentes de um SIG. No nível intermediário, um
SIG deve ter mecanismos de processamento de dados espaciais. A entrada de dados inclui os
mecanismos de conversão de dados. Os mecanismos de visualização e plotagem devem
oferecer suporte adequado para a apreensão cognitiva dos aspectos relevantes dos dados
pesquisados.
Cada sistema deve implementar os componentes de forma distinta, de acordo com seus
requisitos e necessidades, mas todos os subsistemas citados devem estar presentes em um
SIG.
26
Figura 3 – Arquitetura de sistemas de informação geográfica (SIG).
Fonte: Adaptado de CÂMARA, 2005.
O uso de sistemas de informação geográfica (SIG) implica em escolher as
representações computacionais mais adequadas para capturar a semântica do domínio da
aplicação.
d. Traduzindo a informação geográfica para o computador
Para abordar o problema da Geoinformação, que é produzir representações
computacionais do espaço geográfico, usamos o paradigma dos quatro universos (Figura 4),
proposto por Gomes e Velho (1995) e adaptado para a geoinformação por Câmara (1995).
Este paradigma distingue quatro passos entre o mundo real e sua realização computacional.
Figura 4 – Paradigma dos quatro universos.
Fonte: Adaptado de CÂMARA, 2005.
27
Ao criar o universo ontológico, incluímos os conceitos da realidade a serem
representados no computador, entre eles os tipos de solo, elementos e cadastros urbanos. Para
que seja funcional, é necessário que haja uma concordância entre os conceitos das partes.
Numa perspectiva mais geral, seu sucesso depende da existência de uma comunidade que
compartilhe as definições utilizadas para construí-lo.
Na maioria dos sistemas de informação atuais, as ontologias não estão explicitadas,
reduzindo assim o potencial de compartilhamento. A explicitação das ontologias de aplicação
está presente em propostas como a Web Semântica6. Para dados geográficos, existe o
consórcio OGC, o qual propôs o formato GML para descrição de ontologias espaciais.
O universo formal inclui modelos lógicos ou construções matemáticas que
generalizam os conceitos do universo ontológico. Representa um componente intermediário
entre os conceitos do universo ontológico e as estruturas de dados e algoritmos
computacionais. Uma vez que os computadores trabalham com estruturas matemáticas, a
passagem direta destes conceitos da aplicação para estruturas de dados poderia gerar dados
inconsistentes.
Foram associados valores aos diferentes conceitos; ou seja, como podemos medir o
mundo real.
O terceiro universo é o universo estrutural, onde as entidades dos modelos formais são
mapeadas para as estruturas de dados geométricas, e algoritmos que realizam operações. As
estruturas de dados utilizadas por SGBDEs (Sistemas Gerenciadores de Bancos de Dados
Espaciais) podem ser divididas em duas classes: estruturas vetoriais e estruturas matriciais.
O universo da implementação completa o processo de representação. Nesse universo,
são tomadas as decisões sobre programação, desde a arquitetura até os paradigmas que serão
usados, o que pode admitir um número grande de variações. Devem levar em conta as
aplicações às quais o sistema é voltado, a disponibilidade de algoritmos para processamento
de dados geográfico e poder computacional.
O paradigma dos quatro universos é uma forma simples de representar os processos da
transposição da realidade para o computador.
6 Segundo Berners-Lee et al. (2001), a web semântica será uma extensão da web atual
porém apresentará estrutura que possibilitará a compreensão e o gerenciamento dos
conteúdos armazenados na web independente da forma em que estes se apresentem.
28
e. Padronização para metadados geoespaciais
A padronização na geração e armazenamento dos dados facilita seu compartilhamento.
Assim, uma vez que estes estão representados em padrões livres de plataforma, diferentes
sistemas são capazes de interpretar os dados sem fazer nenhum tipo de conversão. Estes
padrões são importantes para a integração de dados.
Dentre as organizações responsáveis por essas padronizações, podemos citar no
contexto da aplicação:
OGC (Open Geospatial Consortium)
O Open Geospatial Consortium é uma organização sem fins lucrativos que visa
promover o desenvolvimento e uso de padrões de dados geoespaciais.
Os padrões criados pela OFGC são chamados de padrões abertos (Open Standards),
pois possuem as seguintes características:
Criados de forma aberta
Distribuição livre
Especificações de acesso livre e independentes de tecnologia
W3C (World Wide Web Consortium)
O World Wide Web Consortium é uma comunidade liderada por Tim Berners-Lee,
onde membros de organizações, especialistas próprios e o público em geral
trabalham juntos para desenvolver padrões, visando o crescimento da experiência
na web.
Os princípios do trabalho do W3C são:
Web para todos, seja qual for seu hardware, software, infraestrutura de rede,
idioma, cultura, localização geográfica ou habilidade física. Envolve iniciativas
de acessibilidade e internacionalização.
Web em tudo, em qualquer lugar e a qualquer hora utilizando qualquer
dispositivo. Envolve iniciativas de web móvel e para outros dispositivos.
Padrões para metadados geoespaciais são importantes para a integração de dados, pois
definem um esquema padrão para os metadados, eliminando as diferenças estruturais.
Também possuem em sua especificação os metadados, que descrevem os elementos de
29
metadados, para que não haja diferenças de interpretação sobre os valores que os elementos
devem receber.
Estes padrões são estabelecidos por organizações como o OGC, que os define e
compartilha com a comunidade promovendo a disseminação. Segundo o IBGE[2009], os
padrões de metadados geoespaciais estão conceituados e estruturados em seções com funções
específicas de:
Identificar o produtor e a responsabilidade técnica de produção;
Padronizar a terminologia utilizada;
Garantir o compartilhamento e a transferência de dados;
Viabilizar a integração de informações;
Possibilitar o controle de qualidade;
Garantir os requisitos mínimos de disponibilização.
4.2. Comércio Eletrônico
O comércio eletrônico foi adotado com o objetivo de realizar negócios por meios
eletrônicos. Podemos definir comércio eletrônico como “aquele que envolve o intercâmbio de
bens físicos e não tangíveis através de etapas, desde o marketing, passando pelo
gerenciamento de pedidos, pagamento, distribuição e pós-venda” (PAOLIELLO e
FURTADO, 2004). A internet permitiu ao comércio eletrônico ficar mais acessível para um
grande volume de usuários.
4.2.1. Business-to-Business (B2B)
O modelo Business-to-Business (Negócio para negócio) refere-se às transações entre
duas empresas, que podem ser produtos ou serviços. Podemos citar como exemplos de
transações nesse formato o comércio atacadista, compra de tecnologias e equipamentos.
a. Gerenciamento de Fornecedores
O comércio eletrônico no modelo B2B possibilita o fácil gerenciamento dos
fornecedores, a troca rápida de informações e custos reduzidos quando comparados a meios
de comunicação tradicionais.
O processo de troca de informações oferece as empresas um acesso mais rápido e mais
confiável a preços, promoções, descontos, lançamentos e novos fornecedores. Permite
também que elas mantenham-se atualizadas com redução de despesas, uma vez que não há
30
necessidade do uso de meios de comunicação tradicionais, como o telefone, para obter as
informações necessárias.
b. Gerenciamento de Estoque
Uma vez que exista confiabilidade mútua, o fornecedor tem acesso ao estoque da
empresa para que, quando o estoque encontrar-se em volume mínimo, o fornecedor possa
emitir ordem de produção ou envio de produtos em condições previamente acertadas.
Outro ponto interessante é o controle do volume do estoque em tempo real, que indica
se os produtos procurados estão ou não disponíveis no momento. Informar a ausência ou não
de um produto em tempo real é uma estratégia que atribui confiabilidade a empresa e reduz a
possibilidade de reclamações futuras.
c. Gerenciamento da Distribuição
Atualmente, o gerenciamento de distribuição no comércio eletrônico utiliza
o suporte da TI por meio das redes de comunicação, bancos de dados e
sistemas operacionais. Esses recursos devem ser bem estruturados, para que
o processo de compra e venda através do comércio eletrônico ocorra dentro
dos padrões de eficiência exigidos por essa alternativa de comercialização.
(PAOLIELLO e FURTADO, 2004, p.4)
Os processos de troca de informações possibilitam que a distribuição ocorra com
maior velocidade e segurança. Permite ainda atender satisfatoriamente aos clientes e criar
condições para os gestores reduzirem os gastos com estoques e pessoal.
d. Gerenciamento do Pagamento
O gerenciamento do pagamento permite que as empresas efetuem transações bancárias
mesmo fora do expediente bancário. Essa vantagem é fruto do uso de estruturas de comércio
eletrônicas originariamente criadas para o processo de vendas.
4.2.2. Business-to-Consumer (B2C)
A estratégia Business-to-Consumer (ou Negócio para consumidor, em português)
consiste nas empresas que veem no comércio eletrônico pela internet uma oportunidade de
retorno financeiro.
Casos de sucesso acontecem geralmente em empresas que já trabalhavam com vendas
diretas, ou seja, que já vendiam seus produtos por telefone/correio antes do advento da
Internet.
31
A grande maioria das vendas continuará sendo concluída nas lojas ou através de
representantes de vendas para determinados tipos de produtos, como por exemplo: seguros,
corretagem de imóveis, etc. Os canais tradicionais ainda têm enormes vantagens em relação à
internet nos seguintes pontos:
Proporcionam o contato físico com o produto antes da venda;
Permitem que o cliente leve o produto para casa na mesma hora da
compra;
Permite a interação com pessoas.
Em um aspecto geral, as vendas por meio de comércio eletrônico não irão substituir o
mercado real/físico. A tendência é que ela coexista e auxilie os outros canais de vendas.
O desafio para as lojas físicas são os consumidores que pesquisam preços em
diferentes lojas na rede, mas que ainda assim preferem testar o produto in loco antes de
compra-los.
Para empresas tradicionais, é importante que elas pensem em investimentos no canal
internet, uma vez que os consumidores utilizam cada vez mais esse canal para pesquisar e
comprar. A maior parcela desse público encontra-se entre adolescentes, jovens e executivos,
que tem a Internet como parte de sua rotina.
Uma das estratégias de comércio eletrônico baseada no B2C que está em ascensão
atualmente é a Compra Coletiva. Nessa estratégia, os parceiros comerciais do sistema de
comércio eletrônico tem oportunidade de atingir milhares de pessoas por meio de vouchers
que trazem descontos significativos através de compra coletiva, possibilitando assim, o
contato direto entre empresas e clientes.
A lógica de funcionamento de um site de compra coletiva é simples. A empresa que
fornece os produtos oferece um produto. O site anuncia o item em seu site com um desconto
agressivo (até 90%, em alguns casos) e tem o direito a uma comissão sobre as vendas.
Para que a transação se concretize, é necessário que haja uma mobilização na rede, ou
seja, um grande número de interessados no produto/serviço.
Assim como acontece em qualquer compra, quando o consumidor paga por muitos
produtos e tem direito a um desconto, nas compras coletivas o pagamento é feito ao site que é
mediador da compra que, por sua vez, repassa para o fornecedor como se fosse uma única
compra, garantindo assim grandes descontos.
32
Outra estratégia derivada do B2C é o B2B2C. Essa estratégia é a criação de web sites
de fabricantes que permitem a pesquisa dos produtos, encaminhando os resultados para os
web sites dos revendedores.
4.2.3. Consumer-to-Business (C2B)
Aplicações que utilizam a estratégia C2B (Consumer-to-Business ou Consumidor para
Negócio) geralmente são websites que disponibilizam informações de pessoas físicas que
oferecem serviços a pessoas jurídicas.
4.2.4. Consumer-to-Consumer (C2C)
No modelo C2C (Consumidor para Consumidor), as transações são efetuadas
diretamente entre duas pessoas físicas. Exemplos desse tipo de comércio sãos os sites de
leilão. Estes sites promovem leilões virtuais de produtos dos usuários finais. Essa estratégia
provê condições para que os consumidores comercializem entre si qualquer tipo de bem e/ou
serviço. Atualmente, a maioria dos serviços C2C implementam os conceitos mais importantes
de comércio eletrônico.
33
5. PROCESSO, DISCIPLINAS, ARTEFATOS E TECNOLOGIAS
5.1. Entendimento do negócio e requisitos
Nos próximos subitens são abordados os requisitos funcionais e não funcionais que
foram levantados para o LOOCALIZA.
5.1.1. Requisitos Funcionais
Um requisito funcional descreve uma determinada ação (ou função) que o sistema
deverá suportar (SILVA e VIDEIRA, 2005). O Quadro 3 descreve os requisitos funcionais do
LOOCALIZA.
ID Requisito Descrição
RF01 Realizar cadastro Realizar o cadastro de um usuário no
sistema.
RF02 Definir localização Definir a localização atual do usuário.
RF03 Manter produto Cadastrar um produto
RF04 Manter anúncio Cadastrar um anúncio para um produto.
RF05 Consultar anúncio Consultar um anúncio de acordo com
critérios.
RF06 Definir favoritos Definir os anúncios favoritos para que
sejam consultados no futuro.
RF07 Qualificar vendedor Qualificar o vendedor por meio de um
texto e com uma nota de 1 a 5 estrelas.
RF08 Visualizar histórico de
qualificações
Visualizar quais vendedores foram
qualificados anteriormente pelo usuário.
RF09 Comentar anúncio Comentar em um anúncio afim de
esclarecer dúvidas.
Quadro 3 – Requisitos funcionais do sistema LOOCALIZA
No sistema LOOCALIZA existem 2 atores que desempenham atividades em comum e
também atividades específicas de cada um. Os casos de uso são demonstrados na Figura 5.
34
Figura 5 - Casos de uso do sistema LOOCALIZA
Serão detalhados os requisitos do sistema que foram levantados. Foram utilizados
diagramas de caso de uso para melhor o entendimento.
RF01: Realizar Cadastro
O cadastro de usuários deve ser disponibilizado em dois tipos: cadastro de clientes e
cadastro de vendedores. Cada tipo de cadastro gera um usuário diferente no sistema, com
funcionalidades distintas. A Figura 6 mostra que os dois atores Cliente e Vendedor estão
envolvidos no caso de uso “Realizar cadastro”.
35
Figura 6 – Caso de uso “Realizar Cadastro”
RF02: Definir Localização
A definição de localização é disponibilizada após o cadastro. O sistema deve
disponibilizar um mapa para que o usuário indique onde ele se encontra geograficamente.
Tanto o ator Cliente quanto o ator Vendedor estão envolvidos no caso de uso “Definir
Localização”.
RF03: Manter Produto
Para realizar as tarefas de cadastro de produto, é necessário que o ator Vendedor esteja
autenticado no sistema, de forma que somente este tipo de ator possa realizar esta tarefa. A
Figura 7 mostra o diagrama de atividades que mostra os passos necessários para que o
vendedor efetue um cadastro de produto.
36
Figura 7 - Diagrama de atividades "Cadastrar Produto"
Os produtos servem para que o vendedor possa criar anúncios e associá-los a
determinado produto, sendo assim, o ator cliente não tem conhecimento de quais produtos
foram cadastrados, mas sim de quais anúncios estão veiculados a ele.
A Figura 8 mostra que apenas o ator Vendedor deve realizar as varias das atividades
relacionadas aos produtos.
Figura 8 – Caso de uso “Manter Produto”
RF04: Manter Anúncio
O vendedor poderá realizar cadastro, edição e exclusão de anúncios. Os anúncios são a
forma como os clientes visualizam o que está disponível para compras e negociações no
37
sistema LOOCALIZA, como citado anteriormente o ator cliente não tem conhecimento de
quais produtos foram cadastrados mas sim de quais anúncios estão veiculados a ele. A Figura
9 mostra que apenas o Vendedor está envolvido nas atividades relacionadas a manter um
produto.
Figura 9 - Caso de uso "Manter anúncio"
RF05: Consultar Anúncio
Os atores Cliente e Vendedor podem sonsultar um anúncio de acordo com critérios. Os
anúncios devem ser consultados de duas formas.
A partir do requisito de consultar anúncios, foram geradas duas User Stories, que se
encontram documentadas no Apêndice C: “Consultar Anúncio Isoladamente” (Quadro 8) e
“Consultar Anúncio em Conjunto” (Quadro 9).
O plano de releases (Tabela 2) mostra que a segunda release contém apenas uma
iteração (Tabela 4) com um tempo superior ao planejado para a primeira release, isso se deve
ao fato da complexidade do desenvolvimento destas funcionalidades.
A Figura 10 mostra que tanto os Clientes como o Vendedor estão envolvidos nas
atividades relacionadas com buscas de anúncios, tanto de forma isolada como de forma
conjunta.
38
Figura 10 - Caso de uso "Consultar Anúncio"
RF06: Definir favoritos
O ator Cliente pode favoritar anúncios no site para que possa consulta-los de forma
rápida em um momento posterior, e ainda, ser lembrado quando um anúncio está próximo da
data de expirar
RF07: Qualificar vendedor
O ator Cliente pode qualificar os vendedores com os quais já fez alguma negociação,
atribuindo uma nota a ele e um comentário. O Quadro 14 representa a User Story que foi
gerada a partir deste requisito.
Figura 11 - Diagrama de atividades "Qualificar Vendedor"
A Figura 11 representa o diagrama que demonstra as atividades relacionadas a
“Qualificar vendedor”.
39
RF06: Visualizar Histórico de Qualificações
O atore Cliente pode verificar o seu histórico de qualificações, ou seja, quais
vendedores ele já atribuiu notas e comentários para que possa ter uma lista com os vendedores
de sua preferência dentro do sistema.
RF06: Comentar em anúncios
Os atores Cliente e Vendedor podem comentar em um anúncio, para que possam
interagir tirando dúvidas acerca de como se dará a negociação. Para comentar em um anúncio,
o usuário só precisa estar autenticado no sistema.
Figura 12 - Caso de uso "Comentar anúncio"
A Figura 12 mostra que tanto o ator Cliente como o ator Vendedor estão envolvidos nas
atividades relacionadas a Comentar Anúncio.
5.1.2. Requisitos Não Funcionais
Um requisito não funcional descreve um aspecto (não funcional) que o sistema deve
satisfazer. Requisitos não funcionais têm a ver com aspectos gerais do sistema tais como:
desempenho, robustez, fiabilidade, distribuição, segurança, integração com a Internet,
abertura, ou suporte de Standards (SILVA e VIDEIRA, 2005). No sistema LOOCALIZA,
foram levantados os seguintes requisitos não funcionais:
Interface de acesso por meio de browser
5.2. Análise e projeto
5.2.1. Projeto Arquitetural
A Figura 13 demonstra graficamente a arquitetura do sistema LOOCALIZA. Baseado
na arquitetura MVC, o projeto foi dividido em três camadas.
40
Figura 13 – Visão gráfica da arquitetura do sistema LOOCALIZA
Detalhamento da arquitetura
A camada de apresentação oferece uma interface web para o cliente, a qual pode ser
acessada através de um browser. As páginas de acesso foram desenvolvidas utilizando
Facelets, que é a tecnologia padrão do Java Server Faces 2.0. Facelets e oferece um modelo
mais simples e poderoso de programação [JSF02].
Juntamente com o JSF 2.0 foram utilizadas as seguintes biblioteca de componentes:
Primefaces7. A opção por essa biblioteca foi pela facilidade de configuração e
utilização em comparação a outras bibliotecas de componentes consagradas como
Richfaces, uma vez que para utilizá-la apenas é obter o pacote Primefaces,
adicionar ao classpath da aplicação e importar o namespace [JSF03].
PrettyFaces8. Esta biblioteca foi necessária para que fosse possível mapear URLs
de forma a torna-las amigáveis (SEO-Friendly), ou seja, que possam ser
compartilhadas e que sejam de fácil entendimento pelos motores de busca [JSF04].
A biblioteca PrettyFaces faz uso de um arquivo de configurações em XML, o
pretty-config.xml que mapeia as URLs e redireciona as mesmas para a view
correspondente. A Figura 14 mostra um exemplo de URL mapeada pelo
PrettyFaces, onde a URL terminada em “/search” é direcionada para a view
“busca.jsf” que está definida na tag <view-id> e preenche o atributo “criterio”
dentro do bean gerenciado “buscaBean”, definido na tag <query-param> e
representado por Expression Language, que torna possível acessar de forma fácil
dados armazenados em componentes JavaBeans. [JSF05]
7 http://www.primefaces.org
8 http://ocpsoft.com/prettyfaces/
41
Ao fim do processo, o método “buscarAnuncios” que é definido na tag <action> é
executado.
Figura 14 - URL mapeada no pretty-config.xml
A camada de aplicação é responsável por oferecer os serviços da aplicação por meio
de beans de sessão. O servidor de aplicações Glassfish é responsável por instanciar e
disponibilizar os serviços dos beans.
A camada de persistência trabalha com a Java Persistence API. O provedor escolhido
para a persistência foi o Hibernate. Provedores de persistência que trabalham com a JPA
devem se comunicar com o banco de dados por meio de um driver JDBC. O banco de dados
escolhido foi o PostgreSQL pelos motivos citados na seção de aspectos de implementação.
As linguagens utilizadas foram:
Java
Para a implementação foi utilizado a linguagem de programação Java, desenvolvida e
suportada pela Oracle. Os motivos que levaram a decisão de usar tal linguagem para este
trabalho é que a mesma é multiplataforma, ou seja, atua em qualquer sistema operacional
desde que exista uma máquina virtual instalada. (SIERRA e BATES, 2005)
Javascript
A linguagem Javascript trabalha em conjunto com o navegador podendo tornar
páginas estáticas de conteúdo em páginas interativas e inteligentes [JAVASCRIPT01]. O
Javascript auxiliou a utilização dos mapas usados na aplicação por meio da API Javascript do
Google Maps.
Google Maps
A API do Google Maps permite usar Javascript para incorporar elementos do Google
Maps em páginas web. Oferece diversas ferramentas para manipular mapas e adicionar
contéudo, oferecendo a oportunidade de criar uma aplicação robusta e personalizada para um
website. Com a API de Javascript do Google Maps, é possível desenhar um mapa em um
documento HTML. [GMAPS01]
42
No sistema LOOCALIZA, a API Javascript do Google Maps facilitou na exibição e
controle dos mapas que são necessários para o sistema. Outra opção para implementar os
mapas seria trabalhar com XML e SVG, o que demandaria muito trabalho em mapear cidades
e ruas, tarefas que já foram realizadas pelo Google Maps.
O sistema LOOCALIZA foi implementado usando as especificações da plataforma
Java Enterprise Edition. Esta especificação define o padrão para o desenvolvimento de
aplicações corporativas de multiplas camadas. Busca simplificar as aplicações corporativas,
fornecendo um conjunto completo de serviços para componentes e pela manipulação do
comportamento do aplicativo automaticamente, sem necessidade de programação complexa.
[JEE01]
Neste trabalho foram utilizados componentes que seguem as seguintes especificações
da JEE:
EJB - Enterprise Java Beans
Enterprise Java Beans é a tecnologia de componente básica da plataforma Java
Enterprise Edition. É uma infraestrutura corporativa projetada para fornecer ao desenvolvedor
um gerenciamento automático de muitos dos serviços essenciais aos aplicativos corporativos.
(KEITH e SCHINCARIOL, 2009).
Java Persistence API
A especificação Java Persistence API define um modo padrão para a persistência de
objetos simples e comuns (POJOs) de Java para um banco de dados (KEITH e
SCHINCARIOL, 2009).
JDBC
Para acessar uma base de dados, a JPA necessita se comunicar por meio de um driver
JDBC (Java DataBase Connectivity). É a interface que possibilita as aplicações Java
acessarem bancos de dados relacionais. [JDBC01]
Java Server Faces
A tecnologia Java Server Faces estabelece um padrão para a construção de interfaces
do usuário do lado servidor. Visa o desenvolvimento de aplicações web de forma fácil e
simples. [JSF01]
43
PostgreSQL / PostGIS
O banco de dados utilizado para a aplicação foi o PostgreSQL, um SGBD objeto-
relacional de código aberto que possui capacidade para extensões como o PostGIS, uma
extensão para manipulação de dados espaciais padronizada (interoperabilidade) em uma base
de dados. O sistema utiliza o PostgreSQL com a extensão espacial PostGIS para o cálculo de
distâncias entre anúncios.
5.2.2. Diagrama de Classes
Segundo SILVA e VIDEIRA (2005), os diagramas de classes descrevem a estrutura
estática de um sistema, em particular as entidades existentes, as suas estruturas internas, e
relações entre si. A Figura 32 do apêndice E mostra o diagrama de classes geral do sistema.
5.2.3. Esquema de Banco de Dados
O DER – Diagrama de Entidade e Relacionamento é um modelo de dados baseado na
lógica de predicados e na teoria dos conjuntos. É composto em alto nível pela entidade e suas
relações. O DER do sistema é demonstrado na Figura 31 do apêndice A.
5.3. Implementação das funcionalidades
As funcionalidades implementadas no sistema foram feitas usando tecnologias baseadas
na especificação Java Enterprise Edition. O uso de JSF 2.0 com a biblioteca de componentes
Primefaces facilitou a construção de uma interface rica para o usuário com vários componentes
como calendário, verificador de força de senha, upload de arquivos entre outros. A Figura 15
mostra um exemplo do componente “Password” do Primefaces, em ação:
Figura 15 - Componente "Password" do Primefaces em ação
Foram implementados os seguintes requisitos:
RF01: Realizar Cadastro
Os usuários no sistema LOOCALIZA podem ser definidos de duas maneiras:
44
Cliente - Sendo um cliente, o usuário poderá buscar ofertas de várias maneiras
de acordo com sua localização, fazer perguntas aos vendedores e avaliar os
vendedores.
Vendedor - Sendo um vendedor, o usuário poderá cadastrar produtos, criar
anúncios para eles indicando sua localização para que as transações ocorram
com presença física, receber perguntas dos compradores e responder as
perguntas.
A Figura 16 mostra a tela de cadastro do usuário.
Figura 16 - Tela de Cadastro do LOOCALIZA
Nesta tela, o usuário pode escolher entre criar um cadastro para cliente ou para
vendedor, o sistema informa quais as funcionalidades de cada tipo de conta, clicando nos
botões dentro de cada bloco levará a um formulário com função diferente, porém, as telas de
cadastro para Cliente e Vendedor são semelhantes. A Figura 17 mostra a tela de cadastro para
Vendedor.
45
Figura 17 - Tela de cadastro de Vendedor
As senhas dos usuários no sistema LOOCALIZA são persistidas após passarem por
uma função de hash SHA-1. Hash é a transformação de uma grande quantidade de
informações em uma pequena quantidade de informações. A sequência gerada pela função de
hash busca identificar um arquivo, uma frase ou informação unicamente. É um método para
transformar dados de tal forma que o resultado busque a exclusividade [HASH01]. Além
disso, funções usadas em criptografia garantem que não é possível a partir de um valor de
hash retornar à informação original.
RF02: Definir Localização
A definição de local é disponibilizada após o usuário estar cadastrado e autenticado, é
feita por um mapa gerado com o Google Maps, onde o usuário deve apontar um local que será
guardado. O mapa foi gerado pelo componente GMap do Primefaces, as inserções de valores
de latitude e longitude nos formulários foram feitos através de JavaScript. Ao clicar em um
ponto, o mapa captura a localização do usuário e insere os valores da latitude e longitude nos
campos. A Figura 18 mostra a tela de definição do local com um ponto marcado e os valores
dentro dos respectivos campos.
46
Figura 18 - Tela de definição de local
A partir da localização do usuário, outras tarefas dentro da aplicação serão
disponibilizadas, como buscar por anúncios próximos e outros tipos de busca com base em
localização geográfica.
RF03: Manter Produto
Ao se autenticar no sistema, o vendedor poderá cadastrar, editar, listar ou excluir os
seus produtos. Nesta tela, foi utilizado o componente FileUpload para que seja possível
associar uma imagem a um produto. O componente recebe o arquivo e faz o upload
automaticamente e mostra durante o processo o andamento do upload. A Figura 19 mostra a
tela de cadastro de produtos com o componente de upload em ação.
47
Figura 19 - Tela de cadastro de produtos com componente FileUpload em ação
A listagem de produtos foi feita com o componente Datatable do Primefaces que
permite utilizar filtragem nos campos. A Figura 20 exibe a tela de listagem de produtos que
exibe uma foto do produto, seu nome, sua descrição e as ações disponíveis.
Figura 20 - Tela de Listagem de Produtos
RF04: Manter Anúncio
Quando o vendedor possui produtos cadastrados na sua conta, está habilitado a
cadastrar anúncios. A Figura 21 mostra parcialmente a tela de cadastro de anúncios, nesta
etapa o vendedor deve selecionar o produto que será vinculado ao anúncio, um produto não
pode estar cadastrado em mais de um anúncio ao mesmo tempo, portanto os produtos que já
estiverem cadastrados não aparecem listados.
48
Figura 21 - Tela parcial de "Cadastro de anúncios"
Após selecionar o produto, o vendedor deve preencher todos os outros dados.
Os dados de latitude e longitude, assim como na tela de “Definir Local” é feita por um
mapa gerado com o Google Maps, onde o usuário deve apontar um local que será guardado.
O mapa foi gerado pelo componente GMap do Primefaces, as inserções de valores nos
formulários foram feitos através de JavaScript. Ao clicar em um ponto, o mapa captura a
localização do usuário e insere os valores nos campos.
Os dados de data inicial e final são definidos por meio do componente Calendar da
biblioteca de componentes Primefaces, onde é exibido um calendário da forma convencional
e o usuário pode clicar na data para preencher os dados no formulário.
A Figura 22 mostra os componentes GMap e Calendar em ação durante o cadastro de
um anúncio no sistema.
49
Figura 22 - Componentes GMap e Calendar em ação
RF05: Consultar Anúncio
O usuário do sistema pode consultar o anúncio de duas formas distintas: isolada ou em
conjunto, porém só os usuários cadastrados e autenticados tem a possibilidade de fazer
consultas em conjunto.
A consulta isolada de anúncios é feita utilizando uma caixa de texto na parte superior
do sistema, a qual é mostrada na Figura 23, o usuário digita um termo para que o sistema
busque correspondentes no título, descrição ou tags dos anúncios. A consulta isolada não faz
uso de localização geográfica ou qualquer outra informação referente ao usuário como base
para a pesquisa.
Figura 23 - Caixa de consulta isolada
50
Já a consulta em conjunto é feita com, no mínimo, três critérios, os quais são
reproduzidos na Figura 24. A consulta de anúncios em conjunto toma como base a
localização geográfica para definir o ponto onde é o centro do raio de busca. Quando o
usuário insere um termo qualquer na busca, o sistema deverá utilizar sua localização
geográfica como o centro, criar uma geometria que represente todos os pontos que distanciam
do ponto do centro para menor ou igual à distância representada no raio (dado em
quilômetros).
Figura 24 - Formulário de consulta em conjunto
É possível utilizar-se de mais de um critério para a busca, clicando no botão a direita
da caixa de texto, o sistema irá habilitar mais um campo para que o usuário possa inserir outro
termo na pesquisa. O máximo de critérios que podem ser inseridos na busca é três.
A consulta para este caso utiliza funções específicas da extensão espacial PostGIS, foi
construída utilizando SQL e mapeando os resultados da consulta para POJOs utilizando EJB.
A Figura 25 mostra a consulta que foi utilizada para este caso.
Figura 25 - Consulta SQL de anúncios em conjuntos
Ao encontrar um anúncio desejado, o sistema exibe a tela de visualização de anúncios, onde o
Cliente e o Vendedor podem trocar informações sobre o produto e a negociação por meio de
comentários, além de outras informações já disponibilizadas pelo sistema. A Figura 26 mostra
a tela de visualização de usuários.
51
Figura 26 - Tela de visualização de anúncio
Clicando no botão “Calcular Rota”, o qual só está disponível para usuários cadastrados e
autenticados, o sistema irá criar a rota que o usuário precisa tomar para chegar até aquele
anúncio. A rota é criada utilizando o serviço Google Maps Directions API, que é um serviço
que calcula rotas entre os locais usando uma solicitação HTTP. As rotas podem especificar
origens, destinos e pontos de referência como strings de texto (por exemplo, "Cajazeiras, PB -
Brazil" ou "Darwin, NT, Austrália") ou como coordenadas de latitude/longitude [GMAPS02].
A Figura 27 mostra a tela do sistema que cria uma rota entre o local do usuário (A) e o
anúncio que ele deseja alcançar (B).
52
Figura 27 - Tela de visualização de rota
RF06: Definir favoritos
O usuário do tipo Cliente poderá definir anúncios como favoritos que estejam no site
para que possa visualizá-los em um momento posterior ou para ser avisado quando estes
estiverem perto de sua data de expirar. A Figura 26 mostra a tela de visualização de anúncios,
onde quando o usuário autenticado é um Cliente, será exibida a opção de adicionar o anúncio
aos favoritos.
RF07: Qualificar vendedor / RF08: Visualizar histórico de qualificações
O usuário do tipo Cliente poderá qualificar um vendedor para que possa atribuir valor
aos vendedores que já concluiu algum tipo de transação comercial e para ter uma lista
personalizada de quem são os vendedores mais confiáveis de acordo com suas próprias
experiências dentro do sistema. Cada Cliente só pode qualificar uma vez cada vendedor. A
Figura 28 mostra a tela de qualificação de vendedor.
Figura 28 - Qualificação de vendedor
53
RF09: Comentar anúncios
Os usuários do tipo Cliente e Vendedor podem adicionar comentários em um anúncio
com o objetivo de esclarecer dúvidas a cerca da qualidade/estado do produto, formas de
pagamento, formas de entrega, entre outras informações. A Figura 29 mostra um exemplo de
comentários entre Vendedor e Cliente, é por meio dos comentários que os usuários podem
manter contato até concluir a negociação.
Figura 29 - Comentários em anúncio
5.3.1. Atividades Futuras
Com a intenção de se tornar mais prático e útil para quem trabalha com negociações, o
sistema LOOCALIZA será implementado em plataformas móveis como Android e iOS, que
são as plataformas móveis mais utilizadas do mercado, segundo pesquisa do website Pingdom
[MOBILE01]. A Figura 30 mostra um comparativo dos sistemas operacionais mais utilizados
no período que abrange Fevereiro de 2011 a Fevereiro de 2012.
54
Figura 30 - Comparativo entre sistemas operacionais móveis
O sistema móvel auxiliará quem trabalha com negociações, utilizando localização
definida por GPS dos dispositivos móveis e atualizando os dados em tempo real.
Prover webservices para que seja possível implementar outras ferramentas baseadas
nas informações de anúncios cadastrados no site, como localizações, disponibilidades e
preços.
55
6. CONCLUSÃO
O sistema de compras geográfico LOOCALIZA foi desenvolvido como uma
alternativa ao e-commerce tradicional visando pular etapas que não são essenciais em
algumas negociações. A proposta do sistema é inovadora, pois trás para os usuários novas
oportunidades de negociações, tornando possível montar uma reputação sólida com clientes
reais onde as negociações podem ocorrer presencialmente, provendo mais confiabilidade e
qualidade as vendas.
O desenvolvimento do sistema proporcionou uma grande base de conhecimento, pois
integrou várias tecnologias para obter o resultado esperado. Muitas das tecnologias utilizadas
neste trabalho não haviam sido mostradas durante o curso, o que trouxe a necessidade de
estudar todas as tecnologias até chegar na decisão de quais seriam utilizadas para melhor
atender as necessidades.
Além disso, o projeto proporcionou o crescimento de conhecimento na utilização de
processos de desenvolvimento baseados em metodologias ágeis, auxiliando a análise e
organização das etapas do desenvolvimento, proporcionando ganho de produtividade.
56
REFERÊNCIAS
[DER01] Aprendendo sobre MER – Modelo de Entidade e Relacionamento e DER –
Diagrama de Entidade e Relacionamento. Disponível em
<http://www.eia.com.br/wp/banco-de-dados/aprendendo-sobre-mer-modelo-de-entidade-e-
relacionamento-e-der-diagrama-de-entidade-e-relacionamento/>. Acesso em 24 Julho 2011.
[GMAPS01] Google Maps JavaScript API V3. Disponível em
<http://code.google.com/intl/pt-BR/apis/maps/documentation/javascript/> Acesso em 05
Abril. 2011.
[GMAPS02] Google Directions API – Google Maps API. Disponível em
<https://developers.google.com/maps/documentation/directions/?hl=pt-br>. Acesso em 20
Janeiro 2012.
[HASH01] STAMP, Mark. Information security: principles and practice. John Wiley,
2005.
[JAVASCRIPT01] GOODMAN, Danny; MORRISON, Michael. Javascript Bible. Wiley,
2007.
[JDBC01] Jdbc, JAVA DATABASE CONNECTIVITY. Disponível em
<http://www.slideshare.net/raquelcarsi/jdbc-java-database-connectivity-presentation> Acesso
em 26/07/2011.
[JEE01] Java 2 Platform, Enterprise Edition (J2EE) Overview. Disponível em <
http://java.sun.com/j2ee/overview.html>. Acesso em 24 Julho 2011.
[JSF01] JavaServer Faces Technology. Disponível em <
http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html>. Acesso em 24
Julho 2011.
[JSF02] JSF 2.0 Views: Hello Facelets, Goodbye JSP. Disponível em
<http://www.developer.com/java/web/article.php/3867851/JSF-20-Views-Hello-Facelets-
Goodbye-JSP.htm>. Acesso em 25 Julho 2011.
[JSF03] Primefaces – Getting Started. Disponível em
<http://www.primefaces.org/gettingStarted.html>. Acesso em 05 Novembro 2011.
57
[JSF04] PrettyFaces – JSF2. Disponível em <http://ocpsoft.com/prettyfaces/>. Acesso em 30
Janeiro 2012.
[JSF05] The J2EE Tutorial - Expression Language. Disponível em
<http://docs.oracle.com/javaee/1.4/tutorial/doc/JSPIntro7.html>. Acesso em 30 Janeiro 2012.
[MOBILE01] Symbian is still top mobile OS – finished 2011 with resurgence. Disponível
em < http://royal.pingdom.com/2011/12/29/symbian-is-still-top-mobile-os-finished-2011-
with-resurgence/>. Acesso em 23 Fevereiro 2012.
[UML01] SAUVÉ, Jacques Philippe. Diagramas de Use Cases. Disponível em
<http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/usecases/usecases.htm
> Acesso em 23/05/2011.
[UML02] SAUVÉ, Jacques Philippe. Diagramas de Atividades. Disponível em <
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/atividades/diag_ativida
des.htm>. Acesso em 23/07/2011.
[UML03] SILVA, Alberto; VIDEIRA, Carlos. UML – Metodologias e Ferramentas CASE.
Centro Atlântico, 2005.
[XP01] SAUVÉ, Jacques Philippe. XP1 : Um Processo de Desenvolvimento. Especificação
do processo. Disponível em
<http://www.dsc.ufcg.edu.br/~jacques/projetos/common/xp1/xp1.html> Acesso em
23/05/2011.
CÂMARA, Gilberto et al. Bancos de Dados Geográficos. Curitiba: MundoGEO, 2005.
CÂMARA, Gilberto; MONTEIRO, Antônio Miguel; MEDEIROS, José Simeao. Introdução
a Ciência da Geoinformação. São José dos Campos: INPE, 2004.
FELIPINI, Dalton. Empreendedorismo na Internet, o momento é agora. eCommerceOrg.
Disponível em: <http://www.e-commerce.org.br/artigos/empreendedorismo-internet.php>.
Acesso em: 14 Julho. 2011.
IBGE. Plano de ação para implantação da Infra-Estrutura Nacional de Dados Espaciais.
Brasil, 2010. Disponível em:
<http://www.concar.ibge.gov.br/arquivo/PlanoDeAcaoINDE.pdf>. Acesso em: 14 Julho.
2011
58
KEITH, Mike; SCHINCARIOL, Merrick. Pro JPA 2, Mastering the Java Persistence API.
Apress, 2009.
LIMA, Thiago. E-Commerce no Brasil – Dados surpreendentes. Disponível em:
<http://emanuais.com.br/blog/e-commerce-no-brasil-dados-surpreendentes/2011/08/21/>.
Acesso em: 7 Março. 2012.
LÖBLER, Mauri Leodir; VISENTINI, Monize Sâmara; BOBSIN, Debora. Entendendo o
comprador virtual através dos determinantes do seu comportamento. Disponível em: <
http://www.abepro.org.br/biblioteca/ENEGEP2006_TR530352_7209.pdf >. Acesso em: 7
Março. 2012.
PAOLIELLO e FURTADO. Sistemas de Informação para Comércio Eletrônico.
04.06.2004.44f. Dissertação. Instituto de Informática Pontifícia da Universidade Católica Rio
de Janeiro. 2004 Rio de Janeiro.
SIERRA, Kathy e BATES, Bert. Use a Cabeça! Java. Rio de Janeiro: Alta Books, 2005.
59
Apêndice A – Diagrama Entidade-Relacionamento
Figura 31 - Diagrama Entidade-Relacionamento do Sistema LOOCALIZA
60
Apêndice B – Plano de Release
Plano de Releases
Equipe com 1 (um) desenvolvedor
Release 1
Data inicial: 11/07/2011
Data final: 02/08/2011
Número de iterações: 2
US Título Prioridade Número de horas
1 Cadastrar usuário 1 30
2 Definir localização 2 10
3 Cadastrar produtos 3 30
Total 70
Release 2
Data inicial: 24/10/2011
Data final: 22/12/2011
Número de iterações: 1
US Título Prioridade Número de horas
4 Cadastrar anúncio 4 40
5 Consultar anúncio isoladamente 5 10
6 Consultar anúncio em conjunto 6 90
7 Visualização de anúncios 7 20
8 Verificar rota 8 20
Total 180
Release 3
Data inicial: 20/02/2012
Data final: 15/03/2012
Número de iterações: 2
US Título Prioridade Número de horas
9 Comentar anúncios 9 10
10 Favoritar anúncios 10 15
11 Qualificar vendedor 11 20
61
12 Visualizar histórico de qualificações 12 5
Total 50
Tabela 2 - Plano de releases
62
Apêndice C – Plano de Iterações
Plano de Iteração
Release 1
Iteração 1
Data inicial: 11/07/2011
Data final: 17/07/2011
Número das User Stories desenvolvidas: 1, 2.
Desenvolvedor: Diogo Moreira
Descrição: Modelagem das entidades do sistema utilizando JPA, Cadastro das entidades
Cliente, Vendedor; Definição de local do usuário.
Tarefas Descrição Desenvolvedor Número
de horas
Concluíd
a
1.1 Fazer a modelagem do banco
de dados para as entidades
Usuário, Cliente, Vendedor,
Produto, Tag, Anuncio,
Comentário e Qualificação.
Diogo 10 Sim
1.2 Mapear as entidades
utilizando JPA.
Diogo 5 Sim
1.3 Planejar e mapear possíveis
consultas
Diogo 5 Sim
1.4 Programar as interfaces de
serviços EJB
Diogo 5 Sim
1.5 Implementação dos serviços
EJB para o cadastro e
autenticação de Cliente e
Vendedor
Diogo 10 Sim
1.6 Criar banco de dados
utilizando Postgis
Diogo 1 Sim
1.7 Criar unidade de persistência Diogo 0,5 Sim
1.8 Criar beans gerenciados para
as telas de cadastro de
vendedor e cliente.
Diogo 5 Sim
1.9 Criar visão para cadastro de
vendedor e cliente
Diogo 3 Sim
1.10 Criar bean gerenciado para
tela de definição de local do
usuário.
Diogo 3 Sim
63
1.11 Criar visão para definição de
local do usuário.
Diogo 5 Sim
Iteração 2
Data inicial: 18/07/2011
Data final: 02/08/2011
Número das User Stories desenvolvidas: 3.
Desenvolvedor: Diogo Moreira
Descrição: Criação da lógica para Cadastro de produtos.
Tarefas Descrição Desenvolvedor Número
de horas
Concluíd
a
2.1 Criar beans gerenciados para
a tela de Cadastro de Produto
Diogo 10 Sim
2.2 Implementação dos serviços
EJB para o cadastro e
autenticação de Cliente e
Vendedor
Diogo 5 Sim
2.3 Criar visão para cadastro de
produto
Diogo 5 Sim
2.4 Criar bean gerenciado para
visualização de produtos
cadastrados
Diogo 5 Sim
2.5 Criar visão para visualização
de produtos cadastrados.
Diogo 5 Sim
Tabela 3 - Plano de iterações da release 1
Plano de Iteração
Release 2
Iteração 1
Data inicial: 24/10/2011
Data final: 22/12/2011
Número das User Stories desenvolvidas: 4,5,6,7,8.
Desenvolvedor: Diogo Moreira
Descrição: Criação da lógica para Cadastro de anúncios, Criação das consultas de anúncio e
verificação de rotas.
Tarefas Descrição Desenvolvedor Número
de horas
Concluíd
a
1.1 Criar beans gerenciados para
a tela de Cadastro de Anúncio
Diogo 10 Sim
64
1.2 Implementação dos serviços
EJB para o cadastro de
anúncios
Diogo 5 Sim
1.3 Criar visão para cadastro de
anúncio
Diogo 15 Sim
1.4 Criar bean gerenciado para
visualização de anúncios
cadastrados
Diogo 10 Sim
1.5 Criar visão para visualização
de anúncios cadastrados.
Diogo 10 Sim
1.6 Criar consulta de anúncio de
forma isolada.
Diogo 1 Sim
1.7 Implementação dos serviços
EJB para a consulta de
anúncios de forma isolada
Diogo 1 Sim
1.8 Criar visão para consulta de
anúncios de forma isolada.
Diogo 3 Sim
1.9 Criar consulta de anúncio em
conjunto.
Diogo 40 Sim
1.10 Implementação dos serviços
EJB para a consulta de
anúncios em conjunto.
Diogo 20 Sim
1.11 Criar visão para consulta de
anúncios em conjunto.
Diogo 30 Sim
1.12 Criar visão para visualização
de anúncios
Diogo 20 Sim
1.13 Criar visualização de rotas Diogo 25 Sim
Tabela 4 - Plano de iterações da release 2
Plano de Iteração
Release 3
Iteração 1
Data inicial: 20/02/2012
Data final: 22/02/2012
Número das User Stories desenvolvidas: 9,10.
Desenvolvedor: Diogo Moreira
Descrição: Criação da lógica para comentários em anúncio e de favoritar anúncios.
65
Tarefas Descrição Desenvolvedor Número
de horas
Concluíd
a
1.1 Modificar beans gerenciados
para que possam prover os
serviços necessários para
comentar em anúncios
Diogo 5 Sim
1.2 Implementação dos serviços
EJB para comentários em
anúncios.
Diogo 2,5 Sim
1.3 Modificar visão de anúncio
para que possa prover o
comentário em anúncios
Diogo 2,5 Sim
1.4 Modificar beans gerenciados
para que possam prover
serviços para favoritar
anúncios
Diogo 5 Sim
1.5 Implementação dos serviços
EJB para favoritar anúncios.
Diogo 2,5 Sim
1.6 Modificar visão de anúncio
para que possa prover a
funcionalidade de favoritar
anúncios
Diogo 2,5 Sim
1.7 Criar visão de visualização de
anúncios favoritados
Diogo 5 Sim
Iteração 2
Data inicial: 25/02/2012
Data final: 15/02/2012
Número das User Stories desenvolvidas: 11,12.
Desenvolvedor: Diogo Moreira
Descrição: Criação da lógica para qualificação de vendedor.
Tarefas Descrição Desenvolvedor Número
de horas
Concluíd
a
2.1 Criar bean gerenciado para
qualificação de vendedor
Diogo 5 Sim
2.2 Implementação dos serviços
EJB para a qualificação de
vendedor.
Diogo 5 Sim
2.3 Criar visão para qualificação
de vendedor
Diogo 5 Sim
66
2.4 Criar visão para visualizar
qualificações feitas.
Diogo 5 Sim
Tabela 5 - Plano de iterações da release 3
67
Apêndice D – Documento de User Stories
User Story 1 – Cadastrar Usuário
Business Value Alto (Prioridade – 1)
Status Concluída
Descrição O sistema deve permitir ao usuário que crie uma conta no
sistema para que possa acessar funcionalidades exclusivas.
Observações O cadastro de usuários deve ser disponibilizado em dois tipos:
cadastro de clientes e cadastro de vendedores. O cadastro para
ambos os atores envolve os seguintes dados:
Senha
Nome
Localização geográfica
Foto (opcional)
Cada tipo de cadastro gera um usuário diferente no sistema,
com funcionalidades distintas
Dependência Nenhuma
Tempo ideal 30h
Tempo consumido 44h
Quadro 4 - User Story 1 - Cadastrar Usuário
User Story 2 – Definir localização
Business Value Alto (Prioridade – 2)
Status Concluída
Descrição O sistema deve permitir aos usuários que definam sua
localização atual.
Observações Na definição de local, o usuário fará uso de um mapa dinâmico
onde poderá indicar o local onde ele está, as funcionalidades
posteriores irão se utilizar desta informação para realizar suas
funções.
Dependência Cadastrar Usuário
Tempo ideal 10h
Tempo consumido 8h
Quadro 5 - User Story 2 - Definir Localização
User Story 3 – Cadastrar Produtos
Business Value Alto (Prioridade – 3)
68
Status Concluída
Descrição O sistema deve permitir ao usuário do tipo Vendedor que
cadastre produtos do seu estoque no sistema.
Observações O cadastro de produtos envolve os seguintes dados:
Nome
Descrição
Tags
Imagem
Os produtos são visualizados apenas pelo vendedor, não
interessando ao cliente. O produto será usado no cadastro de
anúncios.
Dependência Cadastrar Usuário
Tempo ideal 25h
Tempo consumido 30h
Quadro 6 - User Story 3 - Cadastrar Produtos
User Story 4 – Cadastrar Anúncio
Business Value Alto (Prioridade – 4)
Status Concluída
Descrição O sistema deve permitir ao usuário do tipo Vendedor que
cadastre anúncios para seus produtos no estoque do sistema.
Observações O anúncio deve conter os seguintes dados:
Título
Produto
Descrição
Localização
A localização deve ser definida através de um mapa
onde o usuário vai indicar o seu local e o sistema vai
obter latitude e longitude.
Preço
Data de início do anúncio
Data do fim do anúncio
Os anúncios são a forma como os clientes visualizam o que está
disponível para compras e negociações no sistema.
Dependência Cadastrar Usuário, Cadastrar Produto, Definir Localização
Tempo ideal 40h
Tempo consumido 65h
Quadro 7 - User Story 4 - Cadastrar Anúncio
69
User Story 5 – Consultar Anúncio Isoladamente
Business Value Médio (Prioridade – 5)
Status Concluída
Descrição O sistema deve permitir a qualquer usuário (cadastrado ou não)
buscar anúncios no sistema, independente da sua localização
geográfica.
Observações A pesquisa por anúncio de forma isolada utiliza um termo para
procurar no título e/ou descrição do anúncio ou as tags do
produto se os mesmos correspondem com o critério digitado.
Dependência Cadastrar Produto, Cadastrar Anúncio
Tempo ideal 10h
Tempo consumido 10h
Quadro 8 - User Story 5 - Consultar Anúncio Isoladamente
User Story 6 – Consultar Anúncios em Conjunto
Business Value Alta (Prioridade – 6)
Status Concluída
Descrição O sistema deve permitir a qualquer usuário cadastrado buscar
anúncios no sistema, baseado em sua localização geográfica.
Observações A pesquisa por anúncio de forma conjunta se utiliza até de três
critérios de texto, sendo um deles obrigatório. Além disso, é
obrigatório indicar o raio da busca. A pesquisa funciona com
base na localização previamente definida pelo usuário,
procurando anúncios que correspondam com os critérios
digitados e que intersectem a área do raio (ou seja, estejam
dentro da área do raio). Uma vez que tem como base a
localização definida pelo usuário, a pesquisa em conjunto só
deve ser acessível a usuários cadastrados e autenticados no
sistema
Dependência Cadastrar Produto, Cadastrar Anúncio
Tempo ideal 90h
Tempo consumido 200h
Quadro 9 - User Story 6 - Consultar Anúncios em Conjunto
User Story 7 – Visualização de anúncios
Business Value Alta (Prioridade – 7)
Status Concluída
Descrição O sistema deve permitir a qualquer usuário (cadastrado ou não)
70
visualizar os anúncios do sistema por meio de uma URL única.
Observações Nenhuma
Dependência Cadastrar Produto, Cadastrar Anúncio
Tempo ideal 20h
Tempo consumido 20h
Quadro 10 - User Story 7 – Visualização de anúncios
User Story 8 – Verificar rota
Business Value Alta (Prioridade – 8)
Status Concluída
Descrição O sistema deve permitir a qualquer usuário cadastrado verificar
a rota que ele precisa tomar para chegar até o local do anúncio,
baseado em sua localização previamente definida.
Observações Para saber a rota, o usuário deve estar autenticado no sistema e
estar em uma página que referecie o anúncio, a página que irá
mostrar a rota não deve ser um pop-up ou outra página, é
necessário que seja na mesma página.
Dependência Cadastrar Produto, Cadastrar Anúncio
Tempo ideal 20h
Tempo consumido 25h
Quadro 11 - User Story 8 – Verificar rota
User Story 9 – Comentar em anúncios
Business Value Média (Prioridade – 7)
Status Concluída
Descrição O sistema deve permitir a qualquer usuário cadastrado comentar
em um anúncio no sistema.
Observações O sistema deve permitir a qualquer usuário cadastrado, e
somente aos cadastrados, comentar em anúncios para perguntar
ou responder perguntas sobre um anúncio em específico.
Dependência Cadastrar Usuário, Cadastrar Anúncio, Consultar Anúncio
Isoladamente
Tempo ideal 10h
Tempo consumido 10h
Quadro 12 - User Story 9 - Comentar em anúncios
71
User Story 10 – Favoritar anúncios
Business Value Baixa (Prioridade – 8)
Status Em desenvolvimento
Descrição O sistema deve permitir a qualquer usuário cadastrado favoritar
os anúncios de sua preferência para que possa consulta-los em
um momento posterior.
Observações O usuário deverá estar autenticado para favoritar os anúncios de
sua preferência.
Dependência Cadastrar Usuário, Cadastrar Anúncio, Consultar Anúncio
Isoladamente
Tempo ideal 10h
Tempo consumido 10h
Quadro 13 - User Story 10 - Favoritar anúncios
User Story 11 – Qualificar vendedor
Business Value Média (Prioridade – 9)
Status Planejada
Descrição O sistema deve permitir a qualquer usuário cadastrado
qualificar os vendedores,.
Observações O usuário deverá estar logado para qualificar um vendedor. Na
qualificação, os dados envolvidos na qualificação são:
Mensagem
Nota
A nota deve ser de 1 a 5, utilizando um sistema de
estrelas para facilitar o entendimento do usuário.
Um usuário não pode qualificar o mesmo vendedor duas vezes.
Dependência Cadastrar Usuário
Tempo ideal 20h
Tempo consumido 20h
Quadro 14 - User Story 11 - Qualificar Vendedor
User Story 12 – Visualizar histórico de qualificações
Business Value Baixa (Prioridade –10)
Status Planejada
Descrição O sistema deve permitir a qualquer usuário cadastrado e que já
tenha qualificado um vendedor, visualizar seu histórico de
qualificações.
72
Observações O usuário deverá estar logado para visualizar as qualificões que
já fez a um ou mais vendedores.
Dependência Cadastrar Usuário
Tempo ideal 5h
Tempo consumido 5h
Quadro 15 - User Story 12 - Visualizar histórico de qualificações
73
Apêndice E – Diagrama de Classes
Figura 32 - Diagrama de classes do sistema LOOCALIZA