Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas
ASKLUNCH:
APLICATIVO
PARA
PEDIDOS
E
GERENCIAMENTO
DE
MARMITAS
Jéssica Martins Nunes
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas
ASKLUNCH:
APLICATIVO
PARA
PEDIDOS
E
GERENCIAMENTO
DE
MARMITAS
Trabalho de Conclusão de Curso apresentado ao Instituto Federal de Goiás - Câmpus Jataí como um dos pré-requisitos necessários para aprovação no Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas.
Jéssica Martins Nunes
Orientador: Prof. Dr. Heverton Barros de Macêdo
Dados Internacionais de Catalogação na Publicação na (CIP)
NUN/ask
Nunes, Jéssica Martins.
Asklunch: aplicativo para pedidos e gerenciamento de marmitas / Jéssica Martins Nunes. -- Jataí: IFG, Coordenação dos cursos de Informática – Tecnologia em Análise e Desenvolvimento de Sistemas, 2018.
86; il.
Orientador: Prof. Dr. Heverton Barros de Macêdo. Bibliografias.
Apêndices.
1. Restaurante. 2. Marmita. 3. Android. 4. Mobile. I. Macêdo, Heverton
Barros de. II. IFG, Câmpus Jataí. III. Título.
CDD 005.43
Ficha catalográfica elaborada pela Seção Téc.: Aquisição e Tratamento da Informação. Bibliotecária – Rosy Cristina Oliveira Barbosa – CRB 1/2380 – Campus Jataí. Cód. F026/18.
Dedico este trabalho à minha família que sempre me deu suporte para prosseguir com os meus estudos.
Agradeço a Deus por me abençoar com saúde e sabedoria, a minha família por me dar apoio nos estudos, a meu orientador Heverton por compartilhar seu conhecimento, experiências e acreditar na minha capacidade, aos meus amigos Davi, Andra, Pâmela e Karolina pelo carinho, apoio e paciência, aos meus colegas Thiago, Gerbton e Stenio pelo companheirismo e troca de experiências na sala de aula, ao meu professor Leizer pela dedicação e empenho na elaboração e execução das aulas de TCC, e a toda equipe de professores da Coordenação de TADS que contribuíram para a minha formação.
“The people who are crazy enough to think they can change the world are the ones who do.” (Steve Jobs)
Este trabalho apresenta o desenvolvimento de um software para pedidos e gerenciamento do processo de produção a entrega de marmitas. É comum a demora no atendimento ao cliente pelo telefone, principalmente quando se tem apenas um funcionário realizando inúmeras tarefas ao mesmo tempo, além disso, o fato do funcionário desconhecer determinada região da cidade implica em atrasos na entrega e, consequentemente, na insatisfação dos clientes. O
software desenvolvido possibilita aos clientes de um restaurante solicitarem seus pedidos por
um aplicativo, haja vista que cada vez mais as pessoas têm usado seus smartphones para realizar diversas tarefas do dia-a-dia como pagar contas, fazer pesquisas, e solicitar suas refeições. Neste aspecto, este trabalho foi desenvolvido usando uma arquitetura cliente-servidor, sendo o cliente um aplicativo para dispositivos móveis e o servidor um aplicativo
web. Dentre os procedimentos adotados para o desenvolvimento do software é possível
destacar: o estudo de trabalhos similares e a observação dos processos de produção até a entrega de marmitas, tomando como base o restaurante Tradição Goiana – Jataí, GO. Espera-se que após a implantação do software, este diminua o tempo gasto de atendimento ao cliente, melhore a administração e o índice de vendas de marmitas do restaurante, e possibilite ao funcionário a realização de entregas de forma mais ágil. Além disso, acredita-se que a utilização do software permitirá aos usuários maior liberdade com relação à escolha dos produtos que irão compor a sua marmita e minimizará os erros cometidos no processo de montagem por parte dos funcionários.
This paper presents the development of a software for ordering takeaway food as well as its production and delivery process management. When only one employee happens to be performing many tasks at the same time, the delay in the customer service by phone is common. In addition to that, the employee may not know some regions of the city, which might cause delays and, consequently, customer dissatisfaction. Considering that using smartphones to perform several daily tasks, such as paying bills, web searches and buying meals is very common nowadays, the software we developed allows customers to use an application to place an order. Thus, this project was conducted based on a client-server architecture – in which the client is a mobile device application and the server, a web application. Among the procedures that were adopted for software development, it is possible to highlight: the study of similar projects and the observation of the processes from the production up to the delivery of takeaway food, using as a base Tradição Goiana Restaurant, a restaurant from Jataí-GO. After the software implementation, the reduction on the time spent during costumer service, improvements in the administration and sales index of takeaway food, as well as a reduction in delivery time are expected. In addition, it is believed that the use of the software will allow users greater freedom regarding the choice of products that will compose their takeaway and, also, reduce the errors in the takeaway assembly process by employees.
Figura 1 - Classe (Autoria Própria). 23 Figura 2 - Ações do Controlador Baseada nas Rotas (LARAVEL, 2O17). 37 Figura 3 – Relacionamento Cliente - Usuário (Autoria Própria) 45 Figura 4 – Relacionamento Cliente – Pedido (Autoria Própria) 46 Figura 5 – Relacionamento Pedido – Marmita (Autoria Própria) 48 Figura 6 - Relacionamento Pedido - Bebida / Pedido - Forma Pagamento (Autoria Própria) 49 Figura 8 - Requisição utilizando a biblioteca Volley (Autoria Própria) 53
Figura 9- Intent Entrar (Autoria Própria) 54
Figura 10- Tela de Login (Autoria Própria) 54
Figura 11- Tela de Menu (Autoria Própria) 55
Figura 12- Tela de Seleção de Itens da Marmita (Autoria Própria) 56 Figura 13- Tela de Fechamento do Pedido (Autoria Própria) 57
Figura 14- Tela de Pedidos em Rota (Autoria Própria) 58
Figura 15- Tela de Pedidos em Rota (Autoria Própria) 59
Figura 16- Modificação do providersusers no arquivo auth.php (Autoria Própria) 60 Figura 17 - Modelo Usuário adaptado para a autenticação por tabela diferente (Autoria
Própria) 60
Figura 18 – Relatório Total de Marmitas Vendidas no dia (Autoria Própria) 61 Figura 19 - Relatório cardápio do dia (Autoria Própria) 61 Figura 20 – Tela de Pedidos Recebidos (Autoria Própria) 62 Figura 21 – Tela de Pedidos em Andamento (Autoria Própria) 62 Figura 22 – Menu de Gerenciamento de Pedidos (Autoria Própria) 63
Tabela 1 – Tabela Comparativa ... 42 Tabela 2 – Classificação do Requisito Registrar Marmita ... 44
MER – Modelo Entidade-Relacionamento MVC – Model View Control
DER – Diagrama de Entidade-Relacionamento IBGE - Instituto Brasileiro de Geografia e Estatística UP – Unified Process
OO – Orientação a Objetos BD – Banco de Dados
IDE - Integrated Development Environment CASE - Computer Aided Software Engineering UML - Unified Modeling Language
HTML - HyperText Markup Language OMG - Object Management Group HTTP - Hypertext Transfer Protocol
UNIX - Un-multiplexed Information and Computing Service TI – Tecnologia da Informação
SQL - Structured Query Language DDL - Data Definition Language DML - Data Manipulation Language DCL - Data Control Language PHP - Hypertext Preprocessor XML - Extensible Markup Language
CAPÍTULO I ... 14 1. INTRODUÇÃO ... 14 1.1. Justificativa ... 15 1.2. Objetivo Geral ... 16 1.3. Objetivos Específicos ... 16 1.4. Metodologia ... 17 1.5. Organização do Trabalho ... 17 CAPÍTULO II ... 18 2. FUNDAMENTAÇÃO TEÓRICA ... 18 2.1. Introdução ... 18 2.2. Conceitos Iniciais ... 18 2.3. Processo Unificado ... 24
2.4. Programação para Android ... 28
2.5. Programação para Web com Laravel ... 34
CAPÍTULO III ... 39
3. TRABALHOS RELACIONADOS ... 39
3.1. Protótipo de um Aplicativo Android para Pedidos de Lanches e um Portal Web Para Gestão e Monitoramento ... 39
3.2. FASTLINE: Aplicativo mobile para lanchonetes ... 40
3.3. Implementação de um Aplicativo para Dispositivos Móveis: o FoodFeedBack ... 40
3.4. Implementação de um Sistema para Gestão de Bares Integrando Tecnologias Web e Mobile ... 40
3.5. Sistema para Gerenciamento de Lanchonetes ... 41
3.6. Sistema Web para Pedidos de Delivery ... 41
3.7. Tabela comparativa ... 42
CAPÍTULO IV ... 43
4. METODOLOGIA E/OU FERRAMENTAS UTILIZADAS ... 43
4.1. Fases de Concepção e Elaboração - Análise ... 43
4.2. Fase de Elaboração - Projeto ... 49
CAPÍTULO VI ... 64
6. CONCLUSÕES E TRABALHOS FUTUROS ... 64
REFERÊNCIAS BIBLIOGRÁFICAS ... 66
APÊNDICE A – ENTREVISTA ... 70
APÊNDICE B – VISÃO GERAL DO SISTEMA ... 73
APÊNDICE C – REQUISITOS FUNCIONAIS, NÃO FUNCIONAIS E SUPLEMENTARES ... 74
APÊNDICE D – DIAGRAMAS DA UML ... 81
APÊNDICE E – MODELO ENTIDADE-RELACIONAMENTO ... 83
CAPÍTULO
I
1.
INTRODUÇÃO
O hábito das pessoas de frequentarem restaurantes ou pedir comida pronta destes estabelecimentos para se alimentarem em suas residências ou locais de trabalho cresce cada vez mais, visto que estas têm diversas atividades para realizar e não podem perder tempo deslocando-se do serviço até suas casas; por possuírem um curto intervalo para o horário de almoço; ou ainda, por possuírem residências distantes dos seus locais de serviço, o que poderia gerar gastos maiores com deslocamentos do que com a alimentação fora de casa.
A inserção da mulher no mercado de trabalho, o aumento da renda familiar e a escassez de tempo para o preparo das refeições são alguns dos fatores que contribuem para o deslocamento da alimentação para fora do lar (JABS, 2006; GARCIA, 2003; SCHLINDWEIN, 2006 apud CARRIJO, 2013, p. 18).
Segundo o Instituto Brasileiro de Geografia e Estatística (IBGE), na Pesquisa Orçamentária Familiar (POF) de 2002-2003 o percentual gasto tanto na área urbana quanto rural com a alimentação fora do lar, era de 24,1%, já na POF de 2008-2009 este valor subiu para 31,1%.
Na Pesquisa Anual de Serviços (PAS) de 2014 realizada pelo IBGE (2014), estimava-se a existência de 250.118 empresas atuando nos serviços de alimentação, que incluem restaurantes, bares, lanchonetes, ambulantes e os fornecedores de comidas prontas. Enquanto que no PAS (2010) realizado pelo IBGE (2010), esse número era apenas de 193.309.
Nota-se que esse setor tende a crescer com o passar dos anos, porém assim como qualquer outro setor é necessário estar sempre inovando para atrair consumidores e manter a qualidade do serviço.
O aumento da concorrência e do consumo faz com que as empresas busquem novas soluções para melhorar e agilizar seu atendimento, exposição de seus produtos e serviços visando aumentar sua competitividade e destaque no mercado. Tendo em vista todas essas mudanças e a constante evolução dos computadores e celulares, as empresas fazem uso cada vez mais intensivo da tecnologia da informação (TI) como principal ferramenta de apoio estratégico em seus negócios (FINCOTTO, 2014, p. 151).
No âmbito tecnológico, cada vez mais as pessoas têm feito o uso de smartphones para realizarem suas tarefas do dia-a-dia por meio de aplicativos. Segundo o IBGE (2015), na
Pesquisa Nacional por Amostra de Domicílios (PNAD) no ano de 2008 o número de pessoas de 10 anos ou mais que tinham telefone móvel celular para uso pessoal era de 87.160.
A partir desses dados, podemos observar o constante crescimento do setor alimentício e que a tecnologia se torna um fator importante para o melhor gerenciamento das informações. Diante deste cenário, o desenvolvimento de um sistema que possa ser usado pelo aparelho celular se torna mais adequado, visto que este é o meio mais utilizado pelas pessoas atualmente para acessar a internet e solucionar os diversos problemas do dia-a-dia sem precisar deslocar-se até um determinado local, seja para fazer um pedido, pagar uma conta ou qualquer outra atividade. A utilização do software proposto possibilita o estabelecimento ter um novo meio de conquistar seus clientes e até mesmo de atrair novos, justamente pela praticidade e agilidade que este canal de comunicação oferece.
Alguns trabalhos voltados para o ramo alimentício como o FoodFeedBack (MAESATO; VIEIRA; TABALIPA, 2016), PedidosAki (FONTANA JUNIOR, 2013) e Fastline (MELO; RIBEIRO; LUCAS, 2015), não tratam especificamente do gerenciamento de marmitas e não oferecem suporte para quem irá realizar as entregas, o que os tornam diferentes do software batizado como AskLunch, proposto no presente trabalho. Este, permite aos clientes de restaurantes efetuarem seus pedidos de marmita via aplicativo com a possibilidade de personalizá-las retirando os itens indesejados. Além disso, o AskLunch conta com uma área para o entregador na qual ele poderá visualizar as rotas dos endereços de entrega dos clientes. Para gestão dos pedidos desenvolveu-se uma aplicação web em que os funcionários de restaurantes possam gerenciar os pedidos da concepção à entrega dos mesmos, e também gerar relatórios. Almeja-se que o software contribua para o aumento das vendas no restaurante, permita a entrega de marmitas de forma mais ágil e auxilie o cliente a ter liberdade de escolha na seleção dos componentes de sua marmita.
1.1. Justificativa
A Tecnologia da Informação (TI) tem contribuído para maior destaque das empresas no mercado em meio à grande concorrência e competitividade deste (FINCOTTO, 2014). Alinhado a isto o acesso à internet pelo telefone móvel ultrapassou o acesso pelo microcomputador em 2014 (IBGE, 2015). Com isto, as empresas têm disponibilizado serviços por meio de aplicativos para que as pessoas possam realizar diversas atividades sem precisar deslocar-se até os estabelecimentos.
Há diversos aplicativos delivery no mercado para a solicitação de fast-foods, mas a maioria com funcionalidades genéricas, ou seja, que atende desde um estabelecimento que trabalha com a venda de pizzas a um restaurante self-service. A utilização de um aplicativo direcionado especificamente para a venda de marmitas permite maior flexibilidade para o cliente e melhor gerenciamento para a empresa, visto que os clientes podem personalizar suas marmitas retirando os itens indesejáveis em sua composição; e a empresa tem a possibilidade de controlar todo o processo de forma detalhada da concepção à entrega de seus produtos.
Além disso, um aplicativo que provê suporte para o funcionário que realizará as entregas, disponibilizando informações relevantes do pedido e uma rota até o endereço de entrega, possivelmente melhorará o tempo gasto de atendimento ao cliente visto que o funcionário não perderá mais tempo procurando um local desconhecido por ele.
O desenvolvimento de um software como o AskLunch pode trazer benefícios tanto para o cliente como para o restaurante. O cliente se beneficia pela liberdade de escolher os itens de sua marmita utilizando a flexibilidade de um aplicativo para celular. O restaurante consegue melhorar a gestão dos pedidos e facilitar as entregas, uma vez que o aplicativo apresenta ao entregador a localização do endereço do cliente em um mapa.
1.2. Objetivo Geral
Desenvolver um aplicativo para pedido e gerenciamento de marmitas para restaurantes com o objetivo de melhorar o atendimento ao cliente e o controle de marmitas do restaurante, tendo como base para a tomada de decisões o Restaurante Tradição Goiana de Jataí/GO.
1.3. Objetivos Específicos
✓ Proporcionar ao restaurante uma nova forma de oferta e comercialização de seus produtos;
✓ Proporcionar ao entregador a virtualização da rota com o endereço de entrega do cliente.
✓ Possibilitar a diminuição do tempo gasto no atendimento ao cliente; ✓ Possibilitar o aumento do índice de vendas de marmitas;
1.4. Metodologia
Este trabalho se classifica como uma pesquisa tecnológica, pois tem como resultado à materialização de um produto (SOUZA et al., 2013). A pesquisa tecnológica parte de um conhecimento pré-existente e, através da pesquisa e/ou experiência prática, busca a produção de novos materiais, produtos e aparelhagens, novos processos, sistemas e serviços ou aperfeiçoamento de sistemas, processos já existentes (SOUZA et al., 2013, p. 14).
Por se tratar do desenvolvimento de um produto de software, adotou-se a metodologia Unified Process (UP), na qual utilizou-se entrevistas não estruturadas para o levantamento de requisitos e linguagens de programação, base de dados e ambientes de desenvolvimento amplamente utilizados pelos desenvolvedores de software.
1.5. Organização do Trabalho
O trabalho está dividido em seis capítulos, organizados da seguinte forma:
Capítulo I – Introdução: Apresenta o estado da arte acerca do tema, justificativa, objetivos, uma breve descrição da metodologia adotada e da organização dos capítulos deste trabalho.
Capítulo II – Fundamentação teórica: Aborda os conceitos básicos do desenvolvimento para aplicativos móveis, API’s, dentre outros.
Capítulo III – Trabalhos relacionados: Aborda sobre alguns trabalhos correlatos.
Capítulo IV – Metodologia: Descreve a arquitetura do sistema, as técnicas e ferramentas utilizadas para a implementação da interface, modelagem e programação.
Capítulo V – Implementação: Apresenta uma descrição do software desenvolvido.
Capítulo VI – Conclusões e trabalhos futuros: Apresenta as conclusões e sugestões de trabalhos futuros.
CAPÍTULO
II
2.
FUNDAMENTAÇÃO
TEÓRICA
2.1. Introdução
Este capítulo aborda os principais conceitos de programação orientada a objetos, processo unificado, Unified Modeling Language (UML), web services, desenvolvimento para Android, desenvolvimento web, dentre outros, os quais são necessários para a compreensão deste trabalho.
A seguir são apresentados primeiramente os conceitos básicos de programação, banco de dados e modelagem para que posteriormente, seja possível compreender as fases da metodologia Unified Process (UP) e sua relação com o trabalho. Em seguida, são apresentados os conceitos específicos da linguagem JAVA para dispositivos móveis e a linguagem PHP para web, responsável por fazer o pré-processamento de hipertextos (PHP:
Hypertext Preprocessor).
2.2. Conceitos Iniciais
2.2.1. Introdução à Programação
Um “programa consiste em um conjunto organizado de instruções que operam sobre um conjunto de dados, processando-os, a fim de realizar alguma funcionalidade e produzir uma saída” (SILVA FILHO, 2011, p. 1). De acordo com Silva Filho (2016), os programas podem ser construídos utilizando uma abordagem procedural ou orientada a objetos em que, a primeira faz o uso de funções para a construção de um programa e a segunda faz o uso de objetos.
2.2.2. Programação Orientada a Objetos (POO)
“A Orientação a Objetos (OO) é uma técnica de programação que se baseia na construção e utilização de objetos. [...] Um sistema OO é um conjunto de objetos que se inter-relacionam para produzir os resultados desejados” (JANDL JUNIOR, 2015, p. 87).
Esta foi a técnica adotada para a implementação do AskLunch, tanto para sua versão mobile quanto para sua versão web. Portanto, para compreender como este software foi desenvolvido é necessário ter conhecimento de alguns conceitos básicos do paradigma OO.
O primeiro e mais básico conceito do paradigma de OO é o de objetos. Um objeto é composto de dados e operações as quais definem suas responsabilidades. (JANDL JUNIOR, 2015). Estas definições são feitas por meio das classes, que são modelos que descrevem os objetos com suas características (atributos) e comportamentos (métodos). (JANDL JUNIOR, 2015).
Uma classe é composta por atributos e métodos, o primeiro se refere às características de um objeto os quais são responsáveis por definir o estado (valor) do objeto (SINTES, 2002) e, o segundo, às ações executadas “por um objeto quando passada uma mensagem ou em resposta a uma mudança de estado” (SINTES, 2002, p. 8). Segundo SINTES (2002), tanto os atributos quanto os métodos possuem modificadores de acesso os quais definem o escopo de cada um, são eles:
● private (privado): visível apenas para a própria classe.
● protected (protegido): visível para todas as classes de um mesmo pacote. ● public (público): visível para todas as classes da estrutura.
Os métodos “construtores são usados para inicializar objetos durante sua instanciação” (SINTES, 2002, p. 10). Após sua criação, a interação entre eles é feita por troca de mensagens, ou seja, é feita a chamada de métodos. (SILVA FILHO, 2011).
O paradigma de orientação a objetos é composto por três pilares, os quais são explanados a seguir.
2.2.2.1. Encapsulamento
O encapsulamento ou ocultação da informação, é uma técnica que consiste em separar aspectos externos dos internos da implementação de um objeto, isto é, determinados detalhes ficam ocultos aos demais objetos e dizem respeito apenas ao próprio objeto (LIMA, 2011, p. 25). Sendo assim, todas as classes do software AskLunch foram construídas com seus atributos encapsulados utilizando-se dos métodos set e get para atribuição e acesso aos estados do objeto, respectivamente.
2.2.2.2. Herança
“Herança é um mecanismo que permite basear uma nova classe na definição de uma classe previamente existente. Usando herança, a nova classe herda os atributos e comportamentos presentes na classe previamente existente [...]”. (SINTES, 2002, p. 72).
Utilizou-se desse recurso para utilização de classes já existentes nas linguagens de programação JAVA e PHP para a simplificação do processo de desenvolvimento com a técnica de reutilização de código.
2.2.2.3. Polimorfismo
De acordo com Sintes (2002, p. 122), “polimorfismo significa muitas formas. Em termos de programação, muitas formas significa que, um único nome pode representar um código diferente”. Sendo assim, o polimorfismo permite que um único nome expresse muitos comportamentos diferentes. Segundo este autor, o polimorfismo pode ser classificado de diversas formas, sendo as mais relevantes para o trabalho em questão as citadas abaixo:
Sobrescrita (override) ou Sobreposição: quando uma classe derivada contém métodos com a mesma assinatura da classe de origem, mas possui comportamentos diferentes. Sobrecarga (overload): quando os métodos de uma classe têm o mesmo nome, mas
possuem argumentos e/ou tipo de retorno diferentes.
No decorrer do desenvolvimento do AskLunch foram utilizadas as duas técnicas de polimorfismo, mas principalmente o de sobrescrita na fase de construção do módulo do aplicativo para o entregador, em que foram sobrescritos os métodos da API Google Maps.
2.2.3. Introdução à Banco de Dados
Banco de dados (BD) é um “conjunto de dados interrelacionados, organizados de forma a permitir que sistemas de aplicação armazenem novos dados, encontrem dados armazenados, alterem seu conteúdo e excluam dados indesejáveis por meio de métodos precisos de manipulação e localização” (FEITOSA, 2013, p. 14).
Para a persistência dos dados do software AskLunch, utilizou-se o Sistema Gerenciador de Banco de Dados (SGBD) MySQL, um sistema gerenciador de banco de dados relacional e de código aberto (MYSQL, 2017).
De acordo com o ranking DB-Engines (2018) criado e mantido pela Solid IT, empresa austríaca de consultoria de Tecnologia da Informação (TI), nos sistemas de gerenciamento de banco de dados de acordo com sua popularidade o MySQL se encontrava na segunda posição no mês de fevereiro de 2018.
Para a definição da estrutura e operações do BD foi utilizada a Structured Query
Language (SQL), ou Linguagem de Consulta Estruturada a qual subdivide-se em três
categorias principais: Data Definition Language (DDL),Data Manipulation Language (DML) e Data Control Language (DCL), sendo as mais relevantes para o trabalho as citadas por Prescott (2015):
1. DDL - Linguagem de definição de dados utilizada para manipular a estrutura da base de dados a qual foi utilizada para a criação da base de dados e suas tabelas. Dentre seus principais comandos pode-se destacar:
CREATE - utilizado para criação de tabelas e outros objetos;
ALTER - utilizado para alterar estruturas de bancos de dados, principalmente tabelas. DROP - Excluir objetos, principalmente tabelas e bases de dados.
2. DML - Linguagem de Manipulação de Dados utilizada para manipular dados a qual foi aplicada para manusear os cadastros e relatórios do sistema. Dentre seus principais comandos destacam-se:
SELECT - seleciona dados de tabelas. INSERT - insere dados em uma tabela.
UPDATE - atualiza os dados existentes dentro de uma tabela.
DELETE - exclui linhas de uma tabela, mantendo espaço para os registros.
2.2.4. Introdução à UML
“Segundo a especificação do Object Management Group(OMG), a UML ‘é uma linguagem para especificação, construção, visualização e documentação de artefatos de um sistema de software intensivo’” (LIMA, 2011, p. 30).
“A UML é extensível e independente de processos ou linguagens de programação, [...] pois utiliza uma notação padrão” (LIMA, 2011, p. 30). Segundo Lima (2011), a UML possui quinze diagramas divididos em dois grupos:
Diagramas estruturais: “que descrevem os elementos estruturais que compõem o sistema, representando suas partes e seus relacionamentos”(LIMA, 2011, p. 34).
Diagramas de comportamento ou dinâmicos: “que descrevem o comportamento dos elementos e suas interações” (LIMA, 2011, p. 34).
“A UML representa o sistema em cinco visões: visão de caso de uso, visão lógica, visão de processo, visão de implementação e visão de implantação” (LIMA, 2011, p. 38). Estas “podem ser vistas como abstrações dos modelos, em que cada visão dá importância a um determinado aspecto do sistema, deixando os demais de lado” (LIMA, 2011, p. 38).
2.2.4.1. Diagrama de Caso de Uso
“A visão de caso de uso mostra conceitualmente o conjunto de funções que o sistema deve executar para atender aos requisitos do cliente, servindo como um contrato entre o cliente e o desenvolvedor” (LIMA, 2011, p. 55).
Um caso de uso é representado por uma elipse conectada a símbolos de atores. O retângulo mostra os limites (fronteiras) do sistema, contendo em seu interior o conjunto de casos de uso e, do lado externo, os atores interagindo com o sistema. Cada linha entre um ator e uma elipse de caso de uso mostra uma associação entre eles. (LIMA, 2011, p. 57).
Um diagrama de casos de uso é composto por três elementos essenciais, são eles: Ator: “representa um papel executado por uma entidade que envia ou recebe
informações do sistema. [..] É sempre externo ao sistema e pode representar papéis executados por usuários humanos, hardware externo ou outros sistemas” (LIMA, 2011, p. 60).
Associação: indica as interações entre os atores e os casos de uso com o objetivo de invocar um caso de uso, solicitar dados armazenados, modificar dados ou informar algum acontecimento para o sistema. (LIMA, 2011)
Caso de uso: “é a descrição de sequências de ações realizadas pelo sistema que proporciona resultados observáveis de valor para um determinado ator” (BOOCH; RUMBAUGH; JACOBSON, 2005, p. 20).
2.2.4.2. Diagrama de Classes
“O diagrama de classe mostra a estrutura estática do modelo, em que os elementos são representados por classes, com sua estrutura interna e seus relacionamentos” (LIMA, 2011, p. 207)
O diagrama de classes é composto por entidades (classes) que descrevem um conjunto de objetos similares, com suas características (atributos) e comportamentos (métodos) e as relações destes no contexto de um sistema.
Segundo a documentação da UML pelo OMG, “uma classe descreve um conjunto de objetos que compartilham as mesmas especificações de atributos, operações, restrições e semântica”. A finalidade de uma classe é classificar objetos e especificar os recursos que caracterizam a estrutura e o comportamento desses objetos (LIMA, 2011, p. 208).
Uma classe é representada por um retângulo comtrês compartimentos, em que o: ● Primeiro - Contém o nome da classe com alinhamento centralizado, estilo
negrito e a primeira letra maiúscula (Figura 1).
● Segundo - Contém o modificador de acesso (-) privado, (+) público ou (#) protegido; o nome do atributo seguido por dois pontos e o tipo de dados (Figura 1).
● Terceiro - Contém o modificador de acesso (-) privado, (+) público ou (#) protegido; nome do método, parâmetros entre parênteses (quando há) seguido de dois pontos e tipo de retorno (void, int, float, String, etc.) (Figura 1).
Figura 1 - Classe (Autoria Própria).
Após a definição das classes é necessário “determinar como estas associam-se, isto é, como dependem uma das outras para cumprir suas responsabilidades e suprir o comportamento necessário” (LIMA, 2011, p. 217). São representadas por uma linha reta entre as classes (associação simples), as quais podem ou não possuir setas em uma das extremidades para indicar outros tipos de associações como agregação, composição e herança. Além disso, é na associação entre classes que se define a multiplicidade (cardinalidade) para especificar o número de instâncias de objetos que participam da mesma (LIMA, 2011).
2.2.5. Modelo Entidade-Relacionamento
Segundo Leite (2008, p. 6), “o modelo relacional mais empregado para descrever como os dados estão armazenados no banco de dados é chamado Modelo Entidade-Relacionamento – MER”. Ele é composto por quatro elementos essenciais: entidades, atributos, relacionamentos e cardinalidades os quais são explanados sucintamente a seguir.
● Entidade: “É algo concreto ou abstrato, de interesse na análise do sistema, e que possa armazenar dados a seu respeito” (LEITE, 2008, p. 9). É representada por um retângulo no Diagrama de Entidade-Relacionamento (DER).
● Atributos: “Representam as características de uma entidade”(LEITE, 2008, p. 10) e são representados por elipses no DER.
● Relacionamentos: são as ligações entre as entidades representados por uma linha com um losango no centro (LEITE, 2008).
● Cardinalidade: “é a quantificação do relacionamento entre duas entidades, e pode ser entendida como sendo o ‘número de ocorrências de determinada entidade, associado
a uma ocorrência da outra entidade relacionada’” (LEITE, 2008, p. 14).
2.2.6. Ferramentas Case
As ferramentas CASE (Computer Aided Software Engineering) “surgiram para apoiar as atividades de desenvolvimento, proporcionando qualidade e produtividade ao
software” (HIRAMA, 2012, p. 151).
Para a elaboração dos diagramas do software AskLunch foram utilizadas as ferramentas Astah Professional com licença para estudantes e o Dia que é uma ferramenta
opensource (código aberto).
2.3. Processo Unificado
Para o desenvolvimento do software AskLunch adotou-se a metodologia Unified
Process (UP), “uma metodologia para engenharia de software orientada a objetos usando a
UML” (PRESSMAN, 2011, p. 72). A metodologia UP “e a UML são amplamente utilizadas em projetos orientados a objetos de todos os tipos. O modelo incremental e iterativo proposto pelo PU pode e deve ser adaptado para atender necessidades de projeto específicas” (PRESSMAN, 2011, p. 72). Nesse seguimento, Wazlawick (2011, p. 5) define que “o UP
pode ser realizado como um processo ágil, com poucos artefatos e burocracia, permitindo o desenvolvimento de software de forma eficiente [...]”.
O UP é composto por quatro fases, sendo elas: concepção, elaboração, construção e transição. Em suma, ”a fase de concepção incorpora o estudo de viabilidade, o levantamento dos requisitos e uma parte da sua análise” (WAZLAWICK, 2011, p. 5). A fase de elaboração incorpora o detalhamento da análise de requisitos, a modelagem de domínio e o projeto (WAZLAWICK, 2011). “A fase de construção corresponde à programação e testes, e a fase de transição consiste na instalação do sistema e migração de dados” (WAZLAWICK, 2011, p. 5).
Neste sentido, a seguir são apresentadas as atividades realizadas em cada etapa do Processo Unificado para a construção do software AskLunch.
2.3.1. Fases de Concepção e Elaboração – Análise
A fase de concepção é a primeira fase do processo unificado, a qual o desenvolvedor tem o primeiro contato com o cliente a fim de entender qual é o problema a ser solucionado de uma forma abrangente. Neste momento é elaborado um relatório sucinto a respeito do problema bem como a viabilidade de dar prosseguimento no projeto com análise das condições técnicas, financeiras, de cronograma dentre outros. (WAZLAWICK, 2011)
Segundo Wazlawick (2011, p. 21), “a etapa de levantamento de requisitos corresponde a buscar todas as informações possíveis sobre as funções que o sistema deve executar e as restrições sobre as quais o sistema deve operar”. O artefato gerado nesta etapa é “o documento de requisitos, principal componente do anteprojeto de software” (WAZLAWICK, 2011, p. 21),“que registra todos os tópicos relativos ao que o sistema deve fazer e sob quais condições” (WAZLAWICK, 2011, p. 26).
O analista pode e deve utilizar todas as informações disponíveis para identificar as fontes de requisitos (departamentos, pessoas, clientes, interfaces, sistemas etc.) e, para cada fonte, identificar as funções que o sistema deverá disponibilizar. (WAZLAWICK, 2011, p. 21)
Segundo Wazlawick (2008), o passo seguinte ao levantamento de requisitos é o da organização destes em:
a) Casos de Uso: são “os principais processos de negócio da empresa” (WAZLAWICK, 2008, p. 44).
b) Conceitos: são os conceitos envolvidos com o sistema que geralmente possuem quatro operações básicas: inserção, alteração, exclusão e consulta (WAZLAWICK, 2008).
c) Consultas: são operações de acesso a informação que não alteram a base de dados (WAZLAWICK, 2008, p. 45).
Ainda segundo Wazlawick (2008, p. 45), “alguns autores sugerem que todas as interações possíveis com o sistema devem ser representadas como casos de uso, inclusive as consultas”.
Por fim, é feito o planejamento dos ciclos iterativos os quais são miniprojetos que se baseiam nos casos de uso, conceitos e consultas definidos anteriormente. Para miniprojeto é estipulado um tempo para desenvolvimento chamados ciclos, os quais envolvem as etapas de análise, projeto, implementação e testes por se tratar de uma metodologia iterativa e incremental. De acordo com o avanço dos ciclos, menor será a complexidade do trabalho visto que as funcionalidades mais complexas do software são colocadas nos primeiros ciclos (WAZLAWICK, 2008).
A etapa de planejamento dos ciclos possui como artefato um cronograma de execução o qual deve ser construído analisando o tempo total estimado para o projeto em hora ou por pessoa, o tempo disponível em semanas ou meses, o tamanho e estruturação da equipe e seguir um padrão cíclico (WAZLAWICK, 2008).
A etapa subsequente da concepção é a fase de elaboração, a qual comporta atividades de análise e projeto. No escopo de análise esta possui três subatividades distintas, sendo elas:
a) Expansão dos casos de uso e determinação dos eventos e respostas de sistema; b) Construção ou refinamento do modelo conceitual;
c) Elaboração dos contratos das operações e consultas de sistema.
As Fases de Concepção e Elaboração do AskLunch estão disponíveis na Seção 4.1.
2.3.2. Fase de Elaboração - Projeto
Segundo Wazlawick (2011, p. 193), o projeto do software visa produzir uma solução para o problema que, nessa etapa, já deve estar suficientemente esclarecido pela análise. É subdivido em projeto lógico e tecnológico; o primeiro compreende a evolução dos
diagramas criados na fase anterior; e o segundo, os aspectos do problema que são inerentes à tecnologia empregada como interface, armazenamento de dados, comunicação, dentre outros.
No desenvolvimento do AskLunch, não houve alteração nos diagramas construídos na fase de concepção na etapa do projeto lógico. Já no projeto tecnológico, foram definidas as linguagens de programação, ambientes de desenvolvimento, base de dados, bibliotecas, pacotes, frameworks, dentre outros.
2.3.3. Construção
Segundo Wazlawick (2011, p. 291), “a fase de construção do UP prevê a geração e código e testes do sistema”. É gerado “código tanto para a camada de domínio, resultante do projeto lógico, quanto para as demais camadas, resultantes do projeto tecnológico” (WAZLAWICK, 2011, p. 291). Quanto aos testes estes se classificam quanto aos objetivos em:
a) Teste de unidade: verificar o funcionamento dos métodos implementados; b) Teste de integração: verificar se a comunicação entre objetos funciona;
c) Teste de sistema: verificar a execução do sistema do ponto de vista do usuário final;
d) Teste de aceitação: teste conduzido pelos usuários finais;
e) Teste de operação: teste conduzido pelos administradores do sistema no ambiente final;
f) Teste de regressão: aplicado quando novas versões do software são liberadas. (WAZLAWICK, 2011, p. 308)
No decorrer do processo de desenvolvimento, foram efetuados testes de integração do sistema utilizando a estratégia baseada em uso, a qual inicia a construção do sistema testando as classes independentes e, em seguida, as classes dependentes até que todo o sistema seja construído (PRESSMAN, 2011).
2.3.4. Transição
Esta é a última fase do processo unificado a qual abrange as atividades de construção e implantação. Segundo Pressman (2011), nesta fase são criados manuais e procedimentos de instalação; o software é dado aos usuários finais para testes beta; e relatórios de feedback são gerados para que possam ser feitas as modificações no sistema se caso necessário. Na conclusão dessa fase tem-se uma versão utilizável do software.
Esta fase não faz parte do escopo deste trabalho, visto que o software não foi implantado no estabelecimento.
2.4. Programação para Android 2.4.1. Android
De acordo com Tanenbaum (2009, p. 21), um software basicamente subdivide-se em “[...] programas de sistemas, que gerenciam a operação do computador em si, e programas aplicativos, que realizam o trabalho real desejado pelo usuário [..]”. O sistema operacional é o programa responsável por “[...] controlar todos os recursos do computador e fornecer uma base sobre a qual os programas aplicativos possam ser escritos [...]” (TANENBAUM, 2009, p. 21). Um dos sistemas operacionais para dispositivos móveis, atualmente líder mundial nesse segmento, é o Android, criado pela Google (LECHETA, 2016).
Uma pesquisa realizada pela Gartner (2017), empresa de consultoria em tecnologia da informação, divulgou que no mercado de sistemas operacionais de smartphones, o Android do Google abriu sua liderança ao capturar 82% do mercado total no quarto trimestre de 2016. Em 2016, o Android também aumentou sua participação de mercado em 3,2 pontos percentuais para atingir uma participação de 84,8% e foi o único sistema operacional que aumentou a participação no mercado ano a ano.
No Android,“uma versão do sistema operacional é conhecida como plataforma” (LECHETA, 2016, p. 34). Sendo assim, há diversas plataformas diferentes do Android iniciando da 1.0 a 8.0 (DEVELOPERS, 2017).
“Cada plataforma tem um código identificador, chamado de API Level” (LECHETA, 2016, p. 34). A API Level serve para determinar quais serão os dispositivos-alvo no desenvolvimento do aplicativo. A API Level se inicia no level 1 que corresponde a primeira plataforma do Android 1.0 até a API Level X (LECHETA, 2016). Em fevereiro de 2018, a última API Level era a 27 que correspondente à plataforma 8.1 (DEVELOPERS, 2018).
O Android possui um kit para o desenvolvimento de aplicações conhecido como Android SDK, o qual contém “um emulador para simular o dispositivo, ferramentas utilitárias e uma API completa para a linguagem Java, com as classes necessárias para desenvolver as aplicações” (LECHETA, 2016, p. 33).
O emulador do Android também conhecido como Android Virtual Device (AVD) é responsável por simular a “configuração de um smartphone ou tablet Android com
exatamente a mesma plataforma do sistema operacional, resolução de tela e outras configurações” (LECHETA, 2016, p. 49).
O Android Studio é a IDE oficial para o desenvolvimento de aplicativos Android. Criada especificamente para o Android, esta oferece ferramentas personalizadas para desenvolvedores do Android, incluindo ferramentas avançadas para edição, depuração, testes e geração de perfis de código (DEVELOPERS, 2017). A versão padrão para download no site oficial já possui o SDK e AVD embutidos.
2.4.2. Desenvolvimento para Android
Segundo Lecheta (2016), para a criação de um aplicativo simples e bem estruturado é necessário possuir uma classe, um arquivo de layout e um arquivo de configuração. A seguir são apresentados de forma sucinta cada um destes elementos.
2.4.2.1. Activity
Segundo Lecheta (2016), uma activity é uma classe Java que representa uma tela da aplicação e é responsável por controlar os eventos da tela e definir qual arquivo de layout será responsável por desenhar a interface gráfica do usuário. A activity possui um ciclo de vida, isto é, os possíveis estados que ela assume. O próprio sistema operacional se encarrega de gerenciar este ciclo, porém para desenvolver aplicações mais robustas é importante conhecer os estados que ela assume. A seguir são apresentadas de forma sucinta cada um dos estados de uma activity:
onCreate (bundle): Método “obrigatório e chamado uma única vez. O objetivo desse método é fazer a inicialização necessária para executar a aplicação” (LECHETA, 2016, p. 87). É o local onde define-se o layout de configuração da tela.
onStart: “é chamado quando a activity está ficando visível ao usuário e já tem uma view” (LECHETA, 2016, p. 87).
onRestart: “é chamado quando uma activity foi parada temporariamente e está sendo iniciada outra vez” (LECHETA, 2016, p. 87).
onResume: “é chamado quando a activity está no topo da pilha ‘activitystack’, e dessa forma já está executando como activity principal e interagindo com o usuário” (LECHETA, 2016, p. 87).
onPause: é chamado quando a activity é interrompida com algum evento tais como pressionamento do botão home, recebimento de uma chamada telefônica, dentre outros (LECHETA, 2016).
onStop: “é chamado logo depois do método onPause() e indica que a activity está sendo encerrada, e não está mais visível ao usuário” (LECHETA, 2016, p. 88).
onDestroy: encerra a execução de uma activity. É retirada da pilha e seu processo no sistema operacional é completamente encerrado. (LECHETA, 2016).
Por padrão ao criar uma activity no Android Studio, a IDE automaticamente sobrescreve o método onCreate. Sendo assim, durante o processo de desenvolvimento do
software AskLunch, foi necessário sobrescrever os demais métodos apenas em algumas activities como, por exemplo, a activity responsável por fazer a comunicação com a API
Google Maps.
2.4.2.2. Arquivo de Layout - Views e Layout
Cada activity está vinculada a um arquivo de layout o qual é definida sua interface para o usuário. Um arquivo de layout é escrito em XML (Extensible Markup Language) e composto por widgets e layouts, ambos que herdam diretamente da classe View (LECHETA, 2016). “A classe android.view.View é a classe-mãe de todos os componentes visuais do Android, e suas diversas subclasses são utilizadas para criar a interface gráfica do aplicativo” (LECHETA, 2016, p. 120). Os widgets são componentes simples como Button (botão), EditText (campo texto), TextView (rótulo), dentre outros adicionados sob um layout o qual determina como estes serão exibidos. De acordo com Lecheta (2016), as principais classes de
layout são:
AbsoluteLayout: permite posicionar os componentes dadas as coordenadas x e y. Está descontinuada (deprecated) e não deve ser utilizada.
FrameLayout: tipo mais comum e simples de layout. Funciona como uma pilha, sendo que uma view fica por cima da outra.
LinearLayout: utilizado para organizar os componentes na vertical ou horizontal. TableLayout: é filho de LinearLayout e pode ser utilizado para organizar os componentes em uma tabela, com linhas e colunas.
RelativeLayout: permite posicionar um componente relativo a outro, por exemplo, abaixo, acima ou ao lado de um componente já existente (LECHETA, 2016, p. 121).
Além destes citados acima, existe também a classe ConstraintLayout que é similar a classe RelativeLayout em termos de organização dos componentes, mas que permite posicionar e dimensionar widgets de forma mais flexível (DEVELOPERS, 2017).
Na codificação do software AskLunch, algumas activities tiveram seu layout implementado totalmente no arquivo XML, outras com sua base no arquivo XML e o restante por linhas de código em Java, e algumas com sua codificação totalmente na linguagem Java.
2.4.2.3. AndroidManifest
“O arquivo AndroidManifest.xml é a base de uma aplicação Android e contém todas as configurações do aplicativo” (LECHETA, 2016, p. 63). Cada activity criada deve constar no arquivo de manifesto por meio da tag<activity>; por padrão o Android Studio as adiciona automaticamente a este arquivo. Neste arquivo também são definidas as permissões necessárias para o uso do aplicativo por meio da tag<permission>, como por exemplo, permissão de acesso a localização, acesso à internet, câmera, microfone, dentre outras (LECHETA, 2016).
No aplicativo AskLunch foi necessário acrescentar apenas as permissões de acesso a localização e a internet, e a adição da chave de acesso a API Google Maps, pois o restante das configurações a própria IDE Android Studio se encarrega de criar e atualizar a lista de activities a medida em que são geradas no projeto.
2.4.2.4. Intent
Segundo Developers (2017), a Intent é um objeto de mensagem que pode ser usado para solicitar uma ação de outro componente de aplicativo. Embora os intents facilitem a comunicação entre componentes de diversos modos, há três casos de uso fundamentais:
● Para iniciar uma activity: É possível iniciar uma nova instância de uma Activity passando uma Intent para startActivity()
● Para iniciar um serviço: É possível realizar operações em segundo plano sem interface do usuário passando uma Intent para startService().
● Para fornecer uma transmissão: Transmissão é uma mensagem que qualquer aplicativo pode receber e as intents podem transmitir mensagens a outros aplicativos por meio dos métodos sendBroadcast(), sendOrderedBroadcast() .
As Intents foram utilizadas no AskLunch apenas para iniciar activities, pois os serviços da API Google Maps foram inicializados por meio de classes fornecidas pela própria API.
2.4.2.5. Web Services
Segundo Lecheta (2016), o aplicativo não deve se comunicar diretamente com o banco de dados por questões de segurança e padronização de acesso, portanto, o aplicativo deve fazer o uso de um web service para buscar as informações no servidor. “A responsabilidade do web service é acessar o banco de dados, processar as informações e retornar os dados no formato XML ou JSON para o mobile/cliente ler os dados” (LECHETA, 2016, p. 260). Sendo assim, foi desenvolvido um web service para o software AskLunch, utilizando páginas simples com GET e POST na linguagem de programação PHP com retorno dos dados em formato JSON.
2.4.2.6. Google Maps API Android
Segundo Developers (2017), a API do Google Maps para Android fornece recursos que possibilitam ao desenvolvedor construir mapas dentro de sua aplicação. Os mapas são representados pelas classes GoogleMap e MapFragment. Sendo que a primeira, dá acesso a todos os métodos relacionados ao mapa e a segunda é um fragmento de mapa o qual viabiliza uma forma mais simples de colocar mapas em um aplicativo.
Ainda segundo Developers (2017), para adicionar um mapa no aplicativo é necessário seguir quatro passos básicos:
1. Criar um projeto no Google API Console. a. Ativar o Google Maps API Android; b. Gerar uma chave de acesso.
c. Retornar ao aplicativo, adicionar a chave de acesso e permissão de acesso a localização (caso o aplicativo tenha acesso a localização do usuário) ACCESS_FINE_LOCATION e/ou ACCESS_COARSE_LOCATION no arquivo de configuração AndroidManifest.xml
2. Adicionar o elemento <fragment> no arquivo de layout da classe que processará o mapa.
3. Implementar a interface OnMapReadyCallback, a qual possui o método de retorno onMapReady(GoogleMap) que é chamado quando o mapa está pronto para ser utilizado.
4. Utilizar a função getMapAsync() no fragmento para registrar o retorno de chamada.
Para a execução dos passos listados acima é necessária a instalação do Android SDK (kit de desenvolvimento para a plataforma Android) para que seja possível instalar e configurar o Google Play Services o qual fornece a API do Google Maps para o Android. A configuração do Google Play Services consiste apenas em adicionar o comando compile 'com.google.android.gms:play-services:11.4.2' nas dependências do arquivo build.gradle do projeto e sincronizar (DEVELOPERS, 2017).
Esta API foi utilizada no aplicativo mobile para representar o mapa com marcadores no cadastro de cliente para a confirmação do endereço, e com as rotas dos endereços para o funcionário responsável por realizar as entregas.
2.4.2.7. Google MapsDirections API
Segundo Developers (2017), o Google MapsDirections API é um serviço que calcula rotas entre locais o qual permite buscar rotas para diversos modos de transporte, incluindo transporte público, condução, caminhada ou bicicleta. O acesso a API é feito mediante a uma requisição HTTP com a seguinte URL:
https://maps.googleapis.com/maps/api/directions/json?origin=LOCAL_DE_ORIGEM&destin ation=LOCAL_DE_DESTINO&key=CHAVE_DA_API
a qual obtém rotas entre o endereço de origem e destino, tempo estimado e distância em quilômetros no formato JSON. Os parâmetros origin e destination aceitam valores de strings ou coordenadas de latitude e longitude. Contudo, para obter êxito na solicitação HTTP é necessário criar um projeto no Google API Console, ativar a API e gerar chave de acesso no projeto criado.
Este serviço foi utilizado no aplicativo mobile para calcular a distância entre a localização atual do entregador até os endereços de entregas para que, a partir disso fosse possível traçar a rota de cada endereço a partir da localização do funcionário.
2.4.2.8. Volley
Segundo Developers (2017), volley é uma biblioteca para requisições HTTP para a plataforma Android disponibilizada no GitHub. Para utilizá-la basta adicionar a dependência compile 'com.android.volley:volley:1.0.0' no arquivo build.gradle do projeto.
A biblioteca suporta requisições no formato String e JSON. A primeira por meio da classe StringRequest na qual é especificada uma URL e recebe uma String como resposta e a segunda pelas classes JsonObjectRequest e JsonArrayRequest que também especificam uma URL, mas recebem um JsonObject e JsonArray respectivamente. As requisições são enviadas pela classe RequestQueue por meio do método add(), a qual também permite definir tags pelo método setTag(<Tag>) e cancelar requisições pelo método cancelAll(<Tag>).
Esta biblioteca foi utilizada no aplicativo para solicitar informações do webservice tanto no formato String quanto no formato JSON, para preencher a tabela com os itens do cardápio do dia, as bebidas disponíveis, bem como, fazer verificações de login, cancelamento de pedido, dentre outras.
2.5. Programação para Web com Laravel 2.5.1. PHP
É uma linguagem de programação criada em 1994 por Rasmus Lerdof. A princípio era uma linguagem “formada por um conjunto de scripts escritos em linguagem C, voltados à criação de páginas dinâmicas” (DALL’OGLIO, 2015, p. 21).
Com o passar do tempo foram adicionados recursos tais como interação com banco de dados, extensibilidade, possibilidade de conexão com vários bancos de dados, novos protocolos, sintaxe mais consistente, suporte à orientação a objetos, dentre outros. Apesar das grandes melhorias esta ainda demandava maior suporte à orientação a objetos, o qual foi disponibilizado no PHP 5 no ano de 2004 (DALL’OGLIO, 2015).
Ao longo de mais de uma década, o PHP vem adicionando mais e mais recursos e se consolida ano após ano como uma das linguagens de programação orientadas a objetos que mais crescem no mundo. Estima-se que o PHP seja utilizado em mais de 80% dos servidores web existentes, tornando-a disparadamente a linguagem mais utilizada para desenvolvimento web. (DALL’OGLIO, 2015, p. 22)
Esta linguagem foi utilizada para a implementação do AskLunch em sua versão
Os Frameworks pré-empacotam um conjunto de componentes de terceiros com características personalizadas do framework, como arquivos de configuração, provedores de serviço, estruturas de diretório prescritas e carregadores de aplicativos. Logo, o benefício de usar um framework em geral é o de que alguém tomou decisões por você não só sobre componentes individuais, mas também sobre como eles devem estar integrados (STAUFFER, 2016, p. 22).
Além disso, eles fornecem convenções que reduzem a quantidade de código que um desenvolvedor novo no projeto tem de entender - por exemplo, se você souber como o roteamento funciona em um projeto Laravel, saberá como ele funciona em todos os projetos Laravel (STAUFFER, 2016, p. 23).
O framework Laravel oferece um conjunto robusto de ferramentas e uma arquitetura de aplicativos que incorpora muitas das melhores características de frameworks como Ruby onRails, Sinatra, ASP NET MVC e outros (BEAN, 2015).
A seguir são apresentados os principais conceitos da estrutura do framework Laravel para que adiante seja possível compreender a implementação do software AskLunch com facilidade.
2.5.2. Desenvolvendo com Laravel
Segundo Turini (2015), o Laravel utiliza a arquitetura Model View Control (MVC), em que:
● Model é a camada composta pelas “regras de negócio, entidades, classes de acesso ao banco de dados” (TURINI, 2015, p. 20).
● View é a camada “responsável por apresentar as páginas [..] para o usuário [..]. É a resposta que o framework envia para o navegador, que normalmente é um HTML” (TURINI, 2015, p. 20).
● Controller é encarregado de “receber as requisições web e decidir o que fazer com elas. Nessa camada definimos quais modelos devem ser executados para determinada ação e para qual view vamos encaminhar a resposta” (TURINI, 2015, p. 20).
Para a construção de uma aplicação simples com acesso ao banco de dados é necessário entender 6 elementos básicos do Laravel: view, model, controller, migration, arquivo de rotas (web.php) e arquivo de configuração (.env).
2.5.2.1. View
As views são os arquivos de layout da aplicação as quais utilizam-se da linguagem de marcação HTML para a definição da estrutura de suas páginas com seus formulários, tabelas, etc., e são armazenadas no diretório resources/views. Além disso, permite o uso de diretivas condicionais (@if), laços de repetição (@for, @while), definição de sessão (@yield), abertura de sessões (@section), inclusão de outras páginas (@include), dentre outros (LARAVEL, 2017).
2.5.2.2. Model
Cada tabela de banco de dados possui um modelo correspondente o qual é usado para interagir com essa tabela. Por meio dos modelos é possível consultar dados nas tabelas, bem como inserir, atualizar e excluir seus registros. Os modelos possuem extensão .php e ficam localizados no diretório app.(LARAVEL, 2017).
2.5.2.3. Controller
Os controllers possuem os métodos que as rotas fazem referência, seja por meio do método resource ou pelos métodosget/post/put/patch/delete/options. Quando utilizado o método resource, o controller possui 7 métodos: index(), create(), store(Request $request),
show($id), edit($id), update(Request $request, $id), destroy($id) (LARAVEL, 2017).
Em suma, o método index é responsável por retornar a view principal; o create por retornar a view de cadastro; o store é chamado para persistir os dados da view de cadastro, o qual recebe um objeto request que possui todas estas informações as quais precisam ser armazenadas; o show responsável por exibir a view com as informações do BD o qual recebe o id do registro para realizar a busca na base de dados; o edit retorna a view para a alteração do registro o qual recebe o id por parâmetro para buscar o registro e exibir suas atuais informações na view; o update é chamado para atualizar as informações por meio dos dados fornecidos na view de edição; e por fim, o destroy que recebe o id do registro por parâmetro para realizar a exclusão na tabela da base de dados (LARAVEL, 2017)
2.5.2.4. Arquivo de Rotas (web.php)
As rotas definem o caminho a ser percorrido para realizar determinada ação, por exemplo, ao acessar: https://novatec.com.br/livros/primeiros-passos-docker/, a primeira parte se refere ao domínio, /livros a seção que está sendo acessada e finalmente, o nome do livro procurado (DOUGLAS; MARABESI, 2017, p. 66).
Por meio do método resource, define-se uma rota da seguinte forma: Route::resource('pedido', 'PedidoController'), em que o primeiro argumento indica o nome da rota e o segundo qual controller fará o gerenciamento (LARAVEL, 2O17). O resource segue um padrão na definição de rotas para que o controller saiba qual método deve ser executado, como ilustrado na Figura 2:
Figura 2 - Ações do Controlador Baseada nas Rotas (LARAVEL, 2O17).
2.5.2.5. Migration
As migrations são os arquivos em que se define a estrutura das tabelas do banco de dados. Por padrão ao criar-se uma migration esta possui duas definições padrão, a primeira a coluna id com auto incremento e o timestamps que define as colunas create_at e update_at para armazenar os valores de criação e modificação de cada registro da tabela (LARAVEL, 2017)
No desenvolvimento do software AskLunch não foi feita a utilização de
migrations para não forçar o aplicativo a utilizar os padrões do Laravel para a definição da
estrutura da base de dados, visto que o aplicativo faz o uso da mesma base de dados que a aplicação web.
2.5.2.6. Arquivo de Configuração Environment (.env)
O arquivo environment (.env) é responsável por definir os valores de configuração da aplicação para acesso ao banco de dados, configuração de e-mail, dentre outros (LARAVEL, 2017).
CAPÍTULO
III
3.
TRABALHOS
RELACIONADOS
Antes de iniciar o desenvolvimento do software AskLunch, foram levantados aplicativos mobile e aplicações web com funcionalidades semelhantes ao software proposto. Neste levantamento, não foram identificados aplicativos com finalidade específica para pedidos e gerenciamento de marmitas que oferecesse suporte ao entregador com a disponibilização de um mapa com as rotas de entregas de cada pedido. Entretanto, estes softwares possuem funcionalidades similares para o gerenciamento de vendas de produtos alimentícios os quais possibilitam cadastrar pedidos, produtos, usuários, dentre outras particularidades que serão apresentados a seguir.
3.1. Protótipo de um Aplicativo Android para Pedidos de Lanches e um Portal Web Para Gestão e Monitoramento
Dentre os softwares encontrados, o PedidosAki (FONTANA JUNIOR, 2013) é o que mais se destaca pela proximidade das funcionalidades oferecidas. O software é composto de um aplicativo mobile, para solicitação dos pedidos de lanches por parte dos clientes, e uma aplicação web, para gerenciamento destes pedidos por parte dos estabelecimentos. O aplicativo permite que o cliente informe sua localização via CEP ou GPS e, com base nesta, filtra os estabelecimentos próximos ao local atual do cliente. Na relação de estabelecimentos filtrados, é exibido informações de avaliação dos clientes e tempo aproximado de preparo do pedido. Ao selecionar o estabelecimento é exibido o cardápio; ao selecionar o lanche é possível retirar os ingredientes que o cliente não queira na composição deste. A aplicação web permite o cadastramento de bebidas, ingredientes, usuários, informações da empresa e taxas. Esta possui uma interface em que é possível visualizar todos os pedidos recebidos, cancelados e finalizados; uma área para geração de relatórios de gráficos e outra para envio de mensagens para o administrador do sistema.
3.2. FASTLINE: Aplicativo mobile para lanchonetes
O FastLine (MELO; RIBEIRO; LUCAS, 2015) é um aplicativo mobile para a plataforma Android que possibilita ao cliente realizar, pagar e agendar o horário de retirada do pedido, sendo notificado quando seu pedido é finalizado. O software possui uma versão web para gerenciamento dos pedidos recebidos e foi construído com o propósito de evitar longas filas no intervalo das escolas para retirada de lanche.
3.3. Implementação de um Aplicativo para Dispositivos Móveis: o FoodFeedBack O FoodFeedback (MAESATO; VIEIRA; TABALIPA, 2016) é um software composto por um aplicativo Android, que permite os clientes avaliarem pratos e bebidas de estabelecimentos como bares, restaurantes e afins; e uma aplicação web responsável pelo gerenciamento por parte dos gerentes, donos, administradores de restaurantes. Seu uso estabelece um canal de comunicação entre os clientes para indicação e referência de lugares à sua rede de conhecidos e ainda um canal de feedback aos donos, sócios e gerentes do estabelecimento. Segundo Maesato, Vieira e Tabalipa (2016), havia a inexistência de aplicativos de feedback voltados exclusivamente para o ramo de restaurantes, pratos, serviços e afins. Desta forma, o FoodFeedback foi construído com o objetivo de suprir tal necessidade.
3.4. Implementação de um Sistema para Gestão de Bares Integrando Tecnologias Web e Mobile
O Gerência de Bares (SILVA, 2014) é um software que se subdivide em uma versão web e mobile. Ao contrário dos softwares anteriores, este tem seu funcionamento apenas dentro do estabelecimento. Sendo assim, o cliente transmite seu pedido para o garçom, e este por sua vez utiliza o aplicativo para registrar o pedido do cliente no sistema. Todos os pedidos podem ser visualizados e gerenciados na aplicação web, a qual também possui controle da abertura/fechamento do caixa, relatórios, logs do sistema, cadastro de produtos, funcionários, categoria e vendas, gerenciamento das mesas, informações da conta do usuário, controle de produtos em estoque e administração das vendas. O software foi elaborado com o objetivo de melhorar a administração, segurança das informações e geração de relatório das vendas nos bares.
3.5. Sistema para Gerenciamento de Lanchonetes
O Controle de Lanchonete (KOSLOVSKI, 2014) é uma aplicação web para gerenciamento de pedidos de uma lanchonete. A aplicação recebe pedidos dentro e fora do estabelecimento. Quando o pedido é efetuado dentro do estabelecimento a solicitação deste é feita pelos garçons; quando solicitado para a entrega, o cliente é quem faz a solicitação e este pode acompanhar os status do seu pedido pela aplicação. O sistema permite ao gerente do restaurante acompanhar as atividades de vendas registradas pelos funcionários além de controlar o ponto dos mesmos. Assim como outros softwares anteriormente citados tem como objetivo informatizar o controle dos pedidos já que a forma manual é mais propícia a erros. O
software possui cadastro de pessoas, ingredientes, cardápio, tipo de movimentação, controle
de contas a pagar e a receber, registro de requisições de itens e análise das mesmas. Após a realização da análise podem ser feitas cotações com fornecedores cadastrados no sistema, os quais recebem um e-mail com um link que os direcionam para uma página do sistema na qual podem fazer suas ofertas. Além dessas funcionalidades o software ainda conta com controle de estoque, cadastro de vendas e movimentação do caixa.
3.6. Sistema Web para Pedidos de Delivery
O Amaral Delivery (AMARAL, 2014) é uma aplicação web para pedidos de delivery com recursos de controle e monitoramento. Esta possui um usuário “master” (administrador) que faz a gerência dos ingredientes, cardápios, produtos do estabelecimento, cadastro de outros funcionários da empresa, abertura/fechamento do estabelecimento no sistema. Os funcionários e entregadores do sistema têm acesso a todos os dados dos pedidos (em aberto, cancelados, em andamento…). O cliente efetua seu cadastro no sistema e tem acesso a todos os estabelecimentos cadastrados, o que eles oferecem e seus horários de funcionamento. Ao clicar em um estabelecimento é exibido o cardápio, o cliente seleciona o produto que deseja e então é possível personalizar retirando ou acrescentando itens no lanche selecionado. Após a solicitação do pedido é possível acompanhar o andamento do mesmo pela aplicação.
