从《系统分析师UML用例实战》摘录的部分内容一

确立系统边界-分内外，向系统内找用例，向下系统外找参与者

参与者是位于系统外部的用户，联网的其他系统，硬件设备或数据库，它们并不是系统的一部分，它们之中也只有会使用系统，会跟系统互动，会跟系统交换信息的，才是系统的参与者。

参与者的特性表

1. 参与者位于系统外部，它不属于系统的某一部分，所以我们不需要去构建参与者。

2. 只有会使用系统，会跟系统互动，跟系统交换信息的，才是系统的参与者。

3. 参与者会启动，参与用例，所以找到参与者，就可以引导我们找到用例。

4. 我们虽然不需要构建参与者，但是要考虑接口，系统需要提供接口让参与者使用或者系统需要用到参与者提供的接口。

 

找参与者的15个问题---参与者的问题表

1.  谁会来使用这个系统？

2.  谁会来安装这个系统？

3.  谁会来启动这个系统？

4.  谁会来维护这个系统？

5.  谁会来关闭这个系统？

6.  哪些系统会来使用这个系统？

7.  谁会从这个系统获取信息？

8.  谁会给这个系统提供信息？

9.  在预先设定的时间到达时，有什么事情会自动发生吗？----时间一到会自动执行的用例，可以为它们定义为一种“时间”类型的参与者。

10.哪些系统会和这个系统联网?

11.是否有硬件设备会与这个系统联网？

12.哪些数据库会与这个系统联网？

13.公司内部有哪些人员会来使用这个系统？

14.公司外部有哪些人员会i来使用这个系统？

15.当特定的时间或事件发生时，这个系统需要自动通知什么人，或者是自动通知其他系统吗？

 

参与者种类表

种类                                     细项                                 参与者

人                                       公司外部的人

                                          公司内部的人

 

                                          其他系统（内部）

系统                                    其他系统（外不）

                                          数据库

                                          时间

硬件设备

 

系统简述

系统名称

系统简述：

<用两三句话点出系统的主要特>

重点整理：

<最好是用列表的方式，将讨论到的或想到的重要一一列举出来，方便以后回顾>

 

 

用例是系统的一项行为，它能够生成参与者可评估的结果。也就是说用例包含时间的概念，它会花费一段时间，具有一个执行过程。用例还必须在执行结束后产生一项明确的结果。

 

根据参与者查找对应的用例---用例的问题表

1.  参与者想要从这个系统中获得什么样的功能？

2.  这个系统存储信息吗？哪些参与者将建立，读取，更新或删除这些信息？

3.  当系统内部状态有变化时，这个系统需要通知参与者吗？

4.  是否有什么外部事件是这个系统需要知道的？当这些外部事件发生时，哪些参与者会通知这个系统?

5.  这个系统需要定期执行什么操作吗？

6.  当发生了某些重要的外部事件时，这个系统需要自动执行什么操作吗？

7.  这个用例的名称能够明确吗？是否能够从这个用例的名称，直接判断出它的结果？

8.  这个用例会有许多不同结果吗？还是这些结果，其实是在不同的时间点产生的？

 

用例的要点表

用例                   要点                    说明

                         结果

<名称>              重要步骤

                        议题

 

 

 

参与者的特性表---简单列举出团队成员对参与者的认知，在讨论中，比较容易达成共识。

参与者的问题表---把跟参与者有关的问题列出，方便用来帮助寻找参与者。

参与者的种类表---把参与者分成数个种类，方便用来帮助寻找参与者，以及用来记录整个项目会遇到的参与者。

系统简述----------用三言两语简单描述一下系统，同时也可以把想到的重点随手记录下来。

用例的问题表-----把跟用例有关的问题列出，方便用来帮助寻找用例。

用例的要点表-----简单记录用例的结果，重要流程和议题，日后撰写用例描述时，可以作为参考资料。

活动图------------可以绘制简单的活动图表达流程，有助于寻找用例。