当前位置：文档之家 › 第3章 用例图

第3章 用例图

  • 格式：ppt
  • 大小：1.66 MB
  • 文档页数：55

下载文档原格式

  / 55

合集下载

第3章 Rational Rose概述

第3章 Rational Rose概述

2015-3-22 西安财经学院管理学院
Rational Rose窗口介绍
浏览器中包含四个视图： • Use Case视图 • Logical视图 • Component视图 • Deployment视图
•
•
Rose浏览器的功能非常强大，并且易于操作，具有 很强的拖放功能，可以自动地更新模型中的元素等。
2015-3-22
西安财经学院管理学院
Rose模型视图
• Logical视图关注的是系统的逻辑结构。在Logical 视图中，要标识系统中的构件，检查系统信息和功 能，检查组件之间的关系。重复使用是一个主要目 的。通过认真指定类的信息和行为、组合类，以及 检查类和包之间的关系，就可以确定重复使用的类 和包。完成多个项目后，就可以将新类和包加进重 复使用库中。
2015-3-22
西安财经学院管理学院
Rational Rose窗口介绍
5 框图窗口
• 框图窗口是Rose的主要编辑窗口，可以在框图窗 口中浏览模型中的一个或者几个UML框图。如果改 变框图中的元素中，Rose自动更新浏览器中对应的 内容。同样，如果在浏览器中改变元素时，Rose自 动更新相应框图。这样Rose就可以保证模型的一致 性。
Rational Rose窗口介绍
2 浏览器
浏览器功能如下： 浏览器采用的是树形结构， • 增加模型元素 如下图所示，用于在Rose • 浏览现有模型元素间的关 模型中迅速漫游。浏览器 系 • 移动模型元素 中显示了模型中的所有角 • 更名模型元素 色、使用案例、类、组件 • 将模型元素加进框图 等。 • 将文件或URL链接到元素 • 将元素组成包 • 访问元素的详细规范 • 打开框图
用于查看错误和报告各个命令的结果西安财经学院管理学院2016228绘制类图右键单击类图从弹出的菜单中选择openspecificatio双击要设定的属性从type下拉框中选择数据类型在exportcontrol分组框中选择可见性类型西安财经学院管理学院2016228右键单击类图从弹出的菜单中选择openspecification双击要设定的属性从return下拉框中选择数据类型在exportcontrol分组框中选择可见性类型西安财经学院管理学院2016228绘制类图时的良好习惯属性和操作的文档说明在设定它们的值类型的窗体中西安财经学院管理学院2016228西安财经学院管理学院2016228绘制关系系统之间的类是有关联的在uml中可以用关系来描述类之间的关系类之间的关系主要有以下五种
软件工程PPT课件第3章 软件需求分析

软件工程PPT课件第3章 软件需求分析


–多个来回
6
软件需求分析的通信途径
7
分析建模
结构化分析模型 面向对象分析模型 分析模型描述工具

DFD、DD和PSPEC（加工规约）
CFD、CSPEC（控制规约）和STD E-R图 用例图，对象-关系图，对象-行为图
8
结构化分析模型
数据对象 说明 E-R图 加工说明 DFD图
44
数据流图
数据流图(DFD)是一种图形化技术，它描绘信息
流和数据从输入移动到输出的过程中所经受的变换 。 在数据流图中没有任何具体的物理部件，它只是 描绘数据在软件中流动和被处理的逻辑过程。 数据流图是系统逻辑功能的图形表示，即使不是 专业的计算机技术人员也容易理解它，因此是分析 员与用户之间极好的通信工具。 此外，设计数据流图时只需考虑系统必须完成的 基本逻辑功能，完全不需要考虑怎样具体地实现这 些功能。
2
需求分析的结构化分析方法准则
(1) 必须理解并描述问题的信息域，根 据这条准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条 准则要求建立功能模型。 (3) 必须描述作为外部事件结果的软件 行为，这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模 型进行分解，用层次的方式展示细节。
40
分析模型的元素
数据字典(DD)：模型核心(中心库) E-R图(ERD)： 数据流图(DFD)
指明数据在系统中移动时如何被变换; 描述对数据流进行变换的功能;
DFD中每个功能的描述包含在加工规约 (小说明)。
状态变迁图(STD)
指明作为外部事件的结果,系统将如何 动作。
41
3.4.2 数据建模
4
需求分析的任务和步骤
第三章 初识UML-UML面向对象分析、建模与设计-吕云翔-清华大学出版社

第三章 初识UML-UML面向对象分析、建模与设计-吕云翔-清华大学出版社


行为图
状态图
活动图
顺序图
协作图
用例图
UML 2中的图
UML图
结构图
类图
组件图
对象图
外廓图
组合结构 图
部署图
包图
顺序图
行为图
用例图
活动图
状态机图
交互图
通信图
交互概览 图
时间图
UML 1.4与UML 2中不同图的对比
UML 1.4
状态图 活动图
UML 2 包图 状态机图 活动图
对比说明
尽管UML 1.4使用包图说明规范的组织结构，但是没有对包图进行明确 定义。
例如，在一个类的符号中暗示了一种规格说明：它提供类所有的属性、 操作等信息的全面描述。
修饰
修饰是对规格说明的文字的或图形的表示。
例如，通过对类名添加斜体修饰来表明这是一个抽象类。
在UML中的每个元素符号都以一个基本的符号开始，在其上添加一 些具有独特性的修饰。
例如，这里有一个类，我们可以通过不同的修饰来标示出它是一个抽象 类，拥有两个公有性的操作，一个保护性的操作和一个私有性的操作。
通用划分
在面向对象系统建模中，通常有几种划分方法，其中最常见的有两 种划分：
类型-实例：是通用描述与某个特定元素的对应。
➢例如，类和对象就是一种典型的类型-实例划分。
接口-实现：接口是一个系统或对象的行为规范，这种规范预先告知使 用者或外部的其它对象这个系统或对象的某项能力，和其提供的服务。 实现是接口的具体行为，它负责执行接口的全部语义，是具体的服务兑 现过程。
只是名称不同，技术上完全相同。 UML 2的活动图独立于状态机存在。
组合结构图 显示结构化类元或协作的内部结构，和普通类图之间没有严格界限。
软件工程课后习题答案中文翻译版(第八版)

软件工程课后习题答案中文翻译版(第八版)

软件工程课后习题答案中文翻译版(第八版)软件工程课后习题答案中文翻译版(第八版)软件工程是一门关于软件开发和维护的学科。

它涉及项目管理、软件需求分析、软件设计、编码以及测试等诸多方面。

对于软件工程学习者来说，习题是非常重要的学习资源。

习题可以帮助学生巩固所学知识，增强对软件工程概念和技术的理解。

因此，软件工程课后习题答案的翻译版本是非常有价值的学习资料。

第一章：软件工程概述1. 软件工程的定义是什么？软件工程是一门关于开发、维护和管理软件的学科，它涵盖了软件生命周期的各个阶段，包括需求分析、设计、编码、测试和维护等。

2. 软件生命周期包括哪些阶段？软件生命周期包括需求定义、软件设计、编码、测试和维护等阶段。

3. 解释软件过程模型。

软件过程模型是软件工程中定义和管理软件开发过程的一种方法。

常见的软件过程模型包括瀑布模型、迭代模型和敏捷模型等。

第二章：软件项目管理1. 什么是软件项目管理？软件项目管理是对软件开发项目进行规划、组织、指导和控制的过程，目的是确保项目按时、按质量要求完成。

2. 软件项目管理的主要任务是什么？软件项目管理的主要任务包括项目计划、项目组织、项目沟通、项目风险管理和项目控制等。

3. 解释关键路径法。

关键路径法是一种用于确定项目进度安排和资源分配的方法。

通过确定项目中的关键路径，可以确保项目按时完成。

第三章：软件需求分析1. 软件需求分析的目的是什么？软件需求分析的目的是确定软件系统的功能和性能需求，并将其转化为具体的需求规格说明。

2. 软件需求分析的主要活动包括哪些？软件需求分析的主要活动包括需求获取、需求建模、需求验证和需求管理等。

3. 解释用例图。

用例图是一种用于描述系统功能的图形化表示方法。

用例图可以帮助分析师和开发人员理解系统与用户之间的交互。

第四章：软件设计1. 软件设计的目标是什么？软件设计的目标是将需求规格转化为可执行的软件系统，并满足性能、可维护性和可扩展性等要求。

软件工程论文各章节中常见的模型图表

软件工程论文各章节中常见的模型图表

论文各章节中常见的模型图表
1.需求分析相关章节：
●公司组织结构图
●用例图（业务用例图、系统用例图）
●活动图、业务流程图
●状态图
●分析类图
●DFD图
●ERD图（只表明实体关系，不关注细节）
●网络拓扑图、大系统的体系结构图
2.系统总体设计相关章节：
●网络拓扑图
●软件体系结构图
●功能结构图（系统功能结构划分）
●包图
3.系统详细设计相关章节：
●模块/功能设计流程图
●接口设计类图
●设计类图
●功能设计时序图
●ERD（含详细属性及关联关系）+数据库表结构表
4.系统实现相关章节：
●程序流程图
●实现时序图
●典型运行结果截图
5.系统测试与性能分析相关章节：
●测试用例
●性能分析图、表
●测试运行结果截图。

软件工程第三章需求应用全面分析

软件工程第三章需求应用全面分析


结构化英语、判定树、判定表用于描述数据流 图中的处理逻辑说明。
• SA方法的实质*：是采用一组分层数据流图及数据
字典作为系统的模型，从总体来看，是一种依赖数
据流图的自顶向下的建模方法。
2020/11/25
5
数据流图：分层扩展的功能模
型
数据流图（DFD）是SA方法中用于建立系统逻辑模型 的一种工具，它以图形的方式描绘数据在系统中处理的流 动过程。由于它只反映系统需要完成的逻辑功能，所以它 是一种功能模型。*
配件库存
顾客
订货单 发货单
1
处理 业务Biblioteka 订货单 发货单供应 商
2020/11/25
15
数据流图： DFD绘制步骤（续）
* （2）再绘制二层DFD：是顶图的分解，表明子系统划分及其 边界。 • 系统划分几个子系统，一个子系统在二层图中只有一个处理逻辑（需
求来源是业务子系统或用例图中的用例）； • 每一子系统析取所有的外部项、输入输出数据流和主要数据存储； • 各子系统之间的依赖关系（数据流直接依赖，数据存储缓存依赖）。
软件工程 Software Engineering
第三章 需求应用全面分析
2020/11/25
1
本章主要内容
• 3.1 软件需求概念
-软件需求的问题、定义、层次、来源、依据、目标
• 3.2 需求工程过程
- 需求开发：需求获取、需求分析、规格说明、需求验证 - 需求管理：覆盖需求开发全过程
• 3.3 需求获取技术
数据存储可以是一个文件，也可以是文件的一部分或 数据库记录的一部分。数据可以存储在磁盘、磁带、存储 器等任何介质上。指向数据存储的箭头可以是单向的，也 可以是双向的。
用例和用例图

用例和用例图


访客用例图
会员用例图
书店管理员用例图
3、用例描述 （1）细化用例描述----搭框架

用例名称：搜索图书 概述：用户根据关键字搜索图书 前置条件：无 事件流： 基本事件流 扩展事件流 后置条件: 无
3、用例描述 （2）细化用例描述----填＂血肉＂

事件流： •基本事件流 1 用户点击“搜索图书”，用例开始。 2 系统显示搜索图书商品界面，提示用户输入商品关键字。 3 用户输入图书关键字，选择提交。 4 系统访问数据库，根据关键字查询相关的图书商品信息， 并把查询出的图书信息显示搜索图书页面。 5 用例结束。 •扩展事件流 4a) 系统未查出所要商品相关信息，显示提示信息，用例 结束。 4b) 系统查出用户输入的关键字为空，显示提示信息并返 回基本事件流2。

编写用例描述应遵循以下几点：



使用简单的语法，主语明确，语义易于理解；在事件流描 述中让读者直观地了解是参与者在控制还是系统在控制； 从第三者观察的角度指出参与者的动作，以及系统的响应； 显示参与者的意图而非动作 显示过程向前推移，每一步都有前进感；

构建结构良好的用例
为系统和部分系统中单个的、可标识的、合理的原子行为 命名。 将多个用例的公共的行为抽取出来放到一个被包含用例中。 对于变化部分，将其抽取出来，放到扩展用例中。 清晰的描述事件流。


扩展关系（Extend）
扩展关系表示基本用例在由扩展用例间接说明的一个位置 上隐式的合并了另一个用例（扩展用例）的行为。 基本用例不知道扩展用例的任何细节，没有扩展用例，基 本用例是完整的。只有在特定条件下，它的行为可以被扩 展用例的行为扩展，因此扩展关系处理事件流的异常或者 可选事件。
第3章 需求分析与用例模型

第3章 需求分析与用例模型


用例图是骨架，而用例规约则是其内在的肉
用例规约
用例规约包含以下内容： 1 简要说明:对用例作用和目的的简要描述。 2 事件流:事件流包括基本流和备选流。基本流描述的是用例的基本 流程，是指用例“正常”运行时的场景。 3 用例场景:同一个用例在实际执行的时候会有很多不同的情况发生， 称之为用例场景，也可以说用例场景就是用例的实例。 4 特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。 特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性 等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属 性等。 5 前置条件: 执行用例之前系统必须所处的状态。例如，前置条件 是要求用户有访问的权限或是要求某个用例必须已经执行完。 6 后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求 在某个用例执行完后，必须执行另一个用例。
注意：执行基用例时，每次都必须调用被包含用例。
包含关系误用
用例之间的各种关系
4.扩展关系
扩展关系是一个用例被定义为基础用例的增量扩展，通过 扩展关系把新的行为插入到已有用例中。扩展关系中，扩 展用例是基础用例的一个相对独立并且可选的用例。 在UML中，扩展关系用虚线箭头加<<extend>>表示，箭头 指向基础用例，即被扩展的用例
一、 什么叫用例图
3、用例图的作用 获取需求、指导测试、对开发过程中的其他工作起指 导作用。
二、用例图的构成要素
用例图包含3方面内容：
参与者（Actor）
用例（Use Case）
关系： 关联（Association）
泛化（Generalization）
包含（Include） 扩展（Extend）
用例之间的各种关系
软件工程课件之第4章用例和用例图

软件工程课件之第4章用例和用例图


4.2.3 泛化关系
借阅者
.9 泛化关系
4.2.4 分组关系
在一些用例图中，用例的数目可能很多，这时就需要把 这些用例组织起来。这种情况在一个系统包含很多子系 统时就会出现。另一种可能就是，当你按顺序和用户会 谈，收集系统需求时，每个需求必须用一个单独的用例 来表达，这时就需要某种方式来对这些需求进行分类。
4.1.1 参与者
例如，在“图书管理系统”中，可以认为“读者”是 “学生读者”和“教师读者”的泛化，而“学生读者” 还可以具体化为“本科生读者”和“研究生读者”；同 样，“图书管理员”也是“采购员”、“ 编目员”及 “借阅人员”的泛化。图4.3表示出了参与者之间的泛 化关系。
4.1.1 参与者
“<<extend>>”是扩展关系的构造型，箭头指向基本用例。
4.2.2 扩展关系
借阅者
<<include>>
还书
<<extend>>
查询图书 交罚款
图4.8 扩展关系
区别与联系：
联系：都是从现有的用例中抽取出公共的那部分信息
，作为一个单独的用例，然后通过不同的方法来重用这 个公共的用例，以减少模型维护的工作量。
因此，在“图书管理系统”中“借阅者”和“系统管理 员”都是参与者。
4.1.1 参与者
【例4-1】客户给销售员发来传真订货， 销售员下班前 将当日订货单汇总输入系统。谁是系统的参与者？
分析：根据参与者的定义可知，此系统的参与者是销售 员。
4.1.1 参与者
【例4-2】在需求分析中常见的权限控制问题，一般的 用户只可以使用一些常规的操作，如查询等，而管理员 除了常规操作之外还需要进行一些系统管理工作，如一 些关键数据的增加、删除、修改等，操作员既可以进行 常规操作又可以进行一些配置操作。
人事管理系统用例图类图活动图

人事管理系统用例图类图活动图

资料范本本资料为word版本，可以直接编辑和打印，感谢您的下载人事管理系统用例图类图活动图地点：__________________时间：__________________说明：本资料适用于约定双方经过谈判，协商而共同承认，共同遵守的责任与义务，仅供参考，文档可直接下载或修改，不需要的部分可直接删除，使用时请详细阅读内容Fox-ERP人事管理系统(二)-----毕业设计(论文)指导老师专业计算机应用与维护组长班级组员成都电子机械高等专科学校2007年5月10日目录TOC \o "1-5" \h \z \u HYPERLINK \l "_Toc138481954" 第一章系统功能 1HYPERLINK \l "_Toc138481955" 1.1需求分析 3HYPERLINK \l "_Toc138481956" 1.2FOX-ERP人事管理系统功能4HYPERLINK \l "_Toc138481957" 第二章系统分析图PAGEREF_Toc138481957 \h - 5 -HYPERLINK \l "_Toc138481958" 2.1 UML图 52.1.1用例图 HYPERLINK \l "_Toc138481958" 62.1.2类图 HYPERLINK \l "_Toc138481958" 82.1.3活动图 HYPERLINK \l "_Toc138481958" 9HYPERLINK \l "_Toc138481958" 2.2系统架构9HYPERLINK \l "_Toc138481964" 第三章主要关键技术103.1关键技术之一 HYPERLINK \l "_Toc138481958" 103.2关键技术之二 HYPERLINK \l "_Toc138481958" 113.3关键技术之三 HYPERLINK \l "_Toc138481958" 11HYPERLINK \l "_Toc138481965" 第四章数据库结构124.1数据库设计 HYPERLINK \l "_Toc138481958" 124.2人事管理系统的数据模型图 HYPERLINK \l "_Toc138481958" 16HYPERLINK \l "_Toc138481966" 第五章使用FOX-ERP人事管理系统说明书16HYPERLINK \l "_Toc138481967" 5.1 FOX-ERP人事管理系统平台16 HYPERLINK \l "_Toc138481968" 5.1.1 硬件需求 16HYPERLINK \l "_Toc138481969" 5.1.2 安装: 175. 1. 3第二期工程的后续工作 HYPERLINK \l "_Toc138481958" 17HYPERLINK \l "_Toc138481970" 5.2 FOX-ERP人事管理登录和进入系统17HYPERLINK \l "_Toc138481971" 5.2.1 登录17HYPERLINK \l "_Toc138481972" 5.2.2 进入FOX-ERP人事管理系统主界面17HYPERLINK \l "_Toc138481973" 5.2.3 使用说明18HYPERLINK \l "_Toc138481974" 第六章 FOX-ERP人事管理主要源程序PAGEREF _Toc138481974 \h - 32 -HYPERLINK \l "_Toc138481975" 一、密码的修改和找回 PAGEREF_Toc138481975 \h - 34 -1：修改密码代码 HYPERLINK \l "_Toc138481958" 322：找回密码代码 HYPERLINK \l "_Toc138481958" 32二、员工就职 HYPERLINK \l "_Toc138481958" 33HYPERLINK \l "_Toc138481976" 1：代号档资料维护界面代码33HYPERLINK \l "_Toc138481977" 2：员工基本资料353：津贴/扣款维护 HYPERLINK \l "_Toc138481958" 38HYPERLINK \l "_Toc138481978" 4: 健保眷属资料维护代码39HYPERLINK \l "_Toc138481976" 5：经历资料维护代码40HYPERLINK \l "_Toc138481977" 6：证照资料维护代码PAGEREF_Toc138481977 \h - 38 -HYPERLINK \l "_Toc138481978" 7: 技能资料维护代码PAGEREF_Toc138481978 \h - 44 -HYPERLINK \l "_Toc138481979" 三、人事异动431：就职单维护代码 HYPERLINK \l "_Toc138481958" 43HYPERLINK \l "_Toc138481980" 2：调职单维护代码PAGEREF_Toc138481980 \h - 51 -HYPERLINK \l "_Toc138481981" 3：离职单维护代码PAGEREF_Toc138481981 \h - 53 -HYPERLINK \l "_Toc138481976" 4：复职单维护代码47HYPERLINK \l "_Toc138481983" 四、教育训练PAGEREF _Toc138481983 \h - 60 -2：教育训练员工文件维护 HYPERLINK \l "_Toc138481958" 503：教育训练课程名单 HYPERLINK \l "_Toc138481958" 514：教育训练上课员工名单 HYPERLINK \l "_Toc138481958" 51HYPERLINK \l "_Toc138481979" 五、考绩与奖惩作业51HYPERLINK \l "_Toc138481980" 1：考绩资料添加512：考绩资料维护 HYPERLINK \l "_Toc138481958" 52HYPERLINK \l "_Toc138481981" 3：奖惩资料添加534：奖惩资料维护 HYPERLINK \l "_Toc138481958" 54HYPERLINK \l "_Toc138481979" 六、退休作业55HYPERLINK \l "_Toc138481980" 1：退休员工就职文件维护55HYPERLINK \l "_Toc138481981" 2：未来退休员工预估表56七、用户注册 HYPERLINK \l "_Toc138481958" 571：设置用户 HYPERLINK \l "_Toc138481958" 572：用户注册 HYPERLINK \l "_Toc138481958" 57HYPERLINK \l "_Toc138481958" 总结58HYPERLINK \l "_Toc138481988" 主要参考文献59HYPERLINK \l "_Toc138481989" 谢辞59第一章系统功能1.1 需求分析软件工程中包含需求、设计、编码和测试四个阶段，其中需求分析是软件工程中第一个也是很重要的一个阶段，需求分析的基本任务就是准确地回答“系统必须做什么”这个问题，而它的主要任务就是绘制关联图、创建开发原型、分析可行性、确定需求优先级、为需求建立模型、编写数据字典、应用质量功能调配。

UML各章习题

UML各章习题

UML各章习题第1、2章面向对象与UML1．简述统一建模语言(UML)统一建模语言(UML)是一种绘制软件蓝图的标准语言。

可以用UML对密集型软件系统的制品进行可视化详述和文档化。

UML是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言（1分）。

它融入了软件工程领域的新思想、新方法和新技术。

它的作用域不限于支持面向对象的分析与设计（1分），还支持从需求分析开始的软件开发的全过程（1分）。

UML的作用是用图的形式从静态和动态方面来全面描述将要开发的系统（2分）。

2. 简述面向对象分析方法（OOA）的5个基本步骤 1）、识别对象，识别对象包括标识潜在的对象和筛选对象两步（1分） 2）、识别对象的属性（1分） 3）、识别对象的行为（1分） 4）、识别对象所属的类（1分） 5）、定义主题词（1分）3、什么是高内聚度？高内聚度是对一个类中的各个职责之间相关程度和集中程度的度量。

一个具有高度相关职责的类并且这个类所能完成的工作量不是特别巨大，那么它就具有高内聚度。

包括两个含义：一、不要给一个类分派太多的职责，在履行职责时尽量将部分职责分派给有能力完成的其它类去完成。

二、不相关的职责不要分派给同一个类。

4、什么是对象间的可见性?答:可见性（Visibility）指的是一个对象能够“看到” 或者引用另一个对象的能力。

5、领域建模的步骤有哪些？答案：列出候选的概念类；画出领域模型图；加入概念类间的关联；加入概念类的属性。

6、什么是软件生命周期？软件生命周期(SDLC，Systems Development Life Cycle)是软件的产生直到报废或停止使用的生命周期，周期内包括问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段。

这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。

用例图


存款
4
3.1.1 用例
怎样确定用例的粒度？
用例的粒度（用例的大小）可大可小，一般一个系 统宜控制在20个用例左右。 用例是系统级的、抽象的描述，不是细化的（是做 什么，非怎样做） 对复杂的系统可以划分为若干子系统处理。
学籍 处理
退学处分
3.1.1 用例
怎样获取用例？
参与者希望系统执行什么任务？ 参与者在系统中访问哪些信息（创建、存储、修 改、删除等）？ 需要将外界的哪些信息提供给系统？ 需要将系统的哪个事件告诉参与者？ 如何维护系统？
3.1.3 关系
包含include
一个用例过于复杂，可以分解成小用例，构成包含 依赖（三个被包含的用例合起来实现完整的事件 流，不能单独调用）；
3.1.3 关系
扩展extend
一个用例（在某些扩展点上）扩展另一个用例的功 能 ，构成新用例； 扩展用例依赖于被扩展依赖（基本用例），只是部 分片断组成，不是完整的独立用例，无法单独执 行；
用例图
本章内容
组成 用例图 用例描述 用例分析 业务用例图 实例
2
3.1 组成
用例（Use Case） 参与者（角色，Actor） 关系（Relationship）
3
3.1.1 用例
Use Case:
系统、子系统或类与外部的参与者（actor）交互的 动作序列的说明，包括各种序列及出错序列。 用例分析可以认为是对系统功能的分解。
3.4 用例分析
识别参与者
已有的上下文关系图（表示系统范围）及其他相关模型：它 们描述了系统与外部系统的边界，从这些图中可以寻找出与 系统有交互关系的外部实体。 项目相关人员分析：对项目的相关人员进行分析，就能够决 定出哪些人将会与系统进行交互。 书面的规格说明和其它项目文档（如会谈备忘录等） 需求研讨会和联合应用开发会议的记录：这些会议的参与者 通常是很重要的，因为他们在组织中所代表的角色就是可能 与系统发生交互的参与者。 当前过程和系统的培训指南及用户手册：这些东西中经常会 有潜在参与者。

用例图

.1 用例图由前几章可知，用例图用来捕获用户要求，需要首先构建。

为什么？因为用例图在较高级别(即非技术细节)描述用户要求。

概念设计对项目的成败至关重要。

由第2章可知，在决定使用哪种技术前，一定要切实了解影响选择的要求。

用例图的高级特性有利于了解项目范围。

这些图成为项目演化过程中构建明细模型的基础。

用例图的另一个强大之处在于，它使用普通文本和简单绘图技术，不使用任何技术术语，使广大受众都可以理解用例图。

用例图由以下一些基本元素构成：●行动者(Actor)●关系(Relationship)●过程(Process)●包(Package)●系统边界(System boundary)下面几节描述这些元素。

4.1.1 行动者“行动者”是与系统交互的某人或某事。

“交互”指行动者从系统接收收息，或向系统传送信息。

要注意，行动者可以是人，也可以是物(如另一个应用程序)，例如从解决方案接收信息的会计系统。

UML行动者的符号是一个人形，如图4-1所示。

图4-1 行动者的符号是一个人形注意：行动者使用的人形符号是最常用也是最正式的符号。

不过，按UML规范，行动者也可以是一个包含Actor定型的矩形。

该符号与类符号类似，在第5章讨论类图时，将看到这个符号。

图4-1的行动者是一个普通行动者，即一个直接与解决方案交互的真正行动者。

还有其他类型的行动者，即业务行动者。

业务行动者是当前分析业务的行动者，换言之，从业务观点看，参与业务日常过程的所有人或事物都是行动者。

业务行动者不一定是您解决方案的行动者，而是相关业务的行动者。

会记助手便是其中一例。

会计助手可能不是当前开发的解决方案的行动者，而是一个业务行动者。

为什么要注意会计助手呢？虽然这个角色不是解决方案的行动者，但他们可能是采访主体，可提供有价值的信息。

在优化一些过程时，会计助手的知识及他们的日常工作也能提供宝贵信息。

在设计解决方案前，必须了解整个业务，即需要进行业务分析。

“业务分析”是记录业务的过程。

  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

为了保证系统正常运行，谁将对系统进行维护管理

（副参与者）？ 谁将完成系统数据的录入、导出及修改等工作（主 动参与者）？ 谁或什么系统对系统产生的结果感兴趣（被动参与 外部系统进行交互？ 在预定的时间，是否有事件自动触发？ 系统从何处获取信息？
（2）参与者不一定是人，也可以是一个外部系统， 该系统与本系统相互作用。代表的是一种角色。 （3）在系统的实际运作中，多个不同的用户可能 只对应于一个参与者；同时一个实际用户也可 能对应系统的多个参与者。
例如： 在“房地产开发经营管理系统”中，
所有的购房者作为一个集合，在“房屋销售子 系统”中作为购房合同的签约方出现，多个个 体在系统中担任一个参与者；同时，某个独立 的购房者在“物业管理子系统”中又作为房屋 的业主出现，同一个人在系统中担任了两类参 与者。
主参与者和副参与者
主参与者使用系统的主要功能，是使用系统较 频繁、业务量较大的用户。 副参与者处理系统的辅助功能，它与用例进行 交互的主要目的是为了给其他的参与者提供某些服 务。如管理数据库、通信、系统备份以及其他管理
等系统维护工作。
主动参与者和被动参与者
主动参与者是系统的启动者，负责启动一个或多
借阅图书用例的描述
用例名称 标识符 用例描述 参与者 状态 BorrowBook UC0001 图书管理员代理借阅者办理借阅手续 图书管理员 通过审查
前置条件
后置条件 假设 基本操作流程
图书管理员登录进入系统
如果这个用例成功，在系统中建立并存储借阅记录 图书管理员已经成功地登录到系统 1. 2. 3. 4. 5. 管理员输入借书证信息 系统验证借阅证的有效性 图书管理员输入图书信息 添加新的借阅记录 显示借书后的借阅信息
1、关联关系
关联关系是执行者与用例之间的联系。执行者 触发了用例之后，与用例进行信息交换，用例在完 成相应功能后，向执行者返回结果。关联用执行者
与用例之间的带箭头连线来表示。
1、关联关系
关联关系是执行者与用例之间的联系。执行者 触发了用例之后，与用例进行信息交换，用例在完 成相应功能后，向执行者返回结果。关联用执行者 与用例之间的带箭头连线来表示。

<<include>>
基本用例
被包含用例
用例间的包含关系
<<include>>
BorrowBook
Librarian
ProcessOverTime
<<include>>
ReturnBook
图书管理系统用例图包含关系示例
4、扩展关系
扩展关系是一种依赖关系。它指定了一个用例可 以增强另一个用例的功能，通过基本用例添加动作来 扩展该用例。
AddBook
Libraian::LoanBook
3.3.2 确定用例
1、确定用例策略
确定用例最好的方法是从分析系统的参与者开始，
对于已经确定的参与者，通过考虑每个参与者是如
何使用系统的，以及系统对事件的响应来识别用例。
使用这种策略进行具体分析的过程中，可能会发现
新的参与者，这对完善整个系统的建模有很大的帮 助作用。
3.2.3 参与者之间的关系
参与者是类，类之间的关联也适用于参与者， 多个参与者之间的关系就是类与类之间的关系。在 用例图中，使用泛化关系来描述多个参与者之间的 公共行为。如果系统中存在几个参与者，他们既扮 演自身的角色，同时也扮演更具一般化的角色，那 么就用泛化关系来描述他们。
泛化关系：用一个三角箭头来表示，其中箭头所 指向的角色为超类参与者，箭头尾端的角色为特殊化
1、描述用例作用
用例图通过图形符号描述了参与者和系统之间
的关系，但是它对于系统行为的细节描述比较 欠缺。
在一般情况下，需要以书面文档的形式对于用
例进行描述。
2、描述用例包含的内容
1.名称：能够明确的表明用户的意图或用例的用途， 切记不要使用诸如UseCase1、UseCase2之类的 名称，会使用例图的读者在阅读时无法读懂用例 图所描述的内容。
参与者（Actor）
3.2.2 确定参与者
1、说明
（1）进行用例图建模，首先要做的就是确定系统 的参与者。 （2）在确定参与者之前，一定要明确一点：参与 者对于系统而言，总是处于系统外部的，而不 是系统的组成部分。
2、识别参与者
谁将使用系统的主要功能（主参与者）？ 谁将借助于系统来完成日常工作？

面向对象的系统分析主要特点是把问题域中的事 物抽象为系统中的对象，最终建立一个用面向对 象概念表达的系统模型。 抽象必须有一个目标，对分析而言，这个目标就 是要满足用户需求。 Jacobson提出：针对系统对外提供的每一项功 能，详细地描述对这项功能的使用情况（use case，简称用例）。


的参与者。
超类参与者
特殊化的参与者
特殊化的参与者
例：假设在图书管理系统中，管理员分为对系统进
行维护的系统管理员和完成借书、还书等日常操作 的图书管理员。在这里，管理员参与者描述了图书
管理员和系统管理员所扮演的一般角色。
管理员
图书管理员
系统管理员
3.3 用例（Use Case）
3.3.1 用例的概念



用例模型是表达系统外部事物（参与者）与系统 之间交互的可视化工具。

一个系统的用例模型由若干用例图组成，用例图 的主要成分有参与者（Actor）、用例（Use Case）以及用例间的各种关系。
用例图可以包含注释和约束，还可以包含包，用 于将模型中的元素组合成更大的模块。

用例1
参与者1 基用例1
3、参与者的分类
（1）人参与者和外部系统参与者 （2）主参与者和副参与者 （3）主动参与者和被动参与者
人参与者和外部系统参与者。
人参与者是系统的各类用户，用户通过与系统进行交
互来操纵系统，完成各种工作。 外部系统参与者是位于系统外部的其他软件系统或硬
件设备。
例如：计算机网络系统的参与者可以包括操作员系 统管理员、数据库管理员以及普通用户等人参与者，另 外也可以有外部系统参与者，如网络打印机。
可选操作流程
该借阅者有超期的借阅信息，进行超期处理； 借阅者所借阅的图书超过了规定的数量，用例终止，拒绝借阅； 借阅证不合法，用例终止，图书管理员进行确认 王强，定义基本操作流程，2008年1月7日 丁一，定义可选操作流程，2008年1月10日
修改历史记录
3.3.4 用例间的关系
在用例模型中，用例与参与者之间、用例与用 例之间有一定的关系。 UML中用例之间的关系主要有4种：关联关系、 泛化关系、包含关系和扩展关系。
2.标识符[可选]：用来唯一标识一个用例，如 “UC0001”，这样就可以在项目的其他元素中用 它来引用这个用例。 3.参与者[可选]：与此用例相关的参与者列表。在 没有用例图时，它有助于增加对该用例的理解。
4.状态[可选]：用来指示该用例的状态，通常可 包括进行中、等待审查、通过审查或未通过审查 等状态。 5.频率：记录参与者使用该用例的频率。
<<include>>
参与者2 基用例2
<<include>>
被包含用例 用例2
参与者3
基用例3
<<extend>>
扩展用例
基本用例图
3.2 参与者（Actor）
3.2.1 参与者概念
1、概念 参与者是在系统之外与系统进行交互的任 何事物，可以是人或其他系统，他以某种方式 参与了系统内用例的执行。 2、特征 （1）参与者作为外部用户与系统发生交互，交 互的方式可以是参与者向系统发送消息，也可 以是从系统那里接收消息，或与系统之间交换 消息。
8.假设[可选]：假设描述的是系统在使用用例之前 必须满足的状态，这些条件并没有经过用例的检 测，用例只是假设它们为真。 9.基本操作流程：参与者在用例中所遵循的主要逻 辑路径。操作流程描述了用户和执行用例之间交 互的每一步。 10.可选操作流程：包括用例中很少使用的逻辑路径， 那些在变更工作方式、出现异常或发生错误的情 况下所遵循的路径。 11.修改历史记录[可选]：主要记录的是关于用例的 修改时间、修改原因和修改人的详细信息。
用例建模的过程是一个迭代并逐步细化的过程。
2、确定用例方法
参与者需要系统提供什么功能？即参与者需要系统
“做什么”？
参与者是否需要读取、产生、删除、修改或存储系
统中的某种信息？
当系统状态改变时，是否通知参与者？ 是否存在影响系统的外部事件？ 系统需要什么样的输入/输出信息？
3.3.3 描述用例
<<extend>>
基本用例
扩展用例
<<include>>
BorrowBook Librarian ReturnBook
<<extend>>
<<include>>
ProcessOverTime
NotifyOverTime
3.4 用例图建模
1、用例图建模的步骤 在UML中，用例图建模的步骤主要包括： ① 识别和确定参与者。 ② 识别和确定用例。 ③ 描述用例。 ④ 定义用例之间的关系。 ⑤ 建立用例图，构造用例模型。 ⑥ 审核用例模型。
个用例，他们是为了完成某项事务而启动系统的，一 个主动参与者可以请求某种服务或者触发一个事件。 被动参与者从不启动用例，只是参与一个或多个 用例，他们响应系统的请求，为系统提供某种服务。
4、参与者的表示 在用例图中，参与者用一个简化的人体形状的 符号（稻草人）表示，在符号的下方注明了参与者 的名称。