chapter05 用例图
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.1 用例图的基本概念
功能分解方法的另一个缺点是这种方法分割了各项 系统功能的应用环境，从各项功能项入手，很难了 解到这些功能项是如何相互关联来实现一个完成的 系统服务的。 所以在传统的SRS文档中，需要另外一些章节来描 述系统的整体结构及各部分之间的相互关联，这些 内容使得SRS需求更象是一个设计文档。
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.2 用例图的组成
泛化关系：参与者之间可以有泛化(Generalization)关系 泛化关系：参与者之间可以有泛化 关系 或称为"继承 关系）。 继承"关系 （或称为 继承 关系）。
山东科技大学（泰山科技学院）信息工程系
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.2 用例图的组成
用例图的构成4要素： 用例图的构成 要素： 要素
• • • • 参与者 用例 系统边界 关联
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.2 用例图的组成
5.2.1 参与者 参与者(Actor)
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.2 用例图的组成
特殊的参与者――系统时钟 系统时钟 特殊的参与者 有时候需要在系统内部定时地执行一些操作，如检测系统资 源使用情况、定期地生成统计报表等等。从表面上看，这些 操作并不是由外部的人或系统触发的，应该怎样用用例方法 来表述这一类功能需求呢？对于这种情况，可以抽象出一个 系统时钟或定时器参与者，利用该参与者来触发这一类定时 操作。从逻辑上，这一参与者应该被理解成是系统外部的， 由它来触发系统所提供的用例对话。
安新军 sdkdaxj@
5.2 用例图的组成
管理员和操作员都是一种特殊的用户， 他们拥有普通用户所拥有的全部权限， 此外他们还有自己独有的权限。这里 我们可进一步把普通用户和管理员、 操作员之间的关系抽象成泛化关系， 管理员和操作员可以继承普通用户的 全部特性（包括权限），他们又可以 有自己独有的特性（如操作、权限 等）。这样可以显著减速少用例图中 通讯关联的个数，简化用例模型，使 之更易于理解。
安新军 sdkdaxj@
5.2 用例图的组成
用例识别
•参与者要向系统请求什么功能？ •每个参与者的特定任务是什么？ •参与者需要读取、创建、撤消、修改、或存储系统的某些信息吗？ •是否任何一个参与者都要向系统通知有关突发性的、外部的改变？ 或者必须通知参与者关于系统中的发生的事件？ •这些事件代表了哪些功能？ •系统需要哪些输入/输出？ •这些输入输出来自哪里或者到哪里去？
安新军 sdkdaxj@
5.2 用例图的组成
1)、参与者的概念 、
参与者用于表示使用系统的对象。参与者可以是一个人、一个 计算机系统、另一个子系统或另外一种对象。例如，一个计算 网络系统的参与者可以包括操作员、系统管理员、数据库管理 员和普通的用户，也可以有非人类参与者，如网络打印机。 参与者的特征是其作为外部用户与系统发生交互。在系统的实 际运作中，一个实际用户可能对应系统的多个参与者。同样， 不同的多个用户也可以只对应于一个参与者，从而代表同一个 参与者的不同实例。 参与者可以是主要参与者和次要参与者 主要参与者和次要参与者
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.1 用例图的基本概念
与传统的功能分解方式相比，用例方法完全是从外部来定义 系统的功能，它把需求与设计完全分离开来。在面向对象的 分析设计方法中，用例模型主要用于表述系统的功能性需求， 系统的设计主要由对象模型来记录表述。 用例定义了系统功能的使用环境与上下文，每一个用例描述 的是一个完整的系统服务。用例方法比传统的SRS更易于被用 户所理解，它可以作为开发人员和用户之间针对系统需求进 行沟通的一个有效手段。
山东科技大学（泰山科技学院）信息工程系 安新军 sdkdaxj@
5.2 用例图的组成
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.2 用例图的组成
系统边界决定了参与者 参与者是由系统的边界所决定的，如果所要定义的系统边界 仅限于ATM机本身，那么后台服务器就是一个外部的系统， 可以抽象为一个参与者。
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.1 用例图的基本概念
子系统1功能 模块1.1 功能 模块1.2 功能 …… 子系统2功能 模块1.1 功能 模块1.2 功能 …… 子系统N功能 ……
山东科技大学（泰山科技学院）信息工程系 安新军 sdkdaxj@
山东科技大学（泰山科技学院）信息工程系 安新军 sdkdaxj@
5.2 用例图的组成
2)、参与者的确定 、
使用系统主要功能的是谁？ 谁需要借助系统完成日常工作？ 系统从谁或哪些系统获得数据？ 系统会为谁或哪个系统提供数据？ 系统会与哪些其它系统交互 系统是由谁来日常维护和管理的？ 系统的控制硬件有哪些？ 谁对本系统产生的结果感兴趣？ 这些问题有助于抽象出系统的参与者。 这些问题有助于抽象出系统的参与者。
/~car/programming/rup/webtmpl/req/htm_srs.htm 模板参考： 模板参考： 山东科技大学（泰山科技学院）信息工程系 安新军 sdkdaxj@
5.1 用例图的基献 ． 引言 B．整体描述 ． C．软件项目约束 ． 信息描述 A．信息内容表示 ． B．信息流表示： 1）数据流；2）控制流 ．信息流表示： ）数据流； ） A．功能划分 ． 功能描述 B．功能描述：1）处理说明；2）限制 局限；3）性能需求；4）设计约束；5）支撑图 ．功能描述： ）处理说明； ）限制/局限 ）性能需求； ）设计约束； ） 局限； C．控制描述；1）控制规约；2）设计约束； ．控制描述； ）控制规约； ）设计约束； 行为描述 A．系统状态 ． B．事件和响应 ． A．性能范围 ． 检验标准 B．测试种类 ． C．期望的软件响应 ． D．特殊的考虑 ． 参考书目 附录
5.1 用例图的基本概念
采用这种方法来描述系统需求，不太容易界定需求和设 计的界限，这样的表述实际上已经包含了部分的设计在 内。由此常常导致这样的迷惑： 系统需求应该详细到何种程度？一个极端就是需求可以 详细到概要设计，因为这样的需求表述既包含了外部需 求也包含了内部设计。在有些公司的开发流程中，这种 需求被称为“内部需求”，而对应于用户的原始要求则 被称之为“外部需求”。
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.2 用例图的组成
3)、参与者的关系 、
描述参与者与参与者之间的泛化(generalization) ，利用这些关 系来调整已有的用例模型，把一些公共的信息抽取出来重用， 使得用例模型更易于维护。一般来说这些关系都会增加用例 一般来说这些关系都会增加用例 和关系的个数，从而增加用例模型的复杂度。 和关系的个数，从而增加用例模型的复杂度。
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.1 用例图的基本概念
5.1.2 用例图的作用
用例图是需求分析的产物， 用例图是需求分析的产物，主要进行对参与者和用例关系的 描述，帮助开发人员可视化的了解系统功能。借助于用例图， 系统用户、分析人员、设计人员等可以可视化的对问题进行 探讨，减少了大量交流上的障碍。 软件需求规约(Software Requirement Specification )－SRS 软件需求规约 －
山东科技大学（泰山科技学院）信息工程系 安新军 sdkdaxj@
5.1 用例图的基本概念
一般小型的系统，其用例模型中包含的参与者和用例不会 太多，一个用例图就可以容纳所有的参与者，所有的参与 者和用例也可以并存于同一个层次结构中。
对于较复杂的大中型系统，用例模型中的参与者和用例会大大 增加，需要一些方法来有效地管理由于规模上升而造成的复杂 度—包(Package)是UML中最常用的管理模型复杂度的机制， 包 是 中最常用的管理模型复杂度的机制， 中最常用的管理模型复杂度的机制 是一种容器，在包中可以容纳其他任意的模型元素（ 是一种容器，在包中可以容纳其他任意的模型元素（包括其他 的包）。 的包）。
山东科技大学（泰山科技学院）信息工程系
安新军 sdkdaxj@
5.2 用例图的组成
•说明了系统具有的一种行为模式 •说明了一个参与者与系统执行的一个相关的事务序列 •提供了一种获取系统需求的方法 •提供了一种与最终的用户和领域专家进行沟通的方法 •提供了一种测试系统的方法
山东科技大学（泰山科技学院）信息工程系
用例模型奠定了整个系统软件开发的基础。 用例模型奠定了整个系统软件开发的基础。
山东科技大学（泰山科技学院）信息工程系 安新军 sdkdaxj@
5.1 用例图的基本概念
5.1.1 用例图的定义 用例图是被称为参与者的外部用户所能观察到的系 统功能的模型图，呈现了一些参与者和一些用例， 以及它们之间的关系，主要用于对系统、子系统或 类的功能行为进行建模。 用例图展示了用例之间以及同用例参与者之间是怎 样相互联系的。用例图用于对系统、子系统或类的 行为进行可视化，使用户能够理解如何使用这些元 素，并使开发者能够实现这些元素。
第五章 用例图
5.1 用例图的基本概念 5.2 用例图的组成 5.3 用例图的创建概述 5.4 用例图的基本示例
5.1 用例图的基本概念
用例(Use Case)是一种描述系统需求的方法，使用用例的 方法来描述系统需求的过程就是用例建模。 用例方法最早是由Iva Jackboson提出的，后来被综合到 UML规范之中，成为一种标准化的需求表述体系。用例 在RUP中广泛使用，整个RUP流程都被称作是“用例驱 “ 动”(Use-Case Driven)的，各种类型的开发活动包括项 目管理、分析设计、测试、实现等都是以系统用例为主 要输入工件。
第5章 用例图
用例与事件流
• 用例分析处于系统的需求分析阶段，这个
阶段应该尽量避免考虑系统实现的细节问 题，这些细节问题写在事件流文件中。事 件流文件即用例的逻辑流程文档包括：
• 1. 简要说明：描述用例的作用； • 2. 前提条件：用例之前必须满足的条件；例：用户是否有运行权限 • 3. 事件流（主事件流、其他事件流、错误流 ）：描述参与者执行用
习题：
• 2、一台饮料自动售货机能提供6种不同的 、一台饮料自动售货机能提供6
饮料。售货机上有6 饮料。售货机上有6个按钮，分别对应于这 6中饮料，顾客可以通过按钮来选择所要的 饮料。每个按钮旁边有一个指示灯，用来 表明该售货机中是否还有这种饮料可售。 售货机有一个硬币槽的找零槽，用来收钱 和找钱。
① 处理书籍借阅 ② 处理书籍归还 ③ 删除预定信息
3. 系统管理员进行系统维护的用例
① 查询借阅者信息 ② 查询书籍信息 ③ 增加书目 ④ 删除或更新书目 ⑤ 增加书籍 ⑥ 删除书籍 ⑦ 添加借阅者帐户 ⑧ 删除或更新借阅者帐户
5.3.4 使用Rational Rose绘制用例图 使用Rational Rose绘制用例图 的步骤
扩展关系
• 扩展用例被定义为基础用例的增量扩展，这称作
扩展关系。
用例间的扩展关系
扩展关系例子
扩展关系指的是基础用例执行的情况下可选择是否执行提供者用例。
泛化关系
• 父用例也可以被特别列举为一个或多个子用例。 • 子用例从父用例处继承行为和属性，还可以添加
行为或覆盖、改变继承的行为。
用例间的泛化关系 泛化关系例子
例的具体步骤； • 4. 事后条件：用例执行完毕后必须为真的条件。例：用例完成之后 设置一个标志，这种信息就是事后条件。
UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明书画法和功能
UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language ™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成标准文档为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）标准文档角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。
用例和用例图ppt课件
精选课件
6
参与者间的关系
▪ 在用例图中，使用泛化关系 来描述多个参与者之间的公 共行为。
▪ 示例：
父参与者
子参与者
子参与者
▪ 子参与者继承父参与者的 行为和含义，并能增加自 己特有的行为和含义
▪ 子参与者可以出现在父参
与者能出现的任何位置上
精选课件
7
3.3 用例
定义：
对一组动作序列的描述，系统通过执行这一 组动作序列为参与者产生一个可观察的结果
使用扩展关系 ▪ 扩展用例总是在一个或多个扩展点处来扩展基本用例，或
处于特定条件下， 才扩展基本用例。
基本用例
扩展点 扩展点名称
<<extend>>
扩展用例
精选课件
21
扩展关系
使用情形
a.两个用例相似但不完全相同时 b.当要对多个额外情况逐一建模时，使用扩展关
系，用一个独立的用例替代每个额外的情况 c.如果用例涵盖了所有的情况变化，则该用例将
识别用例
用例识别
识别用例最好的方法就是从分析系统的参与者开 始，考虑每个参与者是如何使用系统的。
➢ 参与者要向系统请求什么功能？
➢ 每个参与者的特定任务是什么？
➢ 参与者需要读取、创建、撤消、修改、或存储 系统的某些信息吗？
➢ 是否任何一个参与者都要向系统通知有关突发 性的、外部的改变？或者必须通知参与者关于 系统中的发生的事件？
会变得十分复杂，应该考虑使用扩展关系
精选课件
22
例
项目经理
扩展关系
项目管理系统
<<extend>> ( 任务函数)
[ 选择任务选项]
管理任务
UML用例图
用例图主要包括： 用例图主要包括：一个用例图中包括一组用例和一组参与者，主
要描述用例之间、用例与参与者之间、参与者之间的关系，还有相关 注解和约束。
用例图的六个元素： 用例图的六个元素：参与者(Actor)、用例(Use Case)、关联关系
(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系 (Generalization)。
用例(Use Case)
概念: 概念 用例是外部可见的系统功能单元,这些功能由系统单元所提供,并通过一
系列系统单元与一个或多个参与者之间交换的消息所表达.一个用例表示一个 系统中的一部分功能和行为.
用例的特征: 用例的特征
1.用例总是由一个参与者启动 参与者必须直接或间接地命令该系统执行这 用例总是由一个参与者启动: 用例总是由一个参与者启动 个用例. 2.用例为参与者提供某种结果值 用例必须向用户交付某种具体的结果值. 用例为参与者提供某种结果值: 用例为参与者提供某种结果值 3.用例是完整的 用例必须是一个完整的描述 用例是完整的: 用例是完整的
识别用例: 识别用例 最好的方法就是从分析系统的参与者开始,考虑每个参与者是如何
使用系统的.
1.特定参与者希望系统提供什么功能 2.系统是否存储和检索信息,如果是,由哪个参与者触发 3.当系统改变状态时,是否通知参与者 4.是否存在影响系统的外部事件 5.哪个参与者通知系统这些事件
用例和事件流
事件流是什么:事件流是用来为用例的逻辑流程建立文档.这个文档
用例和事件流:用例分析处于系统的需求分析阶段,这个阶段应该尽
量避免考虑系统实现的细节问题.但是要实际建立系统,就需要更加具 体的细节,所以就将这些细节写到事件流文件中去.
第二讲用例图.ppt
通过回答以下的几个问题识别用例：
特定参与者希望系统提供什么功能。 系统是否存储和检索信息，如果是，由哪个参与者触
发。 当系统发生改变时，是否通知参与者。 是否存在影响系统的外部事件。
哪个参与者通知系统这些事件。
还有两个针对整个系统的问题:(1)系统需要何种输入输 出？输入从何处来？输出到何处去？(2)当前运行系统 的主要问题一？个用这例两至个少问要题与一并个不参意与味者着关联没！有参与者也可以 有用例，只是获取用例时还不知道参与者是什么。
(2)为系统的功能提供清晰一致的描述，以便为后续的开 发工作打下良好的交流基础，方便开发人员传递需求的 功能。
(3)为系统验证工作打下基础。通过验证最终实现的系 统能够执行的功能是否与最初需求的功能相一致，保证 系统的实用性。
(4)从需求的功能（用例）出发，提供跟踪进入系统中 具体实现的类和方法，检查其是否正确的能力。
S-1：添加所选课程
系统提示含有课程名和课程代码的域，学生输入希望选修的 课程名和课程代码(E-3)，系统显示信息表示该课程可以选 修(E-4)，并建立该课程与该学生的连接(E-5)。用例重新 开始。
S-2：删除所选课程
系统提示含有课程名和课程代码的域，学生输入希望取消的 课程名和课程代码，系统删除该课程与该学生的连接(E-6)。 用例重新开始。
4.用例
（1）用例的概念
[UNL课件] 第5章 用例图
![[UNL课件] 第5章 用例图](https://360docs-1393072327.cos.ap-beijing.myqcloud.com/ca0dada01a37f111f1855b7e.webp)
– 3)弄清楚的概念（续）
5.2 用例图的组成
– 4)参与者检查
• 用于检查发现的参与者是否正确的检查点列表
是否你已找到所有的参与者？也就是说，是否你已经对系统环境中的所有角色都进行了说明和 建模？一般要到找到并说明了所有用例后才能将其确定。 每个参与者是否至少涉及到一个用例？删除未在用例说明中提及的所有参与者，或与用例无通 信关联关系的所有参与者。 你能否列出至少两名可以作为特定参与者的人员？如果不能，请检查参与者所建模的角色是否 为另一角色的一部分。如果是这样，应该将该参与者与另一参与者合并。
精化了
B
– 精化用例由基本用例分解得到，精化用例更细致地展 示了基本用例的核心业务。
开立账户 <<refine>> <<refine>> 存入现金 <<refine>> <<refine>> 转账 预存话费
– 一旦确定了用例，软件开发工作的其他活动都以此为 基础进行，即：用例驱动的开发。
分析
设计
需求单元 开发 组织
测试
部署
5.2 用例图的组成
– 3）用例的粒度
• 粒度，即一个用例的大小（包含多少操作）。 • i. 以阶段为划分标准
– 业务建模阶段，用例的粒度以每个用例能够说明一件
完整的事情为宜。
取钱 报装电话 借书 验证密码 填写申请单 查找书目
» 扩展用例带有抽象性质，表示了用例场景中的某个“支 流”，由特定扩展点触发而被启动。
– “扩展”表示的是“可选”：
» 即使没有扩展用例，基本用例也是完整的；
» 如有没有基本用例，扩展用例是不能单独存在的； » 如果有多个扩展用例，同一时间用例实例也只会使用其 中的一个。
UML实践----用例图、顺序图、状态图、类图、包图、协作图
UML实践----用例图、顺序图、状态图、类图、包图、协作图2009-01-20 作者：Randy Miller 来源：网络面向对象的问题的处理的关键是建模问题。
建模可以把在复杂世界的许多重要的细节给抽象出。
许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处。
UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接。
而且每个部分都有一个小问题，测试一下你对这个部分的理解。
为什么UML很重要？为了回答这个问题，我们看看建筑行业。
设计师设计出房子。
施工人员使用这个设计来建造房子。
建筑越复杂，设计师和施工人员之间的交流就越重要。
蓝图就成为了这个行业中的设计师和施工人员的必修课。
写软件就好像建造建筑物一样。
系统越复杂，参与编写与配置软件的人员之间的交流也就越重要。
在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”。
现在它已经成为了软件行业的一部分了。
UML提供了分析师，设计师和程序员之间在软件设计时的通用语言。
UML被应用到面向对象的问题的解决上。
想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的。
一个模型model就是根本问题的抽象。
域domain就是问题所处的真实世界。
模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的。
记住把一个对象想象成“活着的”。
对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）。
对象的属性的值决定了它的状态state。
类Classes是对象的“蓝图”。
一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）。
对象是类的实例instances。
用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象。
第五章_用例图
5.2.1 参与者
❖ 参与者有三大类：
第一类参与者是真实的人，即用户，是最常见的 参与者，几乎存在于每一个系统中。
用例执行期间可能发生的各种情况。 用例是一个完整的描述。若其被分解成多个小用
例，则仅当所有的小用例完成后才代表整个用例的 完成。
2. 用例的识别
❖ 任何用例都不能在缺少参与者的情况下独立存在。 同样，任何参与者也必须要有与之关联的用例。 所以识别用例的最好方法就是从分析系统参与者 开始，在这个过程中往往会发现新的参与者。
❖ 用例图只是从总体上大致描述了系统所提供的各 种服务，让用户对系统有一个总体的认识。
❖ 对于每一个用例，我们还需要有详细的描述信息， 以便让别人对于整个系统有一个更加详细的了解， 这些信息包含在用例规约之中。
3. 用例规约
❖ 每一个用例的用例规约都应该包含以下内容： (1)简要说明：对用例作用和目的的简要描述。 (2)事件流：事件流包括基本流和备选流。基本流 描述的是用例的基本流程，是指用例“正常”运 行时的场景。备选流描述的是用例执行过程中可 能发生的异常和偶尔发生的情况。
第二类参与者是其他的系统。这类位于程序边界 之外的系统也是参与者。
第三类参与者是一些可以运行的进程。如时间， 当经过一定的时间触发系统中的某个事件时，时间 就成了参与者。
5.2.1 参与者
❖ 参与者虽然代表人或事物，但参与者不是指人或 事物本身，而是表示人或事物当时所扮演的角色。
❖ 一个用例的参与者可以划分为发起参与者和参加 参与者。发起参与者发起了用例的执行过程，一 个用例只有一个发起参与者，但可以有若干个参 加参与者。
用例图
用例图用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。
用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。
用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。
它将系统功能划分成对参与者（即系统的理想用户）有用的需求。
而交互部分被称作用例。
用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。
有时，可以将用例的实例引入到图中。
用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor）1．参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。
参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。
参与着由参与用例时所担当的角色来表示。
在UML中，参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。
它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。
参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。
命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
UML图例之用例图
UML图例之⽤例图 ⽤例图主要⽤来描述“⽤户、需求、系统功能单元”之间的关系，在需求分析阶段，常会借助⽤例图，从⽤户的⾓度描述系统的功能，以图形可视化的⽅式作为开发团队与客户的交流，同时也有助于形成统⼀语⾔。
⼀、⽤例图描述 ⽤例图（Use Case Diagrame）：描述了⼈们希望如何使⽤⼀个系统，将相关⽤户、⽤户需要系统提供的服务以及系统需要⽤户提供的服务更清晰的显⽰出来，以便使系统⽤户更容易理解这些元素的⽤途，也便于开发⼈员最终实现这些元素。
之所以说⽤例图⾄关重要，是由于⽤户并不关⼼系统的实现和内部结构，只关⼼产品所呈现出来的外部特征动态。
⽽⽤例图恰好就是描述软件产品外部特性的视图，它从⽤户的⾓度⽽不是从开发者的⾓度来描述需求，分析产品的功能和动态⾏为。
⼆、基本元素1、参与者(Actor)，在系统外部与系统直接交互的⾓⾊或外部系统。
可通过与客户的沟通交流，确定利益相关⼈，进⽽确定参与者。
⾓⾊：通常是具体⼈承担着⾓⾊，这是最常见的参与者。
外部系统：如CRM系统要操作OA系统，以⽅便发送通知，那么针对OA系统的调⽤，CRM系统作为外部系统这⼀参与者。
时间：如存在定时任务操作或者类似操作等，则时间作为参与者2、⽤例客户通过对需求的描述(主要为功能需求)，开发团队通过⽤例来体现系统功能和服务，通过参与者与⽤例的交互，来达到客户与开发团队的⽬标⼀致。
3、关联关系1）参与者与参与者间的泛化关系⽐如腾讯⽤户，包括微信⽤户和QQ⽤户两部分，但是使⽤腾讯业务时，只需要是腾讯⽤户即可，此时，可以采⽤泛化关系，采⽤三⾓空⼼箭头作为指向。
2）参与者与⽤例间的关联关系参与者与⽤例间是简单的关联关系，⼀个参与者可以有着多个⽤例3）⽤例与⽤例间的泛化关系⽤例之间可以存在泛化关系，⽐如常见的⽀付，可以选择微信⽀付、⽀付宝⽀付等等，但是这个操作就是⽀付。
泛化关系采⽤三⾓空⼼箭头。
4）⽤例与⽤例间的包含关系包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。