我们在序列图梳理出来之后，把关注点集中在序列图上指向待建设系统的消息。通过这些消息，我们可以推导出第一批软件用例。
如用例：采集人员录入人口数据
这个软件用例，我叫它“基本软件用例”
活动2：采集人员采集地址数据
但是推导的工作并不到此为止，针对每一个提炼上来的软件用例，以及它所在的上下文思考，是否还需要其他的软件用例，才能比较健全地完成每一项业务活动。
例如，上篇文章在思考的一个问题是：
使用系统录入采集数据，我们从这个事情，又可以引申出，采集后的数据是否需要维护的问题。首先考虑录入数据的过程，是否都能保证数据的准确性，没有人为的错误，系统数据校验机制应该只能解决一部分有格式化，有规律的数据验证。如果是会存在录入不准确的情况，从目标出发，采集如果对于数据质量有一定的要求，那么采集人员数据自检，也是一项重要的工作。所以就要再引入多一个用例：
用例：采集人员自检人口数据
我叫这个用例为“健全性用例”
从而，通过这种推导方法，将所有的基本用例和健全性用例都梳理出来。
我们可以通过更形象的用例图表达软件用例：
用例图
用例图包含三类构成要素：
1. 角色（用一个小人儿表示）
2. 操作（用线段表示）
3. 用例（用圈圈+文字表示）
角色：它可以是系统用户扮演的角色，也可以是跟系统有关的外部设备。
用例：依然采用do something的描述方式来描述使用系统做的事。
网友评论