OO-Unit4单元总结

本单元所实践的正向建模与开发

本单元实现了类图、状态图和顺序图。
它们都有如下特点和作用：
类图是一种静态的结构图，描述了系统的类的集合，类的属性和类之间的关系，可以简化了人们对系统的理解。类图是系统分析和设计阶段的重要产物，是系统编码和测试的重要模型。
状态图（Statechart Diagram）本质上就是一个状态机，或者是状态机的特殊情况，它基本上是一个状态机中元素的一个投影，这也就意味着状态图包括状态机的所有特征。状态图描述了一个实体基于事件反映的动态行为，显示了该实体是如何根据当前所处的状态对不同的事件作出反应的。
顺序图一般用于确认和丰富一个使用情境的逻辑。一个使用情境就是系统潜在的使用方式的描述,也就是它的名称所要描述的。一个使用情境的逻辑可能是一个用例的一部分,或是一条备选线路;一个贯穿单个用例的完整流程,例如动作基本过程的逻辑描述,或是动作的基本过程的一部分再加上一个或多个的备用情境的逻辑描述。

本单元作业的架构设计与最终的代码设计和UML模型设计之间的追踪关系

本单元架构设计对比前三个单元较为简易，主要分为图中六个部分。

最终代码设计主要骨架依托类图的确定，最后在一些类关系的细节，类具体有哪些成员和方法做出了部分调整，而顺序图和状态图确定了写代码时必要的状态转移设计和信息传递，让最终代码实现后逻辑性更强，也不容易出错。
具体的图我就不放了，实在画得丑陋。

四个单元中架构设计思维的演进

第一单元因为好久没写java的原因，导致我架构设计属于边想边写的阶段，最后留下了我修复不好的问题，只能勉强熬过第一单元。第二单元开始有意识的在草稿纸上先用文字、图形设计一下自己的主体框架，并和室友交流想法，最后开始实现，但是由于锁的理解不到位，四处加锁导致程序异常卡顿，以超时gg了第二单元。第三单元因为架构已被助教搭好，也就没啥想法。第四单元因为接触了uml，所以就利用uml的状态图和类图以及顺序图进行架构设计，但是uml和代码抽象层次不同，细节上更是有差距，导致最后反过来是因为代码需要所以才这样设计uml图，个人觉得uml有点鸡肋。

总结自己在四个单元中测试思维的演进

我倒是想说自己根据特例测试，根据题目逻辑覆盖捏造数据，并测试边界数据，奈何我是个实诚的人，我的测试思维演进是：自己测->瞪眼法->不行，DPO好香，不如摆烂等佬投喂。

自己的课程收获

总体来说oo课程设计是很好的，也确实学到了东西，但是性能分这种东西属实让人心烦，我不想内卷，所以就没怎么在意这个性能分了，雷打不动的他卷任他卷，所以没因为oo熬过夜也是一种收获？另外一个收获就是大规模编码和迭代能力的提升，这方面有了较大的提高，对于我这张白纸很有用。就是jml算法有点恶心，也算是外驱动让我学了几个算法（对，我没说错，不是jml规格，是jml算法），利大于诟病，望oo课程改进，给同学们更多的提升，更好的体验。