Un jour dans la vie d'un modèle de restaurant

Cet article décrit les nouveaux composants du cadre de simulation, précédemment présentés dans l'article «Un système simple de simulation en marche» . À mesure que le cadre s'est élargi, il est devenu possible de modéliser des systèmes plus complexes, par exemple pour simuler le travail d'un restaurant.

De nouveaux composants

Il y a plusieurs nouveaux composants: Bifacilité , Split , Aggregate , Count , Assign , Check . Examinons-les plus en détail.

La bifacilité est essentiellement la même que l' installation , mais son objectif est de faire en sorte que la transaction ne prenne pas un composant pendant un certain temps, mais une chaîne de composants. Pour cela, le constructeur Bifacility forme deux composants - IN et OUT. Après qu'une transaction entre dans le composant IN, Bifacility est considérée comme occupée et une autre transaction ne peut plus la prendre. Lorsqu'une transaction atteint le composant OUT, Bifacility est libérée et maintenant une autre transaction peut la prendre. Seule la transaction qui l'a occupé peut libérer Bifacility . L'analogie la plus simple de Bifacility peut être considérée comme une installation technologique qui effectue un certain nombre d'opérations sur une partie. Tant que la pièce ne quitte pas l'installation, il est impossible de lui envoyer une autre pièce.

Split - un composant conçu pour diviser une transaction en parties - d'autres transactions traitées en parallèle à l'avenir. Par exemple, si nous considérons une transaction comme un ordre, alors ses parties sont des positions dans l'ordre. Par défaut, en l'absence de paramètres, Split divise la transaction résultante par un montant égal aux composants qui la suivent. Il est possible de spécifier le nombre de pièces et avec quel modificateur (pour générer une valeur aléatoire) la partition sera effectuée. Étant donné qu'en pratique, il peut être nécessaire que le fractionnement en pièces soit effectué conformément à certaines lois, à Split, il est possible de connecter votre propre gestionnaire pour le fractionnement.

Associé à Split est Aggregate , comme son nom l'indique, il agrège une série de transactions en une seule. Sa fonctionnalité est assez simple, ayant reçu l'une des parties d'une transaction précédemment interrompue, il attend toutes les autres parties et après les avoir reçues, envoie une transaction plus loin.

Count - composant pour compter. Le constructeur Count forme deux composants - INC et DEC. Lorsqu'une transaction entre dans INC, le compteur Count augmente; quand il entre dans DEC, il diminue. Dans le constructeur de Count, les valeurs sont définies par lesquelles le compteur augmente et diminue lorsqu'il entre respectivement INC et DEC.

Attribuer - conçu pour définir certains paramètres de transaction. Une transaction a une liste de paramètres, chaque paramètre a un nom et une valeur. La valeur peut être une chaîne, un nombre, une structure. Lorsque vous affectez nil à un paramètre, il est supprimé de la liste.

Vérifier - un composant conçu pour vérifier la réalisation d'une certaine condition et ignore une transaction uniquement lorsqu'elle est exécutée. Par défaut, l'égalité du paramètre de transaction à la valeur spécifiée est vérifiée. Dans le constructeur Check , vous pouvez spécifier le bloc auquel la transaction sera envoyée si le résultat de la vérification est faux . Pour augmenter la flexibilité, il est possible de connecter son propre gestionnaire pour vérifier la condition du saut de transaction.

Il est à noter que lors du développement du framework, l'objectif n'était pas de copier complètement GPSS, donc, avec le nom identique des composants, leur fonctionnalité peut varier.

Modèle de restaurant

La décision d'essayer de construire un modèle de restaurant n'est pas née de toutes pièces. Premièrement, beaucoup de gens leur rendent visite, deuxièmement, c'est un système de file d'attente assez compliqué, troisièmement, ma femme travaille dans le secteur de la restauration depuis de nombreuses années et je pourrais la consulter.

Nous allons donc commencer à décrire le modèle du restaurant. Le restaurant sera à 24 tables. Les visiteurs du restaurant sont appelés «invités», les invités viennent au hasard, ce seront des transactions générées. Mais la transaction n'est pas une seule personne, il peut s'agir d'un groupe de personnes qui vient de prendre une table. Pour augmenter le réalisme, s'il y a plus de 6 invités dans la file d'attente (6 tables sont nécessaires) en attente d'une table, alors de nouveaux invités partent, n'attendez pas.

Les hôtesses rencontrent les invités à l'entrée, dans les grands restaurants il y en a souvent deux ou plus, il y en aura deux dans le modèle. Dans le cas où il y a des tables gratuites, les hôtesses les conduisent à la table, s'il n'y a pas de tables gratuites, les invités attendent. Dans les vrais restaurants, il y a une réservation et les invités VIP, pour plus de simplicité, ils ne seront pas dans le modèle construit, mais de tels plans doivent être pris en compte.
Après que les invités soient assis à une table, ils sont servis par un serveur, généralement un serveur pour plusieurs tables, dans le modèle il y en aura un pour trois tables. Comme dans un restaurant ordinaire, le serveur ne peut pas servir plusieurs tables à la fois, mais les sert une à la fois. Pendant le service, le serveur reçoit une commande des invités. Par ordre, on entend plusieurs plats de différents types et boissons. Le nombre de plats et de boissons qui seront commandés n'est pas connu à l'avance, mais nous en compterons au moins un et pas plus de cinq, y compris la commande dans un bar. Le serveur, ayant reçu la commande, la passe aux cuisiniers et barmans.

Traditionnellement, parmi les cuisiniers, il existe des spécialisations: apéritifs et salades, viande, gâteaux et desserts, sushi. Il y aura également dans le restaurant simulé - quatre chefs préparant des plats différents. Il y aura deux barmen.

C'est une pratique courante que tous les plats n'apportent pas immédiatement, mais dès qu'ils sont prêts. En conséquence, les convives ne les mangent pas tous en même temps, mais progressivement. Et ce n'est que lorsqu'ils ont mangé tous les plats que vous pouvez payer la commande. Après cela, la table peut être libérée.

Des paramètres horaires spécifiques peuvent être consultés dans le code .

Modélisation

Dans la fig. 1 montre le schéma structurel du modèle. Pour la modélisation, la quasi-totalité de l'ensemble des composants du cadre est impliquée. Ainsi, pour estimer le nombre d'invités dans la file d'attente, le composant Vérifier est utilisé. À l'aide d'un gestionnaire spécialisé, il vérifie le nombre d'invités dans la file d'attente et, si le nombre spécifié est dépassé, les envoie à la sortie. Vérifier vérifie également si des tables libres sont apparues.


Fig. 1. Le schéma structurel du modèle de restaurant

Avec Bifacility , vous pouvez occuper et libérer la table. Et Assigner associé à Chèque vous permet de spécifier si le serveur transfère la commande de la table à la cuisine ou livre déjà les plats finis.

Comme on peut le voir sur la fig. 1 chacun des chefs a une file de commandes, en réalité, bien sûr, il est possible de cuisiner plusieurs plats en parallèle, mais dans le modèle présenté, cela est omis. Pour les barmans, la file d'attente des commandes est courante.

Résultats de la simulation

Les résultats de la simulation peuvent être trouvés ici . Le rapport montre:

• deux tableaux n'ont pas été utilisés (23 et 24) et, en général, un quart des tableaux ne sont pratiquement pas utilisés;
• le restaurant a servi 29 visiteurs et aucun des visiteurs n'est parti sans jamais entrer dans le restaurant;
• les visiteurs n'ont pas eu à faire la queue;
• à la fin de la simulation, 12 visiteurs ont reçu une partie de leur commande et attendaient les plats restants;
  
• les cuisiniers 1 et 4 ont une très grande charge (91,46%, 88,33%);
• Barman 2 n'est pas chargé de travail (1,67%);
• la moitié des serveurs ne sont pas particulièrement occupés;
• l'hôtesse 2 n'est presque pas occupée (9,38%).

En bout de ligne, le restaurant est grand et a beaucoup de personnel supplémentaire. Ou le restaurant est ouvert dans un endroit à faible trafic (dans le modèle présenté, les visiteurs entrent toutes les 10 ± 5 minutes). Si vous testez avec un trafic plus important (5 ± 3), la charge de personnel augmente considérablement, mais certains visiteurs partent sans attendre une table.

Conclusion

Le modèle présenté, malgré un certain nombre de simplifications, vous permet assez bien de simuler le travail du restaurant et peut-être même a une valeur pratique. Mais les composants, nouveaux et anciens, doivent certainement être développés davantage. Toutes les exceptions ne sont pas gérées ou gérées de manière incorrecte. Il est nécessaire de couvrir le code du framework avec des tests et la documentation la plus importante. Tout cela est prévu et, dans la mesure du possible, sera réalisé.