OO第四单元博客总结

OO第四单元博客总结

一、正向建模与开发总结

本单元中，我们分别运用了UML类图、状态图、消息图来对代码的框架结构进行建模，取得了非常理想的效果。UML图使我们在编程之前就能构建好简明的代码框架，并且易于和同学讨论和改进框架的结构，使其更符合SOLID原则。对于类图来说，可以提前规划好每个类所需要实现的任务和存储的数据，并且在类之间建立继承、组合、聚合等关系，使代码的构建更符实际情况，并且有清晰的架构可以进行讨论。对于状态图，可以针对要实现任务中的某一个状态改变量，设计其状态转移路径，避免实现代码时出现状态死锁的问题，可以动态地表示抽象状态的转移过程。对于消息图，更多的是从代码实现的角度着手，探讨不同对象间的通讯和生命周期的创建、撤销之间的联系，从而帮助我们更科学的设计进程间通讯的逻辑，减少不必要的中间层，并且保证收信息方可以为所有收到的信息建立处理方法。

总而言之，本单元通过正向开发，规避了很多设计中的问题，使得代码的实现更加的简介和迅速，避免了代码后期进行大量的重构和修改，提高了编写代码的效率和科学性、透明性。

二、架构设计总结，最终的代码设计和UML模型设计之间的追踪关系的对比分析

关于架构设计，本单元代码的UML类图如下：

在架构的设计上，着重遵守SOLID原则。

1. 使每一个类有其单一职责：例如借还处、预约处、漂流角、书架和登记处的分工各有不同，通过对象间的信息交互动态地实现较为复杂的功能。

2. 架构的设计满足开闭原则：当增加办事机构时，只需要在library的组合中增加实现相应的类，而不需要改动其他的类，体现了对扩展开放。增加机构之间的通讯方式时，也只需要在相应类的内部实现信息通讯方法体现了对修改封闭。

3. 满足里氏替换原则。本单元中未用到继承关系，因此自动满足。

4. 满足接口隔离原则。本单元中未用到接口，因此自动满足。

5. 满足依赖倒置原则。即抽象不应该依赖于具体实现，具体实现应该依赖于抽象。本单元中，library作为借还处、预约处的统筹单元，同时负责给员工staff提供活动信息，其实现并不依赖于具体的借还处、员工的实现细节，而是只需要将信息发送给他们即可，后续由员工、借还处自行处理。

关于最终的代码设计和UML模型设计之间的追踪关系，我在依据UML构建代码的过程中，发现了很多新的需要实现的方法需求，其虽不能直接实现某些功能，却是这些功能实现时必不可少的需求，例如对库存书信息的查找、判断用户是否重复借书等等，作为对UML方法的补充，往往需要在实际编程时才能发现。此外，JAVA的一些语言特性也会使实际编程对UML有一定影响。

三、四个单元中架构设计思维的演进总结

Unit1：表达式解析

编码时只知道一个大概的框架和递归下降的算法，具体的算法和实现都是在编写代码的过程中间完成的。其中涉及到的边界条件非常多且杂，非常难以整理成文件类的信息直接表述，因此大概是一边写，一边设计，一边测试正确性来调整后续写的思路。

这样的结果就是以后每次迭代都会增加系统的复杂性和耦合性，使得系统难以扩展和维护。而且因为没有明确的框架结构，因此方法的实现会有多种选择的方式，导致代码东一块西一块，很难抓住重点，也很难抓住有BUG的点。

Unit2：电梯调度

编码比较贴合物理实际，在写代码之前已经知道需要有一个中央调度器、电梯类、输入输出类这样的框架结构，此后一切的实现都是基于这同一个框架，做到了开闭原则，因此代码比较好维护和扩展。但是过程中极容易出现死锁和状态转移问题。

现在分析来看，应该在实现电梯的调度算法前先规划好进程顺序图，规定信息传递的次序优先级从而确保不会产生死锁。

Unit3：社交关系网络

本单元是基于JML的代码实现，框架上没有富裕的发挥空间，只是在算法的复杂度上可以有较为灵活的改进，例如使用脏位，或修改时更新统计值等，技巧性比较强，实用性比较强，但架构设计上的考验比较少。

Unit4：图书管理系统

本单元主要考察框架设计，通过UML类图进行框架设计，解决了各个部门类之间的职责划分和组合关系的问题。此外，第二次作业中通过UML状态图设计，重点关注图书的所在状态，明确了图书的信息的变化原则，避免了图书状态的丢失或不可预料的错误。第三次作业中增加了顺序图的要求，体现了图书馆各个部门之间信息交流的方式，可以有效避免消息传递的死锁，避免了信息的丢失和误判。

四、四个单元中测试思维的演进总结

Unit1：表达式解析

主要是用随机生成的表达式进行测试，因为边界问题太多，很难从代码出发找到合适的测试样例，因此测试非常盲目，无效测试很多。

Unit2：电梯调度

由于题目接近实际情况，所以可以从实际生活中的极限情况出发，看是否会发生状态死锁或者无意义的空转。比如某个方向突然涌入多个乘客、超载测试、携带测试等。然而由于在第一次作业和第二次作业中使用了随机调度的方式，因此测试出的错误很难复现，只能从单一测试样例中进行错误推断。第三次作业中使用了评分系统规避了这一点，使得相同输入下会有确定的输出，从而实现了错误的修改反馈。此时可以使用随机生成样例来进行程序的正确性测试以及性能测试。

Unit3：社交关系网络

本单元中首次使用了单元测试的方法。通过对每一个方法构建测试用例和assert语句进行判断，可以明确具体是哪一个方法出现问题。具体测试上，本人使用了“随机生成社交网络”+“参数化测试”的方法，通过大量的随机测试来检验对JML所述方法进行性能改进之后的方法是否是和JML的经典方法等价。此外，本单元还可以从整体出发，构建各种特殊行为组合起来的测试样例，也帮我找出了不少问题。

Unit4：图书管理系统

本单元的行为和测试均较为简单。具体可以参考图书状态的转移路径，使用穷举法覆盖测试图书的各个状态之间是否可以按设计运行。此外还使用了随机测试的方法，可以测试图书馆在大量图书交替执行的过程中是否会出现错误。同时也采用了极限测试，例如构造样例测试在归还图书的截止日期的当天是否会被记录为逾期等。总体而言，本单元因为架构设计较为清晰，很容易定位发生错误的位置和原因，因此测试所占精力并不大，更多的是设计上的耗时。

五、课程收获总结

经过四个单元的努力，OO终于圆满落幕。 经过前四个单元的开发，我们对面向对象思想的理解更加深刻，对JAVA语言也更加熟悉。同时对递归下降算法、JAVA多线程、自动化测试、JML模型语言，UML建模语言也都有了实践和了解。从面向对象的学习中，我们了解了在大型软件的设计、开发过程中，对模型结构有一个模式化、清晰简要的共识是多么重要。同时，健康的代码结构，SOLID原则、合适的代码模式对代码后继的维护、修改、迭代的潜力有着深刻的影响。需要辩证地看待敏捷开发和架构设计的关系。使代码能够在良好的框架下构建和迭代是面向对象思想最终要实现的目标。