UML-用例图
UML用例和用例图
h
18
主要内容
基本概念：Use case、Actor、
Scenario Use case间的关系 Use Case 分析技术 案例讲解
h
19
关系
• 参与者与用例之间
– 关联关系
• 用例与用例之间
– 包含关系 (include) – 扩展关系 (extend) – 泛化关系 (generalization)
• 主事件流： • 1、系统显示ID和密码窗口； • 2、顾客键入ID和密码，然后按OK键； • 3、系统验证顾客ID和密码，并显示个人信息窗口； • 4、顾客键入姓名、街道地址、城市、邮政编码、电话号码，然
后按OK键； • 5、系统验证用户是否为老顾客； • 6、系统显示可以卖的商品列表； • 7、顾客在准备购买的商品图片上单击，并在图片旁边输入要购
• 用例结束后的系统状态
• 其他需要描述的内容
用例描述原则：尽可能写的“充分”，而不是追求写的形 式化、完整或漂亮。
h
32
h
33
书写用例文档
——路径交互步骤的描述
只书写“可观测”的 使用主动语句 句子必须以执行者或系统作为主语 每一句都要朝目标迈进 分支和循环 不要涉及界面细节
h
34
书写用例文档
买的数量。选购商品完毕后按Done按钮； • 8、系统通过库存系统验证要购买的商品是否有足够库存； • …….（后续描述省略）
问题：对用户界面的描述过于详细，对于需求文档来说， 详细的用户描述对获取需求并无帮助。
h
45
改进后的描述
• Use Case：Buy Something • 参与者：Customer • 主事件流： • 1、顾客使用ID和密码进入系统； • 2、系统验证顾客身份； • 3、顾客提供姓名、地址、电话号码； • 4、系统验证顾客是否为老顾客； • 5、顾客选择要购买的商品和数量； • 6、系统通过库存系统验证要购买的商品是否有足
电子商务系统分析与设计0301-UML-用例图绘制
第二题答案
显示是否有饮料 选择饮料
自动售货机 收钱
付款 找钱 提供饮料
顾客
10
12:56
第三题答案
11
12:56
12
12:56
12:56
3
1 用例图关系
用例图中涉及的关系有：关联、泛化、包含、扩展。
12:56
2 如何绘制用例图呢？
基本步骤
1.ONE
2.TWO
识别 参与者
确定 用例
4
3.THREE
构建用 例模型
12:56
实例
5
4.7 实例“学生信息管理系统”的需求
（1）系统管理员登录后可以对班级的基本信息进行增加、删除、 修改、查询等操作。学校领导登录后可以对班级基本信息进行查询 操作。
（2）教师登录后可以对学生的考试成绩进行录入、删除、修改、 查询等操作。学生登录后可以对考试成绩进行查询操作。
（3）学生登录后可以了解所有选修课程的具体信息，可以根据自 己的需要选择不同课程。系统管理员登录后可以增加、修改、查询、 删除选修课程。
（4）系统管理员可以对账号进行创建、设置、查看、删除等操作。
03有一台自动销售商品食品或者饮料等的机器任何人都可以通过按上面的按钮来购买商品每个商品旁边都有一个指示灯用来表示有没有该商品机器上有一个人民币入口和找零出口用来收钱和找钱如果你需要购买一瓶果汁请绘制出用例图
Байду номын сангаас习
2
UML有哪些特点？ UML有哪些功能？ UML包含哪些视图？ 用例图主要由哪些元素组成？ 用例图中涉及哪些关系？ 如果你根据一组需求绘制用例图，你会分为哪几步呢？
12:56
练习2
有一台自动销售商品（食品或 者饮料等）的机器，任何人都 可以通过按上面的按钮来购买 商品，每个商品旁边都有一个 指示灯，用来表示有没有该商 品，机器上有一个人民币入口 和找零出口，用来收钱和找钱， 如果你需要购买一瓶果汁，请 绘制出用例图。
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.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。
面向对象系统分析与设计-UML基础-用例图
30
订货系统用例图
<<extend>> 信用卡支付 <<include>> 下订单 <<extend>> <<include>> 计算订单价钱 <<extend>> 退货处理 选择仓库 <<extend>> 退货服务 发货 顾客 缺货 发货者 收款员 付款 <<extend>> 信用卡系统
管理者
货物管理
UseCase
Actor
预定
取车
还车 客户
34
泛化关系
泛化关系（Generalization Association）是表示一般 与特殊的关系。用于共享用例的共同功能行为。用例 可以继承父用例的含义和行为，也可以对父用例的行 为进行增加和修改。子用例可以出现在父用例出现的 任何位置。 泛化关系用泛化箭线（带空心三角箭头的实线）表 示，从子用例发出，指向父用例。如果需要可以在箭 线上标出联系的名称。
32
关系
用例除了与参与者有联系以外，用例之 间还存在着一定的关系。参与者之间还存有 关系。关系类型包括： 关联关系 包含关系 扩展关系 泛化关系
33
关联关系
关联关系用于描 述参与者与用例之间 的关系。在 UML 中用 实线表示。例如，客 户启动系统的取钱功 能，表示客户启动与 用例的关联。关系方 向显示是谁启动了通 信。建立通信之后， 信息是可以双向流动 的。
UML之用例图
UML之⽤例图⽤例图⽤例图是⽤来描述系统功能的技术，表⽰⼀个系统中⽤例与参与者及其关系的图，主要⽤于需求分析阶段。
⽤例图的基本组成元素：参与者、⽤例、元素之间的关系。
⽤例图使⽤范围：需求分析1.捕获需求。
描述功能需求、⾏为需求（系统要完成什么任务）2.分析需求。
明确类和对象，建⽴之间的关系⽤例图的基本概念1、⽤例图是表⽰⼀个系统中⽤例与参与者关系之间的图。
它描述了系统中相关的⽤户和系统对不同⽤户提供的功能和服务。
2、⽤例图相当于从⽤户的视⾓来描述和建模整个系统，分析系统的功能与⾏为。
3、⽤例图中的主要元素包括参与者、⽤例以及元素之间的关系。
此外，⽤例图还可以包括注解和约束，也可以使⽤包将图中的元素组合成模块。
如：参与者的概念1、参与者是与系统主体交互的外部实体的类元，描述了⼀个或⼀组与系统产⽣交互的外部⽤户或外部事物。
2、参与者位于系统边界之外，⽽不是系统的⼀部分。
3、参与者是从现实世界中抽象出来的⼀种形式，却不⼀定确切对应的现实中的某个特定对象。
符号：如何确定参与者？通过对参与者进⾏关注和分析，我们可以把重点放在如何与系统交互这⼀问题上，便于进⼀步确定系统的边界。
另外，参与者也决定了系统需求的完整性。
确定参与者可以从以下⼏个⾓度来考虑：1）为系统提供输⼊的⼈或事物2）接收系统输出的⼈或事物3）需要接⼊的第三⽅系统或设备4）时间是否会触发某些事件5）负责⽀持或维护系统中信息的⼈系统中的参与者⼀般可以分为四类：主要业务参与者：主要从⽤例的执⾏中获得好处的关联⼈员。
主要系统参与者：直接同系统交互以发起或触发业务或系统事件的关联⼈员。
外部服务参与者：响应来⾃⽤例的请求的关联⼈员。
外部接收参与者：从⽤例中接收某些价值或输出的⾮主要的关联⼈员。
参与者的泛化关系当系统中的⼏个参与者既扮演⾃⾝的⾓⾊，同时也有更⼀般化的⾓⾊时，可以通过建⽴泛化关系来进⾏描述。
与类相似，⽗参与者可以是抽象的，即不能创建⼀个⽗参与者的直接实例，这就要求属于抽象⽗参与者的外部对象⼀定能够属于其⼦参与者之⼀。
UML用例图描述
用例名称
系统管理员登录
标识符001用Fra bibliotek描述系统管理员通过设置的用户名和密码登录到学生管理系统
参与者
系统管理员
优先级
1
状态
等待审查
前置条件
学生管理系统正常运行
后置条件
如果管理员登录成功，则可以对学生基本信息进行管理，包括录入，删除，修改，查询学生基本信息，并且可修改自己的密码；如果管理员登录不成功，则不能对学生基本信息进行操作。
2.系统管理员无用户名先进行注册，再输入正确的用户名和密码顺利登录，并对学生基本信息进行操作
3.系统管理员忘记用户名和密码，通过手机动态密码进行验证，找回密码，再输入正确的用户名和密码顺利登录，并对学生基本信息进行操作
被泛化的用例
无
被包含的用例
查学生基本信息
被扩展的用例
无
用例“查学生基本信息”的描述
基本操作流程
1.系统管理员进入学生管理系统
2.系统管理员输入用户名和密码
3.系统管理员提交输入信息
4.系统对系统管理员输入的用户名和密码进行有效性检查
5.系统管理员对学生基本信息进行操作
可选操作流程
1.系统管理员输入正确的用户名和验证码，错误的密码无法顺利登录，重新输入正确的用户名和密码顺利登录，并对学生基本信息进行操作
用例名称
查学生基本信息
标识符
002
用例描述
系统管理员输入要查看的学生的基本信息，系统显示该学生的详细信息
参与者
系统管理员
优先级
2
状态
等待审查
前置条件
学生管理系统正常运行
后置条件
系统管理员输入学生的基本信息，可查看学生的详细信息
UML用例图的基本概念
UML的用途
需求分析
UML可以帮助开发人员更好地理 解客户需求，通过用例图等工具 将客户需求转化为可执行的用例。
系统设计
UML可以帮助开发人员在系统设 计阶段进行系统架构和组件的设 计，通过类图、时序图等工具进 行系统的分析和设计。
05
案例分析
案例一：简单登录系统用例图分析
总结词：简单明了
详细描述：简单登录系统通常包括用户名和密码输入、验证和登录成功或失败的反馈等基本功能。在 UML用例图中，可以清晰地表示出系统的主要功能和参与者的角色。
案例二：网上购物系统用例图分析
总结词：复杂多样
详细描述：网上购物系统涉及到多个参与者，如顾客、管理员和供应商等，以及多种复杂的业务功能，如商品展示、购物车 管理、订单处理和支付等。在UML用例图中，需要对各个功能进行详细的描述和分类，以便更好地理解系统的结构和功能。
用例图在系统设计中的应用
架构设计
用例图可以用于指导系统的架构设计，通过分析用例之间 的关系和交互，设计系统的组件和模块结构。
01
接口设计
用例图可以帮助设计系统组件之间的接 口，明确组件之间的输入输出关系和交 互协议。
02
03
系统流程设计
用例图可以用于描述系统的流程，通 过分析用例的执行顺序和交互逻辑， 设计系统的流程和顺序结构。
用例图在需求分析中的应用
1 2
沟通工具
用例图作为一种可视化图形表示，可以作为沟通 工具，帮助开发团队、客户和利益相关者理解系 统的需求和功能。
需求确认
通过绘制用例图，可以与利益相关者讨论和确认 系统的需求，确保对需求的理解和期望是一致的。
UML中共有5种静态图
UML中共有5种静态图：用例图，类图，对象图，组件图和配置图。
（1）用例图Use Case Diagram用例图展现了一组用例、参与者以及它们之间的关系可以用来描述系统的静态使用情况。
上图中小人形状的用户和ATM是参与者、椭圆形状的如插入卡、输入密码等是用例（2）类图Class Diagram类图展示了一组类、接口、子类以及他们之间的关系，在建模中最常用到的图就是类图；可以用类图说明系统的静态设计视图，包含主动类的类图。
上图中反应了5个类之间的关联关系，人民币账户和美元帐户从账户继承，账户和ATM相关联，两种账户和用户相关联（3）对象图Object Diagram对象图展示了一组对象和他们间的关系，可以用来说明类图中翻译的事物实例的数据结构和静态快照，表达了系统的静态设计视图和静态过程视图，除了显示和原型方面的因素外，它与类图的作用是相同的。
（4）组件图Component Diagram组件图，又名构件图，展现了一组组件之间的组织和依赖，用于对源代码、可执行的发布、物理数据库和可调整的系统建模。
上图中组件1和组件3依赖于组件2（5）配置图Deployment Diagram配置图展现了对运行时处理节点以及其中组件的配属，它描述系统硬件的物理拓扑结构，以及在此结构上执行的软件。
用配置图说明系统结构的静态配置视图，即说明分布、交互和安装的物理系统。
上图中，三个处理机与两个涉笔，相互之间是关联的关系UML中动态图有四种，分别是：时序图、协作图、状态图和活动图。
（1）时序图Sequence Diagram时序图展现了一组对象和由这组对象收发的信息，用于按时间顺序对控制流建模。
可以用时序图来说明系统的动态视图。
这里貌似有不同的说法Visual Paradigm里面叫时序图为Timing Diagram，而我参照的教材里边没有这种图，按理说是应该有的。
上图反应了用户与ATM交互的整个过程。
（2）协作图Collaboration Diagram协作图展现了一组对象之间的链接以及这组对象收发的消息，强调收发消息对象的组织结构，按组织结构对控制流建模。
UML 用例图、关系图、活动图
例如，一个银行系统中，有
一个“验证用户”用例，用 身份认证
于验证用户的合法性，它有
两 个 特 殊 的 子 用 例 ， 一 个 是 密码认证
指纹认证
“检查密码”，另一个是
“检查指纹”，它们都有父
用例“验证用户”的行为，
并且可以出现在父用例出现
的任何地方，还可以添加自
己的行为。
用例图实例
• 以前面图书信息管理系统为例，画出用例 图。先找出参与系统地的角色：
• 扩展关系——允许一个用例扩展另一个用
例的功能。例如，在图书信息管理系统中，
读者还书时，系统检查所还图书是否有预
订记录，如果有则执行“通知”用例。在
UML中扩展关系表示为箭头和《extend》形
式。
《extend》
还书
通知
管理员
读者
注意
• 使用关系和扩展关系之间的区别，A使用B 本质上是A一定使用B，同时增加自己的专 属行为；而A被用例B扩展是说明A是一个一 般用例，B是一个特殊用例，A在某些条件 下可能使用B。
（2）取消预订——本用例提供取消预订图书的功能。
（3）还书——完成还书任务，在还书是要检查所还的书是否超 期、是否有其他读者预订，有的话要通知预订者。
（4）借书——提供借阅书功能 。
• 分析这个用例图，发现“还书”用例应该 被扩展，因为在还书时检查所还图书是否 有预订记录，若有，则应该通知预订者前 来借书。
• 一个用例内部的具体处理细节是由其他图形工具描述 的，用例图只是反映系统的总体功能，以及与这些功 能的相关的角色。有些人可能在画“借书”用例时， 情不自禁地就考虑了“输入读者号和书号”，“检查 图书是否在库？”，“图书数量减1”，“添加读者借 书记录”等等，一旦考虑了这些细节，就会发现用例 图画不下去了。因此，读者注意用例图中不要考虑处 理细节。
uml 基础教程 第三章-用例图
• 用例具有3个明显的特征： （1）用例表明的是一个类，而不是某个具体的实例 （2）用例必须由某一个参与者触发激活后才能执行，即
每个用例至少应该涉及一个参与者 （3）用例是一个完整的描述
椭圆来表示用例
“回顾”饮料销售机
• 在前面的分析中，我们获得了系统中有3个用例，分别是 “Buy soda（买饮料）”、“Restock（供货）”、“Collect（ 收款）”。
• 假设正在对一台饮料机建模，这台饮料销售机允许顾 客选择买一罐饮料或是买一杯饮料。在这种情况下，“Buy Soda”就是一个父用例，“Buy a can of soda”和“Buy a cup of Soda”就是子用例。用例之间的泛化关系建模与类之间 泛化关系建模方法相同，用一条带空心三角形箭头的实线 从子用例指向父用例。
• 要用在用例图上显示某个用例：
➢使用人形符号绘制一个参与者；
➢绘制一个椭圆表示用例，将用例的名称放在椭 圆的中心或椭圆下面的中间位置；
➢使用带箭头或不带箭头的线段来描述参与者和 用例之间的关系。
举例：饮料销售机
• 假设你现在正着手设计一台饮料销售机。为了获得用户 的观点，你会见了许多可能的用户以了解这些用户将如何 与这台机器交互。
“取钱”用例
• 还有一个“取钱”用例，同样也是因为一段时间的流逝， 收款人发起了这个用例。它的前期工作步骤与”供货“一 样，也是打开销售机前端架子。收款人从机器中取出钱， 然后按照”供货“步骤，放回架子锁好机器。 这个用例的前置条件也是时间间隔的流逝，后置条件 是收款人收到了钱。
3.1.1 参与者
• 理想情况下，顾客看到这条消息后会立即选择其它品牌 的饮料。销售机也必须提供给顾客取回原来的钱的选项。 这表示，销售机应给顾客两种选择：让顾客选择另一种饮 料并且给顾客提供这种饮料（如果这种饮料还有存货的话） 或者让顾客选择退钱。
UML功能模型（用例图）
UML功能模型（⽤例图）在UML系统开发中有三个主要的模型：功能模型（从⽤户⾓度展⽰系统的功能，包括⽤例图）、对象模型（采⽤对象，属性，操作关联等概念展⽰系统的结构和基础，包括类图、对象图、包图）、动态模型（展⽰系统的内部⾏为，包括序列图，活动图，状态图）。
下⾯就说⼀说功能模型——⽤例图。
⽤例图是UML建模的⼀部分，也是UML⾥⾯最基础的部分，最主要的功能就是⽤来表达系统的功能性需求或⾏为。
⽤例图是由软件需求分析到最终实现的第⼀步，它描述⼈们如何使⽤⼀个系统，是尾部参与者所能观察到的系统功能模型图，该图呈现了⼀些参与者和⼀些⽤例，以及它们之间的关系，主要⽤于对系统、⼦系统或类的功能⾏为进⾏建模，⽤画图的⽅法来完成。
⽤例图展⽰了⽤例之间以及⽤例与参与者之间是怎样相互联系的。
⽤例图包含留个元素：参与者、⽤例、关联关系、包含关系、扩展关系、泛化关系。
参与者（Actor）：系统外部的⼀个实体，参与⽤例执⾏过程，通过向系统输⼊或请求系统输⼊某些事件来触发系统的执⾏。
参与者的种类概括为三种：系统⽤户、与所建造的系统交互的其他系统以及⼀些可以运⾏的进程。
注意：参与者表⽰⼈和事物与系统发⽣交互时所扮演的⾓⾊，⽽不是特定的⼈或特定的事物；每个参与者需要⼀个具有业务⼀样的名字；⼀个⼈或事物在与系统交互时，可以同时或不同时扮演多个⾓⾊。
⽤例（Use Case）：⽤例是对⼀个活动者使⽤系统的⼀项功能是所进⾏的交互过程的⼀个⽂字描述序列，是系统、⼦系统或类和尾部参与者交互动作序列的说明，包括可选的动作徐磊嗯哼会出现异常的动作序列。
⽤例是岱庙系统各种各个项⽬相关⼈员之间就系统的⾏为所达成的契约，软件开发过程是⽤例驱动的。
⽤例粒度（规模⼤⼩）。
关联关系（Association）：表⽰参与者⽤例之间进⾏通信包含关系（Include）：客户⽤例可以简单地包含提供者⽤例具有的⾏为，并把他所包含的⽤例⾏为作为⾃⾝⾏为的⼀部分。
调⽤⽤例执⾏到包含点，然后执⾏传递给被调⽤⽤例，当被调⽤⽤例完成时，控制在次返回调⽤⽤例。
UML（2）-用例图
UML（2）-⽤例图通过⽤例来捕获系统需求，然后结合参与者进⾏系统功能需求的分析和设计。
由参与者、⽤例及它们之间关系构成的⽤于描述系统功能的动态视图称为⽤例图。
⼀个椭圆，⽤例的名字可以放在椭圆的中⼼或椭圆下⽅的中间位置表⽰⼀个⽤例。
参与者⽤⼈型符号表⽰。
两者之间的关系⽤带箭头的线段描述，其中箭头所指⽅为被动接受者（可以⽤不带箭头的线段描述不带主被动关系）。
要注意的是：箭头的⽅向并不是指信息流的⽅向。
参与者与⽤例之间的信息流默认存在，是双向的。
（⼀）⽤例图的作⽤⽤例图的主要作⽤是描述参与者和⽤例之间的关系，帮助开发⼈员可视化的了解系统功能。
传统的需求表述⽅式是Software Requirment Specification（软件需求规约，SRS），采⽤功能分解⽅式来描述系统功能，将系统功能分解到各个系统功能模块中，然后通过描述每个模块的功能来达到描述整个系统功能的⽬的。
软件需求规约容易混淆需求和设计的界限，导致需求分析包含部分概要设计；通过分割了的系统功能难于表现实现⼀个完整的系统服务。
⽤例图可视化的表达了系统的需求，且把需求与设计分离开。
（⼆）⽤例图构成（1）参与者（Actor）参与者指存在于系统外部且直接与系统进⾏交互的⼈、系统、⼦系统或类的外部实体的抽象。
通过⼈形图来表⽰参与者，参与者的名字在图的下⽅。
参与者是⼀种⾓⾊，⽽不是具体的⼈或事物本⾝。
参与者之间的关系主要是泛化关系，也就是继承关系。
继承关系通过空⼼三⾓箭头的实线段表⽰。
（2）⽤例（Use Case）⽤例是参与者可以感受到的系统服务或功能单元。
它是以⽤户的⾓度上来描述系统功能。
参与者与⽤例之间的关系是关联关系，也称为通信关联。
参与者是⼀种⾓⾊，⽤例不是具体实例，⽽是表⽰⼀个类。
⽤例包含的系统功能有⼤有⼩，这就是⽤例的粒度，粒度⼤，⽤例包含的功能多。
⽤例的粒度重要的是⼀个度。
它决定了⽤例模型级的复杂度，也决定了每个⽤例内部的复杂度。
2.设计模式常用的UML图分析（用例图、类图与时序图）
2.设计模式常⽤的UML图分析（⽤例图、类图与时序图）1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。
2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况，⽤于建⽴需求模型。
⽤例特征保证⽤例能够正确捕捉功能性需求，判断⽤例是否准确的依据。
1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中，参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务，于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中，⼀个实际⽤户可能对应系统的多个参与者。
不同⾓⾊也可以只对应⼀个参与者，从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。
系统的功能由系统单元所提供，并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。
系统单元⽤椭圆表⽰，椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
箭头指向：指向消息接收⽅：⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象。
箭头指向：指向⽗⽤例2-类图描述系统中的类，以及各个类之间的关系的静态试图。
表⽰类、接⼝以及它们之间的协作关系，⽤于程序设计阶段。
注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝，则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图，类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性，则每⼀个属性都必须有⼀个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等2. 操作:如果有操作，则每⼀个操作也都有⼀个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。
UML用例图和类图
UML⽤例图和类图1.⽤例图
关联关系：参与者使⽤某个⽤例，箭头指向消息接收⽅。
泛化关系：⼦⽤例继承⽗⽤例，箭头指向⽗⽤例。
包含关系：⽤例分解出的各步骤，箭头指向分解出来的⽤例。
扩展关系：箭头指向基础⽤例。
依赖关系：箭头指向被依赖项。
2.类图
泛化关系：空⼼三⾓实线箭头，继承⾮抽象类
实现关系：空⼼三⾓虚线箭头，继承抽象类、接⼝
聚合关系&组合关系：空⼼、实⼼菱形实线箭头，A箭头指向B，表⽰B由A组成。
是整体与部分的关系
组合关系（实⼼）偏重强依赖，表⽰整体不存在的话部分也不存在，例如，公司不存在了，部门也将不存在了；聚合关系（空⼼）则不同，表⽰的是即使整体不存在了，部分仍然存在；例如，部门撤销了，⼈员不会消失，他们依然存在。
关联关系：⽤直线表⽰时，说明双⽅互相知道；若强调⽅向，例如A指向B，表⽰A知道B，B不知道A
是⼀种拥有的关系,它使⼀个类知道另⼀个类的属性和⽅法；
依赖关系：A依赖于B，是⼀种使⽤的关系
【代码表现】：局部变量、⽅法的参数或者对静态⽅法的调⽤。
UML建模——用例图（UseCaseDiagram）
UML建模——⽤例图（UseCaseDiagram）⽤例图主要⽤来描述⾓⾊以及⾓⾊与⽤例之间的连接关系。
说明的是谁要使⽤系统，以及他们使⽤该系统可以做些什么。
⼀个⽤例图包含了多个模型元素，如系统、参与者和⽤例，并且显⽰这些元素之间的各种关系，如泛化、关联和依赖。
它展⽰了⼀个外部⽤户能够观察到的系统功能模型图。
【⽤途】：帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。
⼀、⽤例图所包含的的元素1. 参与者(Actor)——与应⽤程序或系统进⾏交互的⽤户、组织或外部系统。
⽤⼀个⼩⼈表⽰。
2. ⽤例(Use Case)——⽤例就是外部可见的系统功能，对系统提供的服务进⾏描述。
⽤椭圆表⽰。
3. ⼦系统(Subsystem)——⽤来展⽰系统的⼀部分功能，这部分功能联系紧密。
⼆、⽤例图所包含的的关系 ⽤例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所⽰： a. 关联(Association) 表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
【箭头指向】：⽆箭头，将参与者与⽤例相连接，指向消息接收⽅ b. 泛化(Inheritance) 就是通常理解的继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象的。
在实际应⽤中很少使⽤泛化关系，⼦⽤例中的特殊⾏为都可以作为⽗⽤例中的备选流存在。
【箭头指向】：指向⽗⽤例 c. 包含(Include) 包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。
包含关系对典型的应⽤就是复⽤，也就是定义中说的情景。
但是有时当某⽤例的事件流过于复杂时，为了简化⽤例的描述，我们也可以把某⼀段事件流抽象成为⼀个被包含的⽤例；相反，⽤例划分太细时，也可以抽象出⼀个基⽤例，来包含这些细颗粒的⽤例。
这种情况类似于在过程设计语⾔中，将程序的某⼀段算法封装成⼀个⼦过程，然后再从主程序中调⽤这⼀⼦过程。
UML用例图
银行出纳
管理帐户 转帐
银行官员
存钱 管理信用帐户 信用管理 贷款资金 客户 客户 改变PIN
取钱
付款
信用系统
查阅结余 投资管理 投资资金
<<Actor>> 信用系统
19
财务公司的简化Business Use Case 图
ATM系统的UseCase 图
确定用例1
我们不用关心“记账”的实现方式，而只需关心 “记账”；相应地，用例名称也不应叫做“网络 记账”或“手工记账”
（Role）。参与者有自己的目标，通过与业务或系统的 法律部门：处理涉及租用汽 交互达到目的。 车的事故部门 参与者可以是人，也可以是部门或外部系统，该外部系 统与本系统相互作用，交换信息。外部系统可以是软件 系统，也可以是一个硬设备。 参与者以它的外部视图为特征，不关心它的内部结构。 会员、非会员 在处理参与者时，重要的是角色，并不关心人或人的职 助手、经理 务等属性。 业务参与者：业务需求中出现的参与者。 系统参与者：系统需求中出现的参与者。
9
谁是参与者？
参与者与系统直接相连——间接相连的对象不是 参与者，不应该被包含而作为系统模型的一部分。 例如维修技师的派遣人员就不应是自动售货机的 参与者
谁是参与者？旅行者、旅行社还是是旅行社的网 上订票系统？
10
谁是参与者？
例如唐纳德以顾客身份操作时，他可以动用顾客 对象的方法；以经理身份操作时，他可以动用经 理对象的方法
假定决定用一个全新的系统替代Auk，新系统兼容了Internet访 问，支持客户希望的“虚拟租赁店”。新系统称为Coot。为了缓 解员工培训问题，新接口（柜台终端和激光阅读器）的外观和操作 方式应类似于Auk的接口。
初学UML——用例图
初学UML——⽤例图开始学习UML建模语⾔，从⽤例图⼊⼿。
建模⼯具选择visio ⽤例图描述的是参与者所理解的系统功能，主要元素是⽤例和参与者，是帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。
这时处于项⽬初始，分析⽤户需求的阶段，不⽤管怎么实现具体的功能，只要能向客户形象化的表述项⽬的功能就⾏。
⽤例图有四个部分：⽤例（Use Case), 参与者（Actor),系统边界，关系。
1）参与者（Actor) 参与者是与系统交互的⼈或物。
⾸先当然包括我们的开发系统⽤户，除此之外，与我们开发的系统有关联的其他系统也算是参与者。
在UML图中我们⽤⼀个⼩⼈表⽰。
2）⽤例（Use Case) ⽤例是参与者可以感受到的系统服务或功能单元。
我理解的就是⽤户可以使⽤我们开发的项⽬去做的任何事情任何⽤例都不能在缺少参与者的情况下独⽴存在，同样，任何参与者也必须要有与之关联的⽤例。
在UML图中我们⽤椭圆表⽰：3）系统边界 指系统与系统之间的界限。
把系统边界以外的同系统相关联的其他部分称为系统环境。
在UML图中我们⽤⼀个矩形表⽰。
4）关系 ⽤例图中的关系有4种：关联，泛化，包含和扩展。
关联：表⽰参与者和⽤例之间的交互。
为通信途径，任何⼀⽅都可发送或可接收消息。
箭头指向：指向消息接收⽅。
在UML中⽤直线表⽰ 包含：包含关系⽤来把⼀个较复杂的⽤例所表⽰的功能分解成较⼩的步骤。
包含⽤例是必须的，如果缺少包含⽤例，基⽤例就是不完整的。
包含关系最典型的应⽤就是复⽤。
这种情况类似与在过程设计语⾔中，将程序的某⼀段算法封装成⼀个⼦过程，然后在从主程序中调⽤这⼀⼦过程（这么说好像懂了点）在UML中，包含关系⽤带箭头的虚线段加《include》表⽰，箭头指向被包含的⽤例。
在VISIO中没有找到include包含关系，解决办法：1）选择菜单栏中的'UML'-》单击’构造型‘-》新建-》构造型那⾥输⼊include-》基类那⾥选择归纳，点击确定2）将UML⽤例下的“扩展”拖到绘图页上-》双击或右键属性-》构造下拉列表中选择include-》确定 扩展：扩展关系是指⽤例功能的延伸。
UML用例图
包含关联与扩展关联的区别： 存在包含关联的两个用例，用例必须包含被包含用例；存在 扩展关联的两个用例则有使用被扩展用例的选择权。
4、用例图示例
成绩管理系统用例图
二、如何建立用例图模型
创建用例图模型有4项任务： •找出系统中的角色和用例。 •区分用例的优先次序。 •细化每个用例。 •建立用例图模型结构。
UML的用例图标
获得产品信息
订购货物
支付货款
。。。
订货处理用例
3、用例图的关联
1）角色与用例的关联
角色与用例的关联表示角色与用例相关性。在UML中是使用 一条带箭头的实线连接角色与用例，如下图所示。
成绩管理
2）角色与角色的关联
角色与角色的关联用来表示一般角色与特殊角色的泛化关系。 在UML图中，使用带空心三角箭头的实线表示。如下图所示：
用例与用例的包含关联用来表示一个用例的行为包含了另一个用例 的行为。在UML图中，使用带虚线箭头表示，并在线上标有构造型 <<include>>。如下图所示：
成绩管理
用例与用例的扩展关联用来表示一个用例的行为扩展了另一个用例 的行为。在UML图中，使用带虚线箭头表示，并在线上标有构造型 <<extend>>。如下图所示：
例1 超市进销存系统用例图建模 1、超市进销存系统的需求描述如下： （1）销售 ①售货员接收顾客订购，输入顾客购买的商品，计算总价； ②顾客付款并接收清单； ③售货员保存顾客购买商品的记录清单。 （2）库存 ①库存管理员每天进行盘点一次； ②库存管理员当发现库存商品有损坏时，及时到相关部门报损； ③在供应商的商品到货时，库存管理员首先检查商品是否合格， 并将合格的商品入库处理；当商品进入卖场时，进行商品出库处 理； ④经理、订货员根据需要进行库存商品的模糊查询或详细查询。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2012年 2012年4月
UML与设计模式 与设计模式
18/60 18/60
要点2 要点2：主动语句
欧文丛贝克汉姆处得到传球，守门员 欧文丛贝克汉姆处得到传球，守门员… 贝克汉姆传球给欧文，欧文射门，守门员扑救… 贝克汉姆传球给欧文，欧文射门，守门员扑救 图书管理员…… 图书管理员 系统…… 系统
UML与设计模式 与设计模式
17/60 17/60
要点1 只写“可观测” 要点1：只写“可观测”的
系统通过ADO建立数据库连接，传送SQL查询语 建立数据库连接，传送 系统通过 建立数据库连接 查询语 商品表”查询商品的详细信息… 句，从“商品表”查询商品的详细信息 系统按照查询条件搜索商品的详细信息
2012年 2012年4月
UML与设计模式 与设计模式
13/60 13/60
用例阐述组成
用例名称 用例概述 涉及的参与者 前置条件Preconditions 前置条件 后置条件Postcondition 后置条件 事件流Flow of events 事件流 分支流Subflows 备选流Alternate flow
2012年 2012年4月
UML与设计模式 与设计模式
11/60 11/60
“Borrow Book”用例中的场景 Book”用例中的场景
如，在“Borrow Book”这个用例中，包含着几 ”这个用例中， 个相关的scenario： 个相关的 ： Scenario-1：顺利地借到书 ： Scenario-2：该种书刊不存在 ： Scenario-3：物理书刊都已借出 ： Scenario-4：没有该借阅者信息 ：
2012年 2012年4月 UML与设计模式 与设计模式
3/60
1、用例图：参与者（Actors） 用例图：参与者（Actors）
参与者定义了一组与系统有信息交互关系的人、 参与者定义了一组与系统有信息交互关系的人、 它是用例的客户并与用例进行交互。 事、物。它是用例的客户并与用例进行交互。 一个参与者针对每一个与之通信的用例扮演一 种角色。 种角色。 角色可以是人或外部系统。 角色可以是人或外部系统。它定义了系统的边 界。
2012年 2012年4月 UML与设计模式 与设计模式
15/60 15/60
前置、后置条件(2) 前置、后置条件(2)
某些用例依赖于其他用例 一个用例在离开系统时， 一个用例在离开系统时，可能是另一个用例的 前置条件（例如： 登录” 管理系统” 前置条件（例如：“登录”和“管理系统”） 有助于识别漏掉的用例 如果一个用例的前置条件不能有执行其他用例 满足，可能意味着丢失了用例（例如： 满足，可能意味着丢失了用例（例如：“管理 订单”却没有“登录”用例） 订单”却没有“登录”用例）
状态图 活动图
部署图
2012年 2012年4月
UML与设计模式 与设计模式
2/60
UML图的作用 UML图的作用
UML 可以用于: 可以用于:
使用用例 使用用例（use cases）和参与者（actors） 用例（ cases）和参与者（actors） 描述系统的边界和它的主要功能。 描述系统的边界和它的主要功能。 使用交互图 顺序图、协作图） 交互图（ 使用交互图（顺序图、协作图）具体描述用 例的实现。 例的实现。 使用类图表示系统的静态结构。 类图表示系统的静态结构 使用类图表示系统的静态结构。 使用状态转换图模型化对象的行为。 状态转换图模型化对象的行为 使用状态转换图模型化对象的行为。 使用构件图和部署图 使用构件图和部署图展现系统的物理实现体 构件图和部署图展现系统的物理实现体 系结构。 系结构。 使用衍型（stereotypes）扩展建模能力。 使用衍型（stereotypes）扩展建模能力。
2012年 2012年4月
UML与设计模式 与设计模式
16/60 16/60
事件流描述要点
1.只书写“可观测”的 只书写“可观测” 只书写 2.使用主动语句 使用主动语句 3.句子必须以参与者或系统作为主语 句子必须以参与者或系统作为主语 4.不要涉及界面细节 不要涉及界面细节
2012年 2012年4月
识别用户
子用例可以出现在父用例 出现的任何位置
验证口令 扫描指纹
2012年 2012年4月
UML与设计模式 与设计模式
10/60 10/60
用例阐述文档
场景（ 场景（scenario）： 是参与者和被讨论系统之间 ）： 的一系列特定活动和交互。 的一系列特定活动和交互。每个用例是一组场景的 集合，而每个场景又是一个步骤序列。 集合，而每个场景又是一个步骤序列。 用例阐述文档针对每个用例， 用例阐述文档针对每个用例，描述各个场景
Maintain Curriculum 2012年 2012年4月
Request Course Roster UML与设计模式 与设计模式
Maintain Schedule
5/60
用例之间关系
《include》 》
包含
《extend》 》
扩展 泛化 使用
<<使用>> <<使用>> 使用
2012年 2012年4月
2012年 2012年4月 UML与设计模式 与设计模式
14/60 14/60
前置、后置条件(1) 前置、后置条件(1)
前置条件约束在用例开始前系统 的状态 把它们看做是看门人， 把它们看做是看门人，它阻 止参与者触发该用例直到满 足所有条件 说明在用例触发之前什么必 须为真 后置条件约束用例执行后系统的 状态 用例执行后什么必须为真 对于有多个事件流的用例， 对于有多个事件流的用例， 则应该有多个后置条件
2012年 2012年4月
UML与设计模式 与设计模式
9/60
泛化关系（generalization） 泛化关系（generalization）
和类一样， 和类一样，泛化是指一个用例继承了另一个用 在用例继承中， 例，在用例继承中，子用例可以从父用例继承 行为和含义，还可以增加自己的行为。 行为和含义，还可以增加自己的行为。
kitchen
COURTYARD
dressing room
Elena
User Interface for Status
living room
Current life OK points: 56.38
Get status Set qualities End game
Strength Endurance Endurance Intelligence Patience
2012年 2012年4月
UML与设计模式 与设计模式
12/60 12/60
谁来写用例文档
最完美：业务人员接受训练，写出优美的用例文 最完美：业务人员接受训练， 档 最现实：业务人员提供素材， 最现实：业务人员提供素材，开发人员写用例文 档 最糟糕：业务人员不管， 最糟糕：业务人员不管，完全由开发人员杜撰
2012年 2012年4月
UML与设计模式 与设计模式
19/60 19/60
要点3 要点3：以参与者或系统作主语
参与者…… 参与者 系统…… 系统 图书管理员输入书目和借阅者信息； 图书管理员输入书目和借阅者信息； 系统检索书目 系统检索借阅者 图书管理员将图书借给借阅者 系统记录借阅信息 …..
2012年 2012年4月 UML与设计模式 与设计模式
20/60 20/60
要点4 要点4：不涉及界面细节
会员从下拉框中选择类别 会员在相应文本框中输入查询条件 会员点击“确定” 会员点击“确定”按钮
2012年 2012年4月
UML与设计模式 与设计模式
21/60 21/60
Encounter Courtyard Image (including game characters)
扩展用例是在原用例的基础上增加新的步骤序 列形成的。 列形成的。 原用例被称为基用例 基用例（ case）。 ）。扩展 原用例被称为基用例（base use case）。扩展 只能发生在基用例的序列中的某个具体制定点 这个点叫做扩展点 扩展点（ points）。 上，这个点叫做扩展点（extension points）。
2012年 2012年4月
UML与设计模式 与设计模式
8/60
扩展关系 VS 包含关系
在扩展关系中， 在扩展关系中，基用例不必知道扩展用例 的任何细节，事实上基用例没有扩展也是 的任何细节，事实上基用例没有扩展也是 完整的，只有特定的条件发生了， 完整的，只有特定的条件发生了，扩展用 例的行为才被执行，而包含关系则不同。 例的行为才被执行，而包含关系则不同。
要调查参与者以确定他们的要求： 要调查参与者以确定他们的要求：
Registrar（注册管理员）－ Registrar（注册管理员）－ 维护所有课程信息 Professor（教授）－ Professor（教授）－ 要求选课名单 Student（学生）－ Student（学生）－ 维护选课表 Billing System（记账系统）－ 从注册中心接受 System（记账系统）－ 记账信息
player
Initialize Use Case for Encounter
actors Encounter Use case Initialize Travel to adjacent area Encounter foreign character designer Set rules Use case details Initialize 1. System displays player’s main character in the dressing room. 2. System displays a window for setting his character's qualities. 3. Player allocates the qualities of his main character. 4. Player chooses an exit from the dressing room. 5. System moves player’s main character into the area on the other side of the exit.