软件工程重点

整理者：南京农业大学戚爱静

第一章 概论

一． 计算机软件

定义：计算机系统中的程序及其文档。

程序：计算任务的处理对象和处理规则的描述。

处理对象：数据或信息。处理规则：一般指处理的动作和步骤。

文档：为了便于了解程序所需的阐述性资料。

发展：1946-1956年：从计算机问世到实用的高级程序语言出现前；

1956-1968年：从实用的高级程序语言出现到软件工程出现前（出现软件危机）；

1968年-至今：从软件工程出现到现在。

软件危机：许多软件项目不能满足客户的要求；许多软件项目超出预算和时间安排。 表现：1）对软件开发成本和进度的估计常常很不正确；

2）用户对“已完成的”软件系统不满意的现象经常发生；

3）软件产品的质量往往靠不住；

4）软件常常是不可维护的；

5）软件通常没有适当的文档资料；

6）软件成本在计算机系统总成本中所占的比例逐年上升；

7）软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势。

原因：1）软件是逻辑产品，开发进度、成本难以估计；

2）缺乏或不完整、不一致的文档给维护带来困难；

3）用户对软件需求的描述往往不够精确，有遗漏，有二义；

4）软件开发人员对需求的理解与用户的本来愿望有差异；

5）大型软件项目需多人协同完成，缺乏管理经验；

6）开发人员不能有效地、独立自主地处理大型软件的全部关系；

7）缺乏有力的方法学和工具的支持；

8）软件项目的特殊性和人类智力的局限性。

克服：1）消除错误的概念和做法；

2）推广使用成功的开发技术和方法；

3）使用软件工具和软件工程支持环境；

4）加强软件管理。

软件的特点（与硬件相比）：

1） 软件是一种逻辑实体，而不是有形的系统元件，其开发成本和进度难以准确地估算。

2） 软件是被开发的或被设计的，没有明显的制造过程，一旦开发成功，只需复制即可，但其

维护的工作量大。

3） 软件的使用没有硬件那样的机械磨损和老化问题。

故障曲线：

软件的分类：

1） 系统软件：位于计算机系统中最靠近硬件的一层，其它软件一般都通过系统软件发挥作

用，它与具体的应用领域无关（如操作系统、编译程序等）。

2） 支撑软件：支持软件开发和维护的软件（如数据库管理系统、网络软件、软件开发环境）。

3） 应用软件：特定应用领域专用的软件（如实时软件、嵌入式软件、科学和工程计算软件、

事务处理软件、人工智能软件等）。

软件语言：书写计算机软件的语言。

1） 需求定义语言：书写软件需求定义（功能需求和非功能需求），做什么（如PSL 、PSA ）。

2） 功能性语言：书写软件功能规约语言。外部功能做什么（如广谱语言、Z 语言）。

（软件功能规约是软件所要完成功能的精确而完整的陈述。）

3） 设计性语言：书写软件设计规约。如何做（如PDL ）。

（设计规约是软件设计的严格而完整的陈述，是功能规约的算法性细化。）

4） 实现性语言：用于书写计算机程序的语言，也称编程语言或程序设计语言。

分类：按语言级别可分为低级语言和高级语言；

按用户要求可分为过程式语言和非过程式语言；

按应用范围可分为通用语言和专用语言；

按使用方式可分为交互式语言和非交互式语言；

按成分性质可分为顺序语言、并发语言、分布语言。

5） 文档语言：用于书写软件文档的语言。

二、软件工程

定义：软件工程是应用计算机科学、数学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本为目的。

软件工程框架：

1） 目标：生产具有正确性、可用性以及开销合宜的产品。

2） 过程：指生产一个最终满足需求且达到工程目标的软件产品所需要的步骤。

3） 原则：选取适宜的开发模型；采用合适的设计方法；提供高质量的工程支持；

重视软件工程的管理。

软件生存周期（6个阶段）：

1） 计算机系统工程：确定待开发软件的总体要求和范围，以及它与其它计算机系统元素之间

的关系；进行成本估算，做出进度安排；进行可行性分析。

2） 软件需求分析：做什么。确定软件的功能、数据、界面等要求，生成软件需求规约。

3） 软件设计：怎么做。系统设计：设计软件系统的体系结构；详细设计：设计各个组成成分

的实现细节。

4） 编码：用某种程序设计语言，将设计的结果转换为可执行的程序代码。

5） 测试：发现并纠正软件中的错误和缺陷（包括单元测试、集成测试、确认测试和系统测试）。

6） 运行和维护：当发现了软件中潜藏的错误或需要增加新的功能或使软件适应外界环境的变

化等情况出现时对软件进行修改。

三、软件过程模型

定义：软件开发全部过程、活动和任务的结构框架。

瀑布模型：给出了软件生存周期活动的固定顺序，上一阶段的活动完成后向下一阶段的活动过渡，最终得到所开发的软件产品。

特征：1）接受上一阶段的结果作为本阶段的输入；

2）利用这一输入实施本阶段应完成的活动；

3）对本阶段的工作进行评审；

4）将本阶段的结果作为输出，传递给下一阶段。

缺点：1）缺乏灵活性，难以适应需求不明确或需求多变的软件开发；

2）问题往往要到交付使用时才发现，维护代价大。

演化模型：在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本， 称之谓原型，然后该用户在试用原型的过程中提出的意见和建议、或者增加新的需求，对原 型进行改造，获得原型的新版本，重复这一过程，最终得到令客户满意的软件产品。 （适用于对软件需求缺乏准确认识的情况。）

1、 增量模型：将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生 软件的一个可发布的“增量”版本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品，（强调每一个增量都发布一个可运行的产品）。

适用于：1）需求经常变化的软件开发；2）市场急需而开发人员和资金不能在设定的市场期限

之前实现一个完善的产品的软件开发。

（能有计划的管理技术风险。）

2、 原型模型：从软件工程师与客户的交流开始，其目的是定义软件的总体目标，标识需求。 然后快速制订原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其建模，并构建原型交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。 根据使用原型的目的不同，原型可分为：

1） 探索型：目的是要弄清目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。

2） 实验型：目的是验证方案或算法的合理性，在大规模开发和实现前，用于考核方案是否合

适，规格说明是否可靠。

3） 演化型：目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化

成最终的目标系统。

原型使用策略：

1） 废弃策略：主要用于探索型和实验型原型的开发。

2） 追加策略：主要用于演化型原型的开发。

3、 螺旋模型：是瀑布模型和演化模型的结合，并增加了风险分析。

四个象限活动：制定计划；风险分析；工程实施；客户评估。

喷泉模型：一种支持面向对象开发的模型（体现迭代和无间隙特征）。

（迭代：开发活动需要多次重复。无间隙：开发活动之间不存在明显的边界。）

四、CASE 工具与环境

计算机辅助软件工程（CASE ）：在软件工程活动中，软件工程师和管理人员按照软件工程的方法和原则，借助于计算机及其软件工具的帮助，开发、维护、管理软件产品的过程。

软件工具：用来辅助计算机软件的开发、运行、维护、管理、支持过程中的活动或任务的软件。

集成型开发环境：一种把支持多种软件开发方法和过程模型的软件工具集成到一起的软件开发环境（由工具集和环境集成机制组成）。

环境集成机制：

1） 数据集成：为各种相互协作的工具提供统一的数据接口规范。

2） 界面集成：持工具界面的集成和应用系统的界面开发，统一界面风格。

3） 控制集成：支持各个工具或开发活动之间的通信、切换、调度和协同工作，并支持软件开

发过程的描述、执行与转接。

4） 方法与过程集成

5） 平台集成

第二章 系统工程

一、 基于计算机的系统

定义：通过处理信息来完成某些预定义目标而组织在一起的元素的集合。

组成元素：软件、硬件、人员、数据库、文档和规程

二、 系统工程的任务

1、 识别用户的需求：标识系统的功能和性能范围，确定系统的功能、性能、约束和接口。

2、 系统建模和模拟：硬件系统模型、软件系统模型、人机接口模型、数据模型。

3、 成本估算及进度安排

4、 可行性分析：从经济、技术、法律等方面分析所给出的解决方案是否可行。

5、 生成系统规格说明

三、 可行性分析

定义：主要从经济、技术、法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成。

1、 经济可行性：

1） 成本：购置硬件、软件和设备费用；系统的开发费用；系统安装、运行和维护费用；人

员培训费用。

2） 效益：经济效益包括使用基于计算机的系统后可增加的收入和可节省的运行费用（经济

效益通常可用货币的时间价值、投资回收期和纯收入来度量）；社会效益指使用基于计算机的系统后对社会产生的影响。

2、 技术可行性：主要根据系统的功能、性能、约束条件等，分析在现有资源和技术条件下系

统能否实现

1） 风险分析：分析在给定的约束条件下设计和实现系统的风险（不成熟的技术、人员流

动、成本和人员估算不合理）。

2） 资源分析：论证是否具备系统开发所需的各类人员、软件、硬件等资源和相应的工作

环境

3） 技术分析：分析当前的科学技术是否支持系统开发的各项活动。

3、 法律可行性：研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触

的问题

4、 方案的选择和折中

第三章 需求工程

一、 需求工程概述

软件需求：用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。

任务：准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。

细分阶段：需求获取；需求分析与协商；系统建模；需求规约；需求验证；需求管理。

二、 需求获取

软件需求种类：功能需求；性能需求；用户或人的因素；环境需求；界面需求；文档需求；数据需求；资源使用需求；安全保密要求；可靠性需求；软件成本消耗与开发进度需求；其他非功能性要求。

需求获取的方法与策略：

1、 建立顺畅的通信途径

2、 访谈与调查

3、 观察用户操作流程

4、 组成联合小组：打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发

挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调。

5、 用况、用例（Use Case）：分析员创建一组标识一串待建造系统的使用场景。用况提供了系

统如何被使用的描述。

创建用况模型的主要步骤如下：

1）确定谁会直接使用该系统，即执行者（Actor ）；

2）选取其中一个执行者；

3）定义该执行者希望系统做什么，执行者希望系统做的每件事将成为一个用况；

4）对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程；

5）描述该用况的基本过程。

三、 需求分析、协商与建模

需求分析原则：

1） 必须能够表示和理解问题的信息域；

2） 必须能够定义软件将完成的功能；

3） 必须能够表示软件的行为(作为外部事件的结果；

4） 必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节；

5） 分析过程应该从要素信息移向细节信息。

模型：对对象系统的形式化的特征抽象，概括性或近似地表示。

需求分析过程：

1） 通过对现实环境的调查，获得当前系统的物理模型；

2） 去掉具体模型中的非本质因素，抽象出当前系统的逻辑模型；

3） 分析当前系统与目标系统的差别，建立目标系统的逻辑模型。

常用的分析方法：面向数据流的结构化分析方法 (SA)；面向对象的分析方法 (OOA)。

四、 需求规约与验证

需求验证目的：是要检验需求是否能够反映用户的意愿。

第四章 设计工程

一、 软件设计工程概述

软件设计：软件设计是把软件需求变换成软件表示的过程。

任务：把软件分析模型中通过数据、功能和行为模型所展示的软件需求的信息被传送给设计阶段，产生数据/类设计、体系结构设计、接口设计、部件级设计。

1. 数据/类设计：将分析-类模型变换成类的实现和软件实现所需要的数据结构（数据对象和

关系以及数据字典中描述的详细数据内容提供数据设计活动的基础）。

过程：

1) 为在需求分析阶段所确定的数据对象选择逻辑表示，需要对不同结构进行算法分析，

以便选择一个最有效的设计方案；

2) 确定对逻辑数据结构所必需的那些操作的程序模块，以便限制或确定各个数据设计决

策的影响范围。

2. 体系结构设计：体系结构设计定义了软件的整体结构，由软件部件、外部可见的属性和它

们之间的关系组成。

3. 接口设计：接口设计描述了软件内部、软件和协作系统之间以及软件同人之间如何通信。

三方面：

1） 软件模块间的接口；

2） 模块和其它非人的信息生产者和消费者(比如外部实体) 之间的接口；

3） 人(用户) 和计算机间的接口

4. 部件级设计：部件级设计将软件体系结构的结构性元素变换为对软件部件的过程性描述（以

类为基础的对象模型、流模型、行为模型中得到的信息是部件设计的基础）。

软件设计过程的目标（McGlanghlin ）：

1) 须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。

2) 必须是可读、可理解的，使得将来易于编程、易于测试、易于维护。

3) 从实现角度出发，给出与数据、功能、行为相关的软件全貌。

衡量设计的技术标准：

1) 设计出来的结构应是分层结构，从而建立软件成份之间的控制。

2) 设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的部件。

3) 设计应当既包含数据抽象，也包含过程抽象。

4) 设计应当建立具有独立功能特征的模块。

5) 设计应当建立能够降低模块与外部环境之间复杂连接的接口。

6) 设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。

软件设计的过程：

1) 制定规范

2) 体系结构和接口设计

3) 数据/类设计

4) 部件级（过程）设计

5) 编写设计文档

6) 设计评审

二、 软件设计原则

1、 抽象与逐步求精：

1) 抽象：是在软件设计的规模逐渐增大的情况下，控制复杂性的基本策略。

抽象手段：

a) 过程抽象：任何一个完成明确定义功能的操作都可被使用者当作单个实体看待，

尽管这个操作实际上是由一系列更低级的操作来完成的。

b) 数据抽象：指定义数据类型和施加于该类型对象的操作，并限定了对象的取值范

围，只能通过这些操作修改和观察数据。

2) 逐步求精：把问题的求解过程分解成若干步骤或阶段，每步都比上步更精化，更接近问

题的解法

2、 模块化：把软件按照规定原则，划分为较小且相互独立的但又相互关联的部件，实际上是

系统分解和抽象的过程（模块化是好的软件设计的一个基本准则）。

（模块：数据说明、可执行语句等程序对象的集合，它是单独命名的，并且可以通过名字来访问）

3、 信息隐藏：可定义和实施对模块的过程细节和局部数据结构的访问限制

4、 功能独立：功能独立是模块化、抽象、信息隐藏和局部化等概念的直接结果。开发功能专

一的且避免与其他模块过多交互的的模块可以实现功能独立。

功能独立的重要性：

1) 功能被分隔且接口被简化使得软件更容易开发。

2) 由于因修改设计或修改编码引起的副作用被限制，减少了错误扩散，且模块复用成为

可能，因而使得软件更易于维护和测试。

功能独立性的两项衡量指标：

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

a) 巧合内聚（偶然内聚）：几个模块中没有明确表现出独立功能的相同程序代码段独立出

来建立的模块。

b) 逻辑内聚：指完成一组逻辑相关任务的模块，调用该模块时，由传送给模块的控制型

参数来确定该模块应执行哪一种功能。

c) 时间内聚：指一个模块中的所有任务必须在同一时间段内执行。例如初始化模块和终

止模块。

d) 过程内聚：指一个模块完成多个任务，这些任务必须按指定的过程（procedural ）执行。 e) 通信内聚：指一个模块内所有处理元素都集中在某个数据结构的一块区域中。

f) 顺序内聚：指一个模块完成多个功能，这些功能又必须顺序执行。

g) 功能内聚：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，

不可分割的。

2) 耦合度:度量模块之间的相对独立性（互相连接的紧密程度）。

a) 内容耦合：如果一个模块直接访问另一个模块的内部数据；或者一个模块不通过正常

入口转到另一模块内部；或者两个模块有一部分程序代码重迭；或者一个模块有多个入口，则两个模块之间就发生了内容耦合。

b) 公共耦合：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦

合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。

c) 外部耦合：指模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格

式、通信协议上）时，称为外部耦合。

d) 控制耦合：如果一个模块传送给另一个模块的参数中包含了控制信息，该控制信息用

于控制接收模块中的执行逻辑，则称为控制耦合。

e) 标记耦合：两个模块之间通过参数表传递一个数据结构的一部分（如某一数据结构的

子结构），就是标记耦合。

f) 数据耦合：两个模块之间仅通过参数表传递简单数据，则称为数据耦合。

g) 非直接耦合：如果两个模块之间没有直接关系，即它们中的任何一个都不依赖于另一

个而能独立工作，这种耦合称为非直接耦合。

模块之间的连接越紧密，联系越多，耦合性就越高，而其功能独立性就越弱；

一个模块内部各个元素之间的联系越紧密，则它的内聚性就越高；

功能独立性比较强的模块应是高内聚低耦合的模块。

三、 软件体系结构设计

软件体系结构关注系统的一个或多个结构，包含软件构件、这些构件的对外可见的性质以及它们之间的关系。

常见的软件体系结构：单主机结构、C/S（Client/Server）结构、B/S（Browser/Server）结构 软件体系结构的风格：

1. 数据为中心体系结构：数据保存在整个结构的中心，并且被其他部件频繁地使用、添加、

删除、或者修改。

2. 数据流风格的体系结构：这种结构适用于输入数据被一系列的计算或者处理部件变换成输

出数据。

3. 调用和返回风格的体系结构：便于设计出非常容易修改和扩充的体系结构。

4. 面向对象风格的体系结构:：系统部件封装数据和操作数据的方法。部件之间的交互和协调

通过消息来传递。

5. 层次式风格的体系结构:在这种结构中，定义不同的层次，每层都完成了相对外层更靠近机

器指令的操作。

四、 部件级设计技术

在结构化分析和设计方法时部件往往被称为模块；

在面向对象分析和设计时部件被称为类；

在基于构件的开发方法中，部件被称为构件。

部件级设计阶段工作：

1. 为每个部件确定采用的算法，选择某种适当的工具表达算法的过程，编写部件的详细过程

性描述； (算法过程)

2. 确定每一部件内部使用的数据结构；（数据结构）

3. 在部件级设计结束时，把上述结果写入部件级设计说明书，并且通过复审形成正式文档，

作为下一阶段（编码阶段）的工作依据。（文档）

方法：

1. 结构化程序设计方法：代码块仅通过顺序、选择和循环这三种基本控制结构进行连结，并

且每个代码块只有一个入口和一个出口。

2. 图形表示法：程序流程图、N-S 图、PAD

3. 判定表：当算法中包含多重嵌套的条件选择时，用程序流程图、N-S 图或PAD 都不易清楚

地描述。然而，判定表却能清晰地表达复杂的条件组合与应做动作之间的对应关系。 优点：能够简洁，无二义性地描述所有的处理规则。

缺点：静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构。

4. 设计性语言PDL ：是一种用于描述功能部件的算法设计和处理细节的语言，称为设计性语

言。

五、 设计规约与设计评审

设计评审内容：可追溯性；接口；风险；实用性；技术清晰度；可维护性；质量；

各种选择方案；限制；其他具体问题。

（分正式评审、非正式评审）

第五章 结构化分析与设计

结构化方法：一种面向数据流的传统软件开发方法，以数据流为中心构建软件的分析模型和设计模型（结构化分析、结构化设计、结构化程序设计）。

一、 结构化方法概述

主要思想：抽象与自顶向下的逐层分解（控制复杂性的两个基本手段）。

1、 抽象：忽略一个问题中与当前目标无关的那些方面，以便更充分地关注与当前目标有

关的方面。

2、 分解：将问题不断分解为较小的问题，直到每个最底层的问题都足够简单为止。 过程：

1. 理解当前的现实环境，获得当前系统的具体模型（物理模型）；

2. 从当前系统的具体模型抽象出当前系统的逻辑模型；

3. 4. 为目标系统的逻辑模型作补充。

结构化分析模型的组成与概述： 数据字典：核心，包含了软件使用和产生的所有数据的描述。 数据流图：用于功能建模，描述系统的输入数据流的加工 变换到输出数据流过程。

实体—关系图：数据对象的属性用“数据对象描述”描述。

状态转换图：事件的作用下系统的状态迁移。

控制规约：用来描述软件控制方面的附加信息。

二、 数据流图DFD

定义：描述输入数据流到输出数据流的变换（即加工）过程，用于对系统的功能建模。

基本元素：源或宿：存在于软件系统之外的人员或组织，表示软件系统输入数据的来源和输出

数据的去向，因此也称为源点和终点。

加工：描述输入数据流到输出数据流的变换。

文件：保存数据信息的外部单元。

数据流：有一组固定成分的数据组成。

扩充符号：星号（*）：表示数据流之间存在“与”关系。

加号（+）：表示数据流之间存在“或”关系。

异或（⊕）：表示数据流之间存在“异或”（互斥）关系。

画分层数据流图的步骤：

1、 画出系统的输入和输出：确定源和宿；确定加工；确定数据流。

2、 画出系统内部：确定加工；确定数据流；确定文件；确定源和宿。

3、 画出加工内部

4、 重复第3步，直至加工都足够简单。

画分层数据流图原则：先全局后局部，先整体后细节，先抽象后具体（由顶向下，逐步细化）。

三、 分层数据流图的审查

一致性：分层DFD 中不存在矛盾和冲突。

完整性：分层DFD 本身的完整性，即是否有遗漏的数据流、加工等元素。

构造分层DFD 时需要注意的问题：

适当命名；画数据流而不是画控制流；避免一个加工有过多的数据流；分解尽可能均匀； 先考虑稳定状态，忽略琐碎的枝节；随时准备重画。

四、 数据字典

定义：对所有与系统相关的数据元素的一个有组织的列表，以及精确的、严格的定义，使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解。

种类：数据流、文件、数据项、加工、源或宿。

字典条目描述内容主要包括：

DFD 元素的基本信息（名称、别名、简述、注解）；定义（数据类型、数据组成）；使用特点（取值范围、使用频率、激发条件）；控制信息（来源、去向、访问权限）。

五、 描述基本加工的小说明

定义：是基本加工的规约说明，应精确地描述用户要求一个加工“做什么”，包括加工的激发条件、加工逻辑、优先级、执行频率、出错处理等。

加工逻辑的描述方法：结构化语言；判定表；判定树。

六、 结构化设计（SD ）概述

定义：将结构化分析得到的数据流图映射成软件体系结构的一种设计方法，强调模块化、自顶向下逐步求精、信息隐蔽、高内聚低耦合等设计准则。

结构图：描述软件系统的体系结构，由哪些模块组成，以及模块之间的调用关系。

基本成分：

1） 模块(module)：指具有一定功能的可以用模块名调用的一组程序语句，如函数、子程序等，

是组成程序的基本单元。

外部特征：模块的接口（模块名、输入/输出参数、返回值等）和模块的功能。

内部特征：模块的内部数据和完成其功能的程序代码。

2） 调用(call)：用从一个模块指向另一个模块的箭头来表示，其含义是前者调用了后者。

3） 数据(data)：模块调用时需传递的参数可通过在调用箭头旁附加一个小箭头和数据名来表示。 辅助符号：条件调用、循环调用、递归调用。

深度：程序结构图中控制的层数。

宽度：程序结构图中同一层次上模块总数的最大值。

扇出(fan out)：该模块直接调用的模块数目。

扇入(fan in)：能直接调用该模块的模块数目。

相关指标的含义：

1. 深度和宽度在一定程序上反映了程序的规模和复杂程度。相对而言，如果程序结构图的深

度和宽度较大，则说明程序的规模和复杂程度都较大；模块的扇入扇出会影响结构图的深度和宽度，例如减少模块的扇出，可能导致宽度变小而深度增加。

2. 一个模块的扇出过大通常意味着该模块比较复杂，然而扇出太少，可能导致深度的增加。

3. 一个模块的扇入表示有多少模块可直接调用它，它反映了该模块的复用(reuse)程度，因此

模块的扇入越大越好。

启发式设计策略：

1. 改造程序结构图，降低耦合度，提高内聚度。

2. 避免高扇出，并随着深度的增加，力求高扇入。

3. 模块的影响范围应限制在该模块的控制范围内。

4. 降低模块接口的复杂程度和冗余程度，提高一致性。

5. 模块的功能应是可预测的，避免对模块施加过多的限制。

6. 尽可能设计单入口和单出口的模块。

结构化设计的步骤：

1. 建立初始结构图

2. 对结构图的改进

3. 书写设计文档

4. 设计评审

七、 数据流图到软件体系结构的映射

变换流：信息沿着输入通路进入系统，并将外部形式转换成内部形式，进入系统的信息通过变换中心的处理，再沿着输出通路转换成外部形式后离开系统，具有这种特征的信息流称为变换流。

事物流：数据流沿着输入通路到达一个事务中心，事务中心根据输入数据的类型在若干条动作通路中选出一条来执行，具有这种特征的信息流称为事务流。

事务中心的任务：

1） 接收事务（输入数据）；

2） 分析每个事务以确定它的类型；

3） 根据事务类型选取一条动作通路。

数据流图映射到结构图的步骤：

1. 复审和精化数据流图；

2. 确定数据流图的类型；

3. 将DFD 映射成初始结构图；

4. 改进初始结构图。

变换分析步骤：

1. 划定输入流和输出流的边界，确定变换中心；

2. 进行第一级分解；

3. 进行第二级分解；

4. 标注输入输出信息。

事务分析步骤：

1. 确定事务中心；

2. 将DFD 图映射成事务型的程序结构；

3. 分解每条动作路径所对应的结构图；

第7章 面对对象方法基础

一、 面对对象的基本概念

面向对象 = 对象（object ）+ 分类（classification ）+ 继承（inheritance ）+ 消息通信 面对对象的基本特点：抽象性、封装性、多态性、继承性。

对象：指一组数性以及这组属性上的专用操作的封装体。

属性：类中对象所具有的数据值，是对对象的描述。

类：一组具有相同属性和相同操作的对象的集合。

实例：一个类中的每个对象都是这个类的一个实例。

继承：类间的一种基本关系，是基于层次关系的不同类共享属性和操作的机制。

消息：一个实例对象与另一个实例对象的通信单元，是要求某个实例对象执行类中定义的某个操作。

抽象类：没有实例的类。

多态性：同意操作作用于不同的对象上可以有不同的解释，并产生不同的执行结果。 动态绑定：在程序运行时才将消息所请求的操作与实现该操作的方法进行连接。

面对对象的优点：

1. 提高软件可复用性；

2. 提高软件系统可扩展性；

3. 提高软件系统可维护性。

二、 面向对象的分析和设计过程

面对对象分析的任务：

1. 软件开发人员与用户之间进行交谈与沟通，理解用户对软件的基本要求；

2. 识别和定义问题域中的类；

3. 刻画类的层次结构；

4. 表示类（对象）之间的关系；

5. 定义对象的行为；

6. 最后建立一个完整的分析模型。

面对对象分析（OOA ）的步骤：

1. 获取客户对系统的需求：包括标识场景（scenario ）和用例，以及建造需求模型；

2. 用基本的需求为指南，来选择类和对象（包括属性和操作）；

3. 定义类的结构和层次；

4. 建造对象—关系模型；

5. 建造对象—行为模型；

6. 利用用例/场景来复审分析模型。

面对对象设计（OOD ）的步骤：

1. 系统设计：将子系统分配到处理器；选择实现数据管理、界面支持和任务管理的设计策略；

为系统设计合适的控制机制；复审并考虑权衡。

2. 对象设计：在过程级别设计每个操作；定义内部类；为类的属性设计内部数据结构。

3. 消息设计：使用对象间的协作和对象--关系模型，设计消息模型。

4. 复审：复审设计模型并在需要时迭代。

三、 UML 概述

UML 定义：是一种对软件密集型系统的制品进行下述工作的语言，这些工作包括：可视化、详述、构造、文档化。

特点：

1. 统一标准：已成为面向对象的标准化的统一的建模语言；

2. 面向对象；

3. 可视化、表示能力强大；

4. 独立于过程；

5. 概念明确，建模表示法简洁，图形结构清晰，容易掌握使用

UML 的构成：

1. 视图：它是由一个或者多个图组成的对系统某个角度的抽象

2. 图：类图、对象图、用例图、顺序图、协作图、状态图、活动图、构件图、配置图。

3. 模型元素

4. 通用机制