第5章 用例图电子课件

用例图

5.1用例图的基本概念用例图是表示一个系统中用例与参与者关系之间的图。它描述了系统中相关的用户和系统对不同用户提供的功能和服务。用例图相当于从用户的视角来描述和建模整个系统，分析系统的功能与行为。用例图中的主要元素包括参与者、用例以及元素之间的关系。此外，用例图还可以包括注解和约束，也可以使用包将图中的元素组合成模块。5.1用例图的基本概念5.2参与者参与者的概念确定参与者参与者的泛化关系参与者的概念参与者是与系统主体交互的外部实体的类元，描述了一个或一组与系统产生交互的外部用户或外部事物。参与者位于系统边界之外，而不是系统的一部分。参与者是从现实世界中抽象出来的一种形式，却不一定确切对应的现实中的某个特定对象。确定参与者通过对参与者进行关注和分析，我们可以把重点放在如何与系统交互这一问题上，便于进一步确定系统的边界。另外，参与者也决定了系统需求的完整性。确定参与者可以从以下几个角度来考虑：为系统提供输入的人或事物接收系统输出的人或事物需要接入的第三方系统或设备时间是否会触发某些事件负责支持或维护系统中信息的人确定参与者系统中的参与者一般可以分为四类：主要业务参与者：主要从用例的执行中获得好处的关联人员。主要系统参与者：直接同系统交互以发起或触发业务或系统事件的关联人员。外部服务参与者：响应来自用例的请求的关联人员。外部接收参与者：从用例中接收某些价值或输出的非主要的关联人员。参与者的泛化关系当系统中的几个参与者既扮演自身的角色，同时也有更一般化的角色时，可以通过建立泛化关系来进行描述。与类相似，父参与者可以是抽象的，即不能创建一个父参与者的直接实例，这就要求属于抽象父参与者的外部对象一定能够属于其子参与者之一。5.3用例用例的概念用例与参与者用例的特征用例的粒度用例的概念用例是类元提供的一个内聚的的功能单元，表明系统与一个或多个参与者之间信息交换的顺序，也表明了系统执行的动作。简单来说，用例就是某一个参与者在系统中做某件事从开始到结束的一系列活动的集合，以及结束时应该返回的可观测、有意义的结果，其中也包含可能的各种分支情况。用例与用例图被广泛使用于系统的需求建模阶段，并在系统的整个生命周期中被不断细化。用例与参与者一个用例可以隶属一个或多个参与者，一个参与者也可以参与一个或多个用例。用例与参与者之间存在关联关系。主参与者与次参与者：通常来说主参与者是用例的重要服务对象，而次参与者处于一种协作地位。用例与参与者在确定用例时可以通过参与者入手来寻找用例：参与者的主要任务是什么？参与者需要系统的什么信息？参与者可以为系统提供什么信息？系统需要通知参与者发生的变化和事件吗？参与者需要通知系统发生的变化和事件吗？用例的特征用例的特征保证用例能够正确地捕捉功能性需求，同时也是判断用例是否准确的依据。用例是动宾短语用例是相对独立的用例是由参与者启动的用例要有可观测的执行结果一个用例是一个单元用例的粒度用例粒度指的是用例组织信息的方式和细化程度。用例的粒度在业务建模阶段，用例的粒度以每个用例描述一个完整的事情为宜。在概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜。在系统建模阶段，用例的粒度以一个用例能够描述参与者与计算机的一次完整交互为宜。5.4用例之间的关系泛化关系依赖关系包含扩展泛化关系与参与者的泛化关系相似，用例的泛化关系将特化的用例与一般化的用例联系起来。子用例继承了父用例的属性、操作和行为序列，并且可以增加属于自己的附加属性和操作。父用例同样可以定义为抽象用例。依赖关系——包含包含指的是一个用例（基用例）可以包含其他用例（包含用例）具有的行为，其中包含用例中定义的行为将被插入基用例定义的行为中。包含的两个基本约束：基用例可以看到包含用例，并需要依赖于包含用例的执行结果，但是它对包含用例的内部结构没有了解；基用例一定会要求包含用例执行。依赖关系——扩展扩展指的是一个用例（扩展用例）对另一个用例（基用例）行为的增强。在这一关系中，扩展用例包含了一个或多个片段，每个片段都可以插入到基用例中的一个单独的位置上，而基用例对于扩展的存在是毫不知情的。使用扩展用例我们就可以在不改变基用例的同时，根据需要自由地向用例中添加行为。依赖关系——扩展扩展用例的使用包括四个部分：基用例：需要被扩展的用例，如图5-10中的“注册”用例。扩展用例：提供所添加的行为序列的用例，如图5-10中的“检查实名信息”用例。扩展关系：使用虚线箭头表示，箭头指向基用例。扩展点：基用例中的一个或多个位置，表示在该位置会根据某条件来决定是否要中断基用例的执行从而执行扩展用例中的片段。依赖关系特性includeextend作用增强基用例的行为增强基用例的行为执行过程包含用例一定会执行扩展用例可能被执行对基用例的要求在没有包含用例的情况下，基用例可以是也可以不是良构的在没有扩展用例的情况下，基用例一定是良构的表示法箭头指向包含用例箭头指向基用例基用例对增强行为的可见性基用例可以看到包含用例，并决定包含用例的执行基用例对扩展用例一无所知基用例每执行一次，增强行为的执行次数只执行一次取决于条件（0到多次）

5.5用例描述与文档用例描述概述前置条件与后置条件事件流补充约束用例文档实践用例描述概述一个完整的用例模型应该不仅仅包括用例图部分，还要有完整的用例描述部分。一般的用例描述主要包括以下几部分内容：用例名称：描述用例的意图或实现的目标，一般为动词或动宾短语。用例编号：用例的唯一标识符，在其他位置可以使用该标识符来引用用例。参与者：描述用例的参与者，包括主要参与者和其他参与者。用例描述：对用例的一段简单的概括描述。用例描述概述触发器：触发用例执行的一个事件。前置条件：用例执行前系统状态的约束条件。基本事件流（典型过程）：用例的常规活动序列，包括参与者发起的动作与系统执行的响应活动。扩展事件流（替代过程）：记录如果典型过程出现异常或变化时的用例行为，即典型过程以外的其他活动步骤。结论：描述用例何时结束。后置条件：用例执行后系统状态的约束条件。补充约束：用例实现时需要考虑的业务规则、实现约束等信息。前置条件与后置条件前置条件指的是用例执行前系统和参与者应处于的状态。前置条件是用例的入口限制，它便于我们在进行系统分析及设计的时候注意到，在何时何地才可以合法地触发这个事件。后置条件是用例执行完毕后系统处于的状态。后置条件是对用例执行完毕后系统状况的总结，用来确保用户理解用例执行完毕后的结果，并非其他用例的触发器。前置条件与后置条件分别是用例在开始和结束时的必要条件。事件流事件流是对用例在使用场景下的交互动作的抽象，应该包括用例何时以及怎样开始和结束，用例何时与参与者交互，该行为的基本流和可选择的流。基本事件流：描述的是用例中最核心的事件流，是用例大部分时间所进行的场景。扩展事件流：描述的是用例处理过程中的一些分支或异常情况。补充约束补充约束用来描述用例在系统功能之外的内容，例如非功能需求、业务规则等等。数据需求：与该用例相关的一些数据项的说明。业务规则：与业务相关的逻辑和操作规则。非功能性需求：例如性能、支持的并发量等。设计约束：是从多个角度对用例或系统的约定。用例文档实践用例名称提交订单用例编号UC002参与者会员用例描述该用例描述一个系统会员提交一份订单的行为触发器当订单被提交时，用例触发。前置条件提交订单的一方需要完成登录操作后置条件如果订单中的商品有库存，则发货；否则提示用户当前缺货基本事件流1参与者将订单信息提交至系统。2系统验证用户信息及订单信息合法后作出响应。3对于订单中的每种产品，系统根据订单中的数量检查产品库存数量。4系统统计订单中产品的总价格。5系统从会员的系统账户余额中扣除相应金额。6系统生成并保存订单信息并将订单发送至分销中心。7系统生成订单确认页面并发送给会员。扩展事件流A-2如果订单信息非法，系统通知会员并提示重新提交订单。A-3如果订单中产品数量超过产品库存量，则提示会员库存不足，暂无法购买，取消订单同时终止用例。A-5如果会员账户余额不足，系统给出相应提示，取消订单并终止用例。结论当会员收到系统发送的订单确认页面或其他异常信息时，用例结束。数据需求D-1订单信息包括订单号、参与者的会员账户名、商品种类数量、商品种类名称以及每种商品的数量。业务规则B-1只有当订单中商品信息确认无误后才能要求会员进行支付。5.6应用用例图建模用例图建模技术用例图使用要点用例图建模技术对系统的语境建模识别系统边界。识别参与者。如果需要，将具有相同特征的参与者使用泛化关系加以组织。如果需要，对某些参与者应用一个构造型以便加深理解。将参与者应用到用例图中，并描述参与者与用例间的通信路径。用例图建模技术对系统的需求建模识别参与者。对于某个参与者，考虑其期望系统提供的行为或与系统的交互。将行为提炼成用例。完善其他用例。分解用例中的公共行为与扩展行为，放入新的用例中以供其他用例使用。创建用例图。如果需要，在用例图中添加一些注解或约束来陈述系统的非功能需求。用例图使用要点构建结构良好的用例。用例图中应该只包含对系统而言必不可少的用例与相关的参与