第4章软件工程
合集下载
软件工程第四章 结构化分析
软件需求分析阶段的工作，可以分成以下四个方面 ：对问题的识别、分析与综合、制定规格说明以及 （ ）。 A．总结 B．实践性报告 C．需求分析评审 D．以上答案都不正确
答案:C
需求验证应该从下述几个方面进行验证：（C ） A 可靠性、可用性、易用性、重用性 B可维护性、可移植性、可重用性、可测试性 C一致性、现实性、完整性、有效性 D 功能性、非功能性
3、需求分析步骤
1、需求获取
3、亲身实践：观察用户工作流程
优点： 1. 通过直接观察提取用户或系统的特性； 2. 有助于理解难以用语言描述清楚的复杂业务。 3. 更加准确和真实 缺点：
1. 观察可能使用户紧张，从而表现与往常不同。 2. 比较费时间
3、需求分析步骤
1、需求获取
3、需求分析步骤
3、需求分析步骤
3 需求描述
1. 又叫：需求规约
2. 是分析任务的最终产物，给出对目标软件的 各种需求。
3. 需求规约作为用户和开发者之间的一个协议 （需求规格说明书），在之后的软件工程各 个阶段发挥重要作用
软件需求分析阶段的目的是澄清用户的要求 ，并把双方共同的理解明确地表达成一份书 面文档——（软件需求规格说明书）。
经调查，系统分析员给出有问题的初略陈述， 其中部分描述如下：某商场的采购部门要求每 天开出定购清单，交采购员输入系统；仓库管 理员还要将库存信息此输入系统，经库存业务 （进贷或出贷）处理后输出。从这段描述可知 该部分数据流图中的外部项为：
A.采购员、仓库管理员 B.定购清单、库存业务 C.库存业务 D.定购清单、采购员 答案A
3、需求分析步骤
4、需求验证
1. 进行需求评审
2. 验证需求的一致性
3. 验证需求的现实性
软件工程 第4章 形式化说明技术
行为建模
1)
2)
3)
系统的需求规格说明通常是用自然语言来叙 述的，但是用自然语言描述往往会出现二义 性。 为了直观地分析系统的动作，从特定的视点 出发描述系统的行为，需要采用动态分析的 方法。 最常用的动态分析方法
有穷状态机
时序图 Petri网
状态迁移图
状态迁移图是通过描述系统的
状态及引起系统状态转换的事 件来表示系统的行为。
形式化方法
形式化方法是建立在严格数学基础上、具有精确数学语义 的开发方法，即就是用数学语言来描述软件的设计规约。 形式化方法可以分为形式化描述和建立在形式化描述基础之 上的形式化开发 形式化的描述：用形式化的语言(具有严格的语法语义定 义的语言)描述描述软件系统及其行为模式，以更好地刻 画软件系统的性质。 形式化的开发：用形式化的语言来描述软件需求和特征， 并且通过推理验证来保证最终的软件产品是否满足这些需 求和具备这些特征，符合给定的行为模式。
应用形式化方法的准则
应该选用适当的形式化方法：主要包括有限状态机、时 序图、Petri网、Z、VDM等。 应该形式化，但不要过分形式化 应该估算成本 应该有形式化方法顾问随时提供咨询 不应该放弃传统的开发方法 应该建立详尽的文档 不应该放弃质量标准 不应该盲目依赖形式化方法 应该测试、测试再测试 应该重用
半形式化方法
软件工程使用方法可分成：非形式化、半形式化和形式化 半形式化： 结构化分析（SA）方法 利用图形等半形式化的描述方式表达需求：用数据流图、 状态转换图或实体-联系图建立数据、行为和功能模型， 形成需求说明书中的主要部分。 利用结构化语言描述加工逻辑：结构化语言是介于自然 语言和形式语言之间的一种半形式语言。加工逻辑结构 可分成外层和内层两层：外层用来描述控制结构，采用 顺序、选择、重复三种基本结构；内层对于顺序执行和 循环执行的动作，用结构化语言描述。 缺点：可能存在矛盾、二义性、含糊性、不完整性及抽 象层次混乱等问题。
软件工程第4章 软件设计
5. 设计软件结构 通常程序中的一个模块完成一个适当的子功能。应 该把模块组织成良好的层次系统，顶层模块调用它 的下层模块以实现程序的完整功能，每个下层模块 再调用更下层的模块，从而完成程序的一个子功能， 最下层的模块完成最具体的功能。
6. 设计数据库 对于需要使用数据库的那些应用系统，软件工程师 应该在需求分析阶段所确定的系统数据需求的基础 上，进一步设计数据库。
高内聚也有两类：如果一个模块内的处理元素和同 一个功能密切相关，而且这些处理必须顺序执行 (通常一个处理元素的输出数据作为下一个处理元 素的输入数据)，则称为顺序内聚。根据数据流图 划分模块时，通常得到顺序内聚的模块，这种模块 彼此间的连接往往比较简单。如果模块内所有处理 元素属于一个整体，完成一个单一的功能，则称为 功能内聚。功能内聚是最高程度的内聚。
(2) 用户手册根据总体设计阶段的结果，修改更正 在需求分析阶段产生的初步的用户手册。
(3) 测试计划包括测试策略，测试方案，预期的测 试结果，测试进度计划等等。 (4) 详细的实现计划 (5) 数据库设计结果
9. 审查和复审 最后应该对总体设计的结果进行严格的技术审查， 在技术审查通过之后再由使用部门的负责人从管理 角度进行复审。
为什么模块的独立性很重要呢?主要有两条理由： 第一，有效的模块化(即具有独立的模块)的软件比 较容易开发出来。这是由于能够分割功能而且接口 可以简化，便于多人分工合作开发同一个软件。
第二，独立的模块比较容易测试和维护。这是因为 相对说来，修改设计和程序需要的工作量比较小， 错误传播范围小，需要扩充功能时能够“插入”模块。
（2）详细设计。详细设计阶段的根本目标是确定 应该怎样具体地实现所要求的系统，也就是说，经 过这个阶段的设计工作，应该得出对目标系统的精 确描述，从而在编码阶段可以把这个描述直接翻译 成用某种程序设计语言书写的程序。 详细设计阶段的任务还不是具体地编写程序，而是 要设计出程序的“蓝图”，结果基本上决定了最终 的程序代码的质量。
软件工程 第四章 概要设计
4.控制耦合 模块之间传递的不是数据信息，而是控制信息如标志、开关量，一个模块控制了另一模块 的功能。
第4章
4.4 模块的独立性
15
4.4.1 耦合性（Coupling）
5.外部耦合 一组模块都访问同一全局简单变量，而且不通过参数表传递该全局变量的信息，则称之为 外部耦合。 6.公共耦合
若一组模块都访问同一全局数据结构，则称之为公共耦合。公共数据环境可以是全局数据
4
4.2.1 概要设计的任务
概要设计的基本任务是： （1）设计软件系统结构； （2）数据结构及数据库设计； （3）编写概要设计文档；
（4）评审概要设计文档。
第4章
4.2 概要设计的任务与步骤
5
4.2.2 概要设计的步骤
概要设计的一般步骤如下： 1.选定体系结构 2.确定设计方案 3.设计软件结构
4.数据结构及数据库设计
（2）一个模块不通过正常入口而直接转入到另一个模块的内部;
（3）两个模块有一部分代码重叠（该部分代码具有一定的独立功能）; （4）一个模块有多个入口。
第4章
4.4 模块的独立性
17
4.4.2 内聚性（Cohesion）
一个模块内各个元素彼此结合的紧密程度用内聚（或称聚合）来度量。一个理想的模块只
完成一个功能，模块设计的目标之一是尽可能高内聚。
第4章
4.4 模块的独立性
21
4.4.2 内聚性（Cohesion）
5.通信内聚
指模块内所有处理功能都通过公用数据而发生关系。即模块内各个组成部分都使用相同的 输入数据或产生相同的输出结果。
第4章
4.4 模块的独立性
22
4.4.2 内聚性（Cohesion）
第4章
4.4 模块的独立性
15
4.4.1 耦合性（Coupling）
5.外部耦合 一组模块都访问同一全局简单变量，而且不通过参数表传递该全局变量的信息，则称之为 外部耦合。 6.公共耦合
若一组模块都访问同一全局数据结构，则称之为公共耦合。公共数据环境可以是全局数据
4
4.2.1 概要设计的任务
概要设计的基本任务是： （1）设计软件系统结构； （2）数据结构及数据库设计； （3）编写概要设计文档；
（4）评审概要设计文档。
第4章
4.2 概要设计的任务与步骤
5
4.2.2 概要设计的步骤
概要设计的一般步骤如下： 1.选定体系结构 2.确定设计方案 3.设计软件结构
4.数据结构及数据库设计
（2）一个模块不通过正常入口而直接转入到另一个模块的内部;
（3）两个模块有一部分代码重叠（该部分代码具有一定的独立功能）; （4）一个模块有多个入口。
第4章
4.4 模块的独立性
17
4.4.2 内聚性（Cohesion）
一个模块内各个元素彼此结合的紧密程度用内聚（或称聚合）来度量。一个理想的模块只
完成一个功能，模块设计的目标之一是尽可能高内聚。
第4章
4.4 模块的独立性
21
4.4.2 内聚性（Cohesion）
5.通信内聚
指模块内所有处理功能都通过公用数据而发生关系。即模块内各个组成部分都使用相同的 输入数据或产生相同的输出结果。
第4章
4.4 模块的独立性
22
4.4.2 内聚性（Cohesion）
软件工程第4章
试用有穷状态机说明上述的图书流通系统。
4-5 试用Petri网说明第4题所述图书馆中一本书的循 环过程。在规格说明中应该包括操作H、C及R。
4-6 试用Z语言对第4题所述图书馆图书流通系统做一 个完整的规格说明。
•
生 活 中 的 辛 苦阻挠 不了我 对生活 的热爱 。20.12.2820.12.28Monday, December 28, 2020
第二条和第三条规则，分别对应于电梯即将下降 或者没有待处理的请求的情况。
4.2.3 评价
有穷状态机方法采用了一种简单的格式来描述规 格说明：
当前状态+事件+
这种形式的规格说明易于书写、易于验证，而且 可以比较容易地把它转变成设计或程序代码。
有穷状态机方法比数据流图技术更精确
4.3 Petri网
4.3.1 概念
所有按钮的集合，因此，Z规格说明开始于： 〔Button〕 2. 状态定义 一个Z规格说明由若干个“格(schema)”组成，每个 格含有变量说明和限定变量取值范围的谓词。例如， 格S的格式如图4.12所示。
图4.12 Z格S的格式
3. 初始状态 对于电梯问题来说，抽象的初始状态为：
ˆ Button_Init Button_State｜pushed=Φ〕
第4章 形式化说明技术
4.1 概述 4.2 有穷状态机 4.3 Petri网 4.4 Z语言 4.5 小结 习题
按照形式化的程度，可以把软件工程使用的方 法划分成非形式化、半形式化和形式化3类:
• 用自然语言描述需求规格说明，是典型的非形式 化方法。
• 用数据流图或实体-联系图建立模型，是典型的 半形式化方法。
有穷状态机对本产品进行规格说明: 这个问题中有两个按钮集。
4-5 试用Petri网说明第4题所述图书馆中一本书的循 环过程。在规格说明中应该包括操作H、C及R。
4-6 试用Z语言对第4题所述图书馆图书流通系统做一 个完整的规格说明。
•
生 活 中 的 辛 苦阻挠 不了我 对生活 的热爱 。20.12.2820.12.28Monday, December 28, 2020
第二条和第三条规则，分别对应于电梯即将下降 或者没有待处理的请求的情况。
4.2.3 评价
有穷状态机方法采用了一种简单的格式来描述规 格说明：
当前状态+事件+
这种形式的规格说明易于书写、易于验证，而且 可以比较容易地把它转变成设计或程序代码。
有穷状态机方法比数据流图技术更精确
4.3 Petri网
4.3.1 概念
所有按钮的集合，因此，Z规格说明开始于： 〔Button〕 2. 状态定义 一个Z规格说明由若干个“格(schema)”组成，每个 格含有变量说明和限定变量取值范围的谓词。例如， 格S的格式如图4.12所示。
图4.12 Z格S的格式
3. 初始状态 对于电梯问题来说，抽象的初始状态为：
ˆ Button_Init Button_State｜pushed=Φ〕
第4章 形式化说明技术
4.1 概述 4.2 有穷状态机 4.3 Petri网 4.4 Z语言 4.5 小结 习题
按照形式化的程度，可以把软件工程使用的方 法划分成非形式化、半形式化和形式化3类:
• 用自然语言描述需求规格说明，是典型的非形式 化方法。
• 用数据流图或实体-联系图建立模型，是典型的 半形式化方法。
有穷状态机对本产品进行规格说明: 这个问题中有两个按钮集。
《软件工程》第4章软件总体设计
《软件工程》第4章软件总体设计软件总体设计是软件工程的一个重要环节，它涉及到软件系统的整体结构和架构的定义，以及软件模块之间的关系和接口的设计。
软件总体设计的目标是确保软件系统能够满足用户需求，并且具有高性能和可扩展性，同时保证系统的可维护性和可测试性。
软件总体设计的过程包括以下几个步骤：1.确定系统的功能需求：根据用户需求和系统分析的结果，定义系统应该具备的功能和特性。
2.划分系统结构：将系统划分为多个模块和子系统，确定各个模块之间的关系和层次结构。
3.定义模块接口：对每个模块定义清晰的接口，包括输入参数、输出参数和功能描述，以便模块之间的协作和集成。
4.设计系统架构：选择合适的架构风格和模式，确定系统的整体结构和组成，包括数据流、控制流和模块之间的通信。
5.设计数据结构和算法：根据系统需求和性能要求，设计合适的数据结构和算法，以满足系统的功能和性能要求。
6.设计系统界面：设计系统与用户和外部系统的界面，包括图形界面、命令行界面和数据交换接口。
7.考虑系统安全性和可靠性：在设计阶段考虑系统的安全性和可靠性需求，设计对应的安全和可靠性机制。
8.进行评审和验证：对软件总体设计进行评审和验证，确保设计的可行性和完整性。
软件总体设计的核心是系统架构设计，系统架构设计要考虑系统的功能需求、性能要求、可扩展性、可维护性、可测试性等因素。
常用的软件架构风格包括层次架构、客户端-服务器架构、分布式架构、面向服务的架构等。
选择合适的架构风格可以提高系统的灵活性和可维护性。
在软件总体设计过程中，还需要考虑到软件的适应性和可移植性。
软件应该能够适应不同平台和操作系统的要求，并能够方便地移植到其他环境中。
为了提高软件的可移植性，可以采用标准化的接口和协议，避免使用具体的硬件和操作系统依赖。
此外，软件总体设计还需要考虑到系统的可维护性和可测试性。
软件系统通常需要进行修改和维护，因此设计时需要考虑到系统的可扩展性和模块之间的解耦。
软件工程实用案例 第4章 结构化需求分析
2 项目前景 2.1 前景概述 2.2 主要特性
3项目范围 3.1 第一版范围 3.2 后续版本范围 3.3 限制与排除
4项目环境 4.1 操作环境 4.2 涉众 4.3 项目属性
词汇表 参考资料 附录
4.3 需求获取
4.3.3 选择信息的来源
• 1. 涉众
• 包括用户、客户、领域专家、用户替代源(市场人员、销售人员) 等。
4.4 需求分析
4.4.1 过程建模
4.4.1.1 数据流图
3. 分层结构 （3）N层图
图4-12 功能分解示意图
4.4 需求分析
4.4.1 过程建模
4.4.1.1 数据流图
3. 分层结构 （3）N层图
图4-13 食物订货系统的1层图
4.4 需求分析
4.4.1 过程建模
4.4.1.2 微规格说明
正式规定文档所需具有的条件或能力。
(3) 对(1)或(2)所描述的条件或能力的文档化表述。 其中，(1)是从用户角度定义的，(2)是从开发人员、
系统的角度定义的。
4.1 需 求
4.1.2 需求的层次
需求通常体现为三个层次：业务需求、用户需求和系 统需求。
4.1 需 求
4.1.2 需求的层次
4.3 需求获取
4.3.2 定义项目前景和范围
• 1.明确问题
P1 决策者：生产的废品过多。
• 2.发现业务需求
BR1：提供销售订单的准确性，减少因此而产生废品。
BR2：提供销售订单的准确性，在使用后3个月内，减少50%因此而产生 的废品。
4.3 需求获取
4.3.2 定义项目前景和范围
• 3.定义解决方案及系统特性
4.3 需求获取
4.3.4 需求获取的方法
3项目范围 3.1 第一版范围 3.2 后续版本范围 3.3 限制与排除
4项目环境 4.1 操作环境 4.2 涉众 4.3 项目属性
词汇表 参考资料 附录
4.3 需求获取
4.3.3 选择信息的来源
• 1. 涉众
• 包括用户、客户、领域专家、用户替代源(市场人员、销售人员) 等。
4.4 需求分析
4.4.1 过程建模
4.4.1.1 数据流图
3. 分层结构 （3）N层图
图4-12 功能分解示意图
4.4 需求分析
4.4.1 过程建模
4.4.1.1 数据流图
3. 分层结构 （3）N层图
图4-13 食物订货系统的1层图
4.4 需求分析
4.4.1 过程建模
4.4.1.2 微规格说明
正式规定文档所需具有的条件或能力。
(3) 对(1)或(2)所描述的条件或能力的文档化表述。 其中，(1)是从用户角度定义的，(2)是从开发人员、
系统的角度定义的。
4.1 需 求
4.1.2 需求的层次
需求通常体现为三个层次：业务需求、用户需求和系 统需求。
4.1 需 求
4.1.2 需求的层次
4.3 需求获取
4.3.2 定义项目前景和范围
• 1.明确问题
P1 决策者：生产的废品过多。
• 2.发现业务需求
BR1：提供销售订单的准确性，减少因此而产生废品。
BR2：提供销售订单的准确性，在使用后3个月内，减少50%因此而产生 的废品。
4.3 需求获取
4.3.2 定义项目前景和范围
• 3.定义解决方案及系统特性
4.3 需求获取
4.3.4 需求获取的方法
软件工程第4章习题解答
解：（1）判定表：
说明：1，每一笔交易有3种属性：“交易金额”、“每股售价”、“股数”。
2，“交易总额”有3种值；“每股售价”有3种值；“股数”有2种值。所以每笔交易有18种状态。(表有19列，第1列是说明列)
3，每种状态有一个决策公式。判定表中的决策方案有18行。
4，每个计算公式中只有一个变量“交易金额”，设为a。
教师的工资档案存储在行政办公室的磁带上，档案中有目前的年工资、赡养的人数、雇佣日期等信息。需要写一个计算程序计算并印出每名教师的原有工资和调整后的新工资。要求：
⑴画出此系统的数据流图；
⑵写出需求说明；
⑶设计上述的工资调整程序(要求用判断表描述)，设计时请分别采用下述两种算法，并比较这两种算法的优缺点；
set START to (I+1)
else if TABLE(I) > ITEM then
set FINISH to (I－1)
endif
enddo
if TABLE(I) = ITEM or TABLE(START) = ITEM or TABLE(FINISH) = ITEM then
set FLAG to 1
解：
⑴ 系统的数据流图
⑵ 需求说明：（略）
⑶ 程序框图：
算法说明：1 此算法是先找出工资少于$26,000的人, 再进行工资调整，属算法a
2 算法a适于数据库的记录不太多的情况，在数据库中查找较费时。
但是，调整系统的主要部分少一个判断，结构清晰一些。
3 算法b适于数据库的记录较多的情况，利用数据库的排序功能可很快地将教师的档案数据按工资大小排好序，调整程序只对前若干个记录进行操作。这个算法对于修改数据库回更便捷些。
交易
说明：1，每一笔交易有3种属性：“交易金额”、“每股售价”、“股数”。
2，“交易总额”有3种值；“每股售价”有3种值；“股数”有2种值。所以每笔交易有18种状态。(表有19列，第1列是说明列)
3，每种状态有一个决策公式。判定表中的决策方案有18行。
4，每个计算公式中只有一个变量“交易金额”，设为a。
教师的工资档案存储在行政办公室的磁带上，档案中有目前的年工资、赡养的人数、雇佣日期等信息。需要写一个计算程序计算并印出每名教师的原有工资和调整后的新工资。要求：
⑴画出此系统的数据流图；
⑵写出需求说明；
⑶设计上述的工资调整程序(要求用判断表描述)，设计时请分别采用下述两种算法，并比较这两种算法的优缺点；
set START to (I+1)
else if TABLE(I) > ITEM then
set FINISH to (I－1)
endif
enddo
if TABLE(I) = ITEM or TABLE(START) = ITEM or TABLE(FINISH) = ITEM then
set FLAG to 1
解：
⑴ 系统的数据流图
⑵ 需求说明：（略）
⑶ 程序框图：
算法说明：1 此算法是先找出工资少于$26,000的人, 再进行工资调整，属算法a
2 算法a适于数据库的记录不太多的情况，在数据库中查找较费时。
但是，调整系统的主要部分少一个判断，结构清晰一些。
3 算法b适于数据库的记录较多的情况，利用数据库的排序功能可很快地将教师的档案数据按工资大小排好序，调整程序只对前若干个记录进行操作。这个算法对于修改数据库回更便捷些。
交易
软件工程导论第四章 概要设计
模式4：共享数据模式
共享数据系统以一个或多个数据库 / 数据仓库为中心进行 组织，其它部件可以从中读写存储的数据。共享数据系统还 提供并发访问、容错处理、访问权限控制等功能。 典型的共享数据系统包括： a. 数据库 b. 知识库 c. 源代码控制程序
模式5：信息系统模式
现代信息系统平台模式，主要考虑B/S模式。 B/S模式的三层：表示层（presentation），业务 层（business），和数据存储层（data access） 。 B/S模式的优点： a. 架构简化了客户端。它无需象C/S模式那样在 不同的客户机上安装不同的客户应用程序，而只需安 装通用的浏览器软件。 b. 简化了系统的开发和维护。 c. 使用户的操作变得更简单。 d. 特别适用于网上信息发布 。
第四章 概要设计
•4.1软件体系结构 •4.2概要设计任务与步骤 •4.3软件设计的基本概念 •4.4面向数据流的设计方法 •4.5面向数据结构的分析设计方法 •4.6概要设计文档评审
概要设计
一是要覆盖《需求规格说明书》的全部内容, 二是要作为指导详细设计的依据。
概要设计注重于宏观上和框架上的设计，它是软 件系统的总体结构设计、全局数据库(包括数据结 构)设计、外部接口设计、功能部件分配设计、部 件之间的接口设计。 概要设计又称为架构设计。 • 用于描述系统最顶的结构和组织形式，标识出软 件的各个组成部分。
2．子系统和模块的区别 （1）一个子系统独立一个构成系统，不依赖 于其他子系统提供的服务。 （2）一个模块通常是一个能提供一个或多个 服务的系统组件。 3．体系结构设计的结果 体系结构设计过程的结果是一个体系结构 的设计文档。
4.1软件体系结构 4.1.1概述
4．体系结构模型 （1）静态结构模型 将子系统或组件作为一个个独立的单元来开发 （2）动态过程模型 给出系统在运行时的过程组成。它与静态模型不 同。 （3）接口模型 定义每个子系统从他们的公共接口能得到的服务。 （4）关系模型 关系模型给出子系统间的数据流的关系。
第4章-实用软件工程(第4版)-陆惠恩-清华大学出版社
❖ 结构化程序设计（Structured Programming ,SP）
❖ 1、采用自顶向下、逐步求精的程序设计方法； ❖ 2、仅采用顺序、选择、重复三种基本控制结构，每种基本结构只有一个
入口、一个出口；将这三种基本控制结构根据程序的逻辑，嵌套或组合 成结构化程序，完成预定的功能。 ❖ 3、采用主程序员组的组织形式。
【例4.4】用因果图法设计测试用例
某规格说明规定：输入的第一列字符必须是A或B，第二列字符必须是一个数字。 第一、二列都满足条件时执行操作H；如果第一列字符不正确，则给出信息L； 如果第二列字符不正确，则给出信息R。
根据上述要求画出因果图，并设计测试用例。
例4.4 的因果图
例4.4的判定表
《实用软件工程（第3版）》陆惠恩编著
源程序文档编写规则 1．源程序文档书写规则：含义鲜明的标识符名称、适当的注解和程序布局阶梯式。 2. 数据说明：易于理解、便于查阅 3. 语句构造要简单明了 4. 输入输出语句要合理 5. 程序效率要满足用户需求。
▪ 程序设计主要应考虑的是程序的正确性、可理解性、可测试性和可维护性。
4.2 软件测试目标
《实用软件工程（第3版）》陆惠恩编著
8
程序流程图
《实用软件工程（第3版）》陆惠恩编著
9
程序图
《实用软件工程（第3版）》陆惠恩编著
10
计算程序的环行复杂度：
方法1:图中有4个线性无关的有向环：R1、R2、R3、R4。 在图4.4（b）中，实线弧数为14,节点数为12。因此，环行复杂度为 V(G)=14-12+2=4
《实用软件工程（第3版）》陆惠恩编著
5
4.5 设计测试方案
测试方案包括三个内容:
要测试的功能
❖ 1、采用自顶向下、逐步求精的程序设计方法； ❖ 2、仅采用顺序、选择、重复三种基本控制结构，每种基本结构只有一个
入口、一个出口；将这三种基本控制结构根据程序的逻辑，嵌套或组合 成结构化程序，完成预定的功能。 ❖ 3、采用主程序员组的组织形式。
【例4.4】用因果图法设计测试用例
某规格说明规定：输入的第一列字符必须是A或B，第二列字符必须是一个数字。 第一、二列都满足条件时执行操作H；如果第一列字符不正确，则给出信息L； 如果第二列字符不正确，则给出信息R。
根据上述要求画出因果图，并设计测试用例。
例4.4 的因果图
例4.4的判定表
《实用软件工程（第3版）》陆惠恩编著
源程序文档编写规则 1．源程序文档书写规则：含义鲜明的标识符名称、适当的注解和程序布局阶梯式。 2. 数据说明：易于理解、便于查阅 3. 语句构造要简单明了 4. 输入输出语句要合理 5. 程序效率要满足用户需求。
▪ 程序设计主要应考虑的是程序的正确性、可理解性、可测试性和可维护性。
4.2 软件测试目标
《实用软件工程（第3版）》陆惠恩编著
8
程序流程图
《实用软件工程（第3版）》陆惠恩编著
9
程序图
《实用软件工程（第3版）》陆惠恩编著
10
计算程序的环行复杂度：
方法1:图中有4个线性无关的有向环：R1、R2、R3、R4。 在图4.4（b）中，实线弧数为14,节点数为12。因此，环行复杂度为 V(G)=14-12+2=4
《实用软件工程（第3版）》陆惠恩编著
5
4.5 设计测试方案
测试方案包括三个内容:
要测试的功能
软件工程考核知识点-第4章-软件概要设计
软件工程考核知识点-第4章-软件概要设计4.1 软件概要设计的基本任务在软件需求分析阶段，已经搞清楚了软件“做什么”的问题，并把这些需求通过规格说明书描述了出来，这也是目标系统的逻辑模型。
进入了设计阶段，要把软件“做什么”的逻辑模型变换为“怎么做”的物理模型，即着手实现软件的需求，并将设计的结果反映在“设计规格说明书”文档中，所以软件设计是一个把软件需求转换为软件表示的过程，最初这种表示只是描述了软件的总的体系结构，称为软件概要设计或结构设计。
4.1.1 基本任务1. 设计软件系统结构(简称软件结构)为了实现目标系统，最终必须设计出组成这个系统的所有程序和数据库(文件)，对于程序，则首先进行结构设计，具体为：(1)采用某种设计方法，将一个复杂的系统按功能划分成模块。
(2)确定每个模块的功能。
(3)确定模块之间的调用关系。
(4)确定模块之间的接口，即模块之间传递的信息。
(5)评价模块结构的质量。
根据以上内容，软件结构的设计是以模块为基础的，在需求分析阶段，已经把系统分成层次结构。
设计阶段，以需求分析的结果为依据，从实现的角度进一步划分为模块，并组成模块的层次结构。
软件结构的设计是概要设计关键的一步，直接影响到下一阶段详细设计与编码的工作软件系统的质量及一些整体特性都在软件结构的设计中决定。
2.数据结构及数据库设计对于大型数据处理的软件系统，除了控制结构的模块设计外，数据结构与数据库设计也是很重要的。
(1)数据结构的设计逐步细化的方法也适用于数据结构的设计。
在需求分析阶段，已通过数据字典对数据的组成、操作约束、数据之间的关系等方面进行了描述，确定了数据的结构特性，在概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。
在概要设计阶段，宜使用抽象的数据类型。
(2)数据库的设计数据库的设计指数据存储文件的设计，主要进行以下几方面设计:①概念设计。
在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用ER模型来表示数据模型，这是一个概念模型。
软件工程第4章概要设计
函数A 函数B 函数C 数据集
通常，通信内聚模块是通过数据流图来定义的。
5.通信内聚(2)
6.功能内聚
一个模块中各个部分都是完成某一具体功能 必不可少的组成部分 或者说该模块中所有部分都是为了完成一项 具体功能而协同工作，紧密联系，不可分割 的 软件结构中应多使用功能内聚类型的模块
内聚类型汇总
5.标记耦合
如果一组模块通过参数表传递信息 这个参数是: 数据结构 字符串 记录 不是简单变量
标记耦合举例 计算水电费
住户情况
计算水费
水费
住户情况
电费
计算电费
“住户情况”是一个数据结构,图中模块都 与此数据结构有关. “计算水费”和“计算电费”本无关,由于 引用了此数据结构产生依赖关系,它们之间 也是标记偶合.
4.2.2 软件结构风格与策略
1.软件结构风格取决于 程序的模块结构表明了程序各个模块的 组织情况，是软件的过程表示 数据的结构表明各个数据之间的关系和 各个数据元素的约束，是软件的信息表 示
2.软件结构的独立性风格
(1).独立性 软件系统中每个模块只涉及软件要求的 具体的子功能, 而和软件系统中其它的 模块的接口是简单的 一个模块和其它模块的独立程度是评价 一个模块设计好坏的重要度量尺度。
例如初始化模块和终止模块。
4.过程内聚
一个模块内部的处理成分是相关的，而且这些处 理必须以特定的次序执行
函数A 函数B 函数C
例如，把流程结构中的循环部分、判定部分、计 算部分分成一个模块，这三个任务组成的模块是 过程内聚模块。
5.通信内聚
如果一个模块内各功能部分都使用了相同的输入数 据，或产生了相同的输出数据，则称之为通信内聚 模块。
通常，通信内聚模块是通过数据流图来定义的。
5.通信内聚(2)
6.功能内聚
一个模块中各个部分都是完成某一具体功能 必不可少的组成部分 或者说该模块中所有部分都是为了完成一项 具体功能而协同工作，紧密联系，不可分割 的 软件结构中应多使用功能内聚类型的模块
内聚类型汇总
5.标记耦合
如果一组模块通过参数表传递信息 这个参数是: 数据结构 字符串 记录 不是简单变量
标记耦合举例 计算水电费
住户情况
计算水费
水费
住户情况
电费
计算电费
“住户情况”是一个数据结构,图中模块都 与此数据结构有关. “计算水费”和“计算电费”本无关,由于 引用了此数据结构产生依赖关系,它们之间 也是标记偶合.
4.2.2 软件结构风格与策略
1.软件结构风格取决于 程序的模块结构表明了程序各个模块的 组织情况，是软件的过程表示 数据的结构表明各个数据之间的关系和 各个数据元素的约束，是软件的信息表 示
2.软件结构的独立性风格
(1).独立性 软件系统中每个模块只涉及软件要求的 具体的子功能, 而和软件系统中其它的 模块的接口是简单的 一个模块和其它模块的独立程度是评价 一个模块设计好坏的重要度量尺度。
例如初始化模块和终止模块。
4.过程内聚
一个模块内部的处理成分是相关的，而且这些处 理必须以特定的次序执行
函数A 函数B 函数C
例如，把流程结构中的循环部分、判定部分、计 算部分分成一个模块，这三个任务组成的模块是 过程内聚模块。
5.通信内聚
如果一个模块内各功能部分都使用了相同的输入数 据，或产生了相同的输出数据，则称之为通信内聚 模块。
《软件工程实用教程》第4章_结构化软件设计
第4 章 結構化軟體設計
3．虛擬機風格 例：解釋器，通過虛擬機特定模組的解釋步驟 如下： 解釋引擎從被解釋的模組中選擇一條指令； 基於這條指令，引擎更新虛擬機內部的狀 態； 上述過程反復執行。
第4 章 結構化軟體設計
特點： 在虛擬機環境中運行的代碼不必須瞭解虛擬 機的具體細節。 一旦運行環境發生變化，只需要重寫虛擬機 本身，而不是整個系統。 通常虛擬機會限制在其中運行的軟體的行為， 特別是那些以實現跨平臺為目的的虛擬機， 如Java虛擬機和.NET CLR。 能夠使系統的結構更具層次性，使用虛擬機 提供的設施編寫的代碼，可以不考慮虛擬機 以外的實際環境，而在正確地實現了這種虛 擬機的環境中執行。
第4 章結構化軟體設計
本章學習內容： 1.瞭解概要設計的任務與過程 2.掌握結構化設計技術的基本原理與準則 3.掌握面向數據流分析的設計方法 4.瞭解面向數據的設計方法 5.掌握資料庫設計原則和步驟 6.瞭解常用的詳細設計工具 7.瞭解概要設計說明書的基本內容
第4 章 結構化軟體設計
4.1 概要設計的任務與過程 概要設計的目標是概要地說明軟體 應該怎樣實現，即解決軟體系統總 體結構設計的問題，包括軟體系統 的結構、模組劃分、模組功能和模 組間的聯繫等。
第4 章 結構化軟體設計
4.2.1 現代體系結構模型的基本概念
1．模式：是針對特定問題的成功解決方案，是指形成 了一種趨於固定的結構形式。 結構模式表達了軟體系統的基本結構組織形式或結 構方案，包含了一組預定義的子系統，規定了這些 子系統的責任，同時還提供了用於組織和管理這些 子系統的規則和嚮導。 設計模式為軟體系統的子系統、構件或者構件之間 的關係提供一個精練後的解決方案，描述了特定環 境下，用於解決通用軟體設計問題的構件以及這些 構件相互通信時的可重現結構。
软件工程课件之第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】在需求分析中常见的权限控制问题，一般的 用户只可以使用一些常规的操作，如查询等，而管理员 除了常规操作之外还需要进行一些系统管理工作，如一 些关键数据的增加、删除、修改等，操作员既可以进行 常规操作又可以进行一些配置操作。
软件工程-第四章解读
在软件开发过程中使用数学，可以在不同的软件工程活动 之间平滑地过渡（系统规格说明、系统设计、程序代码） 提供了高层确认的手段
可以使用数学方法证明，设计符合规格说明，程序代码正确 地实现了设计结果
2018/11/29 5
4.1 概 述
4.1.3 应用形式化方法的准则
应该选用适当的表示方法，选择适用于当前项
当前状态〔菜单〕+事件〔所选择的项〕+谓词 =>
2018/11/29
13
4.2 有穷状态机(FSM/FSA)
在一幢m层的大厦中需要一套控制n部电梯的产品， 要求这n部电梯按照约束条件C1，C2和C3在楼层 间移动
C1：每部电梯内有m个按钮，每个按钮代表一个楼层。当 按下一个按钮时该按钮指示灯亮，同时电梯驶向相应的楼 层，到达按钮指定的楼层时指示灯熄灭 C2：除了大厦的最低层和最高层之外，每层楼都有两个 按钮分别请求电梯上行和下行。这两个按钮之一被按下时 相应的指示灯亮，当电梯到达此楼层时灯熄灭，电梯向要 求的方向移动 C3：当对电梯没有请求时，它关门并停在当前楼层
2018/11/29 8
4.2 有穷状态机(FSM/FSA)
state
transition condition transition
图4.1 保险箱的状态转换图
2018/11/29 9
State Transition Table
2018/11/29
10
FSM/FSA的数学模型
FSM可以表示为一个5元组（J，K，T，S，F）
软件工程导论
第四章 形式化说明技术 (Formal Description Technique，FDT)
4.1 概述 4.2 有穷状态机(FSM/FSA) 4.3 Petri网 (Petri Nets) 4.4 Z语言 (Z Notation) 4.5 小结
软件工程导论 第4章 形式化说明技术1
形式化说明技术按照形式化的程度，可以把软件工程使用的方法划分成非形式化，半形式化和形式化3类。
用自然语言描述需求规格说明，是典型的非形式化方法。
用数据流图或实体—联系图建立模型，是典型的半形式化方法。
所谓形式化方法，是描述系统性质的基于数学的技术，也就是说，如果一种方法有坚实的数学基础，那么它就是形式化的。
4.1 概述4.1.1 非形式化方法的缺点用自然语言书写的系统规格说明书，可能存在矛盾、二义性、含糊性、不完整性及抽象层次混乱等问题。
所谓矛盾是指一组相互冲突的陈述。
例如，规格说明书的某一部分可能规定系统必须监控化学反应容器中的温度，而另一部分（可能由另一位系统分析员撰写）却规定只监控在一定范围内的温度。
如果这两个相互矛盾的规定写在同一页纸上，自然很容易查出，不幸的是，它们往往出现在相距几十页甚至数百页的两页纸中。
二义性是指读者可以用不同方式理解的陈述。
例如，下面的陈述就是具有二义性：“操作员标识由操作员姓名和密码组成，密码由6位数字构成。
当操作员登录进系统时它被存放在注册文件中。
”在上面这段陈述中，“它”到底代表“密码”还是“操作员标识”，不同的人往往有不同的理解。
系统规格说明书是很庞大的文档，因此，几乎不可避免地会出现含糊性。
例如，我们可能经常在文档中看到类似下面这样的需求：“系统界面应该是对用户友好的。
”实际上，这样笼统的陈述并没有给出任何有用的信息。
不完整性可能是在系统规格说明中最常遇到的问题之一。
例如，考虑下述的系统功能需求：“系统每小时从安放在水库中的深度传感器获取一次水库深度数据，这些数值应该保留6个月。
”假设在系统规格说明书中还规定了某个命令的功能：“AVERAGE命令的功能是，在PC机上显示由某个传感器在两个日期之间获取的平均水深。
”如果在规格说明书中对这个命令的功能没有更多的描述，那么，该命令的细节是严重不完整的，例如，对该命令的描述没有告诉我们，如果用户给定的日期是在当前日期的6个月之前，那么系统应该做什么。
软件工程导论第4章 形式化说明技术
形式化方法的分类
4.1 续
形式化方法是应用严格的形式符号和数学方法定义 或描述目标软件系统需求规格说明的一种方法。
根据对需求规格说明的定义方式分类：
⒈面向模型的形式方法。
又称基于状态描述的形式方法。 基本思想：利用域、元组、集合、序列、映射、包等这些已知特性
的数学抽象概念来为目标软件系统的状态特征和行为特征构造形式 语义模型。语义模型就作为目标软件系统需求规格的形式说明。 主要代表：VDM方法（维也纳开发方法）、Z语言方法等。
⒉代数构造形式方法。
目标软件系统的需求规格说明提供一些特殊的构造机制，并以代数 构造方式描述目标系统的结构、功能。
软件形式开发方法
4.1 续
将形式化方法应用于软件开发过程称为软件形式 开发方法。
首先，在需求分析阶段的信息收集和信息分析两 项工作中，采用形式化的规格说明语言构造目标 软件系统严格的形式需求规格说明即形式语义。
状态 • EBON(e,f)：电梯按钮(e,f)打开 • EBOFF(e,f)：电梯按钮(e,f)关闭
例3：电梯系统
事件
4.2 续
• EBP（e，f） ：电梯按钮（e，f）被按下。
• EAF （e，f） ：电梯e到达f层。
谓词
V(e,f)=S(U,e,f)or S(D,e,f)or S(N,e,f)
信息的描述过程中遗留了某个方面。
抽象层次混乱
在非常抽象的陈述中混进了一些关于细节的低层陈述。
形式化方法的主要思想
4.1 续
形式化需求分析方法的主要思想，是利用形式化 规格说明语言严格地定义用户需求，并采用数学 推演的方法证明需求定义的性质。
从某种意义上讲，形式化方法是克服需求分析阶 段中主要困难（不精确性、不一致性和不完全性） 的有效途径。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
7
• 应该建立详尽的文档。
• 不应该放弃质量标准。
• 不应该盲目依赖形式化方法。
• 应该测试、测试再测试。
• 应该重用。
2013-7-10
湖南科技大学 计算机学院 戴祖雄
8
4.2 有穷状态机
利用有穷状态机可以准确地描述一个系统,因
此是表达规格说明的一种形式化方法。
4.2.1
本概念。
基本概念
RL：电梯按钮或楼层按钮被按下进入打开
状态,登录需求。
2013-7-10
湖南科技大学 计算机学院 戴祖雄
24
最后,给出电梯的状态转换规则。为简单起 见,这里给出的规则仅发生在关门之时。 S(U,e,f)+DC(e,f)M(U,e,f+1)
S(D,e,f)+DC(e,f)M(D,e,f-1)
EBON(e,f)：电梯按钮(e,f)打开 EBOFF(e,f)：电梯按钮(e,f)关闭 如果电梯按钮(e,f)发光且电梯到达f层,该按钮将熄灭。 相反如果按钮熄灭,则按下它时,按钮将发光。上述描述中包 含了两个事件,它们分别是：
2013-7-10
湖南科技大学 计算机学院 戴祖雄
15
图4.2 电梯按钮的状态转换图
2013-7-10
湖南科技大学 计算机学院 戴祖雄
10
图4.1 保险箱的状态转换图
2013-7-10
湖南科技大学 计算机学院 戴祖雄
11
表 14.1 保险箱的状态转换表 当前状态 次态 保险箱锁定 转盘动作 1L A 1R 报警 2L 报警 2R 报警 3L 报警 3R 报警
A 报警 报警 报警 报警 报警 B
2013-7-10
湖南科技大学 计算机学院 戴祖雄
22
图4.4 电梯的状态转换图
2013-7-10
湖南科技大学 计算机学院 戴祖雄
23
图4.4中包含了下述三个可触发状态发生
改变的事件: DC(e,f)：电梯e在楼层f关上门。 ST(e,f)：电梯e靠近f层时触发传感器,电 梯控制器决定在当前楼层电梯是否停下。
2013-7-10
湖南科技大学 计算机学院 戴祖雄
16
EBP(e,f)：电梯按钮(e,f)被按下 EAF(e,f)：电梯e到达f层 为了定义与这些事件和状态相联系的状态转换规 则,需要一个谓词V,(e,f),它的含义如下： V(e,f)：电梯e停在f层 如果电梯按钮(e,f)处于关闭状态[当前状态],而 且电梯按钮(e,f)被按下[事件],而且电梯e不在f层[谓 词],则该电梯按钮打开发光[下个状态]。状态转换规 则的形式化描述如下： EBOFF(e,f)+EBP(e,f)+not V(e,f)EBON(e,f) 反之,如果电梯到达f层,而且电梯按钮是打开的,于 是它就会熄灭。这条转换规则可以形式化地表示为： EBON(e,f)+EAF(e,f) EBOFF(e,f)
当前状态[菜单]+事件[所选择的项]+谓词下个状态
2013-7-10
湖南科技大学 计算机学院 戴祖雄
14
4.2.2
例子(电梯问题)
电梯按钮的状态转换图如图4.2所示。令EB(e,f)表示按
下电梯e内的按钮并请求到f层去。EB(e,f)有两个状态,分别
是按钮发光(打开)和不发光(关闭)。更精确地说,状态是:
2013-7-10
湖南科技大学 计算机学院 戴祖雄
27
4.3 Petri网
4.3.1 基本概念
下面通过一个简单例子介绍有穷状态机的基
2013-7-10
湖南科技大学 计算机学院 戴祖雄
9
一个保险箱上装了一个复合锁，锁有三个 位置，分别标记为1、2、3，转盘可向左(L)或 向右(R)转动。这样，在任意时刻转盘都有6种 可能的运动，即1L、1R、2L、2R、3L和3R。 保险箱的组合密码是1L、3R、2L，转盘的任何 其他运动都将引起报警。图4.1描绘了保险箱的 状态转换情况。 图4.1是一个有穷状态机的状态转换图。 状态转换并不一定要用图形方式描述，表4.1的 表格形式也可以表达同样的信息。
T是一个从(J-F)×K到J的转换函数；
S∈J,是一个初始状态；
FJ,是终态集。
2013-7-10
湖南科技大学 计算机学院 戴祖雄
13
当前状态[菜单]+事件[所选择的项]下个状态
为了对一个系统进行规格说明,通常都需要 对有穷状态机做一个很有用的扩展,即在前述的 5元组中加入第6个组件——谓词集P,即把有穷状 态机扩展为一个6元组,其中每个谓词都是系统 全局状态Y的函数。转换函数T现在是一个从(JF)×K×P到J的函数。现在的转换规则形式如下：
2013-7-10
湖南科技大学 计算机学院 戴祖雄
26
有穷状态机方法比数据流图技术更精确, 而且和它一样易于理解。不过,它也有缺点： 在开发一个大系统时三元组(即状态、事件、 谓词)的数量会迅速增长。此外,和数据流图方 法一样,形式化的有穷状态机方法也没有处理 定时需求。下节将介绍的Petri网技术,是一种 可处理定时问题的形式化方法。
在讨论电梯按钮状态转换规则时定义的谓 词V(e,f),可以用谓词S(d,e,f)重新定义如下： V(e,f)=S(U,e,f)or S(D,e,f)or S(N,e,f)
2013-7-10
湖南科技大学 计算机学院 戴祖雄
21
下面定义电梯的三个状态： M(d,e,f)：电梯e正沿d方向移动,即将到达的是第f层；
FBON(d,f)+EAF(1··n,f)+S(d,1··n,f)FBOFF(d,f) 其中,d=UorD。
2013-7-10
湖南科技大学 计算机学院 戴祖雄
20
也就是说,如果在f层请求电梯向d方向运 动的楼层按钮处于关闭状态,现在该按钮被按下, 并且当时没有正停在f层准备向d方向移动的电 梯,则该楼层按钮打开。反之,如果楼层按钮已 经打开,且至少有一部电梯到达f层,该部电梯将 朝d方向运动,则按钮将关闭。
其中1··n表示或为1或为2…或为n。
2013-7-10
湖南科技大学 计算机学院 戴祖雄
18
图4.3 楼层按钮的状态转换图
2013-7-10
湖南科技大学 计算机学院 戴祖雄
19
为了定义与这些事件和状态相联系的状态转换规 则,同样也需要一个谓词,它是S(d,e,f),它的定义如下。 S(d,e,f)：电梯e停在f层并且移动方向由d确定 为向上(d=U)或向下(d=D)或待定(d=N)。 这个谓词实际上是一个状态,形式化方法允许把 事件和状态作为谓词对待。 使用谓词S(d,e,f),形式化转换规则为： FBOFF(d,f)+FBP(d,f)+not S(d,1··n,f)FBON(d,f)
S(N,e,f)+DC(e,f)W(e,f)
第一条规则表明,如果电梯e停在f层准备向 上移动,且门已经关闭,则电梯将向上一楼层移动。 第二条和第三条规则,分别对应于电梯即将下降 或者没有待处理的请求的情况。
2013-7-10
湖南科技大学 计算机学院 戴祖雄
25
4.2.3
评价
有穷状态机方法采用了一种简单的格式来描述规 格说明： 当前状态+事件+谓词下个状态 这种形式的规格说明易于书写、易于验证,而且 可以比较容易地把它转变成设计或程序代码。事实上, 可以开发一个CASE工具把一个有穷状态机规格说明直 接转变为源代码。维护可以通过重新转变来实现,也就 是说,如果需要一个新的状态或事件,首先修改规格说 明,然后直接由新的规格说明生成新版本的产品。
教学内容 4.1 概述 4.2 有穷状态机
4.3 Petri网
4.4 Z语言 4.5 小结
2013-7-10
湖南科技大学 计算机学院 戴祖雄
3
第4章 形式化说明技术
根据形式化的程度,可以把软件工程方法 划分成非形式化、半形式化和形式化三类。使 用自然语言描述需求规格说明,是典型的非形 式化方法。使用数据流图或实体—关系图等图 形符号建立模型,是典型的半形式化方法。 用于开发计算机系统的形式化方法,是描 述系统性质的基于数学的技术,也就是说,如果 一个方法有坚实的数学基础,那么它就是形式化 的。
2013-7-10
湖南科技大学 计算机学院 戴祖雄
6
4.1.3
应用形式化方法的准则
应用形式化方法的几条准则:
• 选择适用于当前项目的符号系统。
• 应该形式化,但不方法的顾问。
• 不要放弃传统的开发方法。
2013-7-10
湖南科技大学 计算机学院 戴祖雄
2013-7-10
湖南科技大学 计算机学院 戴祖雄
4
4.1 概述
4.1.1 非形式化方法的缺点
基本上使用自然语言描述的系统规格 说明,可能存在矛盾、二义性、含糊性、不 完整性以及抽象层次混杂等问题。
2013-7-10
湖南科技大学 计算机学院 戴祖雄
5
4.1.2
形式化方法的优点
数学最有用的性质之一是,它能够简洁、准确地 描述物理现象、对象或动作的结果,因此是理想的建 模工具。 在软件开发过程中使用数学的另一个优点是,可 以在软件工程活动之间平滑地过渡。不仅功能规格 说明,而且系统设计也可以用数学表达,当然,程序代 码也是一种数学符号。 数学作为软件开发工具的最后一个优点是,它提 供了高层确认的手段。可以使用数学方法证明,设计 符合规格说明,程序代码正确地反映了设计结果。
S(d,e,f)：电梯e停在f层,将朝d方向移动(尚未关门)；
W(e,f)：电梯e在f层等待(已关门)。 其中S(d,e,f)状态已在讨论楼层按钮时定义过,但是, 现在的定义更完备一些。 图4.4是电梯的状态转换图。注意,三个电梯停止状 态S(U,e,f)、S(N,e,f)和S(D,e,f)已被组合成一个大的状态, 这样做的目的是减少状态总数以简化流图。