BUAA_OO（2020）_Unit2_Summary

1.マルチスレッドコラボレーションおよび同期制御の設計戦略

最初のジョブアーキテクチャの十分に強力な設計と十分なインターフェイスが残っているため、次の2つのジョブは基本的に小さな調整と最適化されたスケジューリング戦略にすぎないため、次の3つのジョブは区別されず、3つのジョブスレッドがスレッド間で使用されます非同期通信の設計戦略の利点は、共有リソースがなく、ロックと同期制御の問題が回避されることです。この小規模なシミュレーション問題では、データのコピーによる時間とスペースの浪費も無視できます。主な難点は、データに不整合があります。エレベーターのステータス変更->スケジューラーがステータス変更メッセージを受信する->スケジューラーがスケジューリングを実行する->エレベーターが調整命令を受信することを考慮してください。このようなプロセスは、非ブロッキング非同期通信設計のアイデアを使用しているため、スレッドの実行順序を制御できません。想定とは逆に、ステータス変更メッセージを送信した後もエレベータは稼働し続けます。スケジューラは、スケジューリング時に最新のデータがあることを保証できません。また、エレベータが最後にディスパッチされたコマンドを処理すると、状態が再び変更される場合があります。したがって、ディスパッチャ、特にエレベーターは、受信したメッセージを処理するときに不信の設計概念を採用し、まずメッセージが現在の状況に適しているかどうかを検証し、さまざまな状況に対応してこれらの問題を解決します。問題は、コントローラースレッドがエレベータースレッドでうまく機能することです。

次に、機能設計とパフォーマンス設計のバランス、スケーラビリティー、および設計原理の3番目の操作の分析

a）機能設計とパフォーマンス設計のバランス

スレッドの安全性を確保するために、スレッド間でメッセージキュー、非同期通信、および共有変数のモードが使用されます。強い分離により、スケジューラーはエレベーターの状況をリアルタイムで理解できなくなります。スケジューラーは、命令を通じてエレベーターにコマンドを送信します。命令にはある程度のフォールトトレランスが必要です。これは、スケジューリングのパフォーマンスを制限します。より極端なスケジューリングの拡張は達成できず、一部のトリックはそれを実行できません。つまり、機能設計のためにパフォーマンス設計の一部が犠牲になります。しかし、同時に、戦略戦略を使用してスケジューラを分割し、階層型スケジューリングモードを採用することにより、スケジューリング戦略は優れたスケーラビリティを持つことが保証され、スケジューリング戦略の改善を通じて、最終的なパフォーマンススコアは悪くありません。2回の反復後、最初に残されたインターフェースが基本的に使用され、元のインターフェースは拡張の余地があまりありませんが、要求クラス、スケジューリングクラス、およびノー​​ドクラスが抽象化され、簡単に実行できます。コードを変更する代わりにコードを追加して、機能を拡張します。

b）SOLID分析

         i。SRPの原則

1. Controllerクラスの責任は基本的に1つです。これは、状態変化の監視、要求の記録、CenterSchedulerクラスの呼び出しを行い、スケジューリング結果を取得して送信します。ただし、プログラムの終了を検出するだけでは少し複雑です。連携を完了するには、一部をElevatorクラスに割り当てることを検討してください。
2. リクエストの実装の責任はすべて単一であり、情報または指示の伝達に対してのみ責任があります
3. Trayクラスの責任は特異であり、メッセージの転送のみを担当します
4. Elevatorクラスの責任は複雑です。これは、エレベーターの状態を単独で維持し、コントローラーからのコマンドを受け取って完了し、エレベーターの動きを認識し、ドアを開閉し、人の出入りを行い、状態をコントローラーに報告する必要があるかどうかを確認する必要があることに注意してください。このクラス一部のメソッドはわずかに肥大化しており、SRPの原則に違反しています。実際、2番目のジョブから3番目のジョブの反復では、Elevatorクラスがリファクタリングされ、いくつかの関数が抽出されて新しいクラスが形成されています。そして、組み合わせモードを使用してコラボレーションしますが、レイジーは最終的にそれを行わなかったため、後続の反復がある場合は、Elevatorクラスの分割を検討する必要があります
5. Passengerクラスの責任は特異であり、パスに従ってターゲットフロアに到達することに対してのみ責任があります。
6. 中流階級の責任は特異であり、それは最良の経路を計算することに対してのみ責任があります
7. MainClassの責任は特異であり、入力の処理のみを担当します
8. CenterSchedulerのサブクラスの責任は単数であり、各スケジューラのスケジュール順序の制御のみを担当します。
9. スケジューラのサブクラスの責任は単数であり、エレベーターとフロアの状態に応じて指示を与えることのみに責任があります
10. 主に情報を保存するいくつかのカテゴリもあり、これらもSRPの原則に沿っています

         ii。OCPの原則

Strategyモードを使用すると、CenterSchedulerとSchedulerの2つのレベルの抽象クラスが設定されます。サブクラスでスケジューリング戦略を継承および実装することにより、スケジューラはOCPの原則に準拠し、新しいサブクラスを作成することで戦略を簡単に拡張できます。MyNode、RimNode、CenterNodeインターフェイスを確立し、Trayクラスでメッセージを転送するためのサービスをノードに提供します。これにより、新しいスレッドの追加はOCPの原則に沿ったものとなり、メッセージネットワークにアクセスするためにRimNode / CenterNodeインターフェイスを実装するだけで済みます。

       iii。LSPの原則

サブクラスは、LSPの原則に従って、親クラスの機能を変更していません

       iv。ISPの原則

インターフェースの内容は、ISPの原則に沿って完全に固有です

       v。DIPの原則

コントローラーは、DIP原則に準拠する具体的な実装ではなく、CenterScheduler抽象クラスに依存します。ただし、PriorityCenterSchedulerのエレベータ優先度情報を使用して乗客の経路をよりインテリジェントに設計するために、コントローラーはPriorityCenterSchedulerを個別に認識して特別に処理し、ある程度違反しますDIPの原則。CenterSchedulerは、DIPの原則に沿って、Scheduler抽象クラスに完全に依存しています。

3.メトリックに基づくプログラム構造、クラス図、コラボレーション図の分析

 

 

メソッドの複雑さの測定の観点から見ると、全体的な複雑さはそれほど高くなく、平均値は前のジョブと比較して大幅に改善されています。

 

 

クラスの複雑さの測定の観点から見ると、複雑な責任を持つElevatorクラスとControllerクラスの合計の複雑さは高くなります。内部メソッドの分割により、OCavgは問題ありません。Middleクラスの複雑さは、テーブルを初期化するためのコードを含む5つのレイヤーになる場合があります。円形の総当たりの検索パスは関連しており、無視できます。ElevatorクラスとControllerクラスを分割する責任は、今後検討する必要があります。

 

クラス図から、継承と実装はあまり使用されておらず、レベルは比較的浅いです。スレッド間通信では、メッセージパッシングが採用され、中間転送層の構造が追加されています。したがって、MyNodeインターフェースは、受信メソッドをサポートするために確立されており、トレイです。クラス管理、およびRimNodeおよびCenterNodeインターフェース。前者はregisterToメソッドをサポートし、それ自体をCenterNodeに登録して登録応答を受け入れ、後者はregisterメソッドをサポートし、登録要求を受け入れてそれらを処理します。展開されていない一連のリクエストクラスがリクエストパッケージで定義されており、特定のコンテンツがコラボレーション図によく反映されています。

CetnerScheduler抽象クラスは、スケジュールの順序を担当します。4つの実装クラスがあります。最終的に、優先度は実際にはPriorityCenterSchedulerと呼ばれます。使用されるアルゴリズムは、エレベータタイプの動的優先度を計算することです。カテゴリの優先順位は、負荷のバランスをとることです。カテゴリの優先順位が高く、空のスペースが多いエレベーターが最初に発送されます。

Schedulere抽象クラスは、特定のスケジューリングを担当します。2つの実装クラスがあり、実際の呼び出しは、LOOKアルゴリズムを使用して実装されるLookSchedulerです。

このレベルの抽象化により、コントローラーはCenterSchedulerに依存し、CenterSchedulerはスケジューラに依存するため、スケジューリング戦略のスケーラビリティが確保されます。

 

 

もう一度コラボレーション図を見ると、プログラムはいくつかのエレベータースレッド、1つのコントローラースレッド、1つのメインスレッド、および1つのトレイスレッドで構成されています。

メインスレッドは、入力を処理し、非同期通信によってコントローラーに通知します。コントローラーは、各乗客のフロアのテーブルを維持し、エレベーターステータステーブルを記録します。これは、メッセージが受信されるたびに処理され、乗客クラスのレコードは同期呼び出しで更新されます。次のターゲットレイヤー情報とPassengerクラスは、実際に独自の中間ターゲットレイヤーを取得し、Middlerクラスによって提供されるアルゴリズムを呼び出して更新します。その後、コントローラーは独自のコンポーネントCenterSchedulerを使用して、同期呼び出しでスケジューリング結果を取得し、必要に応じて非同期通信を行います。各エレベーターに通知する方法。Elevatorクラスは、コントローラーコマンドを適切に処理し、操作を自動的に完了できます。

第四に、自分のプログラムのバグを分析する

強力なテストと相互テストにはバグはありません。開発プロセス中に発生したいくつかのバグは注目に値します。たとえば、最初のジョブの設計プロセスでは、すべてのスレッドがスタックし、ウェイクアップできないデッドロックが発生しました。理由エレベータは、ディスパッチャをウェイクアップして担当者を正しく処理するための、担当者の入室要求すべてに応答する必要があります。ただし、非同期通信の設計により、担当者の入室要求は、エレベーターがドアを閉めた後、エレベータによって処理される場合があります。現時点では拒否されます。この要求は、ドアを開くと判断するための条件が、要求を処理する前に要求を処理する前に書き込まれたため、要求が拒否されたときに応答メカニズムをトリガーできず、要員が失われ、後続の要員が到着しないと、すべてのスレッドができなくなった目覚めた。マルチスレッドプログラミングでは、スレッドの実行状態を十分に考慮する必要があり、非同期通信モードを採用しても、リクエストの送信条件を慎重に判断する必要があります。

5番目に、他のプログラムのバグを見つけるために自分で採用した戦略を分析する

機能テストに自動評価とランダムデータを使用して、いくつかの極端なデータが追加されました。ソースコードレベルからのバグ検索はありません。3つの相互テストで合計2つのバグが見つかりました。

6.経験

スレッド間コラボレーションのセキュリティ問題は、マルチスレッドプログラミングにとって大きな問題です。スレッド間の結合の度合いが低いほど、スレッドセーフなプログラムを簡単に記述できます。他のスレッド管理クラスのメソッドを呼び出さないことが最善です。可変リソースは、このジョブの設計のように可変リソースを共有していなくても、スレッドの安全性の問題を回避するために低結合を完全に保証できます。コマンドモードは、呼び出し元を呼び出し先から分離し、カップリングを減らすのに効果があります。ストラテジーモードはアルゴリズムの抽象化に非常に効果的であり、置き換えが簡単なアルゴリズムライブラリを提供できるため、アルゴリズムを自由に拡張および調整する機会が得られます。プログラミングプロセス中に優れたデザインモードを使用する利点と、開発速度と効果の両方を完全に実現しましたブラインドライティングを始めるよりもはるかに優れています。この単元を勉強した後、並行プログラミングで対処する必要がある問題をある程度理解しました。また、いくつかの関連する処理方法を試し、必要に応じていくつかの関連する本を読むように促され、多くを得ることができました。