[UML]用例图

用例和功能的误区：

　　最普遍的理解错误是认为用例就是功能的划分和描述。在这种理解下，用例建模变成了仅仅是较早需求分析方法中功能框图的翻版，如果是这样，用例根本就没有存在的必要，有功能框图就行了。

 

用例不是功能

功能实际描述的是“输入——》计算——》输出”。这让你想到什么？DFD图？这可是典型的面向过程分析模式。

在描述一个事物的时候，我们可以从以下三个观点出发：

一、这个事物是什么？

二、这个事物能做什么？

三、人们能用这个事物做什么？

例如，描述一辆自行车的时候，我们通常这样说明：

一、自行车是一种交通工具，它由传动系统、刹车系统等部分组成

二、自行车可以骑行，可以载物

三、人们可以用双脚蹬踏板而向前行进，可以用手捏刹车使自行车停下来。

第一种描述是一种结构性观点，即事物的客观存在。但是这种观点不能够说明事物的作用，也就是功能性方面的信息。从结构上来说，同样是一个圆环，把它用在汽车上，它可以是方向盘，把它用在自行车上，它就是轮子了。所有仅有结构性观点是不够的。

第二种描述是一种功能性观点，说明事物可利用的价值。但是这种观点不能说明事物在某种情形下的真正价值，也就是它缺乏上下文环境，没有人来使用，事物的所有可利用价值可能是无意义的。换句话说，没有人使用的功能是没有意义的。

第三种描述是一种使用者观点，说明事物对于使用者的意义，以及使用者可以怎么使用它，得到什么样的利益。这种观点不能说明事物的本质结构，它只是从表面上揭示了事物相对于使用者来说是什么，能做什么，可以获得什么。

 

用例与功能区别，总结

一、用例是描述使用者愿望的，描述的是使用者对系统的使用要求，用用例来看待系统的团队，则是从使用者角度出发，说明使用者在系统里能做什么。功能则是脱离使用者的愿望而存在的。

二、用例是系统性的，它描述谁在什么情况下通过什么方式得到什么样的结果。功能描述的是一个个点，如果要达成一个特定的目标，必须要再额外加上一个顺序的过程把点串联起来才能完成一个系统性的工作。而用例描述的是一个系统性的工作，这个系统性的工作非常明确地去达成一个特定的目标。

三、用例可以理解为一系列完成一个特定目标的“功能”的组合，针对不同的场景，这些“功能”体现不同的组合方式。

 

目标和步骤的误区

把寄信作为用例是很自然的事情。

以步骤作为用例则是不对的。进入到用例的内部意味着边界已经改变，边界的改变必然导致参与者也在改变，这时步骤也是可以作为用例的。显然寄信用例包含了收钱用例，他们的大小是不一样的，之所以两者都可称为完整目标，前提条件是由于参与者的不同，而参与者又是与边界相关的。

 

用例粒度的误区

 

业务用例

业务用例用于描述客户现有业务的、没有计算机参与的、目前客观存在的业务领域。

 

业务用例实现

业务用例实现是业务用例的一种实现方式。一个业务用例可以有多种实现方式，它们的关系可以类比编程上的接口和实现类的关系，同一个接口可以有多个实现类。

 

概念用例

作为概念模型中的核心元素，概念用例使用获取业务用例中的核心业务逻辑，这些核心业务逻辑揭示了业务模式，成为业务架构的中腰指导。同时，概念用例还是从业务用例到系统用例过渡时非常重要的指导。对于复杂系统来说，缺少了它，系统用例的产生就会显得突兀和生硬，基本上都是拍脑袋的出来的结果。

 

系统用例

系统用例是软件系统开发的全部范围，系统用例就是我们得到的最终需求。