BUAA_OO_Unit4 UML与正向建模

[程斌-23373367]

先来简单回顾一下本单元完成的任务：利用UML进行正向建模，并完成一个小型的图书馆管理系统

• hw13:实现借阅，预约，预约取书，还书等基本流程
• hw14: 实现图书室借阅功能，并增加热门书架与普通书架
• hw15：引用用户信用积分限制

一、正向建模与开发

正向建模与开发是指在软件开发过程中，根据需求说明书或者业务逻辑出发，通过抽象分析构建系统模型，指导我们后续的设计、开发以及测试流程。正向建模强调顶层设计，通过模型定义系统结构、行为以及类之间的交互方式等，并不直接陷入编码细节。

OO作业是迭代性任务，一个良好的初期架构对于后期作业的顺利完成是十分重要的。在前几个单元中，我是通过阅读分析指导书，手绘简易的架构设计图，包括了类及其属性的设计，以及类之间交互关系的设计。

本单元中，课程组的初衷是先绘制UML类图等进行正向建模，并据此进行后续开发。本单元指导书的一大特点就是内容多而繁杂，如若不加思考便着手编码，很难得到一个良好码风与正确性兼具的代码。我是先通过阅读分析指导书，规划得到其中的基本对象类(预约处、借还处、书架等)，并确定其基本属性，并对业务流程加以分析，确定类之间的交互关系与工具类(Runner也即其他同学设计的抽象Library类)。实际上，我是在纸上简单设计其代码架构图，确保各个业务流程能够良好完成，并未直接开展UML设计，不经过编码过程中的一些思考直接得到较为准确的UML类图对我来说还是太难。（但这应该也并不违背课程组初衷）

利用UML等正向建模可以在开发初期便为系统搭建一个良好清晰的架构图，避免边写代码边该架构的混乱，提前暴露出一些逻辑漏洞，同时也便于团队开发，减少架构设计人员、开发人员、测试人员之间的理解偏差。但需注意的是建模深度与开发效率二者之间的平衡，不必为所有功能绘制复杂UML图，也不必一开始陷入非常细节的功能设计。

二、本单元架构设计与UML追踪

2.1 第一次架构设计

第一次功能相对简单，实现了以下几个类

• AppointmentOffice:预约处，处理预约请求并为对应顾客留存对应的书
• BorrowReturnOffice:借还处，用于通过借阅以及预约取书拿到的书都会在此处归还
• Bookshelf：书架，保存依旧属于书架中的书
• User、Book:用户类以及图书类
• QueryMachine:查询机，主要完成查询请求
• Runner:类似于一个抽象的图书馆类，用于各个部门与输入输出的交互实现

实际上，代码中应有的类在指导书以及oolens的推送中已经暗示的非常明显了。

但在本人的作业实现中，我感受到了query功能的一些不足，我是通过在queryMachine中存储了所有出现过的书籍的引用，并在Book书这一对象中利用容器存储其对应的转移路径。但联系现实生活，一本物理存在的书不应知道除书本记录的文字内容之外的信息。所以我任务我们应该额外构建某个容器类，在其中存储所有书籍的信息，可能起到类似数据库的作用吧。

2.2 第二次架构设计

本次作业新增了热门书架，阅读，归还等功能。

为避免对架构的改变，我在Bookshelf中设置了两个数据结构，分别对应普通书架与热门书架。并在开馆整理时候将对应的书移到相应书架，并通过removeBook的返回值来告知外界其来自哪个书架。

新增阅读室，完成阅读以及归还功能，并在每日闭馆的整理过程中将阅读室剩余的书整理回书架。

2.3 第三次架构设计

本次作业中引入了用户信用分系统，对用户的行为做进一步限制，同时新增了图书借阅期限的限制。

我们在Runner中维护一个noReturnBooks容器，在其中记录所用被借阅或者预约取书拿走还未通过return请求归还的书。在借阅和取书成功后加入该容器，并在书中存储对应的截止日期与用户id等信息。在每日闭馆后对逾期未还书的用户进行信用分扣除。

由于开馆闭馆日期的不连续，我们需要注意在每日开馆时候扣除包括两次开馆之间间隔天数对应的信用积分。

实际上本单元三次迭代UML建模与代码设计是相辅相成的

1. UML草图绘制，有基本的架构逻辑体现
2. 初步开始写代码，细节实现逐渐清晰，开始下一步画最终UML图
3. 绘制UML图
4. 完成代码
5. 校对UML图

三、大模型辅助正向建模

• 题目提炼：对于复杂场景，其自然语言描述的需求说明往往较为繁杂，对于设计者来说很难很快从其中获取所需关键信息。首先可以借助LLM总结题目所要求的任务以及场景描述及任务流程

  例如，在第一次迭代时，可以询问AI“总结图书馆所需要实现的功能以及可能的功能流程，并列出细节”

• 模型提取：完成基本业务类模型建立。例如“需要完成哪些业务类，该业务类中需要保存什么属性，对外提供哪些方法”

• 层次设计：你认为应该如何组织其中类之间的层次架构关系，（引导是否有合适的继承关系或者接口关系），并按照合适的格式输出

• 重复修改：指出认为不合理的地方（阐明自己的思考逻辑给AI），让AI按照相同逻辑修改改进

• 关系挖掘： 输出类之间关系

当然在实际应用时候需要加上以下提问技巧

以下框架展示摘自第八次实验

ROSES框架在RTF框架的基础上将输入细分为5个核心部分，以确保清晰、有目的的交互。ROSES在明确角色和目标的基础上，更强调场景和解决方案。

[Role] 你是某科技公司的公关经理。
[Objective] 为即将发布的智能手表撰写一篇吸引投资人和媒体的演讲稿。
[Scenario] 发布会面向投资者、科技媒体和潜在消费者，需突出产品创新性和市场潜力。
[Expected Output] 一篇800字左右的演讲稿，包含开场白、产品亮点、技术参数、市场定位和结尾呼吁。
[Steps]

1. 用故事或数据开场，引起听众兴趣；
2. 分模块介绍核心功能（健康监测、续航能力、设计美学）；
3. 引用第三方机构的市场预测数据；
4. 结尾强调品牌愿景，呼吁合作。

例如：

[Role] 你是某科技公司的公关经理。
[Objective] 为即将发布的智能手表撰写一篇吸引投资人和媒体的演讲稿。
[Scenario] 发布会面向投资者、科技媒体和潜在消费者，需突出产品创新性和市场潜力。
[Expected Output] 一篇800字左右的演讲稿，包含开场白、产品亮点、技术参数、市场定位和结尾呼吁。
[Steps]  
1. 用故事或数据开场，引起听众兴趣；  
2. 分模块介绍核心功能（健康监测、续航能力、设计美学）；  
3. 引用第三方机构的市场预测数据；  
4. 结尾强调品牌愿景，呼吁合作。  

四、OO架构设计思维的演进

经历层次化设计、多线程设计、JML规格设计、UML正向建模与开发四个单元的训练，我们的架构设计能力有了较大的设计

• 层次化设计——U1：这一单元主要训练了我的层次架构设计能力。通过表达式类、项类、因子类以及继承以及接口机制的实现，我学习了如何根据需求说明书理清类之间的关系。通过管理数据的特点去选择合适的数据结构，依据各个类应该实现的功能以及交互关系划分层次，不进行跨层次交互，降低模型的耦合度。
• 多线程设计——U2: 这一单元是我第一次接触多线程设计，带给了我全新的体验。对于多线程设计，我们应该首先明确任务场景中的并行实体(也即线程对象)，在确定各个线程应该完成的工作后，下一步确定各个类之间的交互关系。对于多线程，如何保证并发访问的安全性是重中之重，我们可以利用Java库提供的读写锁，也可以自行实现锁机制，提升代码灵活性
• JML规格设计——U3: 这一单元我们主要学习了规格化设计。清晰、完善、准确的规格说明对于设计、开发、测试人员之间的协作是极其重要的，可以避免自然语言带来的二义性，同时明确各个类以及方法的边界，这对于一些安全性要求较高的软件是十分有帮助的。
• UML正向建模——U4: 这一单元我们学习了使用UML进行系统建模与开发。一个良好的初期架构设计对于复杂系统的开发是极其重要的的，帮助我们明确类的抽象与提炼，并对类之间的交互关系进行明确。拥有一个良好的架构便已经成功了一半

五、OO测试思维的演进

• U1：在层次化设计单元，我主要进行了构造性测试。我根据指导书中的形式化表述，针对性构造各类测试数据进行测试。但实际上，我所进行的测试只是完成了基本功能的测试，对于边界情况的覆盖不足，也导致了我hw2的出错。
• U2: 在多线程单元，我主要进行了黑盒测试。多线程设计中容易出现的便是并发访问的问题，对于共享变量安全性的测试重中之重，同时TLE风险也较大，对于测试数据的并发强度要求较高，手动构造耗时耗力。我主要搭建了评测机，通过同一时刻投放大量请求以及多线程评测等方法加大测试强度。
• U3: 在规格化设计单元，我主要进行了单元测试。对于规格设计明确的系统，数据范围与边界明确，我们可以利用Junit等单元测试工具，对于一些易出错或者关键方法进行测试验证，同时也可借助一些形式化验证工具去完成测试
• U4: 在UML正向建模与开发单元，我们主要基于模型进行黑盒测试。通过分析UML类图，我们可以在开发之初便明确待测模型各个类的功能以及交互关系，并对此进行覆盖性测试。通过功能明确，完善评测机数据构造策略，进行大量黑盒测试。

对于测试来说，我一般会经历以下流程：基本功能测试——搭建评测机进行黑盒测试——边界测试——白盒测试

六、课程收获

在OO学习的过程中，我的架构设计能力有了较大的进步。在之前的学习中，通常是编写一个不是很长的程序来完成某一功能，架构设计能力并未经过很好的训练。在OO学习中，我们每一单元是完成一个小型的系统，并且迭代式任务对架构提出了更高的要求，我的架构设计能力有了长足的进步。虽然每一单元第一次作业都要思考很久才开始写...

同时通过强测以及互测机制，我的测试能力也进步不少，学习并完成了评测机搭建。以前的C语言以及数据结构作业中，我们可以在平台即时得到最终反馈，每次都是本地如果可以跑起来就交上去看看，如果对了就不会再管了，这也导致我的测试能力接近于0。这学期为了不使强测炸锅以及互测顺利，我也在手动构造性测试基础上学习了评测机搭建，锻炼了测试能力。

OO作业好像一个时间计数器，让我清晰的知道了"第几周"这个概念。每一周的迭代开发并没有像CO那样给我带来精神上的摧残，反倒有一点点享受——阅读分析指导书、思考与设计架构、编码、测试、debug、测试。不管怎么说，OO是结束了，希望之后的数据库、软件工程等课程能善待我。