BUAA_OO第四单元总结+课程总结
第四单元架构分析
第十三次作业架构设计
此次作业和第三单元有相似之处，都是官方源码实现了一些功能，我们只需要实现官方代码给予的接口里的方法即可，官方代码的主要作用是能够把读入进来的（经过官方包得到的）mdj文件，转化成一个UmlElemet数组，UML图中的所有元素都是UmlElemet的子类，因此我们通过在MyImplementation的构造方法中遍历读取UmlElement数组进行建模分析，从而为后面的方法实现提供信息。所以本次作业的难点在于理解UmlElement的子类的属性的含义。除此之外，由于相关元素的类（UmlClass，UmlInterface等）所存储的信息比较少，像对于继承关系，UmlClass没有父类和子类的信息， 因此我们创建一个MyClass类，既包括的UmlClass本来的成员变量，又添加一些新的成员方便我们使用分析，MyInterface、MyOperation同理。对于方法的实现，由于本单元作业对时间的要求的不高，因此我并没有过多的考虑优化。
UML类图如下：
第十四次作业架构设计
第十三次作业的难点在于源码的理解和我们对于作业目标的明确，有了第十三次作业的基础，第十四次作业在明确目标上就迅速多了。第十四作业增加了顺序图和状态图，重难点依然是对于每个相关的UmlElement的子类的各种属性的理解。除此之外，这次作业涉及到的相关方法的实现比上次作业复杂了很多，其中，最有难度的是状态图里关键状态的判断，对于如何判断关键状态，通过两次dfs就可以判断，第一次通过dfs判断是否可达终点，第二次去掉该判断节点及相关边再利用dfs判断是否可达即可，关于dfs的算法如下：
private void dfs(int pos) {
if (num2state.get(pos) instanceof UmlFinalState) {//判断目前节点是否是终点
flag = 1;//用flag判断是否可达
return;
}
visited[pos] = 1;
for (int i = 0; i < num; i++) {
if (visited[i] == 0 && graph2[pos][i] == 1) {
dfs(i);
if (flag == 1) {
return;
}
}
}
}
本次作业为了减少MyImplementation的行数，我将第十三次作业涉及到的类图的操作都封装在了MyClassDiagram里面，因此本次作业的架构如下：
第十五次作业架构设计
经过了前两次作业，第十五次作业相对来说在理解和实现上都容易了许多，这次作业是要根据读入进来的UML图判断该图是否合法，不合法输出错误类型。本次作业需要多考虑的元素主要是UmlAssociation和UmlAssociationEnd，理解了各个元素及其成员的含义，不管是提前维护还是在异常的方法里通过循环判断，由于作业对时间限制非常宽松，所以什么方法都可以，保证正确性即可。这次作业的主要难点是对于R003循环继承和R004重复继承异常的判断，这两种异常我依然用dfs进行递归判断，对于R003，找到一条从自身到自身的路径即可标记为异常类，对于R004，如果递归遍历到重复的父类时即可标记为异常类。本次作业我用MyClassDiagram、MySequenceDiagram和MyStateDiagram进行封装之前的作业，使得架构更为清晰。本次作业UML类图如下：
三次作业bug分析
本单元的自测策略和第三次一样，同样是造（借）数据找同学对拍。在对拍的过程中确实发现过许多bug：
第十三次作业：忘记考虑接口的多继承，其父类属性应该是个MyInterface数组。忘记考虑接口也会有属性。
第十四次作业：dfs写错了，回溯的时候我将visited数组标记为0，实际上不用标记，因为此函数是为了判断是否可达，而不是判断路径个数。
第十五次作业：由于我用了很多hashMap，因此存在很多使用get的时候获得空指针然后我依然对其调用方法的情况，导致出现了很多空指针异常。
四个单元中架构设计思维及OO方法理解的演进
第一单元：层次化思想（尽管我用的是预解析）是本单元最关键的思想，采用层次化思想，使得代码具有更好的灵活性。某一层不需要知道它的下一层是如何实现的，而仅仅需要知道该层通过层间的接口所提供的服务，因此一个难以处理的复杂问题分解成了若干个较容易处理的更小一些的问题。这样，整个问题的复杂度就下降了。层次化思想对于我们以后的软件和硬件的学习都有很大的帮助。
第二单元：第二单元的难点在于多线程的相互传递信息，我认为本单元特别符合OO的思想，OO方法提倡用人类在现实生活中常用的思维方法来认识和理解描述客观事物，电梯和调度器的编写过程其实就是我们依照现实里电梯的运动过程来指导我们的架构设计思路，因此第二单元让我对OO的理解更加深入。
第三单元：本单元的主要任务是根据JML规格来撰写代码，JML作为一种行为接口规格语言，可以帮助开展规格化设计，JML本身的描述是逻辑严格的，所以程序员再根据JML规格编写代码时不会发现二义性。 本单元由于架构比较固定，因此架构设计上没有提升太多，但是对于java语言确实理解的更加透彻了。
第四单元：第四单元其实是为了让我们能够对mdj语言有更好的理解。对于开发团队的层面来说：有利于队员间在各个开发环节间确立沟通的标准，便于系统文档的制定和项目的管理。因为UML的简单、直观和标准性，在一个团队中用UML来交流比用文字说明的文档要好得多。对于各个开发项目来说：可以通过UML共享开发经验和资源。uml只是面象对象分析、设计思想的体现，和具体的实现平台无关，用UML建模和设计的系统可以用JAVA或C#来实现。除此之外还可以做为系统分析设计过程使用的表示和体现工具。
四个单元中测试理解与实践的演进
说来惭愧，由于本人能力欠缺，前两个单元都并未采用自动化测试来验证自己程序的正确性。主要采用手动构造测试数据+肉眼判断正确性为主，不但费时费力而且还低效。后两个单元由于难度下降可以通过对拍进行验证，因此我写了自动生成数据（也需要手动构造）+批处理比较两文件输出进行测试，相对于前两个单元确实高效而且可靠。
不过在学习的过程中，我逐渐明白了软件中测试的重要性：软件测试整体是验证功能的实现、可用性，检查程序的错误，最终目的是为了确保软件的质量、确认软件以正确的方式做了所期望的事情。除此之外，在测试的过程中还要遵循测试的原则。
课程收获
面向对象这门课真的让我收获了很多东西，可以说在这门课上所学到的东西对于我们以后的学习甚至工作都有着重要的指导作用，其中最重要的收获包括：
1.对于java语言的理解、运用
2.对于OO思想的理解和体会
3.（研讨课）让自己能够多多表达想法，促进和同学的合作与交流
4.对于代码测试和验证的理解（互测和自测）
5.对于ddl的合理安排和处理（每次作业固定的各项截止时间）
6.通过老师、助教、同学学习他们对于相关问题的理解，进而提升自己
具体的改进建议
改进建议谈不上，更多的是针对于自己在课程学习中遇到的困难，勉强提一些意见，如果这些意见课程组已经有自己的考虑，或者也可能是我本人的问题，希望能够见谅。
1.研讨课和实验课的安排可以更灵活一些。我认为研讨课其实在第一次作业完成后是最有用的，因为研讨课主要是帮助我在优化和为了下一次作业的可迭代性上加强理解。而实验课其实是在第一次作业开始前进行是最有用的，因为每个单元的第一次作业其实是最难的，因为从0到1的这个过程是最不好理解的，实验课能够帮助设计架构和理解题目。可是有的时候会出现这样的情况，自己已经设计和完成好作业架构了，但是实验课上发现助教的代码架构会更好，但是重构的风险是很大的，因此实验课可能就仅仅变成了一次编程测试。当然我也能理解，实验课和研讨课是周四，然而周一发新作业，周六就截止提交，因此如果周四上完实验课以后再着手开始，其实时间不一定够。希望课程组以后能够根据oo课程的时间安排灵活布置研讨课和实验课。
2.互测环节其实可以修缮一下。其实我总觉得互测过程有点不太舒服，按照规则，A房里发现一个bug得到3分，C房里发现一个bug得到1分，当然这个安排是合理的，但是按照我想法，如果有人发现自己进了A房测试的积极性就会相对消极一些，如果发现自己进入C房可能测试的积极性也会消极，因此按照等级分房间总觉得对于大家测试的积极性帮助不大。因此，我的想法是，每次强测结束后依然按照强测成绩分ABC三个等级，但是一个房间内均匀拥有ABC三个等级的学生，然后hack分数根据自己的等级和对方的等级进行赋分，自己等级越低，对方等级越高，那么hack的分数就会高一些，反之亦然。这样我认为大家在互测上可以一视同仁，每个人hack的公平性是差不多的，这样最后大家的积极性会好一些。如果这么做，或许对于学生的信息就没必要公布了，而且我也觉得公布房间里的学生信息没什么必要。
3.后两单元的强测时间公布可以提前一些。我以为，前两单元不当天公布强测结果是因为第二天有互测，所以没必要公布，但是后两单元没有互测，我认为没有必要再隔一天公布强测结果，毕竟正值期末，bug修复还是能够提前弄完较好。
