301
社区成员
发帖
与我相关
我的任务
分享2024 OO Unit4
2024 OO Unit4
Unit4 正向建模与开发
本单元训练的内容是正向建模与开发，具体来说是先用设计出基本的程序架构，再画出UML图，然后再去具体代码实现，最后比对设计与实现，进行调整与优化。
这样做和前面单元要求的最大差别在于，用UML将设计进行了具体落实，并对UML图和实现进行一致性检验。并不是说之前的单元就不进行架构设计，看完指导书就立刻开始写，而是说在设计与实现的过程中，使用UML(Unified Modeling Language)对设计架构的描述进行结构化展示，使得程序的设计对其他人可见，易懂，规则清晰。
本单元涉及了三种UML图，分别是类图、状态图和顺序图。类图中会展示程序所涉及的各个类的属性、函数、接口，以及类之间的相互协作关系。状态图中会展示关键的类在其生命周期中的状态变化，表述一个类从创建开始，在Trigger触发时判断Guard是否满足，并标注状态转移前后的影响。顺序图着重展示类与类之间为实现一个动作功能而进行消息传递的流程，展示在类的Lifeline之间是如何进行数据沟通处理，从而可以对功能执行的过程有清晰的认知。
虽然前期的设计和画UML图可以有效描绘出程序的基本架构，减少代码实现过程中的困难与迷茫，但是只要是设计就会有不足，就会有没有考虑到的盲点。在代码实现的过程中如果突然感到无从下手，无法在设计中找到对应的板块，就说明当初设计的时候出现了偏差与疏漏。这时就要重新考虑架构与实现，既可以修改架构后变更实现，也可以在一些简单的情况下直接实现，再回头修改架构。总之，在实现和架构之间还需要磨合，但是唯独不能让架构与实现之间缺乏关联，各行其是。
Unit4 架构设计与UML
本单元模拟图书馆管理系统，所以我首先构建了一个主体 Library 类，用于连接沟通其他的类，并提供给 MainClss 类处理的函数与调用。
接着我提取出指导书中提及的图书馆内的各个板块，分别建立了书架 BookShelf 类，借还处 BorrowReturnOffice 类，预约处 AppointmentOffice 类，图书漂流角 BookDriftCorner 类，以及用户 User 类。严格来说，用户并不是图书馆的组成部分，但是可以认为书的借出还回是将书移动到了用户处，将用户作为图书馆的一部分处理在逻辑和实操中会更加合适。
考虑到图书馆的各个部分都需要储存书籍，并且需要具有一定的扩展性与灵活性，所以我选择专门构建一系列描述书的类，还有预约订单的类。这些类包括书的集合 BookCollection 类，描述书籍的 Book 类，以及描述副本的 Copy 类。这里我考虑到一类书的多个副本可能会有差异，就专门构建了该类。此外为了方便描述预约处的订单，还构建了 Orders 类和 Order 类。
面对图书馆需要处理的需求，我的思路是对每一个需求都创建一个类专门用于处理。这个类内部会将该功能所涉及的部门作为属性存储起来，并调用这些类对外暴露出的函数接口进行功能实现。这样就构建出从 Library 类到中间处理类再到各个部门的调用次序。这样做的优点是代码按照功能封装在相应的类中，阅读与修改都很方便，但缺点是每次增加新功能都需要扩展新的类，相应地修改UML图会比较麻烦。
最后，基本上我的代码实现几乎完全贴合最初的设计与UML，主要的改动出在两个问题上。一是面对功能扩展，不得不新增类，在已有的类中增加新的函数。二是在实现一些比较复杂的功能时，需要查询类内部的信息再做出动作，此时需要修改储存结构进行一定的优化，还需要新增一些查询函数返回类内部信息。
架构设计思维演进
Unit1
第一单元中面对表达式化简的功能需求，我根据指导书的建议选择了递归下降的解析思路，相对应的选择了与输入语法规则一致的层次化架构设计，从底向上进行类架构设计，从输入中提取出表达式的组成结构，构建出一棵语法树AST，然后再对该书进行递归处理。通过层次化设计，各个类各司其职，通过递归调用关系联系在一起，大大简化了设计难度。
Unit2
第二单元模拟多线程电梯运行，我根据指导书与老师上课时的提示，采取了输入-主控-电梯控制的三层转包控制模式，使用生产者消费者模式，并在两两之间采用共享类进行线程同步。在设计的过程中需要仔细考虑线程同步问题，因而采用了模块化设计，严格区分临界区代码与一般代码，还使用了有限状态机规范电梯的状态，尽量减少对并发编程的干扰。
Unit3
第三单元模拟社交网络，给出了具体的JML规范让我们进行实现。本单元的架构设计要求不多，最重要的是严格遵守JML规范，该做的一定要做，不该做的一定不做，并在允许的空间内选择合适的数据结构与处理方式，降低复杂度与开销。
Unit4
第四单元模拟图书馆，要求先进行程序架构设计，再画出UML图，最后进行代码实现。本单元的架构设计较前面单元进一步细化，深入到UML类图、状态图与顺序图，要求进行更加细化的设计，深入到类的属性、函数的参数、类间的协作调用关系等。正向架构设计可以减轻代码实现时的负担，但是如果设计有误再进行更改就比较麻烦了。
测试思维演进
Unit 1
主要采取手动构造数据点的方法，主要关注一般数据、特殊数据、边界数据、混合数据，目的是在代码实现基本正确的假设上找出一些小的错误。这种方法相对耗时较少，测试力度也较小，主要还是依赖设计进行质量保证。
Unit 2
因为多线程需要定时输入，运行结果也是不可确定的，所以我借助了民间的评测机与数据生成器，主要使用随机数据检测我的代码。大多数测试检测的都是同步问题，死锁是最容易发现和定位的，而有时错误的同步并不会显现出来，只有概率触发，这就需要进行更全面大量的检测。
Unit 3
本单元的测试主要是随机生成数据，因为只要保证遵守了JML编写代码，就不会在正确性上出问题。但是后来发现在性能上也需要关注，所以需要构造一些边界压力数据，测试程序性能。
Unit 4
本单元因为关注设计架构，对性能要求放松，所以只需要测试数据覆盖基本功能，保证正确性即可。
课程收获
OO一共四个单元，其中前两个单元的压力最大，因为需要面对完全不熟悉的递归下降与多线程编程，这两者设计、测试、修改、改错都比较困难，而且是课程前期，不太熟悉，心理压力、时间压力和对编程技术的考验都比较大。后两个单元基本上实现的功能本身没有那么复杂，对课程各方面逐渐熟悉，压力就比较小了。
但是总体而言，一周中还是需要投入较多时间在OO课程上，区别是投入大半周时间还是小半周时间。OO课程内容覆盖了许多内容，让我在多个领域都接受了相应的训练，同时通过一定压力的迭代式开发提高了代码能力。
与此同时，我还学会了面向对象相关的一些知识，增强了我的设计架构能力。
在交流群与讨论区与同学、助教交流，或者看同学与助教交流，都帮助我打开思路，扩展思维，解决编程问题，提高设计的层次与审美，帮助我顺利完成了OO可成。在这里我要感谢老师和助教的付出。
...全文
请发表友善的回复…
发表回复
