Sistema de Atendimento

Neste semestre, vocês implementarão um sistema de informação simples para administrar os
atendimentos e registros de caixa de um fast-food. Um dos objetivos desse projeto é fazer com
que vocês consigam atender aos requisitos do cliente.
Em um sistema qualquer, interfaces simples, agradáveis e fáceis de usar são características
muito importantes. Também é uma regra importante separar a interface com o usuário da
lógica de negócio e fazer com que seu projeto não tenha interface com o usuário é uma forma
de você sacar esse ponto arquitetural importante.
Descrição do Projeto (em poucas palavras)

Módulo de atendimento
O propósito do projeto é de construir um sistema de atendimento e fluxo de estoque de uma
nova loja fast-food chamada JAVALI. O sistema consiste de um banco de alimentos e bebidas
que serão vendidas. O sistema deve registrar cada pedido.
Este restaurante deverá oferecer ao cliente produtos referente a esse ramo de negócio: os
pratos deverão ter as seguintes informações: Tempo médio de preparo, valor, tipo de
pagamento (dinheiro ou cartão de crédito), nome do prato (sempre com o prefixo “J”), preço,
e outras (à escolha de vocês - alunos).
Uma LISTA deverá ser criada para o atendimento do JAVALI (atendimento local);
Uma FILA para o atendimento dos pedidos que serão entregues em casa. Neste caso, o
endereço de entrega e o nome do motoboy deverão estar junto do pedido cadastrado, além
da data-hora máxima para entrega (definida a partir da data-hora do pedido). O tempo
máximo de entrega dependerá do prato e/ou de configuração do gerente.
 Cadastrar pedido (INCLUIR – inclusão sempre no final de cada lista)
 Entregar prato ao cliente (EXCLUIR - a exclusão pode acontecer no meio, inicio ou fim
da lista), sempre com a mensagem “Bom Apetite! O JAVALI agradece.”.
 Despachar para entrega. (EXCLUIR - Como a estrutura é uma fila, a exclusão só pode
acontecer inicio da fila), sempre com a mensagem “As entregas no JAVALI vão a
galope!! ”.
 Imprimir os dados dos pedidos em espera e o total por tipo de pedido.
 Não quero mais essa gororoba! Cliente se aborreceu com a demora, o pedido deverá
ser excluído da lista ou da fila.

Módulo de pratos e bebidas
Você usará duas estruturas de dados. Na primeira estrutura serão armazenados os tipos dos
pratos e bebidas (produtos). Lembrando que não é necessário validar a repetição de tipos, ou
seja, suponha que todos os tipos cadastrados são diferentes. Cada tipo é apenas uma letra.Página 2 de 3
Na segunda estrutura serão armazenados os pratos/bebidas (produtos) onde o número do
produto, o preço e o tipo devem ser digitados. Lembrando que um produto só pode ser
cadastrado se for de um tipo também já cadastrado, faça esta verificação.
Os tipos devem ser cadastrados um por vez. Nesta opção única mensagem disponível é: Tipo
cadastrado.
Os tipos devem ser cadastrados um por vez (código, preço e tipo). Lembrando que um produto
só pode ser cadastrado se o tipo ao qual ele pertence já existe na FILA de tipos. Nesta opção as
mensagens disponíveis são: Produto cadastrado e Tipo de produto inexistente.
O usuário poderá consultar o preço e se este existir (na PILHA de produtos) seu preço deverá
ser mostrado. Nesta opção as mensagens disponíveis são: Preço = valor calculado, Produto não
cadastrado e Pilha vazia.
Um tipo de produto pode ser excluído da FILA de tipos, respeitando a forma de organização de
uma FILA, lembrando que um tipo só pode ser excluído se não existir nenhum produto
cadastrado para o referido tipo, o tipo a ser excluído deverá ir primeiro para o início da fila.
Um produto pode ser excluído da PILHA de produtos, respeitando a forma de organização de
uma PILHA, o produto, antes de ser excluído, deverá ir para o topo da pilha.
Não esqueça que cada produto, além do tipo, pode ser bebida ou prato.
Opções deste módulo:
1 – Cadastrar tipo de produto
2 – Cadastrar produto
3 – Consultar o preço de um produto
4 – Excluir tipo
5 – Excluir Produto

Recomendações para a entrega:
Coisas que devem ser entregues:
 Código-fonte documentado
 documentação do/no código-fonte
 Relatório
Observações/sugestões técnicas:
a) Para busca procure usar um algoritmo de busca de qualidade conhecida, como busca
binária caso seu conjunto de dados esteja ordenado. Para ordená-lo procure usar um
algoritmo de ordenação de qualidade conhecida, como quicksort, mergesort ou
bublesort.
b) Não é permitido usar SGBD ou qualquer tipo de dado (semi)estruturado.Página 3 de 3
c) Sugestão: usar vetor de registros para armazenamento em memória. Caso tenha
interesse pode fazer uso de arquivo para armazenamento físico desta estrutura.
d) Sugestão: usar estrutura (lógica) de árvores para busca/armazenamento (não é
obrigatório, é apenas uma sugestão ).
Lembre dos seguintes pontos ao entregar o resultado:
 A linguagem de programação deve ser o C#.
 Os dados devem estar armazenados (persistentes) em arquivos.
 Entregue um único arquivo zip. O nome do arquivo zip deve ser "joao-maria.zeep"
(identificando os nomes dos membros da equipe). Use a terminação zeep e não zip
para driblar o gmail que não entrega mails com attachments contendo arquivos
executáveis (ele olha dentro de attachments zip).
 Ao extrair do arquivo zip, tudo deve cair no lugar certo para ajudar minha tarefa de
testar e verificar seu trabalho.
 Posso extrair do arquivo em qualquer diretório que eu quiser na minha máquina.
 Use apenas nomes de arquivos relativos, pois nomes absolutos que poderão existir na
sua máquina poderão não existir na minha máquina.
 Lembre que vou brincar testar seu sistema com meus próprios testes adicionais. Para
ter certeza que tudo funcione adequadamente, teste os passos acima numa máquina
diferente daquela onde você desenvolveu o software.
 Estarei testando seu software com o .NET Framework 4.0 ou superior. Não peça para
que eu use uma versão mais antiga.
 Entregue um relatório (chamado relatorio-joao-maria.doc - ou txt, ou html, ou pdf, ou
docx) descrevendo seu design. Seu relatório deve conter:
o Um diagrama de classes
o Descrição da sua solução e das dificuldades encontradas
o Participação de cada membro da equipe
 O projeto será avaliado de acordo com os seguintes pesos:
o Compilação (0% - se não compilar, não aceito o projeto)
o Execução dos meus testes (40%)
o Qualidade da documentação (10%)
o Qualidade do design de interface (15%)
o Qualidade do código (25%): Defeitos a observar no código: uso de "hardcode",
repetição de código, uso de números mágicos, nomes de símbolos mal
escolhidos, modularização (Say what you want, not how to do it), cascatas de
ifs ou endentação profunda de loops/testes, consistência na codificação
(padrão de codificação), má organização em pacotes, mau tratamento de
exceções, etc.
o Qualidade do relatório (10%)