在uml用例图中,参与者表示 uml图例讲解答案( 二 ) _生活百科

（2）参与者是否需要查询系统中的某些信息？
（3）参与者是否需要改变系统中的某些信息，如创建、修改和删除操作？
（4）系统发生的特定事件或状态的改变是否需要通知参与者？
（5）系统哪些外部事件会促使系统执行相关功能以应对？
（6）系统是否提供相关功能以帮助维护人员来维护系统？
4.3 用例识别的要点
（1）识别出的用例应该反应出系统的目标，即“要做什么”，而非“怎么做”，就是说用例不是系统实现的细节；
（2）从参与者（用户）的角度出发定义用例，而非系统的角度。
（3）用例应为参与者提供有价值的结果，而非动作的集合；
（4）避免陷入功能分解，步骤分解；
（5）每个参与者都应该有可执行的用例，每个用例都应关联至少一个参与者
4.4 命名用例
在确定好系统的用例后，需要给各个用例进行命名。用例的命名需要站在用户的角度描述参与者达到的目标。可以使用下述命名方式：
（状语）动词+（定语）宾语
也就是说，用例的名称应该是动宾短语的格式。如选课、借阅图书、订购货物、使用信用卡支付。
4.5 用例的粒度
用例粒度是指用例细化或综合系统功能的程度。也可以说用例所包含的系统服务或功能单元的多少。用例粒度过粗或过大，则用例包含的系统功能就越多，反之越少。
用例粒度过粗，不便于理解系统，粒度过细会使用例模型过于庞大，给设计带来困难。
用例粒度过细，可能会陷入功能分解，如：

文章插图
实际上，系统中很多业务都包含这种增、删、改、查的操作，这样做并不能为用户提供任何有意义的目标，反而会忽略了用户的真正目的。
上面这种“增删改查”无非就是用户管理，这才是参与者的真实目的。使用下面这种方式处理上面的用例也许会更好一些：

文章插图
管理用户这种用例体现了系统管理员的一个目标或任务。如果非要添加上增删改查，可以使用下面的方式来表达会更好一些。

文章插图
在用例建模中常犯的另外一个错误是把步骤当用例。
如下面这个，似乎挺完美，但是很明显是把操作步骤当用例了。

文章插图
上面这些步骤，无非就是完成用户这个参与者的目标：注册。因此，应该改成下面这个样子：

文章插图
在用例建模中，常犯的第3个错误是把系统活动当用例。

文章插图
上面这个用例图中，建立连接对象、建立命令对象和执行SQL语句是系统内的活动，是用户无法感知的，不是用户的目的，用户也不关心。所以这种用例图是不准确的。
用例建模中常犯的第4个错误是使用系统观点来命名用例。

文章插图
上面左右这两个用例图，哪个画得更好呢？
很明显，右边的比左边的要好，因为右边的是从用户的角度命名的用例，而左侧的用例是从系统的角度对用例进行命名，用户看到后会感到莫名其妙的。
4.6 用例规约
用例图在总体上描述了用户的功能需求（系统提供的功能或服务），但对于每个用例还要进行详细的描述，以便让人知道这个用例具体要做什么，这就是用例规约。也就是说，用例模型实质上是由用例图和对每一个用例的详细描述（用例规约）组成的。

文章插图
一个用例规约（use case specification）应该包含以下内容：
（1）用例的标识与名称；
（2）用例涉及到的参与者；
（3）用例的简要说明；
（4）相关的其它用例；
（5）用例执行的前置条件
（6）基本事件流；
（7）备选事件流；
（8）用例执行的后置条件；
（9）其它信息，如非功能性需求、设计约束、用例审核状态、编制者、修改记录等。
下面是一个用例文档中对借阅图书用例的一个描述情况。