软件工程图解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. 验证需求的现实性
《软件工程》PPT课件
第四课时
第一章第四课时
喷泉模型 软件工程的任务与研究范围 软件开发的原则与开发方法
返回
喷泉模型
瀑布模型要求在软件开发的初期就完全确定软件的需求,这在很多 情况下往往是做不到的.螺旋模型试图克服瀑布模型的这一不足.SM 把软件开发过程安排为逐步细化的螺旋周期序列,每经历一个周期, 系统就细化和完善一些.SM每—螺旋周期由六个步骤组成： <1> 确定任务目标： 根据初始需求分析项目计划,确定任务目标、可选 方案和限制.<2>选择对象：对各种软硬件设备、开发方法、技术、 开发工具、人员、开发管理等对象进行选择：并决定软件是进行研 制、购买还是利用现有的.<3>分析约束条件：软件开发的时间、经 费等限制条件.<4>风险分析：评估目标、对象、约束条件三者之间 的联系,列出可能出．现的问题及问题的严重程度等,把最重要的问 题作为尚未解决的关键问题的风险.<5>制定消除风险的方法：应有 详尽的说明和周密的计划,并估计可能产生的后果.依此来开发软件, 为制订下一周期的计划打下基础.<6>制定下一周期的工作计划：在 第一个螺旋周期,确定目标、选择对象、分析约束,通过风险分析制 订消除风险的方法,初步开发原型1,制定系统生存周期计划.
软件工程的任务与研究范围
•软件产品的特点 •软件工程的研究内容与方法 •软件工具与软件支撑环境 •软件管理
软件开发的原则与方法
•软件开发的原则 • 自顶向下与模块结构 •软件开发的方法 •1.非自动形式的系统开发方法 •〔1〕系统流程图〔2〕结构分析法〔3〕结构化设计法 •〔4〕数据结构法〔5〕层次输入——处理——输出方法<HIPO法> • 2.半自动形式的系统开发方法 •〔1〕软件需求工程法〔2〕问题说明语言与分析法 • 3. 自动形式的系统开发方法 〔HOS方法〕：由计算机自动确定规 范、自动分析、自动编程、自动执行与模拟,以规范语言AXES、资 源分配工具RTA为工具.能自动进行分析、设计,工作量少、设计规范, 也能自动进行修改和维护.该方法适用于系统分析和设计.
第一章第四课时
喷泉模型 软件工程的任务与研究范围 软件开发的原则与开发方法
返回
喷泉模型
瀑布模型要求在软件开发的初期就完全确定软件的需求,这在很多 情况下往往是做不到的.螺旋模型试图克服瀑布模型的这一不足.SM 把软件开发过程安排为逐步细化的螺旋周期序列,每经历一个周期, 系统就细化和完善一些.SM每—螺旋周期由六个步骤组成： <1> 确定任务目标： 根据初始需求分析项目计划,确定任务目标、可选 方案和限制.<2>选择对象：对各种软硬件设备、开发方法、技术、 开发工具、人员、开发管理等对象进行选择：并决定软件是进行研 制、购买还是利用现有的.<3>分析约束条件：软件开发的时间、经 费等限制条件.<4>风险分析：评估目标、对象、约束条件三者之间 的联系,列出可能出．现的问题及问题的严重程度等,把最重要的问 题作为尚未解决的关键问题的风险.<5>制定消除风险的方法：应有 详尽的说明和周密的计划,并估计可能产生的后果.依此来开发软件, 为制订下一周期的计划打下基础.<6>制定下一周期的工作计划：在 第一个螺旋周期,确定目标、选择对象、分析约束,通过风险分析制 订消除风险的方法,初步开发原型1,制定系统生存周期计划.
软件工程的任务与研究范围
•软件产品的特点 •软件工程的研究内容与方法 •软件工具与软件支撑环境 •软件管理
软件开发的原则与方法
•软件开发的原则 • 自顶向下与模块结构 •软件开发的方法 •1.非自动形式的系统开发方法 •〔1〕系统流程图〔2〕结构分析法〔3〕结构化设计法 •〔4〕数据结构法〔5〕层次输入——处理——输出方法<HIPO法> • 2.半自动形式的系统开发方法 •〔1〕软件需求工程法〔2〕问题说明语言与分析法 • 3. 自动形式的系统开发方法 〔HOS方法〕：由计算机自动确定规 范、自动分析、自动编程、自动执行与模拟,以规范语言AXES、资 源分配工具RTA为工具.能自动进行分析、设计,工作量少、设计规范, 也能自动进行修改和维护.该方法适用于系统分析和设计.
软件工程-齐志昌版 (4)
2011-8-10
国防科技大学计算机学院
21
4.2初步需求获取技术 初步需求获取技术
例 家庭保安系统
负责人应要求小组成员对接收传感器事件、 负责人应要求小组成员对接收传感器事件、用户编 程控制、电话报警等操作进行更详细的描述， 程控制、电话报警等操作进行更详细的描述，必要 时可用流程图表示。 时可用流程图表示。 用户可能提出一些条件，如造价不能超过3， 用户可能提出一些条件，如造价不能超过 ，000元， 元 对传感器事件必须在1秒内作出响应 秒内作出响应， 对传感器事件必须在 秒内作出响应 ， 事件必须按 优先级进行处理等。会后小组负责人对这些信息进 优先级进行处理等。 行综合、整理，形成文档，该文档应能反映“ 行综合、整理，形成文档，该文档应能反映“家庭 保安系统”的全貌。 保安系统”的全貌。
2011-8-10
国防科技大学计算机学院
4
第四章 需求分析基础
2011-8-10
国防科技大学计算机学院
5
第四章 需求分析基础
用户需求、 用户需求、系统需求和软件设计描述
用户需求 用自然语言和图表描述 说明系统必须提供哪些服务、 说明系统必须提供哪些服务、系统运行要受哪些约束 系统需求 详细说明系统将要提供的服务以及系统受到的约束 精确的描述软件的功能 系统买方和软件开发者签订合同的重要内容 软件设计描述 在系统需求的基础上，加入更详细的内容， 在系统需求的基础上，加入更详细的内容，构成软件设计活动 的概要描述， 的概要描述，是软件设计和实现的基础
2011-8-10
国防科技大学计算机学院
14
第四章 需求分析基础
4.2 初步需求获取技术 初步需求获取技术
访谈与会议 深入调查研究 开发原型
软件工程第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类:
• 用自然语言描述需求规格说明，是典型的非形式 化方法。
• 用数据流图或实体-联系图建立模型，是典型的 半形式化方法。
有穷状态机对本产品进行规格说明: 这个问题中有两个按钮集。
软件工程第四章结构化需求分析
数据字典
定义
数据字典是一种用于描述数据元 素及其属性的工具，它提供了数 据的详细描述和定义。
பைடு நூலகம்
内容
包括数据元素的名称、别名、类 型、长度、取值范围、默认值等 属性信息。
作用
为开发人员提供了一个统一的数 据定义和描述标准，避免了数据 不一致和歧义的问题。
03 结构化需求分析过程
问题识别
01
确定软件系统的范 围和目标
用例表
列出系统的所有用例，包括用例名称、描述、前置条件和后置条件 等。
用户故事表
以用户为中心描述系统需求，包括用户角色、场景、任务和目标等。
原型工具
低保真原型
使用简单的工具和方法创建的原型，主要用于 概念验证和用户反馈收集。
高保真原型
使用高级工具和方法创建的原型，几乎与实际 产品一样，用于详细需求分析和用户测试。
04 结构化需求分析工具
图形工具
流程图
用于描述系统或程序的逻辑流程，包括开始、结束、决策点和活动 等元素。
数据流图
用于描述数据在系统中的流动和处理过程，包括数据源、数据存储、 数据处理和数据终点等元素。
实体关系图
用于描述系统中实体之间的关系，包括实体、关系和属性等元素。
表格工具
需求规格说明书
详细列出系统需求，包括功能需求、性能需求、安全需求和接口 需求等。
步骤
首先确定系统的主要功能，然后逐层向下分解，直 到每个功能都清晰、具体、可实现。
优点
能够全面地了解系统的功能需求，有助于保 证系统的完整性。
数据流图
定义
数据流图是一种图形化表示方法，用于描述系统中数 据的流动和处理过程。
组成
包括数据流、数据存储、数据处理和外部实体等基本 元素。
软件工程ppt课件完整版
缺陷跟踪
使用缺陷管理工具对缺陷进行 跟踪，确保每个缺陷都得到处 理。
缺陷修复
开发人员对缺陷进行分析并修 复，然后提交给测试人员进行 验证。
回归测试
对修复后的缺陷进行回归测试 ，确保修复没有引入新的缺陷
。
质量评估与改进
质量评估
定期对软件产品的质量进行评估，包括功能 、性能、安全等方面。
过程改进
对软件开发过程进行持续改进，提高开发效 率和软件质量。
，提高代码的可读性和可维护性。
模块化开发
02
采用模块化开发方式，将系统划分为不同的模块进行开发，提
高开发效率和质量。
错误处理
03
对可能出现的错误进行充分的考虑和处理，包括异常捕获、日
志记录和错误提示等，确保系统的稳定性和可靠性。
05 测试与质量保证
测试类型及方法
功能测试对软件产品的各项功 进行验证，确保符 合需求和设计。
同时引入了风险管理机制。
螺旋模型的主要阶段包括：制 定计划、风险分析、工程实施
和客户评估。
螺旋模型的优点在于其强调风 险分析和迭代开发，能够及时 发现并解决问题，降低项目风 险。
螺旋模型的缺点在于其需要较 高的项目管理能力和技术水平 ，且可能因为过度关注风险而 忽略其他重要因素。
敏捷开发模型
敏捷开发的主要实践包括：短周期迭代开发、 持续集成、持续交付和自动化测试等。
水平。
04
迭代增量模型的优点在于其能够逐步增加系统功能和 性能，降低项目风险，同时也能够及时发现并解决问 题。
03 需求分析与管理
需求获取与整理
确定需求来源
与客户、利益相关者、业务领域 专家等进行沟通，明确需求背景
和范围。
使用缺陷管理工具对缺陷进行 跟踪，确保每个缺陷都得到处 理。
缺陷修复
开发人员对缺陷进行分析并修 复，然后提交给测试人员进行 验证。
回归测试
对修复后的缺陷进行回归测试 ，确保修复没有引入新的缺陷
。
质量评估与改进
质量评估
定期对软件产品的质量进行评估，包括功能 、性能、安全等方面。
过程改进
对软件开发过程进行持续改进，提高开发效 率和软件质量。
，提高代码的可读性和可维护性。
模块化开发
02
采用模块化开发方式，将系统划分为不同的模块进行开发，提
高开发效率和质量。
错误处理
03
对可能出现的错误进行充分的考虑和处理，包括异常捕获、日
志记录和错误提示等，确保系统的稳定性和可靠性。
05 测试与质量保证
测试类型及方法
功能测试对软件产品的各项功 进行验证，确保符 合需求和设计。
同时引入了风险管理机制。
螺旋模型的主要阶段包括：制 定计划、风险分析、工程实施
和客户评估。
螺旋模型的优点在于其强调风 险分析和迭代开发，能够及时 发现并解决问题，降低项目风 险。
螺旋模型的缺点在于其需要较 高的项目管理能力和技术水平 ，且可能因为过度关注风险而 忽略其他重要因素。
敏捷开发模型
敏捷开发的主要实践包括：短周期迭代开发、 持续集成、持续交付和自动化测试等。
水平。
04
迭代增量模型的优点在于其能够逐步增加系统功能和 性能，降低项目风险，同时也能够及时发现并解决问 题。
03 需求分析与管理
需求获取与整理
确定需求来源
与客户、利益相关者、业务领域 专家等进行沟通，明确需求背景
和范围。
软件工程第四章结构化需求分析
在开始建立分析模型之前先理解问题。 以业务流程为中心来理解用户需求。 使用多个需求分析视图，建立数据、功能和行为模
型。
结构化分析模型
系统模型从以下不同的角度表述系统：
从外部来看，它是对系统分析上下文或系统环
境建模； 从行为上看，它是对系统行为建模； 从结构上看，它是对系统的体系结构和系统处 理的数据结构建模。
实例分析：图书馆系统
借书者 1 借书记录 包含 1 预约 M 书目
1
借/还/续借
M
图书 N
预约记录
实例分析：图书馆系统
实体：图书、借书者、管理员、借书目录、 预约记录、书目 属性给出如下：
借书者：借书者编号、姓名、性别、借书数、
最大借书数、罚金金额、有限期 图书：图书号、书目号 书目：书目号、书名、作者、出版社、丛书名、 收藏数、在馆数、预约数 借书记录：图书号、借书者编号、借出日期、 应还日期、续借次数 预约记录：书目号、借书者编号、预约日期
数据字典
数据字典是分析模型中出现的所有名字的一个 集合，并包括有关命名实体的描述 数据字典有以下两个作用：
它是所有名字信息管理的有效机制 作为连接软件分析、设计、实现和进化阶段的开发
机构的信息存储
数据字典应该由四类元素的定义组成：
数据流 数据流分量 数据存储 处理
实例分析：POS机系统
1 销售记录 1 付款 包含 M 商品 N 描述
N
1
商品描述
支付记录
实例分析：POS机系统
实体有销售记录、支付记录、商品、商品 描述 关联：
销售包含一组商品； 每个商品都有相应的描述信息； 每个支付对应一个销售。
实体的属性：
型。
结构化分析模型
系统模型从以下不同的角度表述系统：
从外部来看，它是对系统分析上下文或系统环
境建模； 从行为上看，它是对系统行为建模； 从结构上看，它是对系统的体系结构和系统处 理的数据结构建模。
实例分析：图书馆系统
借书者 1 借书记录 包含 1 预约 M 书目
1
借/还/续借
M
图书 N
预约记录
实例分析：图书馆系统
实体：图书、借书者、管理员、借书目录、 预约记录、书目 属性给出如下：
借书者：借书者编号、姓名、性别、借书数、
最大借书数、罚金金额、有限期 图书：图书号、书目号 书目：书目号、书名、作者、出版社、丛书名、 收藏数、在馆数、预约数 借书记录：图书号、借书者编号、借出日期、 应还日期、续借次数 预约记录：书目号、借书者编号、预约日期
数据字典
数据字典是分析模型中出现的所有名字的一个 集合，并包括有关命名实体的描述 数据字典有以下两个作用：
它是所有名字信息管理的有效机制 作为连接软件分析、设计、实现和进化阶段的开发
机构的信息存储
数据字典应该由四类元素的定义组成：
数据流 数据流分量 数据存储 处理
实例分析：POS机系统
1 销售记录 1 付款 包含 M 商品 N 描述
N
1
商品描述
支付记录
实例分析：POS机系统
实体有销售记录、支付记录、商品、商品 描述 关联：
销售包含一组商品； 每个商品都有相应的描述信息； 每个支付对应一个销售。
实体的属性：
软件工程 第四讲 组织
三, CC
小组负责人管理顶层问题的解决过程并负责 组内协调. 组内协调.负责人和小组成员之间的通信是 上下级式的. 上下级式的. 用来解决简单的问题, 用来解决简单的问题, 开发规模很大的项目
选择软件工程小组的结构时,应考虑的因素:
待解决的问题的困难程度; 待解决的问题的困难程度; 困难程度 要开发的程序的规模(用代码行或功能点度量) 要开发的程序的规模(用代码行或功能点度量); 规模 小组成员在一起工作的时间(小组生命期); 小组成员在一起工作的时间(小组生命期) 时间 问题能够被模块化的程度; 问题能够被模块化的程度; 模块化的程度 对待开发的系统的质量和可靠性的要求; 对待开发的系统的质量和可靠性的要求; 质量 的要求 交付日期的严格程度; 交付日期的严格程度; 严格程度 项目要求的社交(通信)程度. 项目要求的社交(通信)程度.
1, 民主制程序员组 ,
民主制程序员组通常采用非正式的组织方式, 民主制程序员组通常采用非正式的组织方式, 非正式的组织方式 也就是说,虽然名义上有一个组长, 名义上有一个组长 也就是说,虽然名义上有一个组长,但是他 和组内其他成员完成同样的任务. 和组内其他成员完成同样的任务.在这样的 小组中,由全体讨论决定应该完成的工作, 小组中,由全体讨论决定应该完成的工作, 并且根据每个人的能力和经验分配适当的任 务.
主程序员组的结构 在必要的时候,该组还有其他领域的专家 例如 法律专家, 例如, 在必要的时候,该组还有其他领域的专家(例如,法律专家, 财务专家等)协助 协助. 财务专家等 协助.
3,现代程序员组
实际的"主程序员"应该由两个人来担任: 实际的"主程序员"应该由两个人来担任: 一个技术负责人 负责小组的技术活动; 技术负责人, 一个技术负责人,负责小组的技术活动;一 行政负责人,负责所有非技术的管理决策. 个行政负责人,负责所有非技术的管理决策.
《软件工程实用教程》第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 小结
软件工程第四章形式化说明技术
N
姓名 学号
性别 系
学生
N
M
学
年级 成绩
课程号
课程
课名
学时
学分
图3.2 某校教学管理ER图
3.5 数据规范化
通常用范式定义消除数据冗余的程度。第一范式（1 NF）数据冗余度 最大，第五范式（5 NF）数据冗余度最小。但范式级别越高，(1)存 储同样多数据需要分解成更多张表，“存储自身”的过程越复杂；(2) 数据存储结构与基于问题域的结构间的匹配程度也随之下降，需求变 化时数据稳定性下降；(3)需要访问的表增多，性能下降。(第三范式) 第一范式：每个属性都是原子值 第二范式：满足第一范式条件，每个关键字属性都仅有关键字决定 第三范式：符合第二范式条件，每个非关键字属性都仅有关键字决 定，并且一个非关键字属性值不依赖于另一个非关键字属性值
用户和开发人员共同组成联合小组
加强联系 促进交流 增进合作
3.2.2 面向数据流自顶向下求精
借助数据流图、数据字典、IPO图等，细化、完善详 细的数据流图，等到各处理环节对应的功能。
需要分解
有补充修正
分析追踪数据 流图
用户复查
无补充修 正
细化 数据流图
不需分解
图3.1 需求分析基本过程
3.2.3 简易的应用规格说明技术
3.7.3 IPO图
在需求分析阶段可以使用IPO图简略地描述数据流图中各个处理 的基本算法（着重说明处理功能而不是具体实现功能的算法）。 当然，在需求分析阶段，IPO表中的许多附加信息暂时还不具备。 但是，在软件设计阶段可以进一步补充、修正这些表，继续作为 设计阶段的文档。这正是在需求分析阶段用IPO表作为描述基本算 法的工具的重要优点。
（1）选择合适的形式化方法；适用于当前项目 （2）需要形式化，但不能过渡形式化，不能放弃传统的需求 表达方法； （3）应该估算成本； （4）应该有形式化方法的专家提供指导； （5）不应该放弃传统的开发方法；
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件建模
软件建模：模拟软件的三个世界
现实世界
计算世界
机器世界
用 户 模 型
分 析 模 型
计 算 模 型
程 序 编 码
机 器 指 令
分析
设计
编码
编译
软件建模：逻辑模型和物理模型
抽象（映射）
对象 系统 模型应用 模型 系统
模型是对对象系统的形式化的特征抽象，概括性或近似地表示； 构造模型的过程是一个抽象、分析的过程。
软件建模：模型与视图
模型是视图的全集。
软件建模：模型与视图
模型是视图的全集。
软件建模：逻辑模型和物理模型
怎 么 做
做 什 么 抽象化
当前 系统
当前 系统
模型化
物理 模型
逻辑 模型
需 求 定 义
目标 系统
具体化
物理 模型
实例化
逻辑 模型 目标 系统
软件建模： What is modeling?
Order
parts of the system.”
Dr. James Rumbaugh
Item
Ship via
Business Process
Visual Modeling is modeling using standard graphical notations
Computer System
软件建模： Visual Modeling Captures
Multiple Systems
Reusable Components
软件建模：用UML建模
软件建模： UML模型的作用
UML模型 abstract of 源代码
specify
软件结构和行为 abstract of 可执行代码
specify
软件建模： UML的创造者
Grady Booch
James Rumbaugh
User Interface (Visual Basic, Java)
Business Logic (C++, Java)
Database Server (C++ & SQL)
Model your system independent of implementation language
软件建模： Visual Modeling Promotes Reuse
Business Process
Use Case Analysis is a technique to capture business process from user’s perspective
软件建模： Visual Modeling is a Communication Tool
Use visual modeling to capture business and logic
Use visual modeling to analyze and design your application
软件建模： Visual Modeling Manages Complexity
软件建模： Visual Modeling Defines Software Architecture
Model: A model is a simplification of reality. 模型：是对现实世界的简化。
软件建模： The Importance of Modeling
软件建模： What is Visual Modeling?
“Modeling captures essential
Ivar Jacobson
软件建模：模拟软件的三个世界
现实世界
计算世界
机器世界
用 户 模 型
分 析 模 型
计 算 模 型
程 序 编 码
机 器 指 令
分析
设计
编码
编译
软件建模：逻辑模型和物理模型
抽象（映射）
对象 系统 模型应用 模型 系统
模型是对对象系统的形式化的特征抽象，概括性或近似地表示； 构造模型的过程是一个抽象、分析的过程。
软件建模：模型与视图
模型是视图的全集。
软件建模：模型与视图
模型是视图的全集。
软件建模：逻辑模型和物理模型
怎 么 做
做 什 么 抽象化
当前 系统
当前 系统
模型化
物理 模型
逻辑 模型
需 求 定 义
目标 系统
具体化
物理 模型
实例化
逻辑 模型 目标 系统
软件建模： What is modeling?
Order
parts of the system.”
Dr. James Rumbaugh
Item
Ship via
Business Process
Visual Modeling is modeling using standard graphical notations
Computer System
软件建模： Visual Modeling Captures
Multiple Systems
Reusable Components
软件建模：用UML建模
软件建模： UML模型的作用
UML模型 abstract of 源代码
specify
软件结构和行为 abstract of 可执行代码
specify
软件建模： UML的创造者
Grady Booch
James Rumbaugh
User Interface (Visual Basic, Java)
Business Logic (C++, Java)
Database Server (C++ & SQL)
Model your system independent of implementation language
软件建模： Visual Modeling Promotes Reuse
Business Process
Use Case Analysis is a technique to capture business process from user’s perspective
软件建模： Visual Modeling is a Communication Tool
Use visual modeling to capture business and logic
Use visual modeling to analyze and design your application
软件建模： Visual Modeling Manages Complexity
软件建模： Visual Modeling Defines Software Architecture
Model: A model is a simplification of reality. 模型：是对现实世界的简化。
软件建模： The Importance of Modeling
软件建模： What is Visual Modeling?
“Modeling captures essential
Ivar Jacobson