第四单元总结

一、本单元架构设计

1、单元目标

从本单元三次作业来看，本单元意在实现一个对已经经过初步解析了的UML图进行进一步解析的UML解析器，通过已获得的包含UML各元素相关信息的语句，构建自己的相关UML元素的模型、网络，最终通过输入指令获取想要的信息，并提前对该网络进行初步的正确定检查。

2、我的架构

本单元我也没有重构，每次作业都是上次作业的迭代，因此在此我只介绍第三次作业的架构设计。
在设计之前，我浏览了讨论区，最后选择将涉及到的所有UML元素都进行再次封装，变为My元素，将需要的属性、方法保留，不需要的剔除，同时也加入了一些新的、有利于题目要求操作的方法、属性，或者是有利于网络构建的属性、方法。
因为在行数上我采取了消极态度，直接“破罐子破摔”，因此我的MyImplementation类包括了大量储存My元素的ArrayList容器属性。其方法则是与题设要求的操作一一对应（除了DFS我采取了递归操作，因此方法中有dfs函数）。
而MyImplementation的构造函数则是我的架构的核心部分————它承担的是构建整个UML关系网络的重任。我采取的办法是对UML元素进行分类，然后对MyImplementation函数读入的元素列表进行多次循环读入分析、操作，逐步完成网络的构建。

3、优点

我认为我的架构的优点在于可迭代性强，可强力避免重构的发生；同时，在构造函数中就建立起了一个非常清晰的网络，十分有利于后续开发。

4、不足

不足很明显，风格过于恶劣：MyImplementation类在一千行左右，各项复杂度也极高，难以体现出面向对象编程的特点、优点。

二、四个单元的架构设计与OO方法理解

1、第一单元

本单元的目标是对表达式结构进行建模，完成多层嵌套表达式和函数调用的括号展开与化简。
我的架构有两个核心：
第一，我采用了递归下降的方法来对表达式进行解析：表达式可看作是若干个项的和，而项可看作是若干个因子的乘积，如此鲜明的层次为递归下降提供了很好的环境。
第二，我合理地运用了“统一化”的思想，将看似毫无规律的多项式进行拆分，并最终成为一些能拥有统一形式的“元素”的乘积，以便进行进一步简化。
在这一单元，我学到的最有用的就是OO中的层次化的思想、递归下降的方法。

2、第二单元

本单元的目标是模拟基础以及较复杂的多线程实时电梯系统。
关于架构，我选择了生产者-消费者模型，input类为生产者，schedule类为消费者模型，托盘为两个队列：人队列与电梯队列。我的主调度器只负责将人队列中的人逐个分配到这个人将要乘坐的电梯的等待者队列中，之后的调度则由电梯内部的调度程序完成。
本单元最大的难点在于各个锁的实现、如何避免轮询，其中轮询更是本单元我bug频出的地方。
本单元，对于OO方法，我主要学到了多线程的实现、调度算法。

3、第三单元

本单元的目标是实现社交关系系统中不同消息类型以及相关操作，与前两个单元不同，我们在这一单元只需要根据JML规格完成代码即可。
由于规格的存在，在本单元几乎不需要考虑架构的问题。在本单元，我认为最需要上心的是一些涉及到图论的算法问题以及代码的性能。
在本单元，我学习到的、给我感触最深的就是那些图论算法，以及通过额外增加查询属性来提升代码在面对特殊要求下的性能的方法。

4、第四单元

第一部分已经提到，我的架构的重点在于提前在构造函数中完成了My元素网络的构建，而在本单元学到的方法主要是对已获得类的再次封装、多次循环扫描式读取来构建网络。

三、测试与实践

在第一单元，我在测试中主要是构造一些包含边界数据的测试样例进行测试。
在第二单元，我主要是对两点进行测试：第一，多线程下输出是否会不符合时间逻辑；第二，在临界时间与已有的调度算法下，电梯是否会超时。前者是正确性，后者是性能。
在第三单元，我主要是构造含有大量数据、网络复杂的样例，对代码进行性能方面的极限测试。
从演进来看，我逐步实现了从代码正确性到代码性能方面的测试。

四、课程收获

1、较深刻地认识、学习了层次化的重要性、好处，层次化能使我思路更加清晰，有一种掌控全局的感觉，编程时得心应手。
2、对多线程以及相关操作有了比较基本的掌握。
3、对JML如何书写、如何阅读、JML的好处有了直接的体会、学习。
4、极其深刻地明白了一个好的架构设计的重要性，在以后的课程、工作中我一定会提前设计好架构，再进行其他活动。（最简单的一点，我凭借着还不错的架构设计，在本学期还未重构过）

五、改进建议

1、我个人认为第四单元应该放在第一单元的位置。在第四单元中，我们学习了关于UML图的各种知识，再加上其层次化特点，我认为这一单元用来给OO课程打底很不错。
2、希望要么提高pre的难度、深度，要么降低第一单元难度，否则一上来就“降维打击”有些暴力。
3、对中测难度进行一些合理的调整。中测决定了我们能否进入强测、互测，如果太难，会给同学造成很大的压力；如果太简单，对于会自觉对自己代码进行测试的同学来说问题不他，但是对于比较懒惰的同学来说，就是“钓鱼”了：原本漏洞百出的代码由于中测过弱，“混”进了强测，直接祭天。（本人有过一次经历，属实惭愧）

标签：OO,架构设计,架构,元素,UML,第四,单元
来源： https://www.cnblogs.com/tswq/p/16422873.html