软件工程导论课件

软件工程导论

1.1.1软件的定义

软件的经典定义： 软件=“完成特定功能的程序+数据结构+文档”软件的特征：

1、软件是开发的，而不是制造的；

2、软件不磨损，但退化；

3、自定义。1.1.1软件的定义

软件发展中的相关问题：

硬件的发展超过软件；

现有软件与用户的要求矛盾；

软件失败导致“灾难性后果”；

需要高质量、高可靠性的软件；

设计的问题使升级和维护十分困难。1.1.1软件危机的定义

定义

“在计算机软件的开发和维护过程中所遇到的一系列严重的问题。”1.1.2软件危机的表现（1）对软件开发成本和进度的估计常常很不准确。

实际成本往往大大超过估计成本，或开发进度比计划推迟几个月或一年以上。这种现象极大地影响了软件开发组织的信誉，也会引起用户的强烈不满。（2）软件产品质量较差，可靠性低。

软件开发过程中不能坚持严格的审查、复审和测试，使得软件可靠性差、质量问题多。

1.1.2软件危机的表现（3）用户对开发出来的软件产品不满意。开发人员与用户之间的交流不充分，仅对用户需求有了一个模糊的认识就匆忙开始写程序。这样的结果就是用户对于所谓已经完成的软件很不满意。（4）软件常常是不可维护的。在实际项目中，很多程序的错误往往难以修改，而且不能适应软硬件环境的变化，也无法添加用户需要的一些新功能。1.1.2软件危机的表现（5）软件产品缺少应有的文档资料。软件=程序+数据+文档。开发人员对文档认识不足，不能保证在开发过程中文档的完整性和准确性。缺少文档资料会造成软件开发、管理、审查、用户交流、软件维护等方面的诸多问题。（6）软件产品的供不应求。软件开发的生产率远远低于计算机硬件发展速度和用户的需求，造成了软件产品的供不应求。1.1.3产生软件危机的原因客观原因：软件与硬件产品不同，软件是“开发的”而非“制造的”。其开发过程难以管理和控制，产品质量也不好把握。软件没有“磨损”，但是它会不断“退化”。软件系统无法适应不断变化的环境和功能需求。软件都规模庞大，而程序的复杂性是随其规模的扩大呈指数增加。主观原因：对用户要求没有完整和准确的认识就匆忙编写程序。对软件的开发过程的认识不准确。生命周期的每个阶段都有特定的工作和特点，都是不可逾越的。只有上一阶段工作完成，才能开始下一阶段的工作。对软件质量的重视不够是造成软件开发成本激增的主要原因。注意软件开发过程中错误的“放大效应”。轻视软件维护将是一个重大的错误。软件开发时期各阶段的关键目标都是提高软件的可维护性。1.1.3产生软件危机的原因第1章软件工程学概述

1.1软件危机

1.2软件工程

1.3软件生命周期

1.4软件过程1.2软件工程为了更有效地开发与维护软件，软件工作者在20世纪60年代后期开始认真研究消除软件危机的途径，从而逐渐形成了一门新兴的工程学科——计算机软件工程学(简称为软件工程)。

1.2.1软件工程的概念

定义指导软件开发与维护的工程科学采用工程的概念、原理、技术和方法来开发和维护软件，综合运用正确的管理技术和最好的技术方法，以经济地开发出高质量的软件并有效维护它。

1.2.1软件工程的概念

IEEE的定义

①软件工程是把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；②对这些途径加以研究。

1.2.1软件工程的概念诸多软件工程的定义所揭示的软件工程的本质认识是一致的：软件工程一般更关注于大型软件系统的开发；其中心任务是控制整个软件系统的复杂性，提高软件开发的效率，加强人员和技术的管理，更好地满足用户的需要。1.2.2软件工程的基本原理（1）用分阶段的生命周期计划严格管理应该将软件开发和维护的漫长生命周期划分成若干个阶段，并针对每个阶段制定切实可行的计划，然后严格按照计划对软件的开发和维护工作进行管理。（2）坚持进行阶段评审错误发现的越早，改正错误所付出的代价就越小。因此，开发人员应该坚持在每个阶段都进行严格的评审，以便更早地发现和改正错误。1.2.2软件工程的基本原理（3）实行严格的产品控制在软件开发的过程中不应随意修改需求，当改变需求时，必须实行严格的产品控制以保持软件各个配置成分的一致性。（4）采用现代程序设计技术

采用先进的技术不仅可以提高软件开发和维护的效率，而且还能有效地提高软件产品的质量。

1.2.2软件工程的基本原理（5）结果可以清楚地审查

应规定每个开发阶段的产品标准和文档要求，使得到的结果可以清楚地审查。

（6）开发小组成员少而精软件开发小组人员要求素质高，而人数不宜过多。随着人数n的增加，通信路径也急剧增加。1.2.2软件工程的基本原理（7）承认不断改进软件工程实践的必要性软件开发和维护的过程也需要随之改进。要主动采用最新的软件技术，而且还要不断总结经验和教训、收集历史数据帮助开发人员改进软件工程实践。1.2.3软件工程方法学软件生命周期全过程中使用的一整套技术方法的集合称为方法学。

软件工程方法学主要包含3个要素：方法、工具和过程。

目前使用最为广泛的软件工程方法学是传统方法学和面向对象方法学。1.2.3软件工程方法学1.传统方法学-也称为生命周期方法学或结构化范型。

-它采用结构化技术（包括结构化分析、结构化设计和结构化实现）来完成软件开发的各项任务。

-这种方法学将软件生命周期划分为若干个阶段，然后顺序完成各个阶段的任务。每个阶段依赖上一个阶段产生的结果，并将上一阶段工作进一步具体化。1.2.3软件工程方法学2.面向对象方法学-以数据为主线，将数据和其上的操作紧密结合起来。面向对象方法学的四要素：类+对象+继承+消息传递。

-面向对象的方法学是尽量模拟人类习惯的思维方式，使软件开发过程更接近人类认知模式，做到问题空间与解空间在结构上一致。-运用面向对象方法学开发出来的软件产品一般是由很多较小的独立对象组成，从而降低了软件产品的复杂性，增强了可理解性，使得开发和维护更为简单有效。第1章软件工程学概述

1.1软件危机

1.2软件工程

1.3软件生命周期1.3.1软件生命周期的概念

定义

一个软件从定义、开发、使用和维护，直至最终被废弃，要经历的漫长的时期称为软件生命周期。1.3.1软件生命周期的概念

构成3个时期：软件定义、软件开发和运行维护各时期任务：

软件定义时期：确定软件开发的总目标和工程的可行性；导出实现策略和系统必须完成的功能；进行成本效益的估算；制定开发计划等。

软件开发时期：具体设计和实现前一个时期定义的软件。

维护时期：使软件持久地满足用户的需要。1.3.1软件生命周期的概念

构成3个时期：软件定义、软件开发和运行维护8个阶段：

问题定义

可行性研究

需求分析

总体设计详细设计

编码和单元测试

综合测试软件维护阶段1:问题定义“需要解决的问题是什么？”

确定问题的性质

软件目标和规模

形成书面报告。

1.3.2各阶段的基本任务阶段2:可行性研究“确定软件系统是否值得去解”

高层次的系统分析和设计

估算系统的成本和效益

《可行性研究报告》1.3.2各阶段的基本任务阶段3:需求分析“解决这些问题需要系统做什么？”

与用户的交流

生成系统的逻辑模型

《软件需求规格说明书》1.3.2各阶段的基本任务阶段4:总体设计（概要设计）“应该怎样实现目标系统？”

设计出实现目标系统的方案

设计软件结构，确定模块及之间关系

概要设计说明书1.3.2各阶段的基本任务阶段5:详细设计（模块设计）

“如何具体地实现这个系统？”

详细的设计每个模块的算法和数据结构

1.3.2各阶段的基本任务阶段6:编码和单元测试“写代码，测试每个模块！”

选取程序设计语言

写出容易理解和维护的程序模块

对每一个模块进行严格的测试1.3.2各阶段的基本任务阶段7:综合测试“通过各类测试和调试来完善软件”

集成测试+验收测试(用户参加)

保存测试计划、测试方案和测试结果1.3.2各阶段的基本任务阶段8:软件维护“通过各种必须的维护活动使系统持久地满足用户的需要！”

改正性维护

适应性维护

完善性维护

预防性维护1.3.2各阶段的基本任务1.3.3软件生命周期的模型

定义在软件开发过程中，人们通常使用生命周期模型来简要地描述软件过程。生命周期模型规定了生命周期各个阶段和它们执行的顺序，因此也被称为过程模型。1.瀑布模型—线性模型之一

在20世纪80年代之前，瀑布模型一直是惟一被广泛采用的生命周期模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。

瀑布模型1.瀑布模型—线性模型之一瀑布模型的特点：

（1）各阶段之间有依赖性和严格的顺序性。

（2）推迟实现。

——典型特点（3）严格的阶段质保。（4）文档驱动。

瀑布模型的问题：（1）实际的项目很少顺序严格（2）用户往往难以给出具体、正确、完整的要求（3）开发人员“阻塞状态”严重1.瀑布模型—线性模型之一

2.原型模型原型模型是一个快速开发的过程，首先和用户沟通进行主要功能的需求分析和快速设计，然后建立一个原型，再请用户进行评价和反馈。开发人员根据用户的反馈进一步细化需求，改进原型系统的设计，如此反复直至用户满意。快速需求分析（用户沟通）构建/修改模型（快速设计）用户使用评价（运行测试）原型模型2.原型模型快速原型模型的特点：

(1)出品速度快。

(2)逐步求精。

(3)开发阶段迭代。快速原型模型的问题： (1)实现过程中不应有的折衷方案。

(2)开发者急于完成原型而忽略了整体设计和可维护性；

(3)用户的参与过多也造成了软件开发管理的混乱。

2.原型模型增量模型也称为渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。分析设计编码测试交付增量1分析设计编码测试交付增量2……项目时间分析设计编码测试交付增量n增量模型3.增量模型软件系统3.增量模型增量模型增量模型的特点：

(1)结合了线性模型和原型模型的特点；

(2)每个增量可以结合原型法；

(3)系统的问世提前→“增量1”增量模型的问题：开放的软件体系结构

中心思想：“渐进开发，逐步完善”3.增量模型-使用增量模型开发时，第一个增量往往是系统中的核心构件，同时，要求产品分解成增量构件的规模应当适中。

-如何不破坏已经开发的构件将新的构件集成到一个产品中是增量模型的一个难点。-增量模型的提出很好地解决了线性模型中的人员阻塞问题，尤其是在项目开始初期开发人员不足的时候，能有效地规避技术风险。3.增量模型喷泉模型是典型的面向对象的软件过程模型之一，“喷泉”较好地体现了面向对象软件开发过程迭代和无缝的特性。4.喷泉模型4.喷泉模型（1）假设要求你开发一个软件，该软件的功能是把读入的浮点数开平方，所得到的结果应该精确到小数点后4位。一旦实现并测试完之后，该产品将被抛弃。你打算选用哪种软件生命周期模型？请说明你做出选择的理由。问题讨论——情景分析解：对这个软件的需求很明确，实现开平方功能的算法也很成熟，因此，既无须通过原型来分析需求也无须用原型来验证设计方案。此外，一旦实现并测试完之后，该产品将被抛弃，因此也无须使用有助于提高软件可维护性的增量模型或螺旋模型来开发该软件。问题讨论——情景分析（2）假设你被任命为一家软件公司的项目负责人，你的工作是管理该公司已被广泛应用的字处理软件的新版本开发。由于市场竞争激烈，公司规定了严格的完成期限并且已对外公布。你打算采用哪种软件生命周期模型？为什么？问题讨论——情景分析2.1可行性研究的任务目标：“用最小的代价和尽可能短的时间判断问题是否值得去解？”实质：高层次的系统分析和设计主要任务：（1）分析和澄清问题定义；（2）导出系统的逻辑模型；（3）探索各种解法并研究每种解法的可行性；（4）制定粗略的进度、建议和计划。2.1可行性研究的任务（1）技术可行性对要开发项目的功能、性能和限制条件进行分析，确定在现有的资源条件下，技术风险有多大，项目能否实现。–技术：相关技术的发展可否支持这个软件系统。–资源的有效性：开发人员及用于建立系统的其它资源是否具备。–开发的风险：在给出的限制范围内，能否设计出软件系统并实现必须的功能和性能。2.1可行性研究的任务（2）经济可行性经济可行性研究的内容是进行开发成本的估算以及进行效益的评估确定要开发的项目是否值得投资开发。–成本/效益分析–长期的公司经营策略–对其他的单位或产品的影响–潜在的市场前景等2.1可行性研究的任务（3）操作可行性在这个应用范围内，系统的操作方式（批处理/联机处理）是否行得通。

2.1可行性研究的任务（4）社会可行性社会可行性主要研究开发的项目是否存在任何侵犯、妨碍等责任问题，要开发项目的运行方式在用户组织内是否行得通，现有管理制度、人员素质和操作方式是否可行。–合同、责任、侵权–用户组织的管理模式及规范和其他一些技术人员常常不了解的陷阱等

第2章可行性研究

2.1可行性研究的目标与任务

2.2可行性研究过程

2.3可行性研究工具

2.4成本/效益分析2.2可行性研究过程（1）复查系统规模与目标

(1)访问关键人员，复查确认系统规模和目标

(2)清晰描述对目标系统的一切限制和约束（2）研究目前正在使用的系统

(1)了解现有系统，实地考察

(2)注意现有系统与目标系统之间的接口(功能)

(3)运行费用

Note：重在分析现有系统可以做什么，不要陷入细节！2.2可行性研究过程（3）导出新系统的高层逻辑模型

从现有的物理系统出发导出目标系统的逻辑模型（4）导出与评价各种方案

逻辑模型

——〉物理解法(1)评估解决方案的可行性(2)给出实现进度表（5）推荐行动方针

作为结果之一

是否继续开发？

对于推荐的系统

详细的成本/效益分析2.2可行性研究过程（6）草拟开发计划

工程进度表

开发人员需求

设备与软件的需求（使用情况说明）

估计软件生命周期每个阶段的成本

给出下一个阶段的进度表/成本估计（7）书写文档提交审查——《可行性研究报告》2.2可行性研究过程第2章可行性研究

2.1可行性研究的目标与任务

2.2可行性研究过程

2.3可行性研究工具

2.4成本/效益分析

系统流程图

——用来描述物理系统概貌

数据流图

——用来描述系统逻辑功能

2.3可行性研究工具

系统流程图

基本思想:用图形符号以黑盒子形式描绘组成系统的每个部件（程序、文档、数据库、人工过程）。

注：系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程(程序流程图)。2.3可行性研究工具基本符号表（概括描述系统）2.3可行性研究工具系统符号表（具体描述系统）某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果哪种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便定货，规定每天向采购部门送一次定货报告。该装配厂使用一台小型计算机处理更新库存清单主文件和产生定货报告的任务。零件库存量的每一次变化称为一个事务，由放在仓库中的CRT终端输入到计算机中；系统中的库存清单程序对事务进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的订货信息写在磁带上，并且打印出定货报告。2.3可行性研究工具注：自顶向下从左到右库存清单系统的高层系统流程图2.3可行性研究工具数据流程图

数据流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换，即数据流图描绘数据在软件中流动和被处理的逻辑过程。2.3可行性研究工具2.3可行性研究工具任何系统的基本模型都由若干个数据源点/终点以及一个处理组成，这个处理就代表了系统对数据加工变换的基本功能。1.数据流图的基本图形符号2.3可行性研究工具源点/终点：表示图中要处理数据的输入来源或处理结果要送往何处。它是数据流图的外围环境中的实体。加工/变换：使用椭圆或圆角矩形表示。它是以数据结构或数据内容作为加工对象的，是对数据进行处理的单元，是对数据流进行某些操作或变换。数据流：沿箭头方向传送数据，指明被加工的数据与流向。数据存储：和数据流一样都是数据，仅仅所处的状态不同。数据存储是处于静止状态的数据，数据流是处于运动中的数据。附加符号及含义2.3可行性研究工具2.3可行性研究工具2.数据流图元素命名原则（1）数据流（数据存储）的命名-应代表整个数据流（数据存储）的内容。-不使用空洞、缺乏具体含义的名字（如数据、信息等）。-数据流图分解得当可以有效地为数据流命名。（2）数据加工的命名-与数据流命名相关联。-应反映整个处理的功能。-及物动词+宾语。-处理分解要得当。（3）为数据源点/终点命名

数据源点/终点属于目标系统的外围环境部分。通常在命名时采用它们在问题域中习惯使用的名字。2.3可行性研究工具3.数据流图的层次结构

为了表达数据处理过程的数据加工情况，对于复杂的实际问题，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达整个系统。任何一层数据流图的上层图为父图，下一层的图为子图。2.3可行性研究工具分层的数据流图2.3可行性研究工具

在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出的数据；

底层流图是指其加工不需再做分解的数据流图，它处在最底层；

中间层流图则表示对其上层父图的细化。它的每一个加工可能继续细化，形成子图。2.3可行性研究工具4.画数据流图的基本步骤自顶向下，逐层细化

（1）先找外部实体（可以是人、物或其他软件系统），找到了外部实体，则系统与外部世界的界面就得以确定，系统的源点和终点也就确定了；

（2）找出外部实体的输入和输出数据流；

（3）在图的边上画出系统的外部实体；2.3可行性研究工具4.画数据流图的基本步骤

（4）从外部实体的输出流（源点）出发，按照系统的逻辑需要，逐步画出一系列变换数据的加工，直到找到外部实体处所需的输入流（终点），形成数据流的封闭；

（5）对初步画出的数据流图进行检查和修改。

（6）最后按照上述步骤画出所有子图。2.3可行性研究工具（1）数据流图所有图形符号只限于前述四种基本图形元素；（2）顶层数据流图中的数据流必须封闭在外部实体之间；（3）每个加工至少有一个输入数据流和一个输出数据流；（4）在数据流图中，需按层给加工框编号。编号表明该加工所处层次及上下层的亲子关系；5.检查和修改数据流图的原则2.3可行性研究工具（5）规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。这被称为是父图与子图的平衡；（6）图上每个元素都必须有名字；（7）数据流图中不可夹带控制流；（8）初画时可以忽略琐碎的细节，以集中精力于主要数据流。5.检查和修改数据流图的原则2.3可行性研究工具假设一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据：零件编号、零件名称、订货数量、价格、主要供应者、次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。源点/终点：数据流：处理：数据存储：仓库管理员、采购员处理事务、产生报表事务、定货报表库存清单、定货信息6.数据流图实例定货系统的顶级数据流图

源点终点（1）从问题描述中提取数据流图的4种成分，设计顶级数据流图。6.数据流图实例定货系统的一级数据流图（2）产生一级数据流图6.数据流图实例定货系统的二级数据流图（3）设计二级数据流图。

考虑通过系统的逻辑数据流：当发生一个事务时必须首先接收它；随后按照事务的内容修改库存清单；最后如果更新后的库存量少于库存量临界值时，则应该再次定货，也就是需要处理定货信息。6.数据流图实例2.3可行性研究工具

作为信息交流的工具；

作为分析和设计的工具。8.数据流图的用途课堂练习-1银行计算机储蓄系统的工作过程大致如下：储户填写的存款单或取款单由业务员键入系统，如果是存款则系统记录存款人姓名、住址、身份证号码等存款信息，并打印出存款存单给储户；如果是取款且存款时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并打印出利息清单给储户。要求：用数据流图描绘本系统的功能。计算机储蓄系统数据流图练习-1解析课堂练习-2某医院打算开发一套以计算机为中心的患者监护系统。该系统的基本要求是：系统随时接收每个病人的生理信号（脉搏、体温、血压、心电图等），当某个病人的生理信号超出医生规定的安全范围时向值班护士发出警告信息，定时记录病人情况以形成患者日志，此外，护士在需要时还可以要求系统印出某个指定病人的病情报告。要求：用数据流图描绘本系统的功能。(基本系统模型+功能级数据流图)练习-2解析患者监护系统的基本系统模型练习-2解析患者监护系统的功能级数据流图考虑一个修改磁带上主文件的系统。文件管理员把修改信息穿孔在卡片上，系统读入穿孔卡片上的信息并按照记录号把修改信息顺序排列好。然后系统逐个读入主文件上的记录，根据记录上的校验码核对每个读入的记录，丢掉出错的记录，按照修改信息修改余下的记录，产生的新文件存储在磁盘上。最后系统输出一份修改报告供文件管理员参阅。要求：分层次画出上述主文件修改系统的数据流图。

(基本系统模型+功能级数据流图)课堂练习-3主文件修改系统的基本系统模型练习-3解析主文件修改系统的功能级数据流图练习-3解析第2章可行性研究

2.1可行性研究的目标与任务

2.2可行性研究过程

2.3可行性研究工具

2.4成本/效益分析2.4成本/效益分析

成本/效益分析的目的是从经济角度评价开发一个新的软件工程项目是否可行。成本/效益分析首先是估算待开发软件系统的成本，然后与可能取得的效益进行比较。2.4成本/效益分析成本估计1．代码行技术代码行技术是比较简单的定量估算方法，它把开发每个软件功能的成本和实现这个功能需要用的源代码行数联系起来。软件成本=每行代码的平均成本×源代码行数

每行代码的平均成本主要取决于软件的复杂程度和工资水平；实现一个功能需要的源代码行数通常可以根据经验和历史数据估计得到。此方法对于开发有类似工程的历史数据的项目时比较有效。2.4成本/效益分析成本估计2．任务分解技术将软件开发工程分解为若干相对独立的任务。最常用的办法是按开发阶段划分任务。如果需要可以把每个子系统在按开发阶段进一步划分成更小的任务。估计每个任务成本时，通常是将估计完成该项任务需要的人力（以人月为单位）乘以每人每月的平均工资得到。软件开发成本=任务1的成本+任务2的成本+……2.4成本/效益分析成本估计3．自动估计成本技术

在有长期收集的历史数据和良好的数据库系统的支持下，可以采用自动估计成本软件工具以减轻劳动强度，得到相对客观的估计结果。2.4成本/效益分析效益分析效益包括有形效益和无形效益。有形效益可以用货币的时间价值、投资回收期、纯收入等指标进行度量。无形的效益主要是从性质上、心理上进行衡量，很难直接进行量化。常用的效益度量方法1．货币的时间价值

用利率表示货币的时间价值，设年利率为i，现已存入p元，则n年后可得到钱数为：F=P×(1+i)n

若n年后能收入F元，那么这些钱现在的价值是：P=F/(1+i)n2.4成本/效益分析例：在企业管理中使用制图系统来取代大部分人工工作，每年可节省8.6万元。若软件生存期5年，则5年可节省43万元。开发这个系统共投资18万元。设年利率是5%，利用上面计算货币现在价值的共识，可以算出引入制图系统后，每年预计节省的钱的现在价值。如下表所示。2.4成本/效益分析年将来值（万元）（1+i）n现在值（万元）累积的现在值（万元）18.61.058.19058.190528.61.10257.800415.990938.61.15767.429223.420148.61.21557.075230.495358.61.27636.738237.2335（1）确定对系统的综合要求

功能性需求：应划分出系统必须完成的所有功能。

非功能性需求：可用性：如果用户可以学会对系统的操作，能解释一个系统或构建的输入状况，则称系统是可用的。可靠性：可靠性指系统或构件在给定时间内、指定条件下，可以完成软件要求功能的能力。例如，可靠性需求包括系统出现故障前的使用时间等。3.1需求分析的任务（1）确定对系统的综合要求

性能：性能需要考虑系统的定量属性。例如,响应时间、吞吐量、有效性和准确性。

可支持性：关注系统部署后系统的变化情况。包括可移植性、可维护性等。

外部接口需求：常用的接口需求有用户接口需求，硬件接口需求，软件接口需求和通信接口需求。

约束信息：是指一些合理限制设计者和程序员选择的条件。例如，某种数据必须达到的数据精度；要求软件产品可以在某种系统上运行。3.1需求分析的任务（2）分析系统的数据要求——软件需求分析的一个重要任务

复杂数据由许多基本数据元素组成，数据结构表示数据元素之间的逻辑关系。

数据字典——定义数据；

层次方框图——

定义数据结构3.1需求分析的任务（3）建立软件的逻辑模型

对系统的综合要求对数据的要求描述方法：数据流图、数据字典、实体-联系图、和主要的处理算法。（4）编写软件需求规格说明书（5）需求分析评审：验证一致性、完整性、现实性、有效性

系统逻辑模型3.1需求分析的任务第3章需求分析

3.1需求分析的任务和步骤

3.2需求获取的常用方法

3.3需求分析的方法

3.4结构化分析技术

3.5需求分析图形工具

3.6习题1、访谈：最原始的获取用户需求的技术2、问卷调查：通常与用户访谈组合使用3、观察用户工作流程：需要对复杂流程加深了解或对关键人物理解不清楚时使用4、建立联合分析小组：由软件开发方和客户方共同组成5、快速原型法：需要多次修改3.2需求分析获取的常用方法3.2需求分析获取的常用方法1、访谈：（2）访谈对象被访谈者

话题中心

目标

高层管理人员

问题、机会

探讨系统的目标与范围

中层管理人员

业务事件

理清需求的脉络信息

操作层

业务活动

填充需求的细节

技术团队

解决方案

论证解决方案的可行性

表3.1访谈类型表3.2需求分析获取的常用方法1、访谈：（3）访谈中的沟通技巧(a)制作访谈问卷并事先发给被访谈者。(b)把握语言节奏。(c)有效结合不同的问题类型。包括有封闭式问题（判断题）、半封闭式问题（选择题）、开放式问题（简答题）。(d)注意安排问题的顺序。(e)访谈时要注意沟通的细节。注意消除“隔行如隔山”的术语影响；善于观察在访谈过程中对方的异常现象；在沟通中注意使用模型帮助理解；不要遗漏问题。3.2需求分析获取的常用方法2、问卷调查（1）问卷的特点：当片面性矛盾比较突出时就应该组织进行问卷调查。例如：企业中的从业人员数量是很大的，或存在跨地域用户。（2）使用方法：用户访谈与问卷调查应该采用组合方式使用。先调查，后访谈；先访谈，后调查。

问卷调查在设计问题时还要注意一些设计要点，如问题的篇幅与布局；问题类型的选择等。问卷调查之后还要进行问卷分析。3.2需求分析获取的常用方法3．观察用户工作流程但是这个过程耗时较长。而且由于“被观察”者微妙的心理变化，会使观察失真。所以此方法在需要对复杂流程加深了解时，对关键人物理解不清楚时使用。4．建立联合分析小组联合小组要制定小组工作计划和进度安排，确定专门的记录员和负责人。同时还要选定一种简洁、准确、易于理解的符号，作为共同交流的语言。3.2需求分析获取的常用方法5．快速原型法过程：快速建立起一个系统原型，用来演示系统功能。用户对原型进行评估，根据用户的需求来修改原型，把修改后的系统原型再次交给用户评估，如此循环多次，直到获得用户最终准确的需求。快速原型法在使用时应注意以下几点：（1）系统原型应该是实现用户看得见的功能。（2）尽量在较短的时间内构建原型。（3）原型必须容易修改。第3章需求分析

3.1需求分析的任务和步骤

3.2需求获取的常用方法

3.3需求分析的方法

3.4结构化分析技术

3.5需求分析图形工具

3.6习题3.3需求分析的方法功能分解法结构化开发方法信息建模方法面向对象的分析3.3需求分析的方法1．功能分解方法

这种方法是将一个系统看成是由若干功能构成的一个集合，每个功能又可划分为若干个子功能，每个子功能又进一步分解。

这种方法是把软件需求当做一棵倒置的功能树。体现了“自顶向下，逐步求精”的思想，用过程抽象的观点来看需求，符合传统程序设计人员的思维特征。

最后分解的结果一般已经是系统程序结构的一个雏形，实际它已经很难与软件设计明确分离。由此可见，这种方法往往难以适应用户的需求变化。3.3需求分析的方法2．结构化开发方法

结构化开发方法提出了一组提高软件结构合理性的准则，如分解与抽象、模块独立化等。它包含有结构化分析、结构化设计和结构化程序设计等方法。

结构化分析技术，是由E.Yourdon等人在20世纪70年代提出的一种适用于大型数据处理系统的、面向数据流的需求分析技术。3.3需求分析的方法3．信息建模方法

信息建模方法是从数据的角度来对现实世界建立模型的。

信息建模方法的基本工具是实体-联系图。在信息模型中，实体和关系形成一个网络，描述系统的信息状况。3.3需求分析的方法4．面向对象的分析

面向对象的分析是把实体-联系图中的概念与面向对象程序设计语言中的概念结合在一起。

面向对象分析的关键是识别、定义问题域内的类与对象，并分析它们之间的关系，根据问题域中的操作规则建立模型。第3章需求分析

3.1需求分析的任务和步骤

3.2需求获取的常用方法

3.3需求分析的方法

3.4结构化分析技术

3.5需求分析图形工具

3.6习题3.4结构化分析技术

结构化分析技术是面向数据流自顶向下逐步求精进行需求获取的方法，适合于数据处理类型系统的需求分析。思路：基于数据流图自顶向下逐层分解分析工具：数据流图、数据字典等分析过程：

沿数据流图回朔 注意细节的分析、补充

用户复查 补充、纠正、新问题的提出

细化数据流图

修正开发计划3.4结构化分析技术3.5需求分析图形工具分为：非形式化，半形式化和形式化三类。半形式化的描述工具：实体-联系图、数据流图、数据字典、描述加工逻辑的结构化语言、判定表和判定树等。实体-联系图也称为ER图，是一种面向问题的数据模型，是按照用户观点对数据建立的模型。数据模型中包含3种互相关联的信息：实体、属性

和

联系。3.5.1实体-联系图实体对软件必须理解的复合信息的抽象

复合信息是具有一系列不同性质或属性的事物,仅有单个值的事物不是数据对象。

数据对象可以是外部实体、事物、行为、时间、角色、单位、地点或结构等。3.5.1实体-联系图

属性数据对象的性质

把属性定义为“标识符”。在查找数据对象实例时，用标识符属性作为“关键字”。实体的属性有很多，应尽量找与开发系统相关的一些性质。实体和联系都有属性，两者可以转换为相应的数据库表，而属性则是表里的字段。3.5.1实体-联系图

联系数据对象彼此之间相互连接的方式

一对一联系（1：1）一对多联系（1：N）多对多联系（M：N）3.5.1实体-联系图如何区分实体和属性实体与属性是相对而言的。同一事物，在一种应用环境中作为“属性”，在另一种应用环境中也可以作为“实体”。例：学校中的系，在某种应用环境中，它只是作为“学生”实体的一个属性，表明一个学生属于哪个系；而在另一种环境中，由于需要考虑一个系的系主任、教师人数、学生人数、办公地点等，这时它就需要作为实体了。3.5.1实体-联系图如何区分实体和属性

一般原则：属性不能再具有需要描述的性质。即属性必须是不可分的数据项，不能再由另一些属性组成。属性不能与其他实体具有联系。联系只发生在实体之间。符合上述两条特性的事物一般作为属性对待。为了简化E-R图的处置，现实世界中的事物凡能够作为属性对待的，应尽量作为属性。3.5.1实体-联系图例1：“学生”由学号、姓名等属性进一步描述，根据准则１，“学生”只能作为实体，不能作为属性。例2：职称通常作为教师实体的属性，但在涉及住房分配时，由于分房与职称有关，也就是说职称与住房实体之间有联系，根据准则２，这时把职称作为实体来处理会更合适些。3.5.1实体-联系图

符号E-R图(Entity-RelationshipDiagram)

实体：矩形框

关系：菱形框

属性：椭圆形或圆角矩形3.5.1实体-联系图实体-联系图的元素符号实体联系属性3.5.1实体-联系图例如：某品牌的计算机是由多种部件组成的，而部件通过各地供货商供应，假定每种部件的供货商是唯一的，但一个供货商可以供应多种零件。3.5.1实体-联系图课堂练习-1：请为某仓库的管理设计一个ER模型。该仓库主要管理零件的订购和供应商等事项。仓库向工程项目供应零件，并且根据需要向供应商订购零件。3.5.1实体-联系图工程项目供应商零件供应订购MMNN零件名称零件编号颜色重量供应量订购量项目编号开工日期项目名称供应商编号地址供应商名称课堂练习-2：

银行计算机储蓄系统的工作过程大致如下：储户填写的存款单或取款单由业务员键入系统，如果是存款则系统记录存款人姓名、住址、身份证号码等存款信息，并打印出存款存单给储户；如果是取款且存款时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并打印出利息清单给储户。要求：用ER图描绘系统中的数据对象。3.5.1实体-联系图储户储蓄所存取款MN类型数额利率密码姓名身份证号码住址名称地址电话号码电话号码到期日期计算机储蓄系统的实体-联系图学生每学期按照事先安排的课程计划开始学习。每门课程由多名教师讲授,一个教师可以讲授多门课程；每名学生可以选修多门课程；学期结束后通过考试，教师登记每门课程、每名学生的成绩，并得到确认后存档；要求可以按照教师、学生、课程查询和统计成绩，了解课程授课的质量；能给出统计分析报表，供院主管部门参考。举例：3.5.1实体-联系图教师课程编号姓名性别职称系别自然情况编号名称学时学期性质讲授nm3.5.1实体-联系图学生课程编号姓名性别班级学生证号自然情况编号名称学时学期性质选修nm成绩3.5.1实体-联系图教师课程编号姓名性别职称系别自然情况编号名称学时学期性质讲授nm学生编号姓名性别班级学生证号自然情况选修nm成绩3.5.1实体-联系图

数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。任何字典最主要的用途都是供人查阅对不了解的条目的解释，数据字典的作用也正是在软件分析和设计的过程中给人提供关于数据的描述信息。3.5.2数据字典

数据流图和数据字典共同构成系统的逻辑模型，没有数据字典数据流图就不严格，然而没有数据流图数据字典也难于发挥作用。只有数据流图和对数据流图中每个元素的精确定义放在一起，才能共同构成系统的规格说明。3.5.2数据字典基本功能：定义数据。数据字典由对以下四类元素的定义组成：数据流；数据流分量（即数据元素）；数据存储；处理。

注：通常用IPO图或PDL图描述3.5.2数据字典数据流图中每一个被命名的图形元素包含：名

字：数据流图中表示数据流、数据源或外部实体的名字与别名。（保持命名唯一性）别

名:数据描述：关于该数据条目的简要功能描述。数据定义：该数据条目的解释性说明，可以使用自顶向下的方法进行定义。数据位置：使用该数据条目作为输入流或输出流的转换的列表。（修改时保持数据元素的一致性）3.5.2数据字典数据定义的方法：对于复杂的数据，一般可以采用自顶向下的方法进行分解。复杂数据中的数据元素的组成方式：顺序：表示个分量连续地按次序排列。通常用加号表示连续关系。选择：表示从列表中的多个元素中选取一个。重复：表示某个元素重复零次或多次。可选：表示一个分量是可有可无的（即重复零次或一次）。3.5.2数据字典可以使用的符号：（1）=表示“被定义为”或“等价于”或“由……组成”。

（2）＋表示“与”（和），用来连接两个数据元素。例如，职工号=科室号+序列号。（3）[…|…]表示“或”，对[]中列举的数据元素可任选其中某一项。例如：性别=[男|女]表示性别由男或女组成。3.5.2数据字典（4）{…}表示“重复”，对{…}中内容可以重复使用。通常使用m{…|…}n或者

表示{…}mn中内容至少出现m次，最多出现n次。其中m和n为重复次数的上、下限。例如，字符串=2{字母或数字字符}6表示“字符串”由2—6位字母或数字字符符号组成。（5）（…）表示“可选”，对（…）中的内容可选、可不选；例如，学生基本信息=学号+性别+（家庭住址）。（6）“...”表示基本数据元素。例如，x=“a”。（7）..表示连结符。例如，x=1..9。3.5.2数据字典数据字典的实现：小型软件系统中一般采用卡片的形式描述。一张卡片上记录某数据元素中包含名字、别名、描述、定义和位置。3.5.2数据字典假设一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件，对于每个需要再次定货的零件应该列出下述数据：零件编号，零件名称，定货数量,目前价格，主要供应者，次要供应者。零件的入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。请用数据流图描绘该功能的需求并建立相应的数据字典。3.5.2数据字典名字：定货报表别名：定货信息描述：每天一次送给采购员的需要定货的零件表定义：定货报表=零件编号+零件名称+定货数量+目前价格+主要供应者+次要供应者位置：定货信息名字：零件编号别名：描述：唯一地标识库存清单中一个特定零件的关键域定义：零件编号=8{字符}8位置：定货报表定货信息库存清单事务名字：定货数量别名：描述：某个零件一次定货的数量定义：定货数量=1{数字}5位置：定货报表定货信息

3.5.2数据字典定货报表在DD中的定义：名字：定货报表别名：定货信息描述：每天一次送给采购员的需要定货的零件表定义：定货报表=零件编号+零件名称+定货数量+目前价格+主要供应者+次要供应者位置：定货信息定货报表在数据字典中的表示：3.5.2数据字典名字：零件编号别名：描述：唯一地标识库存清单中一个特定零件的关键域定义：零件编号=8{字符}8位置：定货报表

定货信息

库存清单

事务3.5.2数据字典名字：定货数量别名：描述：某个零件一次定货的数量定义：定货数量=1{数字}5位置：定货报表

定货信息3.5.2数据字典练习-1：某程序设计语言规定，用户说明的标识符是长度不超过8个字符的字符串，其中第一个字符必须是字母字符，随后的字符既可以是字母字符也可以是数字字符。则对标识符的定义可表示为：标识符=字母字符+字母数字串字母数字串=0{字母或数字}7字母或数字=[字母字符|数字字符]3.5.2数据字典习题11电话号码=[分机号码|外线号码]分机号码=8201..8299外线号码=数字零+[市话号码|长话号码]数字零=0市话号码=局号+分局号局号=[455|325|999]分局号=4位数字串4位数字串=4{数字}4数字=0..9长话号码=区号+市话号码区号=000..300练习-2：北京某高校可用的电话号码有以下几类：校内电话号码由4位数字组成，第1位数字不是0；校外电话又分为本市电话和外地电话两类，拨校外电话需先拨0，若是本市电话则再接着拨8位数字(第1位不是0)，若是外地电话则拨3位区码再拨8位电话号码(第1位不是0)。3.5.2数据字典电话号码=[校内电话号码|校外电话号码]校内电话号码=非零数字+3位数字校外电话号码=[本地号码|外地号码]本地号码=数字零+8位数字外地号码=数字零+3位数字+8位数字非零数字=[1|2|3|4|5|6|7|8|9]数字零=03位数字=3{数字}38位数字=非零数字+7位数字7位数字=7{数字}7数字=[0|1|2|3|4|5|6|7|8|9]电话号码在数据字典中的定义：层次方框图：用树型结构的一系列多层次的矩形框描绘数据的层次结构。顶层是一个单独的矩形框，代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素（不能再分割的元素）。3.5.3层次方框图例如，描绘一所大学各个机关部门和学院的组成可以用如图3.3中的层次方框图表示。这所大学由党委办公室、校长办公室及各个学院组成，计算机学院又分为软件工程系、计算机科学系等。3.5.3层次方框图例如，描绘一家计算机公司全部产品由硬件、软件和服务三类产品组成。硬件包括处理机、存储器和外部设备等。软件产品又分为系统软件和应用软件，系统软件又进一步分为操作系统、编译程序和软件工具等。而服务类产品包括软件服务、硬件维修和培训等。试用层次方框图表示该公司全部产品的数据结构。3.5.3层次方框图IPO图：简称是IPO（InputProcessOutput）图。它能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。

左边的框中列出有关的输入数据，中间的框内列出主要的处理，右边的框内列出产生的输出数据。处理框中列出处理的次序暗示了执行的顺序。3.5.4IPO图

总体设计：应用各种技术和原理，对设备、过程或系统做出足够详细的定义，使之能够在物理上得以实现。

过程：将“做什么”的逻辑模型转变为“怎么做”的物理模型，即将前期工程中的软件需求转换为软件表示的过程。4.1总体设计的目标及任务

总体设计的基本目的：

解决“系统应该如何实现”的问题总体设计的两个阶段：

系统设计阶段：确定系统的具体实现方案

结构设计阶段：确定系统的软件结构4.1总体设计的目标及任务1、设计软件结构（1）通过需求分析阶段得到的数据流图设想各种可能方案。将一个复杂的系统按功能划分为若干模块；（2）确定每个模块的功能；（3）确定模块之间的调用关系；（4）确定模块之间的接口，即模块之间传递的消息；（5）评价模块结构的质量。4.1总体设计的目标及任务2．数据结构及数据库设计

数据结构的设计采用逐步细化的方法。在需求分析阶段可通过数据字典对数据的组成、操作约束和数据之间的关系等方面进行描述，确定数据的结构特性。在总体设计阶段要加以细化，详细设计阶段则规定具体的实现细节。4.1总体设计的目标及任务3．确定测试要求并制定测试计划

软件开发早期阶段考虑测试问题，能促使软件设计人员在设计时注意提高软件的可测试性。4、编写总体设计文档《概要设计说明书》4.1总体设计的目标及任务5、评审

对设计部分是否完整地实现需求中规定的功能、性能等要求，设计方案的可行性、关键的处理及内外部接口定义正确性、有效性，及各部分之间的一致性等进行评审。4.1总体设计的目标及任务第4章总体设计

4.1总体设计的目标及任务

4.2软件结构设计原理

4.3软件结构设计工具

4.4软件结构设计启发式规则

4.5结构化设计方法4.2软件结构设计原理软件结构设计（结构化方法）：①在系统设计中分析信息流程，绘制数据流程图；②根据数据的规范，编制数据字典；③根据概念结构的设计，确定数据文件的逻辑结构；④选择系统执行的结构化语言，以及采用控制结构作为软件的设计工具。4.2软件结构设计原理4.2.1模块化“由大化小，各个击破”优点：

提高可靠性、可修改性

错误一般出现在模块或接口中4.2软件结构设计原理4.2.1模块化模块:

数据说明、可执行语句等程序对象的集合，或者是单独命名和编址的元素（如函数、子程序）等。模块化:

解决一个复杂问题时自顶向下逐层把软件系统划分成若干模块的过程。每个模块完成一个特定的子功能，所有的模块按某种方法组装起来，成为一个整体，完成整个系统所要求的功能。4.2软件结构设计原理4.2.1模块化模块的基本属性：接口：模块的输入与输出。

功能：模块实现什么功能。

逻辑：描述内部如何实现要求的功能及所需的数据。

状态：指该模块的运行环境，是模块的调用与被调用的关系。功能、状态、接口反映模块的外部特性，逻辑反映它的内部特性。4.2软件结构设计原理4.2.2抽象抽出事物本质特性而不考虑细节软件设计：从抽象概括到具体实现的过程具体

抽象

具体（系统功能）（建模）（程序代码）问题定义阶段：（具体）用户给出对目标系统的实际需求。

系统定义阶段：（抽象）软件可作为整个计算机系统的一个元素来看待。软件需求分析阶段：（抽象）软件的解决方案是使用问题环境中的术语来描述。总体设计—详细设计阶段：（抽象—具体）将面向问题的术语与面向实现的术语结合起来来描述解决方法，直到产生源程序时到达最低抽象层次。4.2软件结构设计原理4.2软件结构设计原理4.2.2逐步求精为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。Miller法则：一个人在任何时候都只能把注意力集中在(7±2)个知识块上。4.2软件结构设计原理4.2.3信息隐藏和局部化信息隐藏原理：设计和确定模块时，使得一个模块内包含的信息对于不需要这些信息的模块来说，是不能访问的。局部化：把一些关系密切的软件元素物理地放得彼此靠近。优点：防止错误的扩大与传播。4.2软件结构设计原理4.2.4模块独立性模块独立是模块化、抽象、信息隐藏和局部化概念的直接结果。

模块独立：每个模块完成一个相对独立的特定子功能，并且和其他模块之间的关系很简单。4.2软件结构设计原理4.2.4模块独立性良好的模块独立性的重要性：能使开发的软件具有较高的质量。

设计的模块可理解性、可维护性及可测试性好，必然导致软件的可靠性高。

接口简单、功能独立的模块易开发，且可并行工作，有效地提高了软件的生产率。4.2软件结构设计原理4.2.4模块独立性

耦合：软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间总是相互关联的，很少是相互独立的，完全独立的模块是无法构成系统的。

模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。4.2软件结构设计原理4.2.4模块独立性

耦合类型无直接耦合—数据耦合—控制耦合—特征耦合—公共耦合—内容耦合

低——————————————————————高4.2软件结构设计原理4.2.4模块独立性

无直接耦合：指两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，它们之间不传递任何信息。

数据耦合：指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递。这种耦合程度较低，模块的独立性较高。

控制耦合：指一个模块调用另一个模块时，传递的是控制变量(如开关、标志等)，被调模块通过该控制变量的值有选择地执行块内某一功能。4.2软件结构设计原理4.2.4模块独立性

特征耦合：当模块之间传递的是某些数据结构，但是目标模块只是使用了数据结构中的部分内容时，这种耦合方式称为特征耦合。

公共耦合：指通过一个公共数据环境相互作用的那些模块间的耦合。公共数据环境可以是全程变量或数据结构、共享的通信区、内存的公共覆盖区及存储介质上的文件和物理设备等。

内容耦合：当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部时，这种模块之间的耦合便为内容耦合。4.2软件结构设计原理4.2.4模块独立性设计原则：

尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合。4.2软件结构设计原理4.2.4模块独立性

内聚：一个模块内部各个元素彼此结合的紧密程度的度量。

偶然内聚—逻辑内聚—时间内聚—过程内聚—通信内聚—顺序内聚—功能内聚

低内聚————————中内聚

——————高内聚4.2软件结构设计原理4.2.4模块独立性偶然内聚：指一个模块内的各处理元素之间没有任何联系。

逻辑内聚：指模块内执行几个逻辑上相似的功能，通过参数确定该模块完成哪一个功能。

时间内聚：把需要同时执行的动作组合在一起形成的模块为时间内聚模块。时间内聚模块中的各部分都要在同一时间内完成。过程内聚：如果一个模块内部的处理是相关的，而且这些处理必须以特定的次序执行，则称过程内聚。

4.2软件结构设计原理4.2.4模块独立性通信内聚：指模块内所有处理元素都在同一个数据结构上操作，或指各处理使用相同的输入数据或者产生相同的输出数据。

顺序内聚：指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素的输出就是下一功能元素的输入。

功能内聚：最强的内聚形式，指模块内所有元素共同完成一个功能，缺一不可。模块不能再分割。4.2软件结构设计原理4.2.4模块独立性设计原则：

力争做到高内聚，并且能辨认出低内聚的模块，通过修改设计提高模块的内聚程度并降低模块间的耦合程度。【注】耦合性与内聚性是模块独立性的两个定性标准，将软件系统划分成模块时，尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。但也有内聚性与耦合性发生矛盾的时候，为了提高内聚性而可能使耦合性变差。在这种情况下，建议给予内聚性以更高的重视。第4章总体设计

4.1总体设计的目标及任务

4.2软件结构设计原理

4.3软件结构设计工具

4.4软件结构设计启发式规则

4.5结构化设计方法4.4软件结构设计启发式规则1．模块独立性准则：通过模块分解或合并，力求做到降低耦合提高内聚，保持模块相对独立性。（1）如图4.13(a)所示，若多个模块公有的一个子功能（使用阴影部分表示），则可以将这个子功能独立成一个模块，由这些模块调用。4.4软件结构设计启发式规则（2）若有多个功能相关的模块，如图4.13(b)所示B、C、D三个模块耦合度较高，E、F两个模块耦合度较高，应考虑对它们进行合并以减少控制信息的传递，降低接口的复杂程度。4.4软件结构设计启发式规则2．模块的作用域应该在控制域内

作用域：指受该模块内一个判断影响的所有模块的集合。控制域：指模块本身以及其所有直接或者间接从属于它的模块集合。4.4软件结构设计启发式规则(a)(b)(c)图4.14模块的作用域和控制域(a)差的结构图(b)不理想的结构图(c)理想的结构图4.4软件结构设计启发式规则改进方法：（1）上移判断点。如图4.14(a)所示，将模块D中的判断点上移到它的上层模块B中，或者将整个模块D合并到模块B中，使该判断的层次升高，以扩大它的控制域。

（2）下移受判断影响的模块。将受判断影响的模块下移到判断所在模块的控制域内，如图4.14(a)所示，将模块C下移到模块D的下层。（1）深度指软件结构中模块的层次数，它表示控制的层数，一定意义上能粗略地反映系统的规模和复杂程度。

（2）宽度指同一层次中最大的模块个数，它表示控制的总分布。

（3）扇出指一个模块直接调用的模块数目。经验证明，良好的系统结构平均扇出数一般是3-4，不能超过5-9。

（4）扇入指有多少个上级模块直接调用它。

4.4软件结构设计启发式规则3．软件结构的形态特征准则（1）深度能粗略地反映系统的规模和复杂程度，宽度也能反映系统的复杂情况。宽度与模块扇出有关，若一个模块的扇出太多，说明本模块过分复杂，缺少中间层。（2）单一功能模块的扇入数大比较好，说明本模块为上层几个模块共享的公用模块，重用率高。（3）不能把彼此无关的功能凑在一起形成一个通用的超级模块，虽然它扇入高，但内聚低。因此非单一功能的模块扇入高时应考虑重新分解，以消除控制耦合的情况。4.4软件结构设计启发式规则4.3软件结构设计工具如图所示，结构图的深度为5；宽度为8；模块M的扇出为3；模块T的扇入为4。4.4软件结构设计启发式规则4．模块大小准则

在考虑模块的独立性时，为了增加可理解性，模块的大小最好在50-150条语句左右，可以用1-2页纸打印，便于人们阅读与研究。5．模块的接口准则（1）模块接口设计要简单，以降低复杂程度和冗余度。（2）设计功能可预测并能得到验证的模块。（3）适当划分模块规模，以保持其独立性。第4章总体设计

4.1总体设计的目标及任务

4.2软件结构设计原理

4.3软件结构设计工具

4.4软件结构设计启发式规则

4.5结构化设计方法4.3.1层次图4.3软件结构设计工具左图中，矩形框：模块连线：调用关系层次图：适于在自顶向下设计软件的过程中使用。4.3.2HIPO图=H图+每个模块的IPO图（H图：带编号的层次图）4.3软件结构设计工具Note:

和H图中每个方框相对应，应都有一张IPO图来描绘其代表的模块处理过程。4.3软件结构设计工具4.3.3软件结构图主要内容：模块——方框表示

模块的调用关系——单向箭头或直线模块间的信息传递——带注释的短箭头选择调用——菱形循环调用——弧形箭头4.3软件结构设计工具4.3软件结构设