ユニット2のBUAA_OO_Summary

1ジョブデザイン戦略分析

1.1スケジューリング戦略

3つのジョブのスケジューリングはALSアルゴリズムに基づいていますが、それは完全にALSアルゴリズムではなく、著者は各ジョブの特性に合わせてALSアルゴリズムを改善しました。ALSアルゴリズムの主な需要の考え方のみを取り入れていると言えます。

たとえば、最初の2つの操作では、エレベータに待ち時間がなく、エレベータが空の場合、キュー内の最も早い人ではなく、エレベータに最も近い人が主な需要になります。

1.2マルチスレッドの調整と同期制御

マルチスレッドのコラボレーション

このジョブには、入力スレッドとエレベータースレッドの2つのスレッドしかなく、スケジューラをスレッドとしてではなく、静的クラスとして使用しました。この単元の3つの割り当てでは、生産者-消費者モデルを採用しています。つまり、入力は生産者であり、入力が入ると、それを取得するためにDispatcherクラスが呼び出されます。ElevatorはコンシューマーとしてDispatcherにアクセスしてリクエストを取得します。

同期制御

この割り当て用のDispatcherのシンプルな設計により、Elevatorは主にDispatcherのgetメソッドを呼び出して需要を取得し、InputはDispatcherのputメソッドを呼び出して需要を渡すため、保険のためにこれらの2つのメソッドの前に同期キーを直接配置します同期を達成するための単語。同時に、デッドロックを防ぐために、従来のwait関数とnotifyAll関数を使用しませんでしたが、エレベーターループがgetメソッドクエリを呼び出すたびに10ミリ秒スリープします。これにより、デッドロックを回避し、CPUTIMEを約1秒に制御できます。タイムアウトを回避します。

2設計原則に従ってアーキテクチャを確認する

2.1 SOLIDの原理

単一責任の原則。私の仕事のさまざまなタイプから判断すると、それはこの原則とかなり一致しています。たとえば、Elevatorクラスは人間のリクエストのみを実行し、Inputクラスは入力リクエストのみを受け取り、DispatcherクラスはElevatorとInputの間でリクエストをディスパッチするだけです。

ただし、クラス内の一部のメソッドについては、作成時に慎重な計画と考慮が行われなかったため、一部のメソッドがより複雑になり、より多くの責任があり、より複雑になりました。

開閉の原理。この単位ジョブの原則の実装は比較的貧弱です。このユニットの3つの割り当ては繰り返し実行されます。平均して、変更は毎回それほど多くありません。便宜上、メソッドは前の割り当てに基づいて直接変更されます。

これがレープ代替原理です。この割り当てでは、PersonクラスはPersonRequestクラスを継承し、それにいくつかの属性を追加します。しかし、親クラスの関連する制約を破ることなく、この原則は設計の観点から守られます。

インターフェイス分離の原則。この割り当てにはインターフェースが含まれないため、この原則については今のところ説明しません。

浸漬

それは逆転の原理に依存しています。この割り当てには抽象クラスが含まれないため、当面はこの原則については説明しません。

2.2 パフォーマンス設計

この割り当ての私の最大のパフォーマンス設計は、私のDispatcherがスレッドではないことかもしれません。私のエレベーターは、ディスパッチャークラスにアクセスするだけで、フロアに到達するかアイドル状態になるたびに需要を取得し、ローカルで最適なスケジューリング戦略を実現します。需要を積極的に割り当てるスレッドとしてDispatcherと比較すると、この方法の方が良いと思います。。

3測定分析プログラムに基づく

3.1 UMLコラボレーション図

このユニットの3つの操作は、通常、図に示すロジックを使用し、アイデアは比較的明確でシンプルです。

3.2 UML类图

最初の割り当てのUMLクラス図
2番目のジョブのUMLクラス図
3番目のジョブUMLクラス図

クラス図から、3つのジョブのアーキテクチャは基本的に同じであることがわかります。つまり、2つのスレッドElevatorとInputがリクエストを実行し、Dispatcherクラスを介して2つのスレッドにアクセスします。これは、この単位ジョブのアーキテクチャが悪くないこと、および反復的な開発であることを示しています。リファクタリングなし。3番目のジョブでは、PersonRequestクラスから継承したPersonクラスを追加して、より多くの属性を記録できるようにしています。すべての種類の部屋は、基本的に低結合の要件も満たしています。

3.3複雑さの分析

最初の宿題
第二の仕事

第三の宿題

全体として、このユニットの3つの操作は最初のユニットよりもはるかに優れており、大きな赤い領域はなく、全体的な複雑さはそれほど高くありません。ただし、非常に人気のあるメソッドもいくつかあり、メソッドのこの部分を記述する際には複雑すぎる可能性があります。機能を実現するために、プログラム全体の構造を明確にするために忘れてしまいます。今後、さらに改善に注意を払う必要があります。

4自分のバグを分析する

このユニットの割り当てでは、最初のユニットのレッスンを学び、コードを評価するための評価マシンを作成しました。しかし、まだバグがありました。私を傷つけたのは、評価マシンの最初のバージョンに最初の操作のTmax時間の比較が含まれていなかったため、場合によってはTmaxよりも大きなバグが発生したことです。一方で、私は不注意だったからです。他方、評価マシンを書いた後でコードを再チェックしないのは幸運でしたが、実際にはそうではありませんでした。

このバグは、最初の課題のオープンベータで発生しました。このバグの理由は、場合によってはTmaxを超えて判断がタイムアウトになることです。後でバグが修正されたときに、Elevatorクラスに欠けているコードしかなかったことがわかりました。これにより、エレベーターが要件の更新に失敗し、合計時間が長くなる場合がありました。

5他の人のバグを発見するための戦略

このユニットの相互テスト中、私は主に評価機を通して他の人のコードを評価します。

最初の相互テストでは、人のCPU時間タイムアウトのバグが見つかりました。

2番目の相互テストでバグは見つかりませんでした。

3番目の相互テストでは、同じ部屋に8人がいましたが、合計5 人がハッキングに成功しました。実際、合計6 人のバグがローカルで見つかりましたが、6人目のバグは2回提出され、成功しませんでした。強いテスト結果から判断すると、今回はA家になりましたが、まだ多くのバグが見つかり、多くの学生のプログラムに多少の問題があることを示しています。6人のうち1人は特定の状況にあり、まだ完了していない要求が1つあります。これは、スケジューリング戦略の抜け穴になるはずです。残りの5人はすべて200秒以上実行しています。具体的な理由はデッドロックの問題であるか、特定の状況の最適化にはスケジューリング戦略があまり適していません。

このユニットは、最初のユニット評価マシンよりも書くのが難しく、主に結果の正しさを判断し、各状況の論理的正しさを証明する必要があります。

6経験

このユニットはマルチスレッドの知識を学び、いくつかの興味深いエレベーター操作を完了しました。一般に、このユニットの利点はかなり多く、デッドロックなどの関連知識を理解し、デッドロックを回避してスレッドの安全性を確保する方法を学びます。同時に、プログラムの全体的な構造をより科学的で明確にするために、SOILDの設計原則を学びました。プロデューサーとコンシューマー、ワーカースレッドモードなどについても学びました。

このユニットは、評価マシンを作成する際のジョブのコードにも非常に役立つことがわかりました。評価マシンを作成するときは、どのような状況が間違っていると判断されるかを考慮する必要があるため、各操作のピットの概要を簡単にまとめました。これらの落とし穴がコード比較で回避されているかどうかを確認できます。これは、各ジョブの正確性に非常に役立ちます。

同時に、このユニットのパフォーマンスの最適化も大きな課題であり、より柔軟なスケジューリング戦略により、このユニットは多くの資料をチェックし、各ジョブを作成するときに多くの知識を学びました。