Suatu hari dalam kehidupan seorang model restoran

Artikel ini menjelaskan komponen-komponen baru kerangka kerja untuk simulasi, yang sebelumnya disajikan dalam artikel “Sistem Simulasi Sederhana yang Sedang Berjalan” . Ketika kerangka kerja diperluas, dimungkinkan untuk membuat model sistem yang lebih kompleks, misalnya, untuk mensimulasikan pekerjaan restoran.

Komponen baru

Ada beberapa komponen baru: Bifacility , Split , Agregat , Hitungan , Tetapkan , Periksa . Mari kita pertimbangkan secara lebih detail.

Bifacility pada dasarnya sama dengan Fasilitas , tetapi tujuannya adalah untuk membuat transaksi mengambil bukan komponen tunggal untuk sementara waktu, tetapi rantai komponen. Untuk ini, konstruktor Bifacility membentuk dua komponen - IN dan OUT. Setelah transaksi memasuki komponen IN, Bifacility dianggap sibuk dan transaksi lain tidak dapat lagi menerimanya. Ketika transaksi mencapai komponen KELUAR, Bifacility dibebaskan dan sekarang transaksi lain dapat mengambilnya. Hanya transaksi yang menanganinya yang dapat melepaskan Bifacility . Analogi Bifacility yang paling sederhana dapat dianggap sebagai instalasi teknologi yang melakukan sejumlah operasi pada satu bagian. Sampai bagian tersebut meninggalkan instalasi, tidak mungkin untuk mengirim bagian lain untuk itu.

Split - komponen yang dirancang untuk membagi transaksi menjadi beberapa bagian - transaksi lain yang diproses secara paralel di masa mendatang. Misalnya, jika kita menganggap transaksi sebagai pesanan, maka bagian-bagiannya adalah posisi dalam pesanan. Secara default, dengan tidak adanya parameter apa pun, Split membagi transaksi yang dihasilkan dengan jumlah yang sama dengan komponen setelahnya. Dimungkinkan untuk menentukan berapa banyak bagian dan dengan pengubah mana (untuk menghasilkan nilai acak) partisi akan dilakukan. Karena dalam praktiknya mungkin diperlukan pemisahan menjadi beberapa bagian menurut beberapa hukum, di Split dimungkinkan untuk menghubungkan handler Anda sendiri untuk pemisahan.

Dipasangkan dengan Split adalah Agregat , sesuai namanya, agregat serangkaian transaksi menjadi satu. Fungsinya cukup sederhana, setelah menerima salah satu bagian dari transaksi yang sebelumnya rusak, ia menunggu semua bagian lain dan setelah menerima mereka mengirim transaksi lebih lanjut.

Count - komponen untuk menghitung. Konstruktor Count membentuk dua komponen - INC dan DEC. Ketika transaksi memasuki INC, penghitung Count meningkat, ketika memasuki DEC, itu menurun. Dalam konstruktor Count, nilai ditetapkan dengan mana counter meningkat dan menurun ketika memasuki INC dan DEC, masing-masing.

Tetapkan - dirancang untuk mengatur beberapa parameter transaksi. Suatu transaksi memiliki daftar parameter, setiap parameter memiliki nama dan nilai. Nilai dapat berupa string, angka, struktur. Saat menetapkan nil ke suatu parameter, parameter itu dihapus dari daftar.

Periksa - komponen yang dirancang untuk memverifikasi pemenuhan kondisi tertentu dan melewatkan transaksi hanya ketika dieksekusi. Secara default, kesetaraan parameter transaksi dengan nilai yang ditentukan diperiksa. Di konstruktor Periksa , Anda dapat menentukan blok tempat transaksi akan dikirim jika hasil pemeriksaan salah . Untuk meningkatkan fleksibilitas, adalah mungkin untuk menghubungkan handlernya sendiri untuk memeriksa kondisi lompatan transaksi.

Perlu dicatat bahwa ketika mengembangkan kerangka kerja, tujuannya bukan untuk menyalin GPSS sepenuhnya, oleh karena itu, dengan nama komponen yang identik, fungsinya mungkin berbeda-beda.

Model Restoran

Keputusan untuk mencoba membangun model restoran muncul bukan dari awal. Pertama, cukup banyak orang mengunjungi mereka, kedua, ini adalah sistem antrian yang agak rumit, ketiga, istri saya telah bekerja di bisnis restoran selama bertahun-tahun, dan saya bisa berkonsultasi dengannya.

Jadi, kita akan mulai menggambarkan model restoran. Restoran akan berada di 24 meja. Pengunjung restoran disebut "tamu", tamu datang secara acak, ini akan menghasilkan transaksi. Tapi transaksinya bukan satu orang, bisa jadi sekelompok orang yang hanya mengambil satu meja. Untuk meningkatkan realisme, jika ada lebih dari 6 tamu dalam antrian (diperlukan 6 tabel) menunggu meja, maka tamu baru pergi, bukan menunggu.

Nyonya rumah bertemu tamu di pintu masuk, di restoran besar sering ada dua atau lebih, akan ada dua dalam model. Jika ada meja gratis, nyonya rumah membawa mereka ke meja, jika tidak ada meja gratis, para tamu menunggu. Di restoran nyata ada reservasi dan tamu VIP, untuk kesederhanaan, mereka tidak akan berada dalam model yang dibangun, tetapi rencana tersebut harus diperhitungkan.
Setelah para tamu duduk di sebuah meja, mereka dilayani oleh seorang pelayan, biasanya satu pelayan untuk beberapa meja, dalam model akan ada satu untuk tiga meja. Seperti di restoran biasa, pelayan tidak bisa melayani beberapa meja sekaligus, tetapi melayani mereka satu per satu. Selama layanan, pelayan menerima pesanan dari para tamu. Berdasarkan pesanan berarti beberapa hidangan dari berbagai jenis dan minuman. Berapa banyak hidangan dan minuman yang akan dipesan tidak diketahui sebelumnya, tetapi kami akan menghitung setidaknya satu dan tidak lebih dari lima, termasuk memesan di sebuah bar. Pelayan, setelah menerima pesanan, menyerahkannya ke juru masak dan bartender.

Secara tradisional, di antara koki ada spesialisasi: makanan pembuka dan salad, daging, kue dan makanan penutup, sushi. Juga akan ada di restoran simulasi - empat koki menyiapkan hidangan yang berbeda. Akan ada dua bartender.

Ini adalah praktik umum yang tidak semua hidangan segera dibawa, tetapi segera setelah siap. Dengan demikian, para tamu tidak memakannya sekaligus, tetapi secara bertahap. Dan hanya ketika mereka makan semua hidangan Anda dapat membayar pesanan. Setelah itu, meja bisa dikosongkan.

Parameter waktu spesifik dapat dilihat dalam kode .

Pemodelan

Dalam gbr. 1 menunjukkan diagram struktural model. Untuk pemodelan, hampir seluruh rangkaian komponen kerangka terlibat. Jadi, untuk memperkirakan jumlah tamu dalam antrian, komponen Periksa digunakan. Menggunakan penangan khusus, ia memeriksa jumlah tamu dalam antrian dan, jika jumlah yang ditentukan terlampaui, mengirim mereka ke pintu keluar. Periksa juga periksa apakah tabel gratis telah muncul.


Fig. 1. Diagram struktural dari model restoran

Dengan Bifacility , Anda dapat menempati dan membebaskan meja. Dan Assign yang dipasangkan dengan Check memungkinkan Anda menentukan apakah pelayan mentransfer pesanan dari meja ke dapur atau sudah memberikan hidangan yang sudah jadi.

Seperti yang bisa dilihat dari gambar. 1 masing-masing koki memiliki antrian pesanan, pada kenyataannya, tentu saja, dimungkinkan untuk memasak beberapa hidangan secara paralel, tetapi dalam model yang disajikan ini dihilangkan. Untuk bartender, antrian pesanan adalah hal biasa.

Hasil simulasi

Hasil simulasi dapat ditemukan di sini . Laporan menunjukkan:

• dua tabel tidak digunakan (23 dan 24), dan secara umum, seperempat tabel praktis tidak digunakan;
• restoran melayani 29 pengunjung dan tidak ada pengunjung yang pergi tanpa memasuki restoran;
• pengunjung tidak harus mengantri;
• pada akhir simulasi, 12 pengunjung menerima sebagian dari pesanan mereka dan mengharapkan hidangan yang tersisa;
  
• koki 1 dan 4 memiliki muatan yang sangat besar (91,46%, 88,33%);
• Barman 2 tidak dimuat dengan pekerjaan (1,67%);
• setengah dari pelayan tidak terlalu sibuk;
• nyonya rumah 2 hampir tidak sibuk (9,38%).

Intinya, restoran ini besar dan memiliki banyak staf tambahan. Atau restoran buka di tempat dengan lalu lintas yang buruk (dalam model yang disajikan, pengunjung masuk setiap 10 ± 5 menit). Jika Anda menguji dengan lalu lintas yang lebih besar (5 ± 3), beban staf meningkat secara signifikan, tetapi beberapa pengunjung pergi tanpa menunggu meja.

Kesimpulan

Model yang disajikan, meskipun memiliki sejumlah penyederhanaan, cukup lumayan memungkinkan Anda untuk mensimulasikan pekerjaan restoran dan bahkan mungkin memiliki nilai praktis. Tetapi komponen, baik yang baru dan yang lama, tentu perlu dikembangkan lebih lanjut. Tidak semua pengecualian ditangani atau ditangani secara tidak benar. Penting untuk mencakup kode kerangka kerja dengan tes dan dokumentasi yang paling penting. Semua ini direncanakan dan sejauh mungkin akan terwujud.