ディレクトリ
2019 OO第四コースの概要における航空宇宙の北京大学
、UML操作の概要
1.1第十三の仕事
この操作は、単純なパーサUMLクラス図、UmlElementセットからの各要素と要素間の関係を同定し、実行するために、対応するクエリ命令を完了する必要があります。
この割り当ての難しさは、正確に各用語の意味を理解することであるUMLは、継承と実装表現を含むファイルを、エクスポート表しparentIdように意味と。
簡単問い合わせのすべての種類を達成することができる隣接リスト構造に似アーキテクチャは、第13の動作は以下の3つのステップに分けることができます。
- UmlElementは、各サブクラスことを理解し、その意味は、データ構造がどのように対応する各クエリは理解し、属性
- 対応するマップ初期化、受信パラメータを読み出す（インタフェースクラスに、例えばし、ピアに関連付けられたクラスのクラス、クラスのプロパティ、等）
- 各クエリに対応するアルゴリズムを設計および実装
ジョブがモードを取得する再帰的なセット数を持っているので、多くの仕事再帰関数があります。
1.2第14ジョブ
作品はチェックして追加し、新しいマップのための2つのプランは、比較的単純な、そして前と基本的に同じです。フォーカス機能を回避するためにInteraction、それぞれの異なるクラスの図の単離、これらのクラスの唯一のメインクラスのインスタンスを考慮した対応する関数を呼び出します。
3つのチェックがデザインされたため、次のように妥当性チェックは、より複雑です。
- これは、すべてのクラスおよび属性の次の検出ドメイン用に同じ名前のクラスに簡単です：繰り返しという名前のためのクラスの最後の私はクラスのこの2人の関連するクラス名は一般的に終了さを理解して、名前メンバ変数は、別のクラスのクラス名に対応し、他のメンバーは、同じname属性にすることはできません。
- 循環のために継承することができない。対象を定義する最初-有向グラフを、ノードがインターフェースとクラスは、継承エッジがある（非界面関係）、研究の問題がされている図のリングで検出される場合、（自己ループを含みます）私はリングを検出するために、通常の尖塔アルゴリズム（Tarjanのアルゴリズム）を使用します。有向グラフのために、強連結成分の一つのグループは、円形継承オブジェクトであるため。また、アルゴリズムは、余分な決意に、ループバックTarjanを検出できないことに注意してください。
- 継承のために複製することができない。問題が検討され、ノードがインターフェースとクラスであり、研究は有向グラフであり、継承サイド関係を実現されるグラフ内の任意の2つのノードについて、接続されていない2つの異なるパスが存在する場合、このようなノード、ノードべき出力源。ポイント隣接する頂点を通過するときに、検索処理は、隣接ポイントをアクセスされた場合、検索を行うために、ルートノード（ノード0度）の背面図にターンを回すことによって、本明細書で反転を使用することができます出力されるカラーポイント、ポイントおよびそのすべての子孫ノードまでの2つの経路が存在します。これは、すべての点順次マップ全体を検索せずに、レガシーノードのすべてを見つけるために検索を繰り返すことになります。
OOの進化を理解するための2つ、4つのセルアーキテクチャおよび方法
第一発現ユニット導出2.1
このユニットは、オブジェクト指向プログラミング、私はプログラム抽象的アイデアで様々なエンティティを持っていた最初の時間を書き込むための最初の公式です。私が設計し、自然言語共通の関係で説明する手順を実行することができるようになりました。例えば導出、計算、および非常に複雑。私は文法的になってしまった関係をベースに、我々はより多くの設計（最終私のプログラムはまだ簡単ガイドブックよりも多くをサポートすることができます）のためのスペースを確保するために可能な限り完全な導出手順を設計し、そして。
オブジェクト指向の知識を習得することに加えて、私のような、Javaライブラリとメカニズムのいくつかのより良い理解を持ってBigInterger、これらのパッケージの使用の過程でも、オブジェクト指向設計の知識とこれらの開発を学ぶことができる、などのクラスと正規表現のクラス、アイデア-例えば、どのように使いやすいとされ、それを設計する方法をどのようなメソッド、プロパティ、あるべきクラスをクランチに無数のサポートを設計します。実際には、我々は多項式導出システムを行うには、これらのライブラリは、多くのアイデアのようなものです。
总而言之，第一次作业正式为我打开了面向对象的大门，我开始能够不以过程式的思想设计程序了，还接触到工厂模式等等更系统化的设计方法，更让我认识到设计的重要性。
2.2 第二单元 多线程的电梯设计
本单元是第一次编写多线程程序。从本单元开始我在设计时会着重考虑建模的可扩展性和可延拓性。在第一次作业中我就考虑了后续可能出现的需求。虽然课程组的要求往往超乎想象，导致我不能完全一以贯之的使用一套代码来适应越来越多的需求，但是至少这种思路的出发点是好的。我的代码现在看来已经尽可能地符合开闭原则了。
为什么要编写多线程程序，在我看来，有以下几个原因：
- 提高资源利用率：这是毋庸置疑的，改变操作顺序可以减少CPU的空闲的时间，避免无意义的等待
- 简化程序设计：将具有不同职责和时序要求的工作抽象为线程可以大大简化程序难度，方便程序实现
- 提高程序响应速度： 避免一个程序一直处理其他消息而不开启监听，使服务器等进程响应更快
同时，本次作业还让我理解了一些基本的设计，S.O.L.I.D.是指SRP（单一责任原则）、OCP（开放封闭原则）、LSP（里氏替换原则）、ISP（接口分离原则）和DIP（依赖倒置原则）。 第三次电梯作业中我的调度器履行了过多职责，从捎带到换乘，再到电梯选择和停机，这些工作全部在一个类里完成，不太符合SRP原则——应当分解调度器类或者让电梯承担更多的责任。同时我各个模块之间的依赖非常严重，高层模块和底层模块互相依赖导致代码改动的风险很高，很不符合DIP原则。
2.3 第三单元 JML建模语言
第三单元让我们第一次接触到了程序规格的概念。这对理解程序的模块性和规范性大有裨益。总的来说三次作业就是一个图结构慢慢演变的过程，其中包括图的属性和查询模式的演变。
仕事は、私が最も「OO」の場所がマップの抽象化だと思います。それは各小パスで異なる大きな地下鉄システムの対象であるかどうか、要件やクエリが必要、彼らは本質的違いをグラフ化するだけで何のサイズ、構造、トポロジおよび特定の意味ではありません。図抽象クラスと特定のクエリを実行すると実践を加速するために様々なモジュールが含まれて非常に良いの内部です。仕事は私が深く抽象化と再利用を理解しています。
もちろん、主な仕事は、JMLモデリング言語も私の目を開きました。これは、将来の発展のためにチームで便利 - 通信システムの簡単な、統一的な説明を通じて、人々の間で、多くの作業が効率を向上させることができれば、コードを読み取るために、不要な排除、およびので、あいまいな解釈プロセス。（十分なJMLのような現実の生活の中で人々は、そう単純であれば）
第4のセルUML 2.4
OOレベルで支援する第四部Iは、プログラム自体を書くつもりはないと思われます。割り当てよりUMLやデザインなどの理解のために - 実際のコードでと深さと支障がある限りUMLの正しい理解は非常に良い実装であるとして、ありません。使用のUMLの間のコードと、私が最もエキサイティングだと思うのコード内のコード、ロジックやタイミング関係の複雑さを説明します。それは要約し、洗練されたクラス、継承、実装、これに関連して、オブジェクト指向プログラミングの要素と、明確に3つの図との関係を表現する：実際には、UMLは、非常に重要なツールの意味合いを理解するのに役立つように設計され、ガイドデザインのアイデアです。
進化と実践を理解するには、3つのまたは4つのユニットテスト
ジョブの3.1最初のラウンド
精度を向上させる、ジョブバグの現在のラウンドを低減するために、私は、手動と自動の二つの角度からのデバッグ。シンプルな分類境界テストのためのマニュアルの主要部分。分類試験は、設計する必要が分類木の入力をツリーが省略されている等の入力の形態、の各項目の有無分岐点を含みます。境界条件および例えば考えられる極端な困難な状況、空の入力、\のVシンボル、ゼロ次のアイテムなどのための主要な試験。
自動テスト自動化Pythonの正規表現ビルダーの主な用途、サブプロセスおよび科学命令関数算出パッケージ、深さ及び長さは、強度試験することができるように、自動テストポイントをカスタマイズすることができます。ランダムに生成されたテストポイントの品質は高くないかもしれないが、その数は、プログラムの信頼性を向上させるのに十分な大きさであるが。
これは、テストモードのシンプルなデザイン、システムはまた、彼のプログラムの最初のテストで自分のアイデアに基づいて、私の仕事です。
3.2第二ラウンドの求人
通常の手続きよりもテストより複雑かつ困難なマルチスレッド、バグが見つかりました。そして、同様に除外しました。仕事は、私はバグを見つけるために、テストポイントの数が多いと繰り返しテストを多数使用しています。私は喜び（ではない）を持っていた仕事は、スレッドのバグを発見したタフな計測分析を通じて、私はそのバグを見つけました：エレベーターは（例えば、1-2階）を実行して、エレベーターはどこ（のように自分の床を更新されていませんスレッド切り替えが発生した場合に1にもF）、次に、命令シーケンス内のスケジューラ1-2建物命令は1-2の後に建物内のエレベータを実行した後、得られ行うので、欠落していること追加誤解ARRIVE-2出力二回。
私は深く、マルチスレッドの重要性が容易で、プログラミングの設計原理ではないと感じました。スレッド間、私は真剣に、様々なプログラミングテンプレートを満たした場合、それは同様の問題が表示されなくなり、古いデータに基づき可能なアクションで行われるべきではありません。検出することが極めて困難とマルチスレッドの同期の問題は、プログラミング過程で、解決することも極めて困難である古いプログラムDEBUGに戻ってはいけません（ない最初の公害対策後）、最初から設計されたプログラム、私たちは、真剣かつ事前発生チェックイン、その後-ACT、リードモディファイライトや他のテンプレートの原理に従って必要のあるスレッドの間に明確な関係の実装を整理、あまりエラーが発生しやすい優れた信頼性の高いソースアーキテクチャを設計します。
ジョブの3.3第三ラウンド
私は、単純なJMLに基づくアイデアは、最もシンプルなロジック（アルゴリズムのみ）、コースに必要なグループを過小評価の誤りを達成「コンプライアンス遵守、すなわち米国を話す参照」で始まりました。TLEの問題を強いポイントがたくさん登場測定する場合は、以下の主な理由を反映します：
- 背景話題の現実を十分に認識していない：現実には、ほとんどのクエリは、マルチチェックシステム構造の変化が少ないが、すべてのクエリは、コンピュータ科学の学生の質（特に概念はすでに、などのキャッシュを学んだ）の下に再計算されています
- データ構造と組み合わせる重篤なコンテンツん：データ構造は非常に重要な番組内容に依存アルゴリズムであり、やみくもに物事を行うブルート配列初心者を使用して、プログラムがタスクを完了するために、だけでなく、タスクを達成するだけでなく、
主題に基づくストレステストを実施するために必要であれば、私は深い教訓を私に左の問題を見つけるでしょう。
ジョブの3.4第4ラウンド
UMLの主な問題は、対象の要件の理解にあり、特別な事情を考慮してください。この動作は、すべての要素が親として統一されているUmlElementマップは、キーセットのアクセスの要素になりそうではありません-多くの隠された危険がNULLポインタであるように、これは実際には設計されています。リスクは非常にシンプルですが、実際には非常に微妙であるように思われる、と私は私の周りに学生で登場しています。私は、コンテンツを使用して自由に感じるべきではない決してこのウェイクアップコールは、前述したように、NULLポインタが表示されることがありますmap.get()ように。
ここで白新余市の人がテストに多くの利便性を提供メトロノームの学生に感謝したいと思います。
第四に、カリキュラムの収穫
- デザインレベル：私は、もはや私たちの脳をラッキングコードを書くようになったですが、信頼性の高い効率的なコードのアーキテクチャを設計する方法について真剣に考えるべきです。まず、開発者のための更なる発展のために道を開くために使用することは非常に重要です。私はまた、抽象の種類よりスケーラブルとより、良いものを抽象的、抽象的であるものを学びました。
- アルゴリズムレベル：このコースは私だけ実装レベルとイデオロギーのレベルを認識して、実際には、その擬似コードアルゴリズムを知っている前に、真剣に多くのことを達成するために、多くの違いがあります。OOは間違いなく自分の能力を向上させました。
- コードレベル：私は問題を知っているし、チームの共同作業をする際のソリューションは、遭遇する必要があります。私はコードが彼自身の一見のために書かれたかわからない - 、スタイルのコードコードの仕様を、図のコードは、チームのすべてのレベルでの通信は非常に重要です。それ以来、コード、設計手法やツールの両方は、私は、モジュラーデザインを持っており、他の人とうまく通信します。
- アプリケーションレベル：良いコードがエラーなしで堅牢でなければなりません。私はテストの重要性を認識するだけでなく、もちろん周りの学生が及び試験方法とポイントの多くのことを学びました。
改善のための5つの提案
- 他の古典的なシリーズO（CO、OS）のコンピュータ科学科は、機能を持っています - ステップバイステップで、新たな高みを拡大縮小。難しさと深さ、毎週ジョブは、前の週よりもはるかに高くする必要があります。後者の一部の内容は、より難しいかもしれないかどうか、十分なリフトやや突然の終わりを得ることが困難と同じ古典的なコースO OOとして、
- クラスのテストより完全かつ体系的かどうか。あまりにも開いている質問の学生が、時にはモードに答えて間違った方向を行い、応答がないとフィードバックも、学生はタイムリーな考えを修正しないようにすることができます。
- すべてのジョブの可能な将来の拡張モードでは、学生を思い出させることができます。が、一般的に多くの学生は、スケーラブルなコードを書く能力は重要であるが、問題は発散方向することができます。フォロー互換性のデザインの多くを作るために学生を導くことがあり、学生に仕事の次の方向を教えてくれますが、コースの要件の方向はなく、前に考慮していませんでしたしない学生は少ないリファクタリングを書くつもりが、そうではなく、何度も何度も書き換え。