Fabricio Breve - Página Pessoal
Português Português   English English
www.fabriciobreve.com
         
Informações Gerais
Publicações
Currículo Lattes
Trabalhos Acadêmicos
Softwares
Links
Links
Análise de Sinais e Sistemas (UFSCar)
Teoria da Computação (EEP)
PHP (SENAC)
Banco de Dados I (FSL)
Redes de Computadores (FSL)
Laboratório de Programação (FSL)
Laboratório de Redes de Computadores e Sistemas Operacionais (FSL)
Sistemas Orientados a Objetos (UNESP)
Análise de Sistemas (UNESP)
Tópicos: Computação Avançada (UNESP)
Organização de Computadores (UNESP)
Redes de Computadores (UNESP)
Sistemas Operacionais II (UNESP)
Computação Inspirada pela Natureza (UNESP)

Google Scholar ORCID iD icon
 

NOTICE: This page is no longer mantained. Please check the new home page.

SIMULAÇÃO DE UM RESTAURANTE

Introdução

Este projeto tem como objetivo a simulação de um sistema de funcionamento de um restaurante. A simulação se faz necessário para a obtenção de relatórios com informações relativas a situação de um determinado sistema ou uma possível alteração dos mesmos.

Através de softwares de simulação como o Arena, GPSS/H, etc, nós podemos assistir diante de uma tela de computador o funcionamento de uma organização após a introdução de um novo processo ou a mudança de seu lay-out, obtendo como vantagem enxergar as mudanças que pretendem ser implementadas nas organizações, analisando diferentes possibilidades e identificando gargalos sem o gasto de muito dinheiro.

A nossa simulação do sistema restaurante é descrita abaixo:

Existe uma definição de horário de funcionamento, que é das 10 horas às 15 horas, tendo o horário das refeições começando às 11 horas e indo até às 15 horas. Caso o cliente chegue antes desse horário ele vai embora, pois o sistema de refeições ainda não está funcionando. Caso chegue depois das 11 horas, existem três opções: ir embora caso não tenha dinheiro, ir ao banheiro e almoçar ou somente almoçar. Caso escolha ir ao banheiro existem dois vasos sanitários no banheiro. Caso um vaso sanitário esteja ocupado, a pessoa escolhe o outro e caso este outro estiver ocupado, a pessoa vai embora. Ao liberar o banheiro, outra pessoa pode usá-lo. Tendo usado o banheiro a pessoa segue para sua refeição, onde existem quatro mesas nas quais a pessoa “senta” mediante a escolha da menor fila. Ao final da execução existe uma escolha para voltar a refeição ou ir tomar café ou ir para o caixa. Se escolher o café, a pessoa toma e vai para o caixa, onde existem dois atendentes, para os quais as pessoas pagam suas contas escolhendo a menor fila. Após elas pagarem elas vão embora e finaliza -se

o sistema.

Material e Métodos

Para a simulação do sistema de funcionamento de um restaurante nós utilizaremos o software de simulação Arena 3.5. Segundo (Prado, 1999), o Arena é um dos mais utilizados em todo o mundo, tanto por empresas como por universidades. No Brasil ele é o mais popular. O software Arena foi lançado pela Systems Modeling (USA) em 1992, utilizando a linguagem de programação Visual Basic da Microsoft.

A versão utilizada neste trabalho é uma versão extremamente limitada, pois se trata de uma avaliação/demonstração do software. Utilizamos para a simulação um computador Pentium III 667 MHz e 128M de memória RAM com sistema operacional Windows 98 Second Edition.

Como o Arena é um software limitado, para simularmos todas as funcionalidades que são necessárias, tivemos que dividir o modelo geral em 5 módulos:

  • Resumo do Modelo Geral;
  • Funcionamento do Banheiro do Restaurante;
  • Funcionamento do Bandejão (Refeição) do Restaurante;
  • Funcionamento do Café;
  • Funcionamento do Caixa.

Resultados e Discussão

Abaixo será explicado e mostrado cada um dos módulos, que formam o sistema como um todo:

. Resumo do Modelo Geral (arquivo modelo-1.doe): Neste módulo é simulado um funcionamento reduzido (resumo) do restaurante, onde se encontram as funcionalidades de ir ao banheiro e almoçar ou somente almoçar. Foi implementado um bloqueio de horário de funcionamento, o sistema inicia às 10 horas, mas o restaurante só abre às 11 horas . Caso a pessoa (bloco arrive) chegue antes, ela é direcionada à saída (bloco depart). Quando o restaurante inicia (11 horas) existem três opções de caminho (bloco chance): banheiro (probabilidade de 40%) e refeição, refeição (50%), ou ir embora direto caso não tenha dinheiro (10%). Foi implementada uma falha no bloco server banheiro que ocorre após 10 pessoas o usarem. Esta falha permanece por 60 minutos e então é consertada. Foi também introduzida uma parada programada no bloco server bandejão que irá repor a comida a cada duas horas, bloqueando o funcionamento por 10 minutos. O tempo total de funcionamento do sistema é de cinco horas (300 minutos).

Obtivemos os seguintes resultados após a simulação deste módulo:

TALLY VARIABLES

Identifier Average Half Width Minimum Maximum Observations

WC_R_Q Queue Time 43.928 (Insuf) .00000 97.384 30 Bandeijao_R_Q Queue Ti 6.2572 (Insuf) .00000 20.046 77

DISCRETE-CHANGE VARIABLES

Identifier Average Half Width Minimum Maximum Final Value

Bandeijao_R Available .73333 (Insuf) .00000 1.0000 .00000 WC_R Busy .20551 (Insuf) .00000 1.0000 1.0000 # in WC_R_Q 6.7981 (Insuf) .00000 23.000 19.000 # in Bandeijao_R_Q 1.7300 (Insuf) .00000 8.0000 8.0000 Bandeijao_R Busy .56093 (Insuf) .00000 1.0000 1.0000 Bandeijao_R Downtime .06667 (Insuf) .00000 1.0000 .00000 WC_R Available 1.0000 (Insuf) 1.0000 1.0000 1.0000

. Resumo do Funcionamento do Banheiro do Restaurante (modelo2.doe): Existem dois vasos sanitários no banheiro. Foi introduzida uma escolha associada a uma variável externa determinando o funcionamento do banheiro de modo que se ele estiver ocupado, a pessoa escolhe o outro e caso este outro estiver ocupado, a pessoa vai embora. Ao liberar o banheiro outra pessoa pode usá-lo.

Obtivemos os seguintes resultados após a simulação deste módulo:

TALLY VARIABLES

Identifier Average Half Width Minimum Maximum Observations

Mesa1_R_Q Queue Time .00000 (Insuf) .00000 .00000 9 Mesa2_R_Q Queue Time .00000 (Insuf) .00000 .00000 12

DISCRETE-CHANGE VARIABLES

Identifier Average Half Width Minimum Maximum Final Value

# in Mesa2_R_Q .00000 (Insuf) .00000 .00000 .00000 # in Mesa1_R_Q .00000 (Insuf) .00000 .00000 .00000 Mesa2_R Busy .35612 (Insuf) .00000 1.0000 .00000 Mesa1_R Busy .58995 (Insuf) .00000 1.0000 .00000 Mesa2_R Available 1.0000 (Insuf) 1.0000 1.0000 1.0000 Mesa1_R Available 1.0000 (Insuf) 1.0000 1.0000 1.0000

. Resumo do Funcionamento do Bandejão (Refeição) do Restaurante (modelo-3.doe): Existem quatro blocos process representando as mesas, nas quais a pessoa “senta” para comer mediante a escolha da menor fila (bloco pickqueue). Ao final da execução, existe uma escolha (bloco inspect) para a pessoa escolher se volta e faz outra refeição ou segue para o próximo módulo.

Obtivemos os seguintes resultados após a simulação deste módulo:

TALLY VARIABLES

Identifier Average Half Width Minimum Maximum Observations

mesa1_R_Q Queue Time 2.2754 (Insuf) .00000 11.945 36
mesa2_R_Q Queue Time 1.7302 (Insuf) .00000 7.5426 38
Inspect 1_R_Q Queue Ti .34301 (Insuf) .00000 2.5168 120
mesa3_R_Q Queue Time 1.1525 (Insuf) .00000 6.7773 31
mesa4_R_Q Queue Time 1.1280 (Insuf) .00000 6.1161 20
DISCRETE-CHANGE VARIABLES
Identifier Average Half Width Minimum Maximum Final Value

mesa4_R Busy .63591 (Insuf) .00000 1.0000 1.0000 # in mesa2_R_Q .27395 (Insuf) .00000 2.0000 .00000 Inspect 1_R Available 1.0000 (Insuf) 1.0000 1.0000 1.0000 mesa3_R Busy .63266 (Insuf) .00000 1.0000 1.0000 # in mesa1_R_Q .34132 (Insuf) .00000 2.0000 .00000 mesa2_R Busy .77375 (Insuf) .00000 1.0000 1.0000 mesa1_R Busy .89447 (Insuf) .00000 1.0000 1.0000 mesa4_R Available 1.0000 (Insuf) 1.0000 1.0000 1.0000 mesa3_R Available 1.0000 (Insuf) 1.0000 1.0000 1.0000 mesa2_R Available 1.0000 (Insuf) 1.0000 1.0000 1.0000 mesa1_R Available 1.0000 (Insuf) 1.0000 1.0000 1.0000 Inspect 1_R Busy .50000 (Insuf) .00000 1.0000 .00000 # in mesa4_R_Q .09401 (Insuf) .00000 1.0000 .00000 # in mesa3_R_Q .14887 (Insuf) .00000 2.0000 .00000 # in Inspect 1_R_Q .17151 (Insuf) .00000 3.0000 .00000

. Resumo do Funcionamento do Café (modelo-4.doe): Existe uma probabilidade (bloco chance) de a pessoa tomar (50%) ou não (50%) café. Se ela tomar existe uma possibilidade (bloco inspect) de ela tomar mais ou seguir ao próximo módulo do sistema.

Obtivemos os seguintes resultados após a simulação deste módulo:

TALLY VARIABLES Identifier Average Half Width Minimum Maximum Observations

Cafe_R_Q Queue Time 1.2692 (Insuf) .00000 8.9865 60
Mais_Cafe_R_Q Queue Ti .10658 (Insuf) .00000 .92127 59
DISCRETE-CHANGE VARIABLES
Identifier Average Half Width Minimum Maximum Final Value

# in Mais_Cafe_R_Q .02620 (Insuf) .00000 1.0000 .00000 Mais_Cafe_R Available 1.0000 (Insuf) 1.0000 1.0000 1.0000 Cafe_R Available 1.0000 (Insuf) 1.0000 1.0000 1.0000 Cafe_R Busy .46484 (Insuf) .00000 1.0000 1.0000 Mais_Cafe_R Busy .24583 (Insuf) .00000 1.0000 .00000 # in Cafe_R_Q .31732 (Insuf) .00000 3.0000 .00000

. Resumo do Funcionamento do Caixa (modelo-5.doe): Existem dois atendentes (bloco process), para os quais as pessoas pagam suas contas escolhendo a menor fila através de um bloco pickqueue. Após elas pagarem elas vão embora e finaliza-se o sistema.

Obtivemos os seguintes resultados após a simulação deste módulo:

TALLY VARIABLES

Identifier Average Half Width Minimum Maximum Observations

caixa2_R_Q Queue Time 53.197 (Insuf) .00000 96.365 30 Caixa1_R_Q Queue Time 39.345 (Insuf) .00000 72.471 48

DISCRETE-CHANGE VARIABLES

Identifier Average Half Width Minimum Maximum Final Value

caixa2_R Available 1.0000 (Insuf) 1.0000 1.0000 1.0000 Caixa1_R Available 1.0000 (Insuf) 1.0000 1.0000 1.0000 # in caixa2_R_Q 10.208 (Insuf) .00000 18.000 18.000 caixa2_R Busy .98027 (Insuf) .00000 1.0000 1.0000 # in Caixa1_R_Q 10.551 (Insuf) .00000 19.000 18.000 Caixa1_R Busy .99167 (Insuf) .00000 1.0000 1.0000

Conclusão

Não foi possível a simulação do sistema como um todo devido as limitações da versão do Arena, pois o número limite de blocos num mesmo projeto foi excedido. Para sanar este problema, foi mediante sugestão do professor, dividido o projeto todo em cinco arquivos diferentes, cada um com uma funcionalidade existente no sistema. Isto não nos possibilitou resultados mais exatos e precisos para a simulação completa do sistema.

Mesmo assim, foi possível perceber a importância da simulação dentro de cada módulo, pois, como exemplo, poderíamos fazer reformas no banheiro ou na estrutura do bandejão para aumentarmos a capacidade de eficiência caso o uso destes estivessem gerando filas de tamanhos indesejáveis.

Referências Bibliográficas

Pado, Darci. “Usando o Arena em Simulação”. Belo Horizonte, MG: Editora de Desenvolvimento Gerencial. 1999. Rodrigues, “Luis. Apostila de Simulação de Sistemas”. Piracicaba, SP. Notas de Aula.

 
eXTReMe Tracker

"Falarei da magnificência gloriosa da tua majestade e das tuas obras maravilhosas." (Sl 145:5)

Webdesigner: Fabricio Breve 1997 - 2003
[email protected] - Privacidade