用力和功能的误区.doc

1、在实际应用中，用例是非常容易被误解和误用的。尤其是习惯了面向过程结构化 设计方法的计算机技术人员，最普遍的理解错误时认为用例就是功能的划分和描述。他们认为一个用例就是一个功能点。在这种理解下，用例建模变成了仅仅是较早前需求分析方法功能抠图翻版。很多人用用例来划分子系统、功能模块和功能点。如果这样，用例根本没有存在的必要，有功能框图就行了。请特别注意：虽然在用例是捕获功能性需求的，但是有一个前提条件，即这个功能性需求是从参与者的角度出发的，用例并不是功能。如果用例不是功能的话，它是什么呢？从定义上说，能给使用者提供一个执行结果的活动，不就是功能吗？很不幸，这个理解是错误的！功能是计算机术语，它是

2、用来描述计算机的，而非定义需求的术语。功能实际描述的是输入 - 计算 - 输出。这让你想到了什么？DFD图？这可是典型的免息那个过程分析模式。因此把用例当做功能点的做法实际是在做面向过程的分析。抛开面向对象还是面向过程不说，虽然功能和用例很类似，但是从本质上来说功能和用例是完全不同的。为了解释这个问题，我们需要从描述事物的方法入手。在描述一个事物的时候，我们可以从以下三个观点出发：1、这个事物是什么？2、这个事物能做什么？3、人们能够用这个事物做什么？例如，描述一辆自行车的时候，我们通常这样说明：第一，自行车是一种交通工具，它由传动系统、刹车系统等部分组成；第二，自行车可以骑行，可以载物；第三

3、，人们可以用双脚蹬动踏板向前行进，可以用手捏合刹车使自行车停下来。第一种描述是一种结构性观点，即事物的客观存在。但是这个观点不能够说明事物的作用，也就是功能性方面的信息。从结构上来说，同样是一个圆环，把它用在汽车上，它可以是方向盘，把它用在自行车上，它就是轮子了。所以仅有结构性观点是不够的。第二种描述是一种功能性观点，说明事物可以利用的价值。但是这个观点不能够说明事物在某种情况下的真实价值，也就是它缺乏上下文环境，没有人来使用，事物的所有利用价值可能是无意义的。换句话说，没有人使用的功能是没有意义的。第三种描述是一种使用者观点，说明事物对于使用者的意义，以及使用者可以怎么使用它，得到什么样的利

4、益。这种观点不能够说明事物的本质结构，它只是从表面揭示了事物相对于使用者来说是什么，能做什么，可以获得什么。对于一件我们早已熟知的事物来说，我们大可以随便从这三个方面的观点来描述，把事物解释清楚，例如自行车这种天天可以看到的东西。但是如果我们要描述的事物是我们并不熟悉的呢？对于一个陌生的事物，我们不大可能先从结构的角度去解释它，顶多可以通过观察假定出这个事物能做什么，再进一步，如果这个事物是现在还不存在的呢？例如正准备研制一种全新的药品。对于一个还不存在的事物，我们既不能从结构上去解释它，也不能够确定到底能做什么。举个特别的例子，Viagra 本来是辉瑞公司研制生成的一种治疗心绞痛的药物，可现

5、在 Viagra 变成了人尽皆知的伟哥。这不是因为它能治疗心绞痛，而是人们都用它来治疗 ED，大出乎研究人员的初衷。所以对于创造一种还不存在的事物，最好的方式就是从使用者的观点出发，描述希望这个事物使用者能用它做什么，能获得什么。软件恰恰就是一种还不存在的事物。对于正准备开发的软件，我们不能从结构观点去描述它，也不能从功能观点去描述它，最好的方法就是从使用者的观点去描述它。不能从结构观点去描述好理解，毕竟这是一个还没有做的东西，结构是未定的；不能从功能的角度去描述它，你可能心里一定犯嘀咕，不可理解，软件有什么功能不是显而易见的吗？真的如此吗？那么请你制造一个具有开启功能的东西。嗯？你不清楚究竟

6、要你做什么？好，让我从使用者观点再说明一下，请你制造一个东西，人们可以用它来开启酒瓶。现在清楚了吗？回到软件开发上来，从功能观点出发，采用功能分解方式来获取需求的方式，因为缺少了上下文，功能很可能就变成了对使用者无用的，或者使用者不知道怎么用的东西。客户想要一个开瓶器，你可能给客户送来一把钥匙，反而都是具有开启功能的呀。在软件开发过程中，经常出现开发完成之后客户不满意，认为这不是他们想要的东西，与其说是需求不清楚，不如说是方法不对路。因为在一开始，需求收集人员就没有从使用者的观点出发来描述系统，由于缺乏了使用者上下文，功能描述偏离使用者预期就是很正常的了。从使用者观点出发来描述软件则是非常合适

7、的。使用者观点告诉需求收集人员，他希望系统是什么样，他将怎样使用这个系统，希望获得什么结果。那么软件只需要按照使用者的要求提供一个实现，就不会偏离使用者的预期。至于功能性观点和结构性观点，则可以通过使用者观点推导出来。使用者观点实际上就是用例的观点。一个用例是一个参与者如何使用系统，获得什么结果的一个集合，通过分析用例，得出结构性的和功能性的内容，最终实现用例，也就实现了使用者的观点。通过上面的分析可以得出这样一些总结：第一、功能是脱离使用者的愿望而存在的。我们常说某某工具有某个功能，它是描述工具的，而不是站在使用者的角度描述使用者的愿望的。功能用来描述某某东西能做什么，它与使用者的愿望无关，

8、描述的是事物固有的性质。习惯于以功能来看待系统的团队，喜欢从系统的角度出发，说明系统能做什么，而常常系统能做什么并不是使用者关心的。用例是描述使用者愿望的，描述的是使用者对系统的使用要求，用用例来看待系统的团队，则是从使用者角度出发，说明使用者将在系统里做什么。第二、功能是孤立的，给一个输入，通过计算就有一个固定的输出 只要按下开关灯就亮。用例是系统性的，他需要描述谁在什么情况下将通过什么方式开灯结果是什么。功能描述是一个个点，如果要达成一个特定的目标，必须要在额外加上一个顺序的过程把点串起来才能完成一个系统性的工作。而用例描述的是一个系统性的工作，这个系统性的工作非常明确地去达成一个特定的目

9、标。习惯使用功能分析看待系统的团队，习惯从开发者角度出发，提供大量的功能点，指望客户像 UNIX 高手一样，自己从指令集中找到合适的指令来完成工作。而用用例来看待系统的团队，习惯从客户角度出发，为客户量身定制它们的要求。第三、如果非要从功能的角度解释用例，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对不同的应用场景，这些“功能”体现不同的组合方式。并且，不是先有了这些“功能”才来组合成某个场景，而是先有了场景，才分解出“功能”。这里的“功能”之所以打引号，是因为在 UML 里是没有功能这个词的，实际上从场景分解出来的对象，这些对象通过消息相互交流而完成场景。最后举一个例子。从功能的角度出发，对电视的描述是能开关，能显示，可以调频道，可以调声音，以上四者是独立的；从用例角度出发，对电视的描述是有一个人要观看电视节目的用例，要完成这个用例，第一步需要先打开开关，调到自己喜欢的频道，如果声音不合适，可以调节一下，以上三者是因人的需求而相关起来的。大家可以细细品味一下这其中的区别。