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、系统通过库存系统验证要购买的商品是否有足
简述uml用例间的关系
简述uml用例间的关系UML（Unified Modeling Language）是一种用于软件开发的建模语言，它提供了一种标准的图形化表示方法，用于描述系统的结构、行为和交互。
在UML中，用例图是一种常用的图形化表示方式，用于描述系统的功能需求和用户与系统之间的交互。
用例间的关系是指不同用例之间的相互关联和影响。
在UML中，用例间的关系有以下几种：1. 包含关系（Include）：表示一个用例包含另一个用例的功能。
当一个用例需要借用其他用例的功能时，可以使用包含关系来表示。
例如，一个购物车用例可能包含了添加商品、移除商品和结算等子用例。
2. 扩展关系（Extend）：表示一个用例可以在特定条件下扩展另一个用例的功能。
当一个用例的某个功能在特定条件下可以被扩展时，可以使用扩展关系来表示。
例如，一个支付用例可以在用户选择使用优惠券时扩展结算用例的功能。
3. 泛化关系（Generalization）：表示一个用例是另一个用例的特殊情况或特化。
当一个用例继承了另一个用例的功能，并且在此基础上添加了新的功能时，可以使用泛化关系来表示。
例如，一个在线购物系统中的用户登录和游客购物两个用例可以通过泛化关系来表示，游客购物是用户登录的特殊情况。
4. 关联关系（Association）：表示不同用例之间的关联和交互。
当一个用例需要与其他用例进行交互时，可以使用关联关系来表示。
例如，在一个社交网络系统中，用户发布动态和用户评论动态两个用例可以通过关联关系来表示。
5. 依赖关系（Dependency）：表示一个用例依赖于另一个用例。
当一个用例的实现依赖于其他用例时，可以使用依赖关系来表示。
例如，在一个在线购物系统中，购物车结算用例依赖于查看购物车用例。
6. 一般化关系（Realization）：表示一个用例实现了另一个用例的功能。
当一个用例实现了另一个用例定义的接口和行为时，可以使用一般化关系来表示。
例如，一个在线支付系统可以实现支付用例定义的支付接口和行为。
用例图之参与者、用例间的四种关系
⽤例图之参与者、⽤例间的四种关系⽤例图中包括三种元素，参与者，⽤例，它们之间的关系。
下⾯说说参与者与⽤例之间，⽤例与⽤例之间都有哪些关系。
1.关联关系定义：参与者与⽤例之间通常⽤关联关系来描述。
表⽰⽅法：带箭头的实线，箭头指向⽤例。
如图所⽰：2. 泛化关系定义：⼀个⽤例可以被特别列举为⼀个或多个⼦⽤例，这被称为⽤例泛化。
泛化关系在类间也有。
⼦⽤例从⽗⽤例处继承⾏为和属性，还可以添加⾏为或覆盖、改变已继承的⾏为。
表⽰⽅法：带空⼼箭头的实线，箭头指向被泛化（被继承）的⽤例，即⽗⽤例。
（PS：泛化关系的箭头不是指向被泛化，⽽是指向被继承。
泛化和继承是不同的⽅向。
泛化是从下到上的抽象过程，继承是从上到下，从⼀般到特殊的过程。
）如图所⽰：机房收费系统中可以这样应⽤：当系统中具有⼀个或多个⽤例是⼀般⽤例的特化时，就使⽤⽤例泛化。
3.包含关系定义：其中⼀个⽤例（基础⽤例）的⾏为包含了另⼀个⽤例（包含⽤例）的⾏为。
基础⽤例可以看到包含⽤例，并依赖于包含⽤例的执⾏结果。
但是⼆者不能访问对⽅的属性。
表⽰⽅法：虚线箭头+<<include>>字样，箭头指向被包含的⽤例。
如图所⽰：使⽤情况：（1）如果两个以上⽤例有重复的功能，则可以将重复的功能分解到另⼀个⽤例中。
其他⽤例可以和这个⽤例建⽴包含关系。
（2）⼀个⽤例的功能太多时，可以⽤包含关系创建多个⼦⽤例。
4.扩展关系（extend）定义：是把新⾏为插⼊到已有⽤例的⽅法。
个⼈感觉可以叫做特殊情况处理。
⽐如去⾷堂⽤饭卡打饭，绝⼤部分⼈是刷卡，拿饭，两个步骤就完成了。
但是如果某个学⽣的饭卡⾥没钱了，假定不⽤现⾦或者借钱或者赊账等等其他的⽅式来打饭，⽽是必须⽤⾃⼰的饭卡来打饭。
那么他就要先去给饭卡充值。
“饭卡充值”就是“刷卡”的⼀个扩展⽤例。
“饭卡充值”与“刷卡”就是扩展关系。
表⽰⽅法：虚线箭头+<<extend>>字样，箭头指向被扩展的⽤例（即基础⽤例）。
UML类图关系大全(经典)
UML类图关系大全1、关联双向关联：C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。
在GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。
对象引用本身就是有向的，更适合表达我们所讨论的那种关系。
所以这种关系在设计的时候比较少用到，关联一般都是有向的。
使用ROSE 生成的代码是这样的：class C1...{public:C2* theC2;};class C2...{public:C1* theC1;};双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值。
单向关联:C3->C4：表示相识关系，指C3知道C4，C3可以调用C4的公共属性和方法。
没有生命期的依赖。
一般是表示为一种引用。
生成代码如下：class C3...{public:C4* theC4;};class C4...{};单向关联的代码就表现为C3有C4的指针，而C4对C3一无所知。
自身关联（反身关联）：自己引用自己，带着一个自己的引用。
代码如下：class C14...{public:C14* theC14;};就是在自己的内部有着一个自身的引用。
2、聚合/组合当类之间有整体-部分关系的时候，我们就可以使用组合或者聚合。
聚合：表示C9聚合C10，但是C10可以离开C9而独立存在（独立存在的意思是在某个应用的问题域中这个类的存在有意义。
这句话怎么解，请看下面组合里的解释）。
代码如下：class C9...{public:C10 theC10;};class C10...{};组合（也有人称为包容）：一般是实心菱形加实线箭头表示，如上图所示，表示的是C8被C7包容，而且C8不能离开C7而独立存在。
但这是视问题域而定的，例如在关心汽车的领域里，轮胎是一定要组合在汽车类中的，因为它离开了汽车就没有意义了。
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中三种常用的图
1.用例图：用例图是从用户的观点描述系统的功能，它由一组用例、参与者以及他们之间的关系组成他将系统的一个功能描述成一系列事件，这些事件最终对参与者产生有价值的可观测结果参与者（Actor）：代表与系统交互的外部实体用例（Use-Case）：表示系统能提供的功能，如：登录，查询等关联关系：当参与者与用列进行交互时，用例与参与者之间有关联关系，用一条直线表示这种关系参与者之间可能存在泛化关系，类似的参与者可以用泛化关系组成一般与特殊的层析结构如：经理初次之外，用例之间还存在一定的关系，具体包括包含（include）、扩展（extend）、泛化（Generalization）等3种关系（1）包含关系一个复杂系统中，不同用例之间可能存在一些相同的行为，这时可将这些相同的行为提取出来单独组成一个用例。
当其他用例使用该用例时，用例之间便形成了包含关系包含关系用带关键字<<include>>的虚线来表示，虚线指向被包含的用例注册新用户（2）扩展关系在用例的执行过程中，可能会出现异常行为，也可能在不同的流程分支中选择执行，这时可将异常行为或可选分支抽象成一个单独的扩展用例，它与主用例之间形成扩展关系扩展关系用带关键字<<extend>>的虚线表示，箭头指向被扩展的用例注册（3）泛化关系与参与者之间的泛化关系一样，用例之间的泛化关系是描述用例之间一般与特殊关系的，不同的子用例代表了父用例的不同实现方法。
密码找回2.类图类图描述系统的静态结构，表示系统中的类、类与类之间的关系以及类的属性和操作类用一个矩形方框表示，方框被分成3部分，最上面显示类名，中间部分显示类的属性，最下面显示类的操作类之间的关系包括关联、聚合、泛化、依赖等类型关联（Association）是一种结构定义，表达模型元素间的一种语义联系，它是对具有共同的结构特性、行为特性、关系和语义链的描述，使用一条连接在两个类之间的实线表示，关系的每一端用数字表示关系的重数。
UML用例图的创建与应用详解
UML用例图的创建与应用详解UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言。
在软件开发过程中，UML用例图是一种重要的工具，用于描述系统的功能需求和用户与系统之间的交互。
本文将详细介绍UML用例图的创建与应用。
一、UML用例图的概念和基本元素UML用例图是一种用于描述系统功能的图形化表示方法。
它主要由用例（Use Case）、参与者（Actor）和关系（Relationship）三个基本元素组成。
1. 用例（Use Case）：用例是对系统功能的描述，它表示系统与用户之间的交互。
每个用例代表一个特定的用户需求或系统功能。
用例通常以椭圆形状表示，并用文本标识。
2. 参与者（Actor）：参与者是与系统进行交互的外部实体，可以是人、其他系统或外部设备。
参与者以人的图标或简单的方框表示，并用文本标识。
3. 关系（Relationship）：用例和参与者之间的关系有三种：关联（Association）、包含（Include）和扩展（Extend）。
关联表示用例和参与者之间的关联关系，包含表示一个用例包含另一个用例，扩展表示一个用例可以根据条件扩展另一个用例。
二、UML用例图的创建步骤创建UML用例图可以分为以下几个步骤：1. 确定系统边界：首先确定系统的边界，即明确系统与外部实体的交互范围。
2. 确定参与者：根据系统边界确定参与者，包括系统的用户、其他系统或外部设备。
3. 确定用例：根据系统需求确定用例，描述系统的功能和用户需求。
4. 绘制用例图：根据确定的参与者和用例，使用UML工具绘制用例图，将参与者和用例按照关系连接起来。
5. 完善用例图：根据需要，可以添加用例之间的关系，如包含和扩展关系。
三、UML用例图的应用场景UML用例图在软件开发过程中有广泛的应用场景，以下是几个常见的应用场景：1. 需求分析：用例图可以帮助分析人员理解用户需求，明确系统的功能需求和用户与系统之间的交互。
UML（2）-用例图
UML（2）-⽤例图通过⽤例来捕获系统需求，然后结合参与者进⾏系统功能需求的分析和设计。
由参与者、⽤例及它们之间关系构成的⽤于描述系统功能的动态视图称为⽤例图。
⼀个椭圆，⽤例的名字可以放在椭圆的中⼼或椭圆下⽅的中间位置表⽰⼀个⽤例。
参与者⽤⼈型符号表⽰。
两者之间的关系⽤带箭头的线段描述，其中箭头所指⽅为被动接受者（可以⽤不带箭头的线段描述不带主被动关系）。
要注意的是：箭头的⽅向并不是指信息流的⽅向。
参与者与⽤例之间的信息流默认存在，是双向的。
（⼀）⽤例图的作⽤⽤例图的主要作⽤是描述参与者和⽤例之间的关系，帮助开发⼈员可视化的了解系统功能。
传统的需求表述⽅式是Software Requirment Specification（软件需求规约，SRS），采⽤功能分解⽅式来描述系统功能，将系统功能分解到各个系统功能模块中，然后通过描述每个模块的功能来达到描述整个系统功能的⽬的。
软件需求规约容易混淆需求和设计的界限，导致需求分析包含部分概要设计；通过分割了的系统功能难于表现实现⼀个完整的系统服务。
⽤例图可视化的表达了系统的需求，且把需求与设计分离开。
（⼆）⽤例图构成（1）参与者（Actor）参与者指存在于系统外部且直接与系统进⾏交互的⼈、系统、⼦系统或类的外部实体的抽象。
通过⼈形图来表⽰参与者，参与者的名字在图的下⽅。
参与者是⼀种⾓⾊，⽽不是具体的⼈或事物本⾝。
参与者之间的关系主要是泛化关系，也就是继承关系。
继承关系通过空⼼三⾓箭头的实线段表⽰。
（2）⽤例（Use Case）⽤例是参与者可以感受到的系统服务或功能单元。
它是以⽤户的⾓度上来描述系统功能。
参与者与⽤例之间的关系是关联关系，也称为通信关联。
参与者是⼀种⾓⾊，⽤例不是具体实例，⽽是表⽰⼀个类。
⽤例包含的系统功能有⼤有⼩，这就是⽤例的粒度，粒度⼤，⽤例包含的功能多。
⽤例的粒度重要的是⼀个度。
它决定了⽤例模型级的复杂度，也决定了每个⽤例内部的复杂度。
UML用例图中的关系
UML用例图中的关系用例之间的关系做一个总结。
1、关联关系（association）：用带箭头的实线表示，由参与者指向用例。
关联关系是指参与者与用例之间的关系，是参与者和用例之间的通信。
一个参与者可以关联多个用例，一个用例可以关联多个参与者。
但是每一对参与者和用例之间（即一条连线上）的通信必须是唯一的，否则则存在可以合并的参与者或者用例。
2、泛化关系（dependency）：用带空心三角形的实线表示，由子级指向父级。
泛化关系是参与者于参与者之间或者用例于用例之间的关系。
泛化即继承关系，子用例（子参与者）继承了父用例（父参与者）的一切行为和通信。
同时还可以增加属于自己独有的行为和通信。
以机房收费系统中的三个参与者为例。
操作员继承了一般用户的所有功能，同时增加了充值、工作记录查询等功能。
而管理员则继承了操作员的一切功能，同时增加了结账和报表生成等功能。
用例图如下：3、包含关系（include）：用带箭头的虚线和版型（include）表示，由基本用例指向被包含用例。
包含关系是用例之间的关系。
所谓的包含关系是指当一个用例需要以另一个用例的执行为前提才能执行时，这两个用例间的关系。
即一个用例不能被独立执行，随着另一个用例的执行而执行，也随着另一个用例的消亡而消亡。
以机房收费系统中的结账功能为例，如下图：在上图中结账用例和汇总退还金额用例之间即包含关系。
如果结账用例不执行时就无法执行汇总退还金额用例，而结账用例结束那么汇总用例也随之结束。
4、扩展关系（extend）：用带箭头的虚线和版型（extend）表示，右基本用例指向扩展用例。
扩展关系也是用例之间的关系。
它指的是，当一个用例执行时出现某种特定的条件时，激活另一个用例。
这里的一定条件称之为扩展点，被激活的用例称之为扩展用例。
以机房收费系统中，上机时余额不足为例，如下图：上图中，上机用例执行时若发现学生卡号中的余额小于最低余额时则直接转入充值用例，但是充值用例也可以单独被执行。
UML图标含义及记忆方法
UML图标含义及记忆⽅法
记忆技巧：
箭头的⼀⽅为被动⽅（被调⽤者）；
箭头的端点为主动⽅（调⽤者）。
箭头为封闭三⾓形时，表⽰类间关系
箭头为半封闭尖括号时，表⽰类内关系。
其中，虚线表⽰参数强制依赖关系，实线表⽰属性关系。
⼀对⼀的有：依赖、关联；多对⼀的有聚合、组合
对于继承（实现）：⼦类（实现）是主动⽅，⽗类（接⼝）是被动⽅
UML 有⼏种关系图标：泛化（继承），实现，依赖，关联，聚合，组合
1. 泛化（继承） B——▷A B 类作为 A 类的⼦类存在。
2. 实现 B------▷A B 类实现 A 接⼝。
3. 依赖 A------>B B 类作为 A 类某个⽅法的参数，表⽰A想做某些事情需要依赖 B，不然做不成。
虚线参数强依赖。
4. 关联 A——>B（单向） B 类作为 A 类的属性存在，语义上 A 类和 B 类的地位或⽔平相等。
实现属性若关
联
A—— B（双向） B 类作为 A 类的属相存在， A 类作为 B 类的属性存在，语义上 A 类和 B 类的地位或⽔平相等。
5. 聚合 A♢——>B B 类作为 A 类的属性存在，语义上 B 类可作为 A 类的⼀部分，这个关系可有可
⽆，是A has--a B 的关系，如房⼦（A），桌⼦（B）
6. 组合 A♦——>B B 类作为 A 类的属性存在，语义上 B 类是 A 类的⼀部分，这部分必须有，是 A
contain--a B 的关系，如（⼈），⼤脑（B）。
⼀般情况下，继承和实现⽐较简单，就是其他⼏个关系会有点⼩复杂。
UML用例图中的包含、扩展、泛化关系
UML用例图中包含(include)、扩展(extend)和泛化(generalization）三种关系详解共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。
基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。
基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。
但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。
这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。
这时包含关系可以用来理清关系。
2、扩展(extend)扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。
扩展用例为基用例添加新的行为。
扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。
但是扩展用例对基用例不可见。
对于一个扩展用例，可以在基用例上有几个扩展点。
例如，系统中允许用户对查询的结果进行导出、打印。
对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。
导入、打印和查询相对独立，而且为查询添加了新行为。
UML用例图说明
UML⽤例图说明前些时间参加了潘加宇⽼师的技术讲座，UML建模技术受益匪浅。
我也把平时的⼀些积累和上次的收获总结在这篇⽂章中，主要讲解⽤例图相关的知识。
⽤例图是软件需求分析到最终实现的第⼀步，它描述⽤户如何使⽤系统及使⽤系统什么样的功能。
⽤例图从业务⾓度上体现谁来使⽤系统、⽤户希望系统提供什么样的服务，以及⽤户需要为系统提供的服务，也便于软件开发⼈员最终实现这些功能。
⽤例图在开发中被⼴泛的应⽤，但是它最常⽤来描述系统提供了什么样的功能给什么样的⽤户使⽤。
在官⽅⽂档中⽤例图包含六个元素，分别是：执⾏者(Actor)、⽤例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
但是有些UML的绘图⼯具多提供了⼀种直接关联关系(DirectedAssociation)。
⽤例图可⼀个包含注释和约束，还可⼀个包含包，⽤于将模型中的元素组合成更⼤的模块。
有时，可以将⽤例的实例引⼊到图中。
⽤例图模型如下所⽰，执⾏者⽤⼈形图标来标识，⽤例⽤椭圆来表⽰，连线表⽰它们之间的关系。
⼀、执⾏者（Actor）1、执⾏者概念是指⽤户在系统中扮演的⾓⾊。
如图1-1是⼀个⽤户管理的⽤例图，图中的⽤户、管理员就是⽤例的执⾏者。
图1-12、从业务中找出执⾏者获取系统⽤例⾸先要找出系统的执⾏者。
我们可以通过⽤户回答⼀些问题的答案来识别执⾏者。
可以参考以下问题：1. 谁使⽤系统的主要功能（主要使⽤者）？2. 谁需要系统⽀持他们⽇常⼯作？3. 谁来维护、管理系统使其正常⼯作（辅助使⽤者）？4. 系统需要控制哪些硬件？5. 系统需要其他哪些系统交互？这⾥包含其他计算机系统或者应⽤程序。
6. 对系统产⽣结果感兴趣的是哪些⼈和哪些事物？3、执⾏者之间关系因为执⾏者是类，所以多个执⾏者之间可以具有与类相同的关系。
在⽤例图中，使⽤了泛化关系来描述多个执⾏者之间的公共⾏为。
UML用例图中泛化、扩展、包括
UML⽤例图中泛化、扩展、包括在画⽤例图的时候，理清⽤例之间的关系是重点。
⽤例的关系有泛化(generalization)、扩展(extend)和包含(include)。
其中include和extend 最易混淆。
下⾯我们结合实例彻底理清三者的关系。
基本概念⽤例图（Use Case Diagram）:⽤例图显⽰谁是相关的⽤户，⽤户希望系统提供什么服务（⽤例），以及⽤例之间的关系图。
⽤例图主要的作⽤是获取需求、指导测试。
⽤例图的4个基本组件：参与者(Actor)、⽤例(Use Case)、关系(Relationship)和系统。
泛化(generalization)：泛化关系是⼀种继承关系，⼦⽤例将继承基⽤例的所有⾏为，关系和通信关系，也就是说在任何使⽤基⽤例的地⽅都可以⽤⼦⽤例来代替。
泛化关系在⽤例图中使⽤空⼼的箭头表⽰，箭头⽅向从⼦⽤例指向基⽤例。
扩展(extend)： extend关系是对基⽤例的扩展，基⽤例是⼀个完整的⽤例，即使没有⼦⽤例的参与，也可以完成⼀个完整的功能。
extend的基⽤例中将存在⼀个扩展点，只有当扩展点被激活时，⼦⽤例才会被执⾏。
extend关系在⽤例图中使⽤带箭头的虚线表⽰(在线上标注<<extend>>)，箭头从⼦⽤例指向基⽤例。
包含(include)： include为包含关系，当两个或多个⽤例中共⽤⼀组相同的动作，这时可以将这组相同的动作抽出来作为⼀个独⽴的⼦⽤例，供多个基⽤例所共享。
因为⼦⽤例被抽出，基⽤例并⾮⼀个完整的⽤例，所以include关系中的基⽤例必须和⼦⽤例⼀起使⽤才够完整，⼦⽤例也必然被执⾏。
include关系在⽤例图中使⽤带箭头的虚线表⽰(在线上标注<<include>>)，箭头从基⽤例指向⼦⽤例。
实例需求场景联通客户响应OSS。
系统有故障单、业务开通、资源核查、割接、业务重保、⽹络品质性能等功能模块。
UML的图和关系
系统的详细状态在某一时刻的快照，常用于表 示复杂类图的一个实例。 UML中对象图与类图具有相同的表示形式。 在UML中，对象图的使用相当有限，主要用于 表达数据结构的实例，以及了解系统在某个特 定时刻的具体情况。
部署图显示了系统的硬件，安装在硬件上的软件，用于连接硬件的各 种协议和中间件等。
部署模型的目的：描述一个具体应用的主要部署结构，通过对各种硬 件，在硬件中的软件以及各种连接协议的显示，可以很好的描述系统 是如何部署的；平衡系统运行时的计算资源分布；可以通过连接描述 组织的硬件网络结构或者是嵌入式系统等具有多种硬件和软件相关的 系统运行模型。
（一）、用例图
用例方法是完全从外部来定义系统功能， 它把需求和设计完全的分离开来。我们不 用关心系统内部是如何完成各种功能的， 系统对于我们来说就是一个黑箱子。
用例图清楚地描述了使用者及它们之间的 泛化关系，用例及用例之间的泛化、扩展 关系，用例和参与者之间的关联关系，可 从用例图中得到对于被定义系统的一个总 体印象。
一般可以用状态机对一个对象的生命周期建模，状 态图用于显示状态机（State Machine Diagram）， 重点在与描述状态图的控制流。
3、导图概述
4、状态图（机房收费系统-注册）
（五）、活动图
1、定义：阐明业务用例实现的工作流程。 2、简要介绍：活动图是UML用于对系统的动
态行为建模的另一种常用工具，它描述活动的 顺序，展现从一个活动到另一个活动的控制流。 活动图在本质上是一种流程图。活动图着重表 现从一个活动到另一个活动的控制流，是内部 处理驱动的流程。 活动图描述的是对象活动的顺序关系所遵循的 规则，它着重表现的是系统的行为，而非系统 的处理过程。活动图能够表示并发活动的情形， 活动图是面向对象的。
UML 用例图、关系图、活动图
网上 查询 读者 扩展 预定 扩展
查询 图书馆工作 人员 取消 预定
还书
通知
借书
武当山旅游门户网站（ ） 分类信息
注意
在画用例图时要特别注意：用例图是系统分析、 设计和实现的一个最基础的图形，在初期是不一 定要考虑太多的处理细节。 一个用例内部的具体处理细节是由其他图形工具 描述的，用例图只是反映系统的总体功能，以及 与这些功能的相关的角色。有些人可能在画“借 书”用例时，情不自禁地就考虑了“输入读者号 和书号”，“检查图书是否在库？”，“图书数 量减1”，“添加读者借书记录”等等，一旦考虑了 这些细节，就会发现用例图画不下去了。因此， 读者注意用例图中不要考虑处理细节。
武当山旅游门户网站（ ） 分类信息
注意：
活动图描述多个角色之间的处理非常有 效，一张活动图只能有一个开始状态， 但可以有多个结束状态。 一个活动可以与多个实体对象相关，这 里的相关指的是一种访问操作。在上面 “借书”活动图中，“检查读者有效” 的活动，要访问“读者”对象和“借还 书记录”对象，检查“读者编号”的有 效性和读者借书数量。
状态图中的转移可以由三部分组成： 事件[条件]/动作
武当山旅游门户网站（ ） 分类信息
角色
角色是指与系统交互的人或物。 角色可以有四种类型：系统的使用者、硬件设备、 外部系统和时间。
系统使用者是最重要的角色，例如，在图书信息管理系 统中的系统使用者有读者和图书馆的工作人员，包括采 购、编目和办公室的工作人员。 其他外部应用系统。 硬件设备，不同的硬件设备具有不同的特性和不同的处 理方式。 时间作为角色,经过一定的时间触发系统中的某个事件。
认识活动图认识活动图图书馆图书信息管理系统借书活动图图书馆图书信息管理系统借书活动图借书申请检查读者有效性读者信息借书记录读者无效图书无效检查图书有效性检查预订预订记录清除预订记录图书信息借书记录修改图书信息创建借书记录图书信息读者无效借书超期图书无效有预订读者流通组工作人员读者图书编号活动图中的主要图形元素活动图中的主要图形元素泳道
02 UML用例图基础知识
表示符号
表示参与者与用例之间的通信，任何一方都可发送 或接收消息。
uc 继承关系，子用例将继承基用例 的所有行为、关系和通信关系，也就是说在任何使 用基用例的地方都可以用子用例来代替。
泛化关系在用例图中使用空心的箭头表示，箭头方 向从子用例指向基用例。 uc Use Case Model
参与者总是处在正在建模的系统的外部，不是系统
的组成部分，是与系统、子系统或类发生交互的外 部用户、进程或其他系统。
参与者有3大类，即系统用户、与本系统交互的其 他系统和一些可以运行的进程。
名称
说明
人
即用户，是最常用的参与者。例如，汽车租赁公司的汽车租赁者，即客
户。
其他的系统
在当前的项目范围外，建立与其他系统的接口。该类位于程序边界之外
注：任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的
用例。
2）用例图形表示
在UML中，用例使用一个椭圆来表示，用例的名称写在椭圆里，如 下图所示：
3）用例命名
用例是从用户的角度来描绘系统的功能，是根据所执行的实例来命名 的，通常情况下，用例名是一个短语，例如浏览帐户、登陆系统等。 命名的基本原则有以下几种：
一、什么是用例图（Use Case Diagram） 二、用例图的组成 三、用例建模技术
用例图也称为用户模型图，是由软件需求分析到最终实现的第1步， 它是从用户的角度来描述系统功能，描述人们希望如何使用一个系统。 用例图显示谁将是相关的用户、用户希望系统提供什么服务，以及用 户需要为系统提供的服务。
线上标注<u<c Usee CaxsetMoedenl d>>)，箭头从子用例指向基用
例。
UML用例图的用例拓展与关联分析
UML用例图的用例拓展与关联分析UML（Unified Modeling Language）是一种用于软件系统的建模语言，用例图是UML中的一种图示工具，用于描述系统的功能需求和用户与系统之间的交互。
在用例图中，用例是对系统功能的描述，用例之间的关系则表示了不同用例之间的交互和依赖关系。
本文将探讨UML用例图中用例的拓展与关联分析。
一、用例拓展用例拓展是指在某个用例执行过程中，根据特定的条件和需求，对该用例进行扩展或修改。
用例拓展可以通过扩展关系（extend）来表示，该关系表示一个用例的行为可以被另一个用例的行为所扩展。
扩展关系可以帮助我们更好地理解系统的功能需求，并且可以在系统设计过程中提供更多的灵活性。
举个例子，假设我们正在设计一个在线购物系统的用例图。
其中一个基本用例是“下订单”，但是在某些情况下，用户可能需要修改订单中的商品数量或者删除某个商品。
这时，我们可以通过用例拓展的方式来描述这些特定的需求。
我们可以创建一个名为“修改订单”的拓展用例，它扩展了“下订单”用例，并且在用户需要修改订单时触发。
二、用例关联分析用例关联分析是指在用例图中，通过关联关系（association）来描述不同用例之间的关联和依赖关系。
关联关系表示了用例之间的相互关系，可以帮助我们更好地理解系统中不同用例之间的交互和依赖。
举个例子，假设我们正在设计一个社交媒体应用的用例图。
其中一个基本用例是“发布动态”，而另一个基本用例是“评论动态”。
这两个用例之间存在着关联关系，因为用户在发布动态后，其他用户可以对该动态进行评论。
我们可以在用例图中使用关联关系来表示这种关联和依赖关系。
除了关联关系，还有其他类型的用例关系可以用于描述不同用例之间的关系，如包含关系（include）和泛化关系（generalization）。
这些关系可以帮助我们更好地组织和理解系统的功能需求，同时也可以在系统设计中提供更多的灵活性和可扩展性。
综上所述，UML用例图的用例拓展与关联分析是系统设计过程中重要的一环。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1UML用例图中包含(include)、扩展(extend)和泛化(generalization）三种关系详解
共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)
包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。
基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。
基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。
但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。
这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。
这时包含关系可以用来理清关系。
2、扩展(extend)
扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。
扩展用例为基用例添加新的行为。
扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。
但是扩展用例对基用例不可见。
对于一个扩展用例，可以在基用例上有几个扩展点。
例如，系统中允许用户对查询的结果进行导出、打印。
对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。
导入、打印和查询相对独立，而且为查询添加了新行为。
因此可以采用扩展关系来描述：
4、泛化(generalization)
泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。
子用例可以使用父用例的一段行为，也可以重载它。
父用例通常是抽象的。
在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。
例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：
上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。
************************************************************** ***
(1)系统整体用例图
按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!
转：UML中扩展和泛化的区别
泛化表示类似于OO术语“继承”或“多态”。
UML中的Use Case 泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。
如下：
●泛化侧重表示子用例间的互斥性；
●包含侧重表示被包含用例对Actor提供服务的间接性；
●扩展侧重表示扩展用例的触发不定性；详述如下：
既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：
⒈无条件发生：肯定发生的；
⒉有条件发生：未必发生，发生与否取决于系统状态；
因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。
进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。
同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。
另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。