Luis Fernando Krause, Julio Cesar Sartori Neto, Pietro Zuchinali - GSE

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SULFACULDADE DE ENGENHARIA - FENGAUTOMAÇÃO DE ATENDIMENTO EM RESTAURANTESTRABALHO DE CONCLUSÃO DE CURSOENGENHARIA DA COMPUTAÇÃOJúlio César Sartori Neto.Luís Fernando Krause.Pietro Zuchinali.Orientador: Professor Eduardo Augusto Bezerra.Porto Alegre, 30 de novembro de 2007

RESUMOEste trabalho trata sobre automação comercial, tomando como objetivo aautomação no atendimento à clientes em restaurantes. O projeto descrito nestedocumento visa agilizar os processos e aumentar a confiabilidade no fluxo de informaçõesentre os diferentes setores de um restaurante.Para isto é proposto a implementação de dois sistemas. O primeiro utiliza terminaisPOS para a comunicação e interface com o cliente, e o segundo utiliza smartphones, osquais pertencem aos próprios clientes.2

SUMÁRIO1. Introdução. ...........................................................................................................51.1. Motivação.................................................................................................61.2. Objetivos..................................................................................................71.3. Organização do Texto. ............................................................................72. Análise e Identificação de Requisitos. .................................................................92.1. Funcionamento Normal de um Restaurante. ..........................................102.1.1. Abrir Caixa...................................................................................102.1.2. Fechar Caixa. ..............................................................................102.1.3. Reserva de Mesa. .......................................................................112.1.4. Atendimento ao Cliente Presencial com Reserva. .....................112.1.5. Atendimento ao Cliente Presencial.............................................122.2. Requisitos do Sistema.............................................................................133. Tecnologias Estudadas........................................................................................153.1. Dispositivos de Coleta de Dados.............................................................153.2. Criptografia. .............................................................................................173.3. Linguagens de Programação. .................................................................183.3.1. WML. ...........................................................................................183.3.2. Object Pascal. .............................................................................193.3.3. SQL. ............................................................................................193.3.4. J2ME (Java 2 Micro Edition). ......................................................193.4. Ferramentas de Desenvolvimento. .........................................................193.4.1. Delphi. .........................................................................................193.4.2. Servidor Apache..........................................................................203.4.3. Ambiente de Desenvolvimento do POS. ....................................203.4.4. Ambiente de Desenvolvimento da Aplicação Wireless. .............214. Sistema Proposto.................................................................................................234.1. Fluxo Básico do Sistema Proposto. ........................................................254.2. POS como Dispositivo para Entrega de Dados. .....................................264.3. Smartphone como Dispositivo para Entrega de Dados. .........................275. Aplicações Desenvolvidas. ..................................................................................295.1. Aplicação Delphi – Cozinha e Recepção. ...............................................295.1.1. Aplicação Garçom Eletrônico......................................................295.1.2. Aplicação Mediator......................................................................335.1.3. Configuração Inicial.....................................................................365.1.4. Aplicação WML – Terminal POS ................................................365.2. Aplicação Java – Smartphones...............................................................393

5.3. Aplicação J2ME – Smartphone. ..............................................................405.3.1. Introdução do J2ME no Processo...............................................415.3.2. Funcionamento e Implementação da Midlet J2ME. ...................415.4. Modelagem do Banco de Dados. ............................................................445.5. Futuras e Possíveis Expansões. .............................................................466. Conclusão. ...........................................................................................................487. Bibliografia............................................................................................................50ANEXO1 .....................................................................................................................52ANEXO2 .....................................................................................................................534

A Pekus [7] oferece um software para PDA [12] voltado para utilização emrestaurantes. Através de uma conexão wireless, o garçom pode realizar as seguintesoperações:- Abertura e fechamento de mesa;- Abertura e envio de pedidos eletronicamente;- Transferência de pedidos entre as mesas;- Posição dos clientes na mesa;- Pedidos combinados;- Preferências do cliente;- Pedido por descrição e código;- Resumo de conta.Este tipo de sistema ainda necessita da atuação mais ativa dos garçons, bem comoo treinamento dos mesmos. Para efetuar o registro das preferências do cliente talvez fossemais eficiente e prático que o garçom anotasse tais preferências em um bloquinho, daforma mais tradicional. Sendo assim, na hora de realizar o pedido, o cliente iria solicitar,por exemplo, uma carne mal passada ou um refrigerante com limão e gelo. Tais detalhesnão entrariam no registro via PDA, e sim da forma tradicional, em um bloco de notas, queposteriormente seria complementado ao pedido, junto à cozinha.Outro fator que pesa negativamente é o alto custo de um PDA, o que pode tornar asolução muito cara para implantação.A implementação descrita neste documento pretende unir as características maisfortes desses sistemas existentes e incluir melhoras nos pontos mais fracos dos mesmos.1.1 MOTIVAÇÃOObservando as necessidades de controle dos processos envolvidos nofuncionamento de restaurantes, foi identificada a necessidade de sistemas autônomos decontrole de forma a agilizar a comunicação entre os agentes desenvolvidos nos mesmos.O processo de automação, de um modo geral, está se tornando muito utilizado emum número cada vez maior de estabelecimentos, dos mais variados tipos. De acordo como IBGE [10]: “...Além do desempenho positivo do segmento de equipamentos para ossetores elétrico e de telecomunicações, em processo de privatização, houve aumento dedemanda por equipamentos dedicados a automação industrial e de escritório e para asindústrias de extração mineral e de construção, devido ao processo de modernizaçãoimplementado pelas empresas.”Isso se deve principalmente a necessidade de acompanhamento das tendências domercado de cada vez mais tentar automatizar processos, visando agilidade e corte de7

custos e dos consumidores em um atendimento cada vez mais rápido e de grandequalidade.Tendo em vista esses fatores resolveu-se estudar o funcionamento básico de umrestaurante, buscando entender os principais pontos onde a automação de processospudesse melhorar o atendimento aos clientes de uma forma geral, o que proporcionouuma visão clara da análise de requisitos e processos não somente técnicos, mas tambémespecifico da área de atuação onde o trabalho foi desenvolvido.A partir desta análise prévia, usando uma gama de conhecimentos adquiridos nocurso superior de Engenharia da Computação, formalizou-se a implementação de umsistema para automação das atividades de gestão de um restaurante.1.2 OBJETIVOSO objetivo geral desse trabalho é projetar e desenvolver um sistema paraautomatizar os processos presentes no atendimento aos clientes em um restaurante,fornecendo um ganho em eficiência e confiabilidade.De forma a alcançar o objetivo geral, foram definidos os seguintes objetivosespecíficos:• Entender o funcionamento básico de um restaurante típico;• Analisar modelos de negócios existentes;• Estudar tecnologias envolvidas referentes a aplicações de automação emestabelecimentos comerciais de um modo geral, de forma a selecionar aquelasque melhor se enquadram no projeto;• Modelar a arquitetura do sistema, incluindo a base de dados, e o fluxo deinformações existentes nos processos, assim como o protocolo de comunicação aser adotado;• Escolher o hardware e o ambiente de desenvolvimento de software mais adequadopara a implantação;• Implementar a solução proposta;• Analisar os resultados obtidos.1.3 ORGANIZAÇÃO DO TEXTOEsta documento está dividido em 6 capítulos, que estão detalhados logo abaixo:O capítulo um é composto por introdução, objetivos e organização do texto.No capítulo dois é feita uma análise de requisitos e estudo de caso dofuncionamento de um restaurante típico.O capítulo três descreve as tecnologias empregadas, estudo de criptografia eferramentas de desenvolvimento utilizadas.8

O capítulo quatro aborda o funcionamento detalhado do sistema proposto.O capítulo cinco apresenta as aplicações que foram desenvolvidas.Os capítulos seis e sete possuem as considerações finais e bibliografiarespectivamente.9

2 ANÁLISE E IDENTIFICAÇÃO DE REQUISITOSNo desenvolvimento de uma solução para automatizar os processos envolvidos noatendimento de clientes em restaurantes, é necessária a compreensão das atividadesrealizadas pela equipe que trabalha nos restaurantes, desde os garçons, passando peloscozinheiros e chegando até o funcionário encarregado de operar o caixa.A análise deste processo aliada ao estudo de caso de soluções desenvolvidas com omesmo propósito permite identificar os requisitos, equipamentos e tecnologias utilizadaspelo mercado de soluções de automação.A comparação destes dados possibilita a determinação de um planejamento inicialda solução aqui proposta em termos de arquitetura, dispositivos e serviços a seremdesenvolvidos. Na Figura 1 são ilustrados os agentes envolvidos no processo.Figura 1 – Agentes Envolvidos no Processo.10

2.1 FUNCIONAMENTO NORMAL DE UM RESTAURANTEDe forma a identificar os principais pontos de melhoria no atendimento de clientesem restaurantes foi realizado estudo prévio sobre o funcionamento normal de umrestaurante típico.Como funcionamento normal, defini-se os seguintes passos: abertura de caixa,fechamento de caixa, reserva de mesa, atendimento com reserva e atendimento ao clientepresencial. As seções a seguir descrevem as atividades identificadas.2.1.1 ABRIR CAIXAEsta é a etapa inicial no processo de operação de um restaurante. É necessáriapara fazer o controle financeiro do estabelecimento.Antes de iniciar um atendimento, o operador de caixa registra-se no sistema einforma que começará a realizar novas transações. Para isso, ele registra a quantia emdinheiro que possui em caixa ao iniciar e efetua o login no sistema com seu id(identificação pessoal), que, por sua vez, deve estar habilitado para efetuar tal operação. Oprocesso é demonstrado na Figura 2.Figura 2 – Abertura de Caixa.2.1.2 FECHAR CAIXAComo demonstrado na Figura 3, esta é a etapa final no processo de operação de umrestaurante. Ao final do dia, ou a qualquer momento conforme a necessidade, oresponsável pelo estabelecimento realiza o fechamento de todos os caixas abertos norestaurante, conferindo o movimento.Na conferência, leva-se em consideração o valor que o caixa possuía ao ser aberto eas transações realizadas durante o dia. Caso os valores estejam corretos, o caixa éfechado e as transações do dia são armazenadas para geração de relatórios emovimentação contábil.11

Figura 3 – Fechamento do Caixa.2.1.3 RESERVA DE MESAEsta operação ocorre quando o cliente informa antecipadamente que deseja usufruirde algum dos recursos do restaurante em um momento pré-determinado.Para tanto, o cliente entra em contado com o estabelecimento e solicita aoresponsável a reserva de determinado recurso por algum tempo, informando a hora quedeseja fazer a utilização, quais recursos deseja utilizar e quando tempo será necessário.De posse destas informações, o responsável reserva os recursos conforme osolicitado.2.1.4 ATENDIMENTO AO CLIENTE PRESENCIAL COM RESERVANesta etapa, descrita na Figura 4, na chegada ao estabelecimento, o cliente informaque já havia realizado reserva anteriormente. O responsável verifica a validade da reserva,e em caso de reserva efetuada, o cliente é levado à mesa reservada de forma rápida eágil, evitando qualquer tipo de transtorno.Em seguida, é atendido conforme descrito no próximo item referente a atendimento acliente presencial.Figura 4 – Atendimento Presencial ao Cliente com Reserva.12

2.1.5 ATENDIMENTO AO CLIENTE PRESENCIALNesta operação o garçom possui papel de grande importância, pois este gerencia ainteração entre os clientes e os recursos disponíveis no restaurante. É principalmenteneste momento que o processo de automação propõe facilitar a troca de informações.Primeiramente o garçom encaminha o cliente a alguma mesa vaga. Em seguida, ogarçom oferece o cardápio e faz sugestões sobre os pratos, quando solicitado. O clienteentão efetua o pedido ao garçom, que por sua vez, de posse dessas informações,encaminha à cozinha e ao caixa os dados sobre a solicitação. O cancelamento de algumpedido também utiliza o mesmo procedimento Cliente – Garçom – Cozinha.A cozinha, conforme demanda de pedidos, elabora os pratos e informa ao garçomquando tais pratos estiverem prontos, para que o garçom possa servi-los aos clientes. Ooperador do caixa, por sua vez, abre a conta do cliente e armazena os dados referentes atodos pedidos da mesa em questão. A qualquer momento o cliente pode solicitar um novopedido ou um cancelamento do mesmo.Ao final o cliente solicita a conta e o garçom informa ao operador do caixa sobre asolicitação, que gera um relatório de pedidos e seus respectivos valores para serencaminhado ao cliente. O garçom encaminha os dados ao cliente, que, de posse destasinformações, informa a forma de pagamento ao garçom juntamente com o pagamento. Ogarçom então leva os valores ao operador do caixa que, por sua vez, fecha a conta eretorna a nota fiscal e o troco, quando necessário. O garçom então entrega a nota fiscal eo troco ao cliente e o dirige a saída se necessário, fechando assim o fluxo de atendimento.Todo esse processo está demonstrado na Figura 5.13

Figura 5 – Atendimento Presencial.2.2 REQUISITOS DO SISTEMAVisando a implementação do sistema proposto, alguns requisitos precisam seranalisados para que o processo de automação seja bem sucedido e possa serfacilmente compreendido e assimilado por todas as partes envolvidas (garçons,cozinheiros, gerentes, caixas, etc...)• Custo de aquisição de equipamentos ou sistemas de gerenciamento quepermitam a automação e controle dos processos envolvidos. Neste caso épreciso avaliar a relação custo-benefício que a automação irá trazer aoestabelecimento e também fazer uma pré-avaliação para saber quaisresultados são esperados;• Campo de abrangência da aplicação. É necessário ter em mente quaisobjetivos pretende-se obter. Deste modo pode-se avaliar os resultadosobtidos e verificar a real eficiência do sistema implementado;• Validade de Aplicação. Estudo sobre a viabilidade de usar um sistema deautomação no estabelecimento em questão. Para isso é necessário fazer14

um estudo sobre o público alvo, expectativas dos clientes e adaptabilidadepor parte dos funcionários;• Tecnologias envolvidas. Verificar quais tecnologias melhor atendem aoobjetivo escolhido e também quais opções existem no mercado, analisandovantagens e desvantagens;• Mão de obra presente no mercado. Este quesito é bastante importante,pois é dele que depende o desenvolvimento da aplicação, bem comomanutenção e treinamento dos funcionários.15

3 TECNOLOGIAS ESTUDADASPara viabilizar a construção do projeto, foi realizada uma pesquisa envolvendodiversas tecnologias existentes no mercado, e foram selecionadas as que mais seadequavam as necessidades específicas da aplicação, bem como as que oferecessemmenor custo, principalmente em termos de tempo de implementação, dando preferência astecnologias em que já existisse algum tipo de know-how por parte dos integrantes doprojeto.As mais importantes tecnologias estudadas são apresentadas neste capítulo.3.1 DISPOSITIVOS DE COLETA DE DADOSPersonal Digital Assistant (PDA ou Handheld) consiste em um computadorportátil e de tamanho reduzido, dotado de capacidade computacional razoável para umsistema embarcado. Este dispositivo oferece ainda a possibilidade de comunicação comum computador pessoal através de uma conexão de rede sem fios para acesso a serviçoscomo correio eletrônico e internet.Para o sistema proposto, o poder de processamento fornecido por um PDA seriadesnecessário. A utilização desse tipo de equipamento nas atividades previstas poderiaser considerada um desperdício de recursos. O custo destes equipamentos é umimportante fator a ser considerado, o que acabaria inviabilizando o objetivo aqui propostode criar um sistema de baixo custo e de fácil utilização. Um exemplo de PDA pode servisto na Figura 6.Figura 6 – PDA.POS (Point of Service) é um tipo de terminal utilizado normalmente emestabelecimentos comerciais como sistema de pagamento com cartão de débito. Esteequipamento utiliza linhas telefônicas para comunicação e impressora para emitir16

comprovantes de pagamento. Na Figura 7 pode-se observar um exemplo deste tipo determinalO equipamento POS, da empresa Verifone [18], disponibiliza uma camada desoftware em arquitetura semelhante a da WEB, que funciona em conjunto com o sistemado POS, resultando em uma maior facilidade e agilidade no desenvolvimento deaplicações para esse dispositivo. Esse é um grande diferencial em relação aequipamentos de outros fabricantes, os quais o processo de desenvolvimento possui umamaior dependência e especificidade.A facilidade de desenvolvimento no modelo Web do POS, da Verifone, transformaesse equipamento em uma ferramenta geradora de negócios, funcionando como terminalbancário, aceitando o pagamento de contas e diversas outras funções, agregando, assim,novos valores, tais como agilidade, segurança, facilidade de desenvolvimento eflexibilidade, além de boa relação entre custo e benefício.Esses fatores levaram a considerar o terminal POS, da Verifone, como uma dastecnologias a ser utilizada na realização do projeto. A oportunidade de desenvolver aaplicação embarcada em um nível alto de abstração (WEB) e a possibilidade defuturamente expandir a aplicação afim de oferecer ao cliente outras funcionalidades comopor exemplo pagamento da conta na própria mesa e impressão da nota fiscal pelo próprioterminal foram fatores que pesaram nesta decisão.Figura 7 – Terminal POS da Verifone.O smartphone é outro dispositivo estudado que, de forma semelhante ao PDA,também apresenta um alto custo. É um equipamento que alia funcionalidades da telefoniacelular, ou seja, comunicação móvel, com recursos computacionais bastante interessantespara a aplicação proposta. As principais são: sistema operacional embarcado, acesso aredes wireless, possibilidade de rodar aplicações Java, mobilidade, facilidade deconfiguração e flexibilidade.17

Além de suas funcionalidades, “...o comércio global de smartphones irá crescer auma taxa anual de cerca de 30% nos próximos cinco anos, de acordo com dados dorelatório do instituto de pesquisas da In-Stat [17] “, empresa de pesquisa e consultoriaespecialista na área de comunicação. Segundo estes dados, as vendas em unidades desmartphones vão exceder as de notebook até o ano de 2012.Estes dados são bastante interessantes, pois para que os smartphones sejam umatecnologia adequada a nossa aplicação, existe a necessidade de que o número de clientesque possuam a tecnologia seja suficientemente grande afim de viabilizar o projeto. Devidoa estes fatores, o smartphone é uma tecnologia alvo do projeto em questão..Na Figura 8, são apresentados os dois principais modelos que foram utilizadoscomo base para o desenvolvimento da aplicação.Motorola Q Nokia N 95Figura 8 – Modelos de SmartPhone.Esses são os dois principais modelos presentes no mercado, que possuemacesso a redes sem fio, requisito básico para a aplicação implementada.3.2 CRIPTOGRAFIAPara garantir a transmissão segura de dados entre os terminais da rede dorestaurante a ser automatizado, verificou-se a necessidade de utilizar criptografia paracodificar e decodificar a troca de mensagens. Mesmo considerando o caráter poucoconfidencial da informação que irá trafegar na rede interna do restaurante (pedidos, evalores de contas, por exemplo), criptografia é sempre um assunto essencial que deve serlevado em conta quando se trabalha com redes e tráfego de informações.Dois protocolos foram estudados como possíveis soluções no trato deinformações com criptografia:• DES (Data Encrypt Standard) [5]: Foi desenvolvido na década de 70 com opropósito de criar um método padrão para proteção de dados confidencias. Em1976 o DES tornou-se norma federal do governo Norte Americano. O DES realizaduas funções básicas sobre a entrada de dados: shift (deslocamento) nos bits e18

substituição de bits. Essas ações são norteadas pela chave de criptografia. Oalgoritmo trabalha com 64 bits, que podem ser modificados de 1 a 16 vezes. Essealgoritmo pode ser usado tanto na comunicação do POS, quanto em um sistemadesenvolvido para smartphone.• WPA – PSK (Wifi Protected Access) [5]: Este protocolo implementa umacriptografia bastante robusta através da troca constante e automática de chaves(rechaveamento). Estas chaves são autenticadas e testadas entre os dispositivosque estão se comunicando em períodos de tempos determinados ou após certaquantidade de bits terem sido trocados. Esse período é chamado de “período derechaveamento”. O protocolo veio em substituição ao WEP (Wireless EquivalentPrivacy), e é encontrado em roteadores wireless e access points. Também é defácil configuração. Esse algoritmo pode ser utilizado em um smartphone.Apesar do estudo, não foi realizado o desenvolvimento prático das funcionalidadesde criptografia. Foi verificado, inclusive, que o terminal POS utilizado no desenvolvimento,apresentava uma biblioteca de alto nível para troca de informações criptografadas comalgoritmo DES. Porém, seria necessária a implementação de um decodificador naaplicação em execução nos Desktops que realizam a troca de mensagens com osterminais de atendimento. A implementação da criptografia fica como uma sugestão parafutura expansão e melhoria do projeto proposto.3.3 LINGUAGENS DE PROGRAMAÇÃO3.3.1 WMLO protocolo WAP - Wireless Application Protocol [3] – é utilizado em redes sem fio,onde telefones, celulares, pagers e computadores de mão acessam a Web recebendo eenviando informações. O Wap utiliza a linguagem WML[3] ou Wireless Markup Language,que é uma linguagem de programação utilizada para desenvolvimento de páginas Web emdispositivos e equipamentos que fazem uso da tecnologia. Seu padrão é praticamenteigual ao XML, com definições de tags e funções semelhantes.O terminal POS, da Verifone, utiliza esta linguagem em sua programação,oferecendo o acesso aos dispositivos periféricos presentes no aparelho através debibliotecas previamente implementadas que podem ser acessadas através da linguagemWMLS (Wireless Markup Language Script). As regras de sintaxe, variáveis e elementosusadas nestas tags estão definidas no documento de definição de tipos (DTD) elaboradopelo consórcio responsável pela WML.Os scripts WMLS utilizados para o acesso ao hardware, também podem serutilizados para adicionarmos funcionalidades relativas a conexões de rede egerenciamento de bancos de dados.19

3.3.2 OBJECT PASCALObject Pascal [20] é uma extensão da linguagem de programação Pascal, visandoo suporte a programação orientada à objetos. Esta é a linguagem nativa utilizada paraprogramação no ambiente de desenvolvimento de aplicativos Delphi, descrito a seguir.3.3.3 SQLSQL [20] é a sigla para Structured Query Language, que em português significa“Linguagem de Consulta Estruturada”. Trata-se de uma linguagem padrão para criação,manipulação e consulta de objetos de bancos de dados relacionais, como o Oracle [21] e oInterbase [22], por exemplo.Devido a necessidade de armazenar as informações relativas às vendas, pedidos declientes, itens do cardápio, entre outras, é importante a utilização da linguagem SQL paraestruturar a base de dados e gerenciá-la posteriormente.O banco de dados selecionado para a realização deste trabalho foi o Interbasedevido a sua simplicidade e pelo fato de já ser suportado pelo Delphi [20] e por outraslinguagens como o PHP.3.3.4 J2ME (Java 2 Micro Edition )J2ME [14] é uma tecnologia que define um ambiente que suporta a linguagemJava [14] em dispositivos móveis e que possuem acesso via conexão wireless, tais comosmartphones, PDAs, NoteBooks, Pagers.Por ser código aberto, o J2ME torna-se de fácil acesso a compiladores e ambientesde simulação. Também existe disponível uma quantidade considerável de material deajuda e tutoriais sobre o assunto.3.4 FERRAMENTAS DE DESENVOLVIMENTO3.4.1 DELPHIDelphi é um ambiente de desenvolvimento integrado (IDE) para softwaresaplicativos. A sua utilização no nosso projeto surgiu da necessidade de realizar aprogramação dos computadores de acesso da cozinha, da recepção e de tornar a interfacecom o usuário da aplicação o mais clara, simples e amigável possível. Alguns dos pontosfortes do Delphi são a alta produtividade associada e flexibilidade para reutilizarcomponentes que podem acessar diversos tipos de serviços, tais como conexões combancos de dados relacionais. A linguagem utilizada pelo Delphi é o Object Pascal, umalinguagem razoavelmente simples e intuitiva.20

Uma importante motivação para utilização de Delphi é o grande número deprogramadores disponíveis no mercado com conhecimento da ferramenta.Como os componentes do grupo já possuíam afinidade com o ambiente Delphi edevido a unanimidade deste ser um ambiente mais produtivo para este tipo de aplicação,decidiu-se optar por este ambiente para utilização neste trabalho.3.4.2 SERVIDOR APACHEO equipamento POS ,da empresa Verifone, é uma das opções de terminal para osclientes do sistema proposto. Para armazenar as informações e as páginas WML com asquais o terminal trabalha, é necessário utilizar um servidor Web.A escolha do Apache [23] como servidor neste projeto se deve ao fato de ser o maisutilizado e difundido servidor Web, por ser de fácil utilização e possuir bastantedocumentação. A instalação é uma tarefa relativamente simples, uma vez que bastaconfigurar alguns arquivos de inicialização para que ele suporte WML.No caso da aplicação sobre o smartphone, o servidor Apache é utilizado pararealizar a comunicação através da escrita em arquivos. O Apache não só é compatívelcom o protocolo WML como com outras linguagens como PHP e HTML, por exemplo.3.4.3 AMBIENTE DE DESENVOLVIMENTO DO POSO ambiente de desenvolvimento do POS, da Verifone, também conhecido comoPOSWEB possui um módulo para depuração dos códigos, um compilador e um ambientepara emulação do equipamento trabalhando em conjunto com um servidor Web. Ocompilador WMLSComp gera uma representação compacta binária a partir do código doscript WMLS desenvolvido, chamado de bytecode. Este arquivo binário é submetido a uminterpretador de WMLS e pode ser depois conectado ao browser emulador do POSWEB,como mostrado na Figura 9.O software emulador traz uma réplica do equipamento na qual é possível simularseu funcionamento com ações programadas para ler seu teclado, cartões magnéticos,smart cards e até mesmo imprimir na sua impressora.Essa ferramenta foi gentilmente concedida pela empresa DN Automação [19] pararealização do projeto, embora não se trate de um software de utilização gratuita.21

Figura 9 – Interface de Desenvolvimento POSWEB.3.4.4 AMBIENTE DE DESENVOLVIMENTO DA APLICAÇÃO WIRELESSPara desenvolver e emular aplicações Java em dispositivos móveis com acessowireless (celulares e smartphones) foi utilizado o ambiente proporcionado pelo J2ME.Todas as ferramentas possuem licença livre e são fornecidas pela própria SUN [13],empresa que desenvolveu a linguagem.Um das ferramentas utilizadas é o JVM (Java Virtual Machine) que permite que osprogramas desenvolvidos sejam emulados em um computador pessoal. Outra ferramentautilizada foi o Wireless Toolkit, que simplifica e facilita o desenvolvimento do J2ME. AFigura 10 demonstra a interface de desenvolvimento proporcionada pelo Wireless Toolkit:Figura 10 – Ambiente de Desenvolvimento J2ME Wireless Toolkit.22

Uma característica importante do Java é a independência em relação à plataformaque está rodando. Isso acontece porque aplicações Java alocam um espaço independentede memória que não acessa a memória local dos programas presentes no smartphone.Este procedimento utiliza o conceito de Máquina Virtual, com o lema "Write Once, RunAnywhere!" (escreva uma vez, rode em qualquer lugar).Sendo assim é bastante difícil copiar, apagar ou manipular dados confidenciais,tais como agenda de contatos, mensagens, emails entre outros.A única forma de haver perda ou manipulação maliciosa de dados é se fossemimplementadas APIs (Application Programming Interface) ou “Interface de Programação deAplicativos” que fizessem tal acesso diretamente da aplicação Java, mas isso não secaracterizaria como vírus ou cavalos de tróia, e sim procedimentos pré-programados.23

4 SISTEMA PROPOSTOO sistema proposto visa facilitar o trabalho do garçom, agilizar o atendimento eaumentar a discrição no contato com o cliente. Para tanto, propõe-se automatizar boaparte do processo, inserindo equipamentos para interface com o usuário e com osfuncionários, de modo que o atendimento se torne mais rápido, eficiente e controlado. Avisão geral do sistema encontra-se na Figura 11.Figura 11 – Visão Geral do Sistema Proposto.São propostas duas possibilidades de implementação do sistema. Na primeira,terminais POS são distribuídos pelo restaurante, um por mesa, de forma a possibilitar queo cliente realize o pedido sem a presença do garçom e interaja com outros pontos doestabelecimento.As informações de pedidos oriundos dos terminais POS, são enviadas tanto para acozinha quanto para a recepção do restaurante, facilitando o gerenciamento e aumentandoa velocidade de atendimento. O desenvolvimento da aplicação nos terminais POS foirealizado na linguagem WML, enquanto a aplicação em execução nos computadores dacozinha e recepção foi implementada sobre o ambiente de desenvolvimento Delphi, nalinguagem Object Pascal.Os computadores presentes na cozinha e recepção também se comunicarão entre sie poderão enviar informações para os terminais POS nas mesas, tornando possível oacompanhamento tanto dos pedidos que estão sendo preparados quanto do estado daconta do cliente em questão. A Figura 12 apresenta o funcionamento dessa primeiraimplementação do sistema como um todo.24

Figura 12 – Visão Geral do Sistema1 utilizando terminais POS.A segunda opção para implementação do sistema é similar a primeira, porém, osterminais POS que se encontram fixos nas mesas, são substituídos por dispositivosmóveis de telefonia (smartphones), e pertencem aos próprios clientes do restaurante. Taisdispositivos precisam ser previamente carregados com uma aplicação Java que, apósinstalada no celular, possui funcionalidade semelhante àquela implementada nosaparelhos POS.Tal sistema possui interface com o usuário semelhante ao implementado nosterminais POS, embora apresente características próprias que junto com as vantagens edesvantagens de ambas as aplicações, são discutidas ao longo do documento.Conforme pode ser visto na Figura 13, é importante que o smartphone possuacapacidade de conexão via rede wi-fi, de forma a evitar custos desnecessários por partedo cliente para acessar pacotes de dados das operadoras. É possível também utilizar umasolução híbrida, onde algumas mesas possuem terminais POS, e os clientes tambémutilizam o sistema com seus smartphones.25

Figura 13 – Visão Geral do Sistema2 com Smartphones.4.1 FLUXO BÁSICO DO SISTEMA PROPOSTOInicialmente o cliente chegará ao estabelecimento e encontrará na mesa escolhidaum cardápio convencional impresso com todos os itens disponíveis no restaurante. Aolado da descrição de cada um desses itens do cardápio haverá um código que identificaráo pedido no novo sistema eletrônico.Ao optar por um item, o cliente terá duas formas de efetuar o pedido. Em uma delas,o cliente poderá digitar em um terminal POS que estará acoplado em sua mesa o códigorelativo à sua escolha. O terminal irá repassar o pedido do cliente para a cozinha, ondeexistirá um monitor com todos os dados dos pedidos pendentes que devem ser atendidos,entre eles o número da mesa que gerou o pedido.Outra opção será realizar o pedido através do dispositivo de telefonia móvelconvencional, equipado com comunicação wi-fi e apto a rodar aplicações Java, que,semelhante ao terminal POS, repassará o pedido realizado diretamente à cozinha.Istoagiliza a comunicação entre os setores do estabelecimento e também fornece maiorcontrole e confiabilidade para a gerência.Na cozinha, por sua vez, os cozinheiros e os garçons irão interagir com o sistema,coletando e inserindo dados sobre o andamento do pedido. Estas informações tambémestarão disponíveis, se desejável, em uma outra estação de trabalho na recepção.Todos os pedidos feitos pelos clientes, ao serem enviados para os computadores nacozinha, são armazenados em um banco de dados presente em um Desktop, que está26

localizado na recepção. Isto garante um maior controle para o administrador ou dono doestabelecimento sobre o que entrou efetivamente no caixa e outras informações sobre ospedidos já atendidos.Tendo em vista o caráter prático do trabalho desenvolvido, foram feitas análises dealgumas das soluções já existentes no mercado e do tempo disponível para realização eescolha das plataformas de hardware e software a serem utilizadas, afim de viabilizar aimplementação do projeto dentro do prazo proposto.4.2 POS COMO DISPOSITIVO PARA ENTREGA DE DADOSConforme colocado anteriormente, o POS, da Verifone, possui características deinteresse para esse projeto, além de possuir um custo adequado para o projeto. Até oinício do primeiro semestre deste ano nos foi cedido, pela empresa DN Automação, umexemplar deste terminal para testes. Contudo não conseguimos prolongar o empréstimopara o restante do ano por motivos de logística da empresa.O POSWEB Browser funciona como uma camada de software rodando em cimade um sistema operacional próprio do terminal. O browser presente no POSWEB temsuporte às linguagens XML, WML e WMLScripts, valendo-se do protocolo HTTP.As principais vantagens e funcionalidades que se pode obter com o uso desteequipamento são:• Portabilidade: Qualquer aplicação desenvolvida para o POSWEB Browser podeser executada, sem modificações, em qualquer outro modelo semelhante,independente de fabricante, que também utilize o mesmo ambiente operacional.• Redes IP: Ao utilizar a tecnologia POSWEB, as vantagens presentes em redesbaseada em IP serão agregadas ao aplicativo.A Figura 14 ilustra estas características do POSWEB Browser.Figura 14 – Portabilidade e uso em redes IP com terminais POS.27

• Multi Protocolo: O POSWEB Browser permite que uma mesma aplicação usediferentes protocolos de comunicação. Esta funcionalidade permite comunicaçãocom outros dispositivos em uma rede através de diferentes protocolos baseadosem TCP/IP, bem como por protocolos legados, como ilustrado na Figura 15.Figura 15 – Multi protocolos para comunicação com uso do POS.• Servidores de Aplicação: Com o acesso aos servidores de aplicação que oPOSWEB proporciona, pode-se adicionar funcionalidades ao terminal POS, comoatualização remota via HTTP e gerenciamento avançado.4.3 SMARTPHONE COMO DISPOSITIVO PARA ENTREGA DE DADOSDevido a disponibilidade para testes, foram considerados dois smartphones paraexecução da aplicação: o Motorola Q , da fabricante Motorola [11] e o Nokia N95, dafabricante Nokia [16]. Tais aparelhos são bastante completos e possuem inúmerasfuncionalidades embutidas. Neste documento são tratadas apenas funcionalidades doNokia N95 pertinentes ao objetivo do trabalho proposto, ou seja, comunicação wirelesspara acesso à internet, rede local e interface com usuário.Principais características do Nokia N95:• Sistema Operacional Symbian 60.• Tela de 2.6 polegadas QVGA, que pode ser usada tanto na vertical comohorizontal, com 16 milhões de cores e chip dedicado para imagens 3D.• GPS Integrado.• Conexão Alta Velocidade HSDPA (3G).• Suporte a WLAN, EDGE e WCDMA.• Bluetooth.28

• Java:MIDP 2.0• C++ e SDKs Java• Wi –Fi, Bluehtooth e Infravermelho.29

5 APLICAÇÕES DESENVOLVIDASCom o objetivo de distribuir os dados, controlar as operações realizadas norestaurante e oferecer uma interface aos usuários foram desenvolvidas aplicações quepossam interagir e exercer a automação proposta neste documento. Na Figura 16 édemonstrada a visão geral dos protocolos utilizados. Tais protocolos serão detalhados noscapítulos seguintes.Figura 16 – Visão Geral dos Protocolos Utilizados.5.1 APLICAÇÃO DELPHI – COZINHA E RECEPÇÃO5.1.1 APLICAÇÃO GARÇOM ELETRÔNICOEsta aplicação, desenvolvida em Object Pascal (Delphi), serve como integradoraentre o banco de dados Interbase que se encontra no servidor e as mensagens que sãorecebidas dos terminais POS instalados nas mesas do restaurante.A aplicação em Delphi que rodará no servido se divide em dois programas queinteragem. Estes dois programas são o Garçom Eletrônico e o Mediator.O Garçom Eletrônico é a aplicação que servirá de interface para os usuários dosistema. Possuí como funções principais: exibir a situação atual da fila de pedidos dosclientes, exibir os saldos atuais de todas as contas abertas no momento e possibilitar ocadastro de usuários e itens.Inicialmente este sistema possui apenas um usuário cadastrado para o acesso. Esteusuário é o administrador e será utilizado pelo dono ou o usuário admin. Pode-se, a partir30

da tela de cadastro, criar outros usuários para acesso ao sistema e conceder ou revogarprivilégios de acesso para os mesmos. Existem dois níveis de acesso para usuários:administrador e comum.Os usuários com status de administrador têm acesso a todas as funcionalidades doGarçom Eletrônico, enquanto que os usuários comuns podem apenas visualizar a tela coma fila de pedidos. Cada usuário cadastrado corresponde a um registro na tabela deusuários no banco de dados Interbase. A Figura 17 mostra a tela de cadastro de usuários.Figura 17 – Tela de cadastro de usuários do Garçom Eletrônico.O cadastro de itens é uma tela só acessada por usuários administradores, e servepara adicionar no banco de dados todos os itens que estarão à venda no estabelecimento.O conceito de item nesta aplicação serve para descrever pratos, bebidas, e tudo mais quefor oferecido no cardápio do restaurante. Cada item cadastrado no Garçom Eletrônicocorresponde a um registro na tabela de pedidos do banco de dados Interbase.Cada registro de item tem um código (incrementado automaticamente), umadescrição, um preço unitário e a informação que indica se necessita de tempo parapreparo ou não. Isto identifica se o item precisa ser antes preparado pela cozinha comoum prato especial. Um exemplo de item que não precisa de tempo para preparo seria umabebida como refrigerante, que pode ser servida mais rapidamente pelo garçom. Estadiferenciação tem um impacto na tela de exibição da fila de pedidos, que será explicada aseguir. A Figura 18 exibe a tela de cadastro de itens.31

Figura 18 – Tela de Cadastro de Itens do Garçom Eletrônico.A tela de exibição da fila de pedidos pode ser acessada tanto pelo administradorcomo pelos outros usuários do sistema como os garçons e os funcionários da cozinha.É por esta tela que os funcionários na cozinha se guiarão para saber que pedidosestão entrando, sendo atendidos ou já estão prontos para serem entregues.Esta tela é divida em três listas diferentes: a lista de pedidos que estão entrando eprecisam de preparo, aqueles que estão sendo preparados e os que já podem serentregues pelos garçons. Esta última será a única com a qual os garçons deverãointeragir. Ao entregar um pedido, o garçom deverá, apenas com clique duplo no pedido,confirmar a entrega. Ao confirmar a entrega do pedido, este tem seu registro alterado nobanco de dados. Uma melhoria futura seria implementar um sistema de touch screen parainteragir com os garçons, sendo necessário apenas utilizar uma tela com tal capacidade.O campo pedido_status controla se um pedido já foi entregue ou não. Quando esteestiver selecionado com o valor ‘E’ significa que já foi entregue pelo garçom. Além destaalteração, é executada uma rotina que atualiza o saldo atual da conta que realizou opedido, adicionando-se o valor do pedido entregue.Esta rotina primeiro pesquisa pela conta que realizou o pedido, na tabela de contas(através do campo pedidos_codigo_conta). Depois procura na tabela de itens pelo preçounitário do item do pedido (usando o campo pedidos_codigo_item).Com estas informações, a rotina atualiza na tabela de contas, o campocontas_total_a_pagar da conta que fez o pedido, somando o preço unitário do itemmultiplicado pela quantidade do mesmo (informação do campo pedidos_qtde_item).A lista de pedidos sendo entregues e de pedidos em atendimento é utilizada pelosfuncionários da cozinha. São estes que atualizam o status de cada ordem que chega. Aodar um clique duplo em um pedido na lista de pedidos entrando, o valor do campo32

pedidos_status (inicialmente com ‘A’ ,para aberto), é alterado para ‘B’ que significa que opedido entrará em atendimento e estará na lista de pedidos em atendimento. Da mesmaforma, se um usuário der um duplo clique em um pedido na lista de pedidos ematendimento, este terá no banco seu campo pedidos_status alterado para o valor ‘C’, e opedido entrará na lista de pedidos prontos para entrega.Esta tela é atualizada de cinco em cinco segundos, que é o tempo controlado por umcomponente TTIMER, presente no formulário Form_pedidos. Esta atualização consiste emencontrar os pedidos lidos dos terminais POS e inseridos no banco pelo Mediator, queserá explicado em seguida. A Figura 19 mostra a tela de pedidos do Garçom Eletrônico.Figura 19 – Tela de pedidos do Garçom Eletrônico.A última tela do Garçom Eletrônico, a ser explicada aqui, é a tela de contas. Como opróprio nome diz, a tela de contas tem como função exibir dados atualizados sobre ascontas abertas no momento no restaurante. Além disso, a tela fornece opções parapesquisa de contas por número de mesa, por código de conta ou até mesmo por intervalode datas. Esta tela também é atualizada de cinco em cinco segundos como a tela depedidos.A importância desta tela é o fato de fornecer ao administrador do restaurante,informações sobre as contas já abertas no mesmo e ter armazenado no banco de dadostodas as quantias que entraram no caixa. A Figura 20 mostra a tela de contas.33

Figura 20 – Tela de contas do Garçom Eletrônico.Todas as telas do Garçom Eletrônico trazem informações atualizadas dobanco de dados Interbase. Isto é possível porque na hora da construção dasmesmas, foram utilizados componentes de ligação deste banco. Tais componentespermitem a comunicação da aplicação com o banco realizar consultas e manipularos dados das tabelas do interbase.5.1.2 APLICAÇÃO MEDIATORO Mediator é o programa responsável pela comunicação dos terminais POS com oInterbase, lendo os arquivos de pedidos dos terminais e atualizando o banco com osdados lidos. Ao fazer isso, as telas do Garçom eletrônico também são atualizadas, poiseste também está ligado diretamente ao banco, conforme explicado anteriormente.Este programa é chamado pelo Garçom Eletrônico logo após a autenticação dousuário. O Mediator exibe uma pequena tela onde o usuário deve fornecer a localizaçãoonde serão criados os arquivos para comunicação com os terminais POS.Esta localização precisa ser o diretório onde estão sendo disponibilizados osarquivos do servidor Apache. Isto porque este é o diretório que os terminais POSutilizaram para ler e escrever dados nos arquivos para comunicação. O protocolo utilizadopelo POS, para leitura e escrita nos arquivos no servidor, será o HTTP, com comandos deLoadString, Get e Put.Os arquivos de comunicação são na verdade dois: o arquivo de saldo atual para amesa, chamado saldo_conta_mesa1.txt (onde 1 no caso é o numero da mesa), e o arquivode pedidos da mesa, chamado pos1.db (onde também o número 1 representa o númeroda mesa). Além disso, existe também o arquivo itens.txt. A seguir será explicado como oMediator faz para se comunicar com os terminais POS.34

Inicialmente, a comunicação entre POS e Delphi seria por intermédio de sockets. Oproblema encontrado para isso foi o fato das bibliotecas de funções disponíveis no POSpara comunicação via sockets, funcionarem apenas para o protocolo ISO-8583 que éproprietário e utilizado para transações financeiras. E como o compilador para WMLSutilizado não reconhecia estas funções, não foi possível este tipo de conexão.A solução encontrada foi utilizar o protocolo HTTP e comunicação via arquivos. Acomunicação ficou simplificada e unidirecional desta forma, baseada no sistema Mestre –Escravo onde a aplicação Delphi não tem como enviar mensagens para a aplicação noPOS.O Mediator executa um laço infinito que realiza três atividades:• Atualiza os arquivos de saldos de cada mesa;• Atualiza o arquivo de itens cadastrados no banco de dados;• Lê e insere os pedidos feitos por cada mesa.Os arquivos de pedidos, como explicado antes, armazena os pedidos feitos peloPOS. Alguns códigos especiais para pedidos executam operações diferentes da simplesinclusão. Abaixo, na Tabela 2, estão explicitados tais códigos especiais e as açõesexecutadas pelo Mediator ao lê-los do arquivo.Tabela 2 - Códigos Internos Utilizados no Protocolo de Arquivos.Código Descrição9999 Abertura de Conta9998 Fechamento de Conta9997 Chamar o GarçomA aplicação que executa na cozinha e na recepção é a mesma. O que muda de umapara a outra são alguns parâmetros passados tais como a localização do banco de dadose o nível de acesso do usuário que acessa o sistema. A Figura 21 ilustra o funcionamentogeral do protocolo de comunicação criado no sistema proposto, e a Figura 22 explica ofuncionamento do programa Mediator.35

Figura 21 – Funcionamento geral da comunicação POS – Servidor – Delphi.Figura 22 – Funcionamento da Aplicação Mediator.36

O protocolo criado para a comunicação entre os terminais POS e o programaservidor que estará rodando na cozinha, funciona a partir da escrita e leitura em arquivos.Neste protocolo o POS escreve em um arquivo, e o programa servidor retira asinformações deste mesmo arquivo, armazenando em um banco de dados. Este modelo sebaseia no sistema mestre-escravo. Neste caso resolvemos utilizar o mesmo sistema tantopara o POS quanto para o smartphone, O protocolo criado trabalha sobre HTTP, que porsua vez, está implementado sobre TCP/IP, estando por fim sobre o protocolo Ethernet,conforme podemos observar na Figura 23. Esta apresenta todas as camadas necessáriaspara a utilização do protocolo implementado. Em termos físicos, a comunicação sobre oterminal POS foi realizada através de cabos de rede, enquanto, por sua vez, a dosmartphone foi realizada através de redes sem fio (wi-fi).Figura 23 – Pilha de Protocolos Utilizada.5.1.3 CONFIGURAÇÃO INICIALPara fazer a configuração inicial tanto do programa servidor como dos dispositivosclientes existirá uma tela para cadastro, que apresentará o cardápio. Tal cardápio,chamado itens.txt, é inserido no banco de dados e lido pelos dispositivos POS.Ao gerar um novo pedido, o POS irá criar um arquivo no seguinte formato:pos.db onde numero serial é um código único atribuído a cada POS. Estearquivo irá identificar de qual mesa veio o pedido. Quanto ao arquivo de saldo da mesa,será gerado no seguinte formato: saldo_conta.txt onde o numero serial édo POS que efetuou os pedidos.5.1.4 APLICAÇÃO WML – TERMINAIS POSCada mesa do restaurante terá acoplada a si um terminal POS. Utilizando esteterminal, de sua mesa, o cliente poderá efetuar seus pedidos e/ou chamar algum garçomcaso deseje alguma informação adicional. Isto é possível graças a uma aplicaçãodesenvolvida neste projeto, escrita em WML, e scripts WMLS.Esta aplicação consiste de um conjunto de menus associados entre si quepermitem ao cliente fazer a sua escolha. O cliente realiza a consulta de pratos através de37

um cardápio no formato convencional impresso, que estará presente nas mesas dorestaurante. Um exemplo de cardápio encontra-se no ANEXO1.Após digitar no teclado o número do item desejado, o menu na tela do terminalmostrará a descrição deste item escolhido e perguntará se o cliente confirma o pedido ounão. Se confirmar sua escolha, um script WMLS é chamado, e uma rotina interna seencarrega de conectar o POS ao servidor rodando o banco de dados Interbase.Após o estabelecimento da conexão, os dados relativos ao pedido do cliente sãoenviados para a aplicação escrita em Delphi rodando no servidor. A aplicação então montaum registro com os campos do pedido e salva o mesmo no banco de dados. Com isso,todos os outros terminais que também se conectam a mesma base de dados do servidor,como o localizado na cozinha, por exemplo, atualizam as suas listas de pedidos a serempreparados e entregues. Estas listas são exibidas na tela principal do aplicativo em Delphi,onde os funcionários monitoram e se guiam em relação aos pedidos que entram e saemda cozinha. Na Figura 24 pode-se observar o menu inicial da aplicação desenvolvida.Figura 24 – Menu Inicial Desenvolvido na Aplicação POS.O protocolo de escrita e leitura em arquivo funciona da seguinte maneira:• Quando o cliente faz um pedido, o dispositivo POS faz uma busca em seubanco interno, para verificar se o código do pedido realmente existe;• Se a resposta for afirmativa, retorna em sua tela a descrição do pedido e ovalor unitário do mesmo, solicitando logo em seguida uma confirmação daescolha feita;• Ao confirmar a escolha, o POS escreve em um arquivo o pedido feito,descrevendo o código deste, descrição, preço e hora em que foi feita asolicitação (cada POS possui um arquivo único, identificado pelo seu númeroserial, ou pelo numero da mesa onde está alocado);38

• A escrita em arquivo é feita através de um método existente em WML,chamado PUT. Para que isso possa ocorrer é necessário fazer aconfiguração do servidor Apache onde este arquivo estará armazenado;• A partir deste ponto, fica a cargo do programa servidor, implementado emDelphi, buscar as informações presentes no arquivo, atualizando seu bancode dados;• Quando o cliente solicitar a conta total da mesa, terá a sua disposição ummenu criado especialmente para isso. Ao selecionar essa opção, um códigoespecial é passado para o arquivo referente ao POS da mesa em questão.Quando o programa servidor identificar tal código, irá pegar o montante totalda mesa, e irá escrevê-lo em outro arquivo, onde o POS possa buscar aconta do cliente;• Essa busca em arquivo é feita através de outro método presente nalinguagem WML, chamado Load String. Sendo assim, o valor é buscado efornecido ao cliente para que possa efetuar a quitação dos valores devidos.POS:As Figuras 25, 26 e 27 ilustram o fluxograma de cada um dos menus disponíveis noInicioCliente InsereCódigo Relativo aoPedidoNãoCódigo é Válido?SimRetorna Descrição evalor do pedidoEscreve Pedidoem Arquivo juntocom o Código9999FimProgramaServidorArmazenaDados no BancoFigura 25 - Fluxograma para Realizar um Pedido.39

InicioCliente SolicitaGarçomAplicação PosEnvia Código 9997para a base.Base Identifica Código9997 e DisparaMensagem deSolicitação deGarçom,indicando amesaFimFigura 26 – Fluxograma para Chamar Garçom.InicioCliente Solicita aContaAplicação PosEnvia Código 9998para a base.Base Identifica Códigoe Dispara Mensagemde Solicitação deconta da mesaFimFigura 27 – Fluxograma para Pedir a Conta.40

5.2 APLICAÇÃO JAVA – SMARTPHONESNo desenvolvimento da aplicação para dispositivos de telefonia móvel, optou-se pelautilização de sockets e conexões via protocolo TCP/IP para a realização da comunicaçãoentre os sistemas cliente e a aplicação residente no servidor (desenvolvida em Delphi).Esta última, por sua vez, comunica-se com o banco de dados diretamente, realizandotodas as transações com o mesmo.Um socket é uma camada de software que permite a abstração do mapeamento, doendereço do host e da porta da aplicação em uma conexão TCP/IP. A utilização desockets permite de forma padronizada e simples a criação de canais bidirecionais entreduas aplicações rodando em hosts distintos em uma rede.O protocolo TCP é um protocolo de rede da camada de transporte orientado aconexões, ao contrário do protocolo UDP. Ele é atualmente o mais utilizado para a trocade mensagens entre os hosts da rede mundial, sendo encapsulado pelo protocolo IP,responsável pela identificação de um host em uma dada rede. Enquanto que o protocoloIP identifica a localização lógica dos hosts em uma rede, o protocolo TCP identifica quaisaplicações em execução nestes hosts processarão de fato os dados recebidos nacomunicação.A identificação da aplicação que recebe ou envia dados em uma comunicaçãoTCP/IP é feita utilizando-se o conceito de portas. Portas são uma espécie de canalbidirecional que liga uma aplicação à outra na rede. Em redes são identificadas pornúmeros, sendo que algumas inclusive são padronizadas por aplicações de uso comum.São exemplos disto a porta 25, utilizada para o envio de mensagens de e-mail viaprotocolo SMTP (Simple Mail Transfer Protocol) e a porta 80 para a transferência depáginas WWW (World Wide Web) via protocolo HTTP (HyperText Transfer Protocol).5.3 APLICAÇÃO J2ME – SMARTPHONEA aplicação J2ME desenvolvida para smartphones, aparece aqui como umaalternativa a implementação descrita anteriormente, utilizando-se os terminais POS. Comesta aplicação em J2ME, todos os clientes do restaurante poderão realizar pedidos,chamar a atenção dos garçons e abrir e fechar contas, de forma semelhante ao que foifeito na aplicação POS.Para o restaurante poder usar este tipo de serviço, precisa dispor de um ponto derede Wi-Fi (sem fio) e implementar uma pequena rede interna. Ao entrar no perímetro dealcance deste ponto de rede, o smartphone do cliente detecta a rede automaticamente ese conecta à rede do restaurante. Estabelecida a conexão, o cliente deverá acessar o41

endereço da aplicação J2ME no servidor do restaurante. Tal endereço obviamente deveráser divulgado pelo próprio restaurante para conhecimento de seus clientes.Este endereço será o caminho onde se encontram os arquivos disponibilizados peloservidor Apache do servidor do restaurante. Acessando este endereço, o download daaplicação será iniciado e após a instalação da aplicação, o cliente poderá utilizá-la parafazer seus pedidos.5.3.1 INTRODUÇÃO DO J2ME NO PROCESSOA comunicação estabelecida entre a aplicação J2ME e o Garçom Eletrônico noservidor é feita utilizando-se sockets. Ambas se comunicam por uma porta determinada(no caso foi escolhida a porta 2255). Para dar suporte a este tipo de comunicação, oGarçom Eletrônico precisou da inclusão de um componente do Delphi, da bibliotecaInternet chamado TServerSocket. Este componente traz um método para executar açõesquando detecta eventos na porta designada. Neste método foram implementadas as açõesque o Garçom Eletrônico deverá executar ao receber as mensagens das aplicações J2ME.É interessante notar que para essa comunicação a aplicação Mediator não éutilizada. As características descritas anteriormente foram feitas na aplicação GarçomEletrônico. Para efeitos de clareza e padronização, os códigos para as ações de chamaros garçons, abrir e fechar contas e consultar saldo atual foram mantidos da aplicaçãoPOS. Ao receber uma mensagem na porta 2255, o Garçom Eletrônico decodifica amensagem recebida pelo socket e faz toda a comunicação necessária com o banco dedados.Outra opção que poderia ser introduzida é a comunicação direta entre a aplicaçãoJ2ME e o bando de dados do servidor. Mesmo diante deste fato optou-se por utilizar ainterface e comunicação disponíveis no Garçom Eletrônico, pois assim ganha-se bastanteno quesito controle de processo e interface com usuário.O banco de dados do Interbase foi adaptado para suportar a aplicação wi-fi, sendoassim, houve a inclusão de uma nova tabela: a tabela de Mesas, que como o nome diz,serve para o controle das mesas existentes no restaurante. Esta tabela possui apenas umcampo para o código da mesa e uma chave estrangeira com a tabela de contas paravalidar se a mesa que o usuário escolheu pela aplicação J2ME de fato existe, e se ela nãoestá já sendo utilizada por outros.5.3.2 FUNCIONAMENTO E IMPLEMENTAÇÃO DA MIDLET J2MEAo acessar a midlet [14] de serviços do Garçom Eletrônico, o usuário irá sedeparar com a tela inicial apresentada na Figura 28. Esta tela solicita para o usuário o42

número da mesa em que este se encontra. Escolhido o número da mesa (o número damesa estará fixado na mesa), o usuário deverá escolher a opção “Abrir Conta” para podercomeçar a fazer seus pedidos.A midlet J2ME cria uma conexão via socket com a aplicação do servidor e enviauma mensagem contendo o código de abertura de contas e o número da mesa escolhida.O servidor, por sua vez, ao detectar uma nova conexão, inclui esta em uma lista dinâmicade conexões, onde cada nova conexão recebe um número identificador. Em seguida, aoler o pedido de abertura de conta, ela verifica via consulta SQL no banco se o código damesa existe. Neste caso a tabela de contas é pesquisada para validar se a mesa já nãoestá sendo utilizada por nenhuma conta em aberto. Isto é feito checando se nesta tabelaexiste já um registro com o campo CONTAS_NUMERO_MESA igual ao número da mesaescolhida e com o campo CONTAS_DATA_HORA_FECHAMENTO nulo (o que indica quea conta em questão ainda está aberta).Figura 28 – Tela inicial da midlet J2ME.Se a conta foi aberta com sucesso, uma nova tela será exibida para o usuário ondeaparecem as opções do menu principal e poderão ser escolhidas as opções para sechamar um garçom para atendimento, fazer um pedido de algum item do cardápio, ver osaldo atual, e fechar a conta.A Figura 29 exibe a tela com o menu principal da midlet J2ME.43

Figura 29 – Tela com menu principal da midlet J2ME.Quando a opção “Fazer Pedido” for escolhida, a tela para realização dos pedidosserá invocada imediatamente. Esta tela exibe dois campos onde o cliente deverá fornecera quantidade do item desejado, e o código do mesmo item, segundo consta no cardápio dorestaurante. A Figura 30 exibe a tela de menu principal da midlet J2ME.Figura 30 – Tela de pedidos da midlet J2ME.Se os dois campos forem preenchidos corretamente, a midlet enviará umamensagem contendo a palavra PEDIDO seguido do código do item escolhido e aquantidade do mesmo, para a aplicação servidora. Ao receber esta mensagem, o servidor44

insere no banco de dados um registro na tabela de pedidos com as informaçõesfornecidas. O novo pedido será exibido na tela automaticamente, pois como visto antes, oGarçom Eletrônico atualiza as informações que exibe interface a partir dos registros nobanco de dados. Isso ocorre praticamente em tempo real.A opção para ver o saldo atual envia uma mensagem para consulta de saldo e onúmero da mesa do cliente. O servidor pesquisa no banco de dados pelo campoCONTAS_TOTAL_A_PAGAR do registro correspondente à conta aberta pelo cliente natabela de contas. Ao encontrar o valor, retorna uma mensagem com o saldo, que é por fimexibido na tela do smartphone pela midlet J2ME.E por fim, ainda no menu principal temos a opção de se chamar a atenção dosgarçons, que funciona com o envio de uma mensagem para o Garçom Eletrônico contendoo número da mesa do cliente. De forma semelhante à aplicação POS, ao receber estamensagem uma pequena tela de aviso é exibida no Garçom Eletrônico.A opção Pagar da tela de menu principal encerra a conta enviando uma mensagemcom o código para fechamento de conta e o número da mesa. Ao receber esta mensagema aplicação no servidor realiza um update para o registro correspondente da conta docliente, dentro da tabela de contas, no campo CONTAS_DATA_HORA_FECHAMENTO,escrevendo neste campo a data e hora atuais.Um dos problemas encontrados foi a questão de como validar se a mensagem quechega até a aplicação do servidor realmente está sendo enviada da mesa com o númeroque está na mensagem. Isto foi resolvido com a utilização de uma lista dinâmica deconexões na aplicação servidora.Como dito anteriormente, cada conexão recebe um identificador nesta lista e sempreque uma mensagem chega à porta escutada pelo componente do Delphi, este verifica dequal conexão veio a mesma, respondendo corretamente para quem enviou a requisição, erejeitando mensagens com números de mesa incorretos ou outras informações que nãoestejam de acordo.5.4 MODELAGEM DO BANCO DE DADOSO modelo do banco de dados utilizado neste trabalho e implementado no banco dedados Interbase consiste basicamente de quatro tabelas: a de usuários, a de itens, a depedidos e a de contas.A tabela de usuários possui três campos:• USUARIOS_USERNAME - username utilizado para acesso do usuário natela de login;• USUARIOS_SENHA - senha de acesso para o usuário na tela de login;45

• USUARIOS_NIVEL -define o nível de acesso ao usuário no sistema. Ovalor ‘0’ (zero) define um usuário administrador enquanto que o valor ‘1’(um) define um usuário comum.A tabela de itens possui três campos:• ITENS_CODIGO – código do item que é auto-incrementado a cadainserção de um novo item, utilizando-se uma sequence e uma triggerpara isso;• ITENS_DESCRICAO – descritivo do item que será exibido na tela depedidos;• ITENS_ESPERA_ATENDIMENTO – campo que indica se o item precisade tempo para preparo ou pode ser providenciado imediatamente pelogarçom.A tabela de contas possui cinco campos:• CONTAS_CODIGO – código da conta que a exemplo do campoITENS_CODIGO também é auto-incrementado.• CONTAS_TOTAL_A_PAGAR – este campo traz a informação de quantojá foi gasto até o momento nesta conta;• CONTAS_DATA_HORA_ABERTURA – traz a data e a hora do sistemano momento em que a conta foi aberta.• CONTAS_DATA_HORA_FECHAMENTO – traz a data e a hora dosistema no momento em que a conta foi fechada. Se este campo estánulo então significa que a conta ainda está aberta;• CONTAS_NUMERO_MESA – este campo traz o número da mesa dorestaurante, da qual foi originada a abertura da conta.A tabela de pedidos é a central do modelo e se liga às tabelas de itens e contascom as seguintes regras: um pedido deve ter um e somente um item relacionado, aomesmo tempo em que uma conta pode ter um ou vários pedidos relacionados. Estatabela possui seis campos:• PEDIDOS_CODIGO – código do pedido auto-incrementado para cadainserção de novo pedido utilizando um sequence e uma trigger para isso;• PEDIDOS_CODIGO_ITEM – código do item relacionado no pedido. É achave estrangeira para a tabela de itens;• PEDIDOS_CODIGO_CONTA – código da conta associada ao pedido. Éa chave estrangeira para a tabela de contas;• PEDIDOS_QTDE_ITEM – quantidade do item associado que foi pedida;46

• PEDIDOS_STATUS – status atual do pedido. Pode ter os valores ‘A’ paraaberto, ‘B’ para dizer que o pedido está em atendimento, ’C’ para ospedidos que estão prontos pra entrega e ‘D’ para os que já foramentregues.A tabela de mesas existe para validar se a mesa existe realmente noestabelecimento. As mesas são cadastradas na tela de cadastro de mesas daaplicação Garçom Eletrônico. Esta tabela possui apenas um campo com o código damesa que serve para fazer uma ligação com a tabela de contas, associando umaconta a uma mesa já existente. A Figura 31 exibe o diagrama das tabelas e como foimodelado o banco de dados para este trabalho.Figura 31 – Modelo do Banco de Dados Interbase.5.5 FUTURAS E POSSIVEIS EXPANSOESLevando-se em conta o sistema que foi proposto e implementado, temospercepção que muitas expansões e melhorias podem ser feitas e agregadas ao projetooriginal. Neste capítulo iremos citar e dar uma breve introdução sobre alguns pontos quepensamos, mas por questões de tempo e alguns outros fatores, não puderam serimplementadas ou estudadas tão profundamente quanto gostaríamos.a) Uso de terminais POS em hotéis e motéis. Desta forma o hóspede/clientenão teria que entrar em contato com a recepção para realizar pedidos depratos, bebidas ou qualquer outra solicitação. Um grande impedimentoseria em relação ao cabeamento do sistema;b) Uso de SmartCards junto com os terminais POS. O hardware do POS jápossui interface para SmartCard. Poderíamos usar esses cartões parapagamentos de contas, autenticações de usuários, histórico do cliente,reservas, etc...;47

c) Uso de cartões de crédito para pagamento. Muitos estabelecimentosutilizam terminais POS para realizarem pagamentos de contas emrestaurantes, supermercados e afins. Tal pagamento normalmente é feitovia débito bancário automático. Para isso teríamos que ter acesso aoprotocolo de segurança utilizada para esse tipo de transação bancária;d) Utilização de terminais POS para emissão de comprovantes depagamentos, notas fiscais, etc..;e) Implementação de redes wireless em estabelecimentos comerciais dosdiversos tipos. Neste caso, por exemplo, o cliente entraria na loja, e a partirdo seu smartphone com acesso wi-fi, poderia baixar o catálogo na loja,verificar preços, peças que estão no estoque, disponibilidade de entrega,modelos, cores disponíveis, etc.. Esse tipo de aplicação também poderiaser usada pelos funcionários do estabelecimento, agilizando muito oatendimento dos clientes;f) Utilização de terminais POS para controle de freqüência escolar. Sendoassim, os alunos chegariam a sala de aula, e em vez de terem queresponder chamada pessoalmente, estaria disponível um terminal POS,onde o aluno passaria um cartão smartcard que assinalaria a presença doaluno em questão. Uma vez por dia, esse terminal seria conectado ao umPC, e a lista de presença de todos os alunos, e professores estaria gravadana memória do aparelho. Bastando baixá-la e armazená-la no computador.Isso agilizaria bastante o controle de freqüência;g) Terminais POS sendo usados como cartão ponto eletrônicos. A exemplo docontrole de freqüência escolar, os funcionários passariam um smartcard noterminal POS, que gravaria a hora de chegada e saída de cada um deles.h) Uso de telas touch screen para facilitar a interação dos funcionários doestabelecimento com os aplicativos gerenciadores;i) Substituição da aplicação Delphi que roda nos computadores da cozinhapor aplicações hospedadas, escritas em linguagens para Web, como porexemplo, PHP. Isso traria mais mobilidade e flexibilidade a soluçãoimplementada, visto que a partir de qualquer máquina poder-se-ia acessaro seu banco de dados e interface de gerência.48

6 CONCLUSÃOAo optar-se pela implementação de um sistema de automação, percebeu-se,inicialmente, que iria envolver uma gama de conhecimentos, tornando-se assim umaaplicação interdisciplinar. A partir disso verificou-se que vários desafios estavam por vir eteriam que ser superados.O primeiro passo foi o estudo do funcionamento normal de um restaurante, seusprincipais processos, e a relação que o cliente mantém com cada funcionário que trabalhano estabelecimento. Depois de feito esse estudo, foi identificado onde poderia ser inseridoo sistema de automação proposto, e quais as vantagens que isso iria acarretar.O próximo passo foi a modelagem do projeto que realizasse as atividadespropostas, pondo em prática os conhecimentos adquiridos ao longo do curso deEngenharia de Computação, e agregando novos conhecimentos, ou solidificando algunsoutros, que iríamos necessitar ao longo da jornada.Através deste projeto foi possível conhecer as tecnologias oferecidas pelosterminais POS e também pelos smartphones presentes hoje no mercado, além de nos porem contato com uma gama de outras tecnologias que por ventura pudessem seragregadas. Foi possível também perceber algumas limitações, sendo a principal causadapelo tamanho atual dos terminais POS, a comunicação entre eles, o preço atual dosaparelhos smartphones e a dimensão atual destes aparelhos no Brasil.A escolha do dispositivo POS se deu principalmente pela facilidade de acesso queteríamos, tendo em vista que esse mesmo terminal é usado pelo GSE (Grupo de SistemasEmbarcados), da PUCRS, sem haver a necessidade de adquiri-lo. Outro fatorpreponderante foi à finalidade comercial deste aparelho, importante característica dosistema proposto.Também foi feito um estudo de mercado, para pesquisarmos quais soluções jáestavam sendo vendidas, quais as principais fraquezas e vantagens dessas soluções, eonde poderiam ser melhoradas e acrescentadas.Ao longo de todo o trabalho, desde a fase de planejamento, passando pela fase deconcepção e acabamento, diversas dificuldades foram enfrentadas, as quais cabemsalientar neste documento:1) Foi sempre uma meta importante o desenvolvimento de um projeto decaráter mais prático que teórico. Sendo assim, a primeira dificuldadeencontrada foi idealizar o projeto de uma aplicação real e com um grau defuncionalidade.2) Após a fase inicial de descobrir um assunto em potencial, foi o estudo deviabilidade do projeto, levando em conta os recursos disponíveis.49

3) Devido ao grupo ser oriundo de uma área bastante técnica, tentamosbuscar o máximo de informações a respeito do funcionamento normal deum restaurante e de como gerenciar um estabelecimento deste tipo.4) O próximo passo foi estudar as linguagens WML e WMLS, que até entãoeram desconhecidas pelos integrantes do grupo.5) Estudo da linguagem J2ME, a qual não havia familiaridade alguma.6) Nesta fase de estudos percebeu-se que não existia muita informação edocumentação sobre o mecanismo de funcionamento do POS.7) Por lidar com hardwares comerciais, acabou-se enfrentando muitosproblemas com obtenção de informações técnicas e até mesmo naobtenção dos equipamentos para fins de estudo.8) Ao tentar utilizar sockets no POS, conclui-se que não havia possibilidadede tal comunicação por motivos já citados neste documento.9) Foi necessário que criar um protocolo próprio que permitisse o envio e orecebimento de dados entre POS e servidor.10) Na fase de criação do protocolo, foram encontradas dificuldades paraconfigurar permissões e arquivos de inicialização do servidor Apache, ondeficariam hospedados os arquivos utilizados na comunicação.11) Existiram dificuldades para conseguir o terminal POS para realização dostestes finais, já que o projeto foi concebido em ambientes de simulação.50

7 BIBLIOGRAFIA[1] Dayan, Elie G. Restaurante : técnicas de serviço. Caxias do Sul : EDUCS, 1987. 178 p[2] Walker, John R. O Restaurante : conceito e operação. 3. ed. Porto Alegre : Bookman,2003. 366 p.[3] Demétrio, Rinaldo. A tecnologia Wap : aprenda a criar páginas para celulares com alinguagem WML. São Paulo : Érica, 2000. 222 p[4] Buchmann, Johannes. Introduction to Cryptography. 2. ed. New York, NY : Springer,c2004. 335 p[5] Seberry, Jennifer Cryptography : An Introduction to Computer Security. New York,NY : Prentice Hall, c1989.[6] APPI, Soluções de Valor para o seu Negócio. Disponível em:. Acesso em: 03 set. 2007.[7] PEKUS, Soluções em Mobilidade. Disponível em:. Acesso em: 03 set. 2007.[8] CSI, Consultoria e Serviços de Informática LTDA. Disponível em:. Acesso em: 03 set. 2007.[9] Wikipédia, A Enciclopédia Livre. Disponível em:. Acesso em: 03 set. 2007.[10] IBGE, Instituto Brasileiro de Geografia e Estatística. Disponível em:. Acesso em: 10 out. 2007.[11] Motorola Brasil. Disponível em:. Acesso em: 01 nov. 2007.[12] Microsoft Brasil. Disponível em:. Acesso em: 30 out. 2007.[13] SUN Brasil. Disponível em:. Acesso em: 30 out. 2007.[14] Piroumian, Vartan. Wireless J2ME Platform Programming. 1 ed. Palo Alto, CA : SunMicrosystems, c2002. 363 p[15] Traldi Fonseca, Marcelo.Tecnologias Gerenciais de Restaurantes. 3 ed. São Paulo,SP : Senac Editora. c2004. 187 p[16] Nokia Brasil. Disponível em:< http://www.nokia.com.br/>. Acesso em: 20 nov. 2007[17] In - Stat, Digital Communications and Market Research Disponível em:. Acesso em: 03 set. 2007.[18] Verifone, The Way to Pay. Disponível em:. Acesso em: 28 nov. 2007.51

[19] DN Automação,Tecnologia ao seu Alcance. Disponível em:. Acesso em: 28 nov. 2007.[20] Franklint, Kleitor. Delphi 5 para Internet com Banco de Dados. 2 ed. São Paulo, SP :Érica Editora. c2005. 324 p[21] Oracle, Disponível em:< http://www.oracle.com>. Acesso em: 15 nov. 2007.[22] Borlando, The Open ALM Company. Disponível em:< http://www.borland.com>. Acesso em: 15 nov. 2007.[23] Holden, Greg. Apache server. São PauloMakron Books, 2001. 254 p.[24] Holden, Greg. Apache server. São PauloMakron Books, 2001. 254 p.[25] Departamento de Ciência da Computação da UFBA. Acesso em: 15 nov. 2007.52

ANEXO 1 – Modelo de Cardápio.PIZZARIA PUCRSCÓDIGO ENTRADAS PREÇOR$1 Antepasto Napolitano8,00Berinjela, abobrinha e tomates assados na brasa, temperados com azeiteextra virgem, alho, orégano e especiarias.2 ParmiggianoR$5,00Porção de queijo parmesão.3 BruschettaFatias de pão italiano grelhadas com tomate fresco e temperado comalho, azeite e manjericão.R$5,00CÓDIGO PIZZAS TRADICIONAIS PREÇOR$4 Calabresa25,00Lingüiça calabresa, confeccionada por um mestre na arte, e cebolas sobremolho de tomates frescos.5 NapolitanaR$23,00Mussarela, rodelas de tomate e manjericão.6 MargheritaPreparada com mussarela especial, tomates e folhas de manjericão.R$23,00CÓDIGO SOBREMESAS PREÇOR$7 Pizza Doce20,00Creme de Gianduia com cobertura de laranja, banana ou morango.8 Torta BrownieServida com sorvete de creme.9 Petit Gateau de ChocolateBolinho quente de chocolate meio amargo, com sorvete de creme.R$6,00R$5,00CÓDIGO BEBIDAS PREÇOR$10 Refrigerante3,0011 Água sem gásR$2,0012 Água com gásR$2,0013 RumR$6,0014 Chopp da BrahmaR$4,00Para utilizar os recursos do nosso GARÇOM ELETRONICO no seu celularacesse grátis o site www.garcomeletronico.com.br/downloade baixe já o seuFonte : Verdiana Pizzaria53

ANEXO 2 - CRONOGRAMA DE ATIVIDADESTabela 3 – Cronograma Primeiro SemestreTabela 4 – Cronograma Segundo Semestre54