——对用例模型及其应用的一次有益的探讨

　　前言：这是一次对用例模型的探讨。怎样建立用例模型，怎样编写用例说明，它与需求规格说明书有什么区别，它能替代需求规格说明书吗？也许在这里可以找到你要的答案。

　　进入软件业稍微久一点儿的人恐怕都不会陌生，软件开发的最初阶段都是谈需求、写需求规格说明书。需求规格说明书是与客户最终确认到纸上的，非常正式的公文。软件开发应当做什么，做成什么样子，什么东西不做，项目范围有多宽，需求规格说明书都是白纸黑字写得清清楚楚，谁都无法抵赖。所以，需求规格说明书一直都是软件项目开发合同的重要附件，地位相当重要。

　　但是，随着RUP的引入，人们开始困惑了。在RUP中没有需求规格说明书，而是为用例模型所替代。现在，一些信息化走在比较前列的公司，都纷纷要求按照RUP统一过程进行开发，我们也开始尝试使用用例模型来替代需求规格说明书。然而，相信一些关于用例模型的几个重要问题一直困惑着不少人（当然也包括我）：用例模型与需求规格说明书的区别在哪里？用例模型的优势在哪里？用例模型能替代需求规格说明书吗？围绕着这几个问题我们进行一次用例模型的探讨之旅吧。

　　在开始我的探讨之旅之前，我们最好能带上一个问题去探讨：

　　用例模型与需求规格说明书的区别在哪里？

　　看到这个问题，你也许会非常不屑一顾，认为这个问题不值一提。确实，在编写格式上，用例模型与需求规格说明书的差别显而易见。但是，从更深层次来讨论，你会发现，这个问题并不是那么简单。有些人由于对用例模型的肤浅认识，将用例模型当成需求规格说明书来写，格式虽说是用例模型的格式，内容却不是用例模型的内容，换汤不换药，反倒弄巧成拙，让人困惑。需求规格说明书是面向过程时代的产物，因此它的核心就是按照面向过程的设计思想编写需求；用例模型是面向对象分析/设计的产物，因此它的核心思想就是OOA/D（面向对象分析/设计）。我认为，把握这一点实在太重要了。明白了它，才能明白用例模型应当怎样设计，才能明白它与需求规格说明书的区别，才能明白其作用和优势在何处。下面，我们看看用例模型应当怎么设计。

　　如何建立用例模型

　　一些初学者认为，用例模型就是画张用例图。其实这是错误的，用例模型包括用例图、用例说明，有时还要辅之一些简单的行动图、状态图和序列图。用例图采用图形的方式，形象生动地展现了用例、参与者和系统边界之间的关系。而用例说明，是对用例、参与者和系统边界进行的详细描述。在描述过程中，还可以对一些关键的流程，以及这些流程中关键类的状态变化，使用行动图、状态图和序列图进行图形化地展现。

　　一、用例图

　　用例图是建立用例模型的开始。用例模型的建立过程通常都是：先画用例图，然后对用例图编写用例说明。在编写用例说明的时候，对一些复杂的、认为有必要的地方，绘制行动图、状态图和序列图，方便阅读者理解。用例图关注的是三部分内容：用例、参与者和系统边界。

　　1、用例

　　用例就是一个用来描述参与者如何使用系统来实现其目标的一组场景的集合。这句话听起来比较抽象，但我通常都把它暂时理解为功能中的模块（虽然这并不严密，但更加实用）。用例强调的是一组场景，在这组场景不多但相互之间存在功能上的共性，就像一个大功能模块下的多个子模块。这组场景中的每一个，又分别形成一个个子用例。子用例再细分，又可以再形成各自的子用例。用例分析就是这样由粗到细的逐步细分，从而形成一系统的用例图。用例图分析到多细，应当由业务需求的情况决定。分得过粗，就不足以说清楚业务的相关细节，或者使一张用例图信息过多，影响人们的理解；分得过细，不仅会增加工作量，还会丢失许多用例间的相互关系，得不偿失。总之，较为复杂的部分细一些，简单的部分粗一些，保证每个用例图都保持强烈的相关性，指导日后的功能划分。

　　同时，用例强调的是参与者与系统功能的交互，用例就是系统的功能，而参与者可以暂时理解为使用系统的人。因此，大多数用例都对应着一个或数个参与者（但部分从用例中包含着的子用例，或扩展出来的扩展用例没有参与者）。

　　用例与用例之间通常有两种关系：包含与扩展。包含关系表示一种从属关系，即子用例是主用例中相对独立的、必须调用的一部分功能。在用例分析中，我们应当将多个用例都共有的、相对独立的功能提取出来形成一个子用例，为日后代码复用提供有力保障。扩展关系表示一个功能是对另一个功能的扩展，即被扩展功能不一定调用扩展功能，但扩展功能是对被扩展功能的加强与延伸。在绘制用例关系时，包含关系应绘制成从主用例指向子用例的虚线箭头，并标注为“include”，表示主用例包含子用例；扩展关系应绘制成从扩展用例指向被扩展用例的虚线箭头，并标注为“extend”，表示扩展用例是对被扩展用例的扩展。虚线箭头在UML中代表的是一种依赖关系，即客户元素了解供应者，并且供应者的变化会影响到客户元素（依赖是从客户元素指向供应者的）。