如何识别 UML 建模中的用例

用例方法是一种识别系统业务目标的技术。用例的识别有助于定义系统范围，确保找到的需求都与业务价值、需求和战略保持一致。

用例分析中的参与者是什么？

参与者指定用户或与正在开发的系统交互的任何其他系统所扮演的角色。它可能代表人类用户、外部硬件或其他主体所扮演的角色。参与者总是在系统之外，通过启动用例、向它们提供输入和/或从它们接收输出来直接与用例交互。虽然单个物理实例可能扮演多个不同参与者的角色，但参与者不一定代表特定的物理实体，即触发发送电子邮件警报的计时器。

识别用例——用例分析中参与者的特征
简单地列举团队成员对涉众或目标用户的看法，在讨论中更容易达成共识。

1. Actor位于系统之外，不属于系统的某个部分，所以我们不需要“构建”“actor”；
2. 只有能够使用系统、与系统交互、与系统交换信息的人才是系统的参与者；
3. Actors 会启动并参与用例，所以找到 Actors 可以指导我们找到用例；
4. 虽然我们不需要“开发参与者”，但我们需要考虑接口。系统需要考虑actor使用的接口（用户体验/GUI），或者系统需要通过actor提供的接口获取数据。

演员是谁？问以下问题：

1. 谁会使用这个系统？
2. 谁来安装这个系统？
3. 谁来启动这个系统？
4. 谁来维护这个系统？
5. 谁来关闭这个系统？
6. 哪些其他系统将使用该系统？
7. 谁将从这个系统中获得信息？
8. 谁将向该系统提供信息？
9. 当预设时间到来时，会自动发生一些事情吗？
10. 哪些系统将与该系统联网？
11. 是否有任何硬件设备连接到该系统？
12. 哪些数据库将与该系统联网？
13. 公司里谁会使用这个系统？\
14. 谁会在公司之外使用这个系统？
15. 当特定时间或事件发生时，这个系统是否需要自动通知谁或其他系统？

演员类型

许多分析师在用例图绘制过程中忽略了关键角色，因为他们只识别人类角色。以这种方式对用例参与者进行分类有助于分析师确保他们不会忽略用例图中的任何关键参与者。

还有另一种对参与者进行分类的方法。他们可以：

• 人类
• 系统软件
• 硬件
• 定时器/时钟

识别用例的问题列表

1. 参与者希望从这个系统中获得什么样的功能？
2. 该系统是否存储信息？哪些参与者将创建、阅读、更新和删除这些信息？
3. 当系统内部状态发生变化时，系统是否需要通知参与者？
4. 系统是否需要知道任何外部事件？当这个外部事件发生时，哪个参与者会通知系统？
5. 该系统是否需要定期执行任何操作？
6. 当一些重要的外部事件发生时，系统是否需要自动执行某些操作？
7. 这个用例的名称是否足够清楚？这个用例的结果可以直接从这个用例的名字来判断吗？
8. 这个用例会有多个结果吗？或者这些结果是在不同的时间点产生的？