软件工程第8章
合集下载
(软件工程理论、方法与实践)第8章分布式系统体系结构
代理具有自治性，可以独立于其他代理进行操作，并能够与其他代理进行协调。基于代理的设计方法强调动态性 和灵活性，适用于构建可扩展、可重构和自适应的分布式系统。
基于服务的架构设计方法
总结词
基于服务的架构设计方法是一种以服务为中心的设计方法，通过将系统功能封装为可复用的服务，实 现松耦合的分布式系统。
详细描述
01
02
分布式性
组件分布在不同的物理节点上，可以 位于不同的地理位置。
03
通信能力
组件之间通过通信进行协调和交互。
可靠性
分布式系统具有容错性和可恢复性， 能够保证系统的可靠运行。
05
04
并发性
多个组件可以并行执行，提高系统的 整体性能。
分布式系统的应用场景
云计算平台
如亚马逊AWS、谷歌云等，提供计算、存储、网络等 服务。
总结词
基于代理的分布式系统通过使用智能 代理来处理分布式任务，具有自治性、 智能性和协作性等特点。
详细描述
基于代理的分布式系统案例包括：1. 分布式 计算市场案例，如网格计算和云计算平台， 通过智能代理实现资源的共享和交易；2. 智 能家居案例，通过智能代理实现家庭设备的 互联和控制，提高生活便利性。
运维
分布式系统的运维需要关注系统的运行状态 和性能，以及服务的可用性和可靠性。这需
要使用一些监控工具和技术，如 Prometheus、Grafana等，以便及时发现 和处理系统中的问题。同时，还需要建立完 善的运维流程和规范，以确保系统的高可用
性和高可靠性。
05
分布式系统案例分析
基于代理的分布式系统案例
测试方法
对于分布式系统的测试，需要采用一些特定 的方法，如模拟测试、灰度测试、故障注入 测试等。这些方法可以帮助开发人员模拟各 种实际运行场景，以便更好地发现和修复系 统中的问题。
基于服务的架构设计方法
总结词
基于服务的架构设计方法是一种以服务为中心的设计方法，通过将系统功能封装为可复用的服务，实 现松耦合的分布式系统。
详细描述
01
02
分布式性
组件分布在不同的物理节点上，可以 位于不同的地理位置。
03
通信能力
组件之间通过通信进行协调和交互。
可靠性
分布式系统具有容错性和可恢复性， 能够保证系统的可靠运行。
05
04
并发性
多个组件可以并行执行，提高系统的 整体性能。
分布式系统的应用场景
云计算平台
如亚马逊AWS、谷歌云等，提供计算、存储、网络等 服务。
总结词
基于代理的分布式系统通过使用智能 代理来处理分布式任务，具有自治性、 智能性和协作性等特点。
详细描述
基于代理的分布式系统案例包括：1. 分布式 计算市场案例，如网格计算和云计算平台， 通过智能代理实现资源的共享和交易；2. 智 能家居案例，通过智能代理实现家庭设备的 互联和控制，提高生活便利性。
运维
分布式系统的运维需要关注系统的运行状态 和性能，以及服务的可用性和可靠性。这需
要使用一些监控工具和技术，如 Prometheus、Grafana等，以便及时发现 和处理系统中的问题。同时，还需要建立完 善的运维流程和规范，以确保系统的高可用
性和高可靠性。
05
分布式系统案例分析
基于代理的分布式系统案例
测试方法
对于分布式系统的测试，需要采用一些特定 的方法，如模拟测试、灰度测试、故障注入 测试等。这些方法可以帮助开发人员模拟各 种实际运行场景，以便更好地发现和修复系 统中的问题。
软件工程 第八章 面向对象的设计方法
第八章面向对象的设计方法本章采用基于UML的面向对象设计方法的将分析模型转换为设计模型。
如第五章所述，面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。
为完成这一转换过程，设计人员必须处理以下任务：（1）针对分析模型中的用例，设计实现方案。
实现方案用UML交互图表示。
（2）设计技术支撑设施。
在大型软件项目中，往往需要一些技术支撑设施来帮助业务需求层面的类或子系统完成其功能。
这些设施本身并非业务需求的一部分，但却为多种业务需求的实现提供公共服务。
例如，数据的持久存储服务、安全控制服务和远程访问服务等。
在面向对象设计中，需要研究这些技术支撑设施的实现方式以及它们与业务需求层面的类及子系统之间的关系。
（3）设计用户界面。
（4）针对分析模型中的领域概念模型以及第（2）、（3）两个步骤引进的新类，完整、精确地确定每个类的属性和操作，并完整地标示类之间的关系。
此外，为了实现软件重用和强内聚、松耦合等软件设计原则，还可以对前面形成的类图进行各种微调，最终形成足以构成面向对象程序设计的基础和依据的详尽类图。
面向对象的软件设计过程如图8-1-1所示。
图8-1-1 面向对象的软件设计过程第一节设计用例实现方案UML 的交互图（顺序图、协作图）适于用例实现方案的表示。
因此，本节首先介绍交互图的语言机制，然后探讨用例实现方案的设计方法。
该设计方法包含如下3个步骤：（1）提取边界类、实体类和控制类；（2）构造交互图；（3）根据交互图精华类图。
一、顺序图顺序图用来描述对象之间动态的交互关系，着重表现对象间消息传递的时间顺序。
在顺序图中，参与交互的对象位于顶端的水平轴上，垂直轴表示时间，时间推移的方向是自上而下的。
顺序图中的对象一般以“对象名：类名”的方式标识，但也可以仅采用缩写形式“对象名”或者“：类名”。
软件工程课件之第8章维护第6版张海潘编著
(1) 必须描述如何使用这个系统，没有这种描述时即 使是最简单的系统也无法使用； (2) 必须描述怎样安装和管理这个系统； (3) 必须描述系统需求和设计； (4) 必须描述系统的实现和测试，以便使系统成为可 维护的。
用户文档
用户文档至少应该包括下述5方面的内容：
功能描述，说明系统能做什么； 安装文档，说明怎样安装这个系统以及怎样使系统
软件维护过程
维护报告
维护要求表或称软件问题报告表，由申请维 护的用户填写。
软件修改报告，由软件组织内部制定，指明：
满足某个维护要求表中提出的要求所需要的工 作量；
维护要求的性质； 这项要求的优先级； 与修改有关的事后数据；
维护的事件流
维护的事件流
尽管维护申请的类型不同，但都要进行同样 的技术工作：
系统文档
所谓系统文档指从问题定义、需求说明到验收 测试计划这样一系列和系统实现有关的文档。
描述系统设计、实现和测试的文档对于理解程 序和维护程序极端重要
从概貌到每个方面每个特点，从抽象到具体， 有逻辑地介绍系统
可维护性复审
在需求分析阶段的复审过程中，应该对将来要 改进的部分和可能会修改的部分加以注意并指 明；应该讨论软件的可移植性问题，并且考虑 可能影响软件维护的系统界面。
维护的问题
与软件维护有关的绝大多数问题，都可归 因于软件定义和软件开发的方法有缺点：
① 理解别人写的程序通常非常困难，而且困难程 度随着软件配置成分的减少而迅速增加。
② 需要维护的软件往往没有合格的文档，或者文 档资料显著不足。
③ 当要求对软件进行维护时，不能指望由开发人 员给我们仔细说明软件。
的。
软件维护工作量
各类维护工作量 所占比例
维护工作量在软件生 命周期所占比例
用户文档
用户文档至少应该包括下述5方面的内容：
功能描述，说明系统能做什么； 安装文档，说明怎样安装这个系统以及怎样使系统
软件维护过程
维护报告
维护要求表或称软件问题报告表，由申请维 护的用户填写。
软件修改报告，由软件组织内部制定，指明：
满足某个维护要求表中提出的要求所需要的工 作量；
维护要求的性质； 这项要求的优先级； 与修改有关的事后数据；
维护的事件流
维护的事件流
尽管维护申请的类型不同，但都要进行同样 的技术工作：
系统文档
所谓系统文档指从问题定义、需求说明到验收 测试计划这样一系列和系统实现有关的文档。
描述系统设计、实现和测试的文档对于理解程 序和维护程序极端重要
从概貌到每个方面每个特点，从抽象到具体， 有逻辑地介绍系统
可维护性复审
在需求分析阶段的复审过程中，应该对将来要 改进的部分和可能会修改的部分加以注意并指 明；应该讨论软件的可移植性问题，并且考虑 可能影响软件维护的系统界面。
维护的问题
与软件维护有关的绝大多数问题，都可归 因于软件定义和软件开发的方法有缺点：
① 理解别人写的程序通常非常困难，而且困难程 度随着软件配置成分的减少而迅速增加。
② 需要维护的软件往往没有合格的文档，或者文 档资料显著不足。
③ 当要求对软件进行维护时，不能指望由开发人 员给我们仔细说明软件。
的。
软件维护工作量
各类维护工作量 所占比例
维护工作量在软件生 命周期所占比例
第8章 软件维护
系统年龄： – 老系统随着不断的修改，结构越来越乱； – 维护人员经常更换，程序又变得越来越难于理解 – 许多老系统在当初并未按照软件工程的要求进行 开发，因而没有文档，或文档太少。 – 在长期的维护过程中文档在许多地方与程序实现 变得不一致，在维护时就会遇到很大困难。 数据库技术的应用：使用数据库，可以简单而有效 地管理和存储用户程序中的数据，还可以减少生成 用户报表应用软件的维护工作量。
24
8.4
软件的可维护性
许多软件的维护十分困难，原因在于这些软件 的文档不全、质量差、开发过程不注意采用好 的方法，忽视程序设计风格等。 许多维护要求并不是因为程序中出错而提出的， 而是为适应环境变化或需求变化而提出的。 为了使得软件能够易于维护，必须考虑使软件 具有可维护性。 软件可维护性是指纠正软件系统出现的错误和
14
1、维护机构 除了较大的软件开发公司外， 通常在软件维护工作方面，并 不保持一个正式的组织机构。 虽然不要求建立一个正式的维 护机构，但是在开发部门确立 一个非正式的维护机构则是非 常必要的。
15
每个维护要求都通过维护管理员转交给相应的系 统管理员去评价（系统管理员是被指定去熟悉一 小部分产品程序的技术人员）。 系统管理员对维护任务做出评价之后，由变化授 权人决定应该进行的活动。 16
缺陷，以及为满足新的要求进行修改、扩充或 压缩的难易程度。
25
8.4.1 决定软件可维护性的因素
1. 可理解性 2. 可测试性 3. 可修改性 4. 可移植性 5. 可重用性
26
1. 可理解性 软件可理解性表现为外来读者理解软件的结构、 功能、接口和内部处理过程的难易程度。模块化 （模块结构良好，高内聚，松耦合）、详细的设 计文档、结构化设计、程序内部的文档和良好的 高级程序设计语言等等，都对提高软件的可理解 性有重要贡献。 2. 可测试性 诊断和测试的容易程度取决于软件容易理解的程 度。良好的文档对诊断和测试是至关重要的，此 外，软件结构、可用的测试工具和调试工具，以 及以前设计的测试过程也都是非常重要的。维护 人员应该能够得到在开发阶段用过的测试方案， 以便进行回归测试。在设计阶段应该尽力把软件 设计成容易测试和容易诊断的。 对于程序模块来说，可以用程序复杂度来度量它 的可测试性。模块的环形复杂度越大，可执行的 路径就越多，因此，全面测试它的难度就越高。
软件工程导论课件第8章
33
5. 数据重构 对数据体系结构差的程序很难进行适应性和 完善性维护，因此，数据体系结构比源代码对程序 的长期生存力有更大影响。 数据重构是一种全范围的再工程活动。由于 数据重构对程序体系结构及程序中的算法有很大影 响，对数据的修改必然会导致程序体系结构或代码 层的改变。
3
2.适应性维护 为适应变化了的环境界面而修改软件的活动， 称为适应性维护。包括： （1）因硬件或支撑软件改变引起的变化； （2）将软件移植到新的机种上运行； （3）因数据环境的变化而做的变更。 这类维护大约占软件维护总工作量的25％。
4
3.完善性维护 为了满足用户要求，就得对软件进行修改和 扩充，我们称这种维护为完善性维护。完善性维护 主要包括： （1）提高处理效率； （2）提高性能。 在整个维护工作中， 完善性维护大约占50％ 左右，区居第一位。
3. 逆向工程 软件的逆向工程是，分析程序以便在比源代码 更高的抽象层次上创建出程序的某种描述的过程， 也就是说，逆向工程是一个恢复设计结果的过程。 4. 代码重构 某些老程序的体系结构比较合理，但是，一些 模块的编码方式却是难于理解、测试和维护的。在 这种情况下，可以重构这些模块的代码。 通常，代码重构并不修改程序的体系结构，它 只关注个体模块的设计细节以及在模块中定义的局 部数据结构。如果重构扩展到模块边界以外并涉及 软件体系结构，则重构变成了正向工程。
13
（四）软件维护过程 维护过程的实质是对软件定义和开发过程的修 改和压缩。维护过程的主要任务是：建立维护机构， 填写维护报告和评价，为每个维护要求规定一种规 范化的处理序列，建立对维护活动的登记制度及规 定评价复审的标准。 1.维护组织 机构中有一名维护管理员总负责，每项维护要 求都通过维护管理员转交给相应的系统管理员去评 价。系统管理员对维护任务做出评价之后，由变化 授权人决定应该进行的活动，最后由系统管理员去 执行维护任务。
5. 数据重构 对数据体系结构差的程序很难进行适应性和 完善性维护，因此，数据体系结构比源代码对程序 的长期生存力有更大影响。 数据重构是一种全范围的再工程活动。由于 数据重构对程序体系结构及程序中的算法有很大影 响，对数据的修改必然会导致程序体系结构或代码 层的改变。
3
2.适应性维护 为适应变化了的环境界面而修改软件的活动， 称为适应性维护。包括： （1）因硬件或支撑软件改变引起的变化； （2）将软件移植到新的机种上运行； （3）因数据环境的变化而做的变更。 这类维护大约占软件维护总工作量的25％。
4
3.完善性维护 为了满足用户要求，就得对软件进行修改和 扩充，我们称这种维护为完善性维护。完善性维护 主要包括： （1）提高处理效率； （2）提高性能。 在整个维护工作中， 完善性维护大约占50％ 左右，区居第一位。
3. 逆向工程 软件的逆向工程是，分析程序以便在比源代码 更高的抽象层次上创建出程序的某种描述的过程， 也就是说，逆向工程是一个恢复设计结果的过程。 4. 代码重构 某些老程序的体系结构比较合理，但是，一些 模块的编码方式却是难于理解、测试和维护的。在 这种情况下，可以重构这些模块的代码。 通常，代码重构并不修改程序的体系结构，它 只关注个体模块的设计细节以及在模块中定义的局 部数据结构。如果重构扩展到模块边界以外并涉及 软件体系结构，则重构变成了正向工程。
13
（四）软件维护过程 维护过程的实质是对软件定义和开发过程的修 改和压缩。维护过程的主要任务是：建立维护机构， 填写维护报告和评价，为每个维护要求规定一种规 范化的处理序列，建立对维护活动的登记制度及规 定评价复审的标准。 1.维护组织 机构中有一名维护管理员总负责，每项维护要 求都通过维护管理员转交给相应的系统管理员去评 价。系统管理员对维护任务做出评价之后，由变化 授权人决定应该进行的活动，最后由系统管理员去 执行维护任务。
软件工程 第8章 软件维护
8.4.2 软件可维护性的度量
3. 可测试性 4. 可修改性 5. 可移植性 6. 效率 7. 可使用性 8. 间接度量可维护性的方法
8.4.2 软件可维护性的度量
8. 间接度量可维护性的方法
(1) 了解问题的时间； (2) 行政管理拖延的时间； (3) 收集维护工具的时间； (4) 分析问题的时间； (5) 改变规格说明的时间； (6) 具体的改错或修改的时间； (7) 局部测试时间； (8) 整体测试时间； (9) 维护重审时间； (10) 总体恢复时间。
8.4 软件的可维护性
8.4.1 影响可维护性的因素 软件的可维护性可以简单定义为：纠正软件系统出现 的错误和缺陷,以满足新的要求, 能够被理解、被校正、 被修改或被改善的难易程度。可维护性不但与采用的 分析设计方法和开发人员的技术熟练程度有关，更重 要的是与软件项目的管理技术关系密切。软件的可维 护性成为软件开发阶段各个时期的关键目标。
8.1 软件维护的种类
完善性维护 50％
预防性维护5％
改正性维护 20％
适应性维护 25％
图11.1 各类维护的比重
8.2 软件维护的特点
8.2.1 软件维护面临的困难 统计资料表明，有代表性的软件开发组织用于校正性 维护、适应性维护、完善性维护及预防性维护的费用 占其开发总金额的70％至80％。 很多软件机构被束缚在维护工作上，这是软件维护所 带来的无形支出。
8.2.3 非结构化维护
无说明或者文档资料太少由于没有采用定义良好的软 件项目管理过程来开发软件，软件项目管理的缺陷导 致的叫“非结构化维护”,这会使软件维护付出较高的 代价.
8.2.4 结构化维护
存在完整的软件系列文档，那么维护任务就从分析设 计文件开始，确定软件的重要结构特性、功能特性和 接口特性，确定所要求的修改或校正可能产生的影响， 并且计划采用何种维护处理方法，修改设计并进行复 审，编制出新的源程序，利用文档中的信息进行回归 测试，然后重新交付软件。这种维护过程就叫做“结 构化维护”
软件工程第8章详细设计
stop
WHILE Q
F
G N
例2:以下是两个程序流程图，试用PAD图表示。
开始 在工资档案中读一条记录
是文件结束位置吗?Y
N 计 算 工 资 档 案 各 项 基 本 数 据 之 和 并 存 入 pay
num ＝ 当 前 职 工 号
在 奖 金 发 放 表 中 查 找 职 工 号 与 num 相 同 的 记 录
五种基本控制结构：
示例
程序流程图的规定符号
1）顺序型结构 顺序结构由带箭头的控制线依次连接几个处理方框构成。
处理1 处理2 处理n
…
例题
2） 选择型结构 选择型结构是流程图中最为常用的结构，其结构构造有两种，一种是条件选择结构又称为IF-
THEN-ELSE结构，使用菱形表现逻辑判定条件，条件结果决定选择两个处理方框中的一个。
种条件组合相对应的动作。
所有条件
条件组合矩阵
所有可能的 动作列表
与每种条件组合 所对应的动作表
国内乘客 头等舱 残疾乘客 行李≤30kg
免费 (W-30)*2 (W-30)*3 (W-30)*4 (W-30)*6 (W-30)*8 (W-30)*12
TTTTFFFF
TFTFTFTF
FFTTFFTT
TF F F F F F F F
找到了吗?
N
显示错误
Y 计 算 各 项 奖 金 总 和 并 存 入 bonus
应 发 工 资 ＝ pay＋ bonus
读下一条记录
结束
在工资档案中读一条记录
是文件结束位置吗?
计 算 工 资 各 项 基 本 数 据 之 和 并 存 入 pay
num ＝ 当 前 职 工 号
在 奖 金 表 中 查 职 工 号 与 num 相 同 的 记 录
WHILE Q
F
G N
例2:以下是两个程序流程图，试用PAD图表示。
开始 在工资档案中读一条记录
是文件结束位置吗?Y
N 计 算 工 资 档 案 各 项 基 本 数 据 之 和 并 存 入 pay
num ＝ 当 前 职 工 号
在 奖 金 发 放 表 中 查 找 职 工 号 与 num 相 同 的 记 录
五种基本控制结构：
示例
程序流程图的规定符号
1）顺序型结构 顺序结构由带箭头的控制线依次连接几个处理方框构成。
处理1 处理2 处理n
…
例题
2） 选择型结构 选择型结构是流程图中最为常用的结构，其结构构造有两种，一种是条件选择结构又称为IF-
THEN-ELSE结构，使用菱形表现逻辑判定条件，条件结果决定选择两个处理方框中的一个。
种条件组合相对应的动作。
所有条件
条件组合矩阵
所有可能的 动作列表
与每种条件组合 所对应的动作表
国内乘客 头等舱 残疾乘客 行李≤30kg
免费 (W-30)*2 (W-30)*3 (W-30)*4 (W-30)*6 (W-30)*8 (W-30)*12
TTTTFFFF
TFTFTFTF
FFTTFFTT
TF F F F F F F F
找到了吗?
N
显示错误
Y 计 算 各 项 奖 金 总 和 并 存 入 bonus
应 发 工 资 ＝ pay＋ bonus
读下一条记录
结束
在工资档案中读一条记录
是文件结束位置吗?
计 算 工 资 各 项 基 本 数 据 之 和 并 存 入 pay
num ＝ 当 前 职 工 号
在 奖 金 表 中 查 职 工 号 与 num 相 同 的 记 录
第8章软件维护
软件维护步骤
4、修改程序的副作用
副作用是指因修改软件而造成的错误或其它不希望发生的情况。 1）编码副作用：在使用程序设计语言修改源代码时可能引起的错误， 如删除或修改一个标号、标识符、一个子程序，改变程序代码的时序关系， 改变逻辑运算符，改进程序的执行效率，改变程序占用存储的大小等，都 很容易引入错误，应特别小心。 2）数据副作用：在修改数据结构时，有可能造成软件设计和数据结构 的不一致，而导致软件错误。数据副作用是修改软件信息结构引起的，如 重新定义全局或局部常量，重新初始化控制标志或指针等，都容易产生设 计与数据不相容的错误，可通过详细设计文档对数据副作用加以控制。 3）文档副作用：对数据流、软件结构、逻辑模块等进行修改时，必须 对相关技术文档进行修改，否则会导致 文档与程序功能不匹配，使文档不 能反映软件当前的状态。
软件维护步骤
5、重新验证程序：
1）静态确认； 2）计算机确认； 3）维护后的验收。
软件维护步骤
第三步：维护文档整理
记录一些与维护工作有关的数据信息，这些信息 可作为估计软件维护的有效程度，确定软件产品的 质量，确定维护的实际开销等工作的原始数据。
软件维护步骤
第四步：维护活动评价
具体的评价工作可从以下几个方面考虑： （1）每次程序运行时的平均出错次数； （2）花费在每类维护活动上的总的“人时”数； （3）每个程序、每种语言、每种维护类型程序的平均修改次数； （4）维护工作中增加或删除每个源程序语句所花费的平均“人 时”数； （5）用于每种语言的平均“人时”数； （6）维护申请报告的平均处理时间； （7）各类维护申请的百分比。 一方面，可判定此次维护活动开展是否顺利、成功；另一方面， 为今面的维护工作积累经验。
2、结构化维护：进行维护 活动时，首先从评价需求开始，搞清楚 功能、性能上的改变，然后对设计说明文档进行评价、修改和复查； 根据设计的修改，再进行程序的变动；然后根据测试文档中的测试 用例进行回归测试；最后将修改后的软件再次交付使用。
第8章 面向对象分析-软件工程基础(第3版)-胡思康-清华大学出版社
第8章 面向对象分析
第 5 页5
面向对象分析概述
面向对象分析的3类模型
OOA模型由3类独立模型构成：功能模型、静态模型和动态模型。 ➢功能模型描述软件系统的用户交互和功能。 ➢静态模型描述软件系统中类与对象以及它们间的关系，也因也称 为对象模型。 ➢动态模型描述系统的控制结构，也称为交互模型。
第8章 面向对象分析
第 6 页6
面向对象分析概述
类
静态模型的5个层次 类-对象层
对象
Coad和Yourdon 提出，对于大型、复杂 性软件系统，需要建立 分析问题域的静态模型。 该模型由5个层次组成： 类-对象层、结构层、 属性层、服务层和主题 层。
结构层 属性层 服务层 主题层
泛化关系
关联关系
属性
对象连接
服务
消息连接
⑶ 用例描述：用文字信息详细描述用例的内容，它是对用 例的有益补充。
第8章 面向对象分析
第 8 页8
建立静态模型
➢用例模型分别从参与者和系统的角度描述用户需求， 依据用例模型导出静态模型。静态模型是面向对象建 模中最基本、最重要、最耗时的技术活动。 ➢静态建模的任务是构建问题域的概念模型，把问题 域中的实体转变为信息域的类与对象以及它们间的关 系，因此也被称为对象模型或领域模型。 ➢静态模型通过建立类图及关系来反映领域概念，而 面向对象设计也建立类图，但各阶段对类的抽象程度 不同。
第8章 面向对象分析
第 12 页12
建立动态模型
建立状态图
状态图描述的就是对象状态的转换过程。通过对对象状态 的分析，能够了解对象在系统流程中的变换，从而发现潜在的事 件和条件。
建立状态图的一般过程如下： ⑴ 了解系统的主要功能和性能，确定和它们有关的主要对象。 ⑵ 列出一个对象的生存期内的所有可能的状态。 ⑶ 确定对象状态改变时的触发条件或事件。 ⑷ 在一个对象中，选定一组与描述状态相关的行为属性和促使 改变状态的方法。 ⑸ 结合触发条件、事件、行为属性值改变的先后顺序，建立软 件系统的状态图。
第8章前沿测试技术
敏捷测试要求“交付可用产品”而非单纯的“发现缺 陷”
敏捷方法的特征
• 2001年在软件工程界首次出现“敏捷”。 • 敏捷方法最主要的两个特征：轻量和简单
– 包含最少的流程和文档，减少正式性。 – 做眼前能做的事情，而不去预测太远的未来 – 快速、增量的开发
• 开发方法要称之为敏捷，需要具备4个基本特征：
– 工具未必能生成所有满足要求的数据，但最快速 – 编程能生成所有需要的数据，但是可能是最复杂的、最慢的方式 – 应尽量考虑使用一些简单实用的工具，例如DataFactory
敏捷测试的弱点
• 在某些公司，由于各种原因，一个团队的 敏捷程度完全取决于和他们合作的部门或 公司的敏捷程度。 • 敏捷在无法改变周边的人、部门和公司的 做事方式的时候适用性不好。
8.2测试驱动开发(TDD)
• 一个高效的软件开发过程对软件开发人员 来说是至关重要的 • 测试驱动开发（TDD)是极限编程的重要特 点，它以不断的测试推动代码的开发，即 简化了代码，又保证了软件的质量
什么是测试驱动
测试驱动是一种开发形式： 测试驱动是一种开发形式： 1.首先要编写测试代码 首先要编写测试代码 2.除非存在相关测试，否则不编写任何的产 除非存在相关测试， 除非存在相关测试 品代码 3.由测试来决定需要编写什么样的代码 由测试来决定需要编写什么样的代码 4.要求维护一套详尽的测试集 要求维护一套详尽的测试集
TDD测试案例
• 第二个测试： Public void testFibonacci() { AssertEquals(0,Fib(0)); AssertEquals(1,Fib(1)); } Int Fib(int n) { if(n==0) return 0; return 1; }
软件工程导论 第8章 维护
从上述关于软件维护的定义不难看出，软件维护绝不仅限于纠正使用中发现的错误，事实上在全部维护活动中一半以上是完善性维护。国外的统计数字表明，完善性维护占全部维护活动的50％～66％，改正性维护占17％～21％，适应性维护占18％一25％，其他维护活动只占4％左右。
应该注意，上述4类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样重要的。
软件工程的主要目的就是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。
8．1 软件维护的定义
所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护。 因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以必然会有第一项维护活动：在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。把诊断和改正错误的过程称为改正性维护。
8．2 软件维护的特点
8．2．1 结构化维护与非结构化维护差别巨大
1.非结构化维护
如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和(或)设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试(即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试)。非结构化维护需要付出很大代价(浪费精力并且遭受挫折的打击)，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。
上面的模型表明，如果软件的开发途径不好(即，没有使用软件工程方法学)，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。
应该注意，上述4类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样重要的。
软件工程的主要目的就是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。
8．1 软件维护的定义
所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护。 因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以必然会有第一项维护活动：在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。把诊断和改正错误的过程称为改正性维护。
8．2 软件维护的特点
8．2．1 结构化维护与非结构化维护差别巨大
1.非结构化维护
如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和(或)设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试(即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试)。非结构化维护需要付出很大代价(浪费精力并且遭受挫折的打击)，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。
上面的模型表明，如果软件的开发途径不好(即，没有使用软件工程方法学)，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。
软件工程吴迪第八章课后答案
软件工程吴迪第八章课后答案HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】软件工程课后答案《软件工程》作业及答案1-1什么是软件危机?它有哪些典型表现?为什么会出现软件危机?答:软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
概括地说，软件危机包含下述两方面的问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。
软件危机典型表现：对软件开发成本和进度的估计常常很不准确。
用户对“已完成的”软件系统不满意的现象经常发生。
软件产品的质量往往靠不住。
软件常常是不可维护的。
软件通常没有适当的文档资料。
软件成本在计算机系统总成本中所占的比例逐年上升。
软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
产生软件危机的原因：一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。
软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。
管理和控制软件开发过程相当困难。
软件是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
目前相当多的软件专业人员对软件开发和维护还有不省糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这是使软件问题发展成软件危机的主要原因。
1-2假设你是一家软件公司的总工程师，当你把图给手下的软件工程师们观看，告诉他们及早发现并改正错误的重要性时，有人不同意你的观点，认为要求在错误进入软件之前就清除它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢?”你怎么反驳他?1-3什么是软件工程?它有哪些本质特性?怎样用软件工程消除软件危机?答:软件工程是指导计算机软件开发和维护的一门工程学科。
采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它。
软件工程基础知识
●04
第四章 软件设计
结构化设计
结构化设计是软件设计中的重要概念，包括模块 化设计和使用数据流图、DFD等技术来组织和管 理软件系统的结构。通过结构化设计，可以更好 地理清软件的模块，提高软件的可维护性和可扩
展性。
面向对象设计
封装
将数据和操作封装 在一个单元中
多态
同一操作作用于不 同的对象，产生不
模块化、层次化的 编程方法
敏捷开发
迭代、增量式的开 发方法
面向对象编程
将数据和操作封装 在对象中
DevOps
开发和运维的一体 化
软件工程敏捷开发
敏捷开发是一种迭代式的开发方法，注重团队合 作、快速反馈和灵活应对变化。敏捷开发通过持 续交付、用户参与和迭代开发来提高开发效率和
软件质量。
●02
第2章 软件开发方法
总结
重要性
软件需求工程是软件开发的关键阶段，需求获取和验证的准确性直接影响最终 软件质量
持续性
需求工程是一个持续循环的过程，随着项目的发展和变化，需求也会不断更新 和调整
沟通能力
与用户有效沟通是需求获取的关键，能够确保开发团队真正理解用户需求
展望
软件需求工程是软件工程中非常重要的一个环节，随着信息 技术的不断发展，需求工程的重要性也日益凸显。未来，随 着人工智能、大数据等新技术的广泛应用，需求工程也将面 临更多的挑战和机遇。
目标设定
明确团队目标与方 向
冲突解决
及时解决团队内部 矛盾
激励机制
激励团队成员保持 积极性
结语
软件工程实践是软件工程师必备的基础知识之一，通过学习 和实践，我们能够更好地应对各种复杂的软件项目，提高项 目成功率和质量。不断学习和提升技能是软件工程师成长的 关键，希望大家能够在软件工程的道路上不断前行，创造更 加优秀的软件产品。
《软件工程》第八章 软件维护与再工程
软件可维护性－主要影响因素
可移植性：指程序转移到一个新的计算环境的难易 程度。
影响软件可移植性的因素有：信息隐蔽原则；模块 独立；模块化；高内聚低耦合；良好的程序结构； 不用标准文本以外的语句等
一个可移植的程序应具有结构良好、灵活、不依赖 于某பைடு நூலகம்具体计算机或操作系统的性能
软件可维护性－主要影响因素
软件维护的概念－维护成本
其它一些因素：如应用的类型、数学模型、 任务的难度、IF嵌套深度、索引或下标数等， 对维护工作量也有影响
软件维护的过程－维护组织
维护组织结构图
软件维护的过程－维护组织
系统监督员一般都是对程序(某一部分)特别熟 悉的技术人员。 在维护人员对程序进行修改的过程中，由配 置管理员严格把关，控制修改的范围，对软 件配置进行审计 。 维护管理员、系统监督员、修改控制决策机 构等，均代表维护工作的某个职责范围 。
如果已经开始保存维护记录，可以对维护工作做 一些定量度量，至少可以从如下7方面进行评价：
每次程序运行平均失败的次数； 用于每一类维护活动的总人时数； 平均每个程序、每种语言、每种维护类型所必需的程序 变动数； 维护过程中增加或删除源语句平均花费的人时数； 维护每种语言平均花费的人时数； 一张维护请求表的平均周转时间； 不同维护类型所占的比例；
软件维护的过程－维护记录
软件修改报告指明：为满足维护申请报告提 出的需求所需的工作量、本次维护活动的类 别、本次维护请求的优先级、本次修改的背 景数据。在拟定进一步维护计划前，软件修 改报告要提交给修改决策机构，供进一步规 划维护活动使用 保存维护记录的第一个问题就是哪些数据值 得保存？
软件维护的过程－维护评价
软件维护的概念－维护问题
(科创学院) 自考综合题 复习使用 软件工程复习题第八章
重庆科创职业学院历年真题/综合题（仅供复习）软件工程复习题(第八章)一、选择题1.CMMI是一个过程改善框架，其关注相应的质量支撑点，来帮助组织开发和维护相应的产品和服务，从而提高质量。
下列选项中，哪一项不是质量支撑点。
【D】A.人员B.规程和方法C.工具D.技术二、填空题1.所谓过程改善，是指人为设计的一个活动程序，其目的是改进组织的过程性能和成熟度，并改进这一程序的结果。
2.CMMI是由一些过程域组成，过程域有自己的专用目标和共用目标，每个专用目标和共用目标都有包括相应的专用实践和共同实践，每个专有实践中有典型工作产品和子实践，每个共同实践中，也有自己子实践和共用实践的精化。
3.CMMI模型中，共有22个过程域，分为四类，分别是：项目管理类、工程类、支持类、过程管理类。
4.为了改善开发过程和维护过程的组织，CMMI引入了两种类型的”等级”一个称为能力等级、另一个称为成熟度等级5.CMMI中，针对每一个过程域设定了6个能力等级分别是：0级：未完成级、1级：已执行级、2级：已管理级、3级：已定义级、4级：已定量管理级、5级：持续优化级。
6.所谓成熟度等级，是指达到预先定义的一组过程域所有目标的一种过程改善等级。
由预先定义的一个过程域集及其相关的一些专用实践和共用实践组成7.在CMMI中，应用于一个组织过程改善的成熟度等级有5个，分别是：1级：初始级，2级：已管理级、3级：已定义级、4级：已定量管理级、5级：持续优化级。
8.成熟度等级是用于表征组织对一组过程域的改进，而能力等级是用于表征组织对单个过程域的改进9.三、简答题1.简述CMMI模型的模型部件及部件间的关系2.简述能力等级与成熟度等级之间的区别与联系3.简述专用实践与共用实践的关系。
《软件工程实用教程》第8_章_软件维护技术
第8 章 軟體維Βιβλιοθήκη 技術8.2 軟體維護類型8.2.1 改正性維護 1. 利用應用軟體包，可開發出比由用戶完全 自己開發的系統可靠性更高的軟體。 2. 結構化技術，用它開發的軟體易於理解和 測試。 3. 防錯性程式設計。把自檢能力引入程式， 通過非正常狀態的檢查，提供審查跟蹤。 4. 通過週期性維護審查，在形成維護問題之 前就可確定品質缺陷。可理解性
第8 章 軟體維護技術
8.2.2 完善性維護 為了滿足日益增長的新要求，需要修改或再 開發軟體，以擴充軟體功能，增強軟體性能， 改進加工效率，提高軟體的可維護性，這些 維護活動稱為完善性維護。 8.2.3 適應性維護 為了使軟體適應新的變化而去修改軟體的維 護活動稱為適應性維護。 8.2.4 預防性維護 為以後進一步使用軟體打下良好基礎的維護 活動稱為預防性維護活動。
第8 章 軟體維護技術
8.4.2 軟體維護的副作用 1．修改代碼的副作用 2．修改數據的副作用 3．修改文檔的副作用
（1）確認維護類型 （2）實施維護 （3）維護評審
第8 章 軟體維護技術
4．整理軟體維護文檔 程式名稱； 使用的程式設計語言； 根源程式語句條數，機器代碼指令條數； 程式安裝的日期； 程式安裝後的運行次數； 與程式安裝後運行次數有關的處理故障次數； 程式改變的層次，名稱和日期； 修改程式所增加的根源程式語句條數； 修改程式所減少的根源程式語句條數；
第8 章 軟體維護技術
8.3 軟體維護技術
8.3.1 軟體維護過程 1．建立維護機構
第8 章 軟體維護技術
2．編寫軟體維護申請報告 軟體變更報告包括的內容： 所需修改變動的性質； 申請修改的優先順序； 為滿足該維護申請報告，所需的工作量（人 員數，時間數）； 預計修改後的結果。 3．確定軟體維護工作流程
《软件工程》(第五版)习题参考答案
把整个软件生命周期划分为若干个较小的阶段每个阶段都有相对独立的任务和完成任务的步骤和方法然后逐步完成各个阶段的任务这有利于软件开发过程的组织和管理从而降低了整个软件开发过程的困难程度从而使规模庞大结构复杂和管理复杂的软件开发变得容易控制和管理
《软件工程》（第五版）习题参考答案
第1章 一、判断题 1、（×）软件的维护与硬件维护本质上是相同的。 2、（√）软件在运行和使用中也存在退化问题。 3、（×）软件危机的产生主要是因为程序设计人员使用了不适 当的程序设计语言。 4、（√）软件同其他事物一样，有孕育、诞生、成长、成熟和 衰亡的生存过程。 5、（×）文字处理软件 Word 属于系统软件。应用软件 6、（√）原型是软件的一个早期可运行的版本，它反映最终系 统的部分重要特性。 7、（√）软件开发过程中，一个错误发现得越晚，为改正它所 付出的代价就越大。 8、（×）快速原型模型对软件开发人员的水平要求不高。 9、（√）喷泉模型适合于面向对象的软件开发。 10、（×）面向对象开发方法的主要缺点是在适应需求变化方面 不够灵活。 二、选择题 1、软件是一种（C）。 A、程序 B、数据
D、合同文档 14、结构化分析方法是以数据流图、（D）和加工说明等描述工 具，即用直观的图和简洁的语言来描述软件系统模型。 A、DFD 图 B、PAD 图 C、IPO 图 D、DD 15、软件需求分析阶段的工作，可以分为四个方面：需求获取、 需求分析、编写需求规格说明书以及（B）。 A、阶段性报告 B、需求评估 C、总结 D、都不正确 16、数据流图用于抽象描述一个软件的逻辑模型，数据流图由一 些特定的图符构成。下面图符名称标识的图符不属于数据流图合 法图符的是（A）。 A、控制流 B、加工 C、数据存储 D、源点和终点 17、DFD 用于描述系统的（D）。 A、数据结构
《软件工程》（第五版）习题参考答案
第1章 一、判断题 1、（×）软件的维护与硬件维护本质上是相同的。 2、（√）软件在运行和使用中也存在退化问题。 3、（×）软件危机的产生主要是因为程序设计人员使用了不适 当的程序设计语言。 4、（√）软件同其他事物一样，有孕育、诞生、成长、成熟和 衰亡的生存过程。 5、（×）文字处理软件 Word 属于系统软件。应用软件 6、（√）原型是软件的一个早期可运行的版本，它反映最终系 统的部分重要特性。 7、（√）软件开发过程中，一个错误发现得越晚，为改正它所 付出的代价就越大。 8、（×）快速原型模型对软件开发人员的水平要求不高。 9、（√）喷泉模型适合于面向对象的软件开发。 10、（×）面向对象开发方法的主要缺点是在适应需求变化方面 不够灵活。 二、选择题 1、软件是一种（C）。 A、程序 B、数据
D、合同文档 14、结构化分析方法是以数据流图、（D）和加工说明等描述工 具，即用直观的图和简洁的语言来描述软件系统模型。 A、DFD 图 B、PAD 图 C、IPO 图 D、DD 15、软件需求分析阶段的工作，可以分为四个方面：需求获取、 需求分析、编写需求规格说明书以及（B）。 A、阶段性报告 B、需求评估 C、总结 D、都不正确 16、数据流图用于抽象描述一个软件的逻辑模型，数据流图由一 些特定的图符构成。下面图符名称标识的图符不属于数据流图合 法图符的是（A）。 A、控制流 B、加工 C、数据存储 D、源点和终点 17、DFD 用于描述系统的（D）。 A、数据结构
软件工程(钱乐秋)第08章 基于构件的软件开发
复旦大学计算机科学与工程系 软件工程课程 19/41
对可复用构件的要求
• • • • • 构件的设计应具有较高的通用程度 构件应易于调整 构件应易于组装 构件必须具有可检索性 构件必须经过充分的测试
复旦大学计算机科学与工程系 软件工程课程
20/41
创建领域构件的设计框架
• 除应遵循已有的设计概念和原则外， 还必须考虑应用领域的特征，例如：
– 标准数据：应该研究应用领域，并标识出标准的全局 数据结构(如文件结构或完整的数据库)。于是所有设 计的构件都可以用这些标准数据结构来刻画 – 标准接口协议：应该建立三个层次的接口协议：构件 内(intramodular)接口、构件外接口以及人机接口
– 程序模板：程序的结构模型可以作为新程序的体系结 构设计的模板
• COM+ • EJB：一种基于Java的构件标准
– 提供了让客户端使用远程的分布式对象的框架 – EJB规约规定了EJB构件如何与EJB容器进行行交互
11/41
复旦大学计算机科学与工程系 软件工程课程
基于构件的软件开发过程
复旦大学计算机科学与工程系 软件工程课程
12/41
领域工程步骤-1
• 领域分析：首先要进行领域分析，收集领域中有代表性 的应用样本，分析应用中的公共部分或相似部分，抽取 该领域的应用体系结构 • 建立领域特定的基准体系结构模型：在领域分析的基础 上，构造该领域的基准体系结构，这个基准体系结构应 是可以裁剪和扩充的，并可供该领域的应用复用 • 标识候选构件：在领域分析和领域基准体系结构模型的 基础上标识该领域的候选构件 • 泛化(generalization)和可变性(variability)分析：提高 其通用性，同时寻找候选构件在不同应用中的变化点 (variation point)，通过设置参数、继承或其它手段， 使可变部分局部化
对可复用构件的要求
• • • • • 构件的设计应具有较高的通用程度 构件应易于调整 构件应易于组装 构件必须具有可检索性 构件必须经过充分的测试
复旦大学计算机科学与工程系 软件工程课程
20/41
创建领域构件的设计框架
• 除应遵循已有的设计概念和原则外， 还必须考虑应用领域的特征，例如：
– 标准数据：应该研究应用领域，并标识出标准的全局 数据结构(如文件结构或完整的数据库)。于是所有设 计的构件都可以用这些标准数据结构来刻画 – 标准接口协议：应该建立三个层次的接口协议：构件 内(intramodular)接口、构件外接口以及人机接口
– 程序模板：程序的结构模型可以作为新程序的体系结 构设计的模板
• COM+ • EJB：一种基于Java的构件标准
– 提供了让客户端使用远程的分布式对象的框架 – EJB规约规定了EJB构件如何与EJB容器进行行交互
11/41
复旦大学计算机科学与工程系 软件工程课程
基于构件的软件开发过程
复旦大学计算机科学与工程系 软件工程课程
12/41
领域工程步骤-1
• 领域分析：首先要进行领域分析，收集领域中有代表性 的应用样本，分析应用中的公共部分或相似部分，抽取 该领域的应用体系结构 • 建立领域特定的基准体系结构模型：在领域分析的基础 上，构造该领域的基准体系结构，这个基准体系结构应 是可以裁剪和扩充的，并可供该领域的应用复用 • 标识候选构件：在领域分析和领域基准体系结构模型的 基础上标识该领域的候选构件 • 泛化(generalization)和可变性(variability)分析：提高 其通用性，同时寻找候选构件在不同应用中的变化点 (variation point)，通过设置参数、继承或其它手段， 使可变部分局部化
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
若通过，系统执行用况“查看学分”的其余
部分；
方案三：
使用扩展，设计系统登录。
《extend》 选课
登录
扩展点： 选课：选择选课 查看学分：选择查看学分 《extend》 查看学分
研究生
如下为对用况“登录”的描述
研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 若通过，若该生选择选课 系统在扩展点”选课”处执行用况“选课”； 若通过，若该生选择查看学分 系统在扩展点”查看学分”处执行用况“查看学分” ；
《include》 选课 登录
研究生
《include》
查看学分
如下为对用况“登录”的描述： 研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 若通过，若该生选择选课 系统执行用况“选课”； 若通过，若该生选择查看学分 系统执行用况“查看学分”； 该方法的缺点是，必须要了解 系统的所有其它模块，才能描述 清楚“登录”用况。向系统增加 新用况时，也要修改登录用况。 此外，从维护的角度看，有时会 忘记对“登录”用况进行修改。
用况图
电话订购 核对 身份
售票员
设置 订单
《include》 《include》
《extend》
《include》
请求 目录
提供 客户数据
客户
产生 订单
安排 支付
现金 支付 供应 订单
信用卡 支付
送货员
建立 信用
主管r
电话订购系统用况图
一. 定义系统 用况图中的矩形框代表系统，系统的用况画在 矩形框内，代表系统之外的执行者画在矩形 框外
例题
很多软件系统在一开始都需要登录，若用户登 录成功，则可进入系统。 如下以一个研究生学籍管理系统为例，描述四 种登录方法。
为了简化起见，假设此处仅描述登录、选课和查 看学分这3项功能。
方案一：
由于选课和查看学分都需要登录，故专门设立一个“登录” 用况。若登录成功，则可以进行选课，也可以进行查看学分。
执行者还可分为主动执行者和被动执行者： 主动执行者开始一个用况 被动执行者从不开始用况，只是参与一 个或多个用况
三. 确定用况 1. 用况的特征
用况总是被执行者启动的（initiated），执行者必须 直接或间接地指示系统去执行用况
• •用况向执行者提供值，这些值必须是可识别的
•用况是完整的，一个用况必须是一个完整的描述
•
•
•
•
•
另外还有一些不是目前的执行者回答的问题： 系统需要哪些输入 / 输出？谁从系统获取信息？ 谁为系统提供信息？ 与当前系统（可能是人工系统而不是自动化系 统）的实现有关的主要问题是什么？ 对同一个项目，不同的开发者选取的用况数 是不一样的。例如一个10个人年规模的项目， 有人选取了20个用况，而在一个类似的项目中， 有人选用了100个用况 似乎20个太少，而100个太多，希望在项目规 模和用况数之间保持均衡
用况建模步骤
创建用况模型的步骤包括： 1．定义系统 2．确定执行者 3．确定用况 4．描述用况 5．定义用况间的关系 6．确认模型
用况模型由用况图组成，用况图展示了执行 者、用况以及它们之间的关系。用况通常用正文 形式来描述 一个用况模型可由若干幅用况图组成。一幅 用况图包含的模型元素有系统、执行者、用况， 以及表示它们间的不同关系，如关联、扩展、包 含、泛化等
若一个参与者是另一个参与者的一部分，或扮演了 类似的角色，考虑在它们之间使用泛化关系；
用况 每个用况都至少和一个参与者相关； 若两个用况有相同或相似的序列，可能需要合 并它们，或抽取出一个新用况，在它们之间使 用包含、扩展或泛化关系。
若用况过于复杂，为了易于理解，考虑进行分 解；若一个用况中有完全不同的事件流，最好 把它分解成不同的用况
5. 客户输入信用卡支付信息 6. 客户选择提交 7. 系统检验输入的信息，把该订单作为未完成的交易 保存，同时向记账系统转发支付信息。如果客户 提交的信息不正确，系统将提示客户修改。 8. 当支付确认后，订单就被标记上已经确认，同时 返回给客户一个订单ID，用况也就结束了。如果支 付没有被确认，系统将提示客户改正支付信息或 者取消。如果客户选择修改信息，就回到第5步； 如果选择取消，用况结束。 后臵条件：如果订单没有被取消，它将保存在系统中， 并做上标记
只通过有限的接口与 外部交互
把内外交互情况描 述清楚，就确切地 定义了系统的需求
执行者是指那些可能使用这些用况的人或外部系统， 执行者与用况的连接表示该执行者使用了那个用况 用况图给出了用户所感受到的系统行为，但不描述 系统如何实现该功能 用况通常用普通正文描述，也可以用活动图来描述
收款
售货员
四. 用况的描述 用况通常用正文（text）来描述,也可用活动图来描述 用况的正文描述应包括以下内容： 用况的目的：用况的最终目的是什么？它试图达到什 么？ 用况是如何启动（initiate）的：哪个执行者在什么情 况下启动用况的执行？ 执行者和用况之间的消息流：用况与执行者之间交换 什么消息或事件来通知对方改变或恢复信息？描述系 统与执行者之间的主消息流是什么？以及系统中哪些 实体被使用或修改？
方案二：
让所有的相关用况都包含登录用况。
选课 《nclude》
如下为对用况“选课”的描述：
这个方法中的“登录” 研究生启动系统，调用用况“登录” 用况仅描述有关登录的 若通过，系统执行用况“选课”的其余部分 信息，研究生执行系统 ； 的每项功能都要先登录。 如下为对用况“查看学分”的描述： 其缺点为，对研究生要 研究生启动系统，调用用况“登录” 进行多次验证。
该方法与方法一相比， 对“登录”用况的描 述要清楚一些。在增 加新用况时，仅在登 录用况中添加扩展点 即可。
方案四：
登录用况完全独立于其它用况
登录
选课
研究生 查看学分
如订购货物用况的基本路径： 事件流： 基本路径 1. 当客户选择订购货物时，用况开始 2. 客户输入他的姓名和地址 3. 当客户输入产品代码时 a. 系统给出产品描述和价格 b. 系统往客户订单中添加该物品的价格 循环结束 4. 客户输入信用卡支付信息 5. 客户选择提交 6. 系统检验输入的信息，把该订单作为未完成的交易保存， 同时向记账系统转发支付信息 7. 当支付确认后，订单就被标记上已经确认，同时返回给客 户一个订单ID，用况结束
五. 确定用况之间的关系
关系 关联 扩展 说明 执行者与他所参与的一个用况之 间的通信路径 扩展的用况到基本用况的一种关 系，它指出扩展的用况所定义的 行为如何插入到基本用况所定义 的行为中。扩展的用况通过模块 化方式增量地修改基本用况 记号
《extend》
关系 包含
用况泛 化
说明 从基本用况到另一个用况（称 为包含用况，inclusion use case）的一种关系，它指出包 含用况定义的行为被包含在基 本用况所定义的行为中。基本 用况能看到包含用况，并依赖 于执行包含用况后的结果，但 两者相互间不能访问其他属性 一个一般用况与一个更特殊的 用况之间的关系，特殊用况可 继承一般用况的特征
其他需求
在用况中还可描述一些特殊的需求，这些需 求常常是非功能性需求，如可用性、安全性、可 维护性、负载、性能、自动防故障、数据需求等。 如订购货物用况的其他需求： 前臵条件：（略） 事件流： （略） 特殊需求： 系统必须在一秒内响应客户的输入 后臵条件： （略）
事件流可分为两部分： 基本路径 基本路径是运转正常时的路径，是一系列没 有分支和选择的简单陈述句 可选路径 可选路径是指不同于基本路径而允许不同的 事件序列的路径。 对于明显有可能随时发生的事情来说，可选 路径非常有效。
用况的详细描述 前臵条件和后臵条件 前臵条件和后臵条件表示用况开始和结束的条件 事件流（flow of events） 事件流是一系列陈述句，它是从执行者的角度看， 列出用况的各个步骤 用况描述中可以包含条件、分支和循环 例如：订购货物用况的描述如下
用况名称：订购货物 参与的执行者：客户、客户代表 前臵条件：一个合法的客户已经登录到这个系统 事件流： 1. 当客户选择订购货物时，用况开始 2. 客户输入他的姓名和地址 3. 如果客户只输入邮编，系统将给出州和城市名 4. 当客户输入产品代码 a. 系统给出产品描述和价格 b. 系统往客户订单中添加该物品的价格 循环结束
检查
任何一个涉及到系统功能活动的人都会用到用 况模型 客户：用况模型指明了系统的功能，描述了系统 能如何使用。用况建模时客户的积极参与是十分 重要的 开发者：用况模型帮助他们理解系统要做什么， 同时为以后的其他模型建模、结构设计、实现等 提供依据 集成测试和系统测试人员：根据用况来测试系统， 以验证系统是否完成了用况指定的功能
如果在订购货物用况中，客户可以在提交订单前 随时取消订单，其可选路径如下： 可选路径： 在选择提交前的任何时候，客户都可以选择 cancel。这次订购没有被保存，用况结束。 在基本路径第6步，如果有任何不正确的信息，系 统提示客户去修改这些信息。 在基本路径第7步，如果支付没有被确认，系统将 提示客户改正支付信息或者取消。如果客户选择 修改信息，就回到基本路径第4步；如果选择取消， 用况结束。
软件工程
第8章 面向对象建模
内容摘要
用况建模 静态建模 动态建模 物理体系结构建模
内容摘要
用况建模 静态建模 动态建模 物理体系结构建模
用况建模
用况建模是用于描述一个系统应该做什么的 建模技术，用况建模不仅用于新系统的需求获取， 还可用于已有系统的升级。用况模型用用况图来 描述 用况图展示了各类外部执行者与系统所提供 的用况之间的连接。一个用况是系统所提供的一 个功能（也可以说是系统提供的某一特定用法） 的描述 用况图：主要用于对系统(子系统)的功能行为 进行建模。
部分；
方案三：
使用扩展，设计系统登录。
《extend》 选课
登录
扩展点： 选课：选择选课 查看学分：选择查看学分 《extend》 查看学分
研究生
如下为对用况“登录”的描述
研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 若通过，若该生选择选课 系统在扩展点”选课”处执行用况“选课”； 若通过，若该生选择查看学分 系统在扩展点”查看学分”处执行用况“查看学分” ；
《include》 选课 登录
研究生
《include》
查看学分
如下为对用况“登录”的描述： 研究生启动系统； 系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系统进行验证，给出验证信息； 若通过，若该生选择选课 系统执行用况“选课”； 若通过，若该生选择查看学分 系统执行用况“查看学分”； 该方法的缺点是，必须要了解 系统的所有其它模块，才能描述 清楚“登录”用况。向系统增加 新用况时，也要修改登录用况。 此外，从维护的角度看，有时会 忘记对“登录”用况进行修改。
用况图
电话订购 核对 身份
售票员
设置 订单
《include》 《include》
《extend》
《include》
请求 目录
提供 客户数据
客户
产生 订单
安排 支付
现金 支付 供应 订单
信用卡 支付
送货员
建立 信用
主管r
电话订购系统用况图
一. 定义系统 用况图中的矩形框代表系统，系统的用况画在 矩形框内，代表系统之外的执行者画在矩形 框外
例题
很多软件系统在一开始都需要登录，若用户登 录成功，则可进入系统。 如下以一个研究生学籍管理系统为例，描述四 种登录方法。
为了简化起见，假设此处仅描述登录、选课和查 看学分这3项功能。
方案一：
由于选课和查看学分都需要登录，故专门设立一个“登录” 用况。若登录成功，则可以进行选课，也可以进行查看学分。
执行者还可分为主动执行者和被动执行者： 主动执行者开始一个用况 被动执行者从不开始用况，只是参与一 个或多个用况
三. 确定用况 1. 用况的特征
用况总是被执行者启动的（initiated），执行者必须 直接或间接地指示系统去执行用况
• •用况向执行者提供值，这些值必须是可识别的
•用况是完整的，一个用况必须是一个完整的描述
•
•
•
•
•
另外还有一些不是目前的执行者回答的问题： 系统需要哪些输入 / 输出？谁从系统获取信息？ 谁为系统提供信息？ 与当前系统（可能是人工系统而不是自动化系 统）的实现有关的主要问题是什么？ 对同一个项目，不同的开发者选取的用况数 是不一样的。例如一个10个人年规模的项目， 有人选取了20个用况，而在一个类似的项目中， 有人选用了100个用况 似乎20个太少，而100个太多，希望在项目规 模和用况数之间保持均衡
用况建模步骤
创建用况模型的步骤包括： 1．定义系统 2．确定执行者 3．确定用况 4．描述用况 5．定义用况间的关系 6．确认模型
用况模型由用况图组成，用况图展示了执行 者、用况以及它们之间的关系。用况通常用正文 形式来描述 一个用况模型可由若干幅用况图组成。一幅 用况图包含的模型元素有系统、执行者、用况， 以及表示它们间的不同关系，如关联、扩展、包 含、泛化等
若一个参与者是另一个参与者的一部分，或扮演了 类似的角色，考虑在它们之间使用泛化关系；
用况 每个用况都至少和一个参与者相关； 若两个用况有相同或相似的序列，可能需要合 并它们，或抽取出一个新用况，在它们之间使 用包含、扩展或泛化关系。
若用况过于复杂，为了易于理解，考虑进行分 解；若一个用况中有完全不同的事件流，最好 把它分解成不同的用况
5. 客户输入信用卡支付信息 6. 客户选择提交 7. 系统检验输入的信息，把该订单作为未完成的交易 保存，同时向记账系统转发支付信息。如果客户 提交的信息不正确，系统将提示客户修改。 8. 当支付确认后，订单就被标记上已经确认，同时 返回给客户一个订单ID，用况也就结束了。如果支 付没有被确认，系统将提示客户改正支付信息或 者取消。如果客户选择修改信息，就回到第5步； 如果选择取消，用况结束。 后臵条件：如果订单没有被取消，它将保存在系统中， 并做上标记
只通过有限的接口与 外部交互
把内外交互情况描 述清楚，就确切地 定义了系统的需求
执行者是指那些可能使用这些用况的人或外部系统， 执行者与用况的连接表示该执行者使用了那个用况 用况图给出了用户所感受到的系统行为，但不描述 系统如何实现该功能 用况通常用普通正文描述，也可以用活动图来描述
收款
售货员
四. 用况的描述 用况通常用正文（text）来描述,也可用活动图来描述 用况的正文描述应包括以下内容： 用况的目的：用况的最终目的是什么？它试图达到什 么？ 用况是如何启动（initiate）的：哪个执行者在什么情 况下启动用况的执行？ 执行者和用况之间的消息流：用况与执行者之间交换 什么消息或事件来通知对方改变或恢复信息？描述系 统与执行者之间的主消息流是什么？以及系统中哪些 实体被使用或修改？
方案二：
让所有的相关用况都包含登录用况。
选课 《nclude》
如下为对用况“选课”的描述：
这个方法中的“登录” 研究生启动系统，调用用况“登录” 用况仅描述有关登录的 若通过，系统执行用况“选课”的其余部分 信息，研究生执行系统 ； 的每项功能都要先登录。 如下为对用况“查看学分”的描述： 其缺点为，对研究生要 研究生启动系统，调用用况“登录” 进行多次验证。
该方法与方法一相比， 对“登录”用况的描 述要清楚一些。在增 加新用况时，仅在登 录用况中添加扩展点 即可。
方案四：
登录用况完全独立于其它用况
登录
选课
研究生 查看学分
如订购货物用况的基本路径： 事件流： 基本路径 1. 当客户选择订购货物时，用况开始 2. 客户输入他的姓名和地址 3. 当客户输入产品代码时 a. 系统给出产品描述和价格 b. 系统往客户订单中添加该物品的价格 循环结束 4. 客户输入信用卡支付信息 5. 客户选择提交 6. 系统检验输入的信息，把该订单作为未完成的交易保存， 同时向记账系统转发支付信息 7. 当支付确认后，订单就被标记上已经确认，同时返回给客 户一个订单ID，用况结束
五. 确定用况之间的关系
关系 关联 扩展 说明 执行者与他所参与的一个用况之 间的通信路径 扩展的用况到基本用况的一种关 系，它指出扩展的用况所定义的 行为如何插入到基本用况所定义 的行为中。扩展的用况通过模块 化方式增量地修改基本用况 记号
《extend》
关系 包含
用况泛 化
说明 从基本用况到另一个用况（称 为包含用况，inclusion use case）的一种关系，它指出包 含用况定义的行为被包含在基 本用况所定义的行为中。基本 用况能看到包含用况，并依赖 于执行包含用况后的结果，但 两者相互间不能访问其他属性 一个一般用况与一个更特殊的 用况之间的关系，特殊用况可 继承一般用况的特征
其他需求
在用况中还可描述一些特殊的需求，这些需 求常常是非功能性需求，如可用性、安全性、可 维护性、负载、性能、自动防故障、数据需求等。 如订购货物用况的其他需求： 前臵条件：（略） 事件流： （略） 特殊需求： 系统必须在一秒内响应客户的输入 后臵条件： （略）
事件流可分为两部分： 基本路径 基本路径是运转正常时的路径，是一系列没 有分支和选择的简单陈述句 可选路径 可选路径是指不同于基本路径而允许不同的 事件序列的路径。 对于明显有可能随时发生的事情来说，可选 路径非常有效。
用况的详细描述 前臵条件和后臵条件 前臵条件和后臵条件表示用况开始和结束的条件 事件流（flow of events） 事件流是一系列陈述句，它是从执行者的角度看， 列出用况的各个步骤 用况描述中可以包含条件、分支和循环 例如：订购货物用况的描述如下
用况名称：订购货物 参与的执行者：客户、客户代表 前臵条件：一个合法的客户已经登录到这个系统 事件流： 1. 当客户选择订购货物时，用况开始 2. 客户输入他的姓名和地址 3. 如果客户只输入邮编，系统将给出州和城市名 4. 当客户输入产品代码 a. 系统给出产品描述和价格 b. 系统往客户订单中添加该物品的价格 循环结束
检查
任何一个涉及到系统功能活动的人都会用到用 况模型 客户：用况模型指明了系统的功能，描述了系统 能如何使用。用况建模时客户的积极参与是十分 重要的 开发者：用况模型帮助他们理解系统要做什么， 同时为以后的其他模型建模、结构设计、实现等 提供依据 集成测试和系统测试人员：根据用况来测试系统， 以验证系统是否完成了用况指定的功能
如果在订购货物用况中，客户可以在提交订单前 随时取消订单，其可选路径如下： 可选路径： 在选择提交前的任何时候，客户都可以选择 cancel。这次订购没有被保存，用况结束。 在基本路径第6步，如果有任何不正确的信息，系 统提示客户去修改这些信息。 在基本路径第7步，如果支付没有被确认，系统将 提示客户改正支付信息或者取消。如果客户选择 修改信息，就回到基本路径第4步；如果选择取消， 用况结束。
软件工程
第8章 面向对象建模
内容摘要
用况建模 静态建模 动态建模 物理体系结构建模
内容摘要
用况建模 静态建模 动态建模 物理体系结构建模
用况建模
用况建模是用于描述一个系统应该做什么的 建模技术，用况建模不仅用于新系统的需求获取， 还可用于已有系统的升级。用况模型用用况图来 描述 用况图展示了各类外部执行者与系统所提供 的用况之间的连接。一个用况是系统所提供的一 个功能（也可以说是系统提供的某一特定用法） 的描述 用况图：主要用于对系统(子系统)的功能行为 进行建模。