谈谈用例模型的那些事儿 之 用例图

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

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

 

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

 

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

 

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

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

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

如何建立用例模型

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

一．用例图

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

 

1.用例

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

 

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

 

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

封装性是面向对象设计的重要思想之一。而实现封装的前提之一，就是要对需求进行整理的基础上加以功能划分，使具有强烈相关性的功能划分在一起，只有少量接口与外界交互。用例分析，从一开始就对原始需求进行了功能划分，将相关功能划分到一起，将共有功能提取出来，标志出功能间的依赖与非依赖关系（包含表示的是一种依赖关系，而扩展表示的是一种非依赖关系）。这是一种OOA/D，它为日后的OO设计提供了强有力地支持。而这些都是需求规格说明书所不具有，或者不完全具体的功能。

 

2.参与者

现在再来说说参与者。参与者给大家最直观的认识就是操作这个系统的那些人，但更准确的说应当是操作这个系统的那些角色。用例模型要求我们描述清楚系统中的每一个场景的每一步操作，操作者是谁。同时，我们关注的这个操作者并不是某个具体的人，而是一群有着相同职责的人，即角色。用例模型中对参与者的分析，为我们之后在开发过程中，进行功能、角色、用户的划分提供了依据。

 

用例模型中的参与者，除了表示操作系统的人，还表示处于系统边界之外，与系统边界内的用例有关联的其它系统。因此，只有定义好一个系统的边界，才能定义哪些是这个系统内的用例，哪些是这个系统内外的参与者。用例模型对本系统与其它系统相互关联的分析，为我们日后开发过程中，为其它系统提供接口，或与其它系统进行接口，提供了依据。

 

参与者之间的关系只有一种——继承关系，表示功能职责上的继承。譬如，通常软件系统中都有“普通操作者”，代表的是进入系统的所有用户都应当具有的功能。而软件系统又有很多“特殊职能者”，他们除了具有普通操作者的功能外，还有自己独特的功能。在这里，“特殊职能者”是对“普通操作者”的继承，继承了“普通操作者”的所有功能。然而，“特殊职能者”又有“普通操作者”不具备的，自己独特的功能。

参与者与用例之间是一种关联关系，即实线表示。通常，参与者与用例之间的关系不用定义导航关系（即画出箭头），但部分UML的书籍也定义了这种导航关系。如果参与者要使用用例，则箭头从参与者指向用例；如果参与者要接受用例提供的数据或查询结果，则箭头从用例指向参与者。

用例分析将参与者放到了一个十分显著的位置，同时还关注的参与者的期望（即“涉众利益”，在后面详细描述），这也是需求规格说明书所不具有的。

 

3.系统边界

系统边界是一个软件系统需要处理的整个问题空间的范围。一个软件系统不可能处理所有问题，我们必须得给它定义这个问题空间的范围。哪些是我们这个软件可以处理的，哪些则是我们这个软件不能处理的，也就是项目管理中所说的项目范围。与需求规格说明书相比，用例分析通过图形的方式，更加明确地定义出了项目范围，以及与其它系统之间的关系，使其更加清楚明了。

 

相关文章：

《 谈谈用例模型的那些事儿 之 用例说明 》

《 谈谈用例模型的那些事儿 之 注意什么 》

评论

3 楼 fangang 2011-11-03  

操作系统的那些角色=>操作这个系统的那些角色
呵呵，误会误会，添了2个字

2 楼 hotdust 2011-11-03  

文章写的通俗易懂，感觉就像是计算机界的科普读物一样。
一点点小建议：

引用

但更准确的说应当是操作系统的那些角色

操作系统这一词在文中用的较多，感觉如果用“使用系统”是否能好一些。
一看到“操作系统”就想到windows，呵呵。

1 楼 fangang 2009-10-14  

问：用例模型有一个比较麻烦和不好把握的地方就是用例粒度的大小如何进行合理划分，这个大帅后面的文章中是否能谈谈？

答：这着实是一个比较挠头的问题，谈谈我自己的见解吧。

我前面说过，用例大致可以理解成功能模块，这虽不准确但比较奏效，特别是在需求分析的初期。当我们初期开始绘制用例模型的时候，基本上是将系统分为几个模块，每个模块包含几个主要的功能。这几个模块就是几个场景，这几个主要的功能就是几个用例。绘制好以后，我们开始编写用例说明。（注意，不要期望一开始就能把所有的用例都画对，所有的用例说明都写完整，如果你还有这样的思想，说明你还没有摆脱瀑布式开发的束缚。）

然后，随着需求的深入，我们在编写一个一个的用例说明。当你发现，某个用例比较复杂，简单的描述不能把它说清楚，或者当你说清楚它时，已经花费了大量的篇幅。如果你遇到这样的情况时，你应当意识到这个用例需要要细化了。我们编写的用例说明必须清楚明了。客户在描述需求的常常模棱两可，我们必须解决这个问题。同时，我们编写的每个用例说明必须清晰，也就是不能太长，或者过于复杂。如果不能这样，就应当细化了。

细化一个用例，可以在原图上划分出一些子用例或扩展用例，也可以对这个用例描述的场景，单独绘制一张用例图。如果通过子用例或扩展用例能说清楚这个问题，则采用这种方式，否则，采用另启一张用例图的方式。

总之，用例的细化程度由需求的复杂程度来决定，最终的目的就是清楚明了地把需求描述清楚。