第四单元架构设计
官方包将UML图的信息按条进行解析，每种信息解析成一行，解析的过程中只是部分不同种类的信息存在相对顺序，但比如继承关系，target和source对应的id已经出现，可是其对应的类或者接口信息还没有输入，为了避免这种情况，我先将所有输入的信息按照种类存储在对应的Arraylist中，然后按照绝对顺序再次进行遍历，构建树信息，相比于直接构建省去了很多不需要的判断条件，第二次作业多了顺序图和状态图，道理相同，不过由于顺序图的规则没有深入了解，一组强测中出现UMLMessage的父类id为UMLEvent而不是UMLLifeline，程序构建树信息时出现空指针从而出现错误。
为了使程序的架构更加清晰明了，避免面条代码的出现，我定义了自己的类、接口、顺序图、状态图、方法、状态等类，在各自的类内存需要的成员变量以及相对应的查询方法，在MyUmlGeneralInteraction只用Hashmap存这些类的信息，重写接口中代码基本相同，先通过id信息查出对应的类对象，然后直接调用自定义类中的方法，代码简洁明了，不易出错，而且不会有类内代码行数超过500行现象出现。
单元架构
第一单元
先把带非法空格的表达式判断为WRONG FORMAT！然后按照常数、带x的项，封装放入ArrayList动态数组中进行求导和合并，最后输出。这个架构在第一单元的三次作业中都能用，只需要费心思构造正则即可。
第二单元
根据消费者生产者模式写了第一个作业之后，只需要增加捎带队列和待执行队列即可，第三次电梯楼层要求的特殊性，写的很像面向过程。
第三单元
没啥架构可言，就是根据规格写代码再根据需要加上自己需要的函数。
第四单元
画mdj图
测试理解和实践演进
一开始就是指导书有什么需求就写什么，这样在开头两次作业十分快，但是在这些需求的基础上加上一些对架构要求较高的指令后，就只能重构了。所以在之后的作业中，我都会先构思自己程序应该有的架构，留出一些空间来给后面的更高一级的指令实现，面向对象而不是面向过程，好的架构才会有好的程序，没有架构的程序在调试的时候也很难改Bug经常根据是一个点改一堆代码，不方便调试维护，所以我觉得面向对象最重要的是架构，其次才是码上去的代码。
课程收获
思
有了一次堆屎山的经历以致于后来不得不重构的痛苦，我改变了一上来就直接面向程序的思维因为实践证明这是行不通的！！！我会在写代码之前细细研读实验指导书，构思自己的架构，然后对比之前的看看是否更好更合理，是否有可扩展性等等。
谨
第一个单元没有构造测试集测试，结果在一次作业中被别人找出了好多bug,之后吸取教训在接下来的几个单元的作业里我都采取随机生成测试数据的方式跑自己的代码，用shell命令比对别人跑出来的数据看看有没有不一样的，虽然中间有一次也不小心翻车但是感觉数据集多了就莫名的安心了呢~
学
在从对JAVA零基础的情况下通过实验指导书的要求和实际处理代码的时候可以学习到许多知识。例如，在处理第一单元正则匹配爆栈的情况下，我了解到了匹配可以有独占模式，贪婪模式等等在独占量词模式下，正则表达式尽可能长地去匹配字符串，一旦匹配不成功就会结束匹配而不会回溯。一开始使用贪婪算法，结果输入的表达式超过1000字符后会爆栈，原因是正则表达式会尽可能长地去匹配符合规则的字符串，且会回溯。然后知道了一些具有某些特性的元素可以把它封装成类，并且拥有自己的函数。在第二单元学习到了线程，虽然现在还不是特别的理解透它，但是通过这三次作业也对它有了一个大致的了解。
具体意见
关于课上实验
我觉得课上实验这个环节可以取消掉，因为我们没有办法在一个半小时内写完一套完整的代码并且保证完成调试修改Bug。而且下午课上实验用到的东西往往是在上午上课的时候才刚刚接触到，根本写不完真的太窘迫了。
关于作业开放时间
课下作业的开放时间最好能跟操作系统课程设计这门课的课下作业开放时间错开，不然这两门时间分配真的很不合理，花大部分时间在OO上，OS的课下作业总是在当天上机的上午极限通过。
关于测试
强测部分
测试点可以出的更全面一些，有时候我考虑的一些方面，测试点根本没有涵盖，而别人没有考虑到但是和我得到的结果一样，多少有些难受。
互测部分
我觉得我们这一学期的互测改革的还是挺好的，不恶心人，但是去测别人的积极性就不高了，有时候测也是用大量数据集跑代码然后比较不一，在把数据拿出来hack人，花时间去读别人代码是不可能的，这学期都不可能。所以我觉得大部分人对于互测的积极性都不是太高，（狼人除外）我觉得互测的奖励机制可以进行一些调整，诱使我们不得不读别人的代码。