如何应用UML用例图描述软件系统的用户需求

用例图当然很好用，不然RUP（Rational Unified Process，统一软件开发过程，统一软件过程)也不会让用例驱动作为核心方法论之一，当然用例图自身也有很多不足，需要其它技术作补充。一、优点：简洁、直观。是的，确实比较直观，几个小人人、几个椭圆，外加几条不多的线，用一个矩形一框就出来了，了不起再弄个用例描述，系统交互行为很清晰地表达出来。规范、易理解。用例图是UML建模里比较常用的一个图，你用，我用，大家都用，并且标识、要素等均符合UML2中的约定，并且不依赖开发语言，所以说它和其它图一样规范因为规范所以对UML建模用户来说是易理解的。用户导向、描述精准。用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。我们不管系统内部实现功能的机制，仅仅把系统看作一个黑盒，然后参与者与其进行交互，也就是用例是基于用户场景的，所以能更精准地表达用户功能需求。需求与设计分离。因为用例图是站在系统外的视角描述系统需求的，所以并没有介入到系统内部实现细节，这就让需求和设计工作分离开来，条理清晰。便于设计测试用例。用例图描述的就是一个用户场景，测试设计人员正好可以根据用例图设计测试用例。边界清晰。一个矩形框把系统边界清晰、明确地表达出来，便于设计人员据此把握系统范围。敏捷。用例图允许我们讲故事、写卡片，允许我们比较敏捷地实现功能需求方面的管理与交流。二、不足：不能表达非功能需求。用例图是描述用户功能需求的工具，对于可靠性、性能等非功能需求无能为力。对不懂UML的客户或程序员来说难以理解。对UML支持者来说，用例图可能是规范的、清晰的、简单的、易理解的，但对并未掌握UML建模技术的人来说理解那些椭圆并非易事，再说还有一系列如同伪代码似的事件流。粗粒度。是的，用例图不涉及设计实现细节，只是一个功能划分，粒度非常粗，很多细节无从描述，需要用其他工具进行辅助说明。三、常见的错误用法和问题：客户看不懂用例图，又要提供一个高大上（画UML图）的需求规格文档。这时候怎么办呢？作者建议画客户需要画的，然后把用例图制作成一个个卡片去跟客户讲故事，客户不会连故事都听不懂吧除非你讲故事的水平比画图的水平还拙劣。架构师或程序员看不懂用例图。看不懂的话这些用例委实就成了摆设，这时又该怎么办呢？对的，仍旧讲故事，说业务场景并用用例规约加以辅助说明。用例图涉及到实现细节。这个要加以避免，如果过早介入系统内部实现细节，过多的系统内部设计描述会让客户和程序员疲惫不堪。系统边界模糊不清。建议用例图绘制时从上往下画，比较复杂的子系统可以拆在不同的用例图中。用例过多。系统总的用例数不宜超过50个，建议最好是20-30个。过多的用例必定会有过多的Association、include、extend、generalize等关系，各种关系错综复杂违背了我们使用用例图的初衷。

用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)

包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。　

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

2、扩展(extend)

扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

对于一个扩展用例，可以在基用例上有几个扩展点。

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

4、泛化(generalization)

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

1数据流图（Data Flow Diagram）； 坚持更DFD，它从数据的传递和加工角度，以图形方式来表达系统的逻辑功能，数据在系统内部的逻辑流向和逻辑交换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示放大。

它是描绘信息流和数据从输入移动到输出的过程中所经受的变换。数据流图的基本元素： 2系统流程图（System Flowchart）； 描绘系统物理模型的传统工具。他的基本思想是用图形符号以黑盒子的形式描绘系统理念的每个部件包括程序，文件，数据库，表格，人工过程等，表达信息在给个部件之间流动的情况，而不是表示对信息进行加工处理的控制过程。例图： 3程序流程图； 4程序的系统结构图。数据流程图：反应输就走向，它不考虑时序关系，主要用于业务分析，用作详细设计。途中的有向线段表示了数据流。系统流程图：反应主体框架。程序流程图：程序逻辑描述程序中控制流的情况，即程序中处理的执行顺序和执行序列所以来的条件，途中的有向线段表示的是控制流从一个处理走到下一个处理。程序的系统结构图：反应的是系统中模块的调用关系和层次关系，谁调用谁有一个先后次序关系。途中的有向线段表示调用时程序的控制从调用模块一道被调用模块，并隐含了当调用结束时控制将交回给调用模块。

需求分析阶段：如果是结构化程序设计有：

DFD表示数据和 *** 作的关系；

事务流图还有判定表

如果是面向对象程序设计：

UML中的类图，用例图，活动图等

概念设计阶段：E-R图，类图也可以等

详细设计阶段：RTM

；实例图，类的活动图，等

编码阶段：类图，包图，等

测试阶段；测试用例

用例是契约，是系统中利益相关人（Stakeholder）就系统行为所达成的契约，它通过半结构化的自然语言描述了在不同条件下，系统对某一利益相关人发起的请求作出响应时应当发生哪些系统行为。从中可以看出，用例是站在系统外部来看待系统和定义系统的。因此，如果是系统自己完成的事，应当属于用例中的步骤，而不是单独的用例。当然，如果是系统定时自动启动的任务，如没隔30秒自动扫描发送短信通知，则属于定时用例。此时，ACTOR是定时程序。

以上就是关于如何应用UML用例图描述软件系统的用户需求全部的内容，包括:如何应用UML用例图描述软件系统的用户需求、复杂功能分解为小功能的用例图是什么关系、系统用例图是结构化分析技术吗等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！