软件工程-第7讲R2
- 格式：ppt
- 大小：2.47 MB
- 文档页数：82
下载文档原格式
合集下载
软件工程第7章ppt资料
复杂问题(大型系统)的对象模型由下 述五个层次组成：主题层(也称为范畴层)、 类与对象层、结构层、属性层和服务层， 如图7.1
Page 7
河南理工大学
2020/10/12
Page 8
图7.1 复杂问题的对象模型
河南理工大学
2020/10/12
我们在概念上可以认为，面向对象分析大 体上按照下列顺序进行：
Page 12
河南理工大学
2020/10/12
7.2 需求陈述
7.2.1
通常，需求陈述的内容包括：问题范 围，功能需求，性能需求，应用环境及假 设条件等。总之，需求陈述应该阐明“做 什么”而不是“怎样做”。
Page 13
河南理工大学
2020/10/12
它应该描述用户的需求而不是提出解 决问题的方法。应该指出哪些是系统必要 的性质，哪些是任选的性质。应该避免对 设计策略施加过多的约束，也不要描述系 统的内部结构，因为这样做将限制实现的 灵活性。
寻找类—&—对象， 识别结构， 识别主题， 定义属性， 建立动态模型，建立功能模型， 定义服务。
但是，正如前面已经多次强调指出过 的，分析不可能严格地按照预定顺序进行， 大型、复杂系统的模型需要反复构造多遍 才能建成。通常，先构造出模型的子集， 然后再逐渐扩充，直到完全、充分地理解 了整个问题，才能最终把模型建立起来。
Page 5
河1.2 三个子模型与五个层次
面向对象建模得到的模型包含系统的三个要素:
即静态结构(对象模型)，交互次序(动态模型)和数据 变换(功能模型)。解决的问题不同，这三个子模型的重 要程度也不同： 几乎解决任何一个问题，都需要从客观世界实体及实体 间相互关系抽象出极有价值的对象模型； 当问题涉及交互作用和时序时(例如，用户界面及过程 控制等)，动态模型是重要的； 解决运算量很大的问题(例如，高级语言编译、科学与 工程计算等)，则涉及重要的功能模型。动态模型和功 能模型中都包含了对象模型中的操作(即服务或方法)。
太原理工大学软件工程_第七章
本章主要介绍软件测试有关的概念、方法及测试的步骤。
2020年1月23日
第7章 软件测试
第2页
学习目标
掌握软件测试的定义、目标和原则 掌握软件测试的方法和分类 熟练掌握软件测试用例的设计方法 理解和掌握软件测试过程及相关测试概念 理解调试的方法和技术 了解软件测试阶段终止的条件
人工测试常用的方法包括： 桌前检查（Desk Checking) 由程序员检查自己的程序，
对源代码进行分析、检验。 代码会审（Code Reading Review) 由程序员和测试员
组成评审小组，按照“常见的错误清单”，进行会议讨论 检查。 步行检查 (Walkthroughs) 与代码会审类似，也要进行 代码评审，但评审过程主要采取人工执行程序的方式，故 也称为“走查”。步行检查是最常用的静态分析方法。
存在错误。
2020年1月23日
第7章 软件测试
第7页
7.2 软件测试的原则
1.测试用例既要有输入数据，又要有对应的输出结果； 2.测试用例不仅要选用合理的输入数据，还应选择不合理的输
入数据；
3.除了检查程序是否做了它应该做的工作，还应该检查程序是 否做了它不应该做的工作；
4.应该远在测试开始之前就制定测试计划； 5.测试计划、测试用例、测试报告必须作为文档长期保存； 6.Pare to 原理说明，测试发现的错误中80%很可能是由程序中
第7章 软件测试
要使程序中2个判断2个语
句至少执行一次，只需设
计一个能通过路径sacbed
的例子就可以了。
判定一
（1）首先判断a、b为真
A>1，B=0
A=2，X>1
判定二
（2）选择测试用例
2020年1月23日
第7章 软件测试
第2页
学习目标
掌握软件测试的定义、目标和原则 掌握软件测试的方法和分类 熟练掌握软件测试用例的设计方法 理解和掌握软件测试过程及相关测试概念 理解调试的方法和技术 了解软件测试阶段终止的条件
人工测试常用的方法包括： 桌前检查（Desk Checking) 由程序员检查自己的程序，
对源代码进行分析、检验。 代码会审（Code Reading Review) 由程序员和测试员
组成评审小组，按照“常见的错误清单”，进行会议讨论 检查。 步行检查 (Walkthroughs) 与代码会审类似，也要进行 代码评审，但评审过程主要采取人工执行程序的方式，故 也称为“走查”。步行检查是最常用的静态分析方法。
存在错误。
2020年1月23日
第7章 软件测试
第7页
7.2 软件测试的原则
1.测试用例既要有输入数据，又要有对应的输出结果； 2.测试用例不仅要选用合理的输入数据，还应选择不合理的输
入数据；
3.除了检查程序是否做了它应该做的工作，还应该检查程序是 否做了它不应该做的工作；
4.应该远在测试开始之前就制定测试计划； 5.测试计划、测试用例、测试报告必须作为文档长期保存； 6.Pare to 原理说明，测试发现的错误中80%很可能是由程序中
第7章 软件测试
要使程序中2个判断2个语
句至少执行一次，只需设
计一个能通过路径sacbed
的例子就可以了。
判定一
（1）首先判断a、b为真
A>1，B=0
A=2，X>1
判定二
（2）选择测试用例
计算机二级【公共基础知识】软件工程基础课件
结构化设计方法的步骤
包括自顶向下设计和逐步细化设计两 个步骤，通过逐步分解系统，将复杂 问题分解为简单问题，便于开发人员 理解和实现。
面向对象设计方法
面向对象设计方法的概念
面向对象设计方法是一种基于对象的设计技术，将数据和操 作封装在对象中，通过对象之间的交互实现系统的功能。
面向对象设计方法的步骤
需求分析
需求分类
对获取的需求进行分类，明确哪些是功能性需求，哪些是非功能性 需求。
需求优先级排序
根据项目目标和利益相关者的关注点，对需求进行优先级排序，确 定哪些需求是必须满足的，哪些是可协商的。
建立需求模型
通过建立数据流图、实体关系图等模型，对需求进行详细分析和描 述。
需求规格说明书
编写需求规格说明书
测试执行是按照测试计划和测试用例执行测试的过程，而测试报告是记录测试结果和提供决策依据的重要文档。
在测试执行过程中，应按照测试计划和测试用例的要求，对软件系统进行逐项测试，并记录测试结果和发现的问题。测试报 告应详细记录测试过程、方法、结果和结论，并提供决策依据和建议。同时，测试报告还应包括问题跟踪和管理，以确保所 有发现的问题得到及时解决和验证。
迭代模型
在开发过程中不断迭代，逐步完善软件功能，逐步进行测试 和维护。
螺旋模型
强调风险分析，将瀑布模型和迭代模型相结合，逐步完善软 件功能。
敏捷开发方法
概念
敏捷开发是一种以人为核心、迭代、循序渐进的软件开发方法，强调团队合作和灵活性。
常见方法
Scrum、极限编程等。
特点
快速响应变化，快速交付价值，持续改进和团队成员的高度协作。
软件工程的重要性
提高软件质量
通过采用工程化的方法和技术， 可以减少软件缺陷和漏洞，提高
包括自顶向下设计和逐步细化设计两 个步骤，通过逐步分解系统，将复杂 问题分解为简单问题，便于开发人员 理解和实现。
面向对象设计方法
面向对象设计方法的概念
面向对象设计方法是一种基于对象的设计技术，将数据和操 作封装在对象中，通过对象之间的交互实现系统的功能。
面向对象设计方法的步骤
需求分析
需求分类
对获取的需求进行分类，明确哪些是功能性需求，哪些是非功能性 需求。
需求优先级排序
根据项目目标和利益相关者的关注点，对需求进行优先级排序，确 定哪些需求是必须满足的，哪些是可协商的。
建立需求模型
通过建立数据流图、实体关系图等模型，对需求进行详细分析和描 述。
需求规格说明书
编写需求规格说明书
测试执行是按照测试计划和测试用例执行测试的过程，而测试报告是记录测试结果和提供决策依据的重要文档。
在测试执行过程中，应按照测试计划和测试用例的要求，对软件系统进行逐项测试，并记录测试结果和发现的问题。测试报 告应详细记录测试过程、方法、结果和结论，并提供决策依据和建议。同时，测试报告还应包括问题跟踪和管理，以确保所 有发现的问题得到及时解决和验证。
迭代模型
在开发过程中不断迭代，逐步完善软件功能，逐步进行测试 和维护。
螺旋模型
强调风险分析，将瀑布模型和迭代模型相结合，逐步完善软 件功能。
敏捷开发方法
概念
敏捷开发是一种以人为核心、迭代、循序渐进的软件开发方法，强调团队合作和灵活性。
常见方法
Scrum、极限编程等。
特点
快速响应变化，快速交付价值，持续改进和团队成员的高度协作。
软件工程的重要性
提高软件质量
通过采用工程化的方法和技术， 可以减少软件缺陷和漏洞，提高
《软件工程》教学课件CH7-2面向对象分析
当问题涉及用户界面与过程控制时,动态模型是重点.如果问 题涉及大量数据变换,则功能模型非常重要.对象模型中的操 作(即服务)可以出现在动态模型和功能模型内. 2) 面向对象分析的五个层次 面向对象分析由五个主要活动组成,即确定类面向对象分析由五个主要活动组成,即确定类-&-对象,识别 对象, 结构,识别主题,定义属性和定义服务(方法) 结构,识别主题,定义属性和定义服务(方法).对于一个复杂 问题的面向对象的模型可用五个层次 五个层次表示:类-&-对象层,结 对象层, 五个层次 类 构层,主题层,属性层和服务层,见图3.3.8. 构层,主题层,属性层和服务层
是三个模型中最关键的一个模型,它的作用是描 述系统的静态结构,包括构成系统的类和对象, 它们的属性和操作,及它们之间的关系. 在OMT中,类与类之间的关系叫做关联.关联代 表一组存在于两个或多个对象之间的,具有相同结 构和含义的具体连接.关联可以是物理的,也可 以是逻辑的.
类 类名 属性 操作
类的实例 (类名) 类名) 属性值
基类
派生类A 派生类
派生类A 派生类
金额计算器 金额 累加 找零 重置 退币杆 退币杆状态 按退币杆
属于
属于
自动售货机 饮料编号 价格 投入硬币 送出饮料 显示金额 按下按钮 按退币杆 显示售空 购买 顾客 姓名 硬币 投入硬币 取出饮料
属于
存量计算器 饮料编号 存量 递减 显示售空 重置 选择按钮 按钮状态 按钮灯亮 按钮灯灭 售空灯亮 按下按钮
Rumbaugh的对象模型化技术 的对象模型化技术OMT 的对象模型化技术 (object modeling technique)
对象模型化技术的三类模型:对象模型,动态模 型和功能模型.
软件工程-齐志昌-第二版
软件工程阶段
20世纪70年代，随着计算机应用的普及，软件开发的复 杂度越来越高，软件危机开始出现，软件工程的概念和方 法逐渐被提出和应用。
现代软件工程
20世纪80年代以后，随着面向对象编程和软件重用技术 的发展，软件工程进入了一个新的阶段，强调使用工程化 的方法和工具来指导和管理软件开发。
软件工程的三大支柱
02 软件开发生命周期
概念与模型
概念
软件开发生命周期是软件开发从开始 到结束的全过程，包括需求分析、设 计、编码、测试和维护等阶段。
模型
软件开发生命周期模型是描述软件开 发过程的抽象框架，常见的有瀑布模 型、螺旋模型、迭代模型等。
传统开发模型
瀑布模型
按顺序进行需求分析、设计、编码、测试和维护等阶段，阶段间具有严格的顺序性和依 赖性。
面向对象编程
使用面向对象编程语言（如Java、C）进行软件实现，通过封装、 继承和多态等机制实现代码重用和模块化。
面向过程编程
采用结构化程序设计方法，将软件系统分解为一系列过程，通过顺 序、选择和循环等结构实现软件功能。
函数式编程
使用函数式编程语言（如Haskell、Scala）进行软件实现，通过高阶 函数、不可变性等特性提高代码可读性和可维护性。
Jira
一款功能强大的项目管理工具，支持敏捷开发和传统瀑布模型，提供任务管理、缺陷跟 踪和需求管理等功能。
Gantt Chart
甘特图是一种常用的项目进度计划工具，通过条形图展示任务开始和结束时间，直观地 反映任务之间的依赖关系和时间进度。
THANKS FOR WATCHING
感谢您的观看
软件测试技术
单元测试
针对软件中的最小可测试单元（如函数、方法、类等）进行测试， 验证其功能和性能是否符合要求。
计算机二级软件工程
这些软件工具按照一定的方法或模式组合起来，支持软件生命周期 内的各个阶段和各项任务的完成。
计算机辅助软件工程（CASE Computer Aided Software Engineering）是当前软件开发环境中富有特 色的研究工作和发展方向。
2 结构化分析方法
需求分析与需求分析方法 结构化分析方法 软件需求规格说明书
效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移 植性、可追踪性和可互操作性且满足用户需求的产品。
软件工程的原则：
抽象、信息隐蔽、模块化、局部化、确定性、一致性、完备性、可 验证性
软件开发工具与软件开发环境
软件开发工具：为软件工程方法提供了自动的或半自动的软件
支撑环境。
软件开发环境：是全面支持软件开发全过程的软件工具集合。
详细设计
PDL（Procedure Design Language） PDL是一种用于描述功能模块的算法设计和
加工细节的语言，称为过程设计语言。它是一 种混合语言，采用英语的词汇和结构化程序设 计语言的语法，类似编程语言。
4 软件测试
软件测试的目的 软件测试的准则 软件测试技术与方法 软件测试的实施
软件工程基础
1 软件工程的基本概念 2 结构化分析方法 3 结构化设计方法 4 软件测试 5 程序的调试
1 软件工程基本概念
软件定义与软件特点 软件危机与软件工程 软件工程过程与软件生命周期 软件工程的目标与原则 软件开发工具与开发环境
软件定义
软件定义：软件是计算机系统中与硬件相互依存的另一部分， 是包括程序、数据及其相关文档组成的完整集合。 软件=程序+数据+文档
白盒测试又称为结构测试或逻辑驱动测试。
白盒测试主要对程序模块进行如下的检查： 对程序模块的所有独立的执行路径至少测试一次； 对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一 次； 在循环的边界和运行界限内执行循环体； 测试内部数据结构的有效性等。
计算机辅助软件工程（CASE Computer Aided Software Engineering）是当前软件开发环境中富有特 色的研究工作和发展方向。
2 结构化分析方法
需求分析与需求分析方法 结构化分析方法 软件需求规格说明书
效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移 植性、可追踪性和可互操作性且满足用户需求的产品。
软件工程的原则：
抽象、信息隐蔽、模块化、局部化、确定性、一致性、完备性、可 验证性
软件开发工具与软件开发环境
软件开发工具：为软件工程方法提供了自动的或半自动的软件
支撑环境。
软件开发环境：是全面支持软件开发全过程的软件工具集合。
详细设计
PDL（Procedure Design Language） PDL是一种用于描述功能模块的算法设计和
加工细节的语言，称为过程设计语言。它是一 种混合语言，采用英语的词汇和结构化程序设 计语言的语法，类似编程语言。
4 软件测试
软件测试的目的 软件测试的准则 软件测试技术与方法 软件测试的实施
软件工程基础
1 软件工程的基本概念 2 结构化分析方法 3 结构化设计方法 4 软件测试 5 程序的调试
1 软件工程基本概念
软件定义与软件特点 软件危机与软件工程 软件工程过程与软件生命周期 软件工程的目标与原则 软件开发工具与开发环境
软件定义
软件定义：软件是计算机系统中与硬件相互依存的另一部分， 是包括程序、数据及其相关文档组成的完整集合。 软件=程序+数据+文档
白盒测试又称为结构测试或逻辑驱动测试。
白盒测试主要对程序模块进行如下的检查： 对程序模块的所有独立的执行路径至少测试一次； 对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一 次； 在循环的边界和运行界限内执行循环体； 测试内部数据结构的有效性等。
软件工程齐志昌版
软件工程齐志昌版第一点：软件工程的定义与发展软件工程是一门研究如何系统地设计、开发、测试和维护软件的应用学科。
它旨在通过工程化的方法，提高软件的质量、提高开发效率、降低开发成本。
软件工程的概念最早可以追溯到20世纪60年代，当时计算机科学家们开始意识到，软件开发需要像传统工程领域一样，采用科学的方法和规范的流程，以确保软件的可靠性和稳定性。
随着计算机技术的不断进步和软件规模的不断扩大，软件工程逐渐发展出了多个分支领域，如软件架构、软件需求工程、软件测试、软件项目管理等。
同时，软件工程也不断吸收和融合其他学科的理论和技术，如心理学、社会学、经济学等，以更好地适应人类社会的发展需求。
在软件工程的发展过程中，涌现出了许多重要的方法和理论，如结构化分析、面向对象设计、敏捷开发等。
这些方法和理论为软件开发提供了有力的指导，使得软件工程成为了一门具有广泛应用和深远影响的学科。
第二点：软件工程的关键技术和方法软件工程的关键技术和方法是保证软件质量、提高开发效率的基础。
以下是几种常见的软件工程技术和方法：1.结构化分析：结构化分析是一种用于需求分析和系统设计的软件工程方法。
它通过建立数据流图、实体关系图等模型，来描述系统的功能和数据结构。
结构化分析有助于明确系统的需求，为后续的软件开发提供清晰的指导。
2.面向对象设计：面向对象设计是一种基于对象、类和继承等概念的软件设计方法。
它将现实世界中的事物抽象为对象，并通过对象之间的交互来实现系统的功能。
面向对象设计有助于提高软件的可重用性、可维护性和可扩展性。
3.敏捷开发：敏捷开发是一种注重快速响应变化、强调团队协作和持续改进的软件开发方法。
它通过短周期的迭代开发、持续反馈和适应性规划，来提高软件开发的灵活性和适应性。
敏捷开发适用于快速变化的软件需求和复杂的项目管理。
4.软件测试：软件测试是确保软件质量的重要环节。
它包括单元测试、集成测试、系统测试和验收测试等多种测试类型。
软件工程7-1
软件工程7-11. 简介软件工程是指以工程化的方法和原则，对软件进行开发、运行和维护的一门学科。
它涉及到软件需求分析、设计、编码、测试、运行和维护等各个方面。
在软件工程的学习过程中，学生会接触到各种软件开发方法和技术，其中包括敏捷开发、面向对象设计、软件测试等。
本文档将围绕软件工程7-1这个主题，介绍软件工程这门学科的相关内容。
2. 软件工程的基础知识2.1 软件开发生命周期软件开发生命周期指的是软件从需求分析到开发、测试、运行和维护的整个过程。
常见的软件开发生命周期包括瀑布模型、迭代模型和增量模型等。
瀑布模型是最常见的软件开发生命周期模型，它将软件开发过程分为需求分析、设计、编码、测试和维护等阶段，每个阶段都有相应的工作任务。
2.2 敏捷开发敏捷开发是一种以迭代和循环的方式进行软件开发的方法。
它强调团队合作、灵活性和快速响应客户需求。
敏捷开发注重与客户的沟通和反馈，通过不断迭代优化软件的功能和性能。
敏捷开发方法包括极限编程（XP）、Scrum等。
2.3 面向对象设计面向对象设计是一种软件设计方法，它以对象为基本单元，通过封装、继承和多态等特性来组织和管理代码。
面向对象设计注重模块化和复用性，能够提高软件的可维护性和可扩展性。
常见的面向对象设计方法包括UML建模、设计模式等。
3. 软件工程7-1的课程内容软件工程7-1是软件工程专业的一门核心课程，主要包括以下内容：3.1 软件需求分析软件需求分析是软件开发的第一步，它是确定用户需求和软件功能的过程。
在软件需求分析阶段，学生将学习如何与用户进行沟通、了解用户需求，并将其转化为可执行的软件需求文档。
3.2 软件设计和架构软件设计和架构是确定软件结构和组织的过程。
在软件设计和架构阶段，学生将学习如何进行软件结构的分析和设计，以及如何选择合适的软件架构模式。
3.3 软件编码和调试软件编码和调试是将软件设计转化为可执行代码的过程。
在软件编码和调试阶段，学生将学习如何使用合适的编程语言和开发工具进行编码，并通过调试技术找出并修复代码中的错误。
软件工程基础(胡思康)第7章课件PPT课件
第6页/共42页
➢通过机制用于描述系统的其他信息，如注释，通 用模型的语义扩展等。
第7页/共42页
➢统一标准：UML统一了Coad/Yourdon、Booch、 OMT和OOSE等方法的基本概念，并借鉴和吸收了各 类方法的长处，摒弃了引起混乱、误解的图形符号， 补充了新的图形符号，定义了符号语义系统，成为 面向对象分析和设计的标准。
第36页/共42页
➢聚合也称为聚集，它是特殊的关联关系，其特殊之处在于它 描述的多个类之间是整体和部分的关联关系。 ➢如大楼有一个个房间构成，学校由教师、学生和机关人员构 成。 ➢识别聚合关系的直接方法，就是在需求描述中找寻有“包 含”、“由…构成”、“是…的一部分”等词或短语，这些词 或短语直接反映了类之间的“整体-部分”关系。P191
第31页/共42页
➢普通关联是最常见的一种关联关系。只要类和类之间存在 连接关系就能用普通关联来表示。普通关联又分为二元关系 和多元关系。 ➢二元关系描述两个类之间的关系，用直线连接两个类。如 果关联是单向关系，用黑色三角指向关联的方向，因而也称 为导航关联。也可以将直线改为有向箭头，方向与黑色三角 的指向相同。P189 图7-20
设计视图 过程视图
用例视图
实现视图 配置视图
第14页Байду номын сангаас共42页
➢用例视图从用户角度描述系统，用例视图建模主要包括以 下几个方面：
软件系统应具备的、与外部系统交互的功能，这是用例视 图的基础。 用例视图涉及与系统进行信息交换的外部系统。同时，在 用例视图中应指明用户使用或参与的用例，以便于面向对象 设计中交互的分析和设计。
第33页/共42页
➢限定关联用于描述一对多或多对多的关联关系。通过限定关 联，可以将多对多的关系转换成为多个一对多的关系，将一对 多的关系转换成多个一对一的关系。 ➢在类图中，将限定词放在进行限制的类旁，并用矩形框表示； 也可以也能够{ }括起来，作为对类的约束。 P190 图7-23
➢通过机制用于描述系统的其他信息，如注释，通 用模型的语义扩展等。
第7页/共42页
➢统一标准：UML统一了Coad/Yourdon、Booch、 OMT和OOSE等方法的基本概念，并借鉴和吸收了各 类方法的长处，摒弃了引起混乱、误解的图形符号， 补充了新的图形符号，定义了符号语义系统，成为 面向对象分析和设计的标准。
第36页/共42页
➢聚合也称为聚集，它是特殊的关联关系，其特殊之处在于它 描述的多个类之间是整体和部分的关联关系。 ➢如大楼有一个个房间构成，学校由教师、学生和机关人员构 成。 ➢识别聚合关系的直接方法，就是在需求描述中找寻有“包 含”、“由…构成”、“是…的一部分”等词或短语，这些词 或短语直接反映了类之间的“整体-部分”关系。P191
第31页/共42页
➢普通关联是最常见的一种关联关系。只要类和类之间存在 连接关系就能用普通关联来表示。普通关联又分为二元关系 和多元关系。 ➢二元关系描述两个类之间的关系，用直线连接两个类。如 果关联是单向关系，用黑色三角指向关联的方向，因而也称 为导航关联。也可以将直线改为有向箭头，方向与黑色三角 的指向相同。P189 图7-20
设计视图 过程视图
用例视图
实现视图 配置视图
第14页Байду номын сангаас共42页
➢用例视图从用户角度描述系统，用例视图建模主要包括以 下几个方面：
软件系统应具备的、与外部系统交互的功能，这是用例视 图的基础。 用例视图涉及与系统进行信息交换的外部系统。同时，在 用例视图中应指明用户使用或参与的用例，以便于面向对象 设计中交互的分析和设计。
第33页/共42页
➢限定关联用于描述一对多或多对多的关联关系。通过限定关 联，可以将多对多的关系转换成为多个一对多的关系，将一对 多的关系转换成多个一对一的关系。 ➢在类图中，将限定词放在进行限制的类旁，并用矩形框表示； 也可以也能够{ }括起来，作为对类的约束。 P190 图7-23
软件工程 第7章1 ppt
(9) 最高位数字后面有空格； 输入：’ 1 2’ 预期的输出：“错误——无效输入” (10)最高位数字后面有其他字符； 输入：’ 1××2’ 预期的输出：“错误——无效输入” (11)负号与最高位数字之间有空格； 输入：’12’ 预期的输出：“错误——负号位置错” 。
7.7.2 边界值分析
1. 程序运行在边界情况时最容易发生错误。 因此， 设计使程序运行在边界情况附近的测试方案，暴 露出程序错误的可能性更大一些。 2. 使用边界值分析方法设计测试方案首先应该确定 边界情况； 通常输入等价类和输出等价类的边界 按照边界值分析法，应该选取刚好等于、稍小于和 稍大于等价类边界值的数据作为测试数据，而不是 选取每个等价类内的典型值或任意值作为测试数据。 3. 通常设计测试方案时总是联合使用等价划分和边界 值分析两种技术。
图7.8 调试过程
7.8.2 调试途径
◆ 调试的目标都是寻找软件错误的原因并改正错 误。这需要系统地分析、直觉和运气，才能实现 上述目标。 ◆一般，有下列3种调试途径可以采用： 1. 蛮干法 2. 回溯法 3. 原因排除法
7.8.2 调试途径
1. 蛮干法 ◆ 按照“让计算机自己寻找错误”的策略，在这样 生 成的信息海洋的某个地方发现错误原因的线索。 ◆ 蛮干法可能是寻找软件错误原因的最低效的方 法。仅当所有其他方法都失败了的情况下，才应 该使用这种方法。
3) 演绎法 ◆ 从一般原理或前提出发，经过排除和精化的过 程推导出结论。 ◆ 采用这种方法调试程序时，首先设想出所有可 能的出错原因，然后试图用测试来排除每一个 假设的原因。 ◆ 如果测试表明某个假设的原因可能是真的原因， 则对数据进行细化以准确定位错误。 总结： ◆ 上述3种调试途径都可以使用调试工具辅助完成， ◆ 如果用遍了各种调试方法和调试工具却仍然找不 出错误原因，则应该向同行求助。
软件工程 第七版 第2章 软件项目计划
第2章 2.5 MicroSoft Office Visio 2003
16
2.5.1 MicroSoft Office Visio 2003简介
1. 使用VISIO的帮助 2. 新建绘图文件 3. 图件、模具与模板概念
第2章 2.5 MicroSoft Office Visio 2003
17
2.5.2 使用 Visio 绘制系统流程图
第2章 2.2 可行性研究
10
2.2.2 可行性研究的步骤
1.审核系统的规模和目标 2.分析研究现行系统 3.设计新系统的高层逻辑模型 4.获得并比较可行的方案 5.撰写可行性研究报告
第2章 2.2 可行性研究
11
2.2.3 系统流程图
第2章 2.2 可行性研究
12
2.2.4 经济可行性
在可行性研究过程中，经济可行性研究占有重要地位，它从经济上衡量一个项目是否 有开发价值。
1．打开Visio，选择左侧绘图类型“流程图”，并在右侧选择“基本流程图”模 2．添加形状。 3．调整大小和角度。 4．移动位置并输入文本 5．连接形状 6．输入文本。有两种方法为图形添加文本。 7．选择图形、对齐及排版。 8．保存文件
第2章 2.6 项目实践：图书管理系统可行性研究与项目计划
18
第2章 软件项目计划
3
课程 思政
第2章 2.1问题定义
4
第2章 2.1问题定义
5
2.1.1 问题定义的内容
（1）问题的背景，弄清楚待开发系统现在处于什么状态，为什么要开发它，是否具备开 发条件等问题。
（2）提出开发系统的问题要求以及总体要求。 （3）明确问题的性质、类型和范围。 （4）明确待开发系统要实现的目标、功能和规模。 （5）提出开发的条件要求和环境要求。
第7章软件工程全解PPT课件
D.9
11
7.2面向对象技术基础
• 考点:面向对象分析与设计的基本概念，包括对象，类， 消息，继承，多态等
• 一、基本概念 1.对象 2.消息 3.类 4.继承 5.多态 6.动态绑定
12
• 二、面向对象分析与设计基本概念 1.面向对象分析（OOA）：建立待开发软件系统的模型 2.面向对象设计（OOD）：定义系统构造蓝图，并根据系
• A.这三个对象所存储的数据一定是不同的 • B.这三个对象所存储的数据一定是相同的 • C.这三个对象一定具有相同的操作 • D.这三个对象无法共享数据 • 2.下列关于超类,子类,基类的叙述中,正确的是 A • A.子类是超类的特化 B.基类是超类的特化 • C.基类是子类的特化 D.超类是基类的特化
描述了谁将使用系统以及用户期望以什么方式与系统交 互。 序列图：描述了在一个用例或操作的执行过程中以时间顺 序组织的对象之间的交互活动 通信图：强调收发消息的对象之间的结构组织。
14
• 状态图：展现了一个状态机，由状态、转换、事件和活 动组成，用于建模时间如何改变对象的状态以及引起对 象从一个状态向另一个状态转换的事件。
3
7.1 软件工程和项目管理基础
➢考点：软件工程和软件生存周期的概念，软件开 发 项目管理的基础知识
➢一、软件的生存周期 可行性分析和项目开发计划； 需求分析 软件设计 编码 测试和维护
4
二、软件开发项目管理基础知识
➢ 1.成本估算 （1）自顶向下估算方法 （2）自底向上估算方法 （3）差别估算方法
_7iX7n3C0yKIn5eejUpBn4dVAPMttK8UcWRNKHAQneYpivigBd aVWD_c5d0foeYRW_0RwIWSuZ4aBHMLkQq • 3.加工逻辑（小说明） • 1.结构化语言 • 2.判定表 • 3.判定树
软件工程7-2
静态测试约可找出30～70%的逻辑设计错误.
动态黑盒测试 —闭着眼睛测试软件
输入
软件
输出
不深入代码细节的测试方法称为动态黑盒测试。 软件测试员充当客户来使用它。
动态白盒测试 —带上X光眼镜测试软件
250*(1+0.015)*((1+0.015)^360-1)/0.015
250*(1+0.015)*((1+0.015)^360-1)/0.015
检验每个模块能否单独工作. 检验概要设计中模块接口设计问题 以需求规格说明书为检验尺度 综合检验 测试可视为分析、设计、编码三个阶段的最终 复审,以保证软件质量.
测试原则（9条）
所有的测试都应追溯到用户需求 概要设计时应完成测试计划
pareto原则：测试发现的错误中80%很可能起源于20%的模块中。 应孤立这些疑点模块重点测试。
3. 测试人员的组织
3.3 避免开发人员与测试人员产生矛盾 开发人员的注意事项： 不要敌视测试人员。要理解测试的目的就是发现缺陷， 是测试人员的工作职责。不要以为测试人员吃饱了没 事干，存心找茬。 不要轻视测试人员，别说人家技术水平差，不配搞开 发只好搞测试。 测试人员的注意事项： 发现缺陷时不要嘲笑开发人员，别说他的程序真臭、 到处是Bug。 在开发人员压力太大时或心情不好时不要火上浇油， 发现缺陷时别大声嚷嚷。 请留意另一种极端：如果测试人员与开发人员的关系非常
软件测试背景
软件是人编的—所以不完美 实例:
• 1994-1995,迪斯尼的狮子王系统不支持问题 • Intel 的 pentium 处理器
• 1994 年浮点除法缺陷 • 2000 年 8 月 28 日，1.13 MHZ 处理器一个可能导致运
软件工程七版Chapter需求建模场景、信息与类分析PPT课件
(1) 我们应该写什么？ (2) 我们应该写多少？ (3) 我们编写说明应该多详细？ (4) 我们如何组织说明？
.Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright
2009 by Roger Pressman.Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill,
2009 by Roger Pressman.Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill,
2009). Slides copyright 2009 by Roger Pressman.
11
参与者—识别思路
谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付那些硬件设备 系统需要和那些外部系统交互 谁对系统运行产生的结果感兴趣
2009). Slides copyright 2009 by Roger Pressman.
1
经验原则
模型应关注在问题域或业务域内可见的需求，抽象的级 别应该相对高一些。
需求模型的每个元素都应能增加对软件需求的整体理解， 并提出对信息域、功能和系统行为的深入理解。
关于基础结构和其他非功能的模型应推延到设计阶段再 考虑。
2009). Slides copyright 2009 by Roger Pressman.
3
需求分析的元素
基于场景的 模型如： 用例 用户故事
.Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright
2009 by Roger Pressman.Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill,
2009 by Roger Pressman.Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill,
2009). Slides copyright 2009 by Roger Pressman.
11
参与者—识别思路
谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付那些硬件设备 系统需要和那些外部系统交互 谁对系统运行产生的结果感兴趣
2009). Slides copyright 2009 by Roger Pressman.
1
经验原则
模型应关注在问题域或业务域内可见的需求，抽象的级 别应该相对高一些。
需求模型的每个元素都应能增加对软件需求的整体理解， 并提出对信息域、功能和系统行为的深入理解。
关于基础结构和其他非功能的模型应推延到设计阶段再 考虑。
2009). Slides copyright 2009 by Roger Pressman.
3
需求分析的元素
基于场景的 模型如： 用例 用户故事
软件工程 第七版 Chapter_04理解需求
f orm al priorit izat ion? no inf orm ally priorit ize requirem ent s
形式地划分 优先级？
def ine act ors
导出需求
使用QFD划 分需求的 优先级
Use QFD t o priorit ize requirem ent s
20
用例图
Arms/ disarms syst em
安装/接触系统
Accesses syst em via Int ernet homeow ner
通过因特网 访问系统
sensors
传感器
房主
Responds t o alarm event
报警事件 的响应
遇到错误 条件
Encount ers an error condit ion
需求分析为什么重要？
（2）需求分析的输出文档是《用户需求报告》， 它是客户、软件开发人员和项目管理人员三者必 须遵守的一根基线，三者共同工作的基础，是测 试的准则。 （3）需求分析要占用整个软件开发时间或工作量 的30%左右。 （4）需求获取中的错误，属于软件开发中的早期 错误，它会在后续的设计和实现中进行发散式的 传播。 根据以上四项原因，IT企业的高层经理，对 需求分析特别重视，常常派经验最丰富的人员去 作项目需求。正因为如此，“系统分析员”才是 软件行业中的最高技术职称。
质量功能部署
功能部署决定系统所需的每一个功能的“价值” （由客户感知） 信息部署确定数据对象和事件 任务部署检查系统行为 价值分析决定需求的相对优先权
16
导出工作产品
要求和可行性陈述。 系统或产品范围的界限说明。 参与需求导出的客户、用户和其他利益相关者的名单。 系统技术环境的说明。 需求列表（最好按照功能加以组织）以及每个需求使用的领 域限制。 一系列使用场景，有助于深入了解系统或产品在不同运行环 境下的使用。 任何能够更好地定义需求的原型。
软件工程第七版Chapter_02v1过程模型
部署 交付 反馈
M odeling analysis design
建模
Cons t ruc t i on code t est
De plo y m e n t d e l iv e ry fe e dbac k
分析 设计
构件 编码 测试
部署 交付 反馈
delivery of
1st increment
12
惯用模型
惯用过程模型提倡有序的软件工程方法 因此导致一些问题… 如果传统过程模型力求实现结构化和有序，那么
对于富于变化的软件世界，这一模型是否合适呢？ 如果我们抛弃传统过程模型（以及它们带来的秩
序），取而代之以一些不够结构化的模型，是否 会使如软件工作无法达到协调和一致？
13
瀑布模型
功能和特性需求 开发人员可能对算法的效率、操作系统的兼
容性和人机交互的形式等情况并不确定 2.特点 很少是好用的，可能太慢太大，难以使用。 一般作为被丢弃的系统。
20
特点： 采用循环的 方式逐步加 深系统定义 和实现的深 度，同时降 低风险。 确定一系列 里程碑，确 保利益相关 者都支持可 行的和令人 满意的系统 解决方案。
5
过程模式
一个过程模式
描述了软件工程工作中遇到的过程相关的问题 明确了问题环境 并给出了针对该问题的一种或几种可证明的解决方案
通俗地讲，过程模式提供了一个描述模版 [Amb98]—一种在软件过程的背景下，统一描述 问题解决方案的方法。
6
过程模式描述模板
模式名称：表述该模式在软件过程中的含 义。
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
M odeling analysis design
建模
Cons t ruc t i on code t est
De plo y m e n t d e l iv e ry fe e dbac k
分析 设计
构件 编码 测试
部署 交付 反馈
delivery of
1st increment
12
惯用模型
惯用过程模型提倡有序的软件工程方法 因此导致一些问题… 如果传统过程模型力求实现结构化和有序，那么
对于富于变化的软件世界，这一模型是否合适呢？ 如果我们抛弃传统过程模型（以及它们带来的秩
序），取而代之以一些不够结构化的模型，是否 会使如软件工作无法达到协调和一致？
13
瀑布模型
功能和特性需求 开发人员可能对算法的效率、操作系统的兼
容性和人机交互的形式等情况并不确定 2.特点 很少是好用的，可能太慢太大，难以使用。 一般作为被丢弃的系统。
20
特点： 采用循环的 方式逐步加 深系统定义 和实现的深 度，同时降 低风险。 确定一系列 里程碑，确 保利益相关 者都支持可 行的和令人 满意的系统 解决方案。
5
过程模式
一个过程模式
描述了软件工程工作中遇到的过程相关的问题 明确了问题环境 并给出了针对该问题的一种或几种可证明的解决方案
通俗地讲，过程模式提供了一个描述模版 [Amb98]—一种在软件过程的背景下，统一描述 问题解决方案的方法。
6
过程模式描述模板
模式名称：表述该模式在软件过程中的含 义。
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
文件单词数目统计
读取和验证文件名
统计 单词数目
格式化和显示 单词数
读文件名
验证文件名
格式化单词数
显示单词数
23
事务分析设计
事务分析设计方法生成软件结构的步骤： (1) 划分边界，明确数据流图中的接收路径、 事务中心和加工路径
– 确定事务中心：位于多条加工路径的起点，经 过事务中心的数据流被分解为多个发散的数据 流。 – 接收路径：向事务中心提供数据的路径。 – 加工路径：从事务中心引出的所有路径。
3
提纲
• • • • 面向数据流的体系结构设计方法 详细设计的任务、工具和原则 详细设计的方法 面向数据结构的设计方法
4 of 96 4
提纲
• • • • 面向数据流的体系结构设计方法 详细设计的任务、工具和原则 详细设计的方法 面向数据结构的设计方法
5
面向数据流的体系结构设计
• 任务 将数据流图转换成设计阶段所需的软件结 构 • 数据流类型
计算应发工资模块N－S图
43
PAD图
• PAD(Problem Analysis Diagram，问题分 析图) • 采用了树型结构图形符号 • 优点：
(1) 描述的程序结构层次清晰，逻辑结构关系直 观、易读、易记、易修改。 (2) 易于向高级语言源程序转换。 (3) 支持自顶向下、逐步求精的设计过程。 (4) 既能够描述程序的逻辑结构，又能够描述系 统中的数据结构。
计划管 理
2
软件设计三类活动
总体设计：也称概要设计，软件结构设计，或高层设计
• • • • 分析需求规格说明 模块划分，形成具有预定功能的模块组成结构 表示出模块间的控制关系 给出模块之间的接口
详细设计：也称（模块）过程设计，或低层设计。
• 设计模块细节 • 确定模块所需的算法和数据结构等
测试和复审
44
S1 条件 S2
T F
S1
CASE 值1 值2
S1 S2
…
值n Sn (a) (b) (c) S1 WHILE条件 S UNTIL条件 S S S2
(d)
(e)
(f)
PAD中基本符号 (a)顺序结构；(b) 分支结构；(c) 多分支CASE结构； (d) 当型循环；(e) 直到型循环；(f) 对s的细化
审计 记录
修改密码
30
ATM机系统结构
ATM机处理事务主控
分析器
调度器
事务选择
查询
存款
取款
转账
修改密码
编辑事务
更新文件
31
混合流设计：销售管理系统
订货 输入 读入 数据
判别
订货 处理
库存 修改 分析 统计
提货 发票 进货 票据
生成 统计表
进货 输入
订单 记录
32
混合流设计
销售管理系统
读入数据 判别
19
工资计算系统
取得基本数据 计算工资 输出计算结果
取得 水电 扣款
计算出勤 奖和缺勤 扣款
计算业 绩奖
计算基 本工资
计算应 发工资
计算实 发工资
生成工 资存款 清单
打印工 资清单
读水 电扣 款
读考勤 表
读业绩 表
读工资 档案
计算奖 金之和
计算所 得税
查找职工银 行工资账号
完成二级分解后的工资计算系统软件结构
24
E A 接收路径 B C 事务中心 H
F
G
加工路径 1
I K
J
加工路径 2
进行了边界划分的事务型数据流图
25
事务分析设计
事务分析设计方法生成软件结构的步骤： (2) 建立事务型结构的上层模块 • 软件结构的顶层只有一个由事务中心映射 得到的总控模块； • 总控模块有两个下级模块，分别是由接收 路径映射得到的接收模块和由全部加工路 径映射得到的调度模块。 • 接收模块负责接收系统处理所需的数据 • 调度模块负责控制下层的所有加工模块。
15
工资档案F2
出勤表 人事部门 业绩表
统计 出勤、请假 及旷工时数
出勤时数
计算 出勤奖 出勤奖 计算缺勤 扣款
计算各项 基本数据 之和
基本工资
请假及 旷工时数 计算 业绩奖 业绩奖
计算各项 奖金之和 缺勤扣款表
奖金发放表
计算应 发工资 应发工资表
奖惩条例F1 后勤部门 水电扣款表
所得税扣款 计算 实发工资
(c) 计算应发工资模块PAD图
46
开始
找到了吗? Y
N
显示错误
在奖金发放表中查找职工号与num相同的记录
在工资档案中读一条记录
N 是文件结束位置吗? 找到了吗? 显示错误
41
盒图符号
A B a.顺序 F B P A T F P A T Do while p S c.do-while 循环
b.IF-THEN-ELSE 选择 P
S Do until p d.do-until 循环
=1 =2 A1 A2 e.多分支选择
=n An
42
在工资档案中读一条记录 是文件结束位置吗? 计算工资各项基本数据之和并存入pay num＝当前职工号 在奖金表中查职工号与num相同的记录 T 找到了吗? F 计算各项奖金总和并存入bonus 显示 错误 应发工资＝pay＋bonus 读下一条记录
键盘 输入
订货处理
进货处理
销售统计
订货 输入
订货 处理
提货 发票
进货 输入
库存 修改
进货 票据
订单 记录
分析 统计
统计 表
33
提纲
• • • • 面向数据流的体系结构设计方法 详细设计的任务、工具和原则 面向数据流的详细设计的方法 面向数据结构的设计方法
34
详细设计
任务： (1) 确定每个模块的具体算法 (2) 确定每个模块的内部数据结构及数据库的 物理结构 (3) 确定模块接口的具体细节 (4) 为每个模块设计一组测试用例 (5) 编写文档，参加复审
28
总控
B
调度
A E
事务1
事务2
F
G
H J
I K
29
完整的事务型软件结构
事务流设计：ATM系统
查询
事务1 事务2 事务选择 有效 事务
更新事务v 更新事务w 更新事务x 更新事务y 更新事务z
审计信息
存款 取款 转账
有效 事务
有效 事务 有效 事务 有效 事务
确定事 务类型
事务3 事务4 事务5
35
详细设计的工具
• • • • 程序流程图 N-S图 PAD图 PDL语言
36
程序流程图
• 有效描述问题求解过程中的程序逻辑结构 • 优点：对程序的控制流程描述直观、清晰， 使用灵活，便于阅读和掌握 • 缺点：
(1) 可随心所欲地使用流程线，容易造成程序控 制结构的混乱 (2) 难以描述逐步求精的过程，容易导致程序员 过早考虑程序的控制流程，而忽略程序全局结 构的设计。 (3) 难以表示系统中的数据结构。
45
…
Sn
…
S2
(a)
在工资档案中读一条记录 当文件没有读完时 计算应发工资 num＝当前职工号 def 检索个人奖金 找到了吗? 读下一条记录 在奖金表中查找职工号与num相同的记录 T F 检索个人奖金
(b)
计算应发工资 显示错误信息
计算各项奖金之和并存入bonus def 计算应发工资 计算工资基本数据项之和并存入pay 应发工资＝pay＋bonus
变换流
时间
8
事务型数据流图
• 结构特点：输入流经过 “事务中心”的加工被分离 为多个发散输出流，形成多个平行的加工处理路径 • 描述的加工过程
– 外部数据进入系统，被送往事务中心； – 事务中心接收输入数据，分析确定其类型； – 根据输入数据类型为其选择一条加工路径。
…输入流事务 中心加工路径接收路径
20
变换流设计
• 设计一个“统计输入文件中单词数目”程序。
文件名
读文 件名
文件名
验证 文件名
有效的 文件名
统计 单词数
单词 格式化 格式化 总数 单词数
单词数
显示 单词数
单词总数
输入流边界
输出流边界
21
第一次分解
文件单词数目统计
读取和验证 文件名
统计 单词数目
格式化和显示 单词数
22
第二次分解
软件工程
第7讲 软件设计（2）
贾西平
Email: jiaxp@
本课程的学习内容
概述 需求分析 软件设计 测试与维 护 项目管理
07:58
基本概 念
需求分 析过程 设计概 述 软件测 试
过程模 型
结构化 分析 结构化 设计 软件维 护 面向对 象分析 面向对 象设计 软件实 现
项目估 算
在奖金表中查职
计算各项奖金总
应发工资＝p
读下 结束
(a) 计算应发工资模块程序流程图
40
N-S图
• 又称盒图 • 所有的程序结构均使用矩形框表示 • 优点：
– 能清晰表达结构中的嵌套及模块的层次关系 – 有利于培养软件设计人员的良好设计风格。
• 缺点：
– 当描述的程序嵌套层次较多时，N－S图的内层 方框会越画越小，影响可读性，且不易修改。
37
程序流程图常用符号
(a)
(b)
(c)
(d)
(e)
图5.17 程序流程图中的基本符号 (a) 一般处理框；(b) 输入/输出框；(c) 判断框；(d) 流程线；(e) 起止框
38
读取和验证文件名
统计 单词数目
格式化和显示 单词数
读文件名
验证文件名
格式化单词数
显示单词数
23
事务分析设计
事务分析设计方法生成软件结构的步骤： (1) 划分边界，明确数据流图中的接收路径、 事务中心和加工路径
– 确定事务中心：位于多条加工路径的起点，经 过事务中心的数据流被分解为多个发散的数据 流。 – 接收路径：向事务中心提供数据的路径。 – 加工路径：从事务中心引出的所有路径。
3
提纲
• • • • 面向数据流的体系结构设计方法 详细设计的任务、工具和原则 详细设计的方法 面向数据结构的设计方法
4 of 96 4
提纲
• • • • 面向数据流的体系结构设计方法 详细设计的任务、工具和原则 详细设计的方法 面向数据结构的设计方法
5
面向数据流的体系结构设计
• 任务 将数据流图转换成设计阶段所需的软件结 构 • 数据流类型
计算应发工资模块N－S图
43
PAD图
• PAD(Problem Analysis Diagram，问题分 析图) • 采用了树型结构图形符号 • 优点：
(1) 描述的程序结构层次清晰，逻辑结构关系直 观、易读、易记、易修改。 (2) 易于向高级语言源程序转换。 (3) 支持自顶向下、逐步求精的设计过程。 (4) 既能够描述程序的逻辑结构，又能够描述系 统中的数据结构。
计划管 理
2
软件设计三类活动
总体设计：也称概要设计，软件结构设计，或高层设计
• • • • 分析需求规格说明 模块划分，形成具有预定功能的模块组成结构 表示出模块间的控制关系 给出模块之间的接口
详细设计：也称（模块）过程设计，或低层设计。
• 设计模块细节 • 确定模块所需的算法和数据结构等
测试和复审
44
S1 条件 S2
T F
S1
CASE 值1 值2
S1 S2
…
值n Sn (a) (b) (c) S1 WHILE条件 S UNTIL条件 S S S2
(d)
(e)
(f)
PAD中基本符号 (a)顺序结构；(b) 分支结构；(c) 多分支CASE结构； (d) 当型循环；(e) 直到型循环；(f) 对s的细化
审计 记录
修改密码
30
ATM机系统结构
ATM机处理事务主控
分析器
调度器
事务选择
查询
存款
取款
转账
修改密码
编辑事务
更新文件
31
混合流设计：销售管理系统
订货 输入 读入 数据
判别
订货 处理
库存 修改 分析 统计
提货 发票 进货 票据
生成 统计表
进货 输入
订单 记录
32
混合流设计
销售管理系统
读入数据 判别
19
工资计算系统
取得基本数据 计算工资 输出计算结果
取得 水电 扣款
计算出勤 奖和缺勤 扣款
计算业 绩奖
计算基 本工资
计算应 发工资
计算实 发工资
生成工 资存款 清单
打印工 资清单
读水 电扣 款
读考勤 表
读业绩 表
读工资 档案
计算奖 金之和
计算所 得税
查找职工银 行工资账号
完成二级分解后的工资计算系统软件结构
24
E A 接收路径 B C 事务中心 H
F
G
加工路径 1
I K
J
加工路径 2
进行了边界划分的事务型数据流图
25
事务分析设计
事务分析设计方法生成软件结构的步骤： (2) 建立事务型结构的上层模块 • 软件结构的顶层只有一个由事务中心映射 得到的总控模块； • 总控模块有两个下级模块，分别是由接收 路径映射得到的接收模块和由全部加工路 径映射得到的调度模块。 • 接收模块负责接收系统处理所需的数据 • 调度模块负责控制下层的所有加工模块。
15
工资档案F2
出勤表 人事部门 业绩表
统计 出勤、请假 及旷工时数
出勤时数
计算 出勤奖 出勤奖 计算缺勤 扣款
计算各项 基本数据 之和
基本工资
请假及 旷工时数 计算 业绩奖 业绩奖
计算各项 奖金之和 缺勤扣款表
奖金发放表
计算应 发工资 应发工资表
奖惩条例F1 后勤部门 水电扣款表
所得税扣款 计算 实发工资
(c) 计算应发工资模块PAD图
46
开始
找到了吗? Y
N
显示错误
在奖金发放表中查找职工号与num相同的记录
在工资档案中读一条记录
N 是文件结束位置吗? 找到了吗? 显示错误
41
盒图符号
A B a.顺序 F B P A T F P A T Do while p S c.do-while 循环
b.IF-THEN-ELSE 选择 P
S Do until p d.do-until 循环
=1 =2 A1 A2 e.多分支选择
=n An
42
在工资档案中读一条记录 是文件结束位置吗? 计算工资各项基本数据之和并存入pay num＝当前职工号 在奖金表中查职工号与num相同的记录 T 找到了吗? F 计算各项奖金总和并存入bonus 显示 错误 应发工资＝pay＋bonus 读下一条记录
键盘 输入
订货处理
进货处理
销售统计
订货 输入
订货 处理
提货 发票
进货 输入
库存 修改
进货 票据
订单 记录
分析 统计
统计 表
33
提纲
• • • • 面向数据流的体系结构设计方法 详细设计的任务、工具和原则 面向数据流的详细设计的方法 面向数据结构的设计方法
34
详细设计
任务： (1) 确定每个模块的具体算法 (2) 确定每个模块的内部数据结构及数据库的 物理结构 (3) 确定模块接口的具体细节 (4) 为每个模块设计一组测试用例 (5) 编写文档，参加复审
28
总控
B
调度
A E
事务1
事务2
F
G
H J
I K
29
完整的事务型软件结构
事务流设计：ATM系统
查询
事务1 事务2 事务选择 有效 事务
更新事务v 更新事务w 更新事务x 更新事务y 更新事务z
审计信息
存款 取款 转账
有效 事务
有效 事务 有效 事务 有效 事务
确定事 务类型
事务3 事务4 事务5
35
详细设计的工具
• • • • 程序流程图 N-S图 PAD图 PDL语言
36
程序流程图
• 有效描述问题求解过程中的程序逻辑结构 • 优点：对程序的控制流程描述直观、清晰， 使用灵活，便于阅读和掌握 • 缺点：
(1) 可随心所欲地使用流程线，容易造成程序控 制结构的混乱 (2) 难以描述逐步求精的过程，容易导致程序员 过早考虑程序的控制流程，而忽略程序全局结 构的设计。 (3) 难以表示系统中的数据结构。
45
…
Sn
…
S2
(a)
在工资档案中读一条记录 当文件没有读完时 计算应发工资 num＝当前职工号 def 检索个人奖金 找到了吗? 读下一条记录 在奖金表中查找职工号与num相同的记录 T F 检索个人奖金
(b)
计算应发工资 显示错误信息
计算各项奖金之和并存入bonus def 计算应发工资 计算工资基本数据项之和并存入pay 应发工资＝pay＋bonus
变换流
时间
8
事务型数据流图
• 结构特点：输入流经过 “事务中心”的加工被分离 为多个发散输出流，形成多个平行的加工处理路径 • 描述的加工过程
– 外部数据进入系统，被送往事务中心； – 事务中心接收输入数据，分析确定其类型； – 根据输入数据类型为其选择一条加工路径。
…输入流事务 中心加工路径接收路径
20
变换流设计
• 设计一个“统计输入文件中单词数目”程序。
文件名
读文 件名
文件名
验证 文件名
有效的 文件名
统计 单词数
单词 格式化 格式化 总数 单词数
单词数
显示 单词数
单词总数
输入流边界
输出流边界
21
第一次分解
文件单词数目统计
读取和验证 文件名
统计 单词数目
格式化和显示 单词数
22
第二次分解
软件工程
第7讲 软件设计（2）
贾西平
Email: jiaxp@
本课程的学习内容
概述 需求分析 软件设计 测试与维 护 项目管理
07:58
基本概 念
需求分 析过程 设计概 述 软件测 试
过程模 型
结构化 分析 结构化 设计 软件维 护 面向对 象分析 面向对 象设计 软件实 现
项目估 算
在奖金表中查职
计算各项奖金总
应发工资＝p
读下 结束
(a) 计算应发工资模块程序流程图
40
N-S图
• 又称盒图 • 所有的程序结构均使用矩形框表示 • 优点：
– 能清晰表达结构中的嵌套及模块的层次关系 – 有利于培养软件设计人员的良好设计风格。
• 缺点：
– 当描述的程序嵌套层次较多时，N－S图的内层 方框会越画越小，影响可读性，且不易修改。
37
程序流程图常用符号
(a)
(b)
(c)
(d)
(e)
图5.17 程序流程图中的基本符号 (a) 一般处理框；(b) 输入/输出框；(c) 判断框；(d) 流程线；(e) 起止框
38