linguagem em UML

1. Nome dos elementos do grupo:
Carlos Miguel Assucena Ribeiro - ei97043@fe.up.pt
Filipe Alexandre Pais de Figueiredo Correia - ei97001@fe.up.pt
Relatório
Faculdade de Engenharia
da Universidade do Porto
Licenciatura em Engenharia Informática e computação – 4º ano
Ano lectivo de 2000/2001
Modelização do Sistema de Software
de Gestão de um Restaurante Dezembro 2000

2. Trabalho Prático - Sistema de Software de Gestão de um Restaurante - E.S.
Página 2
Introdução
O desenvolvimento das novas tecnologias proporciona, cada vez mais,
que as máquinas, e neste caso os computadores, tenham um papel mais
activo na nossa sociedade. Em todo o lado se verifica uma passagem de
testemunho do homem para o computador nas tarefas mais variadas. No
caso da comunicação, os computadores desempenham um papel
preponderante, facilitando-a incrivelmente. É nesse âmbito que o software
de gestão de um restaurante, aqui apresentado, se insere, permitindo criar
uma comunicação rápida e eficaz, entre o cliente, o empregado e o
cozinheiro . É obvio, no entanto, que este software se destina a um tipo de
restaurante muito bem definido. Nomeadamente, este sistema só é útil
numa grande superfície, com muitos clientes e empregados, em que a
comunicação e gestão seriam complicadas.
Descrição
O software de gestão de restaurantes, aqui descrito, permite que toda a
interacção cliente-empregado-cozinheiro seja feita através de terminais de
computador. Para isso é necessário que o restaurante esteja equipado com
terminais de computador em todas as mesas (para os clientes), assim
como na cozinha e nos locais onde se encontram os empregados, que
atendem os clientes. Alternativamente, neste último caso poderiam ser
utilizados sistemas móveis (PDAs) para os empregados, proporcionando
uma utilização mais rápida e fácil. O sistema permite, portanto, que os
clientes façam o seu pedido através do terminal (assim como ver o
cardápio e também os detalhes de cada refeição) e, também, efectuar o
pagamento, sendo necessário, nesse caso, um aparelho multibanco (ou
outro sistema de pagamento) em cada terminal.

3. Trabalho Prático - Sistema de Software de Gestão de um Restaurante - E.S.
Página 3
Modelo de casos de uso
Este sistema prevê 3 actores, no modelo de casos de uso: o cliente, o
empregado e o cliente. Todos este interagem com o software de maneira
diferente.
O cliente depois de chegar ao restaurante e se sentar na sua mesa, tem
à sua disponibilidade um terminal de computador onde pode, em primeiro
lugar, ver o menu (com as refeições existentes) e opcionalmente ver os
detalhes de cada prato. Depois de escolher o(s) prato(s) que pretende, faz
o pedido directamente no software, onde pode depois, também, ver a
conta e efectuar o pagamento. Entretanto o pedido efectuado aparece em
fila de espera no terminal do cozinheiro, que assim que possa, passará a
confeccioná-lo. Mal a refeição esteja pronta, o cozinheiro informa o
sistema que o pedido está concluído e automaticamente é chamado um
empregado para levar a refeição à mesa do cliente. Um empregado que
esteja livre responde e trata de fazer o que lhe pedem. O pagamento do
cliente pode efectuar-se a dinheiro ou através do multibanco. No primeiro
caso é feita uma chamada a um empregado que procede ao pagamento. No
segundo caso, os terminais, dotados de caixa multibanco, permitem que o
cliente faça de imediato o pagamento, sem ser necessário chamar um
empregado.
No restaurante é possível, também, fazer uma reserva de mesa ( e
cancelar a reserva ) quer pelo empregado (após contacto do cliente através
de telefone, por exemplo) quer pelo cliente (via internet). O cozinheiro
tem, ainda, mais algumas opções no sistema, nomeadamente, para um
determinado prato, ver a sua receita, definir como esgotado ou não e
alterar a composição do prato. Pode, também, consultar os stocks
existentes ( que são diminuídos automaticamente pelo sistema quando os
pedidos são concluídos) e alterá-los ( ajustes manuais do stock, ou
aumentá-los por chegada de novos bens comprados a fornecedores). Por
fim, é possível introduzir novos pratos, definindo a sua receita,
composição e preço.

4. Trabalho Prático - Sistema de Software de Gestão de um Restaurante - E.S.
Página 4
Modelo de objectos
O modelo de casos de uso permite ter uma visão global dos actores e de
todas as possíveis interacções actores-sistema. Tendo esta informação, é
agora possível definir o modo como será organizado o sistema
internamente.

5. Trabalho Prático - Sistema de Software de Gestão de um Restaurante - E.S.
Página 5
Teremos, então, uma classe Mesa à qual podem estar associadas várias
Reservas. Estas, contudo, não poderão ser mais que duas por dia (uma ao
almoço e outra ao jantar) já que não é possível prever quanto tempo
demorará a refeição de determinado cliente. A uma Mesa poderão ainda
estar associados vários Pratos, pedidos pelos clientes dessa Mesa.
Cada um dos Pratos pode ainda estar associado a outros Pratos que
constituem os acompanhamentos (arroz, batata, massa,…). Os
acompanhamentos podem também ser pedidos separadamente, daí a
opção de serem considerados pratos comuns.
Na confecção de um prato estão envolvidos vários produtos. Estes,
estão representados na classe Produto que se liga à classe Prato pelo
atributo de ligação Alimentos R.. Este atributo representa a quantidade
desse produto que é usada na confecção da receita do Prato em questão
Modelo de sequenciação
Neste ponto é possível um aprofundamento da informação presente nos
casos de uso. Neste sentido, apresentam-se cada caso de uso mais
detalhadamente, demonstrando os acontecimentos numa ordem em que,
de facto, se verificarão no sistema.
Como é possível observar nos diagramas seguintes, cada utilizador do
software é representado por um actor, contudo, nem em todos eles existe
intervenção de todos os actores. Como objectos temos apenas o software
uma vez que será o único objecto de interesse neste projecto; qualquer

6. Trabalho Prático - Sistema de Software de Gestão de um Restaurante - E.S.
Página 6
objecto físico não tem especial interesse do ponto de vista do sistema de
software a não ser que seja necessário o processamento / armazenamento
de informação a seu respeito.
Ver Menu/Ver detalhes de determinado prato
Ao ver o menu, o cliente, pode seleccionar a opção de ver detalhes de
um prato seleccionado.
Chamar empregado
Sempre que o cliente quiser chamar o empregado acontecem as
seguintes interacções com o software:

7. Trabalho Prático - Sistema de Software de Gestão de um Restaurante - E.S.
Página 7
Ver conta/Pagar conta a dinheiro
Depois de ver a conta, o cliente pode escolher o pagamento a dinheiro
ou com multibanco. No caso de escolher o pagamento a dinheiro o
desenrolar da acção é o seguinte:
Pagar conta com multibanco
No caso da utilização do cartão multibanco não é necessária a
intervenção do empregado desenrolando-se os acontecimentos assim:

8. Trabalho Prático - Sistema de Software de Gestão de um Restaurante - E.S.
Página 8
Fazer pedido/Ver pedido/Concluir pedido
Neste diagrama estão concentradas as três acções mencionadas, sendo,
para a sua execução necessário a intervenção dos três actores existentes.
Fazer reserva
No caso de, o cliente, querer reservar uma mesa via internet, a acção
desenrola-se conforme o diagrama abaixo. A reserva de mesas pode
também ser feita pelo empregado (mediante um telefonema de um cliente)
sendo o diagrama de sequencia semelhante.

9. Trabalho Prático - Sistema de Software de Gestão de um Restaurante - E.S.
Página 9
Cancelar reserva
Se o cliente, mais tarde, quiser cancelar uma reserva, poderá faze-lo via
internet também.
Novo prato
Pontualmente, o cozinheiro, poderá desejar a introdução de um novo
prato no menu do restaurante.

10. Trabalho Prático - Sistema de Software de Gestão de um Restaurante - E.S.
Página 10
Ver menu/Ver receitas/Definir como esgotado
Neste diagrama foram agrupadas todas as acções que o cozinheiro pode
executar relativamente aos pratos em menu.
Ver stock/Alterar stock
O cozinheiro poderá, sempre que existirem compras de novas
mercadorias, actualizar o valor do stock existente. Este valor será usado
apenas como estimativa dando ao cozinheiro um valioso indicador caso o
prato deva ser considerado esgotado.

11. Trabalho Prático - Sistema de Software de Gestão de um Restaurante - E.S.
Página 11
Modelo de estados
Existem certas entidades do sistema que, em alturas diferentes, podem
ter estados diferentes. Estas mudanças de estado são despoletadas por
eventos que vão definir, sempre que acontecem, o estado de determinada
entidade. Para ilustrar essas mudanças de estado recorremos ao diagrama
seguinte:

12. Trabalho Prático - Sistema de Software de Gestão de um Restaurante - E.S.
Página 12
Cada conjunto de estados é concorrente em relação aos outros
conjuntos mas não necessariamente independente. Por exemplo, no
conjunto (Refeição) é considerado o estado Aguardar refeição no qual
pode ser englobado todo o conjunto Pedido. No entanto, a mudança de
estados Novo pedido (do conjunto Refeição) pode dar-se em qualquer
altura do decorrer das mudanças de estado de Pedido.
Cada mesa pode passar do estado de Livre para Ocupada por dois
modos: por reserva (e posterior chegada do cliente), ou pela chegada de
um cliente que não reservou mesa. Se se tratar de um cliente com reserva,
a mesa passará por um estado intermédio de Reservada antes de passar a
Ocupada.
Como mostrado no conjunto de estados Refeição, depois de ocupada
determinada mesa, os seus ocupantes poderão fazer um ou mais pedidos.
Estes, uma vez consumidos, darão lugar à Conclusão da refeição e
respectivo Pagamento.
Cada Pedido começará por estar Em fila de espera e passará a Em
confecção apenas quando o cozinheiro iniciar a sua execução. No
momento em que o cozinheiro terminar a confecção do prato será então
dado como concluído.