第5章-UML用例图要点
合集下载
软件体系结构课件第5章统一建模语言
2:GetPrefSet()
10:PrefSet(date_mg)
1:GetPrefSet()
:MeetingInitiator
第5章 统一建模语言 直接使用UML建模 – 会议安排系统的类图
Person
StronglyConflicts With
Conflicts With
Important Attendee
0..* 0..*
0..* Profers
Attendee
1..* 1..* 0..* 0..*
11 1 1
1
Meeting Initiator
Find.exe
Query .dll
部署图 定义系 统中软 硬件的 物理体
系结构
第5章 统一建模语言 部署图
客户端:个人PC QueryClient.exe
服务器
《TCP/IP》 查询
QueryServer.exe 部署图
定义系
统中软
Find.exe
硬件的
物理体
Query.dll系结构
第5章 统一建模语言
第5章 统一建模语言
直接使用UML建模 – UML中的通用表示
➢ 字符串：表示有关模型的信息； ➢ 名字：表示模型元素； ➢ 标号：不同于编程语言中的标号，是用于表示或说明图形符号的字
符串； ➢ 特殊字符串：表示某一模型元素的特性； ➢ 类型表达式：声明属性、变量及参数，含义同编程语言中的类型表
0
10
20
30s 时间刻度
第5章 统一建模语言 状态图
提交订单 已审核 印前处理
客户付钱
已付款
已处理
进行冲印
冲印中 冲印完成
描述满足 用例要求 所要进行 的活动以 及活动间 的完约成束关 系，有利 于识别并 行活动
第5章-UML用例图
• 用例图清楚地描述了使用者及它们之间的泛化关系，用例及用例 之间的泛化、扩展关系，用例和参与者之间的关联关系，可从用 例图中得到对于被定义系统的一个总体印象。
5.2 UML包含的内容
5.2.3 用例图
用例图主要包括3个部分： 用例（User Case） 参与者（Actor） 关系
AssociationName UseCaseName
5.2 UML包含的内容
5.2.3 用例图-用例
用例描述
对用例的描述，可以使用自然语言，活动图和伪代码，也可以使 用用户自己定义的语言。无论用什么形式，所描述的动作序列应该 足够清晰，是其他人员易于理解。
在用例中只需要描述参与者和系统彼此对对方做了那些事，不需 要描述怎么做。
最简单的用例描述，至少会包含一条“基本流程（basic course）” ，用来描述正常的使用。
5.2.3 用例图-用例
用例描述
用例图只能告诉我们系统应具有的功能及参与者，让用户对系统 有一个总体的认识。而没有说明用例的执行过程。
因此，对于每一个用例，我们还需要有详细的描述信息，以便让 别人对于整个系统有一个更加详细的了解。
UML是一套标准的图形语言，其中只提出了13种图，没有将用例 描述考虑在内，也当然没有任何标准的用例描述格式了。
5.2 UML包含的内容
5.2.3 用例图-参与者
如何确定参与者？
（1）使用系统主要功能的人是谁（即主要角色）？ （2）需要借助于系统完成日常工作的人是谁？ （3）谁来维护和管理系统（次要角色），保证系统正常工作？ （4）系统控制的硬件设备有哪些？ （5）系统需要与哪些其它系统交互？其它系统包括计算机系统，也包 括该系统将要使用的计算机中的其它应用软件。其它系统也分成二类， 一类是启动该系统的系统，另一类是该系统要使用的系统。 （6）对系统产生的结果感兴趣的人或事是哪些？
5.2 UML包含的内容
5.2.3 用例图
用例图主要包括3个部分： 用例（User Case） 参与者（Actor） 关系
AssociationName UseCaseName
5.2 UML包含的内容
5.2.3 用例图-用例
用例描述
对用例的描述，可以使用自然语言，活动图和伪代码，也可以使 用用户自己定义的语言。无论用什么形式，所描述的动作序列应该 足够清晰，是其他人员易于理解。
在用例中只需要描述参与者和系统彼此对对方做了那些事，不需 要描述怎么做。
最简单的用例描述，至少会包含一条“基本流程（basic course）” ，用来描述正常的使用。
5.2.3 用例图-用例
用例描述
用例图只能告诉我们系统应具有的功能及参与者，让用户对系统 有一个总体的认识。而没有说明用例的执行过程。
因此，对于每一个用例，我们还需要有详细的描述信息，以便让 别人对于整个系统有一个更加详细的了解。
UML是一套标准的图形语言，其中只提出了13种图，没有将用例 描述考虑在内，也当然没有任何标准的用例描述格式了。
5.2 UML包含的内容
5.2.3 用例图-参与者
如何确定参与者？
（1）使用系统主要功能的人是谁（即主要角色）？ （2）需要借助于系统完成日常工作的人是谁？ （3）谁来维护和管理系统（次要角色），保证系统正常工作？ （4）系统控制的硬件设备有哪些？ （5）系统需要与哪些其它系统交互？其它系统包括计算机系统，也包 括该系统将要使用的计算机中的其它应用软件。其它系统也分成二类， 一类是启动该系统的系统，另一类是该系统要使用的系统。 （6）对系统产生的结果感兴趣的人或事是哪些？
uml
都会成为CRUD
光CRUD能为 actor提供价值吗？
识别用例
——用例的“粒度”
一个用例背后可能隐藏着许多数据操作
识别用例
——用例的“粒度”：如果确实是纯 CRUD
如果CRUD不涉及复杂的交互，一个用例“管
理××”即可 不管是C、R、U、D，都是为了完成“管理” 的目标 甚至很多种基本数据的管理都可以用一个用例 表示
系统外部的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统输入某些事
件来触发系统的执行。 由参与用例时所担当的角色来表示。 每个参与者可以参与一个或多个用例。
5.1.2 参与者
参与者的种类：
系统用户 与所建造的系统交互的其他系统
一些可以运行的进程
确定参与者
确定参与者
对参与者建模的过程中需要注意的问题
参与者对于系统而言总是外部的 参与者可以直接或间接的同系统交互
一个人或事物在与系统交互时，可以扮演多个
角色 每一个参与者必须有简短的描述
参与者间的关系
参与者(actor)之间可 以存在泛化关系，表示 一个一般性的参与者与 另一个更为特殊的参与 者之间的联系。 参与者间的泛化关系 示例：
如何寻找系统的参与者
谁使用系统的主要功能？ 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务？ 谁负责维护、管理并保持系统正常运行？ 系统需要应付（处理）哪些硬设备？ 系统需要和哪些外部系统交互？ 谁（或什么）对系统运行产生的结果感兴趣？ 有没有自动发生的事件
主事件流
备选事件流
1a.非法用户：提示用户名或密码错误； 5b.学生的实验结果文件夹未按要求命名，不是以学期和学号两部分组成 ：系统提示文件夹命名错误； 5b.学生所提交的实验结果文件夹是空：系统提示文件夹为空； 6c.在上传实验结果的过程中突然中断：系统要求学生重新上传实验结果 ； 6c.学生误传了实验结果，把其他课程的实验提交到该实验课，可以进行 删除操作，重新上传，重复3～7的操作； 6c.学生未按时提交实验结果：系统提示已过期；
UML 用例图的基本概念
系统名称 参与者
用例
UML建模语言
5.2.3 用例 1. 用例的概念 用例（Use Case）是参与者（角色）可以感 受到的系统服务或功能单元。
带路径名的用例
UML建模语言
2. 用例的识别
任何用例都不能在缺少参与者的情况下独 立存在。同样，任何参与者也必须要有与 之关联的用例，所以识别用例的最好方法 就是从分析系统参与者开始，在这个过程 中往往会发现新的参与者。
细化后 的学生 管理系 统
UML建模语言
4. 用例规约
用例图只是在总体上大致描述了系统所提 供的各种服务，让用户对系统有一个总体 的认识。但对于每一个用例还需要有详细 的描述信息，以便让其他人对于整个系统 有一个更加详细地了解，这些信息包含在 用例规约之中。而用例模型指的也不仅仅 是用例图，而是由用例图和每一个用例的 详细描述——用例规约所组成的。
1. 参与者的概念 2. 参与者的确定 3. 参与者间的关系
UML建模语言
1.参与者的概念
参与者（Actor）是指存在于 系统外部并直接与系统进行交 互的人、系统、子系统或类的 外部实体的抽象。
UML建模语言
2. 参与者的确定
在获取用例前首先要确定系统的参与者，寻找参与者可 以从以下问题入手： .系统开发出来后，使用系统主要功能的是谁？ .谁需要借助系统来完成日常的工作？ .系统需要从哪些人或其他系统中获得数据？ .系统会为哪些人或其他系统提供数据？ .系统会与哪些其他系统交互？其他系统可以分为两类， 一类是该系统要使用的系统，二是启动该系统的系统， 包括计算机系统和计算机中的其他应用软件。 .系统是由谁来维护和管理的，以保证系统处于工作状 态？ .系统控制的硬件设备有哪些？ .谁对本系统产生的结果感兴趣？
用例
UML建模语言
5.2.3 用例 1. 用例的概念 用例（Use Case）是参与者（角色）可以感 受到的系统服务或功能单元。
带路径名的用例
UML建模语言
2. 用例的识别
任何用例都不能在缺少参与者的情况下独 立存在。同样，任何参与者也必须要有与 之关联的用例，所以识别用例的最好方法 就是从分析系统参与者开始，在这个过程 中往往会发现新的参与者。
细化后 的学生 管理系 统
UML建模语言
4. 用例规约
用例图只是在总体上大致描述了系统所提 供的各种服务，让用户对系统有一个总体 的认识。但对于每一个用例还需要有详细 的描述信息，以便让其他人对于整个系统 有一个更加详细地了解，这些信息包含在 用例规约之中。而用例模型指的也不仅仅 是用例图，而是由用例图和每一个用例的 详细描述——用例规约所组成的。
1. 参与者的概念 2. 参与者的确定 3. 参与者间的关系
UML建模语言
1.参与者的概念
参与者（Actor）是指存在于 系统外部并直接与系统进行交 互的人、系统、子系统或类的 外部实体的抽象。
UML建模语言
2. 参与者的确定
在获取用例前首先要确定系统的参与者，寻找参与者可 以从以下问题入手： .系统开发出来后，使用系统主要功能的是谁？ .谁需要借助系统来完成日常的工作？ .系统需要从哪些人或其他系统中获得数据？ .系统会为哪些人或其他系统提供数据？ .系统会与哪些其他系统交互？其他系统可以分为两类， 一类是该系统要使用的系统，二是启动该系统的系统， 包括计算机系统和计算机中的其他应用软件。 .系统是由谁来维护和管理的，以保证系统处于工作状 态？ .系统控制的硬件设备有哪些？ .谁对本系统产生的结果感兴趣？
软件工程 第5章--UML
10
UML的定义
UML定义有两个主要组成部分：语义和表示法。 语义用自然语言描述，表示法定义了UML的可 视化标准表示符号，这决定了UML是一种可视 化的建模语言。 在语义上，模型是元模型的实例。UML定义给 出了语法结构的精确定义。 使用UML时，要从不同的角度观察系统，为此 定义了概念“视图(View)‖。视图是对系统的模 型在某方面的投影，注重于系统的某个方面。
独立于过程
系统建模语言，独立于开发过程。
9
容易掌握使用 概念明确，建模表示法简洁明了，图形结 构清晰，容易掌握使用。 着重学习三个方面的主要内容： (1) UML的基本模型元素 (2) 组织模型元素的规则 (3) UML语言的公共机制 与程序设计语言的关系 用Java，C++ 等编程语言可实现一个系统。 一些CASE工具可以根据 UML所建立的系 统模型来产生Java、C++ 等代码框架。
31
UML事物 — 注释事物
11) Note（注释）
依附于一个元素或一组元素之上，对其进
行约束或解释的简单符号。没有语义影响。
See policy8-5-96.doc for details about these algorithms.
CashAccount presentValue()
32
15
UML定义 9 种图，表达UML中的 5 种视图，各 视图在静态和动态方面表示系统模型。
结构 视图 静态 方面
动态 方面
行为 视图 同左
实现 视图 构件图
环境 视图 部署图
同左
用例 视图 用例图
同左
类图 对象图
顺序图 同左 顺序图 合作图 (注重 合作图 状态图 进程、 状态图 活动图 线程) 活动图
UML的定义
UML定义有两个主要组成部分：语义和表示法。 语义用自然语言描述，表示法定义了UML的可 视化标准表示符号，这决定了UML是一种可视 化的建模语言。 在语义上，模型是元模型的实例。UML定义给 出了语法结构的精确定义。 使用UML时，要从不同的角度观察系统，为此 定义了概念“视图(View)‖。视图是对系统的模 型在某方面的投影，注重于系统的某个方面。
独立于过程
系统建模语言，独立于开发过程。
9
容易掌握使用 概念明确，建模表示法简洁明了，图形结 构清晰，容易掌握使用。 着重学习三个方面的主要内容： (1) UML的基本模型元素 (2) 组织模型元素的规则 (3) UML语言的公共机制 与程序设计语言的关系 用Java，C++ 等编程语言可实现一个系统。 一些CASE工具可以根据 UML所建立的系 统模型来产生Java、C++ 等代码框架。
31
UML事物 — 注释事物
11) Note（注释）
依附于一个元素或一组元素之上，对其进
行约束或解释的简单符号。没有语义影响。
See policy8-5-96.doc for details about these algorithms.
CashAccount presentValue()
32
15
UML定义 9 种图，表达UML中的 5 种视图，各 视图在静态和动态方面表示系统模型。
结构 视图 静态 方面
动态 方面
行为 视图 同左
实现 视图 构件图
环境 视图 部署图
同左
用例 视图 用例图
同左
类图 对象图
顺序图 同左 顺序图 合作图 (注重 合作图 状态图 进程、 状态图 活动图 线程) 活动图
第05章 类图及对象图
26
实体类通过事件流和交互图发现, 实体类通过事件流和交互图发现, 采用目 事件流和交互图发现 标领域术语命名. 标领域术语命名. 通常实体类对应数据库中的表, 属性对 通常实体类对应数据库中的表, 其属性对 应表的字段 字段, 应表的字段, 但实体类与数据库中的表不一定 是一一对应关系. 是一一对应关系.
23
借书处理类图
24
通过用例图可以确定需要的边界类, 每个Actor/User 通过用例图可以确定需要的边界类, 每个Actor/User case对至少需要一个边界类 对至少需要一个边界类. case对至少需要一个边界类.
但并不是每个 case都需 Actor/Use case都需 要生成惟一边界类, 要生成惟一边界类, 多个actor actor启动同一 多个actor启动同一 case可以使用同 use case可以使用同 一边界类. 一边界类.
初始值][{特性}] [可见性]属性名[:类型][‘[ ’多重性[次序]‘]’][=初始值][{特性}] 可见性]属性名[:类型][ 多重性[次序] ][=初始值][{特性 [:类型
该属性对外部实体的显现程度. 该属性对外部实体的显现程度. 可见public : + 可见public 受限protected: 受限protected: # 私有private 私有private : -
13
？
问题： 问题：
1、指出下面属性名的含义。 、指出下面属性名的含义。
+studentName:String=“李明” 李明” 李明 #studentBirthDay:Date=1999-10-21 -price:float=12.01{R/W}
14
5.1.3 类的操作
第5章 用例图
5.3 用例（Use Case）
描述用例 8.假设[可选]：假设描述的是系统在使用用例之前必须 满足的状态，这些条件并没有经过用例的检测，用 例只是假设它们为真。 9.基本操作流程：参与者在用例中所遵循的主要逻辑 路径。操作流程描述了用户和执行用例之间交互的 每一步。 10.可选操作流程：包括用例中很少使用的逻辑路径， 那些在变更工作方式、出现异常或发生错误的情况 下所遵循的路径。 11.修改历史记录[可选]：主要记录的是关于用例的修 改时间、修改原因和修改人的详细信息。
扩展关系也是一种依赖关系。 它指定了一个用例可以增强另一个用例的功 能，通过项基本用例添加动作来扩展该用例。 一个用例被定义为基本用例的增量扩展，这 称作扩展关系。 在扩展关系中，基本用例可以是独立的。在 一定条件下，基本用例的动作可由另外一个 用例扩展而来。基本用例提供了若干“扩展 点”，扩展用例只能在这些扩展点上增加一 个或多个新的动作。也就是说，扩展用例只 能发生在基本用例序列中的某个特定的点上。
用例的表示
在UML语言中，用例用一个椭圆来表示，并
且每个用例必须有一个名字。 在用例命名时用例的名字一般用字符串来表 示，可分为简单名和路径名。其中，路径名 引入了包的概念，在用例名前加上该用例所 属包的名字，两个名字之间用两个冒号分开。
AddBook
Libraian::LoanBook
5.3 用例（Use Case）
5.3 用例（Use Case）
描述用例 5.频率：记录参与者使用该用例的频率。 6.前置条件：前置条件以一个条件列表的形式进行记 录，用来描述执行用例之前系统所必须满足的条件。 这些条件必须在使用用例之前得到满足。前置条件 在使用之前，已经由用例进行过测试。如果条件不 满足，则用例不会被执行。 7.后置条件：后置条件将在用例成功完成以后得到满 足，它提供了系统的部分描述。即在前置条件满足 后，用例做了什么？以及用例结束时，系统处于什 么状态？
uml用例图
取款
查询
持有银行信 用卡的自动 取款机用户
转账
银行客户
图 ATM用例图
图 银行客户注释图
用例图的基本概念
5.1.2 用例图的作用
用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系， 用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系， 帮助开发人员可视化地了解系统的功能。减少了大量交流上的障碍， 帮助开发人员可视化地了解系统的功能。减少了大量交流上的障碍，便于 对问题达到共识。 对问题达到共识。
用例名
2.用例的识别
可以通过以下问题来寻找用例？ 参与者希望系统提供什么功能？ 参与者希望系统提供什么功能？ 参与者是否会读取、创建、修改、删除、存储系统的某种信息？ 参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果 是的话，参与者又是如何完成这些操作的？ 是的话，参与者又是如何完成这些操作的？ 参与者是否会将外部的某些事件通知给系统？ 参与者是否会将外部的某些事件通知给系统？ 系统中发生的事件是否通知参与者？ 系统中发生的事件是否通知参与者？ 是否存在影响系统的外部事件？ 是否存在影响系统的外部事件？
基础用例
扩展用例
《 extend》
扩展关系
3.泛化
用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的 关系就是泛化关系。在UML中，用例的泛化关系通过一个从子用例指向父用例的三角箭头 来表示：
父用例
子用例
泛化关系
5.3 用例图的创建概述
5.3.1 5.3.2 5.3.3 5.3.4 创建用例图 创建参与者 创建用例 创建用例之间的关联
课程回顾
用例图的基本概念 用例图的组成 用例图的创建概述 用例图的创建示例
第5章 用例图
特定参与者希望系统提供什么功能； 系统是否存贮和检索信息，如果是，由哪个参与者触发； 当系统改变状态时，是否通知参与者； 是否存在影响系统的外部事件； 哪个参与者通知系统这些事件。
-11-
made by cnHexu
第5章 用例图
5.1.3 用例
3.用例与事件流 用例分析处于系统需求分析阶段，需要更加具体的细节， 这些细节写在事件流文件中。 事件流的目的：
第5章 用例图
5.1.2 参与者
2 .确定参与者 对参与者建模的过程中需要注意的问题
参与者对系统而言总是外部； 参与者可以直接或间接地同系统交互，或使用系统提供的服务 以完成某件事务； 参与者表示人和事物与系统交互时所扮演的角色，而不是特定 的人或特定的事物； 一个人或事物在与系统发生交互时，可以同时或不同时扮演多 个角色； 每一个参与者需要一个具有业务一样的名字； 每个参与者必须有简短的描述； 参与者可以具有表示参与者的属性和可以接受的事件。
-3-
made by cnHexu
第5章 用例图
5.1.2 参与者
1.参与者的概念 参与者是系统外部的一个实体,以某种形式参与用例的执行过程。 参与者通过向系统输入或请求系统输入某些事件来触发系统的执 行。 每个参与者可以参与一个或多个用例 表示：
人形图
-4-
made by cnHexu
2.确定参与者 如何寻找系统的参与者
谁将使用系统的主要功能； 谁将需要该系统的支持以完成其工作； 谁将需要维护、管理该系统，以保持该系统处于工作状态； 系统需要处理哪些硬件设备； 与该系统交互的是什么系统； 谁或什么系统对本系统产生的结果有兴趣。
UML规范-05 UML2表示法
控制流分叉
控制流 (控制节点) 控制流合并 (去分叉)
(控制节点)
结合(去分支)
活动结束节点
Page-41
Course code：UML-DESIGN
金陵软件教育培训学院
金陵软件教育培训学院
1.3.1 协作定义
协作的可选表示法
协作定义 协作定义
名称 类型 连接器
角色名称 角色
角色
角色
类角色类型
Page-26
Course code：UML-DESIGN
金陵软件教育培训学院
1.3.2 协作使用
参与的对象
协作使用 角色名称
协作使用的名称
协作名称
Page-27
Course code：UML-DESIGN
金陵软件教育培训学院
二、关系
依赖(Dependency):
是两个事务之间的一种语义关 系，其中一个事务（独立事务） 的改变会影响另一个事务的（依 赖事务）语义。
关联(Association):
关联是一种结构关系，它描述了 一组链，链是对象之间的链接
泛化(Generalization):
泛化是一般/特殊关系，其中特殊 元素(子类)的对象可以替换一般 元素(父类)的对象。
包Y将包Z的公有内容添加到了Y私有名称空间中
带有嵌套子包和类的包 包Z将包X的公有内容添加到了Z的名称空间中
类G是私有的，只能在包X内部访问 金陵软件教育培训学院
Page-29
Course code：UML-DESIGN
2 行为图
1. 用例图(Use case diagram)： 展示一组用例、参与者以及它们的关系。 2. 顺序图(Sequence diagram)： 展示一个交互，强调消息的时间顺序。 3. 通信图(Communication diagram)： 展示一个交互，强调收发消息的对象的组织结构。 4. 状态机图(State machine diagram)： 展示一个状态机，强调对象的由事件预定的行为。 5. 活动图(Activity diagram)： 展示一个计算过程，强调从活动到活动的流。 6. 定时图(Timing diagram)： 展示在特定时间具有消息的交互。 （未讲） 7. 交互概览图(Interaction overview diagram)： 结合了活动图和顺序图的内容。（未讲）
uml 用例分析技术
寻找用于解决某个用例的一组对象
寻找对象的准则
限制每一个分析类（analysis class）的职责 对类和方法采用一致的命名 保持分析类的简单 实体（Entity） 边界（Boundary） 控制（Control）
-35-
寻找Hale Waihona Puke 象的步骤（MVC构架）
准则1：限制职责
SRP（The Single Responsibility Principle）：就一个类而言，应该仅有 一个引起它变化的原因
-13-
分析模型与用例模型
用例：外观
类图：内部机理
-14-
如何开始？
从 用 例 开 始！
-15-
从用例开始-1
根据高层用例图和文档来确认需求定义是可靠 的、一致的
可靠的
每个用例都包含对正常事件流和异常事件流的描述 存在备选事件流、异常事件流的描述
如果在分析过程中发现一些新的用例，说明需求是不完备 的，此时应对用例进行重构 在分析过程中，还有可能精化对每一个用例的理解
-27-
经典的三层构架-1
表示层
应用逻辑层
记录销售信息
支付授权
存储层
数据库
-28-
多层体系结构的动机
将应用逻辑作为单独的构件从系统中分离出来， 以便这些构件在其他系统中能得到重用
将各个层次分配到各个不同的物理计算节点， 或者分配给不同的进程。这样可以改善系统性 能、更好地支持客户和服务器系统中的信息共 享和协调 将不同层的开发任务在开发者之间适当地分配， 这可以有效地利用开发人员的专长和开发技巧， 并且能够提高并行开发能力
第五章 用例图
泛化关系的含义是把某些参与者的共同行为提取出来表示成通用 行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊 关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。
7
用例图的构成要素
3. 系统边界
在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与 系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形 成的具有特定功能的有机整体。
和系统管理三大管理功能。 1. 项目管理包括项目的增加、删除、更新。 2. 资源管理包括对资源和技能的添加、删除
和更新。 3.系统管理包括系统的启动和关闭，数据的
存储和备份等功能。
说明：技能表示人力资源。
19
1. 分析确定系统的执行者(角色) 到确定
项目管理员、资源管理员、系统管理 员、备份数据系统。
1. 病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到 中央监护系统。
2. 中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信 号的正常值进行比较，当病症出现异常时系统自动报警。
3. 当病症信号异常时，系统自动更新病历并打印病情报告。
4. 值班护士可以查看病情报告并进行打印。
23
例2 医院病房监护系统
监视病情
产生 病情报告
经 1.过请监初对视步系病的统员需需的求求病进分症行析（分，血析得！压到、系体统温功、能脉要搏求等：） 2. 定时更新病历 3. 病员出现异常情况时报警。 4. 随机地产生某一病员的病情报告。
更新病历
24
二、简单的需求分析说明
需求分析
对“医院病房监护系统”进行分析，确定系统的主要功能如下：
第五章 用例图
1
学习内容
7
用例图的构成要素
3. 系统边界
在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与 系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形 成的具有特定功能的有机整体。
和系统管理三大管理功能。 1. 项目管理包括项目的增加、删除、更新。 2. 资源管理包括对资源和技能的添加、删除
和更新。 3.系统管理包括系统的启动和关闭，数据的
存储和备份等功能。
说明：技能表示人力资源。
19
1. 分析确定系统的执行者(角色) 到确定
项目管理员、资源管理员、系统管理 员、备份数据系统。
1. 病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到 中央监护系统。
2. 中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信 号的正常值进行比较，当病症出现异常时系统自动报警。
3. 当病症信号异常时，系统自动更新病历并打印病情报告。
4. 值班护士可以查看病情报告并进行打印。
23
例2 医院病房监护系统
监视病情
产生 病情报告
经 1.过请监初对视步系病的统员需需的求求病进分症行析（分，血析得！压到、系体统温功、能脉要搏求等：） 2. 定时更新病历 3. 病员出现异常情况时报警。 4. 随机地产生某一病员的病情报告。
更新病历
24
二、简单的需求分析说明
需求分析
对“医院病房监护系统”进行分析，确定系统的主要功能如下：
第五章 用例图
1
学习内容
UML之用例图
初学UML之-------用例图分类：UML Modeling2007-10-16 04:37 58803人阅读评论(48) 收藏举报一．UML简介UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。
它融入了软件工程领域的新思想、新方法和新技术。
它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。
其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。
二．用例建模简介用例建模是UML建模的一部分，它也是UML里最基础的部分。
用例建模的最主要功能就是用来表达系统的功能性需求或行为。
依我的理解用例建模可分为用例图和用例描述。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
用例描述用来详细描述用例图中每个用例，用文本文档来完成。
1．用例图参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。
参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
这是UML对用例的正式定义，对我们初学者可能有点难懂。
我们可以这样去理解，用例是参与者想要系统做的事情。
第5章 用例图
用例的识别
识别用例最好的方法就是从分析系统的参 与者开始，考虑每个参与者是如何使用系 统的。 如何识别用例。
用例的粒度
用例的粒度是指用例所包含的系统服务或 功能单元的多少。 用例的粒度越大，用例包含的功能就越多， 反之，则越少。 用例粒度大，用例数会少，反之，用例粒 度小，用例数会多。 用例数目过多会造成用例模型过大和引入 设计困难大大提高；用例数目过少不便于 进一步充分分析。
图5-17 扩展关系示例
扩展关系一般用来处理异常或构建灵活的系统框架。 使用扩展关系可以降低系统的复杂度，有利于系统 的扩展、提高系统的性能。 扩展关系还可用来处理基础用例中的不易描述的问 题，是系统显得清晰、易于理解。
泛化关系
用例的泛化是指一个父用例可以被特化形成多个子用例， 父用例和子用例之间的关系就是泛化。 父用例也可以被特别列举为一个或多个子用例。 子用例表示父用例的特殊形式。 子用例从父用例处继承行为和属性，还可以添加行为或覆 盖、改变继承的行为。
当系统中两个或多个用例在行为、结构和 目的方面存在共性时，就可以使用泛化关 系。
图5-19 泛化关系示例
泛化关系和包含关系都可以用来复用多个用例中 的公共行为。 泛化关系和包含关系的区别： 1、在用例的泛化关系中，所有的子用例都有相似 的目的和结构，注意它们是整体上的相似。 2、在用例的包含关系中，基础用例在目的上可以 完全不同，但是它们都有一段相似的行为，它们 的相似是部分而不是整体。用例的泛化关系类似 于面向对象中的继承，它把多个子用例中的共性 抽象成一个父用例，子用例在继承父用例的基础 上可以进行修改。但子用例之间又是相互独立的， 任何一个子用例的执行不受其他子用例的影响。 而用例的包含关系是把多个基础用例中的共性抽 象为一个被包含用例，可以说被包含用例就是基 础用例中的一部分，基础用例的执行必然引起被 包含用例的执行。
UML用例图
包含关联与扩展关联的区别： 存在包含关联的两个用例，用例必须包含被包含用例；存在 扩展关联的两个用例则有使用被扩展用例的选择权。
4、用例图示例
成绩管理系统用例图
二、如何建立用例图模型
创建用例图模型有4项任务： •找出系统中的角色和用例。 •区分用例的优先次序。 •细化每个用例。 •建立用例图模型结构。
UML的用例图标
获得产品信息
订购货物
支付货款
。。。
订货处理用例
3、用例图的关联
1）角色与用例的关联
角色与用例的关联表示角色与用例相关性。在UML中是使用 一条带箭头的实线连接角色与用例，如下图所示。
成绩管理
2）角色与角色的关联
角色与角色的关联用来表示一般角色与特殊角色的泛化关系。 在UML图中，使用带空心三角箭头的实线表示。如下图所示：
用例与用例的包含关联用来表示一个用例的行为包含了另一个用例 的行为。在UML图中，使用带虚线箭头表示，并在线上标有构造型 <<include>>。如下图所示：
成绩管理
用例与用例的扩展关联用来表示一个用例的行为扩展了另一个用例 的行为。在UML图中，使用带虚线箭头表示，并在线上标有构造型 <<extend>>。如下图所示：
例1 超市进销存系统用例图建模 1、超市进销存系统的需求描述如下： （1）销售 ①售货员接收顾客订购，输入顾客购买的商品，计算总价； ②顾客付款并接收清单； ③售货员保存顾客购买商品的记录清单。 （2）库存 ①库存管理员每天进行盘点一次； ②库存管理员当发现库存商品有损坏时，及时到相关部门报损； ③在供应商的商品到货时，库存管理员首先检查商品是否合格， 并将合格的商品入库处理；当商品进入卖场时，进行商品出库处 理； ④经理、订货员根据需要进行库存商品的模糊查询或详细查询。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
备注 UML 1原有
UML 1非正式图 UML 2.0新增 UML 1原有 UML 1原有 UML中非正式图 UML 1原有 UML 1原有 UML 1原有 UML 1原有 UML 1中的协作图
复合结构图 描述类的运行时刻的分解
定时图
描述对象之间的交互，重点在于定时
UML 2.0 新增
UML 2.0新增
5.2.3 用例图-参与者
如何确定参与者？
（1）使用系统主要功能的人是谁（即主要角色）？ （2）需要借助于系统完成日常工作的人是谁？ （3）谁来维护和管理系统（次要角色），保证系统正常工作？
（4）系统控制的硬件设备有哪些？
（5）系统需要与哪些其它系统交互？其它系统包括计算机系统，也包 括该系统将要使用的计算机中的其它应用软件。其它系统也分成二类， 一类是启动该系统的系统，另一类是该系统要使用的系统。 （6）对系统产生的结果感兴趣的人或事是哪些？
5.2.3 用例图-参与者
参与者（Actor）是指存在于系统外部并直接与系统进行交互的 人、系统、子系统或类的外部实体的抽象。 每个参与者可以参与一个或多个用例，每个用例也可以有一个或 多个参与者。 注意：参与者可以是人，也可以是外部系统或其它设备。
5.2 UML包含的内容
5.2.3 用例图 -参与者 5.2.1 参与者
• 用例图可视化地表达了系统的需求，具有直观、规范来自优点，克 服了纯文字性说明的不足。
5.2 UML包含的内容
5.2.3 用例图 2. 用例图的作用
用例图的作用
• 用例方法是完全从外部来定义系统功能，它把需求和设计完全的 分离开来。我们不用关心系统内部是如何完成各种功能的，系统 对于我们来说就是一个黑箱子。 • 用例图清楚地描述了使用者及它们之间的泛化关系，用例及用例 之间的泛化、扩展关系，用例和参与者之间的关联关系，可从用 例图中得到对于被定义系统的一个总体印象。
5.2 UML包含的内容
5.2.3 用例图
类图 类(class) 关联(association) 系统的内观(里子) 静态结构 稳定成长 用例图 用例(use case)、参与者(actor) 包含(include)、扩展(extend) 系统的外观(面子) 动态功能 变化迅速
类图与用例图
5.2 UML包含的内容
• 要在用例图上绘制一个参与者（表示一个系统用户）， 可绘制一个人形符号。
5.2 UML包含的内容
5.2.3 用例图
• 参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭 头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话 的被动接受者。如果不想强调对话中的主动与被动关系，可以使用不 带箭头的线段。
• 注意：包、注释都不是用例图的基本组成要素，但在 用例建模过程中可能会用到它们。
5.2 UML包含的内容
5.2.3 用例图
用例图的作用
• 用例图是需求分析中的产物，主要作用是描述参与者和用例之间 的关系，帮助开发人员可视化的了解系统的功能。
• 借助于用例图，系统用户、系统分析人员、系统设计人员、领域 专家能够以可视化的方式对问题进行探讨，减少了大量交流上的 障碍，便于对问题达成共识。
5.2 UML包含的内容
5.2.3 用例图
用例图主要包括3个部分：
用例（User Case） 参与者（Actor） 关系
AssociationName UseCaseName
ActorName (From Use Case View) (From Use Case View)
5.2 UML包含的内容
5.2 UML包含的内容
5.2.3 用例图
• 进行用例建模时，所需要的用例图数量是根据系统的复杂度来衡 量的。
• 对于较复杂的大中型系统，可能会需要几张甚至几十张用例图， 可以使用包来对其进行有效管理。
5.2 UML包含的内容
5.2.3 用例图
• 在用例建模中，为了更加清楚的描述用例或者参与者， 会使用到注释。
交互概观图 是一种顺序图与活动图的混合
5.2 UML包含的内容
5.2.3 用例图
用例图主要用于为系统的功能需求建模，它主要描述系统功能， 也就是从外部用户的角度观察，系统应该完成哪些功能。
用例图可以帮助开发人员以一种可视化的方式理解系统的功能 需求，是后续的系统分析与设计工作的依据。 用例图是对系统功能的一个宏观描述，画好用例图是由软件需 求到最终实现的第一步，也是最重要的一步。
信息系统分析、设计与开发方法
第5章 功能强大的对象建模 工具——UML
用例图
5.2 UML包含的内容
5.2.3 用例图
UML有三个基本构造块：事物、关系和图。
通过关系把多个事物连接在一起，构成了图。 其中，图可视化地描绘了系统某一方面的特征。一个图只能反映系 统中某个侧面和特征，多个图结合在一起可以反映系统的某些侧面 和多个特征。 在UML 2.0中共定义了13种图，比UML 1.0新增了3种。
UML2.0的图型
图名 类图
对象图 组件图 部署图 包图 用例图 活动图 状态机图 顺序图 通信图
功能 描述类、类的特性以及类之间的关系
描述一个时间点上系统中各个对象的一个快照 描述组件的结构与连接 描述在各个节点上的部署 描述编译时的层次结构 描述用户与系统如何交互 描述过程行为与并行行为 描述事件如何改变对象生命周期 描述对象之间的交互，重点在强调顺序 描述对象之间的交互，重点在于连接
5.2.3 用例图 • 由参与者（Actor）、用例（Use Case）以及 它们之间的关系构成的用于描述系统功能的动 态视图称为用例图。
• 用例和参与者之间的对应关系叫做通信关联， 它表示参与者使用了系统中的哪些用例。
5.2 UML包含的内容
5.2.3 用例图
• 要在用例图上显示某个用例，可绘制一个椭圆，然后 将用例的名称放在椭圆的中心或椭圆下面的中间位置。
• 参与者有三大类：
– 第一类参与者是真实的人，即用户，是最常见的参与者，几 乎存在于每一个系统中。
– 第二类参与者是其他的系统。这类位于程序边界之外的系统 也是参与者。
– 第三类参与者是一些可以运行的进程。如时间，当经过一定 的时间触发系统中的某个事件时，时间就成了参与者。
5.2 UML包含的内容