软件工程-第12章第3节

12.3用例模型

在软件开发过程中，分析典型的用例是软件开发者了解用户需求的有效方法之一。这是用户和开发者共同分析系统需求的良好开端。在OOSE方法中首次提出了用例图的概念，UML也采纳了用例图的概念。12.3.1用例图1.作用在用户需求分析中，如何找用户目标，如何通过系统交互实现用户目标，如何表达这些概念，一直是难以解决的问题。引入用例的概念来进行需求分析，这是面向对象分析技术进入第二代的标志。12.3.1用例图

用例图描述了系统的功能需求，它从参与者的角度来理解系统，用于获取系统的需求、规划和控制项目；用例图还描述了系统外部的参与者与系统提供的用例之间的某种联系(用例图着重于从系统外部参与者的角度来描述系统需要提供哪些功能，指明这些功能的参与者是谁)；用例图驱动了需求分析之后的各个阶段的工作。

用例图的元素有用例、参与者和连接。12.3.1用例图2.用例用例是用户与计算机之间为达到某个目的而进行的一次交互作用，即系统执行的一系列动作。动作执行的结果能被指定的参与者见到。用例描述了用户提出的一些可见的需求，它实现了一个具体的用户目标。12.3.1用例图用例由参与者来激活，并提供确切的值给参与者。用例可以简单也可以很复杂，但必须是一个具体的用户目标实现的完整描述。用例的图形表示为一个椭圆，椭圆中标注用例名。用例的表示如图12.2(a)所示。12.3.1用例图图12.2用例图的元素12.3.1用例图3.参与者参与者是用户在系统中所扮演的角色。参与者可以是人、组织和外界系统，参与者执行用例。一个参与者可以执行多个用例，一个用例也可由多个参与者使用。对一个大系统来说，应先列出参与者，对每个参与者列出它的用例，参与者对提供用例是非常有用的。参与者是建立在类概念基础上的一个构造型模型元素，其语义是与系统用例相关联的系统之外的对象类。参与者的图形表示是一个“小人”，在其旁边标注参与者的名字。参与者的图形表示如图12.2(a)所示。12.3.1用例图4.连接用例图中用例元素与参与者元素之间、用例元素与用例元素之间的联系称为连接。用例图中有三种连接，即通信联系、使用和扩展。1)通信联系通信联系是指参与者与用例之间的联系。参与者触发用例，与用例交换信息，用例完成相应功能后，向参与者返回结果。通信联系由参与者与用例之间的连线来表示。通信联系的表示如图12.2(a)所示。12.3.1用例图2)使用使用是指用例之间的关系。当几个用例存在相同的动作时，为避免重复，把相同的动作构造成另一个用例，则该用例与这几个用例之间的关系就是使用关系。使用关系是UML预定义的构造型模型元素，它是泛化关系的构造型模型元素。使用关系的图符表示与泛化关系的图符表示一样，用带空心三角形的连线表示，在连线上标注《使用》。使用关系的表示如图12.2(b)所示。12.3.1用例图3)扩展扩展是指用例之间的一种关系。有两个用例Ａ和Ｂ，Ａ与Ｂ功能相似，但是Ａ的动作比Ｂ的动作多一点，则Ａ与Ｂ之间的关系是扩展关系，Ａ扩展Ｂ。扩展关系也是泛化关系的构造型模型元素，也是预定义构造型模型元素。扩展关系的图符表示与使用关系的图符表示相同，只是在扩展关系的连线上标注《扩展》。扩展关系的表示如图12.2(c)所示。12.3.1用例图扩展与使用之间有相似之处和不同之处。这两者都从几个用例中抽取公共的行为放入一个单独的用例中，以便其他几个用例使用或扩展。但是这两个关系的目的是不同的。可采用下列方法来区别应使用哪种关系。当描述一般行为的变化时，采用扩展；当在两个或多个用例中出现重复描述而又想避免重复时，采用使用。12.3.2画用例图用例模型是获取需求、规划和控制项目迭代过程的基本工具。用例的获取是主要的任务之一，这也是项目的初始阶段首先要做的工作。1.获取参与者建立用例模型时首先要找出系统的参与者。可以通过用户回答一些问题来识别参与者。这些问题如下：12.3.2画用例图(1)谁使用系统的主要功能？(2)谁需要系统支持他们的日常工作？(3)谁来维护、管理系统使其能正常工作？(4)系统需要控制哪些硬件？(5)系统需要与其他哪些系统交互？(6)对系统产生的结果感兴趣的是哪些人或哪些事物？12.3.2画用例图2.获取用例获取了参与者之后，要对每一个参与者提出一些问题，从参与者对这些问题的回答中寻找用例。这些问题如下：(1)参与者要求系统提供哪些功能？(2)参与者需要读、产生、删除、修改或存储系统中的信息有哪些类型？(3)必须指出参与者的系统事件有哪些？(4)参与者必须指出的系统事件有哪些？如何把这些事件表示成用例中的功能？12.3.2画用例图除了针对参与者的问题而外，还有针对系统的问题，对这方面问题的回答也可以帮助获取用例。这些问题如下：(1)系统需要何种输入/输出？(2)系统的输入从何处来？输出到何处去？(3)当前系统的运行存在什么问题？12.3.2画用例图3.用例的数量在建立用例模型时，一个项目要获取多少用例才合适呢？不同的设计者选取用例的数目也不相同。用例数量大，则每个用例较小，较小的用例在执行实施方案时比较容易，但是用例数量过多，则用例过于繁杂，因此用例的数目要适中。对于一个10人年的项目，20个用例可能有些少，100个用例可能有些多。应保持项目规模和用例数目两者之间的平衡。12.3.3用例图的示例金融贸易系统的用例模型如图12.3所示。其中有四种参与者，即贸易经理、营销人员、销售人员和记帐系统。12.3.3用例图的示例在该系统中，基本的用例是“进行交易”。在一次交易中，可能进行得比较顺利，也可能进行得不顺利，存在扰乱顺利进行交易的因素。其中之一便是某些指标超出边界值的情况。例如，贸易组织对某个特定用户规定的最大贸易量。这时不能执行给定用例提供的常规动作，可对进行交易的用例做些改动。图12.3中的“超越边界”用例就是“进行交易”用例的扩展。在营销人员交易过程中还用到“风险分析”和“交易估价”两个用例，而这两个用例中都包含有公共的评价动作，因此把“评价”作为一个独立的用例.12.3.3用例图的示例销售人员使用“进行交易”和“交易估价”两个用