统一建模语言UML-3.ppt

1、,第4章 Use Case图,4.1 概述,4.2 活动者,4.3 Use Case,4.5 Use Case图的应用,4.4 Use Case的联系,所谓Use Case是指系统的外部事物（活动者）与系统的交互，它表达了系统的功能，即系统所提供的服务。 具体地说，Use Case是关于系统的一组动作的说明（Specification），这些动作对一个或多个活动者给出所需要的结果（值）。 Use Case用于为待开发的系统建立功能需求模型。 Use Case图是Use Case模型的图形表示，能准确地表达活动者与系统的交互情况和系统所提供的服务。 Use Case图是后续的系统分析与设计工作的

2、依据，也是系统测试的依据。 Use Case图对需求的描述规范化，较好地避免了表达的歧义性，便于用户和开发人员理解系统的需求，取得共识。 Rational统一过程主张采用Use Case驱动的软件开发方式。,4.1 概述,Use Case图示例，如图4.1所示。 一个有关金融贸易业务活动的Use Case图,图4.1 Use Case图示例,4.2.1 系统范围与系统边界,4.2.2 活动者,4.2.3 活动者的确定,4.2 活动者,系统（System）是指由多个系统元素有机地结合在一起，并执行特定的功能以达到特定目标的集合体。计算机系统是用于解决某个特定的领域问题的。 系统分析的首要任务是问

3、题识别，明确系统范围，划分系统边界，确定系统的责任。 系统范围（System Scope）是指系统的问题域的目标、责任、任务和规模，以及系统应提供的服务。 系统边界（System Border）是指一个系统的所有系统元素与系统以外的事物的分界线。 系统的范围与边界取决于开发的目标、任务和规模。,4.2.1 系统范围与系统边界,活动者（Actor）是用户作用于系统的一个角色（Role）。 活动者用来建立一个系统的外部用户模型，活动者直接与系统交互作用。活动者是对系统边界之外的对象的描述。在系统边界之外的是活动者。 活动者对系统的交互包括信息交换（数据信息和控制信息）和与系统的协同。 活动者包括人

4、活动者（Human Actor）和外部系统活动者（System Actor）。 系统的用户是人活动者。 活动者不一定是人，它也可以是一个外部系统，该系统与本系统相互作用，交换信息。,4.2.2 活动者,活动者运行Use Case，获得系统的某项服务。一个活动者可以运行多个Use Case，而一个Use Case可以由多个活动者运行。 一个活动者与其他的活动者可以有泛化联系，即一个活动者可以继承一个更一般的活动者的特性。 活动者的图形表示如图4.3所示。,图4.3 活动者的表示图形,活动者名,Use Case图示例项目与资源管理系统，如图4.2所示。,图4.2 项目与资源管理系统的高层Use C

5、ase图（活动者）,Use Case概念的创始者Jacobson提出了在确定活动者时应考虑的一些问题： 每一个活动者的主要任务是什么。 活动者是否要读、写或修改系统中的信息。 活动者是否应把系统外部的有关变化通知系统。 活动者是否期望系统把意外的变化通知自己。 这些问题对于确定活动者有一定的启发作用。,4.2.3 活动者的确定,确定活动者首先应明确系统的范围，并从应用的角度考虑系统的作用，确定将有哪些外部事物与系统进行交互。 凡是与系统进行信息交换（包括数据信息和控制信息交换）的外部事物可以确认为活动者。 系统的外部事物包括：人员、设备、外部系统。 凡是直接使用系统的人员可以确认为活动者。 某

6、些设备与系统相联，直接向系统提供外界信息或在系统的控制下运行，可以确认为活动者。 凡是与系统相联，并与系统交互的外部系统，可以确认为活动者。,4.3 Use Case,4.3.1 Use Case概念,4.3.2 业务Use Case与系统Use Case,4.3.3 Use Case图,Use Case是对系统的用户需求（主要是功能需求）的描述，Use Case表达了系统的功能和所提供的服务。 Use Case描述活动者与系统交互中的对话。它可以用一系列的步骤来描述，这些步骤构成一个“剧本”（Scenario）。 “剧本”的集合就是Use Case。全部的Use Case构成了对于系统外部是

7、可见的行为的描述。 Use Case只描述活动者和系统在交互过程中做些什么，并不描述怎样做。 一个活动者可以运行多个Use Case，而一个Use Case可以有多个活动者运行它。但是，也有的Use Case很难有与它明确关联的活动者。,4.3.1 Use Case概念,例：一个网上商店，顾客购买商品的过程的Use Case可以用文字列表描述如下。 购买商品 （1）顾客浏览查询产品分类目录，找出所需要的产品。 （2）顾客准备结算。 （3）顾客填写购货信息（产品信息，数量、送货地址、送货日期）。 （4）系统显示价格和应付款项。 （5）顾客填写信用卡信息。 （6）系统检查信用卡的有效性，确认交易成

8、功。 （7）系统确定发货时间，发出发货通知。 （8）系统发确认成交的电子邮件给顾客。 异动处理：信用卡有效性检查失败。 本Use Case包含了两个剧本：成功的商品交易的 “购买商品” 剧本，“信用卡有效性检查失败”的剧本。,业务Use Case 是指系统提供的业务（Business）功能与活动者（用户）的交互，表现问题领域中各实体之间的联系和业务往来活动。 业务Use Case用于建立问题领域的业务Use Case模型。 系统Use Case 是指活动者与系统的交互，它表现了系统的功能需求和动态行为。 系统Use Case用于建立系统的Use Case模型。 每一个业务Use Case都要由

9、一组系统Use Case支持。 在系统开发的开端阶段，应把注意力集中在业务Use Case上，在精化阶段和构建阶段再考虑系统Use Case。,4.3.2 业务Use Case与系统Use Case,Use Case图是系统的一个功能模型。它提供计算机系统的高层次的用户视图，表示以外部活动者的角度来看系统将是怎样使用的。 一个Use Case图包含活动者、Use Case，以及它们之间的联系，如图4.2所示。 Use Case的图标如图4.4所示。 活动者与Use Case之间的联系用实线表示。 Use Case与Use Case之间的联系可以用实箭线或虚箭线表示。,图4.4 Use Case

10、的表示图形,4.3.3 Use Case图,按照抽象层次，Use Case图可以划分为系统层（最高层）、子系统层和对象类层（最低层）。 系统层Use Case图描述系统提供的全部服务。 子系统层Use Case图描述子系统提供的服务，它的外部交互者可以是其他的子系统或高一层的活动者。子系统层又可以划分为多个层次。 对象类层的Use Case图描述对象类提供的功能片或操作，它的外部交互者可以是其它对象类或高一层活动者。 在系统的开发过程中，Use Case图可以自顶向下不断精化，抽象出不同层次的Use Case图。,4.3.3 Use Case图,例：图4.2是项目与资源管理系统PRMS的高层U

11、se Case图，它的每一个Use Case都可以且应当演化出更为详细的Use Case图，如图4.5、图4.6、图4.7所示。,图4.5 资源管理Use Case图,图4.7 系统管理Use Case图,图4.6 项目管理Use Case图,4.4.1 泛化关联,4.4.2 使用关联,4.4.3 包含关联,4.4.4 扩展关联,4.4 Use Case的联系,泛化代表一般与特殊的关系。一个Use Case与另一个Use Case相似，但做的内容更多，则该Use Case与另一个Use Case存在着泛化关联（Generalization Association） 。 具有泛化关联的两个Use

12、 Case中，一个是基本的Use Case，另一个是更为一般的（泛化）Use Case，基本Use Case的实例包含了一般Use Case的功能行为，此外还有自己的功能行为。 泛化关联用泛化箭线（带空心三角箭头的实箭线）表示，从基本Use Case发出，指向一般Use Case，如图4.8（a）所示。 泛化关联也可以存在于活动者之间，表示一个一般性的活动者与另一个更为特殊性的活动者之间的联系，如图4.8（b）所示。,图4.8 泛化关联的图形表示,4.4.1 泛化关联,使用关联（Use Association）指一个Use Case使用另一个Use Case的功能行为。使用关联用于在Use C

13、ase间共享公共的功能行为。 使用关联是一种泛化关联，在Use Case图上用一个从基本Use Case指向公共Use Case的泛化箭线表示，并在箭线上标有构造型，如图4.9所示。 在UML 2.0中，使用关联已经由包含关联所替代。,图4.9 使用关联的图形表示,4.4.2 使用关联,包含关联（Include Association）是指一个基本Use Case的行为包含了另一个Use Case的行为。 包含关联是一种依赖关联，在Use Case图上用一条从基本Use Case指向被包含的Use Case的虚箭线表示，并在箭线上标有构造型，如图4.10所示。,图4.10 包含关联的图形表示,

14、4.4.3 包含关联,扩展关联（Extend Association）的基本含义与泛化关联类似，但有更多的规则限制。 基本的Use Case必须声明若干“扩展点”，而扩展Use Case只能在这些扩展点上增加新的行为。 扩展关联在Use Case图上用一条从基本Use Case指向扩展Use Case的虚箭线表示，并在箭线上标有构造型，如图4.11所示。 一个Use Case可以有多个扩展点，扩展Use Case可以扩展一个或多个扩展点。,图4.11 扩展关联的图形表示,4.4.4 扩展关联,4.5 Use Case图的应用,4.5.1 Use Case的确定,4.5.2 建立Use Case

15、模型,确定Use Case时必须考虑活动者对系统的服务功能的要求以及活动者与系统的交互过程。 在标识Use Case时需要考虑的问题如下： 对于每一个已经确定的活动者，系统将有一些什么任务，提供什么服务。 在系统中是否需要传递信息给活动者。 活动者是否需要通知系统某些突然的外部变化。 系统是否为领域业务提供了正确的行为。 Use Case的运行特征是否标识出来了。 Use Case将支持和维护的系统功能是什么。,4.5.1 Use Case的确定,Use Case的种类大体如下： （1）系统的开始和停止的Use Case。 （2）系统维护的Use Case。 如添加新用户，设置用户的操作模板（

16、profile）等。 （3）维护系统中存储数据的Use Case。 如所建造的系统要与现存的系统数据同步。 （4）修改系统行为的功能的Use Case。 如创建一个新报表，而不是对一个一个的报表进行单独的编程。,注意Use Case的大小。 不要只用一个Use Case就把一个系统或子系统的功能行为全部包括在内，也不要把Use Case划分得过于琐碎细小。 一般应该把系统或子系统中主要的业务流找出来，对每一个业务流建立一个相应的Use Case。 为业务处理的各种例外（异常）情况的事件流单独建立一个相应的Use Case。,应当先建立业务Use Case模型，然后再从业务Use Case模型向

17、系统Use Case模型映射。 注意Use Case图的层次，从系统到子系统逐层建立 Use Case图。,图4.12 Use Case图的层次,4.5.2 建立Use Case模型,可以按下列步骤建立Use Case图： （1）找出系统外部的活动者和外部系统，确定系统的边界和范围。 （2）确定每一个活动者所期望的系统行为。 （3）把这些系统行为命名为Use Case。 （4）把一些公共的系统行为分解为一批新的Use Case，供其他的Use Case引用。把一些变更的行为分解为扩展Use Case。,（5）编制每一个Use Case的剧本，其中须详细描述基本业务流（Basic Flow）、替代业务流（Alternative Flow）和例外（异常）情况的事件流，以及制约业务流向的必要的前置条件和后置条件。 （6）绘制Use Case图。 （7）必要时可以把表达例外（异常）情况的事件流的Use Case画成一个单独的子Use Case图。 （8）精化Use Case图。解决Use Case 间的重复与冲突问题，简化Use Case中的对话序列。Us