BUAA OO第四单元总结——UML模型及课程总结
作业架构设计
根据官方包AppRunner的输入处理，已经将mdj文件解析为一个UmlELement数组。本单元作业就是要将这个数组的每个UmlElement之间的关系组合成类图、顺序图、状态图，并实现一定的查询接口。
第一次作业
根据本次作业的查询功能，只有类图相关，通过UmlClass和UmlInterface新建MyClass类和MyInterface类，并管理所从属的方法、属性以及继承或实现接口的关系，方法通过UmlOperation实现MyOperation类管理参数。
对所有的查询功能，特别是查询类的所有接口，通过记忆化递归可以减少递归深度，或者通过设置缓存机制，再第一次被查询递归后将结果保存下来。本次作业并未卡CPU时间，不难发现本单元三次作业考察侧重点主要是架构的解析模式。
第二次作业
本次作业新增了状态图和顺序图的查询，新增MyStateMachine类和MyInteraction类及相关属性。
本次作业将构建相关数据的方法放入MyHandler，分离查询和模型化。
第三次作业
本次作业将类图和顺序图、状态图分离，并在对应的Handler中进行错误检查。MyHandler1对应类图的R001、R002、R003、R004、R005、R006错误检查，MyHandler2对应顺序图和状态图相关的R007、R008错误检查。
其中R002检查是否有循环继承中，由于类的继承只有单继承(Java8即本次作业要求，但实际上UML允许类的多继承)，因此不需要进行传统的遍历直接递归就可。对于接口的多继承，采用普通的dfs或bfs复杂度较高，并且要求输出循环中的所有的类或接口，笔者采用Tarjan算法，获取所有强连通分量（任意两点可达，即循环），对只有一个点的强连通分量舍去，剩下的合并输出。
四个单元中架构设计及OO方法理解的演进
第一单元 层次化
第一单元考察表达式求导，作为OO课程的第一次正式作业，对于从未正式接触过“面向对象”的设计思想的笔者来说，难度还是很大。一次次的重写方法，一次次的重构，自上而下，分而治之，表达式-》项-》因子-》表达式。类之间的交互，所有属性...容器的选择和使用，处于最底层的面向对象设计。
第二单元 线程化
第二单元考察多线程交互，对共享对象（临界区和临界资源）的保护，如何设计线程安全的程序。第一次接触多线程，从课上的ppt到CSDN以及往届学长的博客，不断地了解不同的多线程模式的设计。了解“面向对象”的设计模式：观察者模式、工厂模式、传送带等等相关的设计架构和模式，并在本单元中通过工厂模式+生产者-消费者实现电梯调度的多线程。
第三单元 规格化
第三单元为JML规格的实现，通过完善的规格语言，通过课程组所给的接口和规格无脑实现相应的功能。通过这一单元的学习和理解，认识到了规格的重要性，以及实现功能的抽离。本单元并未强调过多的面向对象思想，更多的是养成规格的习惯和一定的算法实现。
第四单元 模型化
第四单元为解析UML类图。通过完整的UML类图输出必要的元素集合，再通过自己的实现复现类似的模型化类图、顺序图、状态图。本单元看似是考察层次化设计的合理性，实际上经过三个单元的历练，架构方面已经不再是问题，而应该把重点放在如何利用给出的元素结合，构造属于近似UML的模型。
四个单元中测试理解与实践的演进
四个单元都有不同的测试方法。
- 评测机：主要针对一单元和第二单元。优点：随机生成测试样例，方便，在互测中可以实现自动化寻找bug。缺点：编写评测机不方便，特别是第二单元实现起来也有点困难
，都是从dalao那里要个第一次的评测机并在之后的二三次作业加以改进。 - JUnit单元测试：第三单元JML规格所提供的测试方法，类似于评测机，只是不需要手动编写方法和类。
- 对拍：方便快捷，找对dalao就能保证很高的正确率。样例手动构造：主要是边缘数据。除了正确性也考察性能，可以发现随机生成样例难以发现的RE错误或越界错误，但需要消耗人力，所以适于对拍
课程收获
- 了解和学习面向对象思想，掌握了一些搭建框架的能力
从面向过程到面向对象的转变还是有点难度的。知道了一些Java开发的常见设计模式 - 通过从dalao那获取评测机和改进评测机，初步尝试了自动化debug，是真的香。
- 会画UML类图、顺序图。
- 学习了多线程的工作原理、思想和实现方法。
- 巩固和学习更多的算法，例如递归下降、图论。
- 了解了协作开发会用到的JML规格，了解一定程度的形式化验证。
- Java编程能力的提高，例如容器的使用，checkStyle的提升
- Git从入门到项目实践
给课程提的一些改进建议
- 最后两个单元的指导书
第三单元中JML规格中，官方给出的JML规格依旧存在很多错误或者说不合JML语法的地方，本次还出现了有歧义的地方。在第四单元中，指导书中的问题更加严重，很多要求并没有说清，也许是课程组希望大家通过讨论区进行有效的讨论，激发大家的讨论意识，但这种情况下的讨论区杂而乱，想要知道自己的疑问是否已被别的同学在讨论区中提出并已被助教回答过，需要将所有的讨论全部翻看，实在是很麻烦，有点不合理。
- 互测机制
互测的初衷当然是好的，通过同学门相互hack可以找到自己难以找到的bug，毕竟强测不太强。但是长达两天多的互测以及互测评分机制，原本为了缩小不同水平同学的差距，到头来却放大了这样的差距，原本优秀的同学难以被找出bug并通过评测机的方法不断hack同屋他人的代码，不太优秀的同学不会找也找不出他人的bug并且自己不断被他人攻击，由于房间的分配是通过强测分数分配的，而强测发现的bug总体来看是低于互测发现的bug，也许就是为了让更多的bug通过互测被发现，那么分配房间的机制就不符合这样的情况，同屋的差距依旧存在，就导致这样的差距不断拉大。并且，互测时间过长，导致内卷强度高，在后续惩罚机制的出现有所降低。
- 研讨课
许多同学很明显是为了分数而去分享的，分享的东西要不就是味同嚼蜡，要么就是与本单元的联系很远，帮助不大。建议增加相应的门槛。
- 实验
每次实验过后，希望给出优秀的代码或正确答案，甚至是一些反馈，不然自己错了也不知道哪里错了。
- 官方代码或优秀代码
给出每次作业相对优秀的架构、算法或者实现方法逻辑。这样很够很好的帮助大家互相学习，效果个人认为或许比互测帮助大。
- 提供部分测试的方法
主要是为了引导大家，不必给出完整的测试方法，这样既起到了引导作用，又让同学们独立思考。减少一定的工作量。
浙公网安备 33010602011771号