BUAA_OO_Unit4单元总结&学期总结
本单元的任务集中在对于UML三种图的解析上，总体而言，难度并不高。难度主要集中在对UML本身的理解以及作业架构的设计上
架构分析
本次作业基本上完全为迭代开发，因此仍然主要将第三次作业作为分析重点
第一次作业
顶层
algotithm软件包
uml软件包
classdiagram
basic
manager
operationmanager
relationmanager
generalization
realization
model
firstlevel
secondlevel
thirdlevel
第二次作业
仅展示与第一次作业不同之处
src
collaborationdiagram
model
firstlevel
secondlevel
thirdlevel
statechartdiagram
manager
model
firstlevel
secondlevel
thirdlevel
fourthlevel
fifthlevel
第三次作业
分析本次作业其实可以发现，本次作业重点在于对于UML元素的分级。由于原始元素仅保存有普通信息，同时为了整体架构的一致性，选择为这些单独元素设立新类。
依然遵循算法与具体结构分离的原则，此处顶层为两个软件包分为算法软件包和uml解析软件包和一个对外接口供完成官方指令。
algotithm软件包
本软件包用于保存关键算法。
此处提供了两个算法支持，拓扑排序用于确定类图中类和接口的依赖关系顺序，tarjian算法本用于实现循环继承中寻找强连通分量，但本次作业对时间复杂度基本无要求，同时为了安全性，最后放弃了使用。
uml软件包
本软件包采用各种方式用于对uml图中的元素进行处理和解析。
实际而言，为每种uml图单独开设了一个软件包进行分类处理。
uml图的元素均遵循一个总体原则，
-
如果元素重点在于自身信息的处理，选择为其开设一个类进行处理，如果元素重点在于表示多个元素的关系，选择另外开设manager进行统一的关系维护。
-
元素解析选择思路为静态信息保存，即在处理后完成所有查询信息的准备工作，使所有的查询基本上能直接获取结果，为此设立了一个Parse虚类，内置对parse情况的询问，以及要求子类必须实现parse方法。
-
补充的，由于作业对于判断元素名称非空的要求较高，选择注册一个静态方法判断是否为空。
-
由于基本上所有元素均有对自身名字、id以及父类id的询问要求，同时为了保存原始元素信息并便于访问，此处选择设立一个统一的虚类MyUmlElement完成这些信息的保存和处理，同时也继承了Parse类
-
对于异常的抛出和外界命令的询问，统一集中在如UmlStateParse等三个类中进行，其他类不再进行异常的抛出。
-
将各个UML图中的元素从上至下依次分级为不同软件包
classdiagram
本软件包即为对类图的处理
basic软件包
由于类图对于type的处理要求，此处设立了basic软件包用于简化type比较
manager软件包
本软件包集中了对于generalization、realization、association的关系维护处理，也集中了对于operation的处理。
operationmanager
考虑到对于operation之间的比较和维护要求较高，选择单独设立一个软件包封装这部分维护操作。
relationmanager
本软件包实现对类图中元素的相关关系的管理
association
本软件包用于管理association关系
generalization
本软件包用于管理generalization关系，由于本次实现中同时储存了直接继承父类、所有继承父类、直接继承子类、所有继承子类等信息，较为复杂，设立一个类进行统一管理。
realization
本软件包用于管理realization关系，由于本次实现中同时储存了直接实现父类、所有实现父类、直接实现子类、所有实现子类等信息，较为复杂，设立一个类进行统一管理。
model
本软件包用于保存uml类图中的元素
firstlevel
第一层即为interface和class，由于两者有许多共同之处，选择设立一个统一的父类简化操作
secondlevel
第二层级的即为attribute和operation，这两个类放在同一个软件包中完全是处于等级关系
thirdlevel
paramteter，可以看到，这里提供了几个信息查询方法比如ableToMap判断是否能一一对应，
collaborationdiagram
本软件包用于实现对于流程图的解析
model
firstlevel
最外层的collaboration元素，为了便于rule的检查，这里为其配置了isRightRepresent方法
secondlevel
实质上顺序图中查询的基本单位
thirdlevel
本软件包中管理的endpoint和lifeline的解析，注意到这两个元素实际上有很多共同的地方，如对消息的维护等，这里设立一个虚类简化操作
fourthlevel
message
statechartdiagram
本软件包用于实现状态图的解析
manager
本软件包用于管理状态间的关系，实际上即为对transition的管理，由于transition涉及到两个state间多个transition以及其上event等的比较，较为复杂，这里选择设立统一类进行管理
model
firstlevel
secondlevel
thirdlevel
为了便于区分，为初始状态、中间状态和终止状态均设立的一个类，同时有由于其实本质上均为state，设立一个共同的父类
fourthlevel
fifthlevel
架构设计思维和OO方法理解的演进
纵观全学期的OO课程设计，其实我的架构设计思维在原则上始终遵循一个核心思路——安全第一，在这个思路之下，自然而然的选择通过架构上付出一定的冗余性换取相对更高的安全性，通过对功能的不断拆分和细化，避免同一个类或者方法过于复杂。这些都导致我的作业有一个显著特点，代码量极大，软件包和类众多。
当然，具体而言仍然是存在一定变化的，下面从各个单元进行分析。
第一单元
对于第一单元的作业，尤其是第一次作业，尽管我对于java和面向对象思想并不是初次接触，但依然还是完全处于蒙圈的状态，尤其是对于字符串的解析更是毫无头绪，这部分也多亏了练习题和课上测试，帮助我建立这学期OO课程学习的基础。对于第二次作业，我的印象是尤为深刻的，便是增加了大量的新功能，尽管在第一单元已经做了一定的设计冗余，但是依然要增加大量的代码。对于此次作业，在最初我选择使用字符串替换的方法，好处便是对于代码量的增加极小，但是坏处也是自然而然的，放弃了结构等的先验信息，直接暴力替换很容易出现问题。最后，我选择再次更换了做法，选择进行了结构解析，也正是在此次作业，坚定了我这学期的代码原则，宁愿多写，也不要少写，同时尽可能提供更大的可扩展性。
第二单元
在第二单元，为了可扩展性，我其实反倒一定程度上破坏了安全性。本单元中本来处于功能分离的目的，将电梯精简为了一个工具类，电梯的运行完全依赖于调度器进行裁决和管理。这导致电梯确实非常简单，但是调度器为了进行调度，需要获取大量的信息，恰恰这部分信息涉及同步的问题，调度时的管理也涉及到对这部分信息的处理，本单元课下测试出现的问题基本上完全集中在调度器上。然而事实上，这部分的可扩展性其实全程并未使用。这也让我反思，冗余的可扩展性以及为了所谓的“安全”进行功能分离，反倒加剧了不安全性。
第三单元
第三单元开始，我开始谨慎控制可扩展性以及功能分离的程度，同时，本单元同样让我有一种倾向——将newtwork、group、person等作为工具类，信息管理交付其他的类进行处理。但是，本单元也与之前的单元有所取杯，本单元对于时间复杂度的要求较高，如果将其作为工具类，信息的传递涉及类的新建和复制，信息的检索也会涉及大量查询，虽然是hash查询，但是不可忽视的是hash表的时间复杂度其实可以达到O(logn)的级别，hash的反复嵌套也会导致时间复杂度过高。
第四单元
第四单元作为最后一个单元，其实反倒是纯粹的架构思想运用单元。同时，本单元对象本身具有非常清楚的层次结构，因此对于架构设计本身并不困难。
测试理解与实践的演进
OO课程给我留下印象更为深刻的反而却是测试环节。无论架构本身如何的优异，也只能一定程度减少BUG出现的概率。真正想要避免BUG的出现，始终得依赖测试。而在这几个单元中，除了第二单元的正确性检验是委托其他同学写的之外，其余部分完全自己书写，因此个人对于测试其实还是有不少的体会的。
数据生成
数据生成是测试的一大重点。
四个单元中我的数据生成均是使用随机生成法，我曾经考虑过一些同学展示过的，将一些特定的数据预存到生成器中进行排列组合的方法。
但是：
1. 普通的极限数据完全可以直接运行检验，不必依赖于评测机。
2. 特定数据能否将所谓的”特定情况“完整覆盖也是一个很大问题。
3. 与其费尽心机去构造，不如对数据生成中的参数进行控制，通过参数控制数据生成的比例和倾向，不仅可以测试的更加全面，也可以通过参数调整进行定向测试，使得测试更具有针对性。
参数设计
那么自然而然的，涉及到了参数的控制问题。在前三个单元，我是通过大量的public + static的方式直接定义参数常量，在有需要时直接更新对应的值即可。但是很明显，这也有几个弊端：
1. 参数的调整必须依赖于IDE本身，一旦评测机共享给别人，那么参数动态调整的优势就难以体现。
2. 即使是自己测试，为了调整特定的参数也必须不断的切换各类，难以做到统一调整。
3. 同时，评测机的另一大用处自然是进行互测，但是互测的数据往往有很大的削弱，不能直接照搬，需要大量修改参数。
于是在第10次作业，我考虑到了静态化的方法。将参数按照一定格式统一写入一个txt文件里，在每次执行时读取这个文件里保存的参数。
但是正如图片中所展示的，这也有几个不足之处
1. 参数的作用等不够直观，极其容易出现参数的误填写；
2. 参数的读取完全是难以复用的，必须单独配置
3. 参数间没有明确的分层关系和对应关系，使用起来仍然不方便。
因此，在第11次作业起，我选择使用xml的方式进行参数的表示，这里展示一份task15的参数配置
可以看到，xml本身便提供了极强的阅读能力，参数的作用通过命名就可以完全体现出来。同时，参数也能明显的显示出分层关系和从属关系，非常直观。加之IDE等众多编辑器提供的xml阅读器，可以自由的实现折叠，也便于大量参数的阅读和修改。当然，xml的读取本身也更加的标准化，每一层的解析方法可以层层递归调用。
当然，不足之处也在于xml的读取操作其实比较复杂，同时添加参数后，修改xml文件也是比较麻烦的事情。我也将在之后继续完善，欢迎各位提出一些建议。
正确性检验
在一二单元，可以直接进行正确性检验，一单元可以使用python自带的数学库辅助化简，二单元选择和其他同学一起编写的不再赘述。在三、四单元无法直接进行正确性校验，可以通过对拍的方式进行检验。
课程收获
首先无疑便是面向对象的思维方法。尽管在此之前，我已经学习了一部分java和c++，且进行过一定的实践，但是终究是没有系统化的学习，在本学期课程中四个单元共计9次作业，一步步的加深了我对面向对象的思维方法尤其是具体应用的理解。
其次便是工程化，面向对象本质上便是一种工程方法，但是工程方法却远不止面向对象。无论是第二单元多线程中提出了的各种经典模型，还是第三单元中形式化语言乃至第四单元uml图，均是从不同角度规范化我们的设计。同时，OO课程提供的风格检查工具在另一个层面上也帮助我养成了写出更加美观的代码的习惯。
第三便是测试，如果中测是基本的功能测试，强测和互测就是BUG的寻找和发现。无论是测试自己的代码，还是测试其他同学的代码，均是对于测试能力的一种提升。尽管我是选择以自动评测作为测试的基础，但我也会根据数据去定位自己或者其他同学的BUG。尤其是在第三单元中，与我一同进行对拍的同学均被hack了，在寻找他们BUG的过程中，不仅让我了解到了java中的一些小坑，也让我意识到这种极其特殊化的情景类BUG本身也是特别难以发现的。随机数据生成始终存在一定局限性，它放弃了代码自身的先验信息，真正的BUG寻找更需要针对代码本身进行逻辑分析。
课程建议
-
建议中测尽可能提升一部分难度，同时改变进入强测的标准，如不要求中测完全通过，这样可以避免过多同学作业不合格的同时，也能帮助定位一些功能错误。
-
对于第二单元，建议评测机尽可能放慢一些运行速度。尤其是在第五次作业，由于评测机过快，导致最极端的数据也难以出现展示线程不安全的BUG，在之后的几次作业中也有类似的问题。
-
-
