UML 2.5 用例图实战：3个真实系统（订餐/教学/交互）需求分析与建模

UML 2.5 用例图实战：3个真实系统需求分析与建模指南

1. 需求分析到用例建模的核心逻辑

在软件工程实践中，需求分析是构建可靠系统的基石。UML用例图作为需求捕获的利器，能够将模糊的用户需求转化为可视化的功能蓝图。不同于简单的功能列表，有效的用例建模需要遵循"角色-目标-交互"的三元思维框架：

1. 角色识别：不是简单罗列用户类型，而是挖掘系统边界外的主动参与者。例如在订餐系统中，"餐厅财务系统"可能作为隐藏参与者处理支付对账
2. 目标分解：每个用例应代表参与者要完成的独立业务目标。如"处理异常订餐"比"点击取消按钮"更能体现业务价值
3. 交互边界：明确系统责任的终止点。例如订餐系统中"打印送餐单"可能属于POS机系统的职责

常见误区警示表：

经验提示：用例图的黄金法则是——如果参与者无法感知某个功能的价值，它就不应该作为独立用例出现

2. 订餐系统建模实战

2.1 核心参与者识别

• 主要参与者：注册员工（发起订餐）、餐厅员工（备餐）、送餐员
• 次要参与者：工资系统（处理餐费扣款）、打印机设备
• 特殊案例：访客虽然可以查看菜单，但未登录时不能订餐——这需要在系统约束中注明

2.2 用例关系设计

@startuml left to right direction actor 员工 as user actor 前台 as admin actor 餐厅 as restaurant rectangle "订餐系统" { user --> (浏览菜单) user --> (提交订单) user --> (取消订单) admin --> (菜单管理) admin --> (订单汇总) (订单汇总) .> (生成传真) : include (生成传真) --> restaurant } @enduml

关键决策点分析：

1. 包含关系：将"生成传真"从"订单汇总"中分离，因为未来可能改为电子接口
2. 扩展点："取消订单"应标注时间限制条件（如上午10点前）
3. 权限控制：普通员工与前台管理的用例明显区隔

2.3 复杂业务规则处理

对于"规律订餐"这类特殊需求，采用扩展用例方式：

【基础用例】每周订餐 - 主流程：员工设置每周固定餐品 - 扩展点：节假日自动跳过 - 条件：遇法定节假日 - 扩展行为：系统发送暂停提醒

3. 远程教学系统建模进阶技巧

3.1 学生端用例图

@startuml actor 学生 as student actor 教务系统 as edu rectangle "教学系统" { student --> (登录系统) <<extend>> student --> (浏览课件) student --> (下载资源) student --> (观看视频) (找回密码) .> (邮件验证) : include (登录系统) <.. edu : 认证对接 } @enduml

3.2 教师端特殊处理

教师用例的三大特征：

1. 内容管理：课件/视频上传需考虑版本控制
2. 心得共享：教学心得需要审核流程
3. 批量操作：支持ZIP包上传等批处理场景

关系对比表：

4. 客户信息系统建模陷阱规避

4.1 权限边界划分

• 匿名用户：仅开放浏览权限
• 认证客户：增删改个人数据
• 管理员：全局删除权限

4.2 敏感数据处理

特别注意客户信息的可见范围控制：

class CustomerInfo: def __init__(self): self.public_fields = ['name', 'phone'] self.private_fields = ['address', 'payment'] def get_view(self, role): return {k:v for k,v in self.__dict__.items() if k in self.get_allowed_fields(role)}

4.3 审计需求体现

增加"操作日志"用例，记录关键操作：

• 记录字段：操作人、时间、修改内容
• 安全要求：日志不可篡改

5. 用例关系深度解析

5.1 包含关系(Include)

本质是"必须执行"的分解逻辑，典型特征：

• 被包含用例不完整依赖上下文
• 执行主用例必然触发包含用例
• 例如："支付"必须包含"验证支付密码"

5.2 扩展关系(Extend)

表现"可能执行"的条件分支，特点：

• 扩展用例可独立存在
• 执行取决于特定条件
• 例如："订单评价"扩展"完成订餐"

5.3 泛化关系(Generalization)

体现"is-a"的继承关系，适用场景：

• 多种方式实现相同目标
• 子用例共享父用例属性
• 例如："支付"泛化为"信用卡支付"/"余额支付"

关系选择决策树：

是否必须执行？ → 包含 是否条件触发？ → 扩展 是否同类变体？ → 泛化

6. 建模工具实战建议

6.1 Visual Paradigm技巧

1. 使用泳道区分参与者
2. 为复杂用例添加颜色标签
3. 利用分层显示控制信息密度

6.2 版本控制策略

• 每个迭代版本建立子系统边界
• 使用注释标注需求变更
• 保持基础用例的稳定性

7. 需求变更应对策略

当出现新需求时（如订餐系统增加发票功能）：

1. 评估是否影响现有用例结构
2. 优先考虑扩展关系而非修改基础用例
3. 建立需求追踪矩阵：

实际项目中，保持用例图的演进式更新比追求完美初版更重要。建议每两周进行一次用例模型复审，确保与需求文档的同步率不低于90%。