BUAA_OO第四单元总结

BUAA_OO第四单元总结

---

一、本单元所实践的正向建模与开发

第一次作业

本单元的第一次作业，根据图书馆对不同地点书本的管理操作以及用户对图书馆的请求操作，我使用UML类图，从程序的需求出发，抽象出了图书馆程序中所包含的类；利用类图中的箭头分析接口与类的实现关系，父类与子类之间的继承关系，以及类与类之间的关联关系等，理清楚了功能类直接的合作流程与分层抽象关系；通过分析UML类图中的属性，我细化了不同类的接口，框定了程序的实现标准。

第二次作业

第二次作业，通过绘制UML状态图，我以书本的状态空间与状态变化条件为出发点进行建模，梳理清楚了书本整体上有哪些状态，以及状态之间的转移对应哪些操作与方法。

第三次作业

第三次作业，我绘制了UML顺序图，从顺序图的角度，识别书本预约和取书流程中的方法调用顺序，以及类的合作关系。

通过先建模的方式，我从程序的需求出发，由上到下，从抽象层到具体实现层，从层次、关系、接口多个角度进行了正向建模。

---

二、架构设计

本单元，我建立了业务类Dispatcher，用于接受命令并调用方法进行处理；建立了五个空间类，BookShelf类，AppointOffice类，BorrowReturnOffice类，HotBookShelf类，以及ReadingRoom类，分别实现图书馆五个空间响应的功能；建立了用户类User类，专门存储用户相关信息，提供用户对应的方法；建立了书本类Book类，存储书本操作的轨迹以及相关信息。

UML类图设计

UML类图的设计，由上到下，统摄了整个代码的设计。代码类与类图中的类相对应，代码类之间的关系与类图中类的关系一一对应，代码实现的方法接口与类图中的属性对应。

UML状态图设计

UML状态图的设计，建模了书本的状态空间，在代码中，书本的属性与其状态相对应，书本相关的方法则与状态转移条件对应。

UML顺序图设计

UML顺序图的设计，建模了书本预约和书本取的信息流动方向与类的合作关系。而在实际的代码设计中，相关的方法与顺序图中的消息相对应。

---

三、大模型辅助正向建模

初步评估

大模型的理解能力很强，不论是在OO课程中，还是在其他软件开发的过程中，

我都经常使用大模型去解析较长的代码（1000行），可以利用大模型快速地了解代码的结构与功能。同时，对于不太了解的代码库，大模型是很好的入门导师。深度学习、科学计算等等领域的代码库都有着各种各样的功能与用法，使用大模型可以快速了解与掌握。

但是在具体代码编写过程中，尤其是千行级别的代码开发，很少使用大模型辅助设计。如果存在使用大模型生成代码的情景，也只能由自己占据开发主体,加速简单代码开发。

为什么？

问题

大模型的生成能力确实很强，但是在如软件开发这种对可靠性要求极高的情景中，大模型难以独当一面。

可能的解决办法

成熟的prompt格式，以标准化的方式描述清楚需求，描述清楚模块的功能与接口。

控制单次代码生成长度，每次生成都对代码进行检查，在确保正确性后进行迭代。

由人来设计代码架构，指定代码功能，只让大模型按照要求做事情。

可行性高，但效率还有提升空间。计算机专业能做什么？

启发

目前有研究让大模型自行生成有关自身推理信息的代码，利用生成的代码评估推理质量，检验正确性。

代码，或者是规格化语言，可以精准地表述信息，提供了自动化测试的可能，为自动化生成代码流程提供准确性保障。

一种设想

假设，我们的软件需求存在规格化语言描述，例如，JML语言描述。

可以设计一种自动化软件，通过调用大模型，输入JML语言描述的模块，以模块为单位进行代码生成，且对于生成的代码进行JML自动化测试。由方法到类，逐级向上，从而利用大模型自动化生成可靠的软件。

在OO课程的第三单元，这种方法是可以尝试的。

问题的关键在于，需要一种依赖于规则的中间层语言，既能描述需求，又能表征检测途径。倘若没有怎么办？也许可以更进一步，让大模型生成中间层语言，描述自己理解到的需求，再使用大模型的中间层语言，指导代码生成和自动化测试……

---

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

第一单元 类的提炼 层次设计

第一次作业，在确立架构上我花费了大量的精力，表达式的处理这一任务，第一眼看上去很简单，但是细想会发现有很多很多要考虑的步骤，高度相关,我总结出如下经验:

对于一项任务，可以将其分解为若干项独立的步骤，并针对这些步骤设立相应的功能类。这是在从功能角度解耦程序复杂度。

对于同一对象，其在处理过程中会有不同的结构类型，如语法结构、展开结构，可以针对不同的结构设立相应的结构类。这是在从结构角度解耦程序复杂度。

不同步骤和不同结构之间存在转化关系，可以识别出转化操作，并实现相应操作类。

分层抽象，使得不同的数据类型可以通过一致的处理流程进行处理，也使得数据处理流程层次化，各层只需实现特定的功能。

高内聚低耦合，模块化设计，提高了系统的可扩展性,降低了程序设计的复杂度。

第二单元 多线程编程

初次接触的时候，非常不适应多线程编程。增加了过多的线程类，追求过于精确的控制与策略，导致初始的系统设计非常混乱。

然后开始以生产者消费者模式为出发点，把握线程类之间的交互关系；同时以共享对象为锚点，设置同步语句和锁。

在把握了多线程编程的特点之后，继续沿用第一单元的架构设计经验，便能设计出较好的多线程架构。

在第二单元三次作业中，进行了大量的迭代，乘客请求的格式出现了变化，请求的类型出现了变化，电梯的结构也出现了变化。可以看到，对于电梯调度算法，它所面向的请求类型以及电梯的结构属性都会发生变化。

但是电梯调度算法也存在稳定的内容，就是生产者消费者模式。不同线程之间通过共享对象进行联系，为了保证共享对象的线程安全性，则需要加锁以及同步方法进行处理。这是多线程架构自身带有的特性。

同时，虽然请求类型以及电梯结构在不断变化，但是电梯调度算法的整体流程是不会变化的，具体来说，就是请求读入-请求调度-请求决策-操作执行的整体模式不会变，使得业务类的整体层次不会变。这是业务逻辑的特性。

第三单元 架构与正确性

第三单元的程序，由JML语言建模，架构设计其实并不由自己决定，可以高度依赖JML语言编写程序。

但想要避免错误率，在检查代码编写情况，以及测试的时候仍然需要充分了解程序架构。

可以从程序架构中更充分地了解程序面向的需求，在检查和测试代码时能更有针对性

第四单元 架构的视图

第四单元，UML语言，充分体验了先设计架构，再按照架构编写代码的流程和优势。或许，不仅于此？

更好的模式是，用UML语言首先简洁地描述整体架构，不必细化至接口和方法的参数，只需画出骨架。然后在后续实际的代码开发中细化具体的细节，并及时地修改整体架构上的问题，形成一个高效的反馈系统，与敏捷开发的原则相吻合。

---

五、测试思维的演进

在OO课程中，我的测试思维经历了四个阶段的演进。

第一阶段 测试机暴力评测

特点：没有针对性地进行数据构造，评测依赖于
海量平凡数据地测试，依靠数量来弥补质量。

结果：第一课顺利通过，其实并没有发现什么bug,最大的作用是提升自信心。

反思：对于评测机有了过高依赖，产生了有评测机，就可以在编码时更追求速度的错误想法。

第二阶段 血的教训

特点：过度依赖评测机，没有花足够时间理清代码
架构，大量时间用于编写评测机。

结果：出现了代码架构的明显漏洞，同时评测机花
费过多时间，bug未能及时修复，扣分。

反思：评测机只是辅助测试手段，正确的分层抽象架构是代码正确性的根基，不可本末倒置。

第三阶段 评测策略的提升

特点：极大地关注代码设计与编写质量本身；在此基础上，评测机不再依赖暴力测试，而是经过对易错点的分析，自动构造；同时对数据类型进行分类，由数量覆盖转向问题情景覆盖。

结果：在第二单元从代码设计之初降低错误风险，并利用针对性的构造数据有效地发现了bug。

反思：完善的评测机在框架，数据构造，正确性检验上需要较多的时间进行开发，开发压力大。

第四阶段 模块化与合作

特点：评测机可以分为数据生成器、正确性检验、上层评测框架三个相对独立的模块。和同学设定好接口与分工，合作开发评测机。

结果：极大地减少了评测机开发的时间压力，且不同模块的设计时间增大，质量提升。

反思：合作的力量，敲代码不要反复造轮子。

测试思维总结

从软件开发完整流程看测试：

评测机应该为辅，不是软件质量的绝对因素，在软件开发前的架构设计，软件开发中的原则与编码质量，都对软件质量有着重要影响；另一方面，测试极为重要，仅仅靠分析代码不能发现所有bug,测试是软件质量的最后保障。

从具体测试方法看测试：

评测机是测试很好的自动化工具，开发评测机时也应该遵循面向对象等软件开发的思想，模块化，抽象分层，提高评测机的可靠性，可扩展性，易于合作；同时测试的数据质量非常重要，可以采用常量池等技巧，针对代码的需求情景针对性地构造数据，数据量背后是对不同应用场景的覆盖。

从JML看测试

代码编写，是在以具体需求为导向，从无到有，由内向外构建起软件工程的正向过程；测试，则是根据规则，由外向内审视软件的逆向过程。

JML语言既体现了软件开发的具体需求，也体现了软件需要符合的规则，作为一种桥梁，表征了自动化测试的可能？ >>> OpenJML

在构造测试数据的时候可以发现，代码设计和代码测试其实在以不一样的方式审视软件的需求，走的却是相似的路径。

---

六、课程收获

本学期的OO课程中，我收获颇丰。

我学习了面向对象思想，学会以对象的角度思考问题。java作为一种强制面向对象语言，其逻辑和功能表征着一种看待软件，乃至看待事物关系的一种视角和哲学。

我学习了模块化封装思想，通过设计高效的抽象分层架构，遵循高内聚、低耦合的思想，便可以有效地控制程序的整体复杂度，并极大地增大程序的可扩展性。

我还学习了多线程编程，掌握了生产者消费者模式，学会以共享对象为中心设置同步锁，以实现异步操作的正确性。

在JML语言的学习中，我深刻体会到了代码功能与代码测试之间的紧密联系关系，并深入了解了标准建模语言对于代码描述的精确功能；而在UML的学习中，我体验了先用UML建模代码架构与功能，再进行代码具体开发的正向建模与开发过程。

最后，我还熟练掌握了迭代思想，尝试使用了瀑布模型和敏捷模型，实现了代码对于不同功能的快速开发与验证。