BUAA_OO_2020_Uint2_Summary
- BUAA_OO_2020_Uint2_Summary_Dir
- 設計戦略（スレッド分割とスケジューリング戦略）
- 最初の宿題
- 第二の仕事
- 第三の宿題
- 3番目のジョブアーキテクチャ設計のスケーラビリティ分析
- プログラム構造測定分析
- バグ分析
- 体験
- 設計戦略（スレッド分割とスケジューリング戦略）
1.設計戦略
最初の宿題
スレッド分割：
Myinput、Elevator、Dispatcherの3つのスレッド。
乗客のリクエストはMyinputとDispatcherの間で共有され、エレベーター内の乗客はDispatcherとElevatorの間で共有されます。
Myinputスレッド：乗客のリクエストをリクエストに解析し、Dispatcherスレッドを呼び出します。
エレベータースレッド：エレベーターの実行状態を維持し、フロアへの乗り降りの機能を完了します。また、ディスパスサースレッドを各フロアに呼び出して、実行状態の更新を待ち、乗客がエレベーターに乗り降りします。
ディスパッチャスレッド：エレベーターの運転ステータスとリクエスト実行スケジュールアルゴリズムに従って、エレベーターの運転ステータスを更新し、乗客機能を完了します。Myinputスレッドとエレベーターの実行ステータスに従ってエレベータースレッドを終了し、操作を終了して終了します。
スケジューリング戦略：
シングルポート、ライトポータブル、容量無制限の条件では、結局、すべての乗客のリクエストはエレベーターがそれ自体で応答することを要求します。私は、エレベーターの操作戦略を2つのタイプに分けました：最下階（高）の乗客（下）を探す）、その床を出発点として、上層（下層）の乗客の最上層（下層）に移動します。総走行距離が短い方の2つの戦略のいずれかを選択します。始点までの移動中にピギーバックは実行されません。始点から終点までのプロセスでは、風下の乗客または誰かが降りたいと思っている場合にのみ、ドアが開かれます。このフロアのすべての乗客が受け入れられ、最も遠い目的地が同じ方向の乗客の目的地に基づいて更新されます。最終的なパフォーマンスは優れています。
第二の仕事
スレッド分割：
Myinput、Elevator、Dispatcherの3つのスレッド。
MyInputとDispatcherは、乗客合計リクエストクラスMainRequestsを共有し、DispatcherとElevatorは、エレベーターサブリクエストクラスRequestsを共有します。
Myinputスレッド：パッセンジャーリクエストをメインリクエストクラスMainRequestsに解析し、Dispatcherスレッドを呼び出します。
エレベータースレッド：エレベーターの稼働状態を維持し、内部リクエストに基づいてエレベーターのすべての機能を完了し、ディスパスサースレッドを各フロアに呼び出してリクエストの割り当てを待機します。
ディスパッチャスレッド：エレベータの走行方向、フロア、負荷、およびリクエスト実行スケジューリングアルゴリズムに従って、リクエストを異なるエレベータに割り当てます。Myinputスレッドとエレベーターの実行ステータスに従ってエレベータースレッドを終了し、操作を終了して終了します。
スケジューリング戦略：
乗客のリクエストごとに異なるエレベータ応答距離を計算します。乗客とエレベータが同じ方向に、エレベータと目的地の間を移動する場合は、エレベータ間の現在の床の距離をとります。それ以外の場合は、エレベータの目的地+エレベータからの距離をとりますフロアは、エレベーターの目的地間の距離に基づいています。応答距離に応じて、最も近い割り当てが選択され、エレベータがアイドル状態のときに、最も遠い要求が実行されます。
スケジューリング戦略は、乗客の待機時間と総走行時間を総合的に考慮しており、最終的なパフォーマンスは優れています。
第三の宿題
スレッド分割：
Myinput、Elevator、Dispatcherの3つのスレッド。
MyInputとDispatcherは、乗客の合計リクエストクラスMainRequestsを共有し、DispatcherとElevatorは、エレベーターサブリクエストクラスRequestsと一般リクエストクラスMainRequestsを共有します。
Myinputスレッド：パッセンジャーリクエストをメインリクエストクラスMainRequestsに解析し、Dispatcherスレッドを呼び出します。
エレベータースレッド：エレベーターの稼働状態を維持し、内部リクエストに基づいてエレベーターのすべての機能を完了し、ディスパスサースレッドを各フロアに呼び出してリクエストの割り当てを待機します。
ディスパッチャスレッド：エレベータの走行方向、フロア、負荷、およびリクエスト実行スケジューリングアルゴリズムに従って、リクエストを異なるエレベータに割り当てます。Myinputスレッドとエレベーターの実行ステータスに従ってエレベータースレッドを終了し、操作を終了して終了します。
スケジューリング戦略：
乗客クラス機能を拡張し、行先フロアキャッシュと転送マークを設定して、乗客をサブリクエストキューからトータルリクエストキューに戻す機能を実現しました。残りのスケジューリング戦略は2番目の操作と同じです。2番目のジョブスケジューリング戦略を総合的に考慮しているため、今回は最終的なパフォーマンスは依然として優れています。
2番目に、3番目の運用アーキテクチャー設計のスケーラビリティ分析（SOLIDの原則）
SRP-単一責任の原則
最初のジョブにはエレベータが1つしかないため、スレッドをディスパッチする必要がないので、私のDispatcherクラスは実際にエレベータ内のスケジューリングタスクを実行し、Elevatorでそれを行うことができます。私はこの問題を2番目の課題で発見して変更を加え、最後に3番目の課題で使用しました。
Elevatorクラスは内部リクエストによる内部スケジューリングとエレベーター操作のみを担当し、Dispatcherクラスはメインリクエストキューとエレベーターステータスに基づくリクエストディスパッチのみを担当し、Myinputクラスはメインリクエストキューへの入力の解析のみを担当します。3つのタイプの職務は互いに重複しないため、SRPの原則に準拠しています。
OCPオープンおよびクローズの原則
2番目のジョブの拡張から3番目のジョブへ、Elevatorスレッドが一般要求クラスに追加され、旅客転送関数が降車関数に追加されることを除いて、5行以内のコードは追加されていません変更、その他の変更はPersonクラスの小さな拡張にすぎません。これにより、3番目のジョブも優れたパフォーマンスで完了するまでに1時間未満かかりました。
SRP原則の考慮と設計に基づいて、私のコードは、スケジューリング戦略を変更せずにOCP原則に準拠できます。
LSP交換の原則
3番目の操作では、3種類のエレベーターすべてがElevatorクラスを継承することで実装されます。オーバーライドする方法は、負荷の初期化、フロアの上下時間、到達可能なフロアの判断のみです。エレベーターモデルを作成するためにファクトリーモデルと組み合わせますLSPの原則を十分に満たすことができます。
ISPインターフェイス分離の原則
この単位ジョブではRUNNABLEインターフェイス以外のインターフェイスは使用していませんが、各クラスにはカバレッジ機能がなく、すべてのパブリックメソッドの操作はISPの原則に沿って比較的独立しています。
DIP-反転の原理に依存
共有リソースMainRequestsクラス、Requestsクラス、およびエレベータークラスのステータスチェックへのアクセスを除いて、各スレッドは他のスレッドクラスのメソッドを呼び出さず、循環依存関係を持たず、DIP原則に準拠しています。
3、プログラム構造測定分析
最初の宿題
uml类图：
複雑さの分析：
第二の仕事
uml类图：
複雑さの分析：
第三の宿題
uml类图：
複雑さの分析：
分析：
最初の操作では、Dispatcherクラスは実際にはエレベーターの内部ディスパッチャーであり、不明確な設計の配置により冗長性が生じます。3番目のジョブは基本的に2番目のジョブのアーキテクチャを継続しました。スケーラビリティと機能の分割の両方で十分でしたが、私が設計した最適化戦略を実装するために多くの複雑なアルゴリズムが導入され、全体的にコードが非常に複雑になりました改善の大きな必要性とリファクタリングの必要性もあります。
タイミング図：
4.バグ分析
私自身のバグ：
この単位ジョブは、2番目のジョブの強力な部分にのみバグがありますが、エラーを再現するのは困難です。デバッグメソッドを追加すると、スレッド操作に影響があり、エラーを再現するのがより困難になるようです。分割しました。
そして、一週間頑張ったところ、入力スレッドがロックされずに長時間動作しなくなったので、同じ問題を抱えている多くの学生に聞いたところ、まだ誰も解決していないので、必死です。
このユニットの最初から最後まで、自動評価機の構築方法をデバッグとセルフテストに使用し、自動評価機の価値もこのユニットで明らかになり、デバッグの優れたツールになりました。他の学生からも使い方を学びました
Jprofiler、Jconsole、Jstackはスレッドのステータスを監視するための効果的なデバッグ手法です。
また、バグが再現しにくいという経験から、評価機を構築する際に新たな警告が出ましたが、評価機を構築するためには、クラス内の強力なテスト評価環境をできるだけ模擬する必要があります！
ハック戦略：
このユニットの相互テスト段階で自動評価者は大きな力を発揮し、多くのバグを発見するのに役立ちました。これは、自己テスト段階で自動評価者を通過することの重要性も示しています！
5.経験
シングルスレッドからマルチスレッドまで、エレベータユニットへの最初のエントリの影響は確かに悪魔という言葉に値しますが、2番目から3番目の操作で約40分で拡張を完了するという楽しい経験もマルチスレッド学習を裏付けています途中で、コードの各ステップの転送を慎重に差し引いて、最適化アルゴリズムのいくつかの状態間の遷移について熟考し、熟考し、さらに多くの奇妙なバグに遭遇しました。不確実性原理の形而上学的な問題に感謝し、私は疲れきっていましたが、それだけの価値があります！