【面向对象】四单元UML总结&学期总结

Love The Way You Lie 2021-11-04 22:44 285阅读 0赞

# **前言** #

--------------------

理论上，这是本学期最后一次OO作业。虽然告别了OO课程，但是没有与OO说再见。我将在这次博客中总结针对第四单元的和本学期所有作业，分析自己代码能力和架构能力的成长。

# **四单元作业架构总结** #

--------------------

两次作业中我都采用了“树形”的代码架构。对于每一条指令，我会让顶级父类向下传送“信号”，直到最底层获得执行结果。这两次作业我都没有进行明显的优化，导致第二次作业的强测中有一个测试点出现了超时的情况，很可惜！

*  ## 第一次作业 ##

![1617294-20190623224650733-831537482.png][]        ![1617294-20190623224803254-1298987166.png][]         ![1617294-20190623224851398-233849291.png][]

从左至右分别是包之间的关系（整体架构关系）、UmlClass类内部的结构和继承map类的结构。

下面我将描述代码架构：

1.  1.  将MyUmlInteraction当作交互平台使用，其受到请求时向Storage类中查询；
    2.  Storage中保存所有MyUmlClass/Interface（我没有区分类和接口），并保存fatherMap类存储类之间的继承关系；
    3.  MyUmlClass存储attributionStorage和OperationStorage；
    4.  OperationStorage中保存类的parameter；
    5.  fatherMap中存储接口实现Map和关联Map；

总体上讲，我在建模时尝试“恢复”java中这几种UmlElement的相互关系，因而形成了多层的结构。不过我认为自己对继承图和接口关联图部分没有处理好，导致此处代码看起来很混乱。其他类基本上都是很清爽的。我还尝试用工厂模式对几个图进行构建，但是各种原因最终没有成功。

*  ## 第二次作业 ##

![1617294-20190623230907137-444294803.png][]       ![1617294-20190623230956077-1003276570.png][]       ![1617294-20190623231028475-419024696.png][]

从左到右分别是包之间的关系（整体架构关系）、状态图内部结构和顺序图内部结构

这一次我依然采取了和上次类似的形式，创建了和fatherMap类同级别的StateMachineMap和InteractionMap。因为我认为类之间的继承关系、状态机类和顺序图类是平行的关系。这次我尽自己的力量去最大化解耦，但是还是由于算法的问题，导致代码十分的鬼畜。不过在状态图和类图，都存在一个Map和一个Storage存储映射关系、map和其他内容。所以这两部分的代码都是“复制粘贴”一样的。

这次作业从算法上来讲（几个复杂的规则检查），还是有一些挑战的。我使用了几个DFS搜索算法，基本和这个类似。其实这块如果有时间的话完全可以做成工厂模式。

![1617294-20190623231919008-407752634.png][]

# 四个单元中架构设计及OO方法理解的演进   #

--------------------

回顾几个单元写的作业，真的明显感觉到自己成长了不少。不管是对语法原则的使用、设计架构的理解，都与最开始的时候上升了不只一个档次。

分析这11次作业，我发现自己都是在尝试“还原真实场景”，这个说法在表达式、电梯、UML作业中能非常明显地感受到。每一次我都是老老实实地区“恢复”人脑的思维过程。这可能也导致了我的性能分从来不高。

*  ##  第一单元 表达式求导 ##

这时候刚刚接触Java编程，对继承和接口等内容的理解还不是很充分，所以程序写起来有些费劲。尤其是最后一次作业，作为一个“由于自己觉得自己不太会用接口而没有用的”人，真是瑟瑟瑟发抖。但是那次作业，还是很有收获的，比如学会了将对象进行拆分，划分成不同的类；架构上可以整体地进行分析，而不停留在算法阶段……

还有就是浅拷贝和深拷贝的问题，由于我自己“嵌套”定义类，导致这个问题疯狂出现。看到了一句话，“每一层都是浅拷贝那最后就是深拷贝”。自己歪打正着最后弄对了。我在这方面还是很欠缺理解。

![1617294-20190624082945102-41035105.png][]

![1617294-20190624083042286-756043477.png][]

顶层类深拷贝代码                                                                             当时觉得8个类太疯狂了

还可以提升的地方：

1.  对sin、cos等使用工厂模式；
2.  对于每一个方法，明确方法的目的（避免现在这样一个方法60行的情况）；
3.  别把东西传来传去的，空间复杂度太高了；
4.  本应作为类存在的对象被当作了属性（Key什么的我固定保存了系数，实际上应该将sin和x拆开），缺少面向对象思维；
5.  不会使用equals和toString，导致代码很鸡肋。

*  ## 第二单元 电梯 ##

多线程部分我感觉到现在还对线程安全问题还缺乏理解……我有好多地方都直接sychronize了，并且还在公测时遇到了严重的线程安全问题。我还使用了一些“结束信号”当作信号枪使用。

我在架构上使用了楼层，将楼层作为共享单元，等于调度器和电梯之间没有什么太大的关联，电梯自己还有许多功能。这样做我认为能在一定程度上减弱线程冲突导致的问题。这回对于类的划分其实很标准，所以我自认为自己写的还行。

![1617294-20190624105135943-465765231.png][]

现在想起第三次的作业，对于每部电梯有不同的需求，当时应该使用继承的方法去写，这样或许能在性能上有所优化。

![1617294-20190624084016206-100694192.png][]        ![1617294-20190624084107321-2077947805.png][]         ![1617294-20190624084131099-783971106.png][]

还可以提升的地方：

1.  在架构上，使用观察者模式；
2.  对于线程安全不要一股脑sychronized；
3.  SOLID设计原则，对于开闭原则理解不到位。

*  ##  第三单元 JML ##

这个单元的作业给我感触很深。JML规格让我对于工程化开发中的代码分工与架构抽象有了新的认识。我更好地理解了架构的意义。架构师是不用关心方法实现的，仅仅设计每一段代码的规格。同时，这样也保证能够更加方便地对代码进行测试。纵观前两单元的作业，我的程序在这方面做的很不好。

除了有关于规格的撰写，这一单元还对数据结构和算法有进一步要求。在这一点上我做的不是很好，因为从整体上来讲，我的程序就是一个“平面”，即类于类之间没有基本联系，只是传一些数据而已。并且，最后一次作业中的各种带权图算法，其实都可以用一个函数来解决，所以当时应该构造工厂模式。

![1617294-20190624103320919-1633708423.png][]               ![1617294-20190624103350666-1612317489.png][]

可以提升的地方：

1.  架构不够好，很混乱；
2.  类中存储过多属性，应该分别创建映射仓库；
3.  此单元代码好像没有体现出OO的本质，对于“对象”的观念不是很清晰。

*  ## 第四单元 UML ##

架构上是“树形”的结构，我在前文有所提及，所以这里不再赘述。

可以提升的地方：

1.  类之间关系清晰，但是内部很混乱；
2.  建立了各种映射关系，很容易出错。

# 四个单元中测试理解与实践的演进 #

--------------------

最开始时，测试在我心中还是“随机测试”的方式，即随便输入一些数据，自己计算结果并比对。随着作业次数的增多，我了解到了“白盒测试”和“黑盒测试”，并逐渐应用于实践之中。我会先进行白盒测试，对于某一些方法进行JMLUnit的白盒测试，之后进行压力测试、以及大数据随机测试

*  ## 第一单元 表达式求导 ##

此单元我还是不会很测试，大概只以枚举法测了一下很基本的东西，并结合各种内容构造复杂数据。

![1617294-20190624104508184-1855419323.png][]                       ![1617294-20190624104545042-1238493961.png][]

但是这样会导致漏掉许多错误场景，比如我一直没有认识到的sin(x)+(x)，我的正则表达式会导致WF。

*  ##  第二单元 电梯 ##

这个单元我已经使用了“黑盒测试”和“白盒测试”，但是还没有像是三单元中那样分别对每个方法进行测试。我写了自己的评测机，会自动生成测试样例，所以测试还是挺充分的。但是第三次作业中由于评测机写的不是很充分，导致翻车事件。

自己写脚本的过程还是很开心的~

![1617294-20190624105417327-940279119.png][]

*  ## 第三单元 JML ##

在汲取了上一单元的翻车教训之后，我这次算是真正的测试充分了。我不仅对每一个方法进行测试，还采用了“交换语句”的方式。事实证明这样是明智的，我确实发现了有些很深的bug。

这次我也生成了一些随机数据，保证能够测试到各种情况。但是这次的数据还不能完全是随机的，所以还是有点难写！

我本着“测试是为了debug”的原则，构建了许多比较小的测试样例。

![1617294-20190624105655304-192034897.png][]

*  ## 第四单元 UML ##

说实话，这一单元的测试我有一点抓瞎。我不是一个很细致的人，所以导致对拍的时候别人经常能发现我想不到的测试点（菱形接口等）。感谢大家！所以我深深明白了测试不能单打独斗的道理。

这一单元我主要采用了“特殊测试”+“随机测试”的方式，构造让我想不到的场景，检验正确性。

![1617294-20190624110159970-1574807644.png][]

从枚举法到最后的有条有理地“生成”测试样例；从随机测试到最后重点测试，我自认为对于工程化测试有了一点理解。而且，一定要Group Test！陷于自己的惯性思维太可怕了！

# 课程收获 #

--------------------

*  ## 代码方面 ##

1.  初步了解了“对象”的思维方式。虽然还是会有对一个类“大杂烩”的情况，但每次我都尝试去解耦、精简方法。
2.  有了一定的架构能力，拿到题目的第一反应是“如何设计”而不是“如何算法”。还存在的一个问题是架构经常产生“头重脚轻”的情况，最后一层负责一切计算而上层起不到作用。
3.  学习了许多设计模式并去应用。不过有时候由于代码过于“女娲补天”，设计模式被摒弃了，这一点很不好。
4.  多线程编程时去思考冲突问题。回顾二单元的几个sychronized方法，我发现这一点还有待提高。

*  ## 测试与Debug方面 ##

1.  使用JML进行测试，分析“边缘”数据构造测试集。每次都从整体上把握程序的架构，分析出深层次BUG（比如上一单元总结中提到的只有特定运行顺序才会出现的bug）。
2.  每次尝试自己写评测机，工作量有时候有些大但是既能深刻研究指导书，又其乐无穷。
3.  学会了不printf的debug方法(O\_O)/，用电脑而不是使用人脑来调试。但是对于多线程场景调试能力还不是很好。
4.  帮助同学进行debug也能受益匪浅！

*  ## 心态方面 ##

1.  深入贯彻落实不到最后一刻不放弃的革命思想，在最后一小时发现bug还敢再交几次。
2.  阅读别人程序时越来越不容易崩溃，认真学习他人对于架构的设计。

![1617294-20190623085602982-56012130.png][]

为什么我代码量1200他只有800？？？

这学期的课程不算多也不算少，OO和OS占用了绝大多数的时间。同时，这两门硬件基础和编程基础的课程在我心中形成了强烈的对比，让我明白了这两门学科是什么，也有了自己的选择。相比于硬件，我发现我更喜欢OO。每一次作业我都能思考上一晚上，每次都考虑自己的收获而不是分数……感谢OO让我对未来的代码生活充满了憧憬！

# 课程改进建议 #

--------------------

1.  每次上机之前，希望早点发布上机内容的指导书，这样还能有所准备。真的被前几次上机折磨的够呛哈哈哈QAQ 
2.  希望形成“小组”的方式进行测试学习和架构学习，这样能更好地向优秀同学借鉴
3.  每次作业公布一下下一次的“拓展需求”，这样能有所准备

超喜欢OO课程和课程组！希望OO越来越好！

转载于:https://www.cnblogs.com/Wendy-Zheng/p/11071751.html

[1617294-20190623224650733-831537482.png]: https://img2018.cnblogs.com/blog/1617294/201906/1617294-20190623224650733-831537482.png
[1617294-20190623224803254-1298987166.png]: https://img2018.cnblogs.com/blog/1617294/201906/1617294-20190623224803254-1298987166.png
[1617294-20190623224851398-233849291.png]: /images/20211104/e1b6af0be3e745a3bdfcb705e60ff266.png
[1617294-20190623230907137-444294803.png]: https://img2018.cnblogs.com/blog/1617294/201906/1617294-20190623230907137-444294803.png
[1617294-20190623230956077-1003276570.png]: https://img2018.cnblogs.com/blog/1617294/201906/1617294-20190623230956077-1003276570.png
[1617294-20190623231028475-419024696.png]: /images/20211104/58ca51bbb1644c21b3a8718e2a61803c.png
[1617294-20190623231919008-407752634.png]: /images/20211104/ae67447b2a43492bb121013f558df82a.png
[1617294-20190624082945102-41035105.png]: /images/20211104/a0b1ee6d0f564f6b8372f73bfa814e9b.png
[1617294-20190624083042286-756043477.png]: /images/20211104/fb7ddd717fbd4460abde9965ca73e2da.png
[1617294-20190624105135943-465765231.png]: /images/20211104/5d42657f82574dc79e29059ac64539d2.png
[1617294-20190624084016206-100694192.png]: https://img2018.cnblogs.com/blog/1617294/201906/1617294-20190624084016206-100694192.png
[1617294-20190624084107321-2077947805.png]: https://img2018.cnblogs.com/blog/1617294/201906/1617294-20190624084107321-2077947805.png
[1617294-20190624084131099-783971106.png]: /images/20211104/1bc2d2ca426a4bf397e13500ce838f5b.png
[1617294-20190624103320919-1633708423.png]: https://img2018.cnblogs.com/blog/1617294/201906/1617294-20190624103320919-1633708423.png
[1617294-20190624103350666-1612317489.png]: /images/20211104/dfc8f52b32bb44bfa28a6bbc7c5e5b6c.png
[1617294-20190624104508184-1855419323.png]: https://img2018.cnblogs.com/blog/1617294/201906/1617294-20190624104508184-1855419323.png
[1617294-20190624104545042-1238493961.png]: /images/20211104/21e23c6478654953a2065935200f4f59.png
[1617294-20190624105417327-940279119.png]: /images/20211104/603f44737f9a49aaad6252ea7286bf7c.png
[1617294-20190624105655304-192034897.png]: /images/20211104/00d74acc256145df8e800e218eeff066.png
[1617294-20190624110159970-1574807644.png]: /images/20211104/f8846396f51240eaa96d9d8fc235dd8d.png
[1617294-20190623085602982-56012130.png]: /images/20211104/04c87578a2f84296a4de6110513105ac.png