PROGRAMA DOCUMENTAÇÃO

Ana Fukuda Brasília 2019 JARBAS SOUZA GESTÃO DE LANCHOTE “Sua Lanchonete Gerenciável e pronta para crescer” Trabalho apresentado como requisito parcial para obtenção da aprovação da disciplina de Projeto Final I, Curso de Bacharelado em Sistemas de Informação, Faculdade de Tecnologia, UPIS - União Pioneira de Integração Social. A data e as assinaturas a seguir devem constar na cópia definitiva, impressa após a aprovação da Banca exminadora) (data da defesa ã Banca Examinadora) Brasília-DF, dd de mmmm de 2011. Banca Examinadora: ___________________________________ Orientadora: Prof. Dra. Ana Fukuda UPIS – União Pioneira de Integração Social ___________________________________ Prof. Um recibo poderá ser impresso contendo o número do pedido, podendo ser enviado para a cozinha para processamento. Palavras-chave: Sistema de Lanchonete. Unified Modeling Language. Sistema de Gestão de Pedido.

ABSTRACT Some small companies in the food sector, because they do not have technological resources, are not implemented as companies that use the way a system for their daily operations, leveraging companies without many expenses. Keywords: Cafeteria System. Unified Modeling Language. Order Management System. LISTA DE FIGURAS Figura 1: Tipos de Diagrama UML 22 Figura 2: Caso de Uso vs Especificação de Caso de Uso 23 Figura 3: Diagrama de Arquitetura do modelo de negócio atual da empresa 25 Figura 4: Caso de Uso - Visão de negócio do cliente 26 Figura 5: Diagrama de Atividade - Visão de negócio do cliente 28 Figura 6: Diagrama de Atividade - Visão de negócio do cliente 29 Figura 7: Caso de Uso - Visão Geral do Sistema Proposto 37 Figura 8: Caso de Uso - Visão Detalhado do Sistema Proposto 38 Figura 9: Caso de Uso: RF001 - Manter Produto 39 Figura 10: Caso de Uso: RF002 – Emissão de Relatórios 40 Figura 11: Caso de Uso Emissão de Relatórios Detalhe - Estoque 41 Figura 12: Caso de Uso: RF003 - Manter Cadastro 42 Figura 13: Caso de Uso: NF004 – Login e Senha 43 Figura 14: Caso de Uso: RF005 - Manter Pedido 45 Figura 15: Caso de Uso: RF006 - Manter Cliente 46 Figura 16: Caso de Uso Atualizar Menu 46 Figura 17: Diagrama de Sequência para identificar a Hierarquia de Classes 48 Figura 18: Diagrama de Sequência Entrar no sistema 48 Figura 19: Diagrama de Sequência para a Seleção da mesa 49 Figura 20: Diagrama de Sequência para Login e Senha Visão do objeto de análise 50 Figura 21: Diagrama de Classe Proposto para o Sistema 51 Figura 22: Tela de Acesso ao Sistema Gestão 52 Figura 23: Painéis de controle do Sistema de Gestão 52 Figura 24: Tela de Cadastro através da tela de Pedidos 53 Figura 25: Tela de Cadastro Geral 54 Figura 26: Tela para Cadastro do Pedido 55 Figura 27: Tela de Produtos 55 Figura 28: Tela do Parâmetro Categoria do Sistema 56 Figura 29: Tela de gerenciamento de Vendas e Contas em Aberto 57 Figura 30: Tela de Compras 57 Figura 31: Tela do Parâmetro Configurações do Sistema 58 Figura 32: Tela do Parâmetro de Relatórios do Sistema 59 Figura 33: Tela do Parâmetro Cartão da Lanchonete 59 LISTA DE QUADROS Quadro 1: – Ferramentas Utilizadas para o desenvolvimento 19 Quadro 2: Lista de Documentos do Trabalho 22 Quadro 3: Resumo dos Usuários 32 Quadro 4: Resumo dos Envolvidos no Projeto 32 Quadro 5: Resumo da Descrição do Problema 33 Quadro 6: Equipamentos Necessários para o Funcionamento do Sistema 34 Quadro 7: Principais Necessidades dos Usuários e dos Envolvidos.

Quadro 8: Requisitos Funcionais 35 Quadro 9: Requisitos Não Funcionais 36 Quadro 10: Descrição do Caso de Uso: RF001 - Manter Produto 39 Quadro 11: Descrição do Caso de Uso: RF002 – Emissão de Relatórios 40 Quadro 12: Descrição do caso de Uso Emissão de Relatórios Detalhe - Estoque 41 Quadro 13: Descrição do Caso de Uso: RF003 - Manter Cadastro 43 Quadro 14: Descrição do Caso de Uso: NF004 – Login e Senha 44 Quadro 15: Descrição do Caso de Uso: RF005 - Manter Pedido 45 Quadro 16: Descrição do Caso de Uso Atualizar Menu 47 SUMÁRIO 1 INTRODUÇÃO 14 1. Diagrama de Atividades Cliente 27 4. Diagrama de Objeto Cliente 28 5 PROJETO DO SISTEMA 30 5. Modelo de negócio proposto 30 5. Objetivos e Cenários 30 5. Resumo dos Usuários 32 5. Caso de Uso: RF003 - Manter Cadastro 42 5. Caso de Uso: NF004 – Login e Senha 43 5.

Caso de Uso: RF005 - Manter Pedido 44 5. Caso de Uso: RF006 - Manter Cliente 46 5. Caso de Uso Atualizar Menu 46 5. Deve haver um modo de introduzir tais mudanças de modo que sejam registradas e testadas. Mais uma vez, a automação é essencial. As mudanças devem ser feitas em um sistema de versionamento e propagadas para produção por meio de processos automatizados. Da mesma forma, deve ser possível usar o mesmo processo para reverter uma versão em produção se a implantar falhar. Declaração do Problema Este estudo de caso analisa o problema da criação de um sistema para um restaurante. O usuário deslizará seu cartão e o sistema verificará a validade do cartão e o pagamento será efetuado. Um recibo será impresso contendo o número do pedido e o pedido será enviado na cozinha para processamento.

Os seguintes problemas, úteis na realização de uma análise detalhada do sistema, serão abordados neste estudo: 1. O que o sistema deve fazer? 2. Quais são os requisitos dos sistemas? 3. Pode evitarar filas longas no balcão devido à velocidade de execução e ao número de telas ideais para acomodar o rendimento máximo. O sistema estará disponível 24 horas por 365 dias, porque a máquina não tirará licença médica ou férias. Justificativa Foi encontrada uma lanchonete dentro de uma empresa onde os funcionários fazem seus lanches e anotam em um fichário. Mensalmente cada funcionário acerta suas despesas junto ao dono da lanchonete. Foi analisado um sistema que poderia armazenar os dados destes fichários, ficando este processo totalmente em meio lógico deixando a papelada de lado.

O Capítulo 6 é dedicado ao Modelo de Projeto, destacando seus diagramas. O Capítulo 7 é dedicado a Implementação do código fonte em C#. Por fim, a Conclusão traz as considerações finais sobre o trabalho, as principais contribuições e as sugestões para trabalhos futuros. DESENVOLVIMENTO WEB A programação da web, também conhecida como desenvolvimento da web, é a criação de aplicativos webs dinâmicas. Exemplos destes aplicativos são sites de redes sociais como o Facebook ou sites de comércio eletrônico, como a Amazon. O desenvolvimento de back-end controla o que acontece nos bastidores de um aplicativo da web. Um back-end geralmente usa um banco de dados para gerar o front-end. Os scripts de back-end são escritos em muitas linguagens de codificação e estruturas diferentes, como, PHP, Ruby on Rails, ASP.

NET, Perl, Java, Node. js, Python entre outros. A segunda fase é a de análise que é o estágio mais importante no ciclo de vida de desenvolvimento de sistemas (CVDS), do inglês systems development life cycle (SDLC). De acordo com Pressman (2016, p. foi identificado que a principal causa de um projeto problemático eram os requisitos insatisfatórios. Curiosamente, eles notaram a falta de envolvimento das partes interessadas como primeiro em sua lista. A falta de envolvimento das partes interessadas, no entanto, também pode estar ligada a requisitos insatisfatórios. Os modelos permitem trabalhos em um nível mais alto de abstração. A modelagem é uma parte essencial dos grandes projetos de software e também é útil para projetos de médio e pequeno porte. Um modelo desempenha o papel análogo no desenvolvimento de software que os projetos e outros planos (mapas do site, elevações, modelos físicos) desempenham na construção de um arranha-céu (PRESSMAN, 2016).

Usando um modelo, os responsáveis pelo sucesso de um projeto de desenvolvimento de software pode assegurar-se de que a funcionalidade de negócios é completa e correta, as necessidades do usuário final sejam cumpridos, e design programa suporta requisitos de escalabilidade, robustez, segurança, capacidade de extensão e outras características (PREECE, 2015). A implementação no código torna as alterações difíceis e caras de fazer (SOMMERVILLE, 2011). Referências Esta subseção fornece uma lista completa de todos os documentos mencionados em qualquer outra parte do documento deste trabalho. Identificando cada documento por título. Quadro 2: Lista de Documentos do Trabalho Título do Documento Fonte / Referência Apêndice A Documento de Requisito Apêndice B Ata de Reunião junto ao proprietário da Lanchonete Quadro 2 – Referências 3.

Caso de Uso vs Especificação de Caso de Uso De acordo com Pressman (2016) um caso de uso pode ser visualizado como um diagrama de caso de uso ou / e no formato de especificação textual estruturada: Figura 2: Caso de Uso vs Especificação de Caso de Uso Diagrama de Caso de uso Especificação do Caso de Uso Caso de uso: pagamento de fatura • Descrição • Condição prévia • Pós-condição • Caminho básico • Caminhos Alternativos • Caminhos de exceção Fonte: Elaborado pelo autor (2019) Conforme Sommerville (2011), caso de uso (tarefa – que um cliente deseja executar) pode ser: • Interativo - Um caso de uso do sistema descreve a interação de um ator com um sistema em busca da meta de negócios definida • Manual - Uma seqüência de ações realizadas por um ator • Automatizado - Uma sequência de etapas executadas por um programa ou script Um caso de uso descreve uma sequência de ações que representam um cenário principal (perfeito) e cenários alternativos, com o objetivo de demonstrar o comportamento de um sistema (ou parte dele), através de interações com atores (Pressman, 2016).

DECLARAÇÃO DA VISÃO DE NEGÓCIO A declaração de visão é capturada é uma visão geral de alto nível do propósito do projeto e sua finalidade em melhorar o negócio. A cozinha é responsável por todas as atividades relacionadas com a comida do restaurante, incluindo, determinar os itens do menu, preparação da comida, ingredientes, lavar e limpar utensílios de cozinha e restaurante. Envio e recebimento é responsável pelos itens de entrada e saída do restaurante, que inclui receber comida para a cozinha, receber itens para o restaurante, controle de recibos, coleta de lixo. A manutenção de estoque é responsável por manter os suprimentos do restaurante, gerenciar estoques de cozinha e encomendar itens necessários. O departamento de Administração é responsável por gerenciar todas as finanças de entrada e saída do restaurante.

Recebe recibos de contas de remessa e recebimento, pedidos de reposição do estoque e recibos. Figura 5: Diagrama de Atividade - Visão de negócio do cliente Fonte: Elaborado pelo autor (2019) O propósito do diagrama da figura 5 é determinar que apenas o caso de uso de alimentação precisa ser detalhado. Diagrama de Objeto Cliente Este diagrama descreve os artefatos manipulados pelo negócio em sua prática comercial normal. Os objetos que foram identificados a partir dos diagramas de atividades e o diagrama de casos de uso. Figura 6: Diagrama de Atividade - Visão de negócio do cliente Fonte: Elaborado pelo autor (2019) Restaurante – Onde comida é servida aos clientes e contém as mesas, cardápio, cozinha e possui usuários (a; Cozinha - Onde a comida é preparada. Menu_Cardapio - O que o cliente usa para pedir comida.

Objetivo 2. O sistema recebe o pedido do cliente de acordo com sua escolha. a. O usuário seleciona uma combinação (ou seja, uma combinação de comida principal, bebida e acompanhamento). b. b. O sistema verifica o valor em dinheiro e dá o reembolso, se houver, após a dedução do valor. c. O usuário decide pagar com cartão de crédito / débito. Sistema informa ao usuário para passar o cartão pelo leitor de cartão. O Diretor da loja decide adicionar / excluir um item do menu. b. O Diretor da loja deseja colocar ofertas festivas em alguns itens, pois há uma mudança no preço de alguns itens. c. O Diretor da loja percebe que alguns pratos estão em falta. Descrição do Problema Esta seção forneça uma descrição resumida do problema que está sendo resolvido pelo projeto.

Quadro 5: Resumo da Descrição do Problema O problema de Gerenciar uma lanchonete Afeta Clientes e dono da lanchonete cujo impacto é Faltam controles das vendas e estoque, grandes filas de clientes. uma boa solução seria Automatizar os processos deixando o atendimento mais rápido e o controle mais seguro. Fonte: Elaborado pelo Autor (2019) 5. Descrição dos Envolvidos e dos Usuários Esta seção fornece um perfil dos envolvidos e dos usuários que integram o projeto, e dos principais problemas que, de acordo com o ponto de vista deles, poderão ser abordados pela solução proposta. Somente quando falta produto que o dono solicita nova mercadoria Sistema deve controlar o estoque de entrada e saída de produtos. Bem como emitir relatório de estoque. DIREÇÃO 1 Para saber quanto foi vendido no dia é necessário abrir cada fichário e somar as vendas do dia ou do mês.

Não existe controle mas há muitos clientes. Implantar Relatórios de vendas. Alterar funcionário Atualizar dados dos funcionário Consultar funcionário Obter as informações atualizadas dos funcionários. ATENDENTE/ VENDEDOR\ DIREÇÃO Incluir produto [RF001] Manter cadastro de produto Registrar dados dos produtos, garantindo a não duplicidade de informação. Alterar produto Atualizar dados dos produtos. Consultar produto Obter as informações atualizadas dos produtos. ATENDENTE/ VENDEDOR\ DIREÇÃO Incluir Venda [RF002] Emissão de relatórios Registrar vendas realizadas. ATENDENTE/ VENDEDOR\ DIREÇÃO Interface com Usuário [NF002] Interface amigável Ambiente desktop, compatível com o padrão Microsoft. Sistema de fácil compreensão Telas com funcionalidades fáceis, apresentação simples para que ser torna as ações intuitivas e lógicas.

ATENDENTE/ VENDEDOR\ DIREÇÃO Sistema com dados precisos [NF001] Acesso Informações de cálculos e valores devem ser precisas. Rotinas de backup [NF003] Backup O sistema deverá apresentar uma rotina de backup para preservação dos dados. ATENDENTE/ VENDEDOR\ DIREÇÃO Login e senha [NF005] Login e senha O sistema deverá possuir um modo de identificação do usuário que juntamente com a senha devem serem checados e validados que o usuário quiser acessa-lo Fonte: Elaborado pelo autor (2019) 5. Usuário deve preencher todos os campos, e clicar em salvar. O sistema emitirá uma mensagem de confirmação do cadastro. Usuário clica em "OK". FA]. Fluxo Alternativo [FA] 1. O sistema abre os parâmetros. O usuário seleciona o parâmetro e a categoria desejada. O sistema abre para a seleção do relatório.

Usuário seleciona o parâmetro desejado. O sistema gera o relatório. Fluxo Básico 1. O usuário seleciona a categoria produto. O sistema abre os parâmetros. O usuário seleciona o parâmetro e a categoria desejada. O sistema abre para a seleção do relatório. O Sistema emite uma mensagem de erro. Fonte: Elaborado pelo autor (2019) 5. Caso de Uso: RF003 - Manter Cadastro Figura 12: Caso de Uso: RF003 - Manter Cadastro Fonte: Elaborado pelo autor (2019) Quadro 13: Descrição do Caso de Uso: RF003 - Manter Cadastro Descrição Cadastrar Clientes, Fornecedores e Funcionário, (cadastro, edição e exclusão) Referência RF003 – Manter Cadastro Atores Direção Pré-condições O usuário deve estar conectado no sistema Pós condições O usuário terá acesso a todos os dados e movimentações no sistema.

Fluxo Básico 1. Clicar no menu Manter Cadastro. Requisitos Especiais Quando o usuário retorna para o sistema tela, o sistema pode mostrar se determinada alteração foi salva. Ponto de Extensão - Informaçãoes Complementares Fluxos de Exceções 1. Usuário não preenche os campos corretamente. O Sistema emite uma mensagem de erro. Fonte: Elaborado pelo autor (2019) 5. Usuário digita login ou senha incorreta. O Sistema emite mensagem de erro e cancela a entrada. Fonte: Elaborado pelo autor (2019) 5. Caso de Uso: RF005 - Manter Pedido Figura 14: Caso de Uso: RF005 - Manter Pedido Fonte: Elaborado pelo autor (2019) Quadro 15: Descrição do Caso de Uso: RF005 - Manter Pedido Descrição Realizar Pedido Referência RF005 – Manter Pedido Atores Direção e Atendente/ Vendedor Pré-condições O usuário deve estar conectado no sistema Pós condições O usuário terá acesso aos dados do módulo do pedido e de acordo com o perfil de acesso ao sistema.

Fluxo Básico 3. Fluxo Alternativo [FA] 5. Usuário cancela o Pedido. O Sistema fecha a janela de pedido. Requisitos Especiais Quando o usuário retorna para o sistema tela, o sistema pode mostrar se determinada alteração foi salva. Ponto de Extensão - Informaçãoes Complementares Fluxos de Exceções 1. Sistema irá emitir uma mensagem confirmando o cadastro. FA]. Fluxo Alternativo [FA] 7. Usuário cancela o cadastro. O Sistema fecha a janela de cadastro Requisitos Especiais Quando o usuário retorna para o sistema tela, o sistema pode mostrar se determinada alteração foi salva. Esses diagramas são amplamente utilizados por empresários e desenvolvedores de software para documentar e entender os requisitos para sistemas novos e existentes (DEBONI, 2003). Figura 17: Diagrama de Sequência para identificar a Hierarquia de Classes Fonte: Elaborado pelo autor (2019) Quando o usuário entre no sistema e o mesmo está ativo, o restaurante é criado e pode ser utilizado.

 Enquanto ativo, o restaurante pode disponibilizar mesas ou visualizar se estão indisponíveis.  Quando um cliente é atribuído a uma mesa, o cliente é criado e inicia o processo de criação do pedido.  A atribuição do usuário cria um pedido e isso, por sua vez, cria um menu para atender ao pedido. É o bloco de construção de todos os sistemas de software orientados a objetos. Usamos diagramas de classes para representar a estrutura estática de um sistema, mostrando as classes do sistema, seus métodos e atributos. Os diagramas de classes também nos ajudam a identificar o relacionamento entre diferentes classes ou objetos (DELBONI, 2003). Figura 21: Diagrama de Classe Proposto para o Sistema Fonte: Elaborado pelo autor (2019) As classes do diagrama da figura 21 acima, dividem os requisitos do sistema em grupos de funcionalidades relacionadas.

RESULTADOS E DISCUSSÃO Para todos os usuários do sistema será apresentado uma tela de login no qual deverão inserir seu número de identificação de funcionário e senha. O pedido exibirá cada item de menu solicitado e seu custo associado, um recibo é emitido com o custo total, impostos, gorjeta e método de pagamento. Figura 26: Tela para Cadastro do Pedido Fonte: Elaborado pelo autor (2019) No parâmetro produtos é possível realizar o cadastro de produtos, bem como possui a possibilidade de importação, e imprimir etiquetas para o controle de estoque. Neste parâmetro é possível adicionar futuramente o código de barras para um controle mais automatizado do estoque. A figura 27 mostra a tela do parâmetro produtos. Figura 27: Tela de Produtos Fonte: Elaborado pelo autor (2019) No parâmetro categoria, como demonstrado na figura 28, quando uma categoria é selecionada, os itens de menu disponíveis e a descrição da categoria, conforme armazenados no banco de dados, serão exibidos para o cliente.

A figura 33 mostra a tela de controle do cartão da lanchonete. Figura 33: Tela do Parâmetro Cartão da Lanchonete Fonte: Elaborado pelo autor (2019) 7 CONCLUSÃO Após fazer-se a análise do decorrente trabalho, nos certificamos cada vez mais de que um sistema informatizado em uma pequena empresa como uma lanchonete pode agregar muito valor para a empresa. O maior desafio em um projeto de desenvolvimento do sistema é a escrita de várias regras de validação para permitir a verificação da confiabilidade das informações já numa fase de entrada de dados. Com base nos resultados da análise e concepção que foi descrito na seção anterior, pode ser desenhada conclusão de que: 1. Este sistema pode auxiliar e ao usuário nas atividades com um sistema organizado e com um o menu categorizado.

ed. Casa do Código. ISBN: 9781783985876. págs. DEBONI, J. págs. HUMBLE, Jez; FARLEY, David. Entrega contínua: como entregar software de forma rápida e confiável. Porto Alegre: Bookman, 2014. PASQUALI, Sandro. MAXIM, B. R. Engenharia de Software – Uma abordagem profissional. ed. Porto Alegre: AMGH, 2016.