BUAA_OO_2025_U4

刘诗怡-23371372 2025-06-11 11:32:28

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

本单元深入实践了正向建模与开发，其核心在于从模型到代码的严谨转化。我们不再是写完代码再回头画图，而是将设计前置，把精力更多地放在分析问题、构建抽象模型和定义行为契约上。

具体而言，我们从对系统需求的透彻理解开始，运用UML等工具（尽管在实践中可能是通过文本描述来模拟）进行概念建模。这包括识别核心实体（如书籍、学生、书架、预约台等）、定义它们之间的关系（如聚合、关联），并明确每个实体的职责和状态。

在此基础上，我们进一步聚焦于行为建模。对于每个关键操作，我们不仅仅是想象它会做什么，而是详细地定义其输入、输出、前置条件、后置条件和不变式。这些行为契约构成了组件之间交互的“协议”，确保了在复杂场景下行为的正确性和可预测性。

开发阶段则严格遵循这些预先设计好的模型和行为描述。每一个类、每一个方法都力求精准地映射模型中的对应元素。这种方法带来多重好处：

减少返工：在设计阶段就能发现并修正潜在的问题，避免在编码后期才发现架构缺陷而导致大规模重构。
提高代码质量：通过模型强制的结构化思考，代码会更具一致性、可读性和可维护性。
促进协作：模型作为统一的“语言”，让团队成员对系统有共同的理解，提高沟通效率。
支持自动化：清晰的契约可以为自动化测试提供明确的依据，甚至可以为后续的代码生成或验证奠定基础。

简而言之，正向建模让我们从“写代码”升级到“设计系统”，强调了软件开发过程中的工程性和规范性。

总结本单元作业的架构设计，并对比分析最终的代码设计和UML模型设计之间的追踪关系

架构设计概述

本单元的架构设计体现了经典的分层与职责分离思想，旨在构建一个高内聚、低耦合的图书馆管理系统。核心组件及其职责如下：

Library (核心协调层)：作为整个系统的“大脑”，负责接收来自外部的命令（如借书、还书、开馆等），并根据业务逻辑协调内部的各个功能模块来完成操作。它不直接管理书籍数据，而是将具体任务委托给专业的子组件。
BookShelf (书籍管理层)：专注于书籍的物理存储、状态管理（普通书架、热门书架）、库存统计以及书籍流转轨迹的记录。它是所有书籍数据的“唯一真相来源”。
ReservationDesk (预约管理层)：专门处理书籍的预约流程，包括管理学生的预约请求、保留书籍以及处理预约超期等逻辑。
BorrowAndReturnDesk (借还中转层)：作为书籍进出图书馆的“关口”，负责接收归还的书籍和发送被借阅的书籍，并充当书架和用户之间的临时缓冲区。
Student (用户状态层)：抽象出学生这一实体，维护每个学生的借阅历史、当前持有的书籍、预约状态以及与借阅规则相关的个人属性（如是否持有B类书等）。

这种设计理念强调了模块的专业性：每个组件只负责单一且明确的业务领域，从而最大程度地降低了它们之间的相互依赖。

代码设计与UML模型设计的追踪关系

在最终的代码实现中，我们力求与假想的UML模型设计保持高度一致的追踪关系，这体现在以下几个层面：

结构层面（类图）：
- 实体映射：UML类图中定义的每个类（Library、BookShelf、ReservationDesk、BorrowAndReturnDesk、Student）都在代码中以独立的.java文件存在，实现了一对一的映射。
- 属性对应：UML类图中每个类的属性（例如 BookShelf 中的 allBooksId、lastOpenHotIsbns，Student 中的 borrowedBooks、hasTypeB 等）都在代码中作为相应的成员变量被声明，并且数据类型通常保持一致。
- 方法实现：UML类图中定义的每个类的操作（方法），在代码中都有对应的同名方法实现，其方法签名（名称、参数类型、返回值类型）严格匹配。例如，Library 类的 borrowBook、returnBook、moveBook 等方法直接对应了业务操作。
- 关联关系：UML类图中表示的类与类之间的关联关系（如聚合、组合）在代码中体现为成员变量的引用。例如，Library 类内部持有 bookShelf、reservationDesk、borrowAndReturnDesk 和 students 的实例，这直接反映了其对这些组件的聚合关系。
- 依赖关系：UML中通过方法参数或局部变量体现的依赖关系，也在代码中得到了实现。
行为层面（序列图/活动图）：
- 流程映射：UML序列图或活动图描述的特定场景下的对象交互顺序和行为流程（例如借书时 Library 调用 BookShelf 查找书籍，再调用 Student 更新状态），在代码中通过方法调用链和条件分支逻辑精准复现。每一个流程步骤、每一个条件判断，都能在代码中找到对应的实现块。
- 状态转换：模型中定义的对象状态（LibraryBookState）及其转换，在代码中通过更新对象的 state 属性来追踪。例如，书籍从 BOOKSHELF 状态到 USER 状态的转换，直接在 borrowBook 方法中完成。

这种紧密的追踪关系是正向建模成功的标志。它确保了设计蓝图与最终产品之间的高度一致性，使得代码更易于理解、维护和调试，也为后续的扩展和重构提供了坚实的基础。

根据使用大模型辅助正向建模的体验，总结分析如何引导大模型在复杂场景中完成架构设计任务

使用大模型辅助正向建模，就像拥有一个“思考加速器”或“知识渊博的助手”，但在复杂场景下，要有效引导它完成架构设计任务，需要一些策略和技巧：

明确而分层级的需求输入：
- 引导方式：不要一次性抛出所有复杂需求。首先从高层次的业务目标和功能模块开始，例如“设计一个图书馆管理系统，需要有书籍管理、用户管理、借还管理和预约管理”。
- 体验总结：大模型在处理海量信息时，容易陷入细节而忽略整体，或者产生泛化的、不贴合核心需求的答案。分层级输入能帮助模型聚焦当前任务，逐步构建复杂系统。
迭代式细化与交互反馈：
- 引导方式：将架构设计视为一个多轮对话的迭代过程。在模型给出初步设计后，针对其不足之处或需要细化的地方进行追问。例如，“在书籍管理模块中，如何处理热门书籍的逻辑？”、“请列出BookShelf类需要包含的属性和方法，并考虑它们的可见性。”
- 体验总结：大模型难以一次性给出完美的、无缺陷的复杂设计。通过不断提问、修正和提供上下文，可以引导模型向更精确、更符合预期的方向演进。这就像与一个初级设计师协作，你需要明确指示和反复修改。
注入设计原则与模式约束：
- 引导方式：在提示中明确告知大模型你希望遵循的设计原则（如单一职责原则、开闭原则）和设计模式（如生产者-消费者模式、策略模式）。例如，“请确保每个类都遵循单一职责原则，避免职责过度膨胀。”
- 体验总结：大模型拥有广阔的知识库，但它不会自动选择“最佳实践”。通过明确的约束，可以促使模型生成更健壮、更可维护的设计。这要求使用者自身对设计原则有一定了解。
要求结构化与可视化输出：
- 引导方式：明确要求模型以特定格式输出设计结果，例如“请以Markdown表格形式列出类名、属性和方法”、“请提供UML类图的PlantUML代码”、“请用伪代码描述关键方法的逻辑流程”。
- 体验总结：大模型默认输出可能是散乱的文字。结构化的输出不仅方便我们理解，也强迫模型在内部对信息进行更好的组织和归纳。这对于后续的编码和文档化都非常重要。
提供领域知识与边缘案例：
- 引导方式：在复杂场景中，往往包含特定的业务规则或边缘条件。及时向大模型补充领域知识（如“热门书籍”的定义、“预约保留期限”等）和特殊情况（如“无书可借”、“用户已持有同类书”等）。
- 体验总结：大模型基于通用语料训练，可能无法完全理解特定业务的细微之处。这些信息的注入能让模型的设计更贴合实际需求，减少“想当然”的错误。

通过以上策略，我们可以将大模型从一个简单的文本生成器，转变为一个强大的、交互式的架构设计辅助工具，尤其在梳理复杂逻辑、生成初步结构和验证设计思路方面表现出色。它能显著加速设计过程，但最终的决策和修正仍需人类设计师的判断。

总结自己在四个单元中架构设计思维的演进

我在四个单元中的架构设计思维经历了一次从局部优化到全局考量，从实现驱动到模型驱动的显著演进。

第一单元（表达式求导）：
- 初期：思维停留在**“如何实现功能”的层面。倾向于将一个大问题拆解成多个小函数，但缺乏对类与对象职责的深入思考。对继承、多态等概念的理解还比较表面，可能仅仅停留在语法层面，没有充分利用它们进行灵活的结构设计。
- 演进：通过反复修改和对比优秀设计，我开始认识到将表达式的各个组成部分（常量、变量、函数、因子等）抽象为统一的接口或抽象类（例如 Factor），并通过多态来处理不同类型的表达式。这让我体会到了树形结构在处理递归和复杂嵌套方面的优越性，也初步理解了面向对象在应对变化方面的优势。但此时的架构设计仍偏向于自顶向下分解，对“架构”的理解更多是类和方法的组织。
第二单元（多线程电梯）：
- 初期：面对并发这一全新挑战，思维容易混乱。可能简单地使用粗粒度锁，或者凭直觉进行线程管理，对线程安全、死锁、活锁、饥饿等并发问题的理解不足。架构上可能只是将不同的任务分配给不同的线程，缺乏对共享资源和协作模式的系统性考虑。
- 演进：被迫引入了并发设计模式，尤其是生产者-消费者模式。我开始明确地将请求输入、调度逻辑、电梯运行抽象为独立的线程实体，并通过共享队列进行解耦和通信。这让我深刻理解了线程间的协作、同步机制（synchronized、wait/notify）的应用，以及如何通过有限状态机（FSM）来管理电梯的内部状态。这是从单线程思维向并发架构思维的重要突破，开始意识到架构需要考虑运行时行为和资源竞争。
第三单元（JML规格化设计）：
- 初期：JML的引入将我从具体的实现细节中抽离出来，被迫从契约的角度审视系统。开始思考“这个模块应该做什么”，而不是**“我如何实现它”**。
- 演进：培养了契约式设计的思维。我不再仅仅关注功能的正确性，而是注重前置条件、后置条件和不变式的严格定义。这使得我在设计时能够更清晰地界定每个模块的职责边界和对外行为，强制我提前思考所有可能的输入和对应的输出，以及异常处理。在架构层面，JML促使我设计出接口清晰、职责明确、可测试性强的模块，因为每个接口都附带了明确的行为规范。这是从“如何实现”到**“如何规范化设计”**的思维转变。
第四单元（UML与正向建模）：
- 初期：可能只是将UML视为一种“画图工具”，用来描述已有的代码，或者在设计阶段画出一些粗略的草图。对UML各种图的语义和如何运用它们进行系统性设计理解不深。
- 演进：通过实践正向建模，我深刻体会到模型先行的重要性。在编写一行代码之前，先通过UML类图明确系统结构、类职责和关联关系；通过序列图、活动图明确对象交互流程和行为逻辑。这种思维强制我进行高层次的抽象和全局的系统性思考，从而在设计阶段就能发现潜在的循环依赖、职责不清或扩展性差的问题，避免了后期大规模的重构。我学会了如何利用UML图作为沟通工具，将设计意图清晰地表达出来，并将其作为指导开发和验证的蓝图。这标志着我架构设计思维从**“代码驱动”到“模型驱动”**的成熟。

总而言之，我的架构设计思维从最初的功能实现导向，逐步发展为并发安全导向，继而转向契约规范导向，最终达到模型驱动的、高内聚低耦合、强调可扩展性和可维护性的全面系统性设计思维。

总结自己在四个单元中测试思维的演进

我在四个单元中的测试思维经历了从朴素的功能验证到系统化、策略性的、自动化的转变。

第一单元（表达式求导）：
- 初期：测试思维非常朴素，主要依赖手动输入少量案例进行功能验证，例如输入简单的多项式，检查求导结果是否正确。测试数据来源有限，往往只覆盖“正常”情况，对边界条件和异常情况考虑不足。
- 演进：开始接触自动化测试。通过编写脚本，生成了大量的随机数据和各种边界条件（如空括号、多重嵌套、大整数、特殊字符等），并尝试用暴力方法进行对拍。这让我认识到测试数据覆盖率的重要性，并开始思考如何构造能够尽可能覆盖所有代码路径和逻辑分支的测试用例。此时，测试的重点主要集中在“功能正确性”上。
第二单元（多线程电梯）：
- 初期：多线程引入了极大的复杂性，测试不再仅仅是输入-输出的静态验证，更要考虑并发安全和运行时行为。初期可能仍然使用固定数据，关注是否会 TLE（超时）或 WA（答案错误），对并发问题的根源理解不足，测试往往难以复现问题。
- 演进：意识到了测试的多维度性：正确性、性能、鲁棒性（线程安全）。
  - 正确性：构造极端并发场景（如大量请求瞬间涌入、请求类型高度重复、临界点请求）。
  - 性能：测试大规模请求下的运行效率，通过改变请求量和请求频率来评估性能瓶颈。
  - 鲁棒性：这是最大的挑战。开始关注非确定性错误，理解死锁、活锁、数据不一致等问题。我学会了使用日志记录来追踪线程行为和数据流转，通过多次运行相同测试数据来发现间歇性的并发问题。测试思维从静态正确性转向了对动态行为和并发特性的验证。
第三单元（JML规格化设计）：
- 初期：JML的引入为测试提供了明确的“黄金标准”，测试不再是凭空猜测可能的问题，而是对照规格进行验证。
- 演进：形成了契约式测试的思维。测试用例的设计直接来源于JML规格中定义的前置条件、后置条件和异常行为。
  - 功能测试：针对JML中的 requires 和 ensures 子句，构造满足前置条件时，验证后置条件是否成立。
  - 异常测试：针对JML中的 signals 或 signals_only 子句，专门构造不满足前置条件的输入，验证是否抛出正确的异常类型，并且异常发生时系统状态符合预期。
  - 不变式验证：关注JML中的 invariant，确保对象状态在方法执行前后始终保持一致性。
  - 黑盒测试的强化：完全根据JML规格设计测试用例，不关注内部实现细节，这极大地提高了测试的系统性和有效性，也使测试用例的构造更加清晰和全面。
第四单元（UML与正向建模）：
- 初期：在正向建模的指导下，我意识到测试可以更早地介入，甚至在编码前就可以根据模型设计测试用例。
- 演进：
  - 设计驱动测试：根据UML类图中的类职责、属性约束和方法签名设计单元测试。确保每个独立组件的功能正确性。
  - 行为驱动测试：根据UML序列图或活动图中的对象交互流程和业务场景设计集成测试和场景测试。验证多个组件协同工作时是否符合预期。
  - 系统级测试：在整个系统完成后，进行端到端的测试，模拟真实用户行为。
  - 回归测试的完善：随着代码规模增大，自动化回归测试变得至关重要，确保每次修改或新增功能不会破坏现有功能。
  - 测试用例的系统化：我学会了如何根据不同的业务功能和交互路径，设计更全面、更有针对性的测试用例，从粒度更小的单元测试到粒度更大的集成测试。

总的来说，我的测试思维从最初的**“能不能跑起来”，发展到“在并发环境下是否安全高效”，再到“是否严格符合规格”，最终达到了“是否符合设计模型和预期行为”的全面、系统和前置的测试思维。测试从“收尾工作”变成了贯穿整个软件生命周期的重要环节**。

总结自己的课程收获

面向对象这门课程对我来说，不仅仅是学习一门编程语言或一些编程技巧，更是一次软件工程师思维模式的重塑和初步养成。

面向对象核心思想的升华：
- 从最初对封装、继承、多态的模糊概念，到能够在复杂的实际问题中灵活而有目的地运用它们来解耦、提高代码复用性和可扩展性。特别是多态在处理不同类型对象时的优雅性，以及接口在定义行为契约时的强大，让我体会到OO范式的精髓。
- 深刻理解了接口与实现分离的重要性，认识到它是构建灵活、可测试和可扩展系统的基石。
软件工程实践的全面洗礼：
- 架构设计：我学会了从高层次抽象问题，将一个复杂的系统分解为职责清晰、边界明确的模块，并考虑模块间的合理协作与依赖关系。这让我明白了“设计先行”的重要性，以及在编码前进行充分思考的价值。
- 并发编程：第二单元的“折磨”让我对多线程编程从恐惧到初步驾驭。我理解了线程安全、死锁、活锁、调度等复杂概念，并学会了运用 synchronized、wait/notify 等同步机制解决并发问题。这是在实际开发中不可或缺的技能。
- 规格化设计（JML）：JML的严格训练强制我养成了**契约式编程（Design by Contract）**的习惯。在编写代码前，我必须清晰地定义每个方法的前置条件、后置条件和异常行为，这对于提高代码质量、减少错误和方便团队协作非常有益。
- 模型驱动开发（UML）：第四单元的正向建模实践，让我明白了模型作为设计蓝图和沟通工具的重要性。通过UML图进行设计，能够更早地发现设计缺陷，提高设计质量，并使开发过程更加规范和可控。
- 测试策略：从最初的随意测试，到后来系统地设计测试数据、自动化测试、并发测试和规格测试，我认识到测试是保证软件质量不可或缺的一环，并且测试应该贯穿于整个开发生命周期。
解决问题能力的飞跃：
- 面对每次作业中遇到的复杂逻辑、隐蔽错误（尤其是并发问题），我学会了如何利用日志、调试工具、版本控制（Git）进行问题定位、分析和修复。这极大地锻炼了我独立解决问题的能力和耐心。
- 通过不断反思和重构，我学会了如何优化代码结构，使其更优雅、更高效。
工程化思维的培养：
- 课程对代码风格、注释规范、JML规格、UML图的要求，让我逐渐形成了良好的编程习惯和工程化思维。这不仅提高了代码的可读性和可维护性，也为未来的团队协作打下了基础。
抗压与持续学习：
- 每次强测和互测的压力，都促使我更深入地思考问题、更全面地考虑边界情况、更严谨地进行测试。这种持续学习和应对挑战的过程，让我对软件开发的全貌有了更切实的体会和敬畏之心。