最初の操作は異なるに基づいてelementUML仕様で設計アーキテクチャ所属。継承UmlInteractionインタフェースのMyUmlInteractionクラスは、メインの対話層です。それぞれは、そのコンストラクタで接合elementが判定され、分析ElementTypeによればparentId、それが格納され、他の特性を解析される場所を決定します。
異なるためにElementType、私は3つのカテゴリに分類されます。
最初のカテゴリは、Javaクラスの特定の代表で、他の要素であるelementような、UmlClass、UmlOperation、UmlInterface、私は彼らのために構築するなど、それは彼自身の財産の一部を持っている、UMLで自分のサブクラスを持ってMyClass、MyOperation、MyInterface3格納するクラス、element独自の基本的な情報およびその他の属性UMLダイアグラム、使用とHashMap店舗IDと特定のクラスの名前との間のマッピングを。とおり記載UmlClassするUmlOperation間の提携、MyClassクラスは、対応するすべて格納する必要がMyOperationクラスを、関係に従って継承、MyClassクラスとMyInterfaceクラス情報は、親クラスとそこに対応する関連情報です。
第二のタイプは、ElementTypeそのような形状のUmlParameter、 UmlAttribute的elementその対応の存在下で直接保存され、基本的な属性なし他の特性に加えて、親UMLそのアーキテクチャに見出すことができるMy***ように、クラスUmlAttributeに対応するあるMyClassクラスが。
第三のカテゴリーは、継承関係を表している、との関係を実現するelementような、UmlInterfaceRealization、、 UmlAssociation、UmlGeneralizationこのためelement、私は最初にすべてがされる、対応する配列に格納しelement、対応するクラスに格納され、その後、別の呼び出しすべての関係の分析の方法は、結果が異なるクラスに格納されます。
でMyUmlInteraction対話層は、この方法は、各ジョブを達成するために必要な、長い応じを有するHashMap入力見つけるためにマッピングclassnameに対応しclass、その後呼び出しMyClass対応するクラスのメソッドは、エラーまたは他の例外情報の結果を返します。親クラスに関連する処理のための方法は、最初に呼び出しClass、その方法を、次に呼び出すparentClass場合、対応するメソッドをparentClass再帰的に呼び出す親クラスがあるparentClass親クラスのメソッドを、再帰呼び出しなど、およびステップを情報バック出力します。
ジョブアーキテクチャ：
2、UML第ジョブ - クラス図、状態図、シーケンス図（フロイドのアルゴリズムが可能です？）
最初のジョブに基づいて、第2の動作は、シーケンス図と状態図の処理の増加は、それがより多くの種類の追加を意味しelement、我々はより包括的な分析を行う必要があります。
-私は2番目の仕事インタラクティブクラス完了するために、継承されたメソッドを使用してMyUmlGeneralInteraction実装クラスを。具体的な方法は、直接ジョブを取るされているMyUmlInteraction実装するクラスUmlClassModelInteraction、親クラスとして使用されるインタフェースをMyUmlGeneralInteraction実装するクラスUmlGeneralInteractionのインターフェースを継承MyUmlInteractionクラス図及び対応する方法のすべての要素（ように、サブクラスとしてクラスUmlClassModelInteractionの進む方法は、インタフェースで定義されました）親クラスに滞在し、第二の方法のために達成するための新たな雇用のサブクラスに配置されています。実装にMyUmlGeneralInteractionクラスコンストラクタは、最初の使用時super()コール親クラスのコンストラクタを、クラス図を再び横断通過サブクラスにおける主要な要素の分析を完了するためにelements解析と状態図の配列を、シーケンス図は、関連するelementと行います適切なストレージ。
仕事は、私はクラスに関連する3つの新しい状態図を設定しMyStateMachine、MyRegionそしてMyTransition（実際には、限りMyStateMachineクラスはなく、最初の解析では、完全な機能を実現することができるようになります、それが判明したいくつかのアーキテクチャelement、他の性質を持って書くのが面倒になった後）に変更し、クラスに関連付けられたシーケンス図MyInteraction。ステートマシン前記MyStateMachine記憶MyRegionクラス、MyRegion各格納されたクラスstate、transition情報、及び、すべての保持stateして遷移行列をfloyd計算アルゴリズムの後継、状態、MyInteractionクラスマップ情報格納された配列を含むlifelineだけでなく、個々のmessage、状態図の動作とシーケンス図ため実装が簡単、単純化された操作を行うためのコンテンツ。
副業に比べて最初の仕事にも参加し、私も達成するためにフロイドのアルゴリズムのこの部分を使用し、モデルの妥当性チェックを......
主でどのUML002ルール、classそれぞれの内部実装は、classストアがのルールに適合していない返し、すべてが通過するすべて取得すれば、情報を空、UML002チェックエラー例外がトリガされません。attributeNamehashsetclasshashsethashset
UML008とUML009 2つの例外のために、それがであるclassとinterface行動の間、および継承を実装することを検討する必要があります。私は、別建てMyClassGraphのカテゴリは、すべての保存UmlClassOrInterface、およびすべてUmlGeneralizationでUmlInterfaceRealization、そして二つの記憶例外情報がありますhashset。クラスAがクラスBを継承する場合、クラスAは、インタフェースBを実装し、AからBへのパスがそれぞれ、存在するとみなされます。確立のための基礎として行列（nは番号）。n*ngraphUmlClassOrInterface
この行列を初期化するとき、すべてのせgraph[i][j] == INF、iは、クラスjに添字を示すマップは、添え字マッピング・クラス・パス（または、実装の継承関係が存在していない）が存在します。
その後、すべての情報は、マトリックスに記入します。クラスはインターフェイスA、Bを実装、またはAまたはBは、インターフェースインターフェースA B継承されたインタフェースを継承する場合、対応するA 及びBは、対応する充填の位置、即ち、BにAが存在するパスを表します。方向Aに対応する場合、ことに留意すべきであるとBが対応する充填位置は、ときに1を有し、それは繰り返し連続し、情報のニーズは（インターフェース）Aが繰り返さ記憶継承異常に格納されていることを示しますでので、特別なキューに格納されている間、すべてのクラスは、（インターフェース）から継承又はも重複連続して達成され、必要である操作の終了後に格納されているクラス（インタフェース）の存在にすべてのパスについて繰り返しストレージ異常を受け継いで。UmlGeneralizationUmlInterfaceRealizationindexiindexjgraph[indexi][indexj]=1indexiindexjgraph[indexi][indexj]hashsetfloydhashset
その後、再びフロイドのアルゴリズムによって、この行列を実行します。それが決定された( graph[i][j] > graph[i][k] + graph[k][j] )パスを更新しつつ、また、我々は、特別な決意を含める必要があります。即ち（ graph[i][j] < INF && graph[i][k] + graph[k][j]) < INF ）iを1からKまで、そしてkにjから、この条件は、2つの（iはiからjまでのクラスのインデックスjに対応するクラスに対応するパスのインデックスからのパスでの存在の意味であり、パス）、iがストレージクラスに格納されたインデックスに対応する継承異常HashSetの、特別なキューを繰り返す必要があります。
フロイドのアルゴリズムが完了した後、graphマトリックスは、到達可能性（インターフェース）クラスの任意の2つの間の行列となります。対角線上の要素の値が0でない場合は、この時点では、それはまた、循環相次いで登場し、自分のクラスのクラスへのパスがあることを意味します。再び対角線上のすべての要素を横断し、ストレージ・サイクルにINFクラスに対応するインデックス要素も完成HashSetの例外クラス、継承しませんUML009ルールチェックを。
完了するまでに1つの最後のステップがありますUML008ルールチェックは、繰り返し相続異常に加えて、店に参加しているhashset（これらのクラスは、そのキューの中の特別な）クラスの外に、我々はまた、特別なキューを反復処理する必要がある、キューが特別になります各クラスは、インデックスに対応する(indexj)場合は、行上のすべての要素が、再びそれを行うために決定されgraph[i][indexj]<INF、下付き文字Iは、に基づいて、一つのパス、indexjクラスに対応する対応するクラスのインデックスを示し、すべてが又は達成から継承しますクラス（インターフェース）が承継が繰り返され、私たちも私も重複のHashSetに追加されたストレージクラスに対応するインデックスに必要な異常を継承し、。
したがって、記憶異常に格納されている全ての繰り返し連続に基づいて異常チェックUML008ルールhashsetの例外クラスが継承記憶ループに記憶されたルールに基づいてUML009、異常チェックhashsetです。MyClassGraphクラスは、これらの2 HashSetのために返す必要がありMyUmlGeneralInteraction、クラス、完了することが2つのルールの検出を。
ジョブアーキテクチャ：
二、四单元中架构设计及OO理解方法的演进
第一单元多项式求导作业是刚刚接触OO所写的第一个系列作业，第一、二次作业可以说就是按照面向过程的思路来写的，采用逐项匹配的思路，针对每一项构建正则表达式分别求导，这个不成熟的设计思路也为后面的嵌套表达式挖了个大坑。第三次作业基本完全重构了一遍。第三次作业迫不得已采用了面向对象的一点点思想，将每一个因子看作是一个独立的对象，逐因子匹配，对每个因子本身求导，若是嵌套因子则递归向内部求导，逐层嵌套，最后再将求导结果合并输出。由于第一单元对面向对象以及代码架构的理解还不够熟悉，第一单元的作业炸了很多次……
第二单元电梯系统作业我们接触了java多线程，也是我第一次尝试使用OO的思想来设计代码，具体实现方式为将输入线程、电梯服务线程以及中间的存储类分离，各司其职，并通过锁与wait-notify机制确保线程安全，也就是所谓的生产者-消费者模式。这一个架构我用了三次作业，每一次作业只需要在前一次作业的架构上稍作修改，增加一些新的功能即可。第二次作业在第一次作业的基础上，修改了电梯线程模块，增加了每一层捎带的功能；第三次作业在第二次作业的基础上在存储类中增加了一个调度器，负责分配请求到各个电梯的请求队列。在三次作业中持续运用并且不断成熟的架构设计，使得我代码出错的概率大大降低，也让我对代码功能的实现有了更为清晰的理解思路。
第三单元的JML系列作业，向我们介绍了一种契约式的编程思想以及JML规格，并且基于这个思想逐步实现了对一个地铁线路图的分析。在这一单元作业中，课程第一次采用了官方包的模式，我们只需要根据源代码中的JML要求，实现官方包接口中的方法，只要代码实现严格满足JML，就能保证正确性。从这一次作业开始，在助教大大们提供的官方包的引导下，我才逐渐认识到了架构的重要性。课程组为我们提供了现成的接口设计，直接推动我们按照课程组希望的方向设计我们的架构，让我们把重心放在了各个方法的设计以及规格的实现上。架构与方法实现是相辅相成的，好的架构能让方法的具体实现更加游刃有余，避免了复杂凌乱的代码带来的灾难。
第四单元的UML系列作业，则为我们介绍了一门全新统一建模语言——UML。这一单元的作业依旧采用了官方包提供接口，我们实现的策略。但这一单元的代码需要分析的信息更为复杂，不是简单地实现所有方法就能完成的，需要我们自己揣摩存储、分析数据的方法。经过前几单元的历练，这一单元我很快地找到了设计存储架构的方法，对于UML各个元素的分析也就显得比较直接，bug出错也大大减少。
三、测试理解与实践的演进
第一单元自己写的代码架构由于一开始考虑得不周到，显得较为臃肿，也没有掌握测试的方法，只是依靠自己乏力地读代码以及一拍脑子想出来的测试数据去确保代码的正确性。对于复杂的多项式求导过程，这种测试远远不够，也就使得我第一单元三次作业炸了两次……
第二单元对于电梯的测试，则是通过手动构造不同的测试集来检查电梯运行的正确性，尤其是第三次作业，为了保证换乘时的正确性，需要针对不同的换乘情况分别构造测试样例，来检查3部电梯的配合。测试样例的构造与代码的设计是相辅相成的，在设计代码时，就已经考虑到了可能出现的测试情况，在构造测试样例时联想到的代码可能无法实现的部分，又需要回去检查代码的设计。
第三单元的测试就比较容易实现了，我在这一单元才使用对拍的方法测试代码。由于这一单元代码的架构已经由官方包规定好了，测试的重点就变成了是否严格符合JML的要求。我设计了针对某个功能的精确覆盖测试以及针对整个程序时间复杂度和鲁棒性的压力测试，在代码实现过程中就消除了大量bug，避免了强测互测被炸。
第四单元的测试主要是通过画奇奇怪怪的UML图来测试自己的程序，考虑一些极端情况，在同学之间互相比对答案。由于画图的速度，第四单元的作业并不能进行大量的测试，但UML图本身固定的性质给代码的实现带来了很大的方便，极大地减少了极端情况的数量。其中比较坑的是第二次作业的规则检查部分，我们拿上一次作业的强测数据来测试第二次作业的代码，发现了很多对于循环继承和多重继承类判断的疏漏，及时发现了错误并进行修正。
四、课程收获
从寒假刚下载idea，写pre作业时的一窍不通，到现在千行以上代码信手拈来，我在这一学期的OO课程中获得了很大的收获。
首先最基本的就是java语言的初步掌握以及idea编译器的使用了，大一时候学习的都是C语言，大二下刚接触java语言时还是有点不适应了，但随着对java使用深入，我渐渐地发现了java语言的优缺点，认识到了c、c++以及java的不同。包括代码风格要求、代码架构、强测互测等，OO课程在一次次作业中也不断训练着我们的代码能力。
其实就是贯穿课程始终的面向对象思想——一切皆对象。从最开始的糊里糊涂到发现面向对象思路的技巧与方便，我大概花了两个单元的时间。OO思想为我们分析代码实现提供了一个全新的思路，开拓了我们的视野。
最后，我觉得OO课程这个以单元为划分，每一单元内的3次作业逐次递进的课程作业体系也锻炼了我们的架构能力。课堂上纪老师给我们多次强调了普通码农和架构师的区别。设计代码远远比实现代码重要的多，一个合理的代码架构能让我们的代码简洁易懂，也能大大减少错误的产生。OO课程在大二就为我们确立了架构的思想，对我们未来可能遇到的更复杂代码问题的解决会有极大帮助。
五、课程改进建议
1.对于所有的通知，讨论区中标记的官方认证的答案以助教对疑惑问题的解答能否集中到一个公告贴中，不然每次都要翻遍全论坛的帖子确保自己代码没有遗漏什么点。
2.实验课与理论课能否间隔几天，每次都是上午上课下午就上机，有几次没来得及看上午上课的内容，一头雾水地去上机……
3.第一次作业的难度偏大了，感觉所有4个单元的作业中第一单元最后一个作业是难度巅峰，代码复杂度有点高。