BUAA OO Unit4 单元总结

[丁宇城-23371414]

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

本单元我们实践的 正向建模 是一种典型的 模型驱动开发 方法。它遵循“先设计，后编码”的原则，强调在编写代码之前，先通过UML等建模语言构建起系统的静态结构和动态行为模型。

在图书馆管理系统的开发过程中，我们的实践步骤如下：

1. 需求分析与概念建模: 首先，我们分析了图书馆管理系统的核心业务需求，例如用户管理、图书管理、借阅和归还流程等。基于这些需求，我们识别出系统中的核心实体，如用户 (User)、图书 (Book)、 阅读处 (ReadingRoom)，为后续的详细设计奠定基础。

2. 静态结构设计: 我们使用 UML类图 (Class Diagram) 来定义系统的静态蓝图。

   • 定义类与属性: 我们将识别出的核心实体设计为具体的类，并为每个类定义了必要的属性（如 Book 的 isbn等）。

   • 定义操作: 为每个类设计了其应有的行为或职责，即方法（如 User 的 getBook(), removeBook()）。

   • 定义关系: 明确了类与类之间的关系，例如 User 和 Book 之间存在“借阅”的 关联关系。

3. 动态行为设计: 在静态结构的基础上，我们进一步设计了系统的动态交互和对象生命周期。

   • 顺序图 (Sequence Diagram): 我们针对具体的业务场景，如“用户预约”，绘制了顺序图。它清晰地展示了用户、系统界面、控制器、服务及数据对象之间的 消息传递和交互顺序，直观地体现了 orderBook() 这个操作背后复杂的调用流程。

   • 状态图 (State Diagram): 我们为具有明确生命周期的对象（主要是 图书 Book）绘制了状态图。它描述了一本图书可能经历的各种状态（如 “bs”、“user”、“hbs”），以及触发状态转换的事件（如 borrowBook() 事件使状态从 bs/hbs 变为 user）。

4. 编码实现: 最后，我们将UML模型作为开发的 指导蓝图，将其转化为实际的编程代码。类图直接映射为程序中的 class 定义，顺序图指导了方法内部的逻辑实现，而状态图则帮助我们用枚举 (enum) 或状态模式来管理对象的生命周期。

总结来说，正向建模让我们在动手编码前，对整个系统的架构、组件职责和交互流程有了宏观且清晰的认识。这种方式有助于 降低开发风险、提高代码质量、促进团队沟通，并使最终的系统结构更加合理和易于维护。

在本次作业中，我的类图和状态图如下：

 

代码设计和UML模型设计之间的追踪关系

本次作业的代码设计如上图的UML类图所示。

1. 最终的代码实现与UML模型设计之间存在着清晰且紧密的追踪关系，这种关系贯穿了系统的静态结构和动态行为。

   • 在静态结构层面，UML类图得到了精确的映射。UML中定义的核心实体，如Book，在代码中被直接实现为public class Book 。类图中的属性，例如Book的ID，在代码中体现为private final LibraryBookId bookId;这样的成员变量。

   • 在动态行为层面，UML顺序图和状态图的交互流程在代码的方法调用链中得到了完整体现。一本图书的核心状态，在代码中由Book类的一个成员变量private LibraryBookState state;来表示。状态图中的“事件”则对应于代码中的具体操作。当一个事件发生时，例如成功执行borrowBook操作，代码会通过调用book.setState(today, LibraryBookState.USER);来触发状态的迁移。

2. 尽管UML模型为代码实现提供了坚实的蓝图，但在实际编码中，最终代码与初始UML设计往往存在一些合理的偏差：

   • 新增辅助类与方法: 在编码时，我们可能会发现一些UML中未预料到的辅助功能，这些通常是实现细节，不会在高级别的设计模型中出现。

   • 实现的具体化: UML中的关联关系在代码中可能有多种实现方式（如使用 ArrayList, HashMap, ），具体选择取决于性能和查询需求，这是在编码阶段进行的优化。

   • 设计的重构: 在实现过程中，可能会发现初始设计中的某些部分过于复杂或不必要，从而进行简化，或者设计初期没有预料到具体实现过程出现的复杂问题，例如为了通过checkstyle需要强行增加方法。

总结来说，UML模型是指导开发的 “建筑图纸”，而最终代码是根据图纸建造并加入了具体装修和施工细节的 “实体建筑”。两者之间存在着从抽象到具体的清晰追踪路径，同时也允许在实现层面上进行必要的微调和优化。这种追踪关系确保了软件开发过程的规范性和最终产品与设计目标的一致性。

大模型使用体验

1. 使用大模型辅助设计时，我深刻体会到提示（Prompt）的详尽性至关重要。我不能简单地抛出一个模糊的想法，而是需要将我的设计意图、关键需求和约束条件都清晰地描述出来。只有当我提供了足够详细的上下文，大模型才能准确理解我的需求，并给出高质量、符合预期的输出。这更像是在给一个能力很强的助手分配一个明确的任务，而不是在进行一次开放式的头脑风暴。

2. 我发现大模型并不适合从零开始构思一个复杂的系统架构，这项工作更适合由自己来完成。它的真正优势在于，当我提供了一个清晰的整体框架后，它能极快地完成细节内容的填充和实现。我负责搭建系统的“骨架”，比如划分模块和定义核心类的职责，然后引导大模型来丰富“血肉”。如果我把整个设计任务一股脑地丢给它，生成的代码常常是“高耦合，低内聚”的。

课程总结和收获

1. 架构设计思维

   在前两个单元，项目的整体框架更侧重于考察我独立建模和搭建的能力。在第一单元的表达式化简任务中，我投入了大量精力预先思考各种可能的情景，并为自己定下了一条严格的设计规矩：遵循清晰的递归下降逻辑，绝不进行跨层次操作。例如，Express层只能调用Term层的方法，而不能绕过Term去间接操作Factor。虽然这让我的第一次作业实现得颇为辛苦，但这份前期的谨慎换来了后续迭代中无与伦比的逻辑清晰度，每次的功能扩展都感觉更加得心应手。同样，在第二单元的电梯调度中，我也花了大量时间去构思整体框架，仔细辨别每一个共享对象，谨慎地为它们加上锁。正是在这个过程中，我才真正深刻地体会到了“高内聚、低耦合”等设计原则为程序带来的巨大好处，它让第二单元中复杂的线程交互变得清晰可控。

   相比之下，第三和第四单元虽然主题就是架构设计，但得益于前期的密集训练和题目中给出的充足提示，我在搭建框架时反而感觉轻松了不少。这并不只是因为挑战变小了，更是因为我已将前两个单元中艰难摸索出的设计原则内化于心。当面对UML建模任务时，我能够迅速地将模型映射到健壮的代码结构上，因为那些关于分层、解耦和并发控制的思考已经成为了一种本能。可以说，正是前两个单元打下的坚实基础，才让我在后两个单元中能够游刃有余，能更快地聚焦于从更高的设计视角去理解和应用架构模式。

2. 测试思维

   除了需要交互性的第四单元，其余三个单元我都搭建了测评机。

   在第一单元表达式化简中，我基于Python的sympy库实现了测评，它能高效检验逻辑等价性，但对于括号匹配这类语法问题却无能为力。到了第二单元的电梯调度，我转而采用输入输出对比的方式，并用多线程加速，这确实帮我找出了许多并发错误，可我也明白，它终究无法穷尽所有复杂的时序问题。第三单元由于输出固定，“对拍”成了最直接有效的方法，但它也让我意识到一个有趣的局限——它无法发现我和同学们代码中可能存在的、因共同思维误区导致的“共性错误”（虽然不太可能出现）。

   这段经历让我确信，测评机并非万能的银色子弹。随机数据在进行压力测试时很有效，却难以覆盖所有刁钻的边界样例，而且测评机本身也可能存在BUG。因此，自动化的压力测试必须与我们自己动手构造的、针对性强的特殊数据点相结合，才能真正有效地保障程序的健壮性。

3. 课程收获

   时间过得很快，现在已经要结课了。回想这门面向对象程序设计（OO）课程，我的实际体验与之前学长学姐口中的“恐怖”印象大相径庭。我发现，成功的关键在于打开IDE动手编码前，愿意投入足够的时间去思考和设计。只要前期思考得足够充分，实际的代码编写过程就会异常顺利。至少对我个人而言，OO课并没有像传闻中那样，需要耗费我海量的课后时间。

   其实，我对代码整体框架的执着由来已久。从大一学习C语言时起，我就有意识地抛弃冗长的main函数，主动去追求更好的代码结构与可读性。而OO课程，则是在这个基础上，以一种系统化的方式，要求我不断地去优化和打磨自己的代码框架，这正与我的追求不谋而合。

   这门课程在我身上留下的印记，早已超越了编程技艺的提升。它让我真正触摸到了“程序设计”的灵魂。这个曾经抽象的词语，在我眼前化作了可以精心构建的实体。更重要的是，课程以恰到好处的压力，锻造着我的耐心，拓宽着我能力的边界，让我一次又一次征服那些过去连仰望都觉得奢侈的复杂任务。如今，当我再次伫立于一个大项目的起点时，心中涌起的不再是面对未知的恐惧与退缩，而是一种沉静的自信，和一份从容的耐心。