OO_Unit2_Review
1.職務構造の構造測定、戦略分析、BUG分析
1.WORK1-シングルALSエレベーター
1.構造
最初のジョブでは、MainClassに加えて、エレベーターの内側と外側のユーザーキューを表すため、QueueInとQueueOutの2つのスレッドクラスを設定しました。QueueInは実際にはエレベーター自体であり、エレベーターの動きを制御します; QueueOutは実際には入力クラスであり、入力の追加操作に使用されます。また、新しいPersonRequestQueueクラスを作成して、PersonRequestのキュークラス、一貫性のある追加、削除、その他のキューメソッド、およびいくつかのセマフォ操作を作成します。
UML
A.クラスの複雑さ
B.メソッドの複雑さ
2.戦略的分析：
この割り当ては、質問の語幹で指定されたALS戦略、つまりピギーバック戦略に厳密に従います。
3.バグ分析：
この割り当てにはバグはありません。
4.スレッドのコラボレーション：
この操作では、エレベーターキューの内側とエレベーターキューの外側に2つのスレッドがあります。外側のエレベーターは入力の処理とキューへの乗客の追加を担当し、内側のエレベーターキューはエレベーターの移動と出力を担当します。2つのスレッドの同期オブジェクトがユーザーキューです。
2.WORK2-複数のエレベーターを便乗可能
1.構造
前回のジョブと比較すると、このジョブにはコントローラークラス、つまりスケジューラクラスがあり、各ユーザーに最適なエレベーターを割り当てるために使用されます。HW1のQueueInの名前をElevatorに、QueueOutの名前をUsersStreamに変更しました。これは、マルチスレッドのロールプレイングに沿ったものです。各エレベーターには、複数のエレベーターのユーザー待機キューを共有するのではなく、独自のユーザー待機キューがあります。
UML
A.クラスの複雑さ
B.メソッドの複雑さ
2.戦略的分析：
今回は、単一のエレベーターがALS戦略を使用し、複数のエレベーターの調整は次の戦略を使用します。
ユーザーごとに既存の合計ユーザーキューをトラバースし、すべてのエレベーターをトラバースし、ALS戦略を使用してユーザーが参加した後の合計時間を計算し、トラバース前の最大整数minを設定しますmin、次にminを現在の継続時間で置き換え、同時にエレベータを記録する、というように、最終的にユーザーに最適なエレベータを取得できます。最後に、最高のエレベーターの待ち行列にユーザーを追加します。後続のプロセスは、ジョブ1のプロセスです。
3.バグ分析：
バグの概要：この操作にはバグがあります。この操作により、エレベーターの最大乗客数が制限されます。各ユーザーの最適なエレベーターを計算するときに、エレベーターが満杯の場合はスキップされるため、エレベーターが1つしかなく、エレベーターが満杯の場合、この時間に参加したユーザーは失われます。
バグ修正：スケジューラリンクのスタッフ全体の判断を削除するだけです。
4.スレッドのコラボレーション：
このジョブのスレッドには、入力ストリーム、スケジューラ、エレベーターの3つのタイプがあります。入力デバイスは、入力の処理とユーザーキューへのユーザーの追加を担当します。スケジューラは、全ユーザーキュー内のユーザーを各エレベーターの待機キューに割り当てます。エレベーターは、それぞれのユーザーのピックアップとドロップのみを担当します。入力ストリームとスケジューラの同期オブジェクトはユーザーキューです。
3.WORK3-追加可能な複数の差動ピギーバックエレベーター
1.構造：
この操作は基本的には2番目の操作の構造に従いますが、わずかな違いは、到達可能なフロア、移動時間、およびエレベーターの最大容量が変数として設定され、エレベーターを追加する方法がスケジューラクラスで設定されることです。
UML
A.クラスの複雑さ
B.メソッドの複雑さ
2.戦略的分析：
戦略の点でこの操作の最大の困難は転送分析です。解決策は次のとおりです。
各エレベータの動作範囲は、複数の閉断面の合体と見なすことができるため、シミュレーションで走行時間を計算する場合、目的地までのカットオフ時間を計算する必要はなく、目的地を含むセクションの境界まで計算する必要があります。上限または下限の場合、ALSの実行軌跡を動的にシミュレーションするだけで済みます。乗り換え待機による時間の無駄を避けるために、乗り換えが不要なすべての種類のエレベーターを最適なエレベーターと見なしています。継続時間を計算して直接戻る必要はありません。
3.バグ分析：
バグの概要：今回のバグは非常にシンプルなので、異なるエレベーターの最大負荷を区別するのを忘れていました。
バグ修正：エレベーターの最大負荷を可変に設定。
4.スレッドのコラボレーション：
スレッド構造は2番目のジョブと同じです。
2.スケーラビリティ分析
3つ目の課題では、すべての機能を区別しました。ディスパッチャーは、各エレベーターへのユーザーの割り当てを担当します。エレベーターはユーザーのピックアップと出力のみを担当し、ユーザー入力ストリームは、SOLIDのSRP原則に準拠した入力の処理とユーザーまたはエレベーターの追加を担当します。したがって、機能拡張がある場合は、カテゴリ別に追加するだけです。たとえば、2番目のジョブから3番目のジョブでは、エレベータの操作規則と入力ストリームの入力動作を変更するだけで済みます。
三。発見されたバグ戦略
今回の相互テストでは、他の人の虫は発見できませんでしたが、同級生に引き抜かれ、多数の乗客が同時に圧迫されてしまいました。エレベーターごとに乗客の負荷の違いを考えるのを忘れていたので、間違えました。
4.経験
この一連の割り当ての難しさは比較的穏やかです。最初の割り当てがマルチスレッドのアイデアに適合された後、次のいくつかの割り当てはすべて元のベースで拡張されました。そして、この操作の論理は強くなく、主な難しさはマルチスレッド部分のスケジューリングに集中していますが、幸い、このユニットで重大なスレッド安全性の問題に遭遇しなかったので、この部分はほとんど問題を引き起こしませんでした。したがって、最初の操作に多くのエネルギーを投入することに加えて、残りの2つをより短時間で完了することができます。最初のユニットの一連の操作と比較して、それは本当に複数のグレードにやさしいです、そして私はすべての後続の操作がこのようになることを望みます。