本文介绍了先前在文章
“ Go上的简单模拟系统”中介绍的模拟框架的新组件。 随着框架的扩展，可以对更复杂的系统进行建模，例如，模拟餐厅的工作。
新组件
有几个新组件：
Bifacility ，
Split ，
Aggregate ，
Count ，
Assign ，
Check 。 让我们更详细地考虑它们。
Bifacility本质上与
Facility相同，但其目的是使事务在一段时间内不占用单个组件，而是占用一系列组件。 为此，
Bifacility构造函数形成两个组件
-IN和OUT。 事务
进入 IN组件后，
Bifacility被视为繁忙，其他事务无法再使用它。 当一个事务到达OUT组件时，
Bifacility被释放，现在另一个事务可以使用它。 只有占用它的事务才能释放
Bifacility 。
Bifacility的最简单类比可以被认为是在一个部件上执行许多操作的技术安装。 在零件离开安装之前，无法向其发送另一个零件。
拆分 -用于将事务拆分为多个部分的组件-将来会并行处理的其他事务。 例如，如果我们将交易视为订单，则其部分就是订单中的头寸。 默认情况下，在没有任何参数的情况下，
Split将所得交易除以等于其后组成部分的金额。 可以指定要执行分区的部分以及使用哪个修饰符（以生成随机值）。 由于实际上可能需要根据某些法律进行
拆分，因此在
拆分中可以连接自己的处理程序进行拆分。
顾名思义，与
Split配对的
是 Aggregate ，它将一系列事务聚合为一个。 它的功能非常简单，已经收到了先前中断的交易的任何部分，它等待所有其他部分，并在收到其他部分后进一步发送交易。
计数 -用于计数的组件。
Count构造函数形成两个组件-INC和DEC。 当事务进入INC时，
计数计数器增加；当事务进入DEC时，
计数减少。 在
Count的构造函数中
，设置了一些值，当计数器分别输入INC和DEC时，该值将增加或减少。
分配 -旨在设置一些交易参数。 一个事务有一个参数列表，每个参数都有一个名称和一个值。 该值可以是字符串，数字，结构。 将nil分配给参数时，将从列表中将其删除。
Check-用于验证特定条件是否满足的组件，仅在执行时才跳过事务。 默认情况下，将检查transaction参数与指定值的相等性。 在
Check构造函数中，如果检查结果为
false ，则可以指定将事务发送到的块。 为了增加灵活性，可以连接其自己的处理程序以检查事务跳过的条件。
值得注意的是，在开发框架时，目标不是完全复制GPSS，因此，使用相同的组件名称，其功能可能会有所不同。
餐厅模型
尝试建立餐厅模型的决定并非从零开始。 首先，很多人来拜访他们，其次，这是一个相当复杂的排队系统，其次，我的妻子已经在餐饮业工作了很多年，我可以向她咨询。
因此，我们将开始描述餐厅的模型。 餐厅将在24桌位。 餐馆的访客被称为“客人”，客人是随机来的，这些将产生交易。 但是交易不是一个人，它可以是一群只拿一张桌子的人。 为了增加真实性，如果队列中有6个以上的来宾（需要6个表）在等待一个表，那么新来宾将离开而不是等待。
女主人在入口处会见客人，在大型餐厅中通常会有两个或两个以上，在模型中将有两个。 如果有免费桌子，礼仪小姐会带他们到桌子，如果没有免费桌子，客人们正在等待。 在真实的餐厅中，有一个预订区和VIP来宾，为简单起见，它们不会出现在构建的模型中，但是必须考虑这些计划。
在客人坐在一张桌子后，他们由一个服务生服务，通常是一个服务员招待几张桌子，在模型中将有一个供三张桌子使用。 就像在普通餐厅一样，服务生不能一次提供多张桌子，而是一次提供一张。 服务期间，服务员收到客人的订单。 订购是指各种类型的各种菜肴和饮料。 事先不知道要订购多少种菜肴和饮料，但是我们将计算至少一种且不超过五种，包括在酒吧订购。 接到订单的服务员将其传递给厨师和调酒师。
传统上，厨师中有专长：开胃菜和沙拉，肉，蛋糕和甜点，寿司。 在模拟餐厅中还将有-四位厨师准备不同的菜肴。 将有两个调酒师。
通常的做法是并非所有菜肴都立即带来，但要尽快带来。 因此，客人不是一次全部吃掉而是逐步吃掉。 只有当他们吃完所有的菜后，您才能为订单付款。 之后，该表可以腾空。
特定的时间参数可以在
代码中查看。
造型
在图。 图1示出了该模型的结构图。 对于建模，涉及框架的几乎整个组件。 因此，为了估计队列中的访客数量，使用了
Check组件。 他使用专门的处理程序，检查队列中的来宾数目，如果超过了指定数目，则将其发送到出口。
还检查是否有空闲表出现。
图 1.餐厅模型的结构图使用
Bifacility ，您可以占用并释放桌子。 “
分配”和“
检查”配对可以让您指定服务员是将订单从桌子转移到厨房还是已经交付了成品。
从图可以看出。 1每个厨师都有一个订单队列，实际上，当然可以并行烹饪多个菜肴，但是在提出的模型中将其省略。 对于调酒师，订购队列很常见。
仿真结果
仿真结果可以在
这里找到。 该报告显示：
- 没有使用两个表（23和24），通常，实际上没有使用四分之一的表；
- 该餐厅为29位游客提供了服务，但没有任何游客没有进入餐厅就离开；
- 访客不必排队等候；
- 在模拟结束时，有12位访客收到了部分订单，并期望剩余的菜肴；
- 厨师1和4的负荷非常大（91.46％，88.33％）;
- 酒保2的工作量不大（1.67％）；
- 一半的服务员不是特别忙；
- 女主人2几乎不忙（9.38％）。
最重要的是，餐厅很大，有很多额外的员工。 或者，餐厅在人流稀少的地方营业（在提出的模型中，访客每10±5分钟进入一次）。 如果您以更高的流量（5±3）进行测试，则工作人员的负担会显着增加，但有些访客会离开而不必等待桌子。
结论
尽管有许多简化，但所提供的模型可以容忍地模拟餐厅的工作，甚至可能具有实用价值。 但是，新旧组件肯定都需要进一步开发。 并非所有异常都得到正确处理或处理。 有必要用测试和最重要的文档覆盖框架代码。 所有这些都是计划好的，并且将在可能的范围内实现。