UNIVERSIDADE ANHEMBI MORUMBI
ANDRESSA PEREIRA DE OLIVEIRA
BRUNO NORONHA FRAGOMENI
MILDREDH HARUE NOGUEIRA
NAIME IOSIMUTA
VICTOR HIGINO VASCONCELLOS
SMARTCOMPRAS: DESENVOLVIMENTO DE UM APLICATIVO PARA
CELULARES SMARTPHONE.
São Paulo
2011
ANDRESSA PEREIRA DE OLIVEIRA
BRUNO NORONHA FRAGOMENI
MILDREDH HARUE NOGUEIRA
NAIME IOSIMUTA
VICTOR HIGINO VASCONCELLOS
SMARTCOMPRAS: DESENVOLVIMENTO DE UM APLICATIVO PARA
CELULARES SMARTPHONE.
Trabalho de Conclusão Curso apresentado como
exigência parcial para a obtenção do título de
Bacharel em Ciência da Computação da Universidade
Anhembi Morumbi.
Orientador: Dr. Augusto Mendes Gomes Júnior
São Paulo
2011
S644
Smartcompras: desenvolvimento de um aplicativo
para celulares smartphone / Andressa Pereira de
Oliveira [et. al.]. – 2011.
106f.: il.; 30 cm.
Orientador: Augusto Mendes Gomes Júnior.
Trabalho de Conclusão de Curso (Graduação em
Ciência da Computação) – Universidade Anhembi
Morumbi, São Paulo, 2011.
Bibliografia: f.67-71.
1. Ciência da Computação. 2. Código de Barras.
3. Mineração de Dados. 4. Processamento de Imagens.
5. Software – Vendas.
I. Título.
CDD 004
ANDRESSA PEREIRA DE OLIVEIRA
BRUNO NORONHA FRAGOMENI
MILDREDH HARUE NOGUEIRA
NAIME IOSIMUTA
VICTOR HIGINO VASCONCELLOS
SMARTCOMPRAS: DESENVOLVIMENTO DE UM APLICATIVO PARA CELULARES
SMARTPHONE.
Trabalho de Conclusão Curso apresentado como
exigência parcial para a obtenção do título de
Bacharel em Ciência da Computação da Universidade
Anhembi Morumbi, sob a orientação do Dr. Augusto
Mendes Gomes Júnior.
Aprovado em
___________
Nome do orientador/titulação/IES
___________
Nome do convidado/ titulação/IES
___________
Nome do convidado/IES
Dedicamos este trabalho aos nossos pais e
irmãos que nos ajudaram em todos os momentos
que precisamos.
AGRADECIMENTOS
Agradecemos à Deus pela vida, saúde e sabedoria nos fornecida.
Agradecemos ao nosso orientador, Dr. Augusto Mendes, pelo suporte
prestado e por todo o conhecimento compartilhado.
Agradecemos as nossas famílias e amigos pela paciência e, acima de tudo,
por estarem ao nosso lado quando precisamos.
Agradecemos à cada integrante do grupo que, entre muitos problemas,
souberam superar as diferenças e entregar o projeto com qualidade.
“O verdadeiro ato da descoberta não
consiste em descobrir novas terras, mas
em enxergá-las com outros olhos!”
Marcel Proust
RESUMO
Este trabalho apresenta como tema central o estudo do processamento de
imagens e da mineração de dados, e tem como objetivo desenvolver um software de
compras que utilize o Android como sistema operacional. Este software irá realizar a
captura e o processamento de uma imagem de código de barras, e aplicar conceitos
de mineração de dados, com o intuito de identificar os perfis dos clientes e oferecer
produtos eventualmente adquiridos que possuam um menor custo no instante da
compra. Compras realizadas pessoalmente em supermercados demandam tempo e
desgaste físico, uma vez que é necessário colocar e retirar o produto do carrinho
diversas vezes e ainda comparar preços de produtos adquiridos constantemente. Ao
mesmo tempo em que a tecnologia para celulares cresce consideravelmente,
disponibilizando maiores comodidades ao usuário. O objetivo deste trabalho é
integrar duas áreas importantes para o mercado (tecnologia e marketing),
oferecendo conforto e comodidade ao consumidor. O processamento de imagem
engloba a transformação da imagem em uma imagem digital, tratamento da cor,
melhoria e restauração, segmentação e representação, e por fim reconhecimento de
objetos e padrões. E o código de barras será a imagem principal neste trabalho. A
mineração de dados envolve análise, tratamento, modelagem, avaliação dos
resultados obtidos e por fim a implementação da mineração. Dentre os diversos
algoritmos utilizados na implementação da técnica de mineração de dados, Árvore
de Decisão, Redes Neurais e Apriori.
Palavras-Chaves: Mineração de dados, Processamento de Imagem, Código
de barras, Android.
ABSTRACT
This work has as its central theme the study of image processing and data
mining, and aims to develop shopping software that uses the Android operating
system. This software will perform the capture and processing of a barcode image,
and apply concepts of data mining, in order to identify customer profiles and offer
products that may have accrued that have a lower cost at time of purchase.
Purchases made in person at supermarkets demand time and physical stress, since
it is necessary to insert and remove the product from the cart several times and also
compare prices of products purchased constantly. At the same time the technology
for mobile phones grows considerably, providing more facilities to the user. The
objective is to integrate two important areas to the market (technology, marketing),
offering comfort and convenience to the final consumer. The image processing
includes transforming the image into a digital image, color treatment, improvement
and restoration, segmentation and representation, and finally recognizing objects and
patterns. And the bar code will be the main image in this work. Data mining involves
analysis, processing, modeling, evaluation of results and finally the implementation of
mining. Among the various algorithms used in implementing the data mining
technique, we studied decision tree, neural networks and Apriori.
Keywords: Data Mining, Digital Image Processing, Bar Code, Android.
LISTA DE SIGLAS E ABRREVIAÇÕES
API
Application Programming Interface
CRISP-DM Cross Industry Standard Process for Data Mining
CRM
Customer Relationship Management
EAN
European Article Numbering Association
EDGE
Enhanced Data-Rates for Global Evolution
GPS
Global Positioning System
GSM
Global System for Mobile
IDC
International Data Corporation
ISBN
International Standard Book Number
ISSN
International Standard Serial Number
KDD
Knowledge Discovery in Databases
PDA
Personal Digital Assistant
RGB
Red Green Blue
SOAP
Simple Object Access Protocol
SD
Secure Digital
UML
Unified Modeling Language
UPC
Universal Code Products
URL
Uniform Resource Locator
ILUSTRAÇÕES
Figura 1 - Etapas completas de processamento de imagem. ............................................... 20
Figura 2 – Etapas básicas de processamento de imagem ................................................... 21
Figura 3 – Cores RGB e escala de cinza a partir das cores RGB. ....................................... 22
Figura 4 - Exemplo de código de barras .............................................................................. 24
Figura 5 – Exemplo de código de barras UPC-A.................................................................. 26
Figura 6 – Exemplo de código de barras UPC–E ................................................................. 27
Figura 7 – Exemplo de código de barras EAN 13 ................................................................ 27
Figura 8 – Exemplo de código de barras EAN 8 .................................................................. 28
Figura 9 – Exemplo de código de barras do tipo ISBN ......................................................... 29
Figura 10 – Exemplo de código de barras do tipo ISSN. ...................................................... 29
Figura 11 – Antes e depois do processo de binarização de uma placa veicular ................... 32
Figura 12 - Antes e depois do processo de erosão de uma placa veicular. .......................... 32
Figura 13 - Antes e depois do processo de erosão de uma placa veicular ........................... 32
Figura 14 – Ciclo de vida do processo de mineração de dados ........................................... 35
Figura 15 – Fluxograma do processo KDD .......................................................................... 38
Figura 16 – Exemplo de árvore de decisão .......................................................................... 41
Figura 17 – Exemplo de redes neurais ................................................................................ 42
Figura 18 – Pseudocódigo do algoritmo Apriori.................................................................... 43
Figura 19 - Arquitetura do Sistema Android ......................................................................... 44
Figura 20 - Ciclo de vida de uma atividade .......................................................................... 46
Figura 21 - Diagrama Entidade-Relacionamento do software SmartCompras ..................... 50
Figura 22 - Diagrama de Caso de Uso do software SmartCompras ..................................... 52
Figura 23 - Diagrama de Classe do software SmartCompras .............................................. 54
Figura 24 – Arquitetura do sistema. ..................................................................................... 56
Figura 25 – Arquitetura da biblioteca ZXing ......................................................................... 59
Figura 26 – Informações inseridas no banco de dados através do aplicativo SmartCompras
............................................................................................................................................ 65
Figura 27 - Projeto do banco de dados do software SmartCompras .................................... 92
Figura 28 - Diagrama de Atividade - UC6 ............................................................................ 93
Figura 29 - Diagrama de Atividade – UC19.......................................................................... 94
Figura 30 - Diagrama de Atividade - UC22 .......................................................................... 95
Figura 31 - Diagrama de Atividade - UC26 .......................................................................... 96
Figura 32 - Diagrama de Atividade - UC31 .......................................................................... 97
Figura 33 - Diagrama de Seqüência- UC6 ........................................................................... 98
Figura 34 - Diagrama de Seqüência- UC19 ......................................................................... 99
Figura 35 - Diagrama de Seqüência- UC22 ....................................................................... 100
Figura 36 - Diagrama de Seqüência- UC26 ....................................................................... 101
Figura 37 - Diagrama de Seqüência- UC31 ....................................................................... 102
Figura 38 - Primeira tela de cadastro do SmartCompras ................................................... 104
Figura 39 - Segunda tela de cadastro do SmartCompras .................................................. 104
Figura 40 - Terceira e última tela de cadastro do SmartCompras ...................................... 105
Figura 41 - Tela de login do SmartCompras ...................................................................... 105
Figura 42 - Tela Principal do SmartCompras ..................................................................... 106
Figura 43 - Tela para digitar o código de barras................................................................. 106
Figura 44 - Tela de detalhe do produto .............................................................................. 106
Figura 45 - Tela do carrinho de compras ........................................................................... 107
Figura 46 - Tela para escolha da forma de pagamento ...................................................... 107
SUMÁRIO
1 INTRODUÇÃO ................................................................................................................. 16
1.1 OBJETIVO ..................................................................................................................... 16
1.2 JUSTIFICATIVA ............................................................................................................. 17
1.3 ABRANGÊNCIA ............................................................................................................. 17
1.4 ESTRUTURA DO TRABALHO....................................................................................... 18
2 PROCESSAMENTO DE IMAGEM ................................................................................... 19
2.1 DEFINIÇÃO ................................................................................................................... 19
2.1 CAPTURA DE IMAGEM E PROCESSAMENTO DA COR ............................................. 21
2.2 MELHORIA E RESTAURAÇÃO DA IMAGEM ................................................................ 22
2.3 SEGMENTAÇÃO E REPRESENTAÇÃO ....................................................................... 23
2.4 RECONHECIMENTO DO OBJETO E DE PADRÕES .................................................... 24
2.5 CÓDIGO DE BARRAS ................................................................................................... 24
2.5.1 Conceitos .................................................................................................................... 25
2.5.2 Padrões ...................................................................................................................... 26
2.5.3 Leitura de Código de Barras ....................................................................................... 29
2.6 APLICAÇÕES ................................................................................................................ 31
2.6.1 Reconhecimento de placa veicular.............................................................................. 31
3 MINERAÇÃO DE DADOS ................................................................................................ 33
3.1 FASES DA MINERAÇÃO DE DADOS ........................................................................... 33
3.2 ANÁLISE DESCRITIVA E ANÁLISE DE PROGNÓSTICOS .......................................... 36
3.3 BUSCA DE CONHECIMENTO ...................................................................................... 37
3.4 TÉCNICAS DE MINERAÇÃO DE DADOS ..................................................................... 38
3.5 TIPOS DE ALGORITMOS ............................................................................................. 40
3.5.1 Árvores de decisão ..................................................................................................... 40
3.5.2 Redes Neurais ............................................................................................................ 41
3.5.3 Apriori ......................................................................................................................... 42
4 ANDROID ......................................................................................................................... 44
5 MODELAGEM DO SISTEMA SMARTCOMPRAS............................................................ 47
5.1 LEVANTAMENTO DE REQUISITOS ............................................................................. 47
5.1.1 Requisitos Funcionais ................................................................................................. 47
5.1.2 Requisitos Não-Funcionais ......................................................................................... 48
5.2 MODELAGEM DO BANCO DE DADOS ........................................................................ 48
5.3 DIAGRAMA DE CASO DE USO .................................................................................... 49
5.4 DIAGRAMA DE CLASSE ............................................................................................... 53
6 DESENVOLVIMENTO DO SMARTCOMPRAS ................................................................ 55
6.1 ARQUITETURA DA SOLUÇÃO ..................................................................................... 55
6.2 CAPTURA E PROCESSAMENTO DO CÓDIGO DE BARRAS ...................................... 56
6.2.1 Captura do código de barras ....................................................................................... 57
6.2.2 Processamento do código de barras ........................................................................... 57
6.3 MINERAÇÃO DE DADOS .............................................................................................. 59
7 TESTES............................................................................................................................ 62
7.1 CONFIGURAÇÃO DE REDE ......................................................................................... 62
7.2 CAPTURA E PROCESSAMENTO DE IMAGEM ............................................................ 62
7.3 WEBSERVICE ............................................................................................................... 63
7.4 APRIORI ........................................................................................................................ 64
7.5 SISTEMA DE COMPRA................................................................................................. 64
8 CONCLUSÃO................................................................................................................... 66
8.1 TRABALHOS FUTUROS ............................................................................................... 67
APÊNDICE .......................................................................................................................... 73
A REQUISITOS FUNCIONAIS: ........................................................................................... 73
B DESCRIÇÃO FORMAL DOS CASOS DE USO ................................................................ 75
C PROJETO DO BANCO DE DADOS ................................................................................. 92
D DIAGRAMAS DE ATIVIDADES ........................................................................................ 93
E DIAGRAMA DE SEQUÊNCIA .......................................................................................... 98
F REQUISITOS DO CELULAR UTILIZADO NO TESTE: ................................................... 103
G TELAS DO SISTEMA ..................................................................................................... 104
16
1 INTRODUÇÃO
Há 10 anos, eram poucas pessoas que utilizavam celulares. Já nos dias de
hoje, esse recurso ganhou uma importância considerável. Segundo a IDC
(International Data Corporation - 2011) o mercado de smartphone cresceu 79,7% no
primeiro trimestre de 2011. Além do layout, as funcionalidades e aplicações que o
celular possui, são requisitos muito avaliados no momento da compra.
Pensando nisso, os desenvolvedores de softwares para smartphone seguem
trabalhando com a idéia de tornar este equipamento essencial e necessário no dia a
dia, sendo capaz de dispensar outros aparelhos de diversas funcionalidades.
Atualmente os smartphones realizam tarefas de outros equipamentos, como por
exemplo, os despertadores, o GPS(Global Positioning System), aparelhos de
reprodução de música e vídeo, etc. Ainda assim, existem ramos pouco explorados,
como por exemplo, o doméstico.
Além da tecnologia, a área de compras também vem recebendo grande
investimento. Seja de maneira virtual ou local, as lojas vem cada dia mais buscando
inovações tecnológicas a fim de serem mais competitivas no mercado. Devido à
concorrência acirrada, nem sempre é possível oferecer o melhor preço de
determinados produtos, e gerar conforto e comodidade ao cliente pode ser um
grande diferencial.
Este trabalho desenvolve um software para auxiliar seus usuários no
momento de realizar uma compra em supermercado, com o intuito de possibilitar
conforto e economia de tempo ao usuário.
1.1 OBJETIVO
O objetivo deste trabalho é a modelagem e o desenvolvimento de um
software para smartphone que permita realizar compras em um supermercado.
Para
alcançar
este
objetivo
alguns
conceitos
são
estudados
e/ou
implementados como: a leitura e interpretação de código de barras, a conexão do
software com o banco de dados do supermercado para a verificação de
disponibilidade dos produtos desejados e a utilização dos conceitos de mineração de
dados, para traçar o perfil do usuário de acordo com as compras realizadas.
17
1.2 JUSTIFICATIVA
Atualmente, as maneiras mais comuns de se realizar uma compra são: à
distância, através de um site ou por telefone, fisicamente, se deslocando ao
mercado.
Porém, analisando as alternativas, a segunda mostra-se desgastante ao
usuário, uma vez que ele precisa adicionar os produtos ao carrinho, retirá-los para
passar ao caixa, recolocá-los no carrinho e por fim coloca-los em seu carro,
enquanto a primeira alternativa, por mais cômoda que seja, não permite que o
cliente “toque” ou veja em tamanho real o produto desejado, não podendo avaliar
informações que possuam na embalagem do mesmo.
Segundo a Associação Brasileira de Automação Comercial (2011), existem
empresas que estudam uma 3ª alternativa de compra, onde no carrinho de compras
que o cliente está utilizando possui um PDA (Personal Digital Assistant - computador
de bordo) que possuiria um mapa do mercado capaz de localizar todos os produtos
do mercado e, além disso, no próprio carrinho o cliente pode scannear o código de
barras e já empacotar os produtos. O Grupo Pão-de-Açúcar, juntamente com outras
treze grandes redes de supermercado e empresas de tecnologia, trabalha em uma
loja conceito no Shopping Iguatemi localizado na cidade de São Paulo.
A possibilidade de integração de diferentes tecnologias, todas em uso e
crescendo no mercado, proporciona a criação de um sistema que simplifique a rotina
de compras realizadas, economizando tempo, uma vez que não será necessário
colocar compras no carrinho, pegar filas, empacotar, etc, que possibilite oferecer aos
clientes a funcionalidade de comparação de preço de produtos de mesma
subcategoria e ainda promoções ou sugestões de produtos de acordo com as
compras já realizadas, durante a realização de uma nova compra.
1.3 ABRANGÊNCIA
Para
a
elaboração
deste
trabalho
foi
realizado
um
estudo
sobre
processamento de imagens, uma vez que é realizada a leitura de código de barras
via celular, de forma a possibilitar o tratamento de imagens de códigos de barras.
Também foi realizado um estudo sobre mineração de dados, em que é
18
traçado o perfil do cliente baseado em suas preferências, de acordo com suas
compras.
O banco de dados foi criado baseado no diagrama entidade-relacionamento.
Através de uma rede é possível conectar-se com o banco do supermercado
com o intuito de manipular e consultar dados desse banco.
O trabalho não abrange cobrança de valores, apenas disponibiliza as formas
de pagamento de acordo com os critérios do supermercado e abrange somente o
desenvolvimento para celulares com tecnologia smartphone que possuam o Android
versão 2.2 como Sistema Operacional.
1.4 ESTRUTURA DO TRABALHO
Os capítulos 2, 3 e 4 consistem na revisão bibliográfica, onde o capítulo 2
aborda o conceito de processamento de imagens, além de sua utilização, o capítulo
3 aborda o conceito de mineração de dados e técnicas para executá-la e o 4 nos
conceitos de código de barras.
A partir do capítulo 5 o sistema SmartCompras começa a ser moldado. No
capítulo 5 é realizada a modelagem do SmartCompras, e o 6 mostra como foi o
sistema foi implementado.
O capítulo 7 explica o ambiente utilizado para os testes, apresenta os
resultados obtidos e por fim, o capítulo 8 finaliza o projeto com as conclusões da
monografia e propõe sugestões de temas para trabalhos futuros.
19
2 PROCESSAMENTO DE IMAGEM
O processamento de imagem é um conjunto de operações realizadas em uma
imagem, que tem como objetivo melhorar a sua qualidade para que a interpretação
dos dados e o reconhecimento dos objetos contidos nela sejam feitos de forma mais
precisa (GONZALEZ; WOODS, 2008).
Neste capítulo são abordados os principais conceitos e as diversas técnicas
de processamento de imagem, com o intuito de alcançar o melhor resultado para o
seu processamento.
2.1 DEFINIÇÃO
A definição de imagem segundo o dicionário Michaellis é “Coleção de bits
representando os pixels que caracterizam uma imagem na tela ou em uma
impressora”. Gonzalez e Woods (2008) definem a imagem de maneira semelhante.
A imagem é uma função bidimensional, em que a amplitude de uma determinada
coordenada mostra a intensidade ou o nível de cinza naquele ponto da imagem, e é
definida como uma imagem digital quando a mesma possuir um número finito de
pixels.
O processamento de imagem utiliza diversas técnicas para melhorar as
informações visuais, o que tem ajudado na resolução de problemas, que mesmo
sem relacionamento entre eles (problemas distintos), necessitam de melhorias
visuais nas informações para análise e interpretação humana.
No mundo tecnológico, a extração das informações contidas na imagem
segue um procedimento base, em que são feitas operações com intuito de analisar
objetos contidos na imagem, gerando assim, modelos matemáticos.
Para realizar o processamento de uma imagem, é necessário convertê-la para
uma imagem digital (representada por funções bidimensionais ou mais dimensões,
em caso de coloridas e multiespectrais). Após essa conversão existem outras etapas
para o processamento de imagem digital (figura 1), porém nem todos os algoritmos
passam por todas as etapas. Desta forma, o processamento da imagem é dividido
em 4 grupos, conforme ilustra a figura 2.
Na figura 1 são exibidas etapas para o processamento da imagem, etapas
essas que consistem nas captura da imagem (image acquisition), no aprimoramento
20
(image enhancement), na restauração (image restoration), no processamento da cor
(color image processing), no processamento de ondas e multi-resolução (wavelets
and multiresolution processing), na compressão (compression), no processamento
morfológico (morphological processing), na segmentação (segmentation), na
representação
e
descrição
(representation
&
description)
e
por
fim
no
reconhecimento do objeto (object recongnition). As informações utilizadas em cada
uma dessas etapas são encontradas ou trocadas na base de conhecimento
(knowledge base).
Figura 1 - Etapas completas de processamento de imagem. Fonte: GONZALEZ e WOODS
(2008)
Para todos os passos de processamento de imagem é necessário a
implementação de softwares, havendo necessidade de utilizar hardwares somente
para captura e exibição das imagens, devido à velocidade de atuação. Os próximos
tópicos detalham as etapas básicas para o processamento das imagens, sendo elas:
- Captura da imagem e processamento da cor;
- Melhoria e restauração da imagem;
- Segmentação e representação;
- Reconhecimento de objetos padrões.
21
Figura 2 – Etapas básicas de processamento de imagem. Fonte: O AUTOR (2011)
2.1 CAPTURA DE IMAGEM E PROCESSAMENTO DA COR
Existem várias maneiras diferentes para capturar uma imagem, como por
exemplo, câmeras de vídeos, scanners ou sensores dedicados (infravermelho, raiox, etc) (MUENZ, 2008) .
Assumindo que a entrada seja feita através de uma câmera (que atualmente
já possui um nível de sensibilidade muito alta), é necessário fazer uma conversão de
sinal analógico para digital, em que a imagem digital é discretizada espacialmente
(em coordenadas x e y) e em luminância (que são os níveis de cinza). As
intensidades são indexadas em uma tabela de conversão chamada “Look-Up Table”
(ROSA, 2008).
Durante a conversão (para digital) é importante saber que essa digitalização
precisa ser feita nos dois componentes da imagem: espacial e amplitude. Um
processo conhecido como Amostragem (GONZALEZ; WOODS, 2008) define o
componente espacial, nesse processo a imagem é representada em sua forma mais
simples (função contínua e infinita), que se transforma em uma matriz finita de pixels
(ou elementos picturais) com tamanhos iguais. Já o processo de amplitude
(denominado quantização), a partir de uma função contínua de amplitude, define o
nível discreto de cinza permitido para cada pixel, fazendo atribuições funcionais de
valores de níveis de cinza para cada par de coordenadas distintas da função,
transformando essa imagem em uma função bidimensional (2-D).
A qualidade da imagem original com aproximação pela matriz depende da
quantidade de amostras e níveis de cinza que foram utilizados no processo, quanto
maiores esses números, melhor a qualidade. Caso haja necessidade de manter
pequenos os números de níveis de cinza, pode-se utilizar a técnica de espaçamento
22
irregular (BERTHOUD, 2004), distribuindo esses níveis em espaços que variam de
estreitos a muito grandes. Há ainda a possibilidade de existir grandes níveis de cinza
em uma escala, e pequenos em outras. Nesse caso, o procedimento ideal é espaçar
de maneira suave onde há maiores níveis e, sem suavidade nos menores.
No modelo de cor RGB (Red, Green e Blue), um dos mais simples e
freqüentemente utilizado, todas as cores são representadas a partir da mistura das
três cores primárias, porém, nem todas as cores possíveis pelo sistema RGB são
identificadas pelos olhos humanos, sendo que geralmente essas cores são utilizadas
apenas em computadores. A conversão em escala de cinza nesse modelo parte do
princípio de que todos os bytes de cada pixel precisam ter o mesmo valor. Portanto,
para realizar essa conversão é necessário percorrer toda a imagem pixel a pixel,
alterando seus respectivos valores para que todos fiquem com seus valores iguais.
Uma opção para realizar essa conversão, é obter o valor RGB atual, calcular sua
média aritmética e repassar o valor obtido ao R, ao G e ao B do pixel atual,
realizando esse processo nos demais pixels. A figura 3 mostra uma imagem em
RGB e em escala de cinza.
Figura 3 – Cores RGB e escala de cinza a partir das cores RGB. Fonte: O AUTOR (2011)
2.2 MELHORIA E RESTAURAÇÃO DA IMAGEM
Após a captura/conversão da imagem são necessárias algumas correções
para que, posteriormente, o algoritmo possa interpretá-la de forma mais eficaz.
Estas correções podem ser feitas através de filtros e são denominadas melhoria da
imagem. Porém, esta melhoria é muito subjetiva, cabendo ao observador dizer se o
resultado está satisfatório, tendo então a restauração da imagem. Este passo é
fundamentado principalmente em funções e métodos matemáticos (estatística).
Para este passo, existem várias técnicas (GONZALEZ; WOODS, 2008), como
23
por exemplo:
• A filtragem inversa em que uma estimativa da imagem restaurada é encontrada
pela divisão da imagem degradada e da estimativa da função de degradação;
• A filtragem de Wiener minimiza a diferença entre a imagem inicial e a restaurada,
considerando também os ruídos, ou seja, é como a filtragem inversa que também
trata ruídos;
• A transformação geométrica em que os pixels são alterados espacialmente para
distorcer as imagens e etc.
2.3 SEGMENTAÇÃO E REPRESENTAÇÃO
A segmentação é a primeira fase do processamento, se considerar a
informação que é necessária extrair da imagem, e por mais fácil que pareça para um
ser humano, é talvez a fase mais complexa para o computador.
Nesta fase são identificados os objetos (dividindo a imagem de acordo com o
agrupamento de pixels), possibilitando definir regiões de interesse para análise, e
para isso é importante saber o tipo de imagem que será segmentada e ter em mente
o nível de detalhe, pois sem essas informações o processo se torna mais complexo,
uma vez que não existe uma técnica específica para isso e sim técnicas que
dependem de uma série de fatores (ALBURQUERQUE, 2000). Há os seguintes
exemplos de implementação:
• Detecção
de
descontinuidade:
tenta
identificar
as
bordas
da
imagem,
normalmente aplica a técnica gradiente, na qual intensifica as tonalidades tentando
aproximar-se ao máximo de uma imagem binária;
• Técnicas de limiar: parte do pressuposto que pixels com as mesmas
características pertencem à mesma região;
• Métodos baseados em regiões: partindo de um pixel (chamado semente), ele é
comparado com seus vizinhos, agrupando-os por região.
Analisando o código de barras da figura 4, pode-se concluir que ele pode ser
segmentado em duas regiões: o fundo da imagem (parte branca) e o das listras
(parte preta).
24
Figura 4 - Exemplo de código de barras. Fonte: ERDEI (1994)
Após o resultado da segmentação é realizado a parametrização, em que se
identifica e cria os parâmetros e depois faz a representação, ou seja, o resultado da
segmentação é agrupado, podendo gerar uma nova representação (dependendo da
necessidade).
2.4 RECONHECIMENTO DO OBJETO E DE PADRÕES
Os últimos passos para o processamento da imagem são: fazer o
reconhecimento do objeto e do padrão, ou seja, interpretar a informação contida na
imagem de acordo com uma base de dados anteriormente definida, lhe fornecer
uma identificação e extrair um padrão entre elas.
Depois de a imagem estar segmentada e devidamente pré-classificada entre
o que é fundo e o que é objeto, deve-se aplicar um algoritmo que seja capaz de
reconhecer todas as características do objeto (área, perímetro, posição na imagem,
número de furos e etc.).
Existem diversos métodos para reconhecimento de padrão, como por
exemplo, utilização de redes neurais, abordagem sintática, abordagem estatística,
cabendo na hora de aplicá-la, saber escolher a mais eficaz (CONCI, MONTEIRO,
2004).
2.5 CÓDIGO DE BARRAS
“O código de barras é um símbolo composto de barras paralelas de larguras e
espaçamentos variados” (GROSSMANN, ZYNGIER, 1991) que armazenam
informações (ERDEI, 1994).
O código de barras surgiu devido à necessidade de identificação dos produtos
de
maneira
automatizada,
ou
seja,
a
quantidade
de
produtos
crescia
25
exponencialmente e os mercados/indústrias precisavam de um número único de
identificação para cada um deles.
Inicialmente existiam duas possibilidades, o código magnético e o código de
barras. Embora o código magnético fosse praticamente imune a cópias, era muito
caro de se implementar devido a materiais especiais e necessitava um contato físico
entre a máquina e o produto, diferentemente do código de barras (mais utilizado)
que é mais simples, com menor custo em sua fabricação e fácil de realizar sua
leitura (GROSSMANN, ZYNGIER, 1991).
O primeiro país a utilizar o código de barras foi os Estados Unidos da America
e utilizava o padrão UPC (Universal Code Products - mais detalhes na seção 2.5.2).
Segundo o site Linha Base (2010), existem dois tipos de código de barras, os
numéricos e os alfanuméricos, sendo que as características de um código de barras
podem aparecer em diversos padrões.
2.5.1 Conceitos
Para analisar um código de barras, alguns conceitos são fundamentais. Suas
definições são:
a. Barras: é responsável por absorver a luz do scanner. Geralmente possui a cor
preta e seu tamanho varia de um a vários módulos;
b. Caractere Inicial: é o caractere que indica o inicio do código;
c. Caractere Final: é o caractere que indica o fim do código;
d. Dígito: cada um dos caracteres representados por barras e espaços, podendo ser,
numéricos ou alfanuméricos;
e. Espaço: é responsável por refletir a luz do scanner, geralmente possui a cor da
embalagem e seu tamanho varia de um a vários módulos;
f. Fator de Magnitude (FM): é responsável por aumentar (em até 200%) ou diminuir
(em até 80%) o código de barras, a partir da dimensão inicial do código;
g. Módulos: é o elemento mais estreito do código de barras, independentemente de
ser um espaço ou uma barra, onde todos os outros caracteres têm tamanho múltiplo
ao modulo, como por exemplo, a zona muda e outros elementos do código de barra;
h. Separadores: caractere auxiliar que permite a identificação das extremidades do
código, bem como do sentido da leitura, permite também separar as zonas do
código de barras e são formados por barras e espaços;
26
i. Sinais de enquadramento: são as marcas que delimitam a área do código de
barra;
j. Zonas Mudas: são espaços antes do caractere inicial e após o caractere final,
com tamanho de, no mínimo, 10 módulos (caso seja menor, o scanner não o
consegue ler) que possibilitam a leitura do código juntamente com o padrão
escolhido.
2.5.2 Padrões
Existem diversos padrões de código de barras, mas são abordados abaixo
somente os principais existentes, com maior ênfase no EAN 13 (European Article
Number). Os padrões são:
a) UPC (Universal Product Code) – Criado pelos Estados Unidos e possui
duas versões (ERDEI, 1994), sendo que a UPC-A possui doze (12) caracteres
numéricos que são representados por 2 espaços e 2 barras. A figura 5 ilustra um
exemplo de código de barras no padrão UPC-A.
Figura 5 – Exemplo de código de barras UPC-A. Fonte: ERDEI (1994)
Analisando a figura 5, os números do código de barra UPC-A são
subdivididos em 4 grandes grupos, sendo eles:
A – Categoria do produto;
B – Identificação do fabricante do produto;
C – Identificação do produto;
D – Digito de verificação.
E a versão UPC – E (figura 6) é um código reduzido que consiste em retirar,
seguindo 1 dos 4 modelos, os números 0 (zero) considerando 2 (dois) atributos –
número do fabricante e número do produto.
1º modelo: Caso, no código UPC-A, o número do fabricante termine em 000,
100 ou 200, o UPC-E terá os 2 primeiros números do fabricantes, os 3 últimos
27
números do produto, seguido pelo terceiro número do fabricante.
2º modelo: Caso, no código UPC-A, o número do fabricante termine em 00,
precedido de um número entre 3 e 9, o UPC-E terá os 3 primeiros números do
fabricantes, os 2 últimos números do produto, seguido do número 3.
3º modelo: Caso, no código UPC-A, o número do fabricante termine em 0 e
não atende nenhum dos requisitos dos 2 modelos apresentados anteriormente, o
UPC-E terá os 4 primeiros números do fabricantes, o último número do produto,
seguido do número 4.
4º modelo: Caso, no código UPC-A, o número do fabricante não termine em 0,
o UPC-E terá todos os números do fabricantes e o último número do produto,
seguido do número 4.
Figura 6 – Exemplo de código de barras UPC–E. Fonte: ERDEI (1994)
b) EAN (European Article Numbering Association) - Criado para utilização
no mercado europeu é também muito utilizado no Brasil (GROSSMANN, ZYNGIER,
1991). Assim como o UPC, possui duas versões, sendo elas a EAN 13 utilizada no
mundo inteiro (exceto pelos Estados Unidos e Canadá), possui 13 dígitos e 30
barras e 29 espaços que codificam a informação (ERDEI, 1994), conforme ilustrado
pela figura 7.
Figura 7 – Exemplo de código de barras EAN 13. Fonte: ERDEI (1994)
28
Analisando a figura 7, os números do código de barra EAN 13 são
subdivididos em 4 grandes grupos (GROSSMANN, ZYNGIER, 1991), sendo eles:
-Número do país: os três primeiros dígitos – (BRASIL = 789);
-Identificação do fabricante do produto: este número pode variar de 4 a 5
dígitos, dependendo da quantidade de produtos que a empresa possui;
-Identificação do produto: assim como a quantidade de dígitos do fabricante, a
identificação do produto também varia de 4 a 5 dígitos;
-Dígito de verificação: o último dígito que consiste em conferir se o leitor
efetuou uma leitura corretamente.
A seguir está o passo a passo de como criar o dígito verificador ou conferir se
a leitura foi feita corretamente (GROSSMANN, ZYNGIER, 1991):
Passo 1 - Enumerar de 1 a 13 os dígitos do código de barras (iniciando do
código verificador terminando no primeiro dígito do país).
Passo 2 – Somar todos os valores dos dígitos ímpares a partir do terceiro
dígito.
Passo 3 – Somar todos os valores dos dígitos pares e multiplicar por 3.
Passo 4 – Somar o resultado do passo 2 e do passo 3.
Passo 5 - O dígito verificador será o menor número encontrado que,
somado ao resultado do passo 4, se iguala a um número múltiplo de 10.
E a versão EAN 8: Possui 8 dígitos e é utilizado somente em embalagens
pequenas, ele é a forma reduzida do código EAN 13, conforme representado pela
figura 8.
Figura 8 – Exemplo de código de barras EAN 8. Fonte: ERDEI (1994)
c) Codificação internacional de livros e revistas – Ainda existem outros 2
tipos de códigos de barras que são os de Livros (ISBN – International Standard Book
Number) e o de revistas (ISSN – International Standard Serial Number ), que devido
a um acordo da ISBN e da ISSN eles utilizam o código EAN, porém a estrutura do
código é diferente.
No ISBN, o código de barras, ilustrado na figura 9, é constituído por (ERDEI,
29
1994):
- Identificação ISBN (978 ou 979);
- Número ISBN do livro;
- Caractere de verificação.
Figura 9 – Exemplo de código de barras do tipo ISBN. Fonte: GROSSMANN, ZYNGIER
(1991)
Já no ISSN o código de barras, ilustrado na figura 10, é constituído por:
- Identificação ISSN (977);
- Número ISSN da publicação;
- Dígito extra;
- Caractere de verificação.
Figura 10 – Exemplo de código de barras do tipo ISSN. Fonte: REVISTA INFO (2010).
2.5.3 Leitura de Código de Barras
Técnicas complexas para decodificar códigos de barras só eram utilizadas em
computadores. Contudo, graças ao avanço tecnológico, atualmente é possível
realizar essa decodificação em aparelhos móveis, desde que possuam qualidade no
processamento câmera (é necessário uma imagem de boa qualidade) e grande
espaço em memória, igualando-se a um computador.
A captura de código de barras pode ser feita por um feixe de laser, ou por
algoritmos de reconhecimento de imagens que são capturados através da câmera
de um celular, desde que haja garantia de que não haverá interferência (problemas
como sombras, falta de foco, imagens com excesso ou falta de iluminação, etc) na
imagem.
Independentemente da maneira que se captura a imagem do código de
30
barras, o seu processamento é similar, portanto, somente está explicado o
processamento da imagem no item “Captura pela câmera do celular”.
a) Captura pela câmera do celular
O ideal para capturar um código de barras através de uma câmera de celular
é utilizar códigos de barras impressos em uma área ampla e com pequena
densidade de informações impressa. Em códigos com alta densidade de informação,
cada uma das informações é armazenada em pequenos detalhes da imagem,
tornando a captura mais complexa. O ideal que se tenha uma câmera de alta
resolução e códigos de barras visivelmente grandes com pouca densidade de
informação.
Devido à grande probabilidade de ruídos nas imagens capturadas por uma
câmera de um celular, é necessário aplicar técnicas de processamento digitais antes
de se obter o código de barras. Dessa forma, a imagem é convertida em escala de
cinza, seguindo o conceito de conversão de imagens em RGB. Além disso, é
provável que o código de barras não esteja devidamente alinhado, por isso é
necessário também detectar as bordas (caracterizadas por tons de cinza). O código
resulta em grandes quantidades de pixels de bordas, indicando as direções
perpendiculares à direção que deve ser percorrida para a leitura do código de
barras. Assim, tornam-se simples identificar a direção da imagem.
Uma vez que se obtiveram as direções da imagem é possível construir um
histograma (maneira comum de se representar níveis de cinza) de direções, com o
intuito de localizar a borda comum da imagem que corresponde as direções das
barras do código. Para identificar as larguras das barras, é utilizada a direção obtida
no histograma e uma constante, fazendo com que a imagem seja percorrida em
linha reta, o que, finalmente, possibilita a leitura do código de barras e depois é feita
a conta do código verificador para verificar se o código lido é o correto.
b) Captura pelo scanner
Existem inúmeros tipos de scanners diferentes e cada um possui um
mecanismo próprio para fazer a captura do código de barras.
Scanner é um instrumento capaz de emitir e receber um feixe de luz
31
vermelho. Ao iluminar (ou percorrer) toda a largura do código de barras e receber o
feixe refletido, o decodificador é responsável por converter para um sinal elétrico
digital, processá-lo, verificando se realmente o código de barras foi lido
corretamente, e por fim transmiti-lo a um computador central. Dependendo do
modelo do scanner, o decodificador pode ficar dentro do scanner ou em um circuito
externo ao scanner (ERDEI, 1994).
2.6 APLICAÇÕES
Existem inúmeras aplicações para o processamento de imagem digital. As
principais áreas são:
a. Reconhecimento de placa veicular;
b. Reconhecimento de caracteres;
c.
Análise de cromossomos;
d. Mapeamento de terrenos e superfícies;
e. Detecção de faces e objetos;
f.
Sistemas de segurança;
g. Monitoramento da poluição;
h. Planejamento Urbano;
i.
Análise de clima e temperatura;
j.
Determinação do tipo
k.
Tomografia computadorizada;
l.
Ultrassonografia.
O reconhecimento de placa tem um objetivo muito similar ao reconhecimento
de código de barras, por isto, na seção 2.6.1 existe uma explicação mais detalhada
de como a placa veicular é processada. Já o reconhecimento facial, abordado na
seção 2.6.2, possui diversas técnicas e a escolha de qual aplicar depende do
objetivo de implementação.
2.6.1 Reconhecimento de placa veicular.
Inicialmente é feita a captura da placa veicular, sendo a segunda etapa o préprocessamento, onde é identificado a região da placa, e por fim a imagem resultante
do pré-processamento é classificada, podendo então identificar os caracteres
32
presentes na placa veicular. Para isso, os seguintes conceitos são utilizados
(CONCI, MONTEIRO, 2004):
-
Binarização (Limiarização): Consiste na transformação da placa
veicular de tons de cinza para pixels preto e branco (figura 11). Para alguns autores,
este processo consiste em retirar o plano de fundo da imagem.
Figura 11 – Antes e depois do processo de binarização de uma placa veicular. Fonte:
CONCI, MONTEIRO (2004)
-
Erosão: Consiste em reduzir de tamanho uma imagem, contanto que
não perca as características geométricas importantes (figura 12) , com o intuito de
facilitar o reconhecimento de um caractere que esteja “grudado” ou muito próximo a
outro. (Problema comumente encontrado no reconhecimento de caracteres de uma
placa veicular).
Figura 12 - Antes e depois do processo de erosão de uma placa veicular. Fonte: CONCI,
MONTEIRO (2004)
-
Segmentação dos caracteres: última fase do pré-processamento é a
segmentação de caractere, ou seja, separar as letras e os números (figura 13).
Figura 13 - Antes e depois do processo de erosão de uma placa veicular. Fonte: CONCI,
MONTEIRO (2004)
33
3 MINERAÇÃO DE DADOS
O grande avanço tecnológico tem gerado grande volume de dados, e
conseqüentemente criado a necessidade de novas técnicas e ferramentas capazes
de transformar grande número de dados em informações significativas e em
conhecimento.
Informações
que
possuem
importância
considerável
para
planejamento, gestão e tomada de decisões, não podem ser descobertas ou
identificadas apenas com recursos de gerenciamento do banco de dados comum.
Devido à necessidade de extração dessas informações surgiu à mineração de
dados, também conhecido como Data Mining (NAVEGA, 2002).
Na década de 80, empresas perceberam que não aproveitavam todas as
informações que tinham de seus clientes. Com isso, decidiram extrair essas
informações, com o intuito de definir perfis e padrões de clientes, tornando a
empresa mais competitiva. Inicialmente os dados só eram extraídos, os conceitos de
mineração de dados que existem atualmente foram desenvolvidos e amadurecidos
ao longo dos anos (AMO, 2004). Tal amadurecimento torna fundamental o processo
de mineração de dados em empresas que sabem aplicá-lo e que apliquem o
conceito de CRM (Customer Relationship Management), pois conseguem um auxilio
fundamental para tomada de decisões, aumentando a probabilidade de se obter
sucesso (BRAGA, 2005).
Mineração de dados é o nome dado ao processo de análise de objetos que
visa encontrar padrões escondidos nos dados compreensíveis para pessoas e
extrair informações sem conhecimento prévio de um banco de dados (AMORIM,
2006).
O processo de mineração de dados é uma etapa do processo KDD
(Knowledge Discovery in Databases – em português, Descoberta de Conhecimento
em Base de dados), que, segundo Addrians e Zantinge (1996), permite a extração
não trivial de conhecimento previamente desconhecido e potencialmente útil de um
banco de dados.
3.1 FASES DA MINERAÇÃO DE DADOS
Como dito anteriormente, a mineração de dados vai além de uma simples
extração de dados. Atualmente dados tratados adequadamente são de grande
34
importância em propagandas específicas para um determinado público alvo. Uma
vez traçado o perfil de clientes, torna-se mais fácil identificar em quais campanhas
(de propaganda) melhor se encaixa o que aumenta a possibilidade de venda dos
produtos desejados, uma vez que já se sabe a quem deve ser oferecido (NAVEGA,
2002).
A especificação do que se deseja encontrar nos dados, como por exemplo,
tipo de regularidade, categoria de padrões, ou até mesmo padrões que podem
surpreender, é conhecida como tarefas. Já a especificação de métodos que
garantem como descobrir padrões é conhecida como técnica de mineração de
dados (NAVEGA, 2002).
Existem diversas técnicas de mineração de dados, por isso, deve-se escolher
a melhor para o problema a ser resolvido. Particularmente, cada problema possui
uma determinada técnica, portanto, o sucesso de cada tarefa depende da intuição e
experiência do analista que implementará a mineração de dados.
A interpretação dos padrões descobertos, e a possibilidade de retorno aos
outros processos é determinada na etapa final da mineração de dados, no pósprocessamento. A partir do objetivo proposto, analisam-se as informações obtidas
na extração, identificando e apresentando as melhores (SFERRA, CORRÊA, 2001).
Para a garantia da obtenção dos conhecimentos relevantes, é importante
estabelecer metas bem definidas. A maioria desses métodos são baseados em
técnicas de aprendizado de máquina, reconhecimento de padrões e estatísticas.
Em 1996 três empresas especializadas no, até então imaturo, mercado de
mineração de dados, criaram um modelo de processos genérico (figura 14), tendo
como objetivo padronizar as etapas (ciclo de vida) do processo de mineração,
nomeando o projeto como CRISP-DM (Cross Industry Standard Process for Data
Mining) (SFERRA, CORRÊA, 2001).
O ciclo de vida é compreendido pelas seguintes etapas:
• Entendimento do Negócio (Business Understanding): Fase inicial que tem
como foco, juntamente com o negócio, levantar quais são os objetivos, bem como
requisitos do projeto. Uma vez entendido os objetivos, é definido o problema e
projetado um plano inicial.
• Seleção dos Dados (Data Understanding): A partir da coleção de dados,
inicia a primeira captura de dados, buscando com que o time de projeto tenha um
35
primeiro contato com o banco de dados, a fim de identificar possíveis problemas de
qualidade e detectar subconjuntos que se julgam interessantes para criar hipóteses.
Figura 14 – Ciclo de vida do processo de mineração de dados. Fonte: SFERRA,CORRÊA
(2001)
• Limpeza (ou Preparação) dos Dados (Data Preparation): Fase de
preparação dos dados, onde se tratam ruídos, dados estranhos ou inconsistentes,
através de limpeza, transformação, integração e/ou formatação dos dados da etapa
anterior. Ocasionalmente são desempenhadas diversas vezes e de maneira
aleatória. É responsável também por preparar os dados para a ferramenta de
modelagem.
• Modelagem dos Dados (Modeling): Fase que aplica técnicas de modelagem
sobre conjunto de dados anteriormente preparado, tendo seus parâmetros
calibrados, para obter valores otimizados. Pode-se aplicar diversas técnicas de
modelagem para o mesmo problema, sendo que algumas técnicas possuem
requerimentos específicos na forma de dados, podendo então voltar para a etapa
anterior.
• Avaliação dos Dados (Evaluation): Nesta fase é avaliado o modelo gerado
na fase de modelagem. Esta etapa visa garantir a qualidade do modelo e verificar se
as expectativas da organização serão alcançadas e se alguma questão importante
do negócio ainda não foi englobada. A decisão sobre a utilização dos resultados da
mineração é obtida no fim desta fase e seus resultados podem ser mostrados de
várias formas, desde que, possibilitem uma análise criteriosa, e a verificação da
36
necessidade de retorno a algum dos processos anteriores.
• Execução (Deployment): Fase que define a implementação do projeto de
mineração de dados. Podendo ser o analista que designará as ações que devem ser
tomadas, baseando-se na visão do modelo, ou aplicando o modelo a diferentes
conjuntos de dados. Existe, também, a possibilidade de o cliente poder realizar as
etapas de execução, contanto que ele tenha compreendido as medidas que deverão
ser tomadas para empregar os modelos criados.
Essa fase não é a final do projeto, uma vez que o conhecimento gerado
precisará de uma organização e deverá ser apresentado de maneira a dar a
visibilidade desejada pelo cliente.
3.2 ANÁLISE DESCRITIVA E ANÁLISE DE PROGNÓSTICOS
Análise descritiva é responsável por investigar os dados com o intuito de
descrever fatos relevantes que não são de conhecimento dos usuários, validando o
conhecimento encontrado. Segundo Cortes et al (2002) pode-se subdividi-la em dois
processos:
• Análise Prévia: visa percorrer uma base dados buscando identificar
anomalias ou resultados raros, que ameaçam influenciar os resultados da mineração
de dados.
• Descobrimento: responsável por examinar uma base de dados buscando
padrões até então não reconhecidos, ou seja, sem que exista uma idéia ou hipótese
previamente estabelecida.
A partir dos padrões encontrados na análise descritiva, a análise de
prognósticos investiga os dados com o intuito de obter resultados, prognosticando o
comportamento de um conjunto de dados. Pode ser dividida em três processos
distintos: Estimação, Predição e Classificação.
• Estimação: A partir de padrões já conhecidos é possível estimar valores.
• Predição: Baseado em diversos valores prediz um comportamento futuro.
• Classificação: A partir de características em comum, classifica os objetos em
classes previamente definidas (seção 3.4)
37
3.3 BUSCA DE CONHECIMENTO
Na abordagem de mineração de dados é descrito ao usuário como conduzir o
processo de mineração de dados. Na abordagem denominada busca de
conhecimento, o usuário tenta descobrir algo ainda desconhecido iniciando o
processo de exploração dos dados (figura 15).
O usuário pode ainda decidir se a abordagem do conhecimento será feita de
forma direta, ou indireta, ambas descritas a seguir:
• Direta: o usuário tem uma meta orientada, um valor prognosticado, uma
classe a ser atribuída aos registros, ou um determinado relacionamento a ser
explorado. Existe uma vaga idéia do que se busca, de acordo com os seguintes
passos:
- Identificar as fontes dos dados selecionados para a mineração;
- Selecionar os dados necessários;
- Preparar os dados para análise;
- Construir e trinar o modelo computacional;
- Avaliar o modelo computacional.
• Indireta: sua meta não é definida, as ferramentas acabam sendo mais livres
em sua aplicação sobre os dados, tendo como resultado esperado a descoberta de
alguma estrutura significante nos dados. Os seguintes passos são aplicados na
busca indireta:
- Identificar as fontes dos dados;
- Preparar os dados para análise;
- Construir e trinar o modelo computacional;
- Avaliar o modelo computacional;
- Aplicar o modelo computacional no novo conjunto de dados;
- Identificar potenciais objetivos para busca de conhecimentos direta;
- Gerar novas hipóteses para teste.
38
Figura 15 – Fluxograma do processo KDD. Fonte: CÔRTES et al (2002).
3.4 TÉCNICAS DE MINERAÇÃO DE DADOS
As técnicas de mineração de dados podem ser aplicadas em qualquer método
da mineração de dados e existem diferentes maneiras de implementá-las. As cinco
primeiras listadas a seguir tem um caráter mais genérico e uma visão mais global
(CARVALHO, 2001), porém também existem outras técnicas, sendo algumas citadas
neste trabalho.
• Classificação:
processo
utilizado
para
encontrar
um
conjunto
de
características em um objeto, que descrevem e distinguem classes ou conceitos,
podendo assim classificá-lo em classes previamente definidas. Existem dois
processos para esta classificação, o da discriminação, onde se classifica de acordo
com características especificas que todos possuam e o da caracterização, onde se
classifica por sumarização, ou seja, por valores próximos.
• Estimativa: determina um valor provável baseado em dados semelhantes ou
previamente extraído.
• Previsão: baseado em dados anteriores faz uma avaliação dos possíveis
novos valores (determinação do futuro).
• Análise de Agrupamento (Cluster): sempre que um objeto possuir
similaridade com outro, ambos são agrupados em um determinado agrupamento
(cluster). Uma vez criado este agrupamento (cluster) de objetos, é identificada uma
classe, gerando aglomerações que descrevem dados. A análise de agrupamento
(cluster) é uma técnica que tem como objetivo detectar a existência de diferentes
grupos, em um determinado conjunto de dados, e caso existam, determina quais são
esses grupos, não existindo, portanto, classes previamente definidas.
39
• Análise de Afinidade: técnica utilizada para descobrir elementos ou fatos que
normalmente ocorrem simultaneamente, proporcionando a extração de regras.
• Regras de associação: é representada pela expressão X → Y, onde X e Y
são conjuntos de itens, tal que X é o antecedente da regra e Y é o conseqüente.
Determina relações entre campos de um determinado banco de dados.
• Modelos e Relacionamentos entre Variáveis: utiliza técnicas estatísticas
como, por exemplo: regressão linear simples, múltiplas e modelos lineares por
transformação, para verificação de relacionamentos funcionais. Esta técnica faz a
associação de um item a uma ou diversas variáveis de predição de valores reais,
consideradas independentes e exploratórias.
• Modelo de dependência: existem dois níveis de modelo de dependência que
descrevem dependências significativas entre variáveis: o estruturado, que especifica
quais variáveis são localmente dependente, e o nível quantitativo, que utilizando
escalas numéricas é capaz de especificar o grau de dependência.
• Sumarização: esta técnica reduz o número de valores, a partir de
agregações. A sumarização é principalmente utilizada no pré-processamento dos
dados, quando são determinados valores inválidos por meio do cálculo de medidas
estatísticas, no caso de variáveis quantitativas e variáveis categóricas. Porém, a
sumarização também pode ser utilizada no momento de apresentar resultados, uma
vez que o intuito da mineração é, também, poder apresentar os resultados de
maneira fácil e prática. Freqüentemente utilizada em análises exploratórias de dados
com geração automatizada de relatórios, que são responsáveis pela descrição de
conjunto de dados.
• Análise de Outliers (exceções): técnica utilizada para identificar os objetos
que não seguem o padrão da maioria. Estes outliers (exceções) dependendo do
objetivo podem ser descartados como ruído, ou pode ser o foco de outro processo
(como contra fraudes).
• Análise de padrões seqüenciais: utilizada para, uma vez que os dados
estejam em seqüência, traçar a ordem cronológica dos acontecimentos. (Exemplo:
<{casa}, {móveis}, {...} {televisão}>, ou seja a pessoa inicialmente comprou a casa,
tempos depois, comprou móveis e por fim uma televisão).
• Análise de Séries Temporais: tem por objetivo modelar o estado do
processo, extraindo e registrando desvios e tendências no tempo. Quatro padrões
40
compõem as séries: variações cíclicas, tendência, variações irregulares e variações
sazonais. Ela determina características seqüenciais, como por exemplo, dados com
dependência no tempo.
3.5 TIPOS DE ALGORITMOS
Dentre os diversos tipos de algoritmos utilizados para aplicar distintas
técnicas de mineração de dados, pode-se destacar árvore de decisão (RUSSELL,
NORVIG, 2004), redes neurais (HAYKIN, 2001) e Apriori (AMO, 2004). As seções a
seguir detalham estes algoritmos.
3.5.1 Árvores de decisão
Este algoritmo representa o aprendizado de máquina, baseado na abordagem
de dividir-para-conquistar, sendo um algoritmo alternativo mais rápido de se
construir. O seu funcionamento é recursivo, dividindo os dados (nomeados como
ramo ou galho) com base nos valores dos campos de entrada (RUSSELL, NORVIG,
2004).
O ramo inicial, denominado raiz, é subdividido em conjuntos (ramos filhos),
com base em valores de um determinado campo de entrada. Os filhos também
podem ser divididos em sub-ramos, que podem ser divididos novamente, e assim
sucessivamente até não mais poderem ser divididos, denominando-os como galhos
terminais ou folhas, e se encontram no nível mais baixo da árvore (SFERRA,
CORRÊA, 2001).
Uma árvore de decisão é também um fluxograma (figura 16), onde cada nó
interno denota um teste em atributo e cada ramo representa o resultado do teste e
por fim a folha representa a distribuição do registro.
Na sua utilização recomenda-se treinar o método, usando diversas amostras
de dados, até descobrir as melhores regras para a segmentação do conjunto dos
dados.
Outro ponto a ser estudado é a poda de árvores, que produz árvores
menores, com precisão potencialmente melhor, não havendo garantia de que após a
poda a estrutura torne-se simples.
41
Figura 16 – Exemplo de árvore de decisão. Fonte: FONSECA (1994)
3.5.2 Redes Neurais
Este algoritmo se baseia em conceitos de organização e aprendizado do
cérebro humano, ou seja, tentar elevar o nível do algoritmo de maneira a superar o
cérebro humano (HAYKIN, 2001).
Como este algoritmo visa oferecer métodos práticos para funções de
aprendizado, compreendendo procedimentos computacionais que envolvem o
desenvolvimento de estruturas matemáticas, e sua representação é dada por
atributos contínuos, discretos ou por vetores.
As redes neurais consistem na interconexão de um número simples de
unidades de processamento (neurônios), e tem por objetivo realizar cálculos de
determinadas funções matemáticas (funções de ativação). As duas principais
estruturas são: o nó correspondente ao neurônio e o link que corresponde as
conexões entre os neurônios que são dispostos em uma ou mais camadas
interligadas
por
diversas
conexões,
que
estão
associadas
a
pesos
de
armazenamento de conhecimento (figura 17).
Como vantagem apresenta robustez ao lidar com erros no conjunto de
treinamento, o que possibilita alta tolerância aos dados com ruídos e, também, boa
escalabilidade. Porém, necessita da definição de um grande número de parâmetros
e de maior força computacional o que, diferente de regras, não é facilmente
compreensível para pessoas.
42
Figura 17 – Exemplo de redes neurais. Fonte: BARBOSA et al(2002)
3.5.3 Apriori
“O Apriori é um algoritmo que minera conjuntos de itens freqüentes para
regras de associação booleanas” (PINOTI, 2002).
Este algoritmo visa resolver o problema de Itemset freqüente, sendo que
Itemset é o conjunto de itens numa única transação e a porcentagem com que o
itemset aparece é denominado suporte (AMO, 2004).
Para executar as 3 fases principais do algoritmo (geração, poda de
candidatos e o cálculo do suporte) espera-se como entrada, o banco de dados e o
nível mínimo de suporte definido/esperado e como saída os itemset freqüentes
considerando as entradas (AMO, 2004). Em cada fase ocorre o seguinte:
• Geração de candidatos: nesta fase, o algoritmo percorre as informações
procurando candidatos para itemsets.
• Poda de candidatos: nesta fase, o algoritmo filtra as informações da fase
anterior, ou seja, um itemset que não apareceu no seu candidato anterior pode ser
descartado, uma vez que ele pode não ser freqüente.
• Cálculo de suporte: por fim, é calculada a freqüência com que o itemset
aparece, ou seja, varre-se o banco de dados uma única vez, verificando todas as
transições e conforme atenda o critério é adicionado 1 ao contador.
Paras as 2 primeiras fases (geração e poda de candidatos) não é necessário
a utilização de memória secundária, apenas a principal e portanto não existe a
necessidade de percorrer o banco de dados todo, exceto quando a lista de itemsets
é devidamente grande e não cabe na memória principal (AMO, 2004).
43
Fazendo uma análise do algoritmo da figura 18, a primeira etapa do algoritmo
de Apriori conta quantas vezes cada produto apareceu em compras diferentes. Uma
vez contabilizada a quantidade de cada item, o algoritmo armazena apenas os
números considerados “freqüentes” (escolhe-se um parâmetro) e todos os pares de
itens freqüentes possíveis são comparados, verificando se isso ocorre na mesma
compra. Esse passo é repetido até que não tenha mais nenhuma combinação.
Quando não existirem mais combinações, o algoritmo de Apriori seleciona a última
seqüência que teve combinação.
Figura 18 – Pseudocódigo do algoritmo Apriori. Fonte: PITONI (2002)
44
4 ANDROID
O Android é um sistema operacional, específico para dispositivos móveis,
baseado no kernel do Linux e desenvolvido pela Google, e hoje sendo gerenciado
pela Open Handset Alliance (JANTSCHER ET al, 2009).
Conforme ilustrado na figura 22, no nível mais baixo pode-se encontrar o
Linux, no qual a maioria do gerenciamento é realizado, seguido pelo nível de
bibliotecas nativas do Android, mesmo sendo escritas em C/C++, para executar um
aplicativo é necessária uma máquina virtual (Dalvik Virtual Machine) que chama as
interfaces Java.
O próximo nível é composto pelo framework de aplicações disponibilizadas
pelo Google, uma vez que as APIs (Application Programming Interface – Interface de
Programação de Aplicativos) já estão disponibilizadas. Neste nível, também, contém
o gerenciador de atividades, responsável pelos ciclos. Por fim, existe o nível da
aplicação em si, onde os desenvolvedores podem disponibilizar suas aplicações,
utilizando componentes da camada anterior (JANTSCHER ET al, 2009). Por
questões de segurança, cada aplicativo recebe um ID e tem uma máquina virtual
“exclusiva”.
Figura 19 - Arquitetura do Sistema Android. Fonte: JANTSCHER et al (2009)
Para o desenvolvimento de novos aplicativos para o Android é importante ter
em mente que não são todas as classes das bibliotecas do JavaME e do JavaSE
que executam, e são necessários os seguinte requisitos:
45
• Conhecimento em Java (mesmo que a máquina virtual seja a Dalvik VM o
código é desenvolvido, preferencialmente, em Java);
• SDK do Android ou, a plataforma sugerida, Eclipse IDE com Android
Development Tools (ADT) plug-in.
No momento da implementação do aplicativo no smartphone é necessário
instalar, também, o arquivo de extensão “.apk” que contém outro arquivo chamado
AndroidManifest.xml, que contém as informações básicas e necessárias (i.e. nome
de classes) para a instalação do aplicativo (MARTINS, 2009).
A interface com usuário é baseada no conceito de View (parte da tela –
Widgets) e ViewGroup (disposição dos objetos).
Para o Android existem 4 componentes básicos, sendo eles, atividades (todas
as ações disponíveis para cada tela), serviços, provedores de conteúdo (possibilitam
a troca de informações entre aplicativos) e receptores de broadcast (respondem a
eventos). Para iniciar uma atividade, por exemplo, o objeto Intent deve ser utilizado
(ele contém a ação a ser executada) (MARTINS, 2009).
Uma atividade possui basicamente 4 estados, ilustrados na figura 23 e tem a
sua comunicação realizada com um dos sete métodos listados.
No método onCreate a atividade é iniciada e define a interface com o usuário,
uma vez criada, a atividade passa pelos métodos onStart e onResume que é quando
a atividade está executando. A atividade passa para o método onPause sempre que
outra atividade é aberta. Caso o usuário opte por voltar a utilizar esta atividade, ela
retornará para o método onResume e caso outra aplicação precise de memória o
processo é encerrado (o sistema opta pela atividade que não está tendo mais
interação com o usuário) e a atividade volta para o onCreate. Além dessas
possibilidades, ainda no método onPause, a atividade pode não estar mais visível e
portanto ir para o método onStop. Uma vez no estado onStop a atividade possui as
mesmas opções que no onPause, com apenas duas diferenças que são, caso o
usuário volte a utilizar a atividade, ela deve passar pelo método onRestart para
depois voltar para o onStart e caso ela continue sem visibilidade ela é encaminhada
para o método onDestroy que realmente finaliza a atividade.
46
Figura 20 - Ciclo de vida de uma atividade. Fonte: MARTINS(2009)
47
5 MODELAGEM DO SISTEMA SMARTCOMPRAS
A modelagem do sistema SmartCompras é fundamental para o seu
desenvolvimento. Este capítulo detalha a modelagem do sistema, definindo os
requisitos e elaborando os diagramas através da linguagem UML (Unified Modeling
Language) (BOOCH et al, 2005).
5.1 LEVANTAMENTO DE REQUISITOS
Como uma das partes mais importantes da modelagem de um sistema, os
requisitos funcionais e não funcionais devem ter claramente definidos tudo que o
cliente espera do sistema.
Para o sistema SmartCompras pode-se destacar como principais requisitos a
funcionalidade de captar a imagem, processá-la, realizar uma compra e permitir que
o cliente decida por ter o seu perfil traçado ou não.
Nas seções 4.1.1 e 4.1.2 estão disponíveis todos os requisitos levantados
para o sistema SmartCompras.
5.1.1 Requisitos Funcionais
Os principais requisitos funcionais são listados a seguir, sendo o restante
anexado no apêndice A.
•
RF7. O sistema deve ser capaz de ler e interpretar o código de barras do
produto;
•
RF8. O sistema deve permitir que o usuário digite o código de barras;
•
RF11. O sistema deve mostrar na tela os dados do produto identificado
pelo código de barras;
•
RF14. O sistema deve traçar o perfil do cliente de acordo com as compras
já realizadas por ele;
•
RF16. O sistema deve permitir a finalização da compra;
•
RF18. O sistema deve perguntar ao usuário se ele permite traçar um perfil
de suas compras;
•
RF19. O sistema deve permitir que o usuário escolha ou não manter no
48
seu carrinho os produtos comprados com maior freqüência;
•
RF20. O sistema deve encaminhar ao usuário os produtos compatíveis
com seu perfil, caso o usuário deseje traçar o seu perfil;
•
RF21. O sistema deve imprimir na tela todos os produtos do carrinho com
a quantidade e seus respectivos valores e pedir confirmação, quando o
usuário decide concluir a compra;
•
RF26. O sistema deve enviar a lista de produto (produto, quantidade e
valor), endereço do usuário e forma de pagamento para o sistema do
mercado;
•
RF29. O sistema deve permitir que o administrador cancele uma compra
finalizada.
5.1.2 Requisitos Não-Funcionais
Os requisitos não-funcionais para o sistema SmartCompras são:
•
RFN1. O sistema deve executar em todos os dispositivos móveis que
possuam como sistema operacional o Google Android versão 2.2,
possuam câmera e conexão com a internet;
•
RFN2. O sistema deve ler o código de barras em, no máximo, 5 segundos;
•
RFN3. O sistema deve atualizar o banco de dados no dispositivo móvel
em, no máximo, 5 minutos após o login do cliente;
•
RFN4. O sistema deve ter taxa de acerto quanto a leitura de código de
barras igual a 80%;
•
RNF5. O sistema deve garantir a segurança dos dados do cliente;
•
RFN6. O sistema deve ter tempo de resposta entre as páginas inferior a 3
segundos considerando que a conexão tenha um bom sinal;
•
RFN7. O sistema não deve permitir que o usuário altere ou exclua a base
de dados de produto.
5.2 MODELAGEM DO BANCO DE DADOS
Para o sistema SmartCompras, foi utilizado uma modelagem de banco de
dados relacional. Desta forma, dois fluxos foram desenhados, sendo eles: o modelo
49
conceitual e o projeto do banco de dados. O projeto do banco de dados pode ser
encontrado no apêndice C, enquanto o modelo conceitual, diagrama de entidade e
relacionamento (DER), está ilustrado na figura 19. O diagrama de atividade é
apresentando no apêndice D, enquanto o de sequência E é apresentado no
apêndice.
5.3 DIAGRAMA DE CASO DE USO
Através do diagrama de Caso de Uso (figura 20) é possível descrever todas
as funcionalidades do sistema. Para o sistema SmartCompras os principais casos de
uso estão listados a seguir e as especificações formais de todos pode ser
encontrado no apêndice B.
UC 6 - Tirar foto do código de barras desejado
Após o usuário logar-se no sistema, através de usuário e senha, o sistema
deve abrir o software para captura de código de barras. O usuário deve capturar o
código de barras desejado e, em seguida o sistema deve processá-lo e imprimir na
tela as informações do produto. Caso o usuário não consiga capturar o código, ou
deseje digitar o mesmo, o sistema deve abrir um campo para a digitação. Se o
produto impresso não for o desejado, o usuário deve removê-lo do carrinho e refazer
o processo. Caso o código de barras não esteja cadastrado no banco de dados do
supermercado, é exibida uma mensagem “Produto não encontrado!” e caso o
produto não esteja disponível no momento, o sistema exibe a mensagem “Produto
indisponível”. Em ambas as situações (não cadastrado ou indisponível) o sistema
volta ao começo do caso de uso.
Um campo deve ser aberto para o usuário digitar a quantidade do produto
desejado, essa quantidade é adicionada ao carrinho, e seus respectivos valores
adicionados ao valor total. Caso o usuário não especifique a quantidade, o sistema
trata a quantidade como uma unidade do produto. Se não houver disponível a
quantidade desejada, o sistema exibe uma mensagem “Quantidade indisponível” e o
usuário deve digitar uma nova quantidade, até digitar um valor disponível e válido.
50
Figura 21 - Diagrama Entidade-Relacionamento do software SmartCompras. Fonte:
O AUTOR (2011)
51
UC 19 – Finalizar compra
Com o usuário tendo ao menos um produto no carrinho, o sistema deve
habilitar a opção de finalizar a compra.
Quando o usuário desejar finalizar a compra, o sistema deve solicitar
confirmação de finalização e, se o usuário não confirmar o sistema deve chamar o
UC6 e cancelar a finalização de compra.
Uma vez que o usuário confirme a finalização, o sistema deve chamar o UC20
que imprime todos os produtos do carrinho na tela e, se o usuário quiser excluir
algum produto o sistema deve chamar o UC15 para a exclusão de produtos.
Confirmado os produtos do pedido do usuário, o sistema deve chamar o
UC21 que solicita confirmação do endereço de entrega, exibir o valor total do pedido
e chamar o UC22 que solicita a forma de pagamento, assim que informado, deve
informar o número do pedido ao usuário. Após isso, o sistema encaminhará todos os
dados da compra para o supermercado e manterá o carrinho de produtos freqüente.
UC 22 – Informar forma de pagamento
Sempre que solicitada a finalização de uma compra, o sistema deve exibir as
formas de pagamento disponíveis e solicitar a escolha de uma forma de pagamento.
O usuário deve informar a forma de pagamento, e confirmar via solicitação do
sistema. Após a confirmação o sistema chama o UC23 que encaminha os dados do
pagamento ao supermercado. Caso o usuário não escolhe nenhuma das formas de
pagamento, o sistema exibe a mensagem “Selecione uma forma de pagamento” e o
usuário volta ao inicio desse fluxo.
UC26 – Cancelar compra
Com uma venda finalizada, o sistema deve solicitar o motivo do
cancelamento, o gerente informa o motivo do cancelamento e o sistema solicita uma
confirmação de cancelamento, o gerente confirma que deseja cancelar a venda.
Caso o gerente não confirme ou não de um motivo para cancelamento, o sistema
deverá exibir a mensagem “Cancelamento não efetuado!
52
Após a confirmação do cancelamento o sistema deve retirar os produtos do
carrinho, cancelar a venda, e exibir a mensagem “Compra cancelada!”.
UC 31 – Escolher se quer que trace seu perfil
Um usuário devidamente logado no sistema, através de usuário e senha, é
questionado pelo sistema se deseja traçar um perfil. Caso ele deseje traçar o perfil,
o sistema chama o UC30 para traçar o perfil sempre que ele se logar e exibe a
mensagem “Obrigado!”. Se a escolha for não traçar o perfil, o sistema exibe a
mensagem “Perfil não traçado!”.
Figura 22 - Diagrama de Caso de Uso do software SmartCompras. Fonte: O AUTOR
(2011)
53
5.4 DIAGRAMA DE CLASSE
Baseado nas funcionalidades do sistema, foi desenhado o diagrama de classe
(figura 21), onde as principais classes são “Clientes”, “Pedido” e “Produtos”. A classe
Cliente tem uma lista de endereços, telefones e logins associados a ela. A classe
Produto possui uma marca e uma categoria/subcategoria associada. A classe
Pedido tem um cliente, um status, uma forma de pagamento e uma lista de detalhes
de produtos que relaciona a quantidade de produtos escolhida. E partindo destas
classes, os seus atributos e métodos foram gerados.
54
Figura 23 - Diagrama de Classe do software SmartCompras. Fonte: O AUTOR (2011)
55
6 DESENVOLVIMENTO DO SMARTCOMPRAS
O sistema SMARTCOMPRAS foi desenvolvido utilizando o paradigma de
orientação a objetos e o sistema operacional Android na versão 2.2 ou superior. A
leitura e a interpretação do código de barras foi implementada em Java, sendo que
todas as classes também estão implementadas em Java (versão 6).
A interface de comunicação entre o usuário e o dispositivo móvel é realizada
através de arquivos XML. O banco de dados foi modelado através das ferramentas
brModelo (construção do DER e do Projeto Lógico de Banco de Dados) e do Astah
Comunity (construção dos diagramas de Classe, Uso, Atividade e Sequencia) e
implementado com o MySQL (versão 5.2.34). Através da linguagem SQL o algoritmo
Apriori foi implementado, tornando o seu funcionamento interno ao banco de dados.
As
próximas
seções
detalham
o
desenvolvimento
do
sistema
SMARTCOMPRAS, detalhando a implementação o Apriori e da captura e
processamento de imagem, bem como a arquitetura da solução implementada.
6.1 ARQUITETURA DA SOLUÇÃO
O banco de dados do sistema foi desenvolvido em MySQL, porém o Android
suporta apenas o SQLite (que funciona internamente no próprio celular). Com isso
foi necessário desenvolver um WebService (abordado neste tópico) responsável por
realizar a comunicação entre o banco de dados (MySQL) e o aplicativo disponível no
smartphone (Android).
O WebService é uma tecnologia que realiza a comunicação entre sistemas,
podendo ser de diferentes plataformas e linguagens, utilizando um dos modelos (ou
protocolos) existentes, (TANENBAUM & STEEN, 2011) sendo utilizado o SOAP
neste trabalho.
O SOAP (Simple Object Access Protocol) é um protocolo para ambientes
descentralizados e distribuído, no qual, após receber uma mensagem a converte
para XML, sendo que a troca de mensagem é realizada entre diferentes nós SOAP
(SUDA, 2003).
Conforme ilustrado na figura 24, o nó SOAP Servidor, implementado no
WebService se comunica com o nó SOAP Cliente, implementado no Smartphone
56
Android. Para realizar esta comunicação os objetos devem ser serializados, ou seja,
podem ser transferidos como parâmetros e depois montados novamente.
Esta comunicação entre os nós utiliza a estrutura de requisição de
documento, ou seja, toda a mensagem é enviada de uma única vez, não sendo
necessário aguardar o relatório de confirmação para enviar a outra parte da
mensagem.
Para disponibilizar o WebService, foi utilizado dentro do projeto o servidor
GlassFish, que é um servidor de aplicação desenvolvido pela SUN, responsável por
fornecer um ambiente que possibilite executar um WebService ou uma aplicação
web.
O banco de dados MySQL e o WebService estão alocados em um mesmo
servidor, e sua comunicação é feita utilizando uma classe responsável por informar a
URL (Uniform Resource Locator) do servidor e através do plugin DriveManager é
realizada a conexão com o banco de dados.
A aplicação envia uma requisição, através da rede, (utilizando o conceito de
mensagem SOAP) para o WebService, que busca a informação dentro do banco de
dados e retornar toda a informação solicitada para a aplicação.
Figura 24 – Arquitetura do sistema. Fonte: O AUTOR (2011).
6.2 CAPTURA E PROCESSAMENTO DO CÓDIGO DE BARRAS
A captura e processamento de imagem é uma das partes mais difíceis de ser
desenvolvida devido a grande gama de diferentes códigos de barra existentes e
57
devido ao fato de que quem irá manipular a captura da imagem é o usuário, sendo
necessário implementar diferentes ângulos de leitura.
Um ponto importante do Android é que ele possui diversas bibliotecas, como
por exemplo a biblioteca Zxing (Zebra Crossing) que é responsável por fazer a
captura e a interpretação de diferentes códigos de barras. O BarCode Scanner.
Como ela não foi desenvolvida apenas para aplicativos Android, ela possui diversas
classes e métodos que não são necessários implementar em um aplicativo Android.
Neste trabalho foi desenvolvido a captura e processamento de código de
barras, porém para o processamento do código de barras também foi utilizado à
biblioteca Zxing.
6.2.1 Captura do código de barras
A captura da imagem foi inicialmente projetada para realizar a captura
utilizando o conceito normal de uma captura de foto, após o usuário apertar o botão
a imagem é salva no cartão SD (Secure Digital). Porém, se a imagem não estiver
com a qualidade mínima para ser processada, o usuário deveria tirar outra foto e,
como isso poderia ocorrer com freqüência, o usuário poderia ficar descontente.
Para evitar este problema foi estudado e implementado o stream de vídeo, no
qual é aplicado, através do método onPreviewFrame() a funcionalidade de processar
frame por frame o que estiver no stream, sem necessitar salvar a imagem.
Esta solução inicialmente informa os parâmetros nos quais a câmera deve
operar e, através do SurfaceHolder (classe do Android para trabalhar com a câmera)
ativa o stream de vídeo, uma vez ativado, a imagem é processada conforme o que
será explicado no item 6.2.2.
6.2.2 Processamento do código de barras
Para realizar o processamento é necessário aplicar uma série de
transformações na imagem, conforme abordado no capítulo 2 deste trabalho.
O primeiro conceito implementado é a transformação para a escala de cinza,
para depois detectar a borda.
Os estudos para a detecção de borda foi focado em apenas um algoritmo,
que obteve sucesso na implementação, por isso, para a detecção de borda foi
58
implementado o algoritmo do Operador de Sobel, que através da expressão: g(x,y) =
X2 + Y2, onde o X é uma matriz da máscara resultante de variação no sentido
horizontal e o Y no sentido vertical, é possível realçar as colunas do código de
barras, descartando qualquer ruído na imagem.
Uma vez descartado os ruídos, é necessário binarizar todos os pixels do vetor
gerado. Isso é feito comparando o valor do pixel, ou seja, atribui-se 0 a posição do
vetor do pixel lido caso o valor seja maior do que -128, senão atribui-se ao valor 1.
Após fazer essas duas transformações, finaliza-se o Operador de Sobel com as
margens de cada coluna, bastando apenas, decodificar o código de barra em si.
Para esta decodificação, existe um algoritmo que inicia armazenando o valor
do marcador de início e o marcador final. Uma vez reconhecido as duas
extremidades do código, o algoritmo o separa em duas partes, a primeira
responsável por identificar o primeiro dígito, enquanto a segunda armazena o
restante do código. O primeiro dígito é a primeira parte a ser feita, pois dependendo
do seu valor a decodificação do restante do código passa a ser diferente, ou seja,
dependendo da paridade do primeiro dígito a interpretação dos próximos 6 dígitos
podem ser distintas. Uma vez interpretado o primeiro dígito, automaticamente foi
identificado os 6 números seguintes. Ao alcançar a parte intermediária do código de
barras, a maneira de interpretar é diferente, passando por tanto a realizar outra
verificação para identificar o código de barras.
Foi estudado os métodos implementados pela biblioteca Zxing (figura 25) para
dar continuidade ao processamento de imagem.
Nesta biblioteca existe dezenas de classes, pois ela interpreta não somente
os códigos de barra EAN-13, como todos os outros tipos de código de barra
existentes, além de poder ser utilizada em qualquer plataforma (OWEN, 2011).
Para o tratamento da imagem, as principais classes utilizadas são:
Reader é responsável por identificar as extremidades do código de barras
(utilizando a classe Result) e por verificar qual o tipo de código de barra (utilizando a
classe DecodeHintType).
Binarizer é responsável pela conversão dos dados em escala de cinza para
um vetor de bits, essa transformação para escala de cinza é realizada na classe
LuminanceSource.
Para a decodificação do EAN 13 é importante relembrar que o primeiro
número do código de barra define a interpretação que deverá ser aplicada no
59
restante do código, sendo assim a classe EAN13Reader () da biblioteca ZXing utiliza
o primeiro dígito para definir como será a decodificação do restante do código de
barras.
Esta classe importa 3 outras classes também desta biblioteca, sendo elas, a
BarcodeFormat, a NotFoundException e a BitArray.
A BarcodeFormat é responsável por identificar que tipo de código de barra o
aplicativo está processando, lembrando que esta biblioteca permite processar
qualquer tipo de código de barras.
NotFoundException é utilizada quando não é possível processar uma
imagem, ou seja, quando a biblioteca não tem certeza se é um código de barra ou
não.
BitArray é responsável por fazer toda a gestão do array onde ficará
armazenada as informações do código processado.
Figura 25 – Arquitetura da biblioteca ZXing. Fonte: O AUTOR (2011)
6.3 MINERAÇÃO DE DADOS
Toda vez que um cliente realiza uma compra, ela fica armazenada no banco
de dados com 3 principais objetivos, o primeiro é para que o próprio mercado tenha
maior controle sobre as compras de seus clientes, o segundo é com o intuito de
60
oferecer ao cliente maior comodidade – uma vez que ele pode optar por realizar a
mesma compra, evitando que ele tenha o desgaste de passar por todo o mercado
novamente - e o último objetivo, mas não menos importante, é para ter informações
suficientes do cliente para poder aplicar conceitos de Mineração de Dados
permitindo ao supermercado enviar promoções aos seus clientes.
A Mineração de Dados deste sistema foi implementada direto no banco de
dados MySQL, utilizando o algoritmo do Apriori.
Conforme abordado no item 3.5.3, o Apriori resolve o problema do “itemset”
freqüente, no qual cada produto adquirido pelo cliente em uma compra é um
“itemset” e o algoritmo é responsável por verificar a quantidade de vezes que dois
produtos aparecem em uma mesma compra.
Foram utilizadas tabelas auxiliares, criadas durante a execução do algoritmo
Apriori e que ao finalizar o algoritmo elas são descartadas. Outra particularidade do
MySQL é que não se trabalha com vetores ou matrizes, mas sim com tabelas.
Uma view (BaseApriori) foi desenvolvida para auxiliar na seleção dos pedidos,
sendo assim, é possível determinar o percentual que define se o itemset é freqüente
ou não. Por exemplo, pode-se definir que um produto que aparece pelo menos em
60% das compras como freqüente, o que auxilia na oferta de novos produtos e
promoções para determinados clientes. Esta porcentagem, do que se considera
freqüente, pode ser definida pelo mercado, mas como padrão o sistema
estabelecerá 60%.
A view BaseApriori realiza um select na tabela de pedido e seleciona os
produtos que foram pedidos, que através do innerjoin, (ou seja, copia para uma nova
tabela somente as informações onde tanto a informação da tabela A e da tabela B
atenderem os parâmetros definidos) irá juntar a tabela de detalhe_pedido, tendo,
portanto, o código do pedido e o código do produto.
O algoritmo Apriori é chamado sempre que o cliente seleciona um produto
para adicionar ao seu carrinho. O intuito da utilização do Apriori neste momento é
verificar qual outro produto o cliente costuma comprar quando compra o produto
selecionado e com isso, já lhe oferecer esta opção.
Neste caso, o Apriori será aplicado apenas em dados específicos do cliente
em questão, ou seja, no momento em que for requisitado a execução do Apriori,
será passado o CPF do cliente onde o Apriori irá fazer o join (citado anteriormente)
somente das compras destes clientes e retornará a informação.
61
Além desta funcionalidade, o Apriori também é utilizado para que o sistema
possa definir uma lista de promoções específica para um determinado nicho de
cliente, ou seja, o mercado poderá criar uma lista de produtos, passando como
parâmetro o perfil que ele desejar, seja por idade, por sexo ou por características de
compra, e o Apriori retornaria os itens mais comprados pelos clientes do perfil
aplicado.
O Apriori pode ser implementado em outras situações, bem como existem
outros algoritmos para realizar a mineração de dados, porém neste trabalho,
abordamos o Apriori para as funções citadas acima.
62
7 TESTES
Concluído o desenvolvimento, iniciaram-se os testes. Os testes foram
realizados em ambiente simulado, conforme descrito no item 6.1, e foram
executados 3 testes de funcionamento, sendo eles: captura e processamento do
código de barra, comunicação utilizando o WebService e a funcionalidade do Apriori.
Além dos testes descritos, foi executado o teste de integração, ou seja, a realização
de uma compra utilizando as funcionalidades desenvolvidas para o sistema. As telas
do teste do sistema bem como suas descrições encontram-se no apêndice G.
7.1 CONFIGURAÇÃO DE REDE
Inicialmente, os testes foram realizados em ambiente simulado sendo,
portanto, necessário montar uma rede sem fio, que é definida pela Microsoft como
”Redes sem fio que usam ondas de rádio para enviar informações entre
computadores. Os três padrões mais comuns de rede sem fio são 802.11b, 802.11g
e 802.11a.”
O Android suporta apenas as conexões GSM (Global System for Mobile), 3G,
EDGE (Enhanced Data-Rates for Global Evolution) e 802.11, portanto foi escolhida a
opção 802.11 para os testes.
Para montar a rede sem fio, os seguintes equipamentos foram necessários:
1 Roteador DLink;
1 Notebook Vaio (como servidor);
1 Samsung Galaxy 5 (como smartphone).
7.2 CAPTURA E PROCESSAMENTO DE IMAGEM
Os testes de captura foram com sucesso, porém ao testar o processamento
de imagem, a limitação descrita no item 6.3 foi o primeiro impeditivo para dar
continuidade aos testes.
Ao melhorar o código e trabalharmos com o cenário perfeito (eliminando o
primeiro problema) outro problema foi encontrado: a qualidade da imagem era baixa
e durante a binarização da imagem ela ficava toda branca, inclusive as barras pretas
63
o que impossibilitou a continuidade com o código desenvolvido pelo grupo.
Portanto, foi utilizada a biblioteca ZXing, descrita no item 6.3. Com esta
biblioteca implementada, a captura e o processamento ocorrem internos a ela e
somente retorna o resultado com o valor do código de barra.
Inicialmente foi testado em um celular com uma câmera de 3.2 mp e os testes
foram com sucesso, porém ao executar com o celular de teste, que possui uma
câmera de 2.0 mp, foi testado em 7 produtos diferentes, porém apenas foi possível
ler 1 produto. Para certificar que o problema era com a câmera, testamos o
aplicativo da própria biblioteca ZXING, o Barcode Scanner, que também não
identificou os produtos.
7.3 WEBSERVICE
O teste do WebService foi feito utilizando o conceito de que toda informação
digitada no celular e enviada, deve aparecer no banco de dados. Sendo assim,
realizando um novo cadastro, foi possível verificar se a comunicação feita via
WebService está ok (ilustrado na figura 26).
Durante os testes foram encontrados problemas com a parametrização.
Quando enviado apenas uma variável como parâmetros, por exemplo o CPF para
realização da mineração de dados, não foram encontrados problemas, porém para
passar como parâmetro um objeto inteiro, por exemplo do tipo Cliente, a
complexidade foi muito maior. A solução implementada para tratar este tipo de
situação foi tratá-las como String e separá-las por ponto e vírgula (;).
Uma vez implementado os dois tipos de parâmetros, os testes foram
executados considerando o processo de compra e de cadastro.
Foram realizadas 9 compras, alternando a quantidade de produtos do
carrinho, ou seja, 3 compras foram realizadas inserindo apenas 1 produto no
carrinho porém, com diferentes quantidades deste produto, os 3 seguintes foram
realizados adicionando diferentes tipos de produto, porém apenas 1 de cada tipo e
por fim, foram realizados 4 compras com diferentes quantidades de diferentes
produtos e para o cadastro foram realizados 3 testes.
Todas as informações foram inseridas com sucesso no banco de dados.
64
7.4 APRIORI
Para realizar os testes do Apriori foram utilizadas duas situações, a primeira
que foi escolhendo a opção “Promoções do dia” e a segunda foi a de oferecer
produtos assim que foi adicionado um novo produto ao carrinho.
Para as duas opções todos os testes foram com sucesso. Sendo que foram
testados os seguintes cenários:
-Caso seja a primeira compra do usuário, nada foi mostrado, pois como não
existem compras cadastradas no CPF de um novo usuário, não é possível realizar a
mineração.
-Caso o cliente já tenha realizado, ao menos, uma compra o Apriori foi
executado com sucesso, porém, ficou nítido que somente após a 10ª compra que o
Apriori apresentou maior eficiência.
A diferença da execução do Apriori, quando com maior quantidade de
compras cadastrada no CPF em questão ou com poucas compras cadastradas, foi,
na maioria dos testes, similar, sendo quase imperceptível ao usuário esta diferença.
7.5 SISTEMA DE COMPRA
Uma vez integrado todo o sistema, realizamos 12 compras, sendo 9 delas
com CPFs já existentes no banco de dados para que as funcionalidades de
promoções e anteriores pudessem ser testadas e 3 com um cadastro novo utilizando
o sistema desenvolvido para realizar o cadastro.
As funcionalidades de realizar a compra foram testadas com sucesso, apenas
a funcionalidade de comparação de produtos de mesma categoria que não
apresentou resultado satisfatório 100% do tempo por utilizarmos um banco de dados
de um pequeno comércio, onde a subcategoria não era um quesito preenchido ou
preenchido incorretamente.
65
Figura 26 – Informações inseridas no banco de dados através do aplicativo SmartCompras.
Fonte: O AUTOR (2011)
66
8 CONCLUSÃO
Com a crescente competitividade entre os mercados, ter um sistema que
facilite o usuário a realizar as compras, é sem dúvida, um ganho muito grande. A
implementação do sistema SmartCompras reduz o tempo de compra do cliente,
além de proporcionar maior comodidade.
O desenvolvimento para Android é muito similar ao desenvolvimento em Java,
exceto por particularidades do próprio sistema Android, durante a implementação do
sistema, vale ressaltar que foram encontradas limitações quanto ao processamento
de imagem, pois a qualidade da foto do código de barra tirada não permitiu a
continuidade dos testes utilizando o código estudado e desenvolvido pelo grupo,
porém, uma das grandes facilidades do Android, é que muitas funcionalidades que
foram pensadas em desenvolver para este sistema, o Android já possuía uma, ou
mais, bibliotecas prontas.
Um grande problema encontrado, e ainda sem uma solução eficaz, é
referente ao usuário final que possua qualquer tremor em suas mãos, pois este
aplicativo não será tão eficiente, uma vez que ele não conseguirá interpretar a
imagem e, portanto, não interpretará o código de barras, tendo, o usuário, que digitar
o código, mas com isso, toda a facilidade e agilidade do sistema, é perdida, ainda
considerando a facilidade para o usuário, outro problema sem solução que o grupo
encontrou, foi com relação a usuários sem conhecimento de tecnologia, ou seja,
pessoas que possuem limitações para manusear o aparelho celular e o aplicativo.
Outra limitação do Android é quanto a comunicação com o banco de dados,
pois ele não se comunica com o MySQL, apenas com o SQLite, por isso,
implementamos
um
WebService
responsável
por
essa
comunicação,
a
implementação deste WebService, por mais complexa que tenha sido, para o
usuário final é transparente.
Considerando a mineração de dados, foram estudados diferentes tipos para
realizá-la, e, para este aplicativo, a opção que ofereceu melhor custoXbenefício foi o
Apriori, pois ele resolve o problema do itemset freqüente, exatamente o que era
necessário e a sua complexidade/tempo de execução mostrou-se a melhor opção
para realizar a mineração dos dados.
Portanto, este aplicativo, na situação ideal, facilita a realização de compras
67
para o cliente e para o estabelecimento, porém, até o momento, ele ainda possui
limitações que podem causar desconfortos dependendo do tipo de usuário.
8.1 TRABALHOS FUTUROS
Com a conclusão, pode-se identificar alguns estudos futuros. Sendo eles:
melhorar a implementação do processamento da imagem, sem utilizar a biblioteca,
bem como o designe da aplicação. Foi identificado oportunidade de novas
implementações novas funcionalidades, como por exemplo, um sistema web,
exclusivo para o estabelecimento controlar o cancelamento ou para extração de
relatórios. A mineração de dados pode ser melhorada a todo instante, novos
conceitos e conhecimentos podem ser implementados, aprimorando o resultado da
mineração. Não houve tempo para a implementação de todos os casos de uso,
sendo que os casos de uso listados a seguir podem ser implementados futuramente:
- UC2 - Validar CEP e CPF;
- UC7 - Alterar dados pessoais;
- UC15 - Ativar e desativar usuário;
- UC21 - Confirmar endereço de entrega;
- UC25 - Verificar compras realizadas;
- UC26 - Cancelar compra;
- UC27 - Gerar cancelamento.
68
REFERÊNCIA BIBLIOGRÁFICA
ADDRIANS, Pieter; ZANTINGE, Dolf. DataMining. Inglaterra: Addison-wesley, 1996.
ALBUQUERQUE, Márcio Portes de; ALBUQUERQUE, Marcelo Portes de.
Processamento de Imagens: Métodos e Análises. Revista Científica, Rio de
Janeiro:
2001.
Disponível
em:
<www.cbpf.br/cat/pdsi/pdf/ProcessamentoImagens.PDF>. Acesso em: 26 abr. 2011.
AMO, Sandra de. Curso de Data Mining. 2003. Programa de Mestrado - Curso de
Ciência da Computação, Universidade Federal de Uberlândia, Uberlândia, 2003.
Disponível em: <http://www.deamo.prof.ufu.br/CursoDM.html>. Acesso em: 10 maio
2011.
AMORIM, Thiago. Conceitos, técnicas, ferramentas e aplicações de Mineração
de Dados para gerar conhecimento a partir de bases de dados. 2006. 50 f.
Trabalho de Diplomação (Graduação) - Curso de Ciência da Computação,
Departamento de Informática, Universidade Federal de Pernambuco, Pernambuco,
2007. Disponível em: <http://www.cin.ufpe.br/~tg/2006-2/tmas.pdf>. Acesso em: 13
maio 2011.
ANAIS XIII SIMPÓSIO BRASILEIRO DE SENSORIAMENTO REMOTO, 2007,
Florianópolis. Uso de árvore de decisão para predição da prevalência de
esquistossomose no estado de Minas Gerais, Brasil. Florianópolis: Inpe, 2007.
Disponível
em:
<http://www.dpi.inpe.br/geoschisto/publicacoes/MartinsFT_SBSR.pdf>. Acesso em:
10 maio 2011.
ASSOCIAÇÃO BRASILEIRA DE AUTOMAÇÃO COMERCIAL (Brasil). O futuro será
assim. Disponível em: <http://www.afrac.com.br/si/site/13110>. Acesso em: 15 maio
2011.
BARBOSA, Anderson Henrique; FREITAS, Marcílio Sousa da Rocha; NEVES,
69
Francisco de Assis Das. Confiabilidade estrutural utilizando o método de Monte
Carlo e redes neurais. Revista Escola de Minas, Ouro Preto, v. 58, n. 3, p.x-x, jul.
2005.
Disponível
em:
<http://www.scielo.br/scielo.php?pid=s0370-
44672005000300011&script=sci_arttext>. Acesso em: 26 maio 2011.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usuário. Rio
De Janeiro: Campus, 2005.
BRAGA, Luis Paulo Vieira. Introdução à Mineração de Dados. Rio de Janeiro: Epapers, 2005.
CARVALHO, Luís Alfredo Vidal De. DATAMINING: A mineração de Dados no
Marketing, Medicina, Economia, Engenharia e Administração. São Paulo: Érica,
2001.
CONCI, Aura; MONTEIRO, Leonardo Hiss. RECONHECIMENTO DE PLACAS DE
VEÍCULOS
POR
IMAGEM.
Niterói,
2004.
Disponível
em:
<www.ic.uff.br/~aconci/CONENPLACAS.pdf>. Acesso em: 15 abr. 2011.
CORTES, Sérgio Da Costa; PORCARO, Rosa Maria; LIFSCHITZ, Sérgio.
Mineração de Dados: Funcionalidades, Técnicas e Abordagens. 2002. 35 f.
Pesquisa - Puc, Rio de Janeiro, 2002. Disponível em: <http://www.dbd.pucrio.br/depto_informatica/02_10_cortes.pdf>. Acesso em: 25 maio 2011.
ERDEI, Guillermo E. CÓDIGO DE BARRAS: Desenvolvimento, Impressão e
Controle de Qualidade. Rio De Janeiro: Makron Books, 1994.
FONSECA, José M. M. R. de; INDUÇÃO DE ÁRVORES DE DECISÃO: HistClass Proposta de um algoritmo não paramétrico. Lisboa, 1994. Trabalho de
Diplomação (Mestrado) – Departamento de Informática, Universidade Nova de
Lisboa.
Disponível
em:
http://www.uninova.pt/~jmf/Documentos%20pdf/Tese%20Mestrado/Tese%20Mestra
do.pdf
70
GONZALEZ, Rafael C.; WOODS, Richard E. Digital Image Processing. 2. ed. New
Jersey: Pretice Hall, 2002.
GROSSMANN, Fábio; ZYNGIER, Mauro Luiz. CÓDIGO DE BARRAS: DA TEORIA
À PRÁTICA. 2. ed. São Paulo: Nobel, 1991
HAYKIN, Simon. REDES NEURAIS: PRINCÍPIOS E PRÁTICA. 2. ed. Porto Alegre:
Bookman, 2001.
JANTSCHER, Martin; TALHAOUI, Mohammed; VOS, Denis de; CUNHA, Ivan;
Roszcyk, Artur; Datsyuk, Mikhail. ANDROID PLATFORM PRESENTATION., 2010.
Disponível em: < www.mad-ip.eu/files/reports/Android.pdf> Acesso em: 22 Outubro
2011.
LINHA BASE (Brasil). Enciclopédia sobre Código de Barras. 2011 Disponível em:
<http://www.linhabase.com.br/codigodebarras/simbologias/default.asp>. Acesso em:
05 maio 2011.
MARTINS, Rafael J. Werneck de A., Desenvolvimento de Aplicativo para
Smartphone com a Plataforma Android. 2009. 50f. Trabalho de Diplomação
(Graduação) – Curso de Engenharia da Computação, Pontifícia Universidade
Católica do Rio de Janeiro, Rio de Janeiro, Dezembro de 2009. Disponível em:
<www.icad.puc-rio.br/~projetos/android/files/monografia.pdf> Acesso em 20 Outubro
2011.
MICROSOFT. O que é necessário para configurar uma rede doméstica. 2011.
Disponível em: <http://windows.microsoft.com/pt-BR/windows-vista/What-you-needto-set-up-a-home-network> Acesso em: 18 Outubro 2011
MUENZ,
Edison
Gustavo.
Estudo
e
implementação
de
algoritmos
de
processamento de imagens com técnicas GPGPU. 2008. 53 f. Trabalho de
Diplomação (Graduação) - Curso de Ciência Da Computação, Universidade Federal
De
Santa
Catarina,
Florianópolis,
2008.
Disponível
em:
71
<http://projetos.inf.ufsc.br/arquivos_projetos/projeto_833/tcc_EdisonGustavoMuenz.p
df>. Acesso em: 19 maio 2011.
NAVEGA, SERGIO, 2002, São Paulo. Princípios Essenciais do Data Mining.
Cenadem:
Anais
do
Infoimagem,
2002.
Disponível
em:
<http://www.intelliwise.com/reports/i2002.htm>. Acesso em: 15 abr. 2011.
OWEN, Sean,
GOOGLE CODE: ZXing ("Zebra Crossing").
Disponível em:
<code.google.com/p/zxing>. Acesso em: 20 outubro 2011
PITONI, Rafael Moreira. Mineração de Regras de Associação nos. 2002. 61 f.
Trabalho de Diplomação (Graduação) - Curso de Ciência Da Computação,
Departamento de Instituto De Informática, Universidade Federal Do Rio Grande Do
Sul
Associação
Nos,
Porto
Alegre,
2002.
Disponível
em:
<http://www.inf.ufrgs.br/gppd/direto/trabalhos/Dissertacao_Pitoni.pdf>. Acesso em:
27 abr. 2011.
REUTERS. Crescimento dos smartphones anima mercado no 1º trimestre. G1:
Tecnologia
&
Games,
Brasil,
29
abr.
2011.
Disponível
em:
<http://g1.globo.com/tecnologia/noticia/2011/04/boom-dos-smartphones-animamercado-no-1o-trimestre.html>. Acesso em: 15 mar. 2011.
RUSSELL, Stuart; NORVIG, Peter. Inteligência Artificial. 2. ed. Rio de Janeiro:
Campus, 2004.
Revista Info Exame. UM NOTEBOOK COM A SUA CARA. Editora Abril, jun. 2010.
SANTOS, Tiago Henrique Tudisco dos; ARTERO, Almir Olivette. Processamento
Digital de Imagens de Códigos de Barras usando Telefones Celulares,
Presidente Prudente, VI Workshop de Visão Computacional, 2010. Disponível em:
< iris.sel.eesc.usp.br/wvc/anais_WVC2010/artigos/poster/72797.pdf>. Acesso em: 24
outubro 2011.
SFERRA, Heloisa Helena; CORRÊA, Ângela M. C. Jorge. Conceitos e Aplicações de
72
Data Mining. Revista De Ciência & Tecnologia, Piracicaba, v. 11, n. 22, p.19-34,
jul.
2003.
Disponível
em:
<http://www.unifra.br/professores/EDUARDO/Artigo%208.pdf>. Acesso em: 10 maio
2011.
SUDAN, Brian, SOAP Web Services. 2003. 75f Tese (Mestrado) – Curso de Ciência
da Computação, Computer Science School of Informatics, University of Edinburgh,
Edinburgh,
2003.
Disponível
em:
<suda.co.uk/publications/MSc/brian.suda.thesis.pdf>. Acesso em 25 outubro 2011.
TANENBAU, Andrew S.; STEEN, Maarten Van. Sistemas Distribuídos: princípios
e paradigmas. 2.ed. São Paulo: Pearson Prentice Hall, 2007. 402p.
WALTER WEISZFLOG (Brasil). MICHAELIS: Moderno dicionário da língua
portuguesa. São Paulo: Companhia Melhoramentos, 1998.
73
APÊNDICE
A REQUISITOS FUNCIONAIS:
RF1.O sistema deve permitir a criação e alteração de cadastro do usuário;
RF2.O sistema deve validar o CEP e o CPF do cliente;
RF3. O sistema deve permitir logar o cliente (através de login e senha);
RF4. O sistema deve permitir que o cliente armazene seu login e senha e
permaneça conectado;
RF5. O sistema deve verificar se o cliente está apto a realizar uma compra
(ativo/inativo);
RF6. O sistema deve permitir a atualização do banco de dados de produto
diariamente quando o usuário se logar no sistema;
RF7. O sistema deve ser capaz de ler e interpretar o código de barras do produto;
RF8. O sistema deve permitir que o usuário digite o código de barras;
RF9. O sistema deve permitir que o usuário adicione produtos no carrinho;
RF10. O sistema deve criar um pedido;
RF11. O sistema deve mostrar na tela os dados do produto identificado pelo código
de barras;
RF12. Ao adicionar um produto no carrinho, o sistema deve permitir que o usuário
escolha a quantidade a ser comprada;
RF13. O sistema deve permitir que o usuário exclua um produto do carrinho;
RF14. O sistema deve traçar o perfil do cliente de acordo com as compras já
realizadas por ele;
RF15. O sistema deve validar se o cliente deseja receber ofertas de produtos
comprados com freqüência, durante a realização de uma compra;
RF16. O sistema deve permitir a finalização da compra;
RF17. O sistema deve ser capaz de comparar preço de produtos com a mesma
funcionalidade e de marcas distintas;
RF18. O sistema deve perguntar ao usuário se ele permite traçar um perfil de suas
compras;
RF19. O sistema deve permitir que o usuário escolha ou não manter no seu carrinho
74
os produtos comprados com maior freqüência;
RF20. O sistema deve enviar ao usuário os produtos compatíveis com seu perfil,
caso o usuário deseje traçar o seu perfil;
RF21. O sistema deve imprimir na tela todos os produtos do carrinho com a
quantidade e seus respectivos valores e pedir confirmação, quando o usuário decide
finalizar a compra;
RF22. O sistema deve armazenar todas as compras realizadas pelo usuário;
RF24. O sistema deve solicitar confirmação ao usuário do endereço a ser entregue;
RF25. O sistema deve solicitar a forma de pagamento para o usuário;
RF26. O sistema deve enviar a lista de produto (produto, quantidade e valor),
endereço do usuário e forma de pagamento para o sistema do mercado;
RF27. O sistema não deve duplicar produto, apenas aumentar a sua quantidade;
RF28. O sistema não deve permitir que o usuário não escolha nenhuma forma de
pagamento;
RF29. O sistema deve permitir que o administrador cancele uma compra finalizada;
RF30. O sistema deve permitir que o administrador faça a ativação/bloqueio de um
usuário;
RF31. O sistema deve permitir que o usuário solicite o bloqueio da sua conta;
RF32. O sistema deve permitir que o cliente cancele a compra antes de finalizá-la;
75
B DESCRIÇÃO FORMAL DOS CASOS DE USO
UC1 – Cadastrar no sistema:
Descrição: Caso de uso que realiza o cadastro do usuário no sistema.
Ator Principal: Usuário.
Pré-Condição: Não há.
Fluxo Principal:
1. Sistema solicita dados cadastrais do usuário;
2. Usuário informa dados cadastrais;
3. Sistema valida CEP e CPF informado (chama UC2);
4. Sistema solicita dados de login (usuário e senha);
5. Usuário informa dados de login;
6. Sistema exibe informações (dados cadastrais e de login) e solicita confirmação;
7. Usuário confirma dados;
8. Sistema envia dados ao banco de dados, e cadastra cliente;
9. Sistema exibe mensagem “Cadastro realizado com sucesso!”;
10.
Sistema encerra caso de uso.
Fluxo de Alternativo:
2.a Usuário não informa dados cadastrais;
2.a.1 Sistema exibe mensagem “Preenchimento obrigatório!”
2.a.2 Sistema volta ao passo 1 do fluxo principal.
4.a Usuário não informa dados de login;
4.a.1 Sistema exibe mensagem “Preenchimento obrigatório!”
4.a.2 Sistema volta ao passo 4 do fluxo principal.
7.a Usuário não confirma dados;
7.a.1 Sistema reabre campos para edição de dados;
7.a.2 Usuário altera os campos desejados;
7.a.3 Volta ao passo 6 do fluxo principal.
Fluxo de Exceção:
6.a Login já existente;
6.a.1 Sistema exibe mensagem “Login já cadastrado”;
6.a.2 Sistema reabre campo de login para alteração;
6.a.3 Volta ao passo 6 do fluxo principal.
76
UC2 – Validar CEP e CPF:
Descrição: Caso de uso que valida CEP e CPF do cliente.
Ator Principal: Usuário.
Pré-Condição: Usuário solicitar cadastro no sistema.
Fluxo Principal:
1. Sistema solicita CEP e CPF do cliente;
2. Usuário informa CEP e CPF;
3. Sistema valida CEP e CPF informado pelo cliente no cadastro;
4. Sistema volta ao UC1 – “Cadastrar no sistema”;
5. Sistema encerra caso de uso.
Fluxo de Alternativo:
2.a Usuário não informa CEP;
2.a.1 Sistema exibe mensagem “Preenchimento obrigatório!”;
2.a.2 Sistema volta ao passo 1 do fluxo principal.
2.b Usuário não informa CPF;
2.b.1 Sistema exibe mensagem “Preenchimento obrigatório!”
2.b.2 Sistema volta ao passo 1 do fluxo principal.
Fluxo de Exceção:
2.a CEP inválido;
2.a.1 Sistema exibe mensagem “CEP inválido!”;
2.a.2 Sistema volta ao passo 1 do fluxo principal;
2.b CPF inválido;
2.b.1 Sistema exibe mensagem “CPF inválido!”;
2.b.2 Sistema volta ao passo 1 do fluxo principal.
UC3 – Logar no sistema:
Descrição: Caso de uso que realiza o login do usuário no sistema.
Ator Principal: Usuário.
Pré-Condição: Usuário possuir cadastro no sistema.
Fluxo Principal:
1. Sistema solicita login e senha;
2. Usuário informa login e senha;
3. Sistema valida login e senha (chama UC4);
4. Sistema chama UC6 – “Tirar foto do código de barras desejado”;
77
5. Sistema encerra caso de uso.
Fluxo de Alternativo:
2.a Usuário não informa login;
2.a.1 Sistema exibe mensagem “Insira um login!”;
2.a.2 Sistema volta ao passo 1 do fluxo principal.
2.b Usuário não informa senha;
2.b.1 Sistema exibe mensagem “Insira uma senha!”;
2.b.2 Sistema volta ao passo 1 do fluxo principal.
Fluxo de Exceção: - Não há.
UC4 – Validar login e senha:
Descrição: Caso de uso que loga o cliente no sistema.
Ator Principal: Usuário.
Pré-Condição: Usuário possuir cadastro no sistema.
Fluxo Principal:
1. Sistema valida login e senha;
2. Sistema chama UC6 – “Tirar foto do código de barras desejado”;
3. Sistema encerra caso de uso.
Fluxo de Alternativo: - Não há.
Fluxo de Exceção:
3.a Login inexistente;
3.a.1 Sistema exibe mensagem “Digite um login válido”;
3.a.2 Sistema volta ao passo 1 do fluxo principal.
3.a Login já existente;
3.a.1 Sistema exibe mensagem “Senha inválida!”;
3.a.3 Sistema volta ao passo 1 do fluxo principal.
UC5 – Atualizar banco de dados disponível no celular:
Descrição: Caso de uso atualiza o banco de dados no celular do cliente.
Ator Principal: Usuário.
Pré-Condição: Usuário solicitar logar-se no sistema.
Fluxo Principal:
1. Sistema conecta-se com o banco de dados do supermercado;
2. Sistema atualiza banco de dados;
78
3. Sistema exibe mensagem “Banco de dados atualizado!”;
4. Sistema encerra caso de uso.
Fluxo de Alternativo: Não há.
Fluxo de Exceção: Não há.
UC6 - Tirar foto do código de barras desejado:
Descrição: Caso de uso que realiza a captura do código de barras.
Ator Principal: Usuário.
Pré-Condição: Cliente estar devidamente logado no sistema, através de usuário e
senha e fotografar um produto existente no banco de dados do supermercado.
Fluxo Principal:
1. Sistema abre software para captura de código de barras;
2. Usuário captura código de barras desejado;
3. Sistema processa o código de barras (chama UC8);
4. Sistema se comunica com o banco de barras do supermercado (chama UC09);
5. Sistema imprime informações do produto (chama UC10);
6. Usuário informa a quantidade desejada (chama UC12);
7. Sistema adiciona a quantidade de produtos no carrinho;
8. Sistema soma o valor do produto adicionado, ao valor total da compra;
9. Sistema encerra caso de uso.
Fluxo Alternativo:
2.a Usuário deseja digitar o código de barras;
2.a.1 Sistema habilita campo de código de barras (chama UC11);
2.a.2 Volta ao passo 3 do Fluxo Principal.
5.a Produto impresso errado;
5.a.1 Usuário remove produto do carrinho (chama UC15);
5.a.2 Volta ao passo 1 do Fluxo Principal.
7.a Usuário não informa a quantidade desejada;
7.a.1 Sistema preenche automaticamente a quantidade com 1;
7.a.2 Volta ao passo 6 do Fluxo Principal.
Fluxo de Exceção:
2.a Usuário não consegue capturar o código de barras;
2.a.1 Usuário solicita digitar o código de barras;
2.a.2 Sistema habilita campo de código de barras (chama UC11);
79
2.a.3 Volta ao passo 3 do Fluxo Principal.
3.a Código de barras não cadastrado no Banco de Dados;
3.a.1 Sistema exibe mensagem “Produto não encontrado!”;
3.a.2 Volta ao passo 1 do Fluxo Principal.
3.b Produto não disponível;
3.b.1 Sistema exibe a mensagem “Produto indisponível!”;
3.b.2 Volta ao passo 1 do Fluxo Principal.
7.a Usuário insere uma quantidade não disponível;
7.a.1 Sistema exibe a mensagem “Quantidade indisponível!”;
7.b.2 Volta ao passo 5 do Fluxo Principal.
UC7 – Alterar dados pessoais:
Descrição: Caso de uso que altera os dados pessoais do usuário no sistema.
Ator Principal: Usuário.
Pré-Condição: Cliente estar cadastrado no sistema.
Fluxo Principal:
1. Sistema abre campos de cadastro e senha para edição;
2. Usuário altera dados desejados;
3. Sistema salva novos dados;
4. Sistema exibe mensagem “Dados alterados com sucesso!”;
5. Sistema encerra caso de uso.
Fluxo Alternativo:
2.a Usuário não altera dados;
2.a.1 Sistema encerra caso de uso.
Fluxo de Exceção: Não há.
UC8 – Interpretar código de barras:
Descrição: Caso de uso que converte o código de barras para escala de cinza, e
interpreta-o.
Ator Principal: Sistema.
Pré-Condição: Cliente capturar um código de barras.
Fluxo Principal:
1. Sistema converte o código de barras para escala de cinza;
2. Sistema interpreta o código de barras;
80
3. Sistema chama o UC9;
4. Sistema encerra caso de uso.
Fluxo Alternativo: Não há.
Fluxo de Exceção: Não há.
UC9 – Comunicar com o banco de dados do mercado:
Descrição: Caso de uso que realiza a comunicação do sistema com o banco de
dados do supermercado.
Ator Principal: Sistema.
Pré-Condição: Cliente estar realizar a captura de um código, e ele já estar
devidamente interpretado.
Fluxo Principal:
1. Sistema comunica-se com o banco de dados do supermercado;
2. Sistema localiza produto capturado no banco;
3. Sistema encerra caso de uso.
Fluxo Alternativo: Não há.
Fluxo de Exceção:
2.a Sistema não encontra produto;
2.a.1 Sistema exibe mensagem “Produto não encontrado!”;
2.a.2 Sistema encerra caso de uso.
UC10 – Mostrar o produto escolhido na tela:
Descrição: Caso de uso que imprime as informações do produto na tela do
Smartphone.
Ator Principal: Sistema.
Pré-Condição: Capturar um código de barras de um produto existente no banco de
dados do supermercado.
Fluxo Principal:
1. Sistema imprime informações do produto;
2. Sistema encerra caso de uso.
Fluxo de Alternativo: Não há.
Fluxo de Exceção: Não há.
81
UC11 – Digitar código de barras:
Descrição: Caso de uso que permite a digitação do código de barras.
Ator Principal: Usuário.
Pré-Condição: Não há.
Fluxo Principal:
1. Sistema abre campo para digitação do código de barras;
2. Usuário digita código de barras;
3. Sistema encerra caso de uso.
Fluxo de Alternativo:
2.a Usuário não digita código de barras;
2.a.1 Sistema exibe mensagem “Digite um código de barras”
2.a.2 Sistema volta ao passo 1 do fluxo principal.
Fluxo de Exceção: Não há.
UC12 – Escolher quantidade do produto:
Descrição: Caso de uso que solicita a quantidade de produtos desejados.
Ator Principal: Usuário.
Pré-Condição: Usuário ter capturado um código de barras válido.
Fluxo Principal:
1. Sistema abre campo para digitação da quantidade;
2. Usuário informa quantidade;
3. Sistema coloca quantidade no carrinho;
4. Sistema encerra caso de uso.
Fluxo de Alternativo:
2.a Usuário não informa quantidade;
2.a.1 Sistema insere a quantidade 1 no carrinho
2.a.2 Sistema encerra caso de uso.
Fluxo de Exceção:
3.a Quantidade não disponível;
3.a.1 Sistema exibe mensagem “Quantidade indisponível”;
3.a.2 Volta ao passo 1 do fluxo principal.
UC13 – Criar um pedido:
Descrição: Caso de uso que cria um pedido.
82
Ator Principal: Sistema.
Pré-Condição: Cliente colocar ao menos 1 (um) produto no carrinho.
Fluxo Principal:
1. Sistema verifica se já há um pedido para o carrinho;
2. Sistema cria um pedido;
3. Sistema encerra caso de uso.
Fluxo de Alternativo: Não há.
Fluxo de Exceção:
2.a Já existe um pedido para o carrinho;
2.a.1 Sistema encerra caso de uso;
UC14 – Remover produto:
Descrição: Caso de uso que remove produto do carrinho.
Ator Principal: Usuário.
Pré-Condição: Haver ao menos 1 (um) produto no carrinho.
Fluxo Principal:
1. Sistema solicita confirmação de exclusão;
2. Usuário confirma exclusão;
3. Sistema exclui produto do carrinho;
4. Sistema subtrai o valor do produto excluído do valor total da compra;
5. Sistema encerra caso de uso.
Fluxo de Alternativo:
2.a Usuário não confirma exclusão;
2.a.1 Sistema encerra caso de uso.
Fluxo de Exceção: Não há.
UC15 – Ativar e desativar usuário:
Descrição: Caso de uso que ativa ou desativa um usuário.
Ator Principal: Gerente.
Pré-Condição: Usuário cadastrado no sistema.
Fluxo Principal:
1. Sistema solicita CPF do cliente;
2. Gerente informa CPF do cliente;
3. Sistema busca dados de cliente e exibe;
83
4. Sistema solicita confirmação de ativação/desativação;
5. Gerente confirma ativação/ativação;
6. Sistema ativa/desativa cliente;
7. Sistema exibe a mensagem “Realizado com sucesso!”
8. Sistema encerra caso de uso.
Fluxo de Alternativo:
2.a Gerente não informa CPF
2.a.1 Sistema exibe mensagem “Digite um CPF!”
2.a.2 Sistema volta ao passo 1 do fluxo principal.
5.a Gerente não confirma ativação/desativação;
5.a.1 Sistema encerra caso de uso;
Fluxo de Exceção:
3.a Sistema não encontra CPF;
3.a.1 Sistema exibe mensagem “CPF inválido!”;
3.a.2 Sistema volta ao passo 1 do fluxo principal.
UC16 – Selecionar 2 ou mais produtos para comparação:
Descrição: Caso de uso que permite a comparação de dois produtos.
Ator Principal: Usuário.
Pré-Condição: Usuário estar logado no sistema.
Fluxo Principal:
1. Sistema solicita código de barras dos dois produtos;
2. Usuário captura / digita os dois códigos de barras;
3. Sistema interpreta códigos de barras (chama UC8);
4. Sistema compara o preço dos dois produtos (chama UC17);
5. Sistema exibe o produto de menor preço;
6. Sistema encerra caso de uso.
Fluxo de Alternativo:
2.a Usuário não informa código de barras;
2.a.1 Sistema exibe mensagem “Insira um código de barras”;
2.a.2 Sistema volta ao passo 1 do fluxo principal.
Fluxo de Exceção:
5.a. Produtos diferentes;
84
5.a.1 Sistema exibe mensagem “Produtos distintos, selecione produtos da mesma
categoria!”;
5.a.2 Volta ao passo 1 do fluxo principal.
6.a Preços iguais;
6.a.1 Sistema exibe mensagem “Valores iguais”;
6.a.2 Sistema exibe o valor dos produtos;
6.a.3 Sistema encerra caso de uso.
UC17 – Comparar preços de um mesmo tipo de produto:
Descrição: Caso de uso que compara o preço de dois produtos.
Ator Principal: Sistema.
Pré-Condição: Usuário capturar dois tipos de produtos do mesmo tipo.
Fluxo Principal:
1. Sistema conecta-se com o banco de dados (chama UC9);
2. Sistema localiza os dois produtos;
3. Sistema compara os valores dos dois produtos;
4. Sistema encerra caso de uso.
Fluxo de Alternativo: Não há.
Fluxo de Exceção:
2.a Sistema não encontra produtos;
2.a.1 Sistema exibe mensagem “Produto não localizado”;
2.a.2 Sistema chama o UC16;
UC18 – Verificar quais produtos estão na lista:
Descrição: Caso de uso permite a visualização da lista de produtos.
Ator Principal: Usuário.
Pré-Condição: Existir ao menos um produto no carrinho do usuário.
Fluxo Principal:
1. Sistema solicita confirmação de exibição de lista;
2. Usuário confirma a exibição;
3. Sistema exibe a lista de produtos do carrinho (chama UC20);
4. Sistema encerra caso de uso.
Fluxo de Alternativo:
2.a Usuário não confirma exibição;
85
2.a.1 Sistema encerra caso de uso;
Fluxo de Exceção: Não há.
UC 19 – Finalizar compra
Fluxo Principal:
1. Sistema pergunta se usuário deseja finalizar a compra;
2. Usuário informa que deseja finalizar a compra;
3. Sistema imprime todos os produtos na tela (chama UC20);
4. Sistema solicita confirmação dos produtos exibidos;
5. Usuário confirma a lista exibida;
6. Sistema solicita confirmação de endereço de entrega (chama UC21);
7. Sistema exibe valor total;
8. Sistema solicita forma de pagamento (chama UC22);
9. Sistema exibe número do pedido para o usuário;
10.
Sistema encaminha todos os dados da compra para o supermercado (chama
UC23);
11.
Sistema armazena no carrinho de produtos freqüente (chama UC24);
12.
Sistema encerra caso de uso;
Fluxo Alternativo
2.a Usuário não deseja finalizar a compra
2.a.1 Chama UC6;
2.a.2 Sistema encerra caso de uso;
5.a Usuário não confirma a lista exibida
5.a.1 Sistema reabre carrinho para exclusão de produtos (chama UC15);
5.a.2 Sistema encerra caso de uso;
Fluxo de exceção: Não há.
UC20 – Mostrar todos os produtos na tela.
Descrição: Caso de uso mostra todos os produtos do carrinho.
Ator Principal: Sistema.
Pré-Condição: Existir ao menos um produto no carrinho.
Fluxo Principal:
1. Sistema busca produtos no carrinho;
2. Sistema localiza dados dos produtos no banco de dados;
86
3. Sistema exibe informações dos produtos;
4. Sistema encerra caso de uso.
Fluxo de Alternativo: Não há.
Fluxo de Exceção:
2.a Lista vazia;
2.a.1 Sistema exibe mensagem “Não há produtos a serem exibidos”;
2.a.2 Sistema encerra caso de uso;
UC21 – Confirmar endereço de entrega:
Descrição: Caso de uso que solicita confirmação do endereço de entrega.
Ator Principal: Sistema.
Pré-Condição: Usuário finalizar uma compra.
Fluxo Principal:
1. Sistema exibe endereços cadastrados;
2. Sistema solicita a seleção de um endereço de entrega;
3. Usuário seleciona um endereço de entrega;
4. Sistema solicita confirmação do endereço de entrega;
5. Usuário confirma endereço de entrega;
6. Sistema encerra caso de uso.
Fluxo de Alternativo:
3.a Usuário não seleciona um endereço de entrega;
3.a.1 Sistema exibe a mensagem “Selecione um endereço de entrega!”;
3.a.2 Sistema volta ao passo 1 do fluxo principal.
5.a Usuário não confirma endereço;
5.a.1 Sistema pergunta se usuário deseja inserir novo endereço;
5.a.2 Usuário informa que deseja inserir novo endereço;
5.a.3 Sistema chama UC7 – “Alterar dados cadastrais”;
5.a.4 Sistema encerra caso de uso.
Fluxo de Exceção: Não há.
UC 22 – Informar forma de pagamento:
Descrição: Caso de uso que solicita ao usuário a forma de pagamento da compra
realizada.
Ator Principal: Usuário.
87
Pré-Condição: Finalizar uma compra.
Fluxo Principal:
1. Sistema imprime formas de pagamentos disponíveis;
2. Sistema solicita a forma de pagamento desejado;
3. Usuário informa forma de pagamento;
4. Sistema solicita a confirmação da forma de pagamento;
5. Usuário confirma a forma de pagamento;
6. Sistema encaminha os dados do pagamento ao supermercado (chama UC23);
7. Sistema encerra caso de uso.
Fluxo Alternativo:
3.a Usuário não seleciona forma de pagamento:
3.a.1 Sistema exibe a mensagem “Selecione uma forma de pagamento”;
3.a.2 Volta ao passo 1 do Fluxo Principal.
5.a Usuário não confirma forma de pagamento:
5.a.1 Volta ao passo 1 do Fluxo Principal.
Fluxo de Exceção: Não há.
UC 23 – Enviar dados ao mercado:
Descrição: Caso de uso que envia os dados das compras ao supermercado.
Ator Principal: Sistema.
Pré-Condição: Finalizar uma compra.
Fluxo Principal:
1. Sistema envia mensagem ao supermercado “Novo pedido”;
2. Sistema encaminha dados do cliente e do pedido ao supermercado;
3. Sistema encerra caso de uso.
Fluxo Alternativo: Não há.
Fluxo de Exceção: Não há.
UC24 – Manter carrinho de compras freqüente:
Descrição: Caso de uso que atualiza carrinho de compras, guardando as ultimas
aquisições do usuário.
Ator Principal: Sistema.
Pré-Condição: Existir ao menos uma compra finalizada do usuário.
88
Fluxo Principal:
1. Sistema armazena as informações da compra atual do usuário;
2. Sistema disponibiliza as últimas compras do usuário para eventuais aquisições
semelhantes;
3. Sistema encerra caso de uso.
Fluxo de Alternativo: Não há.
Fluxo de Exceção: Não há.
UC25 – Verificar compras realizadas:
Descrição: Caso de uso que permite ao gerente verificar as compras realizadas.
Ator Principal: Gerente.
Pré-Condição: Existir compras finalizadas.
Fluxo Principal:
1. Sistema exibe lista de pedidos finalizados;
2. Sistema solicita a seleção de um pedido;
3. Gerente seleciona um pedido;
4. Sistema exibe informações do pedido (chama UC10);
5. Sistema encerra caso de uso.
Fluxo de Alternativo:
3.a Gerente não seleciona um pedido;
2.a.1 Sistema exibe mensagem “Selecione um pedido”
2.a.2 Sistema volta ao passo 1 do fluxo principal.
Fluxo de Exceção: Não há.
UC 26 – Cancelar compra:
Descrição: Caso de uso que permite o cancelamento de uma compra.
Ator Principal: Gerente.
Pré-Condição: Existir uma venda finalizada.
Fluxo Principal:
1. Sistema solicita motivo de cancelamento;
2. Gerente informa motivo de cancelamento;
3. Sistema solicita a confirmação do cancelamento;
4. Gerente confirma o cancelamento;
5. Sistema Cancela a venda (chama UC27);
89
6. Sistema exibe mensagem “Compra Cancelada!”;
7. Sistema encerra caso de uso.
Fluxo Alternativo:
4.a Gerente não confirma o cancelamento:
4.a.1 Sistema exibe a mensagem “Cancelamento não efetuado!”;
4.a.2 Sistema encerra caso de uso.
Fluxo de Exceção: Não há.
UC 27 – Gerar cancelamento:
Descrição: Caso de uso que cancela uma compra.
Ator Principal: Sistema.
Pré-Condição: Gerente solicitar cancelamento.
Fluxo Principal:
1. Sistema retira os produtos do carrinho;
2. Sistema atualiza o status do pedido para “Cancelado”;
3. Sistema encerra caso de uso.
Fluxo Alternativo: Não há.
Fluxo de Exceção: Não há.
UC 28 – Escolher se deseja receber promoções:
Descrição: Caso de uso que permite ao usuário receber promoções do
supermercado.
Ator Principal: Usuário.
Pré-Condição: Usuário possuir cadastro.
Fluxo Principal:
1. Sistema questiona se usuário deseja receber promoções;
2. Usuário informa que deseja receber promoções;
3. Sistema exibe mensagem “Ok!”;
4. Sistema exibe promoções (chama UC29);
5. Sistema encerra caso de uso.
Fluxo Alternativo:
2.a Usuário não deseja receber promoções:
2.a.1 Sistema exibe a mensagem “Ok!”;
2.a.2 Sistema encerra caso de uso.
90
Fluxo de Exceção: Não há.
UC 29 – Mostrar promoções:
Descrição: Caso de uso que exibe as promoções disponíveis para o usuário.
Ator Principal: Sistema.
Pré-Condição: Usuário desejar receber promoções.
Fluxo Principal:
1. Sistema verifica promoções disponíveis no supermercado;
2. Sistema encaminha mensagem com promoções disponíveis;
3. Sistema encerra caso de uso.
Fluxo Alternativo: Não há.
Fluxo de Exceção:
2.a Não há promoções disponíveis:
2.a.1 Sistema exibe a mensagem “Não há promoções disponíveis!”;
2.a.2 Sistema encerra caso de uso.
UC30 – Traçar perfil do usuário:
Descrição: Caso de uso que traça o perfil do usuário de acordo com suas
aquisições.
Ator Principal: Sistema.
Pré-Condição: Usuário já possuir compras no supermercado, e desejar traçar perfil.
Fluxo Principal:
1. Sistema compara as últimas compras do usuário;
2. Sistema verifica maiores aquisições do usuário;
3. Sistema traça o perfil do cliente de acordo com as aquisições;
4. Sistema encerra caso de uso.
Fluxo de Alternativo: Não há.
Fluxo de Exceção:
2.a Não há aquisições;
2.a.1 Sistema exibe mensagem “Perfil não traçado”;
2.a.2 Sistema encerra caso de uso.
91
UC 31 – Escolher se quer que trace seu perfil:
Descrição: Caso de uso que questiona ao cliente se é desejado traçar um perfil de
consumidor.
Ator Principal: Usuário
Pré-Condição: Usuário estar cadastrado e logado no sistema.
Fluxo Principal:
1. Sistema questiona de usuário deseja traçar um perfil;
2. Usuário informa que deseja traçar perfil;
3. Sistema traça o perfil do cliente, sempre que ele se logar (chama UC30);
4. Sistema exibe a mensagem “Obrigado!”;
5. Sistema encerra caso de uso.
Fluxo Alternativo:
2.a
Usuário não deseja traçar seu perfil:
2.a.1 Sistema exibe a mensagem “Perfil não traçado!”;
2.a.2 Sistema encerra caso de uso.
Fluxo de Exceção: Não há.
92
C PROJETO DO BANCO DE DADOS
Figura 27 - Projeto do banco de dados do software SmartCompras. Fonte: O AUTOR (2011)
93
D DIAGRAMAS DE ATIVIDADES
Figura 28 - Diagrama de Atividade - UC6. Fonte: O AUTOR (2011)
94
Figura 29 - Diagrama de Atividade – UC19. Fonte: O AUTOR (2011)
95
Figura 30 - Diagrama de Atividade - UC22. Fonte: O AUTOR (2011)
96
Figura 31 - Diagrama de Atividade - UC26. Fonte: O AUTOR (2011)
97
Figura 32 - Diagrama de Atividade - UC31. Fonte: O AUTOR (2011)
98
E DIAGRAMA DE SEQUÊNCIA
Figura 33 - Diagrama de Seqüência- UC6. Fonte: O AUTOR (2011)
99
Figura 34 - Diagrama de Seqüência- UC19. Fonte: O AUTOR (2011)
100
Figura 35 - Diagrama de Seqüência- UC22. Fonte: O AUTOR (2011)
101
Figura 36 - Diagrama de Seqüência- UC26. Fonte: O AUTOR (2011)
102
Figura 37 - Diagrama de Seqüência- UC31. Fonte: O AUTOR (2011)
103
F REQUISITOS DO CELULAR UTILIZADO NO TESTE:
SAMSUNG GALXY 5;
Tecnologia
Quad Band (850 + 900 + 1800 + 1900 MHz)
3G: UMTS (850 / 2100 MHz)
GPRS disponível
EDGE disponível
3G disponível
Navegador da Internet (WAP 2.0 / xHTML, HTML)
Valores SAR: 0.484 W/kg corpo e 0.601 W/kg cabeça
Bateria
Capacidade da Bateria: 1200 mAh
Tempo de conversa: 2G: até 9 h, tempo de conversação
Tempo em Standby: até 500 horas
Câmera
Câmara 2.0 megapixels
Zoom digital 4x
Display
TFT
Resolução: 240 X 320
Tamanho da tela: 2,8";
Vídeo
Vídeo Player disponível
Gravador de Vídeo disponível
Streaming de Vídeo disponível
Conectividade
Bluetooth integrado
WAP disponível
USB disponível
Navegador HTML disponível
Wi-Fi (802.11 b/g)
GPS disponível
Aplicação PC Sync disponível
USB Mass Storage disponível
Tamanho
Peso: 102 g
Dimensões: 111,8 x 46,9 x 13,3mm
Interface com Usuário
Touch Screen
Memória
Memória para SMS de 100MB
Entradas de lista telefônica até memória
Memória Externa (microSD de 2 GB).
104
G TELAS DO SISTEMA
- Cadastro
A realização do cadastro foi efetuada através de três telas, apresentadas
abaixo nas figuras 38, 39 e 40:
Figura 38 - Primeira tela de cadastro do SmartCompras. Fonte: O AUTOR (2011)
Figura 39 - Segunda tela de cadastro do SmartCompras. Fonte: O AUTOR (2011)
105
Figura 40 - Terceira e última tela de cadastro do SmartCompras. Fonte: O AUTOR (2011)
- Login
O login do sistema é feito a partir de um usuário e senha pré cadastrados,
como pode ser visto na figura 41.
Figura 41 - Tela de login do SmartCompras. Fonte: O AUTOR (2011)
- Página Principal
Na página principal do sistema são exibidas as funcionalidades disponíveis no
SmartCompras, como mostra a figura 42.
106
Figura 42 - Tela Principal do SmartCompras. Fonte: O AUTOR (2011)
- Compra
Uma compra é realizada a partir de diversas etapas, como mostram as figuras
43 a 46.
Figura 43 - Tela para digitar o código de barras. Fonte: O AUTOR (2011)
Figura 44 - Tela de detalhe do produto. Fonte: O AUTOR (2011)
107
Figura 45 - Tela do carrinho de compras. Fonte: O AUTOR (2011)
Figura 46 - Tela para escolha da forma de pagamento. Fonte: O AUTOR (2011)