この記事では、以前の記事「Goでの簡単なシミュレーションシステム」で説明したシミュレーションフレームワークの新しいコンポーネントについて説明します。 フレームワークが拡張されると、たとえばレストランの仕事をシミュレートするなど、より複雑なシステムをシミュレートすることが可能になりました。
新しいコンポーネント
いくつかの新しいコンポーネントがあります： Bifacility 、 Split 、 Aggregate 、 Count 、 Assign 、 Check 。 それらをより詳細に検討しましょう。
バイファリティは基本的にFacilityと似ていますが、その目的は、トランザクションがしばらくの間1つのコンポーネントではなく、コンポーネントのチェーンを占有するようにすることです。 このため、 Bifacilityコンストラクターは、INとOUTの2つのコンポーネントを形成します。 トランザクションが INコンポーネントに入ると 、 Bifacilityはビジーと見なされ、別のトランザクションはそれを取得できなくなります。 トランザクションがOUTコンポーネントに入ると 、 Bifacilityが解放され、別のトランザクションがそれを取得できるようになります。 それを占有したトランザクションのみがBifacilityを解放できます。 Bifacilityの最も単純な例えは、1つのパーツで多数の操作を実行する技術的なインストールと考えることができます。 パーツがインストールを離れるまで、別のパーツをインストールすることはできません。
分割 -トランザクションをパーツに分割するように設計されたコンポーネント-将来並行して処理される他のトランザクション。 たとえば、トランザクションをオーダーと見なす場合、そのパーツはオーダー内のポジションです。 デフォルトでは、パラメータがない場合、 Splitは結果のトランザクションをその後のコンポーネントに等しい量で分割します。 パーティションが実行されるパーツの数と修飾子（ランダム値を生成するため）を指定できます。 実際には、いくつかの法律に従って部品への分割を実行する必要がある場合があるため、 分割では、 分割のために独自のハンドラーを接続する機会があります。
Splitとペアになっているのは Aggregateで、名前が示すとおり、一連のトランザクションを1つに集約します。 その機能は非常にシンプルで、以前に壊れたトランザクションの一部を受信し、他のすべての部分を待機し、受信後にさらにトランザクションを送信します。
カウント -カウント用のコンポーネント。 Countコンストラクターは、INCとDECの2つのコンポーネントを形成します。 トランザクションがINCに入ると、 Countカウンターが増加し、DECに入ると減少します。 Countのコンストラクターでは、カウンターがINCとDECにそれぞれ入ったときにカウンターが増減する値が設定されます。
割り当て -トランザクションパラメータを設定するように設計されています。 トランザクションにはパラメーターのリストがあり、各パラメーターには名前と値があります。 値には、文字列、数値、構造を指定できます。 パラメータにnilを割り当てると、リストから削除されます。
チェック -特定の条件が満たされていることを確認するように設計されたコンポーネントで、実行されたときにのみトランザクションをスキップします。 デフォルトでは、トランザクションパラメータと指定された値の等価性がチェックされます。 Checkコンストラクターでは、チェックの結果がfalseの場合にトランザクションが送信されるブロックを指定できます。 柔軟性を高めるために、独自のハンドラーを接続して、トランザクションのスキップの状態を確認することができます。
フレームワークを開発するときの目標は、GPSSを完全にコピーすることではなかったため、コンポーネントの名前が同じでも機能が異なる場合があることに注意してください。
レストランモデル
レストランモデルを構築しようとする決定は、ゼロから生じたものではありません。 第一に、かなり多くの人々が彼らを訪れます。第二に、これはかなり複雑な待ち行列システムです。第三に、私の妻は長年レストランで働いており、彼女に相談することができました。
そこで、レストランのモデルについて説明し始めます。 レストランは24のテーブルに配置されます。 レストランの訪問者は「ゲスト」と呼ばれ、ゲストはランダムに来ます。これらはトランザクションで生成されます。 ただし、トランザクションは1人ではなく、1つのテーブルを取得した人のグループにすることができます。 現実感を高めるために、待ち行列に6人以上のゲスト（6つのテーブルが必要）がテーブルを待っている場合、新しいゲストは待たずに退場します。
ホステスは入り口でゲストに会います。大きなレストランではしばしば2人以上、モデルには2人います。 空きテーブルがある場合は、ホステスがテーブルに案内し、空きテーブルがない場合はゲストが待っています。 実際のレストランには予約とVIPゲストがいます。簡単にするために、構築されたモデルには含まれませんが、そのような計画を考慮する必要があります。
ゲストがテーブルに着席すると、ウェイター、通常は複数のテーブルのウェイターがサービスを提供します。モデルには3つのテーブルに1つがあります。 通常のレストランのように、ウェイターは一度に複数のテーブルを提供することはできませんが、一度に1つずつ提供します。 サービス中、ウェイターはゲストから注文を受け取ります。 注文とは、いくつかの異なる種類の料理や飲み物を指します。 注文する料理と飲み物の数は事前にわかりませんが、バーでの注文を含め、少なくとも1つから5つまでをカウントします。 注文を受けたウェイターは、料理人とバーテンダーに渡します。
伝統的に、料理人には専門分野があります：前菜とサラダ、肉、ケーキとデザート、寿司。 シミュレートされたレストランにもあります-4人のシェフが異なる料理を準備します。 2人のバーテンダーがいます。
すべての料理がすぐに運ばれるのではなく、準備が整い次第、持ち込むのが一般的です。 したがって、ゲストはそれらを一度にすべてではなく、徐々に食べます。 そして、彼らがすべての料理を食べた場合にのみ、注文の代金を支払うことができます。 その後、テーブルを空にすることができます。
特定の時間パラメータをコードで表示できます 。
モデリング
図 モデルの構造図を図1に示します。 モデリングには、フレームワークのほぼすべてのコンポーネントセットが含まれます。 そのため、キュー内のゲストの数を推定するために、 Checkコンポーネントが使用されます。 特別なハンドラーを使用して、キュー内のゲストの数を確認し、指定された数を超えた場合、ゲストを出口に送信します。 チェックは、空きテーブルが表示されているかどうかもチェックします。
図 1.レストランモデルの構造図
Bifacilityを使用すると、テーブルを占有して解放できます。 また、 チェックと組み合わせて割り当てを使用すると、ウェイターが注文をテーブルからキッチンに転送するか、既製の食事を既に配達するかを指定できます。
図からわかるように 1各シェフには注文の列がありますが、実際にはもちろん、いくつかの料理を並行して調理することは可能ですが、提示されたモデルではこれは省略されています。 バーテンダーの場合、注文キューは一般的です。
シミュレーション結果
シミュレーションの結果はここにあります 。 レポートには以下が表示されます。
- 2つのテーブル（23と24）は使用されませんでした。一般に、テーブルの4分の1は実際には使用されません。
- このレストランは29人の訪問者にサービスを提供し、訪問者は誰もレストランに入らずに立ち去りませんでした。
- 訪問者は並んで待つ必要はありませんでした。
- シミュレーションの最後に、12人の訪問者が注文の一部を受け取り、残りの料理を予想しました。
- クック1と4の負荷は非常に大きい（91.46％、88.33％）。
- バーマン2は仕事を積んでいません（1.67％）。
- ウェイターの半数は特に忙しくない。
- ホステス2はほとんど忙しくありません（9.38％）。
一番下の行、レストランは大きく、多くの余分なスタッフがいます。 または、レストランは交通量の少ない場所で営業しています（提示されたモデルでは、訪問者は10±5分ごとに入場します）。 より大きなトラフィック（5±3）でテストすると、スタッフの負荷が大幅に増加しますが、一部の訪問者はテーブルを待たずに立ち去ります。
おわりに
提示されたモデルは、いくつかの単純化にもかかわらず、かなり許容できるほどレストランの仕事をシミュレートすることができ、場合によっては実用的な価値さえあります。 ただし、新旧両方のコンポーネントを確実にさらに開発する必要があります。 すべての例外が処理されたり、正しく処理されたりするわけではありません。 フレームワークコードをテストと最も重要なドキュメントでカバーする必要があります。 これはすべて計画されており、可能な範囲で実現されます。