301
社区成员
发帖
与我相关
我的任务
分享BUAA-OO-第四单元总结及课程总结
目录
一、本单元所实践的正向建模与开发
正向建模是一种自顶向下的建模方法，即从全局的角度出发，逐步细化到具体的功能和实现细节。而在本单元中，我们就通过正向建模的方法逐步搭建起了一个小型的图书管理系统。具体而言，正向建模可分为以下几步：
- 分析需求
正向建模的第一步是分析需求。本单元每次作业的指导书中给出的都是我们要实现的功能，也即实际的需求。这就需要我们先对需求进行分析，从而大致确定程序需要有哪些模块，每个模块该实现什么样的功能，以及模块之间如何协作以形成一个有机整体进而能够正确实现所要求的全部功能。
- 系统设计
分析完需求之后，我们就可以绘制UML图来进行进一步的系统设计了。首先可以画一个大致的类图，根据我们刚才分析出的模块创建类，每个模块可以对应一个类。然后根据具体的需求考虑一下每个类中应该有哪些属性和方法，以及类之间应该有哪些关系如依赖、关联等。除了类图之外还可以画状态图和顺序图，状态图用来描述对象在不同场景之下可能的状态转移，顺序图则用于展示系统中的各个活动以及它们之间的关系。通过绘制UML图，我们可以初步确定代码的框架，为之后的编写代码提供一个较为清晰的思路。
- 编写代码
最后就是编写代码了。在我们完成了UML建模之后，就可以根据之前建模设计的结果开始编写代码了。主要就是根据之前画的UML类图编写相应的Java类和方法。当然，在具体写代码的过程中，为了满足所要求的功能，我们可能会对之前的设计做出某些调整，这时我们就要对之前所画的UML图进行相应的修改，直到完成所有的代码编写。
当然，在写完代码之后，还要进行充分的测试与维护，以保证所建模型的正确性。
二、架构设计
由于本单元三次作业的代码架构大体上相似，所以这里只展示最后一次作业的代码架构。
UML类图如下：
Main类是整个代码架构的核心，它兼具读取输入和处理请求的功能，相当于整个图书馆，其中有借还处、书架、漂流角、预约处的实例各一个，以及一个学生的集合。
而借还处、书架、漂流角和预约处各自通过一个类来实现，分别对应Borrow类、BookShelf类、Corner类和Order类。其中借还处主要处理用户借书、还书的请求，预约处处理用户的预约请求，书架和漂流角则用于存放书籍，同时漂流角也可以接受用户捐献的图书。这四个类之间相互协作，共同构成了整个图书管理系统。
Student类则是用于表示去图书馆进行借书、还书等操作的用户，其中记录了用户所持有的书籍、信用积分以及拿到书的日期（用于判断还书时是否逾期）。
三、最终的代码设计和UML模型设计之间的追踪关系
1、类图一致性
最初的时候，我的类图中的类和方法均能在代码中有所体现，但随着要求的功能的增多以及绘制UML图时考虑细节的不周，我在代码中逐步添加了一些类图中刚开始没有的类的属性、方法等，并修改了一些原来的方法。而在写代码的同时，我也在不断修改我的UML类图，使我的类图一直与我的代码保持一致，因此我最终的代码设计和类图也是一致的。
2、状态图一致性
在写每次作业的时候，指导书中都已经比较明确地给出了书籍的状态转移路径，所以我每次作业中画的状态图都不需要改动，代码设计和状态图也能很好地保持一致。唯一变动的地方在于第二、三次作业在新加了一些功能之后需要先对上一次作业的状态图做一些补充。
3、顺序图一致性
顺序图和状态图类似，在写代码的过程中没有发生太多改动，只在后两次作业进行迭代开发的时候需要对前一次作业的顺序图修改一下，代码设计也随之修改。
四、四个单元中架构设计思维的演进
1、第一单元
- 模块化设计：第一单元中，我将表达式解析、表达式化简分为两个模块，这样可以将复杂的任务解耦为几个相对独立的部分，逻辑上更为清晰，也降低了代码实现的难度，符合高内聚、低耦合的思想。
- 抽象思维：在设计的过程中，我把表达式、项、因子各自抽象为了一个类，以便于表达式解析功能的实现。
2、第二单元
第二单元需要考虑的主要是多线程的并发。首先用到的是层次化设计，即将输入请求的处理、电梯的调度以及电梯的运行分离开来，封装为几个不同的类，形成一个类似于流水线的架构。在这个过程中可以利用生产者-消费者模式、工厂模式等来组织代码，将各部分联系起来。
另一个需要考虑的点就是线程安全问题，这也是本单元不同于其他单元的一个地方。我们要合理利用synchronized等机制来防止数据竞争访问和修改，同时还要考虑到可能发生的死锁并加以避免。
3、第三单元
第三单元主要是对JML语言的理解。因为JML已经给出了详细的规格说明，所以本单元的代码架构不需要自己设计，只需要按照JML进行实现即可。本单元一个主要的思想是规格与实现分离，利用JML描述规格以提高代码的可扩展性和可维护性。
4、第四单元
- 面向对象：第四单元比较好地体现了面向对象设计的思维，根据图书管理系统的功能将借还处、预约处、书架等分别用一个类实现，各个类之间在完成自己的功能的同时又相互协作，共同构成一个有机整体。
- 正向建模：本单元要求我们利用UML图进行正向的建模开发，我在写代码之前先绘制了UML的类图，形成了一个初步的架构，之后在具体实现的时候再做出适当的调整，从而形成了最终的代码架构。
总而言之，通过这四个单元的学习，我的架构设计思维逐步成熟，对面向对象编程的理解也更加深入。
五、四个单元中测试思维的演进
对于测试思维，我在本学期四个单元的测试中主要采用的是评测机测试的方法，因为评测机能够自动生成大量随机数据，可以覆盖比较多的情况，此外对于压力测试也有一定的效果。此外我也针对一些特殊情况进行了手动构造数据，用以补充测试评测机测不到的情况。
1、第一单元
- 测试思维的建立：虽然OO先导课中已经有了JUnit测试，但从第一单元开始我才真正意识到充分的测试对于编程的重要性。
- 特殊情况：在第一单元的测试中有些特殊情况评测机很难覆盖到，需要手动构造，比如一些边界数据等。
2、第二单元
- 线程安全测试：多线程并发中线程安全是一个很重要的点，也是一个比较容易出错的点，所以本单元的测试的侧重点之一便是检查各种情况下线程是否安全。
- 死锁检测：死锁也是本单元中一个比较令人头疼的点。由于多线程并发的随机性，一种出现死锁的情况很难复现，因此需要大量的测试。
- 性能：本单元的性能分是四个单元中最难拿高分的，因为事实上没有一种真正完美的电梯调度和运行策略。所以这个单元我在检测电梯的运行性能方面做了比较多的测试，主要就是想出各种比较极端的情况比如所有的人都从1楼到11楼这种来对不同策略下的乘客等待时间、耗电量等进行比较，以选出能在大多数情况下相对最佳的策略。
3、第三单元
- JUnit测试：第三单元我主要用JUnit测试来对方法是否符合JML规格进行检测。
- 压力测试：本单元的作业由于设计到一些图的算法，因此不同的写法的时间复杂度有很大差别，所以在数据规模较大时程序可能出现运行时间过长的情况。对此我采取了压力测试来检验数据量较大时程序的算法是否能够满足时间要求。
4、第四单元
- 模型验证：第四单元主要考察的是我们的正向建模与开发能力，因此写完代码之后要检验自己的代码设计与UML模型设计是否一致，中测当中也有相应的测试点。至于数据的话，本单元的逻辑比较清晰，各部分功能也很明确，因此通过评测机就可以很好地检验程序的正确性了。
总体而言，在这四个单元中，我对于代码的测试思维从最开始的只关注代码正确性到逐渐开始关注代码的性能、鲁棒性等方面，对代码的测试也越来越全面。我觉得这种测试思维对于我检验代码的正确性有很大的帮助。
六、课程收获
经历了12次代码作业、8次实验和4次博客作业之后，OO课程终于迎来了尾声。回顾这一个学期的OO课，我相比于学期开始时收获了很多东西：
- 面向对象的思维方式
OO课本身的名字就是“面向对象设计与构造”，所以面向对象编程的思维模式是贯穿始终的。面向对象思维把相关的数据和方法组织为一个整体来看待，从更高的层次来进行系统建模，更贴近事物的自然运行模式。OO课的学习很好地培养了我的面向对象思维，让我明白了与面向过程不同的另一种解决问题的思路。
- Java语言
从OO先导课到OO正课，我从对Java一无所知到能够较为熟练地用Java写程序，OO课让我又掌握了一门语言。
- 多线程并发
第二单元的多线程并发我觉得是整个学期中最难的一部分，但经过那一个单元的历练， 我对线程安全、锁机制等有了更深入的了解，也明白了避免死锁的一些方法。
- 代码测试
OO课的中测、强测、互测让我深刻明白了测试的重要性，不管是黑箱测试、白箱测试还是JUnit测试，都对于检测出代码的设计漏洞有很大帮助。随着代码规模不断增大、代码逻辑越来越复杂，单凭检查代码逻辑就能保证正确性也越来越难，这个时候充分的测试就显得尤为重要，是我们进行编程的有力辅助。
- 抗压能力和毅力
整体而言，OO课作业还是有难度的，无论是代码量还是代码逻辑上，尤其是第一单元和第二单元，这对我们的抗压能力和坚持不懈的毅力无疑是一个考验。
当然，除了以上几点之外，OO课带给我的收获还有很多，比如抽象能力、架构设计思维、JML语言以及UML图的绘制方法等。相信这一学期的学习将为我日后的工作和学习打下坚实的基础。
总的来说，我觉得OO课确实配得上“昆仑课程”的称号。最后，我想感谢各位老师和各位助教一学期以来的辛苦付出，为我们成功完成各次作业提供了保障。祝OO越来越好！
...全文
请发表友善的回复…
发表回复
