日常练习

今天主要学习了 UML 中的鲁棒图（Robustness Diagram），这是需求分析到系统设计之间的一种过渡模型，用来描述系统在用例执行过程中，各个对象如何协作，并保证系统结构的稳定性。鲁棒图最早由 Ivar Jacobson 提出，属于 Rational Unified Process（RUP）中的一种表达方式，介于用例图和顺序图之间。它的核心作用是在不改变业务语义的情况下，把用例描述转换成更具体的对象交互结构，同时检查系统是否具备良好的职责分配。

在学习过程中，我首先明确了鲁棒图的三种核心元素：边界对象（Boundary Object）、控制对象（Control Object）和实体对象（Entity Object）。边界对象负责系统与外部环境的交互，比如界面、控制器、网关等；控制对象负责业务逻辑的处理和流程控制，比如服务类、管理器；实体对象则对应系统中的核心业务数据，一般是持久化对象。理解这三种对象的职责区分很重要，因为在画图时要避免混淆，比如不能让边界对象直接操作数据库，也不能让实体对象承担过多的业务逻辑。

接着我练习了从一个用例描述出发绘制鲁棒图。用例是“用户登录系统”，用例描述中包括参与者（用户）、前置条件（用户未登录）、基本流程（用户输入账号密码并提交，系统验证通过后跳转主页）、异常流程（账号或密码错误时提示重新输入）。根据这个描述，我先确定了边界对象是“登录界面”和“系统主页”，控制对象是“登录控制器”，实体对象是“用户账户”。然后按照流程连接这些对象：用户与登录界面交互，登录界面向登录控制器发送请求，登录控制器读取用户账户信息进行校验，校验成功后通知登录界面跳转到系统主页。画图的过程中，我特别注意了箭头的方向和类型，鲁棒图中一般使用依赖关系来表示消息传递，而不是继承或实现。

在练习过程中，我发现鲁棒图的一个重要作用是帮助识别设计缺陷。例如，当我最初画的图中，登录控制器直接访问了数据库表结构，这会让控制对象依赖具体的存储实现，不利于后期更换数据库。经过调整，我把数据访问部分抽象成一个“用户数据访问对象（UserDAO）”，让控制对象只依赖接口，而不关心具体实现，这样系统的健壮性提高了。
另外，我还看了一些实际项目的鲁棒图案例，比如在线购物系统中的“下单”用例。在这个案例中，边界对象包括“商品详情页”“购物车页面”“订单确认页”，控制对象是“订单处理器”，实体对象包括“订单”“商品”“库存”。通过分析鲁棒图，可以看到在订单处理过程中，库存检查、价格计算、订单生成等操作都被分配到不同的对象中，避免了单一类承担过多职责。这种职责分离的思想，在后续的顺序图和类图设计中都非常有用。

今天的学习让我意识到，鲁棒图虽然不像类图那样细致到属性和方法，也不像顺序图那样精确描述消息的时间顺序，但它在需求理解和系统结构设计之间起到了桥梁作用。它能帮助开发者在早期就识别出不合理的对象关系，避免后期重构成本过高。接下来我打算继续练习更多复杂用例的鲁棒图，并尝试将它与顺序图结合起来，看看两者在建模过程中的互补性。