用例和用例图
参与者(Actor)
用例(Use Case)
4.3.2
关系 参与者 与用例 之间的 关系
用例图中的关系
解释 图
关联
表示参与者与用例之间的交互，通信途径。 (关联有时候也用带箭头的实线来表示，这样 的表示能够显示地表明发起用例的是参与 者。) 箭头指向的用例为被包含的用例，称为包含 用例；箭头出发的用例为基用例。包含用例 是必选的，如果缺少包含用例，基用例就不 完整；包含用例必须被执行，不需要满足某 种条件；其执行并不会改变基用例的行为。 箭头指向的用例为被扩展的用例，称为扩展 用例；箭头出发的用例为基用例。扩展用例 是可选的，如果缺少扩展用例，不会影响到 基用例的完整性；扩展用例在一定条件下才 会执行，并且其执行会改变基用例的行为。 发出箭头的事物“is a”箭头指向的事物。泛 化关系是一般和特殊关系，发出箭头的一方 代表特殊的一方，箭头指向的一方代表一般 一方。特殊一方继承了一般方的特性并增加 了新的特性。 《include》
4.3.1 用例图中的事物
事物名称 解释 在系统外部与系统直接交互的人或事物(如另一 个计算 机系统或一些可运行的进程)。我们需要注意的 是： 1.参与者是角色而不是具体的人，它代表了参与 者在与系统打交道的过程中所扮演的角色。所 以在系统的实际运作中，一个实际用户可能对 应系统的多个参与者。不同的用户也可以只对 应于一个参与者，从而代表同一参与者的不同 实例。 2.参与者作为外部用户(而不是内部)与系统发生 交互作用，是它的主要特征。 3.在后面的顺序图等中出现的“参与者”，与此 概念相同，但具体指代的含义，视具体情况而 定。 系统外部可见的一个系统功能单元。系统的功能 由系统单元所提供，并通过一系列系统单元与一 个或多个参与者之间交换的消息所表达 。创建 新用例，确认候选用例和划分用例范围的优秀法 则----“WAVE”测试(见附录) UML表示
实例2 用例之间扩展和包含关系
• 用例的上下文是：短途旅行但汽车的油不足以应付全部路 程。那么为汽车加油的动作在旅行的每个场景(事件流)中 都会出现，不加油就不会完成旅行。吃饭则可以由司机决 定是否进行，不吃饭不会影响旅行的完成。
实例3. 航空售票的用例图
参与者(actor)：clerk，监督员，信用卡 服务商，信息亭 用例(use case)： Buy tickets， Buy Subscription， Make charges， Survey sales 参与者Clerk参与(或称发起)Buy tickets 和Buy Subscription 两个用例(关联关系)。 这两个用例的事件流都包含Make charges用例(包含关系)。
<<include>>
查询图书
还书 借阅者
<<extend>>
交罚款
4.2.3 扩展关系
• 扩展（extend） （是一种依赖关系，加了版型<<extend>>）
– 一个用例在某些扩展点上扩展另一个用例的功能，构 成新用例；箭头方向由扩展用例指向被扩展用例（即 基本用例）； – 扩展用例依赖于被扩展用例（基本用例），只是部分 片段组成，不是完整的独立用例，无法单独执行； – 扩展用例不一定每次都被执行和调用。（吃饭前也可 以不洗手），而被包含用例每次必修执行。 – 肯定没有活动者指向扩展用例，因为扩展用例依赖基 本用例。
4.1.1 用例
• 例如，在图书管理系统中，用户可以进行“查询图书的基 本信息”，“借书”以及“还书”，管理员可以对图书的 基本信息进行管理，如“新增图书信息”、“修改图书信 息”，“删除图书”等等操作。即这些操作都是系统提供 的服务（功能），因此，这些都可以独立成为一个用例。 执行这些操作的都是人（即参与者）。 • 用例在UML中通常用一个椭圆图形符号来表示。如图4.4 所示。
用例 1
图4.4 用例符号
4.1.1 用例
• 例如，在文字处理程序中，“置正文的字体为宋体”是一 个用例，在图书管理系统中“新增图书信息”、“借书” 和“还书”也是用例，在超市管理系统中的“进货”也是 一个用例，如图4.5所示。在这里可以看出，用例可大可 小，有的用例可能比较简单，而有的可能就很复杂，如 “置正文的字体为宋体”这个用例就比较简单，很容易实 现，但是对于“进货”和“借书”这样的用例相对就比较 复杂，可能需要花一些时间才能够实现。
包含 用例之 间的关 系 扩展
《extend》
参与者 之间的 关系
泛化
பைடு நூலகம்
4.3.3 用例图的例子
• 实例1 参与者之间的泛化关系 • 参与者：经理，安全主管，保安 • 用例：管理人事，批准预算，批准安 全证书，监视周边 • 在参与者之间不存在泛化关系的情况 下，各个参与者参与用例的情况分别是： 经理参与用例管理人事和批准预算；安全 主管参与用例批准安全证书；保安参与用 例监视周边。由于安全主管与经理，安全 主管与保安之间泛化关系的存在，意味着 安全主管可以担任经理和保安的角色，就 能够参与经理和保安参与的用例。这样， 安全主管就可以参与全部4个用例。但经理 或者保安却不能担任安全主管的角色，也 就不能参与用例批准安全证书。
置正文的字体为宋体 借 书 还 书
图4.5 用例
4.1.1 用例
• 怎样确定用例的粒度？（用例规模的大小）
– 用例的粒度可大可小，一般一个系统控制在20 个左右，但没有严格规定 – 用例是系统级的、抽象的描述，不是细化的 （考虑的是“做什么what”，而不是“怎样做 how”） – 对复杂的系统可以划分为若干子系统处理
• 包含（include） （是一种依赖关系，加了版型<<include>>） – 包含关系指的是两个用例之间的关系，其中一个用例 （称为基本用例）的行为包含了另一个用例（称为包含 用例）的行为。也就是说基本用例会用到包含用例。 – 在UML图中，使用带虚线箭头表示，并在线上标有 <<include>>。 箭头方向由基本用例指向被包含用例； – 执行基本用例时，每次都必须调用被包含的用例（吃饭 前洗手）； – 被包含用例也可以单独执行；
精确查找 查找图书 借阅者 模糊查找
4.3 用例图
• 用例图是被称为参与者的外部用户所能观察到的系统功能 的模型图。 • 用例图列出系统的用例和系统外的用例，并显示哪个参与 者参与了哪个用例的执行（或称为发起了哪个用例）。 • 用例图多用于静态建模阶段(主要是业务建模和需求建模)。 • 显示系统和外部实体（Actor）交互的图
第4 章
用例和用例图
4.1 用例图的组成
• 用例（use case） • 参与者（活动者，角色，actor） • 关系（relationship）
• 还可以有包、注解等
4.1.1 用例
• Use Case – 系统、子系统或类与外部参与者（actor）交互的动作 序列的说明，包括各种序列及出错序列。 – 简单理解为用例就是系统的功能。 – 用例分析可以认为是对系统功能的分解。 • 用例是代表系统中各个项目相关人员之间根据系统的行为 所达成的契约。用例描述了在不同条件下，针对某一项目 相关人员的请求，系统对其作出的响应。也就是说用例指 的是对一组动作的描述，系统通过执行这些动作将对用例 的参与者产生可以看到的结果。用来描述参与者可以感受 到的系统服务或功能。
4.1.1 用例
• 怎样识别用例 – 参与者需要从系统中获得什么功能？参与者需要做什 么？ – 参与者读取、产生、删除、修改或存储系统的哪些信 息？ – 需要将系统的哪个事件告诉参与者？ – 需要将外界的哪些信息提供给系统？（输入、输出信 息） – 采用什么实现方法满足特殊要求？
图书管理系统的用例图
4.1.2 参与者
• Actor
– 系统外部的参与者，可以是用户、外部硬件、 其他系统。
4.1.2 参与者
• 【例4-1】客户给销售员发来传真订货， 销售员 下班前将当日订货单汇总输入系统。谁是系统的 参与者？ • 分析：根据参与者的定义可知，此系统的参与者 是销售员。
4.1.2 参与者
• 【例4-2】在需求分析中常见的权限控制问题，一 般的用户只可以使用一些常规的操作，如查询等， 而管理员除了常规操作之外还需要进行一些系统 管理工作，如一些关键数据的增加、删除、修改 等，操作员既可以进行常规操作又可以进行一些 配置操作。
4.1.2 参与者
• 参与者（也称为角色或活动者，Actor）是系统外部的一个 人或者物，它以某种方式参与了系统的执行过程。参与者 不是特指人，是指系统以外的，在使用系统或与系统交互 中所扮演的角色。因此参与者可以是人，可以是事物，也 可以是时间或其他系统等等。还需要注意的是，参与者不 是指人或事物本身，而是表示人或事物在系统中所扮演的 角色。 • 例如，张明是图书馆的管理员，他参与图书管理系统的交互， 这时他既可以作为管理员这个角色参与管理，也可以作为借 书者向图书馆借书，在这里张明扮演了两个角色，是两个不 同的参与者，即管理员和借阅者。 • 因此，在“图书管理系统”中“借阅者”和“系统管理员” 都是参与者。
4.2.2 包含关系
4.2.2 包含关系
• 包含关系示例
删除图书
<<include>>
查询图书
<<include>>
图书管理员
修改图书信息
4.2.2 包含关系
• 包含（include） – 一个用例功能过多，可分解成小用例，构成包含依赖 – 本例中，被包含用例不能单独执行，没有Actor直接指向 它们
4.1.2 参与者
• 理解
– Actor不是指人，而是指代表某一种特定功能 的角色，因此同一个人可能对应很多个Actor。 Actor也可以指外部系统和设备。 – 如果一个活动者的操作是由另外一个活动者代 理完成的，可以建立该活动者到另外活动者的 依赖（或关联）关系。
合集下载
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、系统通过库存系统验证要购买的商品是否有足
需求分析-用例图-用例规约
用例名:帖子管理 相关需求:版主对相应版块的帖子进行管理 参与者:版主 前置信息:版主登陆管理系统，进行相应操作 后置信息:相应版块下的帖子更新 主成功场景下的事件流: →1.版主登陆管理系统 ←2.系统跳转到管理界面 →3.版主删除相应版块帖子，或在相应版块设置或撤销热帖，或在相应版块发布公告 ←4.服务器响应操作，更新当前版块内容 扩展事件流: →3a.版主设置新热帖时热帖数量达到上限
2a.1 游客重新注册 2b.游客输入密码过短
2b.1 游客重新注册
用例名:登陆 参与者:普通用户 事件流: 1.用户访问论坛首页，选择登陆按钮，进入登陆界面 2.用户输入用户名、密码，完成登陆 可选路径: 2a.用户输入用户名或密码错误
2a.1 系统提示出错，并要求用户重新输入用户名及密码
用例名:个人资料管理 参与者:普通用户 事件流: 1.用户登陆并进入个人中心
3a.1 系统提示待添加用户与已有用户重复 3b.相应版块版主设置数量达到上限
3b.1 系统提示该版块版主数量设置达到上限
用例名:报表管理 参与者:管理员 事件流: 1.管理员登陆管理系统 2.管理员查看报表，或打印报表
用例图
用例规约
用例名:浏览帖子 相关需求:选择相应版块、浏览帖子 参与者:游客、用户 前置信息:游客访问论坛首页并选择相应版块 后置信息:显示当前帖子 主成功场景的事件流: →1.用户访问论坛首页，选择版块 ←2.服务器响应点击事件，跳转页面 →3.用户浏览版块下的帖子
←3a.1 系统提示错误 →3a.2 游客重新输入注册信息 →3b.游客填写的密码过短 ←3b.1 系统提示错误 →3b.2 游客重新输入注册信息
用例名:登陆 相关需求:用户登陆论坛 参与者:用户 前置信息:用户点击登陆按钮进入登陆界面，输入用户名和密码 后置信息:登陆成功进入论坛 主成功场景的事件流: →1.用户点击登陆按钮 ←2.服务器响应点击事件，跳转到登陆界面 →3.用户输入用户名和密码 ←4.登陆成功，用户进入论坛页面 扩展事件流: →3a.用户输入错误的用户名或密码
2a.1 游客重新注册 2b.游客输入密码过短
2b.1 游客重新注册
用例名:登陆 参与者:普通用户 事件流: 1.用户访问论坛首页，选择登陆按钮，进入登陆界面 2.用户输入用户名、密码，完成登陆 可选路径: 2a.用户输入用户名或密码错误
2a.1 系统提示出错，并要求用户重新输入用户名及密码
用例名:个人资料管理 参与者:普通用户 事件流: 1.用户登陆并进入个人中心
3a.1 系统提示待添加用户与已有用户重复 3b.相应版块版主设置数量达到上限
3b.1 系统提示该版块版主数量设置达到上限
用例名:报表管理 参与者:管理员 事件流: 1.管理员登陆管理系统 2.管理员查看报表，或打印报表
用例图
用例规约
用例名:浏览帖子 相关需求:选择相应版块、浏览帖子 参与者:游客、用户 前置信息:游客访问论坛首页并选择相应版块 后置信息:显示当前帖子 主成功场景的事件流: →1.用户访问论坛首页，选择版块 ←2.服务器响应点击事件，跳转页面 →3.用户浏览版块下的帖子
←3a.1 系统提示错误 →3a.2 游客重新输入注册信息 →3b.游客填写的密码过短 ←3b.1 系统提示错误 →3b.2 游客重新输入注册信息
用例名:登陆 相关需求:用户登陆论坛 参与者:用户 前置信息:用户点击登陆按钮进入登陆界面，输入用户名和密码 后置信息:登陆成功进入论坛 主成功场景的事件流: →1.用户点击登陆按钮 ←2.服务器响应点击事件，跳转到登陆界面 →3.用户输入用户名和密码 ←4.登陆成功，用户进入论坛页面 扩展事件流: →3a.用户输入错误的用户名或密码
用例及用例图案例
第3章
用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统（或工作内容） – 帮助业务过程重建工程工作 – 帮助员工（小组内成员）充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例：预订变更 ●参与者：柜台工作人员 ●说明：
Ａ２：有冲突。
⑧系统添加新课程，并提示添加成功。
⑨系统回到管理主界面，显示所有课程，用例结束。
14
● ⑦ 对异常流程确定单独用例。 ⑧ 优化用例图，解决用例之间的冲突和重复。
15
案例3：
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的 功能。
第3章 用例和用例图
● 3.4 用例图 3.4.1 用例图的作用 3.4.2 用例图的形式
● 3.5 用例描述 ● 3.6 用例分析 ● 3.7 业务用例图
● —— 重要知识点
26
本章作业
(1) 什么叫用例？ (2) 用例图在软件建模中的作用是什么？ (3) 用例之间存在那几种关系？ (4) 包含关系和扩展关系有什么区别? (5) 参与者可以是那几种形式？ (6) 什么叫事件流,作用是什么？
用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统（或工作内容） – 帮助业务过程重建工程工作 – 帮助员工（小组内成员）充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例：预订变更 ●参与者：柜台工作人员 ●说明：
Ａ２：有冲突。
⑧系统添加新课程，并提示添加成功。
⑨系统回到管理主界面，显示所有课程，用例结束。
14
● ⑦ 对异常流程确定单独用例。 ⑧ 优化用例图，解决用例之间的冲突和重复。
15
案例3：
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的 功能。
第3章 用例和用例图
● 3.4 用例图 3.4.1 用例图的作用 3.4.2 用例图的形式
● 3.5 用例描述 ● 3.6 用例分析 ● 3.7 业务用例图
● —— 重要知识点
26
本章作业
(1) 什么叫用例？ (2) 用例图在软件建模中的作用是什么？ (3) 用例之间存在那几种关系？ (4) 包含关系和扩展关系有什么区别? (5) 参与者可以是那几种形式？ (6) 什么叫事件流,作用是什么？
13种uml简介、工具及示例
13种uml简介、工具及示例UML（Unified Modeling Language）是一种用于软件开发的标准化建模语言，它使用图形表示法来描述软件系统的不同方面。
在软件开发过程中，使用UML可以帮助开发人员更清晰地理解系统的结构和行为，从而更好地进行设计和实现。
UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式，其中每种模型都有各自的符号和语法规则。
通过使用这些模型，开发人员可以将系统分解成不同的部分，然后逐步细化这些部分的设计，以便更好地组织和管理项目。
在UML中，最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。
每种图表都有其特定的用途和表达能力，开发人员可以根据实际需要选择合适的图表进行建模。
除了建模元素外，UML还定义了一系列的建模工具，这些工具可以帮助开发人员更高效地进行建模和分析。
其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。
下面将对13种UML简介、工具及示例进行详细介绍：1. 用例图（Use Case Diagram）用例图是UML中描述系统功能和用户交互的基本图表之一。
它用椭圆表示用例，用直线连接用例和参与者，展示了系统外部用户和系统之间的交互。
用例图可以帮助开发人员更清晰地理解系统的功能需求，从而指导系统的设计和实现。
示例：一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等，以及参与者“顾客”和“管理员”。
2. 类图（Class Diagram）类图是UML中描述系统结构和静态关系的基本图表之一。
它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。
类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。
示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。
用例和用例图.
2.确定系统的参与者
根据图书馆管理系统的需求分析，可以确定如下几点： （1）作为一个图书馆管理系统，首先需要借阅者的参与，借阅 者可以登录系统查询所需要的书籍，查到所需书籍后可以考 虑预订，当然最重要的是借书、还书操作。 （2）对于系统来说，借阅者发起的借书、还书等操作最终还需 要图书馆管理员来处理，他们还可以负责图书的预订取消。 （3）对于图书馆管理系统来说，系统的维护操作也是相当重要 的，维护操作主要包括增加书目、删除或更新书目、增加书 籍、减少书籍等操作。 系统的参与者主要有：借阅者、图书馆管理员、图书馆管理 系统维护者。
怎样识别参与者
谁向系统提供信息？ 谁从系统获取（使用）信息？
谁管理这个系统？
谁维护这个系统？ 系统要使用哪些外部资源？（系统启动打印机、扫描仪）
系统是否和已经存在的系统交互？（跨行转账的外部银行
系统、时间到了定时启动系统某功能）
查找参与者时请注意，参与者一定是直接并且主动的 向系统发出动作并获得反馈的，否则就不是参与者。 下面对机票预订系统进行分情况讨论： 情况一：机票购买者通过登录网站购买机票，那么谁 是参与者？
用例和用例图
用例建模是UML建模的一部分，它也是UML里最基 础的部分； 用例建模的最主要功能就是用来表达系统的功能性需 求或行为； 用例建模可分为用例图和用例描述； 用例图是由软件需求分析到最终实现的第一步，它描 述人们如何使用一个系统，是外部参与者所能观察到 的系统功能的模型图，该图呈现了一些参与者和一些 用例，以及它们之间的关系，主要用于对系统、子系 统或类的功能行为进行建模，用画图的方法来完成； 用例描述用来详细描述用例图中每个用例，用文本文 档来完成。
（3）系统管理员进行系统维护的用例 ① 查询借阅者信息； ② 查询书籍信息； ③ 增加书目； ④ 删除或更新书目； ⑤ 增加书籍； ⑥ 删除书籍； ⑦ 添加借阅者账户； ⑧ 删除或更新借阅者账户。
第2章用例和用例图
成绩管理
UML用例图组成( UML用例图组成(续) 用例图组成
饮料销售机
UML用例图组成( UML用例图组成(续) 用例图组成
用例与用例的扩展关联用来表示通过对已有用例增加步 用例与用例的扩展关联用来表示通过对已有用例增加步 扩展关联用来表示 骤创建一个新的用例,即对原有的用例进行了扩展。 骤创建一个新的用例 即对原有的用例进行了扩展。扩展只能 即对原有的用例进行了扩展 发生在基用例的序列中的某个具体指定点上。这个点叫做扩 发生在基用例的序列中的某个具体指定点上。 展点.在UML图中，使用带虚线箭头表示，并在线上标有构造 展点 在UML图中，使用带虚线箭头表示， 图中 带虚线箭头表示 如下图所示： 型<<extend>> 。如下图所示：
UML用例图组成( UML用例图组成(续) 用例图组成
包含关联与扩展关联的区别： 包含关联与扩展关联的区别：
存在包含关联的两个用例,在执行基本用例时 一定会执 存在包含关联的两个用例 在执行基本用例时,一定会执 在执行基本用例时 行包含用例；存在扩展关联的两个用例,在执行基本用例时 在执行基本用例时, 行包含用例；存在扩展关联的两个用例 在执行基本用例时 可以执行,也可以不执行扩展部分 可以执行 也可以不执行扩展部分. 也可以不执行扩展部分
UML用例图的作用( UML用例图的作用(续) 用例图的作用
• 用例图的主要作用： 用例图的主要作用：
– 用来描述待开发系统的功能需求和系统使用场景 – 作为开发过程的基础，驱动各阶段的开发工作 作为开发过程的基础， – 用于验证与确认系统需求
画好用例图是由软件需求到最终实现的第一步. 画好用例图是由软件需求到最终实现的第一步.
UML用例图的建模( UML用例图的建模(续) 用例图的建模
用例和用例图解读
怎样识别用例
参与者希望系统执行什么任务？ 参与者在系统中访问哪些信息？（创建、存储、修改、删
除等） 需要将外界的哪些信息提供给系统？ 需要将系统的哪个事件告诉参与者？ 如何维护系统？
如何判断一个用例是否是一个优秀的用例呢？ ① 用例是否描述了应该做什么，而不是如何做？ ② 用例的描述是否采取了参与者的视点？ ③ 用例是否对参与者有价值？ ④ 用例描述的时间流是否是一个完整场景？ ⑤ 是否所有的参与者、用例都有相应的关联用例或关 联参与者？
Icon形式
Label形式
Decoration形式
由于Actor实际上是一个类, 因此它们之间可以存在 一定的关系,参与者之间的关系一般表现为特殊/一 般化关系，即，泛化关系。
思考： 1、这样一个需求：每天自动统计网页访问量，
生成统计报表，并发送至管理员信箱。这个
需求的参与者是谁？ 2、自动售货机的参与者是谁？
用例和用例图
用例建模是UML建模的一部分，它也是UML里最基 础的部分； 用例建模的最主要功能就是用来表达系统的功能性需 求或行为； 用例建模可分为用例图和用例描述； 用例图是由软件需求分析到最终实现的第一步，它描 述人们如何使用一个系统，是外部参与者所能观察到 的系统功能的模型图，该图呈现了一些参与者和一些 用例，以及它们之间的关系，主要用于对系统、子系 统或类的功能行为进行建模，用画图的方法来完成； 用例描述用来详细描述用例图中每个用例，用文本文 档来完成。
怎样识别参与者
谁向系统提供信息？ 谁从系统获取（使用）信息？
谁管理这个系统？
谁维护这个系统？ 系统要使用哪些外部资源？（系统启动打印机、扫描仪）
系统是否和已经存在的系统交互？（跨行转账的外部银行
用例和用例图
访客用例图
会员用例图
书店管理员用例图
3、用例描述 （1）细化用例描述----搭框架
用例名称：搜索图书 概述：用户根据关键字搜索图书 前置条件：无 事件流： 基本事件流 扩展事件流 后置条件: 无
3、用例描述 （2）细化用例描述----填＂血肉＂
事件流： •基本事件流 1 用户点击“搜索图书”，用例开始。 2 系统显示搜索图书商品界面，提示用户输入商品关键字。 3 用户输入图书关键字，选择提交。 4 系统访问数据库，根据关键字查询相关的图书商品信息， 并把查询出的图书信息显示搜索图书页面。 5 用例结束。 •扩展事件流 4a) 系统未查出所要商品相关信息，显示提示信息，用例 结束。 4b) 系统查出用户输入的关键字为空，显示提示信息并返 回基本事件流2。
编写用例描述应遵循以下几点：
使用简单的语法，主语明确，语义易于理解；在事件流描 述中让读者直观地了解是参与者在控制还是系统在控制； 从第三者观察的角度指出参与者的动作，以及系统的响应； 显示参与者的意图而非动作 显示过程向前推移，每一步都有前进感；
构建结构良好的用例
为系统和部分系统中单个的、可标识的、合理的原子行为 命名。 将多个用例的公共的行为抽取出来放到一个被包含用例中。 对于变化部分，将其抽取出来，放到扩展用例中。 清晰的描述事件流。
扩展关系（Extend）
扩展关系表示基本用例在由扩展用例间接说明的一个位置 上隐式的合并了另一个用例（扩展用例）的行为。 基本用例不知道扩展用例的任何细节，没有扩展用例，基 本用例是完整的。只有在特定条件下，它的行为可以被扩 展用例的行为扩展，因此扩展关系处理事件流的异常或者 可选事件。
第5讲2-用例及用例图
取款 用例旳动态事件流
a 经过读卡机，储户插入ATM卡
b ATM系统从卡上读取银行ID、帐号、并验证帐号。 c 储户键入密码，系统检验密码。 d 储户按确认键，输入取款金额。 e ATM把帐号和取款金额传递给银行系统，取回帐户余额。 f ATM输出现金，并显示帐户余额。 d ATM统计事务到日志文件。
参加者
1. 参加者旳概念 参加者（actor）是外部需要与系统交互旳事物。
也被称为活动者。 2.参加者旳三种类型
①. 人：客户，读者，库管员 ②. 设备：计算机，磁盘，读卡机等 ③. 外部系统：上层系统等
参加者旳表达
参加者能够表达为下面三种形式。
参加者之间旳关系
参加者之间能够有泛化关系。
用例之间旳关系(1)
用例之间能够具有下列几种关系：
➢ 泛化关系 ➢ 包括关系 ➢ 扩展关系
参加者与用例之间旳关系
关联关系 参加者与用例之间是关联关系，表达参加者与用
例之间具有使用，交互信息旳关联。
用例之间旳关系(3)
泛化关系 参加者与参加者之间，用例与用例之间存在一般与 特殊旳关系。
用例之间旳关系(4)
包括关系 两个用例之间，一种用例(基本用例)旳行为包括了 另外一种用例(包括用例)旳行为。 包括关系用依赖关系旳<<include>>构造型来表 达。
某学校网上选课系统旳用例分析(1)
管理员经过系统管理界面进入系统，建立本学期 要开设旳多种课程，将课程信息保存到数据库中， 并能够对课程进行改动和删除。 学生经过客户机浏览器进入系统，选择课程：能够 查询课程，选择课程，支付课程费用。
某学校网上选课系统旳用例分析(2)
●找出系统外部参加者，拟定系统边界和范围。
a 经过读卡机，储户插入ATM卡
b ATM系统从卡上读取银行ID、帐号、并验证帐号。 c 储户键入密码，系统检验密码。 d 储户按确认键，输入取款金额。 e ATM把帐号和取款金额传递给银行系统，取回帐户余额。 f ATM输出现金，并显示帐户余额。 d ATM统计事务到日志文件。
参加者
1. 参加者旳概念 参加者（actor）是外部需要与系统交互旳事物。
也被称为活动者。 2.参加者旳三种类型
①. 人：客户，读者，库管员 ②. 设备：计算机，磁盘，读卡机等 ③. 外部系统：上层系统等
参加者旳表达
参加者能够表达为下面三种形式。
参加者之间旳关系
参加者之间能够有泛化关系。
用例之间旳关系(1)
用例之间能够具有下列几种关系：
➢ 泛化关系 ➢ 包括关系 ➢ 扩展关系
参加者与用例之间旳关系
关联关系 参加者与用例之间是关联关系，表达参加者与用
例之间具有使用，交互信息旳关联。
用例之间旳关系(3)
泛化关系 参加者与参加者之间，用例与用例之间存在一般与 特殊旳关系。
用例之间旳关系(4)
包括关系 两个用例之间，一种用例(基本用例)旳行为包括了 另外一种用例(包括用例)旳行为。 包括关系用依赖关系旳<<include>>构造型来表 达。
某学校网上选课系统旳用例分析(1)
管理员经过系统管理界面进入系统，建立本学期 要开设旳多种课程，将课程信息保存到数据库中， 并能够对课程进行改动和删除。 学生经过客户机浏览器进入系统，选择课程：能够 查询课程，选择课程，支付课程费用。
某学校网上选课系统旳用例分析(2)
●找出系统外部参加者，拟定系统边界和范围。
第03章 用例和用例图
前置条件
后置条件
一个条件列表, 这些条件必须在访问用例前得到满足
一个条件列表, 这些条件必须在用例完成之后得到满足
基本操作流程 描述用例中各项工作都顺利进行时用例的工作方式
可选操作流程 描述变异工作方式、出现异常或发生错误的情况下的路径
20 面向对象分析与设计 & UML
3.6 用例的描述
用例的描述格式(续表)
14 面向对象分析与设计 & UML
3.4.4 几种关系的比较
关系类型 关联 泛化 包含 扩展 说明 actor与use case之间 actor之间或use case之间 use case之间 use case之间 表示符号
15
面向对象分析与设计 & UML
3.5 用例图
用例图(use case diagram)是显示一组用例、参与者以及 它们之间的关系的图.
26
面向对象分析与设计 & UML
3.8 常见问题分析
(1) 用例的粒度问题
对于一个目标系统进行用例分析后得到的用 例数目有多少比较合适?
27
面向对象分析与设计 & UML
3.8 常见问题分析
(2) 用例的分解/合并 系统中相似的功能, 是合并为一个用例还是 分解为几个用例?
方法1 一中指贯穿用例的一条单一路径, 用 来显示用例中的某种特殊情况. 其它译名: 情景、场景、情节、剧本. 每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
例：在“订货”用例中包括几个相关脚本： • 订货顺利进行的脚本; • 相关货源不足时的脚本; • 购货者的信用卡被拒绝时的脚本; • ……