BUAA-OO第四单元及课程总结

OO课程总结

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

类图

• 需要利用StarUml来实现类图
• 根据类图实现图书馆管理系统
• 微调类图使其符合自己的代码架构

这次作业的总体思路基本按照课程组给出的思路来完成。不过在使用StarUml的过程中我发现这个软件的调整非常复杂而且细节繁多，而且由于第一次作业是从无到有的过程，很难做到类图建模和自己的实现完全一致。因此我选择首先搭建大体框架而放弃细枝末节的堆砌，在代码完成后再进行细节的完善。即使如此，我搭建的框架也和我最终的实现不一致，比如最初的Book类只打算承担书籍的作用，但最后的实现更像是一个BookLog，即书籍日志的作用，用来记载相关借阅或者预订信息。
第一次作业的详细类图如下
后面的类图只是在这个类图的基础上添加一些方法和属性，故不赘述

状态图

要求我们展示出书籍的状态转换，感觉在这次作业中状态转换完全可以用地点表示，分别用BookShelf、User、AO、BRO、BDC来表示书记状态即可。但是感觉状态图转换是为了让我们更加清楚地理解图书的流转以及目前所处的状态，与正向开发的关系并不是很大

本单元架构设计

本单元的架构较为简单，我相信很多同学的架构都和我大差不差，总体上也没有很大的改变

• Main类用于处理输入，将所有的请求传入Library
• Library类只有一个实例，负责实例化各个部门以及管理书架和用户列表，负责分析指令并将指令分发给各个部门
• CirculationDesk、ReservationDesk、BookDriftCorner分别是借还台、预约台以及图书漂流角，实际作为Library类的各个部门，用来处理相关的预约和借还业务
• Book类，实际应该是BookLog类，充当书籍日志的作用，记载书籍当前状态以及借还日期等书籍日志信息
• User类，用于实现用户类，用户可以发出各种请求与Library交互并且持有书籍

不足之处

• 感觉应该直接用一个用户面板类来管理所有用户而不是形成一个容器堆在图书馆中
• 各个部门的统一性不是很强，比如书籍的存在形式有时候是BookId,有时则是Book，导致在书写代码的时候容易出现混乱

OO课程的架构设计思维演进

• 第一单元教会了我们层次化设计的思想，如何将一个表达式拆分成不同的层次并对每个层次采取不一样的处理方法是我们要思考的。实际上当我们面临复杂度较高的工程时，这样的思想并不罕见，我们需要将问题拆分成各个层次，逐步去实现整个工程
• 第二单元则是多线程的设计方法。一个线程难以解决并发问题，因此多线程应运而生。在这里我们需要考虑的是如何设置临界区并且做好各个线程的互斥与同步设计，让多线程正确运转。这个单元也是重构次数最多的一次
• 第三单元是规格化设计。这一单元旨在教会我们规范化开发，让我们实现规格设计与实现分别进行
• 第四单元的具体架构如上

测试思维的演进

• 基础样例的测试
• 极限条件的测试
• 压力测试

课程收获

• 学到了很多专业知识，面向对象的思想以及项目开发的各种形式都有所涉猎
• 从不同的角度去看待一个项目，之前可能是从底部向上看，现在逐渐学习了从顶部向下看
• 抗压能力有所增强，尤其是电梯月，反复打磨的代码还是被放在地上蹂躏，不断修改的过程也是不断进步的过程
• 团队合作意识逐渐增强。举例来说，在之前我们宿舍基本是各自为政，大家各忙各的，但是在oo这门课中我们学会了相互交流和相互勉励，每次讨论总能有一些新的启发与收获

最后感谢课程组老师和助教以及各位同学们的帮助，这一学期的oo课到此也就结束了，希望我们的oo课能够越来越好