توضح هذه المقالة المكونات الجديدة لإطار المحاكاة ، والتي تم تقديمها مسبقًا في المقالة
"نظام بسيط للمحاكاة أثناء التنقل" . مع توسيع الإطار ، أصبح من الممكن تصميم أنظمة أكثر تعقيدًا ، على سبيل المثال ، لمحاكاة عمل المطعم.
مكونات جديدة
هناك العديد من المكونات الجديدة:
Bifacility ،
Split ،
التجميع ،
Count ،
تعيين ،
تحقق . لننظر فيها بمزيد من التفصيل.
Bifacility هي نفسها نفس
التسهيلات ، ولكن الغرض منها هو جعل المعاملة لا تأخذ مكونًا واحدًا لفترة من الوقت ، ولكن سلسلة من المكونات. لهذا الغرض ،
يُنشئ مُنشئ
Bifacility عنصرين - IN و OUT. بعد أن
تدخل إحدى المعاملات
في مكون IN ، تعتبر
Bifacility مشغولة ولم يعد بإمكانها معاملة أخرى. عندما تصل معاملة إلى مكون OUT ،
يتم تحرير
Bifacility ويمكن الآن أن تأخذها معاملة أخرى. فقط المعاملة التي احتلتها يمكنها تحرير
Bifacility . يمكن اعتبار أبسط تشابه
Bifacility تثبيتًا تقنيًا ينفذ عددًا من العمليات على جزء واحد. حتى يغادر الجزء التثبيت ، من المستحيل إرسال جزء آخر إليه.
انقسام - مكون مصمم لتقسيم معاملة إلى أجزاء - معاملات أخرى تتم معالجتها بالتوازي في المستقبل. على سبيل المثال ، إذا نظرنا إلى معاملة كطلب ، فإن أجزائها هي مراكز في الترتيب. بشكل افتراضي ، في حالة عدم وجود أي معلمات ، يقسم
Split المعاملة الناتجة بمقدار يساوي المكونات بعدها. من الممكن تحديد عدد الأجزاء ومع أي معدل (لإنشاء قيمة عشوائية) سيتم تنفيذ القسم. نظرًا لأنه في الممارسة العملية ، قد يكون من الضروري إجراء التقسيم إلى أجزاء وفقًا لبعض القوانين ، في
سبليت ، من الممكن توصيل معالجك الخاص بالتقسيم.
يقترن
Split بـ Aggregate ، كما يوحي الاسم ، فإنه يجمع سلسلة من المعاملات في واحدة. وظيفتها بسيطة للغاية ، حيث استلمت أيًا من أجزاء الصفقة التي تم كسرها مسبقًا ، وهي تنتظر جميع الأجزاء الأخرى وبعد تلقيها ترسل معاملة أخرى.
العد - مكون لحساب. منشئ
الكونت يشكل عنصرين - INC و DEC. عندما تدخل معاملة INC ، تزداد عدادات
Count ؛ وعندما تدخل إلى DEC ، تنخفض. في مُنشئ
Count ، يتم تعيين القيم التي يزيد بها العداد وينقص عندما يدخل INC و DEC ، على التوالي.
تعيين - مصمم لضبط بعض المعاملات المعلمة. تحتوي المعاملة على قائمة بالمعلمات ، ولكل معلمة اسم وقيمة. يمكن أن تكون القيمة عبارة عن سلسلة أو رقم أو بنية. عند تعيين لا شيء لمعلمة ، تتم إزالته من القائمة.
تحقق - مكون مصمم للتحقق من استيفاء شرط معين ويتخطى المعاملة فقط عند تنفيذها. افتراضيًا ، يتم التحقق من مساواة معلمة المعاملة بالقيمة المحددة. في "مُنشئ
الشيك" ، يمكنك تحديد الكتلة التي سيتم إرسال المعاملة إليها إذا كانت نتيجة الشيك
خاطئة . لزيادة المرونة ، من الممكن توصيل معالجها الخاص للتحقق من حالة تخطي المعاملة.
تجدر الإشارة إلى أنه عند تطوير الإطار ، لم يكن الهدف هو نسخ نظام تحديد المواقع العالمي (GPSS) بشكل كامل ، وبالتالي ، قد يتغير وظيفته مع الاسم المتطابق للمكونات.
نموذج المطعم
لم ينشأ قرار محاولة بناء نموذج مطعم من الصفر. أولاً ، يقوم عدد كبير من الناس بزيارتهم ، وثانياً ، هذا نظام انتظار معقد إلى حد ما ، ثالثًا ، كانت زوجتي تعمل في مجال المطاعم لعدة سنوات ، ويمكنني أن أستشيرها.
لذلك ، سوف نبدأ في وصف نموذج المطعم. سيكون المطعم على 24 طاولة. تسمى زوار المطعم "الضيوف" ، ويأتي الضيوف بشكل عشوائي ، وسيتم إنشاء هذه المعاملات. لكن المعاملة ليست شخصًا واحدًا ، فقد تكون مجموعة من الأشخاص الذين أخذوا جدولًا واحدًا فقط. لزيادة الواقعية ، إذا كان هناك أكثر من 6 ضيوف في قائمة الانتظار (هناك حاجة إلى 6 طاولات) في انتظار الجدول ، ثم يغادر الضيوف الجدد ، وليس الانتظار.
تقابل مضيفات الضيوف عند المدخل ، وفي المطاعم الكبيرة يوجد غالبًا اثنين أو أكثر ، وسيكون هناك اثنان في النموذج. في حالة وجود طاولات مجانية ، تؤدي مضيفاتهم إلى الطاولة ، وإذا لم تكن هناك طاولات مجانية ، فإن الضيوف ينتظرون. في المطاعم الحقيقية يوجد حجز وضيوف كبار ، للبساطة ، لن يكونوا في النموذج المبني ، ولكن يجب أن تؤخذ هذه الخطط في الاعتبار.
بعد أن يجلس الضيوف على طاولة ، يتم تقديمهم من قبل نادل ، وعادة ما يكون هناك نادل واحد لعدة طاولات ، في النموذج سيكون هناك واحد لثلاثة طاولات. كما هو الحال في مطعم منتظم ، لا يمكن للنادل تقديم عدة طاولات في وقت واحد ، ولكن يقدمها واحدة تلو الأخرى. أثناء الخدمة ، يتلقى النادل طلبًا من الضيوف. حسب الطلب يعني العديد من الأطباق من أنواع مختلفة والمشروبات. عدد الأطباق والمشروبات التي سيتم طلبها غير معروف مسبقًا ، لكننا سنحسب على الأقل واحدًا ولا يزيد عن خمسة ، بما في ذلك الطلب في البار. يقوم النادل ، بعد استلام الطلب ، بتمريره إلى الطهاة والسقاة.
تقليديا ، من بين الطهاة هناك تخصصات: المقبلات والسلطات واللحوم والكعك والحلويات والسوشي. سيكون هناك أيضًا في المطعم المحاكي - أربعة طهاة يقومون بإعداد أطباق مختلفة. سيكون هناك اثنين من السقاة.
إنها ممارسة شائعة لا تجلبها جميع الأطباق فورًا ، ولكن في أسرع وقت ممكن. تبعا لذلك ، لا يأكل الضيوف كل منهم دفعة واحدة ، ولكن تدريجيا. وفقط عندما يأكلون جميع الأطباق ، يمكنك أن تدفع ثمن الطلب. بعد ذلك ، يمكن إخلاء الجدول.
يمكن عرض معلمات زمنية محددة في
الكود .
تصميم
في التين. 1 يوضح الرسم البياني الهيكلي للنموذج. للنمذجة ، تشارك مجموعة كاملة من مكونات الإطار تقريبًا. لذلك ، لتقدير عدد الضيوف في قائمة الانتظار ، يتم استخدام مكون
التحقق . باستخدام معالج متخصص ، يتحقق من عدد الضيوف في قائمة الانتظار ، وإذا تم تجاوز الرقم المحدد ، يرسلهم إلى الخروج.
تحقق أيضًا من التحقق من ظهور طاولات مجانية.
التين. 1. المخطط الهيكلي لنموذج المطعممع
Bifacility ، يمكنك شغل وتحرير الجدول. ويتيح لك
تعيين إقران مع
Check تحديد ما إذا كان النادل ينقل الطلب من الطاولة إلى المطبخ أو يقدم الأطباق الجاهزة بالفعل.
كما يمكن أن يرى من التين. 1 لكل من الطهاة قائمة انتظار من الطلبات ، في الواقع ، بالطبع ، من الممكن طهي العديد من الأطباق بشكل متوازٍ ، لكن في النموذج المقدم تم حذف هذا. بالنسبة للنادلين ، قائمة انتظار الطلب شائعة.
نتائج المحاكاة
يمكن العثور على نتائج المحاكاة
هنا . يظهر التقرير:
- لم يتم استخدام جدولين (23 و 24) ، وبشكل عام ، لا يتم استخدام ربع الجداول عملياً ؛
- خدم المطعم 29 زائرًا ولم يغادر أي زائر من دون دخول المطعم ؛
- لم يكن على الزوار الانتظار في الطابور ؛
- في نهاية المحاكاة ، تلقى 12 زائرًا جزءًا من طلبهم وتوقعوا الأطباق المتبقية ؛
- طباخ 1 و 4 له حمولة كبيرة جدًا (91.46٪ ، 88.33٪) ؛
- Barman 2 ليس محملاً بالعمل (1.67٪) ؛
- نصف النوادل ليسوا مشغولين بشكل خاص ؛
- المضيفة 2 ليست مشغولة تقريبًا (9.38٪).
خلاصة القول ، المطعم كبير ولديه الكثير من الموظفين الإضافيين. أو يفتح المطعم في مكان به حركة مرور ضعيفة (في النموذج المقدم ، يدخل الزوار كل 10 إلى 5 دقائق). إذا قمت بإجراء اختبار مع زيادة عدد الزيارات (5 ± 3) ، فإن حجم الموظفين يزداد بشكل كبير ، لكن بعض الزوار يغادرون دون انتظار جدول.
استنتاج
النموذج المقدم ، على الرغم من عدد من التبسيط ، يسمح لك بشكل محتمل بمحاكاة عمل المطعم وربما له قيمة عملية. لكن المكونات ، القديمة والجديدة ، تحتاج بالتأكيد إلى مزيد من التطوير. لا تتم معالجة جميع الاستثناءات أو معالجتها بشكل غير صحيح. من الضروري تغطية رمز الإطار مع الاختبارات وأهم الوثائق. كل هذا مخطط له وسيتم تحقيقه قدر الإمكان.