BUAA OO Unit4

熊熙恺-23371265 2025-06-12 21:31:29

BUAA OO U4

本单元的核心训练目标是正向建模与开发，即“先设计，后编码”的软件工程实践。与前几个单元直接拿到需求就开始编码不同，本单元强制要求我们首先通过UML来构建系统的静态结构和动态行为模型，然后再根据这个设计蓝图进行代码实现。

但是实际开发困难重重，故我是先进行粗糙地建模，在建模完成编码过程中大体遵循之前的建模逻辑，并在开发完毕后对UML进行修改

整体代码从UML角度分析

需求分析：
首先，提取了系统中的核心实体。例如，用户(User)、图书(Book) 是基本实体。系统中的功能区域，如**普通书架(Bookshelf)、热门书架(Hot Bookshelf)、借还处(BorrowAndReturnOffice)、预约处(AppointmentOffice)、阅览室(ReadingRoom)**，也被抽象为关键的类。这些实体和它们之间的关系构成了最初的概念模型。
UML设计：
- 类图设计：基于概念模型，我设计了系统的静态结构。确定了每个类的属性（如User的信用分，Book的ISBN和位置）和方法（如Library的borrowBook，UserMap的modifyScore）。类与类之间的关系，如Library对各个“部门”的组合关系，UserMap作为单例被多处访问的关联关系，都在这个阶段被明确下来。
- 状态图设计：我为“图书”这一核心对象设计了状态图。根据指导书，图书的物理位置就是其核心状态，包括 bookshelf (bs), hot bookshelf (hbs), borrow and return office (bro), appointment office (ao), reading room (rr), user。状态之间的转换由用户的操作（如 borrowed）或系统的整理流程（arrangeBook）触发。
- 顺序图设计：对于指导书要求的“用户成功预定新书”和“用户成功取书”两个场景，我绘制了顺序图来描述对象间的交互时序。
编码：
在UML模型完成后，最重要的就是实现部分，每个UML类对应一个Java类，属性和方法也一一对应。在编码中，发现大量的冗余或者设计的不足，最后我会返回去修改UML模型，形成一个“设计-编码-反馈-修订”的迭代循环。这种方式保证了最终代码与设计的高度一致性，也使得代码结构更加清晰和健壮。

架构设计

有点小乱，主要是因为依赖关系和关联关系有点太多了

代码采用了一种分层、模块化的架构，其核心思想是职责分离。

**入口(Main.java)**：作为程序的入口，Main类负责解析输入指令，并将指令分发给核心业务逻辑层。它不处理具体的业务逻辑，只做请求的“路由”
**协调器 (Library.java)**：Library类是整个系统的第二层路由（）。它聚合了图书馆的所有“部门”对象（BookShelf, AppointmentOffice等），并对外提供统一的服务接口（borrowBook, orderBook, arrangeBook等）。客户端（Main）只需要与Library交互，无需关心内部复杂的部门协作
业务模块：
- BookShelf.java: 抽象了“书架”这一概念。通过创建两个BookShelf实例（originBookShelf和hotBookShelf）来区分普通和热门书架，复用了代码。它负责管理在架图书的库存和借阅/阅读的初步处理。
- AppointmentOffice.java, BorrowAndReturnOffice.java, ReadingRoom.java: 这三个类分别模拟了图书馆的三个物理/逻辑区域。它们作为图书的临时容器，并封装了各自区域的特定逻辑
- AppointRequest.java: 一个简单的数据类，用于封装一次预约请求的所有信息，使得信息传递更加清晰。
管理器：
- UserMap.java (Singleton): 这是一个非常关键的设计。我将所有与用户状态和规则相关的逻辑都集中到了这个单例类中。它管理着所有用户的持有书籍、借书日期以及信用分。所有涉及用户权限的判断（canGetBook, canReadBook）和状态更新（addBook, modifyScore）都由它统一负责。这使得用户相关的逻辑内聚性极高，易于修改和维护。
- BookTracer.java (Singleton): 同样，为了将图书轨迹追踪这一功能独立出来，我设计了BookTracer单例。它专门负责记录和查询每本书的移动历史，与主业务流程解耦。

大模型 in UML

通过本次作业的体验，结合使用大模型（如Gemini）辅助编程的经验，我认为要有效引导大模型完成复杂场景的架构设计，关键在于将人类设计师的“结构化思维”传递给模型。具体可以遵循以下策略：

递进式提问：
不要试图用一个宏大的问题得到完美的答案。应该像我们自己思考一样，分步骤引导：
- 识别核心
  - 提供完整的需求文档（如hw15.md），要求模型：“请根据以下需求，列出所有的核心、它们的主要属性和职责。” 这能帮助模型建立起对问题域的基本认知。
- 构建结构
  - 基于上一步的实体列表，让大模型设计一个UML类图，需要体现类之间的继承、实现、组合和关联关系。请特别考虑如何管理用户数据和图书库存。” 这一步是在搭建系统的骨架。
- 细化行为
  - 选择一个复杂的业务流程，如“用户预约并成功取书”，然后提问：“请为‘用户成功取书’这个场景绘制一个顺序图，展示User, Library, AppointmentOffice, UserMap等对象之间的交互过程。” 这能帮助理清对象间的调用链
- 提示重点
  - 虽然大模型现在已经高度智能，但是某些边界情况的考虑可能还是不够到位。因此我们需要根据自己的理解对大模型给予适当提示，这有利于我们将bug扼杀在摇篮中
角色扮演：
将大模型视为一个初级架构师或开发伙伴，进行对话式协作。
- 赋予角色：“你现在是一名资深的架构师，请评审我下面的Library类设计，指出其中可能违反SOLID原则的地方，并提出改进建议？”
- 修改反馈：“你给出的设计中，Library类的arrangeBook方法太复杂了。请将其重构，把处理借还处、阅览室和预约处的逻辑分别拆分到私有辅助方法中。”

OO总结

一个学习的OO课程总算结束了

架构

本学习四个单元，四种不同的风味（）

U1：复杂问题建模，真的需要仔细考虑架构设计问题，否则一不小心就要陷入重构风波了。最难忘是优化器的代码量以及和功能代码量差不多了
U2：多线程问题建模，对于多线程协作完成任务。仔细考虑“锁”的问题，不然修复死锁bug到怀疑人生
U3：JML建模问题，仔细研读JML文档以及JML规格描述，各类细小问题藏匿其中，严格遵守规格设计的同时不能缺少性能
U4：UML建模问题，先思考还是先编码，这是一个问题。我们的回答是“建模-编码-再建模”，通过UML建模我们可以理清思路，抽丝剥茧。

测试

本学期在测试方面最大的转变就是总是测不够，用测评机轰炸也觉得不够保险。
在上个学期学习oopre时，几乎没怎么使用测评机，甚至没怎么进行测试；而在OO正课中，就算搭好了测评机也觉得测试不够（）

U1：纯粹的随机，极致的数值。因为第一单元的数据生成器是自己搭建的，所以存在数据过强或者过弱的情况。所有数据均采用随机生成的方式
U2：在Gemini的帮助下，U2的数据生成器搭建的十分顺利，从这时起，养成了使用参数调整数据生成器脚本的习惯（其实是AI的习惯），这样利用参数可以更加多样化地生成数据。同时也是首次采用依据输出建模checker的方式，以应变大家多种多样的策略
U3：白盒测试，依照JML编写junit测试代码，从设计角度测试代码实现而非往常的依赖数据进行黑盒测试。不过同时也依赖一些极端数据用于性能测试
U4：交互式测评，使用UML搭建测评机，设计driver驱动整个测评系统工作，依赖state跟踪java程序状态。合理设计，AI实现（），测评如此简单！

感想

从我的OO专属报告截取一部分出来

数据不会说谎，它们为你描绘了一幅独特的开发者画像。以下是为你专属定制的亮点标签：

🗺️ UML专家: 在第四单元，你精确地解析了所有UML模型，所有检查点均完美通过，展现了对复杂模型无与伦比的洞察力。
🤝 积极的协作者: 在「第七次作业」的互测中，你发起了 300 次测试，积极参与到社区协作中。发现他人bug与修复自身bug同样是学习的重要一环。
🎯 精准打击者: 在「第二次作业」中，你的Hack成功率高达25%，展现了你构造高效测试用例的非凡能力。
🌊 风暴幸存者: 在「第二次作业」这场被Hack总数高达49次的“腥风血雨”中，你仅被攻破0次，展现了超凡的生存能力。
🚀 开局冲刺手: 在「第九次作业」等多次作业中，你都在早期就完成了首次提交，展现了极强的学习主动性和规划能力。

虽然过程极度辛苦，所幸结果并不让人失望。OO越办越好呀