BUAA_OO_2022 第四单元总结
BUAA_OO_2022 第四单元总结
一、第四单元架构设计
1.1 hw13 架构设计
在本次作业，只需要对类图进行解析，但是考虑到未来作业可能需要对顺序图和状态图进行解析，因此专门设置了ClassDiagram作为顶层管理类来管理类图的相关信息。
很明显我们官方包提供的原型类很难建立快速查询的树形结构，因此我选择对其中部分关键类进行包装，其中主要包括Interface、Class,使其能够包含属性、操作、父类、子类等信息，并提取相关具有共性的方法构造CommonOperate接口。
对于顶层解析信息采取以下顺序进行：
第一轮：UmlInterface、UmlClass、UmlAssociationEnd
第二轮：UmlOperation、UmlGeneralization、UmlAttribute
第三轮：UmlParameter、UmlRealization、UmlAssociation
本次作业bug：在类的属性耦合度计算时，从父类继承来的属性出现了缺失，从而产生了bug
1.2 hw14 架构分析
本次作业新增了关于顺序图和状态图的解析，采取与第一次作业相似的方式进行增量开发。分别新增SequenceDiagram、StateDiagram来管理顺序图和状态图的信息。
对于顶层解析信息采取如下顺序：
第一轮：类图：UmlInterface、UmlClass、UmlAssociationEnd；
顺序图：UmlInteraction；
状态图：UmlStateMachine；
第二轮：类图：UmlOperation、UmlGeneralization、UmlAttribute；
顺序图：UmlLifeline；
状态图：UmlRegion、UmlEndpoint；
第三轮：类图：UmlParameter、UmlRealization、UmlAssociation；
顺序图：UmlMessage；
状态图：UmlPseudostate、UmlState、UmlFinalState；
第四轮：状态图：UmlTransition；
第五轮：状态图：UmlEvent；
本次作业bug：无
1.3 hw15 架构分析
本次作业要进行规格检查，在架构上沿用上一次作业架构，没有新增类，而是将规格检查的方法直接放到了类图、顺序图、状态图的顶层控制类中。
但在之后分析，个人认为如果要让架构的可扩展性更强，其实应该为每种UML图新增一个checker类，其中集成了检测该UML图的方法，这样对于以后如果新增新的检查规则，可以直接在对应的checker类中新增，更加轻松。
bug分析：在R003中关于接口循环继承的检测出现了问题。由于我是采用拓扑排序的方式去寻找在环中的元素，对于有自圈的元素，可能会使得相关联的元素在分析的过程中无法被消掉，因而可能将不处于环内的元素判断为环内元素。
二、架构设计思维的演进
- 第一单元是我们接触OO编程思维的开始，我们以表达式括号展开为例进行了三次迭代开发，在本单元我认识到了抽象与层次化的重要性。
- 第二单元则是关于多线程编程电梯的实现。而在本单元我个人认为重点是实现多线程的同步控制，为了实现线程安全，我们就需要安全的通信，进而需要封装安全的通信容器，而为了保证性能我们就需要创建比如我们要设计Schedule类、Dispatcher类来对请求进行一个总体的分发，要保证每一个电梯都尽量处于运行状态而不产生”饥饿“。
- 第三、四单元主要内容是对JML、UML的认识。JML是一种让我们可以在一定程度上忽视底层实现而进行框架设计的描述性语言，而UML则是一种面向对象式的统一建模语言，帮助开发者构建可视化框架，从而描述类在时间和空间上产生的交互关系。
总结：
其实最开始我认识到的OO，其实就是把类划分了，而如何做一个好的架构，我认为就是继承的好，尽可能地去实现复用。但逐渐我认识到，架构设计重要的是要进行封装，封装的好自然就可以抽象归类进行继承和实现，自然就实现了复用性。而如何进行封装，就是要进行具体分析和抽象分析，尽可能将功能、职责在一定程度上尽可能地进行划分并归类，使得类达到较低耦合度和高内聚的特点。同时我们在进行划分时，一种重要地思想即是去层次化，底层到高层对应地层次表征的功能愈加的泛化，因此层次化即使我们看待问题、分析分体的切入点，也是我们要实现的目的。而在架构设计时，我个人也逐渐认识到可以先进行一些UML图的绘制或是JML的描述，将具体实现和框架设计在一定程度隔离开，分工地去进行一个项目地实现。
三、测试的理解和演进
测试的流程大致可以分段为数据生成、数据投喂、正确性检查三部分。
对于数据生成，我们可以使用随机数据生成以及手动构造数据两种方法进行。其二者各有优劣，随机生成可以依照某种规则在一定范围内快速生成大量数据，数据强度不定，覆盖面较广，但是针对性不强。而对于手动构造数据，很显然覆盖面不足但针对性强。对于上述两种方式，很难说哪个更具有优势，应具体情况具体分析，比如对于第一单元，采取与分析手段相同的递归下降来生成数据，其强度就相当可观，但是对于第二、三单元，随机构造就很容易产生问题，比如一些情况需要某个特定情况发生多次才可以检测出来（如第三单元 getReceiveMessage只有收到Message到达4个以上会产生区别），这就依赖于数据规模的大小，但终究很容易会出现很多有纰漏的地方。
而对于数据投喂部分，通用的就是使用python提供的subprocess库，可以运行多个进程并进行通信。
对于正确性检测部分，第一单元主要采用sympy库进行检测，在第二单元采用了大佬分享的数据正确性检测的部分代码，对于第三、四单元则主要是用对拍来进行检测。
而在学习过程中，我们也接触到了Junit的测试工具，但是我个人只是在第三单元简单使用了一下，并没有大规模使用，还是希望自己在未来可以花时间多研究研究。同时对于本学期没有完整地完成过一套评测系统，其实也是略有遗憾，希望自己能够在空闲时间努力提升自己，完成一套独立完整的评测系统，并在其他的课程上应用。
四、课程收获
- 首先肯定是对OO的思想有了一定的认识，它让我认识到分工和抽象的重要性，但是OO的思想要始终不断地落实到实处，我们才会有成长，才能不断积累经验、增加自身事物的敏感度和抽象能力。
- 简单接触到了多线程编程的大门，可以说是相当的有趣了，对于我个人来说是开启了崭新的领域。
- 了解、学习了UML和JML，在未来成为我们规划设计、向他人展示设计的得力工具。
- 同时OO课程也是对我们个人心态、能力的锻炼，每一次作业、每一次迭代我们都要面对不小的挑战，它即教导我们如何做到尽可能地不会重构，也在教导我们不要畏惧重构。
- 接触到了简单的设计模式。
- 认识了SOLID设计原则，其将作为未来我继续进行架构设计遵循的基准。
五、一些建议
1.希望每次实验结束后都能够公布答案
2.希望能够开设一些关于测试的指导，包括如评测机、JUnit的一些tips
3.希望可以多融入一些JAVA底层的知识，包括虚拟机、内存管理等部分的知识（如某次实验以Java内存回收机制展开）
4.希望可以引入更多设计模式，个人看来设计模式就像是一些编程时的tips，总是能以小见大的提醒我们、帮助我们设计架构。
