总结本单元所实践的正向建模与开发重点分析两阶类图在正向建模过程中的作用在以往的开发中面对复杂需求我们往往习惯于直接动手敲代码遇到逻辑分支就加 if-else缺少全局视角的规划。而本单元所强调的正向建模Forward Modeling强制我们在动手写下第一行代码前先通过类图、状态图和顺序图将系统的骨架搭好。这种“先设计后编码”的范式带来了显著的好处防患于未然在画状态图时就能提前发现很多逻辑漏洞例如图书状态流转是否闭环预约逾期后的去向等避免了在代码中出现“死胡同”。责任划分清晰在画类图时系统中的每一个动作都需要被分配给一个具体的对象。这迫使我们思考职责边界有效避免了长达数千行的类的出现。一阶类图剥离实现细节聚焦业务核心在动手编码前一阶类图强迫我们从厚厚的指导书中提取类、属性和方法。此时不需要考虑用 List 还是 Map而是专注于构建领域模型如 User、Book、Library。确立系统骨架它帮助我们理清了类与类之间的静态关系谁包含谁、谁依赖谁。一阶类图就像是建筑的施工蓝图在动土之前明确了哪里是承重墙二阶类图技术细节的下沉随着编码的深入我们会发现一阶类图往往过于理想化。为了优化性能或解决特定问题我们会在代码中引入新的内部类如 BorrowRecord、OrderReq或采用特定的设计模式。二阶类图如实反映了这些底层数据结构的变动。架构演进的见证当代码为了解耦而进行重构例如将庞大的 Library 拆分出 BookManager 和 OrderManager时二阶类图记录了这一演变。确保了即使系统再复杂其设计全貌依然可追溯。总结本单元作业的架构设计并对比分析最终的代码设计和UML模型设计之间的追踪关系本单元架构设计总结高内聚与低耦合的实践以图书馆系统为例最终的架构设计呈现出明显的分层管理与职责解耦特征总控分发层 (Library / Main)根据使用大模型辅助正向建模的体验总结分析如何引导大模型在复杂场景中完成架构设计任务扮演门面Facade角色负责接收外部指令并解析时间流逝处理跨日期的结算如统一扣分然后将具体的借、还、预约等指令分发给下层的 Manager。专业管理层 (BookManager, OrderManager, GradeManager)这是解耦的核心。书籍的状态流转、预约队列的维护、评分的统计被完全隔离开来。这种设计使得任意一块逻辑的修改比如增加了续订逻辑都不会波及其他模块。领域实体层 (User, BookCopy, BorrowRecord)将数据与行为封装在一起。例如User 类内部维护自己的借阅限制和信用分状态而不是让 Library 去外部计算。BorrowRecord 解耦了用户与书籍之间复杂的时效关系。代码设计与 UML 模型设计的追踪关系分析最终的 Java 代码与 UML 模型之间存在着高度的映射与追踪关系这正是评测机进行 R1-R5 一致性检验的底层逻辑静态结构的精准映射UML 中的类名、可见性和方法签名在代码中得到了严格的落实。 vUML 中的关联与聚合/组合在代码中直接体现为类属性的引用。动态行为的隐式追踪代码中复杂的业务逻辑如 if 判断、for 循环虽然不在类图中直接体现但完全受到状态图和顺序图的约束。代码中 BookCopy.setState() 的每一次调用都严格对应着状态图上的一条有向边。最终我的二阶类图根据使用大模型辅助正向建模的体验总结分析如何引导大模型在复杂场景中完成架构设计任务我使用的大模型为AIStuidio中的Gemini3.1Pro。在四单元学习中我一直都使用了大模型辅助我完成任务其中第一次第二次我都没有使用如实验中提到的prompt来提示我是将作业的整个文本都传给AI来进行建模。在第三次作业中我学习了实验提到的prompt方法用的是:[1]扮演的职业[2]背景[3]任务要求[4]完成步骤的方式来提示AI完成总体来说效果比之前的要好。(实验中的提示词)总的来说使用prompt来循序渐进地提示AI能更有效的进行建模。总结自己在四个单元中架构设计思维的演进在一单元时我的思维还是更多的停留在之前C语言中的想的更多的是如何使用C的方式来完成任务具体表现为使用一个Scanner类里面包含了所有的函数与所有的变量然后用自己熟悉的方法来解决直观的说就是使用的C语言一样的底层逻辑在微观的视角下进行解析。再之后慢慢地理解了面向对象的思考方式相较而言的“宏观视角”。比如完成文本解析用C的方法或是视角的话就得从每一个字符输入开始判断然后用数据结构中学的”栈“的方法维护一个栈然后将读取的依次出入栈最后完成化简也就是文本解析。而在面向对象中根据任务我们需要一个预处理一个解析器以及一个计算器和一个优化器这就构成了四个类然后在四个类中分别设置好各自的职能。进一步说面向对象的思维像是”分析任务“-“创造对象”-”完善方法“。直观的展示的话使用C时会有一个程序包含上千行代码从宏定义结构体定义全局变量声明函数定义最后是主程序。这更偏向一种线性思考。而面向对象强调的则有所不同在程序设计中需要什么对象便new一个通过封装好各个类最后完成的与C相比更加直观。总结自己在四个单元中测试思维的演进我的测试方法最开始是比较朴素的自己构造样例测试更像是一种”排列组合“排列出所有可能的情况然后在运行后进行对比。这种测试方法的好处是确实管用能初步排查出所有可能的问题。但缺点也十分明显即人力是有限的情况是列不完的错误原因是想不通的。然后就是更加先进的评测鸡测评通过评测鸡能明显不足人力的短板即评测时样例构造多错误原因复杂通过大数据覆盖总能找到错误。但缺点是当错误原因十分刁钻时评测鸡也有概率覆盖不了比如电梯调度中经典的在第50面出现大量检修申请然后再来大量的乘客评测鸡只有小概率才能生成这种”刁钻的“数据。但这种其实人力很好想因为假如站在Hacker的角度这种攻击才是最有可能成功的。所以后面认为最好还是通过”大规模覆盖“再进行特定情况构造来保证正确。(电梯调度中“刁钻”情况)总结自己的课程收获我将用用最简单最直接最不绕弯子的话说我学会了一种新的语言。显然最明显的收获是我从一个只会C的小白变成了一个会OO小猿了其实C和Java的语法感觉差距不大更像是升级版的C。其次通过OO学习我感觉更多的是学会了一种“思维”面向对象的思维我认为就是一种宏观的思维又譬如制造一个房子学习了面向对象后我们就知道需要一个家具接口用来规范家具类还需要水电类来管理水电再浇上弄弄的户型管理类。这是顶层的设计然后再向下细分桌子、椅子、电视、等等。记得之前先导课老师讲的笑话有些冷没有对象怎么办当然是new一个。然后是AI的使用悲哀的说因为能力有限为了更好的完成任务我不得不寻求强大的AI的帮助从豆包到DeepSeek再到GeminiAI着实对我的OO学习带来了巨大的影响我使用AI的能力确实是增强了不少。最后总结的话最简单的话说我想还是我学会了一种新的语言一种新的思维方式。