BUAA OO 第四单元总结
BUAA OO 第四单元总结
一、第四单元架构设计
第一次作业
作业要求
实现对Uml类图的元素分析
设计细节
本次作业的Uml类图如下
在第一次作业中，仅对UmlClass，UmlOperation和UmlParameter进行进一步抽象。由于Id的唯一性，在读取全部element时，利用hashMap将class，interface和operation建立索引，同时也将全部element建立索引便于后续查询。同时，对于class进行进一步封装，建立class下属的operation、attribute以及其对应的父节点等信息，便于后续查询操作，同理对于operation和parameter也进行了封装。
对于指令1、2、3，均可利用hashmap进行直接查询。对于指令4、5、6、7、8则均在MyClass中进行具体实现。在MyImplement中调用MyClass提供的接口函数即可。
第二次作业
作业要求
实现对Uml类图、时序图和状态图的元素分析，并实现相关查询接口。
设计细节
本次作业Uml类图如下
在上次作业的基础上，对新加入的元素Interaction、LifeLine、StateMachine、Region和Transition做了封装。并且由于输入处理的情况增多，新增了Utils工具类用于处理输入和在输入阶段对类图、时序图和状态图的建模。实际上对于建模的工作量才是最大的，在组织好相应类的模型和数据结构后，再进行查询操作就是一件很自然的事情。
类的内部结构方面，时序图部分，Interaction类维护LifeLine和EndPoint，LifeLine维护creator和相关message的信息。状态图部分，StateMachine仅维护一个Region，仅仅是作为对外的一个接口方便调用。Region中维护State和全部的Trigger，在预处理时，则把Transition里的Trigger全部抽出，并在两个状态之间连边。对于边的抽象在Edge中，具体而言就是维护了起点终点信息，和两个状态之间的全部Trigger。
对于新操作的实现，时序图部分，在预处理部分已经为三个操作准备好了相关数据组织，直接利用HashMap查询即可。状态图部分，指令1和指令3可直接查询，对于指令2，由于在Region中已经建立好了图，利用对图进行简单的BFS即可。注意在预处理建好图之后先对整体做BFS检测是否存在initial到finish的路径。
第三次作业
作业要求
实现对Uml类图、时序图和状态图的元素分析，并实现相关查询接口，并加入了模型有效性检查。
设计细节
本次作业Uml类图如下
在上次作业的基础上，要加入对模型的检查功能。对于本次作业要用到的新元素Association和AssociationEnd进行处理，需要在Utils中的预处理加入新的分支。由于方法复杂度进一步增加，对Utils的预处理过程进行进一步细化，同时在预处理过程中，将Association元素加入到MyClass类中，方便后续指令的处理。
在有效性检查中，R001可在读入的过程中完成，R005-R009在组织好数据结构和相关类维护的数据中，也能很容易的实现。稍微复杂的是R002-R004。对于R002，则在MyClass中通过其维护的attributes和associationEnd比较即可。对于R003，由于维护有Class和Interface的父子关系，利用dfs来找图中的环即可。对于R004，由于Class是单继承的，如果出现重复继承则会在R003中被检测到，其实只需要对Interface做判断即可，同样利用DFS，在递归过程中记录每个元素在递归过程中出现的次数即可。
二、课程总结
对OO方法和架构设计的理解
在这学期OO课程的培养下，最直观的进步就是感觉现在的代码还勉强能看，学程设和数据结构时候的代码实在没眼看。OO课程将层次化设计的思想贯穿始终，在进行具体的代码实现前，应当提前做好模块化的设计工作，要设计好数据与功能之间的关系。这一点不光体现在这门课程的代码实践中，在完成其他项目代码时，无论功能简单与否，做好设计工作都是一件非常能提高效率的事情。在写python的时候，不会再脑门一热，要写一个脚本就单独开个函数从头到尾写一遍，然后下次再有需要时发现之前的代码完全不具备复用性。一个好的架构，除了可扩展性之外，也能让整体的逻辑设计更加清晰，在debug时能够更快的定位，实现过程中也不会出现两天没看代码就看不懂了的局面（×对于更贴近实际的大型项目而言，面向对象的设计能够实现对整个大型项目的管理，对于整个模型的抽象的想法也能更好的指导代码实践。
对测试的理解和实践的演进
对于OO这门课程而言，测试恐怕比设计来的还要重要。在以往习惯了通过准备好的数据来对自己的代码进行正确性检验，这门课更让我意识到了测试的重要性。在第一单元，开始完全不懂要如何进行测试。在同学的帮助下，了解了递归下降算法，学会了如何搭测评机进行测试，但还是会出现某些边界情况没有办法覆盖到。在第二单元和第三单元的测试中，还要求对程序性能进行检测和评估。总体而言，对于测试只能说掌握了基本方法，但还没能够对整体的测试覆盖率进行评估。在造数据的时候，数据生成的逻辑也会启发到对代码的正确性检查，从某种程度上说，数据生成也是对代码进行检查的一个过程。
课程收获
-
对于java的掌握
代码实践永远是掌握一门编程语言最有效的方式。在写pre的过程中就能迅速掌握java的基本用法，不得不说写代码还是比看书来的快多了。随着课程的进行，也掌握了多线程编程模型和java的特性等等知识，对于java的理解更进一步了。
-
面向对象的设计思想
以往写代码基本就是想到哪里写到哪里，面向对象的设计思想更多的是为代码实践提供了一个新的理论指导，如何真正的将一个复杂功能的系统给组织起来，实现代码上的权责分配，OO确实教会了我很多。同样，在看到别人的完整项目时，也能更容易理解代码的框架和功能。
-
代码风格
OO强制要求的checkstyle真的好评，纠正了很多不好的代码习惯，增强了程序的易读性。对于函数行数的限制也在侧面让人保持了面向对象的习惯
课程建议
- 在JML单元实际上真正学习JML的就基本在第一次作业里都学完了，配合上课上的实验，感觉后面两次作业和JML关系就不是很大了，反而更像一个算法作业，大家完成作业的重点基本都在如何避免TLE上，感觉没有太大必要为了这个单元开设三次作业
- 在UMl这个单元，个人感觉在完成作业时很多时候就是在和指导书较劲，对我个人而言真正的难点在于有没有准确理解指导书的内容。在设计和实现上反倒是没有多少困难。个人感觉第三次指导书对于R002、R003的表述等不是很清晰，还有诸如同学在群里问的“为空”等，指导书中确实有描述，但看的时候确实不直观。（手动保命）建议能够给出更加直观的样例在每条指令下配合说明，可以尝试加一些配图，有时候对着一堆json文件确实不太好看，毕竟指导书的目的是希望大家准确理解题意，如果门槛都在理解题意上感觉有点头重脚轻了。
- 还是对于后两个单元的意见，感觉后两个单元的内容实际上撑不起六次作业的内容，对于UML图和JML而言，更多的意义是在理论层次上，可以考虑将两个单元的内容合成一个，最后一个单元的内容以一种较为开放的形式，完成一个综合功能的程序，可以由课程组给出一定接口和框架，留下一部分需要个人设计的空间。
