拥抱敏捷的用例分析方法

引言

用例分析方法的传播与UML和RUP的关系密不可分。笔者当年学习用例分析最主要的并不是根据那两本UML经典书《UML用户指南》、《UML参考手册》，而是根据RUP更多一些。2003年前后，UML貌似是当时的热点，但可惜的是，历经了近10年，UML的使用并没有像当初预期的那样流行。而RUP的声音在最近几年也是渐渐沉寂。原先的用例分析方法是RUP中与其他工作联系最紧密的一个环节，RUP中的4+1视图是以用例视图为中心的，用例分析的不少具体做法是为了RUP后续工作服务的，看起来用例分析方法就是RUP中不可分割的一部分，所以用例分析方法貌似随着UML和RUP也在沉寂。 随着敏捷软件开发的传播，用户故事（User story）也随之传播，大有取代用例分析方法之势，或者说已经取代了。但是用例分析方法的优势也许被埋没了。本文试图介绍一种拥抱敏捷的用例分析方法，把用例分析方法从RUP中分离出来，能够为敏捷开发所用。

用例分析的职责

一个小人 和一个椭圆连根线组成了用例分析最基本的单元，简单理解用例的话，其实并不复杂。但如果用例分析的目的是下面这些：

· 找出用例中的执行流程、事件的各个类。

· 通过实现用例，把用例的行为指定到具体的类。

· 找出类的责任、属性和他们相互的关系。

· 规范地确定系统中各用例的职责。

· 在用例设计的时候，把业务概念抽象成类、对象、关系、组件、接口等等，这些都与目标系统直接对应。

以上目的也许已经吓退一半以上的初学者。这样目的的用例分析承担了过多的职责，对用户来说是不能理解用例之后的类的，对开发者来说，这些个要求未免也高了点。所以用例分析应当回归到需求分析层面，能够把用户需求交代清楚，已经是天下难事，就不必承担什么类的识别这样的额外任务了。

单一职责是OO当中的概念，引申到用例分析，它的职责定位在了解用户的需要，那么就应当把这个职责作为它的唯一职责。在用例分析时，不必考虑具体实现的类，专注于把用户需要表达出来。

从SRS看用例和用户故事

SRS是software requirement specification的缩写，中文译为软件需求规格书。SRS在当年曾经进入了ISO标准，在中国进入了国家标准，出现在大量的软件工程教材当中。根据SRS的要求，有不少SRS的文档模板。SRS在整体上给出了要求，但在具体需求方面并没有给出表示方法，因而大量的实践是各种格式的文字，每家组织提供的SRS在大样子上是相似的，但在具体需求方面表达方式各异。

用例方法给出了用例规约的写法，展现了具体需求，用例规约对于细节的展现能力是很棒的；用户故事同样对具体需求给出了写法。在这点上后来的这两个方法就要比SRS考虑得更加周到。

在传统软件开发当中，SRS要求是完备的、充分的，能够指导后续设计开发。SRS虽然也能处理后续需求变更，但变更处理耗时耗力，很不灵活，很不敏捷。而用例分析所带来的文档在这方面是与SRS有相同的感觉，虽然RUP也强调迭代，精化，但还是要求用例规约能够完备，详细。不少组织在采用用例分析方法时，往往是从SRS转到用例分析，看到了用例分析对于需求细节绝佳的展现能力，认为这是用例分析较之于SRS的优势，不可避免的把完备、详细的要求带到了用例分析当中。根据敏捷宣言以及现在对需求冻结实践的总结回顾，现在已经清楚的知道：需求变更是不可阻挡的，前期完备详细的需求未必能指导后期开发，甚至可能成为负累。

而用户故事就是来自于敏捷开发的，天生注重响应变化和可运行。所以可以看到，用户故事既能展现具体需求，又不要求完备充分，讲究刚刚好的表达，鼓励拥抱变化。

用例分析也可以追求刚刚好的需求表达，不必像SRS一样要求完备和详细。

条目化管理的需求

常见的SRS可能是一份数十页甚至上千页的文档，用例分析形成的文档一般是UML工具生成的文件。而用户故事形成的文档天生是条目化管理的。同时拥有具有如下的优点：

1， 逐条表达，可以逐条修改，如果有工具支持，可以让多个人同时修改；

2， 方便跟踪，如果是在白板上，可以方便的移动；

3， 方便检索 ；

4， 如果有工具支持，能够记录变更的所有历史。

而UML工具生成的文件相比于用户故事就显得不方便。如果用例也能够条目化管理，就也能获得以上的好处。虽然现在没有现成的工具同时支持用例图和用例的条目化管理，但组合两样工具就能方便的获得。具体方法是利用条目化管理工具（比如Mantis，VSTS，JIRA，ClearQuest等，纸片+白板也是工具之一）记录用例，字段设置参照用例规约的要求，但注意这些字段大都允许为空，并加设状态字段，常用的状态字段有“新建”、“采纳”、“活动”、“完成”。利用UML工具来绘制用例图和用例相关的其他图（比如活动图，泳道图），用例图是帮助理解需求的绝佳工具，但不是所有的用例都要在用例图上出现的，只需要把需要的用例绘制在用例图上，如果用例之间关系并不复杂，不用画用例图也是完全可能的。在两个工具之间协作用例，唯一需要注意的是要保证用例命名的一致性。

承载的信息

Mike Cohn推荐的用户故事的基本格式如下。

As a <type_of_user> I want <some_goal> so that <some_reason>.

在实际使用时，更多见的是

作为[什么类型用户]，我想要 [做什么]，这样就可以[达到什么目标]

就这句话而言，对用例了解的朋友就能想到一个小人连着一个椭圆，小人就是这个用户，用例的名称就是“做什么”，而用例规约中的目的就是“达到什么目标”。

用户故事能够扩充，可以加上场景描述，可以加上测试确认条件等等。这些对于用例来说，不是难事。用例规约可以提供足够的空间来记录任何描述，有不少现成的方法来使用基本流和备选流来描述场景。如果工具支持，可以直接将测试确认条件写成于用例关联的测试用例。

所以，用户故事所能承载的信息并不比用例多，利用用例完全能够承载用户故事所含有的信息。如果把用户故事转换到用例，可以做到信息无损。

用例分析的优势

用例除了能够承载以上提到的信息之外，还有用例图，能够清晰的表达多个角色和多个用例之间的关系。比如下图所示，用例图能够带来更为清晰的业务理解。

用例分析对后续的工作更有指导作用，虽然前文指出放弃用例分析对后续设计的指导目的，只需专注于需求，但仍然给后续的设计编码有更清晰的指导，对于已经了解RUP和OOAD的朋友来说，处理用例更是轻车熟路。

当对用例规约的各个字段（基本流、备选流、前置条件、后置条件、特殊需要、扩展点等等）提出强制要求时，往往把这些看成是繁琐的、麻烦的；但如果是根据需要可选的，那么也就可以看到“用例分析方法拥有丰富的细节表现力”。

总结

经过以上的分析修改，用例分析不再是为RUP服务的一个环节，只专注于表达用户需要，不再承担原来Rational 4+1视图中所意味的繁重职责。不再为了分析得到某个类而纠结于对应的用例规约应当如何写。

用例分析的文档也不再求全责备，而是根据刚刚好的原则，像用户故事一样，用户没有说到的地方可以留空，不再强求用户一定要说清楚。根据已经获得的用户需要来更早的获得可运行的软件。

用例不再位于某个UML文件中的某个角落，而是在一个可以方便检索、修改的条目化管理系统中（包括白板+纸片）。

所以，对于已经采用用例分析的组织，没有必要改成用户故事，对用例方法进行像前文所诉的适应性修改，就能获得敏捷开发的好处，也能保留用例分析的优势。

对于已经采用用户故事的组织，不妨看看用例分析方法，用例分析方法拥有丰富的细节表现力，能清晰的展现业务逻辑过程全景，对关键流程不妨采用泳道图，对复杂业务全景不妨采用用例图。