loocaliza - sistema de compras geográfico

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


LOOCALIZA


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


LOOCALIZA


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



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

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

http://java.sun.com/j2ee/overview.html

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/

http://www.primefaces.org/

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.

http://www.slideshare.net/raquelcarsi/jdbc-java-database-connectivity-presentation

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





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





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



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



Número das User Stories desenvolvidas: 3.


Descrição: Criação da lógica para Cadastro de produtos.


de horas

Concluíd

a


a tela de Cadastro de Produto

Diogo 10 Sim


EJB para o cadastro e

autenticação de Cliente e

Vendedor

Diogo 5 Sim


produto

Diogo 5 Sim


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



Número das User Stories desenvolvidas: 4,5,6,7,8.


Descrição: Criação da lógica para Cadastro de anúncios, Criação das consultas de anúncio e

verificação de rotas.


de horas

Concluíd

a


a tela de Cadastro de Anúncio

Diogo 10 Sim

64


EJB para o cadastro de

anúncios

Diogo 5 Sim


anúncio

Diogo 15 Sim


visualização de anúncios

cadastrados

Diogo 10 Sim


de anúncios cadastrados.

Diogo 10 Sim

1.6 Criar consulta de anúncio de

forma isolada.

Diogo 1 Sim


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


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


de anúncios

Diogo 20 Sim

1.13 Criar visualização de rotas Diogo 25 Sim


Plano de Iteração

Release 3

Iteração 1



Número das User Stories desenvolvidas: 9,10.


Descrição: Criação da lógica para comentários em anúncio e de favoritar anúncios.

65


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


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


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



Número das User Stories desenvolvidas: 11,12.


Descrição: Criação da lógica para qualificação de vendedor.


de horas

Concluíd

a


qualificação de vendedor

Diogo 5 Sim


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


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:

E-mail

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


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


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.


Tempo ideal 25h

Tempo consumido 30h

Quadro 6 - User Story 3 - Cadastrar Produtos

User Story 4 – Cadastrar Anúncio


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


Tempo ideal 90h

Tempo consumido 200h

Quadro 9 - User Story 6 - Consultar Anúncios em Conjunto

User Story 7 – Visualização de anúncios


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


Tempo ideal 20h

Tempo consumido 20h

Quadro 10 - User Story 7 – Visualização de anúncios

User Story 8 – Verificar rota


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.


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.


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.


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

loocaliza - sistema de compras geográfico

Documents