用力和功能的误区.docVIP

在实际应用中，用例是非常容易被误解和误用的。尤其是习惯了面向过程结构化 设计方法的计算机技术人员，最普遍的理解错误时认为用例就是功能的划分和描述。他们认为一个用例就是一个功能点。在这种理解下，用例建模变成了仅仅是较早前需求分析方法功能抠图翻版。很多人用用例来划分子系统、功能模块和功能点。如果这样，用例根本没有存在的必要，有功能框图就行了。请特别注意：虽然在用例是捕获功能性需求的，但是有一个前提条件，即这个功能性需求是从参与者的角度出发的，用例并不是功能。如果用例不是功能的话，它是什么呢？从定义上说，能给使用者提供一个执行结果的活动，不就是功能吗？很不幸，这个理解是错误的！功能是计算机术语，它是用来描述计算机的，而非定义需求的术语。功能实际描述的是输入 - 计算 - 输出。这让你想到了什么？DFD图？这可是典型的免息那个过程分析模式。因此把用例当做功能点的做法实际是在做面向过程的分析。抛开面向对象还是面向过程不说，虽然功能和用例很类似，但是从本质上来说功能和用例是完全不同的。为了解释这个问题，我们需要从描述事物的方法入手。在描述一个事物的时候，我们可以从以下三个观点出发：1、这个事物是什么？2、这个事物能做什么？3、人们能够用这个事物做什么？例如，描述一辆自行车的时候，我们通常这样说明：第一，自行车是一种交通工具，它由传动系统、刹车系统等部分组成；第二，自行车可以骑行，可以载物；第三，人们可以用双脚蹬动踏板向前行进，可以用手捏合刹车使自行车停下来。第一种描述是一种结构性观点，即事物的客观存在。但是这个观点不能够说明事物的作用，也就是功能性方面的信息。从结构上来说，同样是一个圆环，把它用在汽车上，它可以是方向盘，把它用在自行车上，它就是轮子了。所以仅有结构性观点是不够的。第二种描述是一种功能性观点，说明事物可以利用的价值。但是这个观点不能够说明事物在某种情况下的真实价值，也就是它缺乏上下文环境，没有人来使用，事物的所有利用价值可能是无意义的。换句话说，没有人使用的功能是没有意义的。第三种描述是一种使用者观点，说明事物对于使用者的意义，以及使用者可以怎么使用它，得到什么样的利益。这种观点不能够说明事物的本质结构，它只是从表面揭示了事物相对于使用者来说是什么，能做什么，可以获得什么。对于一件我们早已熟知的事物来说，我们大可以随便从这三个方面的观点来描述，把事物解释清楚，例如自行车这种天天可以看到的东西。但是如果我们要描述的事物是我们并不熟悉的呢？对于一个陌生的事物，我们不大可能先从结构的角度去解释它，顶多可以通过观察假定出这个事物能做什么，再进一步，如果这个事物是现在还不存在的呢？例如正准备研制一种全新的药品。对于一个还不存在的事物，我们既不能从结构上去解释它，也不能够确定到底能做什么。举个特别的例子，Viagra 本来是辉瑞公司研制生成的一种治疗心绞痛的药物，可现在Viagra变成了人尽皆知的伟哥。这不是因为它能治疗心绞痛，而是人们都用它来治疗ED，大出乎研究人员的初衷。所以对于创造一种还不存在的事物，最好的方式就是从使用者的观点出发，描述希望这个事物使用者能用它做什么，能获得什么。软件恰恰就是一种还不存在的事物。对于正准备开发的软件，我们不能从结构观点去描述它，也不能从功能观点去描述它，最好的方法就是从使用者的观点去描述它。不能从结构观点去描述好理解，毕竟这是一个还没有做的东西，结构是未定的；不能从功能的角度去描述它，你可能心里一定犯嘀咕，不可理解，软件有什么功能不是显而易见的吗？真的如此吗？那么请你制造一个具有开启功能的东西。嗯？你不清楚究竟要你做什么？好，让我从使用者观点再说明一下，请你制造一个东西，人们可以用它来开启酒瓶。现在清楚了吗？回到软件开发上来，从功能观点出发，采用功能分解方式来获取需求的方式，因为缺少了上下文，功能很可能就变成了对使用者无用的，或者使用者不知道怎么用的东西。客户想要一个开瓶器，你可能给客户送来一把钥匙，反而都是具有开启功能的呀。在软件开发过程中，经常出现开发完成之后客户不满意，认为这不是他们想要的东西，与其说是需求不清楚，不如说是方法不对路。因为在一开始，需求收集人员就没有从使用者的观点出发来描述系统，由于缺乏了使用者上下文，功能描述偏离使用者预期就是很正常的了。从使用者观点出发来描述软件则是非常合适的。使用者观点告诉需求收集人员，他希望系统是什么样，他将怎样使用这个系统，希望获得什么结果。那么软件只需要按照使用者的要求提供一个实现，就不会偏离使用者的预期。至于功能性观点和结构性观点，则可以通过使用者观点推导出来。使用者观点实际上就是用例的观点。一个用例是一个参与者如何使用系统，获得什么结果的一个集合，通过分析用例，得出结构性的和功能性的内容，最终实现用例