UML用例图之寻找参与者与用例

1 寻找参与者

1.1 参与者的特征

简单列举出团队成员对参与者的认知,在讨论过程中比较容易达成共识。

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

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

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

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

1.2 寻找参与者的问题表

把与参与者有关的问题列出,方便来帮助寻找参与者。

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

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

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

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

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

6. 那些系统会来使用这个系统?

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

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

9. 在预先设定的时间到达时,有什么事情会自动发生吗?

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

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

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

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

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

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

1.3 参与者种类表

把参与者细分为数个种类,方便用来寻找参与者,以及用来记录整个项目会遇到的参与者。
种类细项参与者
公司外部的 
公司内部的 
系统其它系统(外部) 
其它系统(内部) 
数据库 
时间 
硬件设备  

2 寻找用例 

2.1 系统简述

用三言两语简单描述一下系统,同时可以把想到的重点随手记录下来。
系统名称:
系统简述:
<用两三句话点出系统的主要特点>
重点整理:
<最好使用列表式的方式,将讨论到的或者想到的重要一一列举出来,方便日后回顾>

2.2. 用例问题表

把跟用例相关的问题列出,方便寻找用例。
1. 参与者想要从这个系统获得什么样的功能?
2. 这个系统存储信息吗?哪些参与者将建立、读取、更新和删除这些信息?
3. 当系统内部状态发生变化时,这个系统需要通知参与者吗?
4. 是否有什么外部事件是这个系统需要知道的?当这个外部事件发生时,哪些参与者会通知这个系统?
5. 这个系统需要定期执行什么操作吗?
6. 当发生了某些重要的外部事件时,这个系统需要自动执行某些操作吗?
7. 这个用例的名称够明确吗?是否能够从这个用例的名称,直接判断出它的结果?
8. 这个用例会有多样的结果吗?还是这些结果,是在不同的时间点产生的?

2.3 用例要点表

简单记录用例的结果、重要流程和议题,日后撰写用例叙述时,这些可以作为参考资料。
用例要点说明
<用例名称>结果 
重要步骤 
议题 

2.4 活动图

绘制简单活动图表达流程,有助于寻找用例。

3 用例指南

1. 以“强动词”作为用例名称的开头;
2. 使用领域术语作为用例名称;
3. 以用例的对方顺序“暗示”其发生时间;

4. 把主要参与者放置于图标的左上角;
5. 将参与者放置于用例图的边框外;
6. 用单数的、领域相关的名称来为参与者命名;
7. 每个参与者关联到一个或多个用例;
8. 以角色命名参与者,不以职务头衔命名;
9. 使用《system》表示系统参与者;
10. 不允许参与者之间有互动;
11. 用“时间”参与者表示预订事件;
  • 4
    点赞
  • 36
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值