Fase de Construção Implementação e Testes

O software foi implementado seguindo os pilares da orientação a objetos: encapsulamento, herança e polimorfismo, o qual será detalhado no capítulo seguinte. Durante o processo de desenvolvimento, foram efetuados testes de integração do sistema no contexto da Orientação a Objetos utilizando a estratégia de teste baseado em uso (PRESSMAN, 2011).

Este trabalho não contempla a fase de transição, a qual compreende a implantação do software. Porém, os métodos descritos acima resultaram em um software que cumpre os objetivos propostos pelo trabalho, o qual permite os clientes do restaurante efetuarem seus

pedidos por meio do aplicativo, uma interface web para o gerenciamento destes por parte do restaurante, além de viabilizar suporte ao funcionário que realiza as entregas, oferecendo-lhe um mapa que permite a visualização de uma rota até o endereço de entrega do cliente.

CAPÍTULOV

5.

IMPLEMENTAÇÃO

A metodologia UP propõe um processo iterativo e incremental, portanto a cada ciclo concluído obteve-se uma parte utilizável do software. O desenvolvimento do software iniciou-se pelo módulo do cliente, em que no primeiro momento foram projetadas as telas do aplicativo utilizando a linguagem XML no modo texto da IDE Android Studio.

Em seguida, deu-se início a construção do webservice composto por uma classe de conexão no formato PDO utilizando o padrão singleton, este que permite a utilização de apenas uma instância do objeto em todo o escopo da aplicação, e também um arquivo para cada tipo de operação do aplicativo. Este foi codificado na linguagem de programação PHP o qual possibilita receber requisições GET/POST, processar informações no banco de dados e retornar dados para o aplicativo no formato String ou JSON conforme ilustrado na Figura 7:

As telas de personalização das marmitas, bebidas e o campo de valor total da tela de finalização do pedido são preenchidos com dados provindos da base de dados. Para isso, no método onCreate das activities são feitas requisições GET para o webservice por meio da biblioteca Volley, e os dados retornados são inseridos na interface do usuário conforme ilustrado na Figura 8:

Figura 8 - Requisição utilizando a biblioteca Volley (Autoria Própria)

Após o preenchimento das telas com as informações do banco de dados, foi elaborada a navegação entre as telas utilizando as Intents para a chamada das activities e os valores informados pelo usuário. A Figura 9apresenta o método actionEntrar utilizado para a chamada da primeira tela do aplicativo após o login passando para este o código do cliente logado, e o método actionVoltarMenupara recuperação dos dados ao voltar da primeira tela do pedido para o menu principal do aplicativo.

Figura 9- Intent Entrar (Autoria Própria)

Feita a navegação das telas, foram codificadas as requisições no aplicativo e as respectivas funcionalidades relacionadas a elas no webservice para armazenamento das informações na base de dados.

Na Figura 10 é possível visualizar a tela de login, na qual o usuário informa o email e senha cadastrados e seleciona o botão de acesso ao aplicativo, caso este ainda não possua cadastro deve-se então selecionar o link cadastre-se. Esta interface possui também um

link para recuperação de senha, no qual o usuário informa seu e-mail e seleciona o link que,

por sua vez, fará uma requisição para o webservice buscar a senha de acesso e devolverá para o usuário via e-mail cadastrado.

Ao efetuar login no aplicativo, é exibido um menu com quatro opções: novo, status, perfil e sair, conforme apresentado na Figura 11. O primeiro para iniciar um novo pedido, o segundo para acompanhar o andamento dos pedidos realizados no dia, o terceiro para visualizar e alterar dados cadastrais e por fim o botão responsável por efetuar logout no aplicativo.

Figura 11- Tela de Menu (Autoria Própria)

Ao selecionar a opção novo no menu, é exibida uma tela na qual o usuário marca, os tamanhos de marmitas (grande/pequena) que deseja e a quantidade de cada. Em seguida, são exibidas a quantidade de marmitas de tamanhos grande e pequena com seus respectivos conteúdos, ou seja, os ingredientes definidos pelo restaurante para aquele determinado dia. Neste momento é possível personalizar cada uma das marmitas, selecionando o botão de edição e desmarcando os itens que não farão parte da composição das marmitas, como apresentado na Figura 12.

Figura 12- Tela de Seleção de Itens da Marmita (Autoria Própria)

O passo seguinte é opcional, pois se trata da adição de bebidas ao pedido no qual seleciona-se as bebidas e suas respectivas quantidades. Por fim é exibido o valor total do pedido, as opções de formas de pagamentos e se o pedido é para entrega ou retirada no restaurante, conforme apresentado na Figura 13. Quando selecionada a opção de entrega o usuário pode optar por utilizar o endereço de entrega cadastrado ou utilizar outro endereço.

Figura 13- Tela de Fechamento do Pedido (Autoria Própria)

Após a construção e testes do aplicativo do módulo cliente, iniciou-se o desenvolvimento do módulo do entregador. Assim como a versão do cliente deu-se início construindo o layout das telas. Em seguida, foram codificados os arquivos necessários para modificar e buscar informações no banco de dados, sendo o principal deles o arquivo de pedidos em rota, o qual busca os pedidos em andamento designados ao entregador, calcula a distância entre a localização atual do funcionário até o endereço de entrega de cada um dos clientes utilizando o Google MapsDirections API, ordena o resultado em ordem crescente e retorna para a aplicação os dados do pedido e a distância de cada endereço.

O módulo do entregador possui uma tela de login similar à do módulo do cliente, com a diferença que este não possui um link para cadastro, visto que os funcionários são cadastrados na plataforma web pelo administrador do sistema. Ao efetuar login no aplicativo,

este faz uma requisição para o webservice que, por sua vez, retorna os pedidos designados ao entregador, como apresentado na Figura 14.

Figura 14- Tela de Pedidos em Rota (Autoria Própria)

Ao serem exibidos os pedidos dos clientes com a distância dos endereços em ordem crescente, o funcionário pode selecionar o mais próximo e então, são exibidas informações como nome do cliente, telefone, endereço e forma de pagamento. A partir disso, conforme ilustrado na Figura 15, o funcionário pode visualizar uma rota partindo da sua localização atual até o endereço selecionado, na qual foi utilizada a Google Maps API

Figura 15- Tela de Pedidos em Rota (Autoria Própria)

Ao retornar para a tela principal dos pedidos as distâncias são recalculadas e é possível sinalizar que o pedido foi entregue, por meio de uma caixa de seleção que quando marcada solicita confirmação de entrega e, em caso positivo, retira o pedido da lista.

Por fim, iniciou-se a versão web do sistema modificando o template AdminLTE, que possui um layout adequado para administração de informações além de ser um modelo responsivo.

Em seguida, foi necessário adaptar a autenticação fornecida pelo Laravel para efetuar login no sistema utilizando uma tabela diferente no banco de dados. Para isso, foi necessário modificar o providersusers no arquivo auth.php como indicado na Figura 16:

Figura 16- Modificação do providersusers no arquivo auth.php (Autoria Própria)

Feita esta alteração, indicou-se no modelo Usuário a tabela que este representa no banco de dados bem como sua chave primária. Além disso, foi necessário sobrescrever o método setAttribute para efetuar a autenticação com o método loginUsingId, como indicado na Figura 17:

Figura 17 - Modelo Usuário adaptado para a autenticação por tabela diferente (Autoria Própria)

O passo seguinte foi a criação de um Controller com os métodos necessários para efetuar operações de login e logout no sistema. Para autenticação do usuário no sistema foi utilizado o método loginUsingId que recebe por parâmetro a chave primária do usuário e um valor booleano referente a funcionalidade remember me que mantém o usuário conectado em uma seção com um longo tempo de vida ou até que este se desconecte manualmente. Para desconectar do sistema foi utilizado o método logout.

Codificada as operações de login e logout, foram criadas views com formulários, tabelas e outros componentes para as seções de conteúdo do template para operações de cadastro, edição, exclusão e exibição de informações.

Posteriormente foram elaborados os models, controllers, requests e definidas as rotas no arquivo web.php. Em todos os models foi necessário indicar a tabela e chave primária do banco de dados que estes representavam, além de definir o valor false para a variável

$timestamps, visto que o banco de dados já tinha sido previamente definido e não adotava os

as chaves primárias. Com exceção do controllers responsáveis pela geração dos relatórios, autenticação e de métodos extras todos foram construídos utilizando o padrão resource.

No AskLunch é possível gerar relatórios do cardápio do dia, quantidade e total de marmitas vendidas no dia, aniversariantes de um mês específico, quantidade de pedidos por status (cancelados, extraviados, finalizados, etc.), dentre outros. A Figura 18 apresenta o relatório de marmitas vendidas no dia 31 de janeiro de 2018.

Figura 18 – Relatório Total de Marmitas Vendidas no dia (Autoria Própria)

Os relatórios foram elaborados por meio do pacote DOMPDF, que transforma as páginas HTML em arquivos PDF. Para isso, utilizou-se o método loadView que recebe uma

view com seus respectivos valores por parâmetro que, por sua vez, os transforma em um

arquivo pdf e o método stream exibe-o na página com opções de download e impressão, como ilustrado na Figura 19:

Figura 19 - Relatório cardápio do dia (Autoria Própria)

A plataforma web possui cadastro de clientes, funcionários, bebidas, formas de pagamentos,relatórios, gerenciamento de cardápio, valores das categorias de marmitas, andamento e cadastro de pedidos. Este último, foi implementado para os casos em que o cliente por ventura faça seu pedido por telefone.

Ao selecionar a opção pedidos recebidos, o operador pode visualizar as marmitas do cliente com seus respectivos itens, sinalizar que o pedido está pronto ou cancelado, como apresentado na Figura 20. No caso do primeiro, o pedido aparecerá no submenu de pedidos prontos e no segundo, aparecerá no submenu de pedidos cancelados.

Figura 20 – Tela de Pedidos Recebidos (Autoria Própria)

O submenu de pedidos prontos dispõe de uma opção para selecionar um entregador quando este for para entrega e de finalizar quando este for para retirada no estabelecimento, além de uma opção para cancelamento caso o cliente ligue para cancelar o pedido ao invés de realizar esta operação pelo aplicativo.

A Figura 21 apresenta os pedidos para entrega que ficam situados na seção de pedidos em andamento. Esta contém uma opção para finalizar o pedido, caso o entregador esqueça de finalizá-lo pelo aplicativo e uma para sinalizar que o pedido foi extraviado, para os casos em que não houver a efetivação do pedido como, por exemplo, em casos de acidentes de trânsito com o entregador e perda dos pedidos designados a ele.

O menu de gerenciamento, conforme apresentado na Figura 22, possui um submenu para visualização dos pedidos cancelados o qual possui uma opção de restauração do pedido para os casos em que os clientes optem por reestabelecer seu pedido ou para recuperação do pedido em casos de descuido do operador. Este engloba também uma seção de pedidos extraviados na qual é possível recriar o pedido com os mesmos parâmetros alterando apenas o código e data/hora do pedido.

Figura 22 – Menu de Gerenciamento de Pedidos (Autoria Própria)

Sendo assim, o software AskLunch possui o seguinte funcionamento: o cliente faz o seu pedido pelo aplicativo e estes aparecerão na plataforma web na seção de pedidos recebidos, para serem administrados pelo operador. Os pedidos para a entrega, serão designados para algum entregador que esteja disponível no momento e, a partir disso, estes serão exibidos no aplicativo do entregador para que ele visualize a rota de cada endereço de entrega.

CAPÍTULOVI