第2章软件开发方法与技术( 功能模型—用例图)
合集下载
软件工程之用例模型总结
软件工程之用例模型总结一、用例模型1.用例概念用例：使用系统时发现的功能性需求，不应过于复杂，简单的来说就是你希望系统能够有什么功能，能够增加系统的价值。
用例模型包括用例描述和用例图，我们主要把中心放在用例描述上。
用例模型包含参与者和场景，场景包括成功场景和失败场景。
因此用例模型中有多个场景；每个场景是一个用例。
用例必须注重为用户提供可观察的返回值，就是系统触发了一个用例之后能够给用户带来什么。
一般用例都是黑盒用例，即不考虑如何实现。
e Case Description每个用例都有一个描述。
怎样确定用例？(1)确定一个功能；(2)写一个用例；(1)主要参与者：调用系统服务完成目标的人。
(2)次要参与者：为系统提供服务的人。
(3)写出每个项目相关人员的理想需求，从中分析功能。
(4)PreCondition:执行到这个用例之前必须为真的情况，比如必须已成功登录或通过验证。
(5)PostCondition:成功执行完此用例后的情况，比如登录用例的后置条件是成功登录（不考虑其他失败情况）。
(6)main flow：将最理想的步骤列出。
一般main flow步骤如下：(1)参与者发生动作。
(2)系统验证。
(3)返回结果。
(7)extension flow：扩展步骤,通常格式为：(1)系统检测到**有问题;在main flow中的第一步扩展，则用1a,1b,1c;3.如何确保正确的用例EBP原则:一般用例都需要遵守这个规则，即确定主要用例。
用例中的主要用例是一些重复做但是有意义的事，比如收银员收钱，重复多次是有意义的，因为钱收得多了；但是像登录系统，这种做100次却没有意义的用例，不能被称为主要用例；(1)EBP（基本业务过程）原则的用例写入；(2)如果要写编辑A，删除A，添加A，可以合并成“管理A”；4.用例图每个用例描述都是一个用例，左边是主要参与者（希望系统为他提供服务）和次要参与者（提供给系统服务的人）；在次要参与者中不能有数据库，因为在用户角度看是不知道系统有数据库的；关系：(1)泛化关系，在参与者和用例中都能泛化。
软件开发模型PPT课件
第24页/共67页
适合的项目类型： ➢ 采用快速度从小到大变化的项目，例如重整企业的信息系统。
第25页/共67页
软件生命周期与软件开发模型
3、增量模型 增量模型也称为渐增模型。 使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、
➢这个模型中最终用户是很重要的角色，从图2.5 可以看出，系统构造的实践比传统其他模型要少 很多，模型中更多的任务是规划和设计，而不是 编码和测试。
➢因为在开发中采用很多的工具，例如利用代码生 成器等生成需要的系统，这样会很快构造一个系 统。采用这种方法可以不断完善地构造出一个用 户需要的系统。
➢这个系统中的构造包括详细设计、编码、测试等， 所以，快速应用开发（RAD）模型相当于将设计、 构建、测试等压缩为一系列的短的迭代式的循环。
修正前面阶段的产品之
综合测试
后再回来继续完成后面
阶段的任务。
图2.2 实际瀑布模型
维护
第9页/共67页
软件生命周期与软件开发模型
瀑布模型有许多优点：
➢ 可强迫开发人员采用规范的方法（例如，结构化技 术）；
➢ 严格地规定了每个阶段必须提交的文档； ➢ 要求每个阶段交出的所有产品必须经过质量保证小
组的仔细验证。
第27页/共67页
软件生命周期与软件开发模型
3、增量模型 ➢ 使用增量模型时，把软件产品分解成增量构件时，应该使构件的规模适中， 规模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而 异。 ➢ 分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形 成的产品必须是可测试的。 ➢ 第一个增量构件往往实现软件的基本需求，提供最核心的功能。
➢ 原型的用途是获知用户的真正需求，一旦需求确定了，原型将 被抛弃。
适合的项目类型： ➢ 采用快速度从小到大变化的项目，例如重整企业的信息系统。
第25页/共67页
软件生命周期与软件开发模型
3、增量模型 增量模型也称为渐增模型。 使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、
➢这个模型中最终用户是很重要的角色，从图2.5 可以看出，系统构造的实践比传统其他模型要少 很多，模型中更多的任务是规划和设计，而不是 编码和测试。
➢因为在开发中采用很多的工具，例如利用代码生 成器等生成需要的系统，这样会很快构造一个系 统。采用这种方法可以不断完善地构造出一个用 户需要的系统。
➢这个系统中的构造包括详细设计、编码、测试等， 所以，快速应用开发（RAD）模型相当于将设计、 构建、测试等压缩为一系列的短的迭代式的循环。
修正前面阶段的产品之
综合测试
后再回来继续完成后面
阶段的任务。
图2.2 实际瀑布模型
维护
第9页/共67页
软件生命周期与软件开发模型
瀑布模型有许多优点：
➢ 可强迫开发人员采用规范的方法（例如，结构化技 术）；
➢ 严格地规定了每个阶段必须提交的文档； ➢ 要求每个阶段交出的所有产品必须经过质量保证小
组的仔细验证。
第27页/共67页
软件生命周期与软件开发模型
3、增量模型 ➢ 使用增量模型时，把软件产品分解成增量构件时，应该使构件的规模适中， 规模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而 异。 ➢ 分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形 成的产品必须是可测试的。 ➢ 第一个增量构件往往实现软件的基本需求，提供最核心的功能。
➢ 原型的用途是获知用户的真正需求，一旦需求确定了，原型将 被抛弃。
高级软件工程(第二章)软件开发过程与开发方法 (2017课件)
ቤተ መጻሕፍቲ ባይዱ
⑸ 支持阶段
主要目标：在系统初始安装后的几年里保持系统 有效的运行。
主要活动： 维护系统； 加强系统； 支持用户。
11
1. 迭代
迭代意味着任务做了一次，接着又一次，然后 又一次(任务是不断重复的)。 随着每一次迭代，结果得到了修正，并且越来 越接近目标。 假设：不可能在第一次就得到正确的结果。
17
模型的概念
模型(MODLE)是对某个实体或事物的抽象和简 化。其目的是在构建这个事物之前先来理解它。 模型忽略了非本质的细节，抽象出了问题本质， 使问题更容易理解，有助于对复杂问题进行分 层，从而更好地解决问题。
18
面向过程方法
面向过程的方法认为我们的世界是由一个个相互关 联的小系统组成。 每个小系统都有明确的开始和明确的结束 ,开始和结 束之间有着严谨的因果关系。 如果用计算机模拟它，首先的工作就是将这个过程 描绘出来，定义因果关系，细化，用编程语言实现。 过程中每一步都会产生、修改或读取一部分数据。 将世界视为过程的这个方法本身蕴涵着一个前提假 设，即这个过程是稳定的，这样我们才有分析的基础， 所用的工作成果都依赖于这个过程的步步分析。
19
面向对象方法
面向对象方法将世界看作一个个相互独立的对象， 相互之间并无因果关系。只有在某个外部力量的驱 动下，对象之间才会依据某种规律相互传递信息。 这些交互构成了这个生动世界的一个“过程”。 在没有外力的情况下，对象保持“静止”的状态。
20
面向过程，还是面向对象？
如果你的分析习惯是在调研需求时最先弄清楚有多 少业务流程，先画出业务流程图，然后顺藤摸瓜， 找出业务流程中每一步骤的参与部门或岗位，弄清 楚在这一步参与者所做的事情和填写表单的结果， 并关心用户是如何把这份表单传给到下一个环节的。 面向过程。 如果你的分析习惯是在调研需求时最先弄清楚有多 少部门，多少岗位，然后找到每一个岗位的业务代 表，问他们类似的问题：你平时都做什么？这件事 是谁交办的？做完了你需要通知或传达给谁吗？做 这件事情你都需要填写些什么表吗？.... OO
第1章 软件开发方法与技术(UML概述)
说明: 采用面向对象技术开发软件时： 第 1步：基于问题域，建立系统的描述需求模型“用例图” 且给出系统需求的文字陈述，包括： ⑴ 功能性需求：描述系统的功能（做什么） ⑵ 非功能性需求：描述系统的功能实现更好的方面： 性能、安全性和可靠性等 ⑶ 可用性需求：描述系统的应用程度 其中：功能性需求是必不可少的，另两个是辅助的
OMT 其他方法
UM0.8
Booch UML0.9 UML1.0
OOSE
§1.2 UML的特点 UML的主要特点可归纳以下几点： 1．UML统一了Booch、OMT、OOSE和其他面向对象方法 的基本思想、概念和符号。 2．UML是支持面向对象软件开发的建模语言。 3．UML可视化、表达能力强大。 4．UML是一种建模语言而不是一种方法。 其中：方法包括表示符号和开发过程的指导原则，而 UML仅提供了建模使用的表示符号及其应用规 则，不依赖于特定的软件开发过程。这也是它 能够被大众接受的一个原因。 例如：RUP（Retional Unified Process） Retional公司统一制定的开发过程，同UML （Retional Rose）配套使用 5．UML仍然在不断的完善和发展。
活动类是这种类，它的对象有一个或多个进程或线程，其外观 和普通类没有什么区别。
说明：在类的属性中按如下步骤设置： ” Detial Concurrency Active” 细节标签 并发性选项
⑥ 构件（component）
Component
构件是定义了良好接口的独立的软件实现实体（单元），它是 系统中物理的、可替代的部件。
逻辑视图 类图 对象图
并发视图：体现了系统的动态或行为特征 也称为：进程视图（Process View）
并发视图 时序图 协作图 状态图 活动图
第二章-软件开发方法概述-PPT课件
把问题／子问题的分解与软件开发 中的系统／子系统或系统／模块对 应起来，就能够把一个大而复杂的 软件系统划分成易于理解的比较单 纯的模块结构。
31
抽象化
软件系统进行模块设计时，可有不 同的抽象层次。 在最高的抽象层次上，可以使用问 题所处环境的语言概括地描述问题 的解法。 在较低的抽象层次上，则采用过程 化的方法。
16
实用性：确认该设计对于需求的解 决方案是否实用 技术清晰度：确认该设计是否以一 种易于翻译成代码的形式表达 可维护性：确认该设计是否考虑了 方便未来的维护 质量：确认该设计是否表现出良好 的质量特征
17
各种选择方案：看是否考虑过其 它方案，比较各种选择方案的标 准是什么 限制：评估对该软件的限制是否 现实，是否与需求一致 其它具体问题：对于文档、可测 试性、设计过程..等进行评估
49
公共耦合的复杂程度随耦合模块的个 数增加而显著增加。若只是两模块间 有公共数据环境，则公共耦合有两种 情况。松散公共耦合和紧密公共耦合。
50
内容耦合 (Content Coupling)
如果发生下列情形，两个模块之间 就发生了内一个模块不通过正常入口转 到另一模块内部;
28
④ 在模块A的箭头尾部标以一个菱 形符号，表示模块A有条件地调用 另一个模块B。当一个在调用箭头 尾部标以一个弧形符号，表示模块 A反复调用模块C和模块D。
29
程序的系统结构图
30
模块化
软件系统的模块化是指整个软件被 划分成若干单独命名和可编址的部 分，称之为模块。这些模块可以被 组装起来以满足整个问题的需求。
外部耦合（External Coupling）
一组模块都访问同一全局简单变量而 不是同一全局数据结构，而且不是通 过参数表传递该全局变量的信息，则 称之为外部耦合。
31
抽象化
软件系统进行模块设计时，可有不 同的抽象层次。 在最高的抽象层次上，可以使用问 题所处环境的语言概括地描述问题 的解法。 在较低的抽象层次上，则采用过程 化的方法。
16
实用性：确认该设计对于需求的解 决方案是否实用 技术清晰度：确认该设计是否以一 种易于翻译成代码的形式表达 可维护性：确认该设计是否考虑了 方便未来的维护 质量：确认该设计是否表现出良好 的质量特征
17
各种选择方案：看是否考虑过其 它方案，比较各种选择方案的标 准是什么 限制：评估对该软件的限制是否 现实，是否与需求一致 其它具体问题：对于文档、可测 试性、设计过程..等进行评估
49
公共耦合的复杂程度随耦合模块的个 数增加而显著增加。若只是两模块间 有公共数据环境，则公共耦合有两种 情况。松散公共耦合和紧密公共耦合。
50
内容耦合 (Content Coupling)
如果发生下列情形，两个模块之间 就发生了内一个模块不通过正常入口转 到另一模块内部;
28
④ 在模块A的箭头尾部标以一个菱 形符号，表示模块A有条件地调用 另一个模块B。当一个在调用箭头 尾部标以一个弧形符号，表示模块 A反复调用模块C和模块D。
29
程序的系统结构图
30
模块化
软件系统的模块化是指整个软件被 划分成若干单独命名和可编址的部 分，称之为模块。这些模块可以被 组装起来以满足整个问题的需求。
外部耦合（External Coupling）
一组模块都访问同一全局简单变量而 不是同一全局数据结构，而且不是通 过参数表传递该全局变量的信息，则 称之为外部耦合。
第二章 软件开发模型
2.2 瀑布模型（Waterfall Model） 瀑布模型（ ）
2.2.1 瀑布模型的概念： 瀑布模型的概念：
需求分析
（需求说明书） 需求说明书） （系统设计书） 系统设计书） （程序设计书） 程序设计书） （程序清单） 程序清单）
系统设计
程序设计
编码 测试
（测试报告） 测试报告） （维护报告， 维护报告， 改进的系统 ）
分析定义 系统需求 生成 原型 原型化
运 行 和维护
含原型化的 软件生存期
测试 编码
系统 设计
程序 设计
2.3.3 原型模型的特点
优点： 优点： 开发者与用户充分交流，可以澄清模糊需求， 开发者与用户充分交流，可以澄清模糊需求，需求定义 比其他模型好得多 为用户需求的改变提供了充分的余地 缺点： 缺点： 开发者为了使一个原型快速运行起来， 开发者为了使一个原型快速运行起来，往往在实现过程 中采用折衷的手段。软件系统的组成部分可能会打折扣； 中采用折衷的手段。软件系统的组成部分可能会打折扣； 资源规划和管理较为困难，随时更新文档也带来麻烦。 资源规划和管理较为困难，随时更新文档也带来麻烦。 一般使用场合： 一般使用场合： 开发者在不了解的应用领域开发 客户不清楚其所开发软件项目的最终目标
第二章 软件开发模型
软件开发模型与软件工程 瀑布式模型 原型模型 增量模型 螺旋模型 XP开发模型 XP开发模型 面向对象的开发模型 构件集成模型
2.1 软件开发模型与软件工程
软件开发模型： 软件开发模型： 软件开发模型是软件开发的全部过程、活动、 软件开发模型是软件开发的全部过程、活动、任务和管理 结构框架。 的结构框架。 软件开发模型能清晰、直观地表达软件开发全过程， 明确 软件开发模型能清晰、直观地表达软件开发全过程， 规定了要完成的主要活动和任务， 规定了要完成的主要活动和任务，用来作为软件项目工作 的基础。 的基础。 选择合适的开发模型是十分重要的
第2章 软件开发工具
2.1.3 Visio 2013建模示例
图2-9 Visio绘制系统架构图
2.1.3 Visio 2013建模示例
在项目前期的粗略设计阶段，系统架构图体现软件部件之 间的联系和部件的布局。 Visio也没有提供专门模型来支持系统架构图的绘制，此时 可以借助Visio“基本框图”、“基本流程图”中的部分元 素，进行系统结构图的描述。
2.1.3 Visio 2013建模示例
图2-12 Visio绘制数据流图
2.1.3 Visio 2013建模示例
在需求分析阶段，数据流图是结构化方法下需求模型的主 要构成部分。通常绘制数据流图逐步细化、逐步精化的一 个过程。 Visio提供了专门的“数据流图表”样式，支持系统数据流 图的的描述。
2.2.2 StarUML基本操作
图2-16 StarUML软件界面
2.2.2 StarUML基本操作
图2-17 添加新工程
2.2.2 StarUML基本操作
图2-17 工程选择
2.2.2 StarUML基本操作
图2-18 模型添加
2.2.2 StarUML基本操作
图2-19 通过菜单添加图
2.2.1 StarUML简介
根据图的特点，StarUML把所有的UML图分为五类，包括 用例视、分析视、设计视、实现视和发布视。StarUML只 支持图内部的语法检查，并不支持模型验证和一致性检查， 这表明在各种图内部，工具能够很好地保证模型元素的合 法使用，但不能保证图与图之间的联系是否合法正确。 StarUML的缺陷在于不支持业务建模，当进行管理信息系 统等事务处理软件的时候，可以借助Rational rose进行业 务分析和建模工作。
2.1.1 Visio简介
第2章 UML通用知识点概述
2、图
序 列 图
序列图显示了一个具体用例或者用例的一部分的一个详细流程。它几 乎是自描述的，序列图不仅可以显示了流程中不同对象之间的调用关系， 还可以很详细地显示对不同对象的不同调用。 序列图有两个维度：垂直维度，也称时间维度，以发生的时间顺序显 示消息或调用的序列；水平维度显示消息被发送到的对象实例。
UML统一建模语言
二、常用的UML元素分析
1、视图
活 动 视 图
活动视图是一种特殊形式的状态机视图，是状态机的一个变体，用 来描述执行算法的工作流程中涉及的活动。 通常活动视图用于对计算流程和工作流程建模。活动视图中的状态 表示计算过程中所处的各种状态。 活动视图是在假定整个计算处理的过程中没有外部事件引起的中断 的条件下进行描述的，否则普通的状态机更加适合于描述这种情况。
UML统一建模语言
二、常用的UML元素分析
2、图
用 例 图
用例图描述了系统提供的一 个功能单元。用例图的主要目的 是帮助开发团队以一种可视化的 方式理解系统的功能需求，包括 基于基本流程的“角色”关系， 以及系统内用例之间的关系。 使用用例图可以表示出用例 的组织关系，这种组织关系包括 整个系统的全部用例或者是完成 相关功能的一组用例。 在用例图中画出某个用例方 式是在用例图中绘制一个椭圆， 然后将用例的名称放在椭圆的中 心或椭圆下面的中间位置。
三、UML的通用机制
2、修饰
在UML的图形表示中，每一个模型元素都有一个基本符号，这个基本 符号可视化地表达了模型元素最重要的信息。 用户也可以把各种修饰细节加到这个符号上以扩展其含义。这种添加 修饰细节的做法可以为图中的模型元素在一些视觉上的效果上发生一些 变化。
UML统一建模语言
三、UML的通用机制
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
说明：需求来源于问题域，需求的目的是把问题域中的“问题”提 炼成系统责任，用例图就是描述系统责任的良好工具。
• 问题域：指被开发系统的应用领域，即在现实世界中这个系统所 涉及的业务范围。
• 系统责任：指被开发系统应该具备的职能。即在计算机世界中这 个系统所涉及的业务范围。
3.它是由软件需求到最终实现的第一步，它驱动了需求分析之后 的各阶段的开发工作；
其参与者和用例图形元素为：
§2．4 用例与事件流
用例的事件流：指对一个用例的具体细节的描述文档 事件流通常包括： 1.简要说明：简要描述该用例的作用和目标（用例要
达到的结果） 2.前置条件：列出用例之前必须满足的条件（如：前
驱用例或运行权限） 注意：并不是所有用例都有前置条件。 3.主事件流和其他事件流：描述用例的工作流程的事 件流。 包括：用例是怎样开始的； 用例是怎样结束的； 用例如何与参与者交互； 用例的主流程； 用例的非正常流程（其他事件流）； 用例所需要的数据；
例2：
为系统的需求建模
<<extend>>
Librarian (工作人员)
ReturnBook (还书)
<<include>>
IssueFind (交纳罚金)
BorrowBook (借书)
CheckUserInfo (检 查 用 户 合 法 性 )
<<include>>
Borrower (读者)
<<include>>
⑵ 某一个用例的功能过多、事件流过于复杂时可以把某一段事件 流抽象成为一个被包含的用例（提供者），以达到简化描述的 目的。 例如：
Query (查询)
<<include>>
<<include>>
QueryBorrows (查询借阅情况)
QueryBooks (查询图书)
4．扩展关系（Extend） 是把可选的、只在特定条件下运行的行为插入到已有用
4. 后置条件：是用例执行完毕后必须满足的条件（如，使一个标 记为‘真’）
注意：并不是所有用例都有后置条件 说明:事件流的“描述”位置可以放在用例的Specification (规格
说明/属性)对话框General(综合) 页面的Documentation (文档)处
§2．5 用例间的关系
1.关联关系（Association relationship） 是一种结构+语义（动态行为）关系，表示一个事物的
控制之外。 (2)参与者直接同系统交互，这可以帮助定义系统边界 (3)参与者表示人和事物与系统发生交互时所扮演的角
色，而不是特定的人或特定的事物。 (4) 一个人或事物在与系统发生交互时，可以同时或不
同时扮演多个角色。 (5) 每一个参与者需要有一个具有业务一样的名字。 (6) 每个参与者必须有简短的描述，从业务角度描述参
例的方法。 其中：前者被称为“扩展”用例 后者被称为“基础”用例 扩展关系用原型为<<extend>>的依赖关系来表示，其
图形表示如下：
<<extend>>
Extension point OverdueBook
基础用例
扩展用例
<<extend>>
Librarian (工作人员)
ReturnBook (还书)
如图：
Relationship
Actor
UseCase
6.用例图中也可以有注释和约束，还可以有包(Package)
§2. 2 参与者（Actor） 参与者 (Actor) 是指系统以外的，需要使用系统或与 系
统交互的实体（如：人、设备、外部系统等） UML中参与者的表示形式：
ActorName
说明： 1.在构造用例图时，为获取“用例”，首先要确定系统的
成为一个用例，然后让其他用例来包含这个用例。 例如：
客户
Librarian (工作人员)
CreateAccount <<include>> (建立账户)
<<include>>
提供者
ModifyAccount
QueryAccount
(修改账户)
( 查询账户)
<<include>>
DeleteAccount (删除账户)
例1：
Librarian (工作人员)
Borrower (读者)
Teacher Student (教师) (学生)
为系统的上下文建模
|—— Lib—ra—ry—inf—or—ma—tio—n—sy—ste—m——|
|
|
|
|
|
|
|
ReturnBook
|
|
(还书)
|
|
|
|
|
|
|
| | |
BorrowBook (借书)
统中的信息吗? (3) 什么用例会创建、存储、改变、删除、或读取这个
信息？ (4) 参与者需要通知系统外部的突然变化吗? (5) 需要通知参与者系统中正在发生的事情吗? (6) 什么用例将支持和维护系统?
例：某图书馆开发一个图书管理系统，该系统要求实现下列功能： (1) 读者查询（直接通过外部终端进行） 读者查询图书，通过书的种类、出版社、书名、作者等方式查询；
(3) 读者还书（通过工作人员） 根据图书证号、图书号，从“借阅图书文件”中读出该图书相关 的记录（判断是否超期，如果超期则按相应标准收取罚金），登记 还书信息（日期等）, 且将所还书的所有信息存入“借阅历史档案” 中，然后从“借阅图书文件”中注销该图书借阅信息 (4) 管理维护系统（系统管理员通过后台终端），包括：增、减或 更新图书数据；增、减或更新读者账户信息。
把它所包含的行为作为自身行为的一部分。 其中：包含用例称为“客户”用例 被包含用例称为“提供者”用例
包含关系用原型为<<include>>的依赖关系来表示。
其图形表示如下：
<<include> >
如：
<<include>>
客户
提供者
说明：主要有两种情况需要用到包含关系 ⑴ 多个用例用到同一段行为，则可以把这段共同的行为单独抽象
参与者（Actor），可以根据以下问题来寻找系统的 参与者：
(1) 谁是系统的主要用户？ (4) 谁管理、维护系统？ (2) 谁从该系统获得信息？ (5) 与该系统交互的是什么系统？ (3) 谁向系统提供信息？ (6) 系统从那里获得信息？
2.在确定“参与者”过程中，记住以下要点。 (1)参与者对于系统而言总是外部的，因此它们在你的
Login (登录)
SQeuaerrcyh
(查询询))
CheckBorrowInfo (检 查 借 阅 权 限 )
RegisterBorrower
(注册读者)
<<include>>
UpdateBorrower (更新读者)
MaintainBorrower (维护读者)
<<include>>
Administrator (管理员)
对象与另一个事物的对象间的特定的联系（链接）。 例如：教师和学生：存在“老师教学生”关联 员工和公司：存在“员工受聘于公司”关联 用户和软件：存在“用户使用软件”关联
工作人员和读者：存在“业务员为读者办理业务”关 联
注意：参与者（Actor）同用例（Use case）之间的 关系是关联关系（主要体现在“行为”上）。
关联包括双向关联和单向关联，其图形表示分别如下：
例如：
Librarian (工作人员)
Borrower (读者)
LendBook (借书)
ReturnBook (还书)
Search (查询)
2.泛化关系（Generalization） 是一种结构关系，描述一般到特殊之间的关系（继承
关系） 例如：学生和研究生、本科生 泛化关系，其图形表示如下：
读者查询借阅图书情况，通过姓名和图书证号等方式查询。 (2) 读者借书（通过工作人员） 读者凭图书证(书卡)借书。系统首先检查该读者(图书证号)是否有
效，若无效，则拒绝借书；否则进一步检查该读者所借图书是否达 到限额数，若达到限额数，则拒绝借书，否则读者可以借书.把图书 证号、图书号、借书日期和还书日期等登记在借阅图书文件中
4.它是描述系统的动态模型，即是5个UML动态视图之一; 其中,5个UML动态视图是: “用例图”、“状态图”、“活动图”、“时序图”、“协作图”
5．它描述了一组用例、参与者以及它们之间的关系，因此用例图 包括以下3方面内容： (1) 用例（Use case） (2) 参与者（Actor） (3) 关系（Relationship ） •关联关系（Association ） •泛化关系（Generalization ） •依赖关系（Dependence ）
第2章 用例图
§2.1 用例图（Use-Case Diagram）
用例图是参与者（Actor）所能观察到的描述系统功能视图，它 通过用例（Use-Case）来捕获系统的需求。 其中：
1.用例图描述了待开发系统的功能需求，是软件产品外部特性描 述的视图；
2.用例图是从用户的角度而不是从开发者的角度描述软件产品的 需求，分析产品所需的功能和动态行为；
在为系统的需求建模时应考虑： （1）确定系统外部的参与者，从而建立系统的上下文 （2）考虑每个参与者所期望的或要求系统提供的行为 （3）把公共行为命名为用例 （4）确定被其他用例使用的用例或用来扩展其他用例
• 问题域：指被开发系统的应用领域，即在现实世界中这个系统所 涉及的业务范围。
• 系统责任：指被开发系统应该具备的职能。即在计算机世界中这 个系统所涉及的业务范围。
3.它是由软件需求到最终实现的第一步，它驱动了需求分析之后 的各阶段的开发工作；
其参与者和用例图形元素为：
§2．4 用例与事件流
用例的事件流：指对一个用例的具体细节的描述文档 事件流通常包括： 1.简要说明：简要描述该用例的作用和目标（用例要
达到的结果） 2.前置条件：列出用例之前必须满足的条件（如：前
驱用例或运行权限） 注意：并不是所有用例都有前置条件。 3.主事件流和其他事件流：描述用例的工作流程的事 件流。 包括：用例是怎样开始的； 用例是怎样结束的； 用例如何与参与者交互； 用例的主流程； 用例的非正常流程（其他事件流）； 用例所需要的数据；
例2：
为系统的需求建模
<<extend>>
Librarian (工作人员)
ReturnBook (还书)
<<include>>
IssueFind (交纳罚金)
BorrowBook (借书)
CheckUserInfo (检 查 用 户 合 法 性 )
<<include>>
Borrower (读者)
<<include>>
⑵ 某一个用例的功能过多、事件流过于复杂时可以把某一段事件 流抽象成为一个被包含的用例（提供者），以达到简化描述的 目的。 例如：
Query (查询)
<<include>>
<<include>>
QueryBorrows (查询借阅情况)
QueryBooks (查询图书)
4．扩展关系（Extend） 是把可选的、只在特定条件下运行的行为插入到已有用
4. 后置条件：是用例执行完毕后必须满足的条件（如，使一个标 记为‘真’）
注意：并不是所有用例都有后置条件 说明:事件流的“描述”位置可以放在用例的Specification (规格
说明/属性)对话框General(综合) 页面的Documentation (文档)处
§2．5 用例间的关系
1.关联关系（Association relationship） 是一种结构+语义（动态行为）关系，表示一个事物的
控制之外。 (2)参与者直接同系统交互，这可以帮助定义系统边界 (3)参与者表示人和事物与系统发生交互时所扮演的角
色，而不是特定的人或特定的事物。 (4) 一个人或事物在与系统发生交互时，可以同时或不
同时扮演多个角色。 (5) 每一个参与者需要有一个具有业务一样的名字。 (6) 每个参与者必须有简短的描述，从业务角度描述参
例的方法。 其中：前者被称为“扩展”用例 后者被称为“基础”用例 扩展关系用原型为<<extend>>的依赖关系来表示，其
图形表示如下：
<<extend>>
Extension point OverdueBook
基础用例
扩展用例
<<extend>>
Librarian (工作人员)
ReturnBook (还书)
如图：
Relationship
Actor
UseCase
6.用例图中也可以有注释和约束，还可以有包(Package)
§2. 2 参与者（Actor） 参与者 (Actor) 是指系统以外的，需要使用系统或与 系
统交互的实体（如：人、设备、外部系统等） UML中参与者的表示形式：
ActorName
说明： 1.在构造用例图时，为获取“用例”，首先要确定系统的
成为一个用例，然后让其他用例来包含这个用例。 例如：
客户
Librarian (工作人员)
CreateAccount <<include>> (建立账户)
<<include>>
提供者
ModifyAccount
QueryAccount
(修改账户)
( 查询账户)
<<include>>
DeleteAccount (删除账户)
例1：
Librarian (工作人员)
Borrower (读者)
Teacher Student (教师) (学生)
为系统的上下文建模
|—— Lib—ra—ry—inf—or—ma—tio—n—sy—ste—m——|
|
|
|
|
|
|
|
ReturnBook
|
|
(还书)
|
|
|
|
|
|
|
| | |
BorrowBook (借书)
统中的信息吗? (3) 什么用例会创建、存储、改变、删除、或读取这个
信息？ (4) 参与者需要通知系统外部的突然变化吗? (5) 需要通知参与者系统中正在发生的事情吗? (6) 什么用例将支持和维护系统?
例：某图书馆开发一个图书管理系统，该系统要求实现下列功能： (1) 读者查询（直接通过外部终端进行） 读者查询图书，通过书的种类、出版社、书名、作者等方式查询；
(3) 读者还书（通过工作人员） 根据图书证号、图书号，从“借阅图书文件”中读出该图书相关 的记录（判断是否超期，如果超期则按相应标准收取罚金），登记 还书信息（日期等）, 且将所还书的所有信息存入“借阅历史档案” 中，然后从“借阅图书文件”中注销该图书借阅信息 (4) 管理维护系统（系统管理员通过后台终端），包括：增、减或 更新图书数据；增、减或更新读者账户信息。
把它所包含的行为作为自身行为的一部分。 其中：包含用例称为“客户”用例 被包含用例称为“提供者”用例
包含关系用原型为<<include>>的依赖关系来表示。
其图形表示如下：
<<include> >
如：
<<include>>
客户
提供者
说明：主要有两种情况需要用到包含关系 ⑴ 多个用例用到同一段行为，则可以把这段共同的行为单独抽象
参与者（Actor），可以根据以下问题来寻找系统的 参与者：
(1) 谁是系统的主要用户？ (4) 谁管理、维护系统？ (2) 谁从该系统获得信息？ (5) 与该系统交互的是什么系统？ (3) 谁向系统提供信息？ (6) 系统从那里获得信息？
2.在确定“参与者”过程中，记住以下要点。 (1)参与者对于系统而言总是外部的，因此它们在你的
Login (登录)
SQeuaerrcyh
(查询询))
CheckBorrowInfo (检 查 借 阅 权 限 )
RegisterBorrower
(注册读者)
<<include>>
UpdateBorrower (更新读者)
MaintainBorrower (维护读者)
<<include>>
Administrator (管理员)
对象与另一个事物的对象间的特定的联系（链接）。 例如：教师和学生：存在“老师教学生”关联 员工和公司：存在“员工受聘于公司”关联 用户和软件：存在“用户使用软件”关联
工作人员和读者：存在“业务员为读者办理业务”关 联
注意：参与者（Actor）同用例（Use case）之间的 关系是关联关系（主要体现在“行为”上）。
关联包括双向关联和单向关联，其图形表示分别如下：
例如：
Librarian (工作人员)
Borrower (读者)
LendBook (借书)
ReturnBook (还书)
Search (查询)
2.泛化关系（Generalization） 是一种结构关系，描述一般到特殊之间的关系（继承
关系） 例如：学生和研究生、本科生 泛化关系，其图形表示如下：
读者查询借阅图书情况，通过姓名和图书证号等方式查询。 (2) 读者借书（通过工作人员） 读者凭图书证(书卡)借书。系统首先检查该读者(图书证号)是否有
效，若无效，则拒绝借书；否则进一步检查该读者所借图书是否达 到限额数，若达到限额数，则拒绝借书，否则读者可以借书.把图书 证号、图书号、借书日期和还书日期等登记在借阅图书文件中
4.它是描述系统的动态模型，即是5个UML动态视图之一; 其中,5个UML动态视图是: “用例图”、“状态图”、“活动图”、“时序图”、“协作图”
5．它描述了一组用例、参与者以及它们之间的关系，因此用例图 包括以下3方面内容： (1) 用例（Use case） (2) 参与者（Actor） (3) 关系（Relationship ） •关联关系（Association ） •泛化关系（Generalization ） •依赖关系（Dependence ）
第2章 用例图
§2.1 用例图（Use-Case Diagram）
用例图是参与者（Actor）所能观察到的描述系统功能视图，它 通过用例（Use-Case）来捕获系统的需求。 其中：
1.用例图描述了待开发系统的功能需求，是软件产品外部特性描 述的视图；
2.用例图是从用户的角度而不是从开发者的角度描述软件产品的 需求，分析产品所需的功能和动态行为；
在为系统的需求建模时应考虑： （1）确定系统外部的参与者，从而建立系统的上下文 （2）考虑每个参与者所期望的或要求系统提供的行为 （3）把公共行为命名为用例 （4）确定被其他用例使用的用例或用来扩展其他用例