毛明志老师软件工程期末总结-内容填充版

第一章：

1.1

补充一下1.1

计算机软件：指计算机系统中的程序及其文档。程序是计算任务的处理对象和处理

规则的描述。

1.1.2

软件的特点：

1软件是一种逻辑实体，开发成本和进度难以准确估算；

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

但维护的工作量大

3软件使用没有硬件的机械磨损和老化问题，但使用过程有维护问题，维护修改

程序的时候可能引入副作用，使故障率升高。

1.1.3

软件的分类

1系统软件：操作系统、编译程序等

2支撑软件：数据库管理系统、网络软件等

3应用软甲：各类特定应用程序

1.2

1.2.1

软件工程定义

IEEE：软件工程是:

①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，

即将工程化应用于软件；

②在①中所述方法的研究。

1.2.2

软件工程框架：概括为目标、过程和原则

目标：生产具有正确性，可用性和开销合宜的产品。

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

原则：

①选取适宜的开发模型

②采用合适的设计方法

③提供高质量的工程支撑

④重视软件工程的管理

1.2.3

软件生存周期：六阶段

①计算机系统工程：确定软件开发的要求和范围，估算成本，安排进度，可行性

分析。

②需求分析：要“做什么”，确定软件功能、性能、数据、界面等要求，生成软

件需求规约。

③设计：要“怎么做”，分为系统（总体）设计和详细设计。

前者设计软件系统的体系结构，包括软件系统的组成部分，各成分的功能和接口，

成分间的连接和通信，同时设计全局数据结构；

后者设计各个组成成分的实现细节，包括局部数据和算法

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

⑤测试：任务是发现并纠正软件中的错误和缺陷。主要包括单元测试、集成测试、

确认测试和系统测试。

⑥运行和维护：软件测试完成即可交付使用。在软件运行期间，需对投入运行的

软件进行维护，即当发现软件中潜藏错误或需要增加功能或适应新外部环境变化等，对

软件进行修改。

1.3

1.3.1了解

ISO/IEC12207软件工程生存周期过程

该标准把软件生存周期中可以开展的活动分为5个基本过程，8个支持过程和4个

组织过程。每一个过程划分为一组活动，每项活动又进一步划分为一组任务。

（内容坑爹，无视，P9~P12约3页的表格，有兴趣的自己看

（话说了解比知道要轻..现在我这么觉得

1.3.2

能力成熟度模型CMM

5级：

初始级：无秩序或混乱，成功依赖个人或小组的努力

可重复级：建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要

的过程纪律，能重复早先类似应用项目的成功。

已定义级：以将管理和工程活动两方面的软件过程文档化、标准化，并综合成该组

织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。

已管理级：收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量

的理解和控制。

优化级：过程的量化反馈和先进的新思想、新技术促使过程不断改进

CMM的结构P14有兴趣的..

1.3.3知道

能力成熟度模型集成CMMI

两种表示法：

①阶段式模型：同CMM,关注组织成熟度，5级

初始的、已管理的、已定义的、定量管理的、优化的。

②连续式模型：关注每个过程域的能力，分为6级：

CL0：未完成的：未执行或未达到Q1定义的所有目标

CL1：已执行的：共性目标是过程将可标识的输入工作产品转换成可标识的输出工

作产品，以实现支持过程域的特定目标。

CL2：已管理的：共性目标集中于已管理的过程的制度化。

CL3：已定义级的：共性目标集中于以定义过程的制度化。

CL4：定量管理的：共性目标集中于可定量管理的过程的制度化。

CL5：优化的使用量化（统计学）手段改变和优化过程域，以对付客户要求的该百

年和持续改进计划中的过程域的功效。

1.4

常见模型的种类，特点，优缺点，不同模型间对比

瀑布模型：一路向下，可倒流回到上一级，7级

系统工程->需求分析与规约->设计与规约。编码与单元测试〉

集成测试系统测试。运行与维护

演化模型：先做原型给用户，根据使用意见逐步改造，最终得到令客户满意的产品。

典型的模型有：增量模型、原型模型、螺旋模型（•.居然这模型和后面这三种在同一级

的标题

增量模型：将开发过程分成若干个日程时间交错的线性序列，每个线性序列都产生

软件的一个可发布“增量版本”。（越看越像流水线

原型模型：快速计划，快速设计方式建模，构建原型。部署交付和反馈。交流。快速

计划……不断循环。根据原型目的不同可分为：探索型、实验型、演化型。使用策略分

为废弃策略、追加策略。

螺旋模型：制定计划-＞风险分析〉工程实施,客户评估不断循环。风险太大则可能

终止

喷泉模型：支持面向对象开发的过程模型，开发各个活动没有明显边界，各个活动

经常重复、迭代地进行。“喷泉”体现了面向对象方法的迭代和无间隙特性。六个活动:

演化，集成，测试，编码，设计，分析

1.5

敏捷软件开发基本概念，XP开发特点

敏捷软件开发概念：

书上没有，自由发挥。

简单而言就是软件工程用了，质量提高了，但工作量太大以至于难以准时交付,

于是快节奏开发软件的需求就来了，方法也出来了，这些方法就是敏捷软件开发。

敏捷软件开发价值观：

①

②个人和交互高于过程和工具

③可运行软件高于详尽的文档

④与客户协作高于合同（契约）淡判

对变更及时作出反应高于遵循计划

敏捷软件开发原则：12条P27有兴趣的话..

XP:extremeprogramming极限编程。四个价值观：交流，简单，反馈，勇气（追加

第5个谦虚）。

XP适用于软件需求模糊且挥发性（今天要求明天可能就不需要了）强，开发团队人

数在10人以下，开发地点集中的场合。（这是特点么..？

XP方法的12个核心实践P29-30怎么都是这种..

1.完整的团队

2.计划对策

3.系统比喻

4.小发布

5.测试

6.简单设计

7.结对编程

8.设计改进

9.持续集成

10.代码全体共享

11.编码标准

12.可持续步调

第二章

2.1

计算机系统的概念，内容

基于计算机的系统：通过处理信息来完成某些预定义目标而组织在一起的元素

的集合或排列。组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、

文档和规程。

软件：计算机程序、数据结构和相关的工作产品，以实现所需要的逻辑方法、

规程和控制；

硬件：指提供计算能力的电子设备、支持数据流的互连设备、提供外部世界功

能的电子机械设备（传感器，马达等）。

人员：硬件和软件的用户和操作者。

数据库：通过软件访问并持久存储的大型的有组织的信息集合。

文档：描绘系统使用或操作的描述性信息。

规程：指定义每个系统元素的特定使用或系统所处的过程性语境的步骤。

一个基于计算机的系统可以是另一个更大的基于计算机的系统的一个宏元素

（组成部分）。

2.3

可行性分析的概念，分类

可行性分析：

一个基于计算机的系统通常受到资源和时间上的限制，可行性分析主要从经

济、技术、法律等方面分析给出的解决方案是否可行，能否在规定的资源和时间约

束下完成。

可行性分析分类：

①经济可行性：从成本、效益、货币的时间价值（通常可用年利率来表示）、投

资回收期、纯收入来分析。

②技术可行性：分为风险分析、资源分析、技术分析。

③法律可行性。

第三章

需求工程的角色及其各个阶段〃好吧，其实就是全部

3.1概述

需求工程是应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析

人员理解问题，评估可行性，协商合理的解决方案、无歧义地规约方案、确认规约以及

将规约转换到可运行的系统时的管理要求，需求工程通过合适的工具和符号系统地描述

开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予

支持。

分为6阶段：

①需求获取：通过与用户交流，对已有系统的观察及对任务的分析，确定系统或

产品范围等。

②需求分析与协商：对需求进行分类组织，分析每个需求与其他需求的关系以检

查需求的•致性、重叠和遗漏的情况，并根据用户的需要对需求排序。

③系统建模：通过合适的工具和符号地描述需求。分析和建模方法有：面向数据

流方法、面向数据结构方法和面向对象方法。

④需求规约：需求规约是分析任务的最终产品，建立完整的信息描述、详细功能

和行为描述、性能需求和设计约束说明、合适的验收标准，给出对目标软件的各种需求。

⑤需求验证：对功能的正确性、完整性和清晰性以及其他需求给予评价。

⑥需求管理：对需求工程所有相关活动的规划和控制。

3.2需求获取

3.2.1软件需求

①功能需求：系统要做什么，在何时做，在何时及如何修改或升级

②性能需求：软件开发的技术性指标

③用户或人的因素：用户类型

④环境需求：软件应用的环境，包括硬件和软件。

⑤界面需求：考虑来自其他系统的输入，到其他系统的输出，对数据格式的

特殊规定，对数据存储介质的规定。

⑥文档需求：需要什么文档，针对哪些读者

⑦数据需求：考虑输入、输出数据的格式，接受、发送数据的频率，数据的

准确性和精度，数据流量，数据需保持的时间。

⑧资源使用需求：考虑软件运行时所需要的数据、其他软件、内存空间等资

源；软件开发、维护所需人力、支撑软件、开发设备等。

⑨安全保密要求。

⑩可靠性需求

①①软件成本消耗与开发进度需求

①②其他非功能性要求。

3.2.2需求获取方法与策略

①建立顺畅的通信途径

②访谈与调查

③观察用户操作路程

④组成联合小组

⑤用况

3.3需求分析、协商与建模

3.3.1需求分析原则

•必须能够表示和理解问题的信息域

•必须能够定义软件将完成的功能

•必须能够表示软件的行为（作为外部事件的结果）

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

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

3.3.2信息域

信息域包括：

信息内容：表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。

信息流：表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信

息（数据或控制），然后进一步被变换为输出。

信息结构：表示了各种数据和控制项的内部组织形式，比如数据或控制项将被组织

为n维表还是树形结构..?等

3.3.3抽象、分解与多视点分析

问题抽象方法要求分析人员在分析过程中捕捉用户描述或问题本身固有的一般-特

殊关系，首先关注一般问题的解决途径，进而指导特殊问题的解决方法。

问题分解的目的是要能以层次化的方式对问题进行分解和不断细化。

分析人员在整理用户描述的过程中应注意用户视角上的变化，避免由于视角不全引

起的需求遗缺。

3.3.4需求协商

复杂的系统又许多项目相关人员，他们之间的需求必定会出现冲突，协商的过程就

是讨论需求冲突，找出每个人都满意的折衷方案。

通常会议是解决冲突最快的方式。冲突解决会议应当只关注与冲突相关的需求问

题。

通常会议分为3个阶段：叙述阶段、讨论阶段和决策阶段。

3.3.5需求建模

在需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做。

目标软件的需求模型不应涉及软甲你的实现细节。

常用的分析方法有以下几种：

面向数据流的结构化分析方法(SA)

面向数据结构的分析方法

面向对象的分析方法(00A)

3.4需求规约与验证

3.4.1需求规约的原则

①从现实中分离功能

②使用面向处理的规约语言，讨论来自环境的各种刺激可能导致系统做出什

么样的功能性反应。

③如果被开发软件知识一个基于计算机的系统中的一个元素，那么整个大系

统也应包括在规格说明的描述中

④

⑤规约必须包括系统运行环境。

⑥规约必须是一个认识模型，而不是设计或实现的模型。

规约必修是可操作的，利用它能够通过测试用例判断已提出的解决方案是

否都能满足规约。

⑦规约必须允许不完备性并允许扩充。

⑧规约必须局部化和松散耦合。

3.4.2需求规约

软件需求规约的框架IEEE/ANSI830-1993标准：

1引言

2信息描述

3功能描述

4行为描述

5检验标准

6参考书目

7附录

3.4.3需求验证

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

评审人员评审时往往需要检查以下内容：

①系统定义的目标是否与用户的要求•致

②系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清

晰、准确地反映了用户要求。

③

被开发项目的数据流与数据结构是否确定且充足。

④

⑤主要功能是否已包括在规定的软件范围之内，是否都已充分说明

⑥设计的约束条件或限制条件是否符合实际。

⑦开发的技术风险是什么。

是否制定了详细的检验标准，它们能否对系统定义进行确认。

3.5需求管理

需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求

的活动。

在需求管理中，每个需求被赋予唯一的标识符，一旦标识出需求，就可以为需求建

立跟踪表，每个跟踪表标识需求和其他需求或设计文档、代码、测试用例的不同版本间

的关系。

需求跟踪有两种方式：正向跟踪以用户需求为切入点，检查《需求规约》中的每个

需求是否能在后继工作中找到对应点；逆向跟踪检查设计文档、代码、测试用例等工作

产品是否都能在《需求规约》中找到出处。

第四章

4.1软件设计工程概述

软件设计是把软件需求变换成软件表示的过程，主要包含两个阶段：软件体系结构

（概要）设计阶段和部件级设计阶段。

软件体系结构设计：将软件需求转化为数据结构和软件的系统结构。

部件级设计：将软件体系结构中的结构性元素转化为软件部件的过程性描述，得到

软件详细的数据结构与算法。

4.1.1软件设计的任务

软件设计的输入的软件分析模型。使用一种设计方法，软件分析模型中通过数据、

功能和行为模型所展示的软件需求的信息被传送给设计阶段，产生数据/类设计、体系

结构设计、接口设计、部件级设计。

①数据/类设计：将分析类模型变换成类的实现和软件实现所需要的数据结构。

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

之间的关系组成。

③接口设计：描述了软件内部、软件和协作系统之间以及软件同人之间的通信方

式。

主要包括3方面内容：设计软件模块间的接口，设计模块与其他非人的信息生

产者和消费者之间的外部接口以及设计人与计算机间的人机接口。

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

4.1.2软件设计的目标

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

需求。

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

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

为

达

①

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

②

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

④设计应该既包含数据抽象，也包含过程抽象。

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

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

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

4.1.3软件设计的过程

软①件设计是一个把软件需求编程软件表示的过程，通常软件设计过程分为6个步骤:

制定规范

②

体系结构与接口设计

③

④数据/类设计

⑤部件级（过程）设计

⑥编写设计文档

设计评审

4.2软件设计原则

在将软件的需求规约转换为软件设计的过程中，软件的设计人员通常采用抽象与逐

步求精、模块化和信息隐藏等原则。

4.2.1抽象与逐步求精

①抽象：将注意力集中在某一层次上考虑问题，忽略低层次的细节。软件工程的

每一步都是对较高一级抽象的解作一次具体化的描述。

软件设计的主要抽象手段有：

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

待，尽管这个操作实际上是由一系列更低级的操作完成的（类似函数的概念

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

范围，只能通过这些操作修改和观察数据（类似类的概念。

②逐步求精：把问题的求解过程分解成若干步骤或阶段，每一步都比上一步更精

化，更接近问题的解法。

抽象和逐步求精是一对互补的该你那，抽象使设计者能够描述过程和数据而忽略底

层的细节，而求精有助于设计者在设计过程中揭示底层的细节。

4.2.2模块化

模块化，即把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联

的部件。模块化实际上是系统分解和抽象的过程。

在软件工程中，模块是数据说明、可执行语句等程序对象的集合，是单独命名的，

并且是可以通过名字来访问的。例如，对象类、构件、过程、函数、子程序、宏等都可

以作为模块。

模块具有名字、参数、功能等外部特征以及完成模块功能的程序代码和模块内部数

据等内部特征。

假设C(x)是描述问题x复杂性的函数，E(x)是解决问题x所需工作量(按时间算)的

函数，则有：

①若C(pl)>C(p2)则E(pl)>E(p2)

(2)C(pl+p2)>C(pl)+C(p2)

由①、②可推出

@E(pl+p2)>E(pl)+E(p2)

但虽然有③式存在，模块划分并非越多越好，因为还存在着将模块联接起来的工作

量。

4.2.3信息隐藏

每个模块的实现细节对于其他模块来说应该是隐蔽的，即模块中包含的信息(包括

数据和过程)不允许其他不需要这些信息的模块使用。

4.2.4模块独立

所谓的模块独立指：模块完成独立的功能并且与其他模块的接口简单，符合信息隐

蔽，模块间关联和依赖程度尽可能小。模块独立性是模块化、信息隐藏和局部化等概念

的直接结果。

模块的独立性很重要，体现在：

①功能被划分，并且接口被简化，所以具有有效模块化的软件更易于开发。

②由于因设计和编码修改引起的副作用受到局限，错误传播被减少，并且模块复

用成为可能，所以独立的模块更易于测试和维护。

模块的独立性可以由两项指标来衡量：内聚度和耦合度。

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

耦合度：衡量不同模块彼此间相互依赖的紧密程度。

4.2.4.1内聚

一般模块内聚性分为7种类型，由低到高分别是：

①巧合内聚：将几个模块中没有明确表现出独立功能的相同程序代码段独立

出来建立的模块。

②逻辑内聚：完成一组逻辑相关任务的模块，调用该模块时，由传送给模块

的控制型参数来确定该模块应执行哪一和功能。

③时间内聚：一个模块中的所有任务必须在同一时间段内执行，例如初始化

模块和终止模块。

④

过程内聚：一个模块完成多个任务，这些任务必须按指定的过程执行。

⑤

⑥通信内聚:--个模块内所有处理元素都集中在某个数据结构的一块区域中。

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

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

密联系，不可分割。

4.2.4.2耦合

一般模块之间的可能的耦合方式有7种，由高到低分别是：

①内容耦合：一个模块直接访问另一个模块的内部数据；或一个模块不通过

正常入口转到另一模块内部；或两个模块有一部分代码重叠；或一个模块有多个入

口。

②公共耦合：一组模块都访问同一个公共数据环境。公共数据环境可以是全

局数据结构、共享的通信区、内存的公共覆盖区等。

③外部耦合：模块间通过软件之外的环境联结（如I/O将模块耦合到特定的

设备、格式、通信协议上）时。

④控制耦合：•个模块传送给另一个模块的参数中包含了控制信息，该控制

信息用于控制接受模块中的执行逻辑。

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

数据结构的子结构）。

⑥数据耦合：两个模块之间仅通过参数表传递简单数据。

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

于另•个而能够独立工作。

强耦合-＞低内聚

强内聚。低耦合

耦合和内聚都是模块独立性的定性标准，都反映了模块独立性的良好程度，但耦合

是直接的主导因素，内聚则辅助耦合共同对模块独立性进行衡量。

4.3软件体系结构设计

4.3.2软件体系结构的风格

一些软件体系结构风格：

①数据为中心的体系结构：一些数据保存在整个结构中心，并且被其他部件频繁

地使用、添加、删除、修改。

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

输出数据。由管道和过滤器组成，过滤器之间由传送数据的管道联通。

③调用和返回风格的体系结构：包含主程序/子程序风格体系结构和远程过程调用

风格的体系结构。前者把功能分解成控制层次，顶层调用下层，下层调用下下层，最下

层完成最具体的功能；后者是前者的扩展，这种结构中被主程序调用的部件分布在网络

上不同的计算机中。

④面向对象风格的体系结构系统部件封装数据和操作数据的方法，部件之间的交

互和协调通过消息来传递。

⑤层次式风格的体系结构：圆环套圆环，最外面层部件向用户提供接口操作，最

内层部件使用系统接口，每个中间层都是对内层接口的封装。

4.4部件级设计技术

在部件设计阶段，主要完成如下工作：

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

的详细过程性描述。

②确定每一部件内部使用的数据结构。

③在部件级设计结束时，应该把上述结果写入部件级设计说明书，并通过复审形

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

4.4.1结构化程序设计方法

如果一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接，

并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。

结构化程序设计方法能提高程序的可读性、可维护性和可验证性，从而提高软件的

生产率。

4.4.2图形表示法

4.4.2.1程序流程图

入口出口：圆角矩形

顺序语句：矩形

条件分支：菱形

只允许5种基本控制结构：顺序型，选择型、先判定型循环、后判定型循

环、多情况选择型，如下所示：

③先判定型循环④后判定型街好

(DOWHILE)<DO-INTIL)

4.4.2.2N-S图

懒的画了

、P1

二1=2♦♦♦♦♦♦=n

AlA2♦♦♦♦♦♦An

⑤多分支选择型

s(CASE型)

DO-UNTILP

③WHILE重复型④UNTIL重复型

4.4.23PAD

PAD=problemanalysisdiagram

①顺序型②选择型

⑤多分支选择型

③WHILE重复型④UNTIL重复型（CASE型）

4.4.3判定表

简单而言就是列出所有条件可能组合以及对应的操作。

1251891011121314

4.4.4设计性语言PDL

某种伪代码，关键字一律大写，其他单词一律小写。

PROCEDUREspellcheckIS查找错拼的单词

BEGIN

splitdocumentintosinglewords

把整个文档分离成单词

loodupwordsindictionary

在字典中查这些单词

displaywordswhicharenotindictionary

显示字典中查不到的单词

createanewdictionary造一新字典

ENDspellcheck

P85课后题,第2,4,5,8题

以下问题答案不保证正确性

4.2软件设计和软件质量的关系是怎么样的

答：在进行软件设计的过程中，我们要密切关注软件的质量因素。同时软件质量也很

大程度依赖于软件设计。

4.4简述模块、模块化及模块化设计的概念

答：

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

名字来访问。

模块化，即把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联

的部件，实际上是系统分解和抽象的过程。

模块化设计，即利用模块化的思想进行软件设计。

4.5举例说明每种类型的模块契合度和每种类型的模块内聚度，作业

4.8什么是模块的独立性？设计中为什么模块要独立？如何度量独立性？模块功能独

立有何优点？

答：

所谓的模块独立指：模块完成独立的功能并且与其他模块的接口简单，符合信息隐

蔽，模块间关联和依赖程度尽可能小。模块独立性是模块化、信息隐藏和局部化等概念

的直接结果。

模块的独立性很重要，体现在：

①功能被划分，并且接口被简化，所以具有有效模块化的软件更易于开发。

②由于因设计和编码修改引起的副作用受到局限，错误传播被减少，并且模块复

用成为可能，所以独立的模块更易于测试和维护。

模块的独立性可以由两项指标来衡量：内聚度和耦合度。

第五章结构化分析与设计〃重点。

/*极度混乱，MMZ想到什么说什么，不保证全都记下了，因为有些说得很含糊*/

数据流的分析方法，数据字典，数据流图，UML,UML视图，面向对象的设计步骤

/*个人整理如下，实在太混乱，而且感觉他没讲全，仅供参考*/

5.1结构化方法概述

一种面向数据流的传统软件开发方法

以数据流为中心构建软件的分析模型和设计模型

分为：

结构化分析(StructuredAnalysis简称SA)

结构化设计(StructuresdDesign简称SD)

结构化程序设计(StructuredProgrammin简称SP)

5.1.1抽象和分解

抽象：在每个抽象层次上忽略问题的内部复杂性，只关注整个问题与外界的联

系

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

5.1.2结构化分析过程

①理解当前的现实环境，获得当前系统的具体模型(物理模型)

②从当前系统的具体模型抽象出当前系统的逻辑模型

③分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型

④为目标系统的逻辑模型作补充

5.1.3结构化分析模型的描述

/毕

革

融/

劣

状态转换图

稔制规妁

5.2数据流图(这货毫无疑问的是重点啊

DataFlowDiagram(简称DFD)：描述输入数据流到输出数据流的变换(即加工)过

程，用于对系统的功能建模。

5.2.1数据流图的图形表示

_A数据流(dataflow)：由一组固定成分的数据组成，代表

数据的流动方向

C加工(process)：描述了输入数据流到输出数据流的变

3换，即将输入数据流加工成输出数据流

—文件(file)：使用文件'数据库等保存某些数据结果供以

一后使用

I—I源或宿(sourceorsink)：由一组固定成分的数据组成，

1■-1代表数据的流动方向

5.2.1.1数据流图的基本图形元素

①源或宿：存在于软件系统之外的人员或组织，表示软件系统输入数据

的来源和输出数据的去向，因此也称为源点和终点

源或宿用相同的图形符号表示

当数据流从该符号流出时表示是源

当数据流流向该符号时表示是宿

当两者皆有时表示既是源又是宿

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

每个加工用一个定义明确的名字标识

至少有一个输入数据流和一个输出流

可以有多个输入数据流和多个输出数据流

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

每个文件用一个定义明确的名字标识

由加工进行读写

DFD中称为文件，但在具体实现时可以用文件系统实现也可以用数据

库系统等实现

④数据流：每个数据流用由一组固定成分的数据组成并拥有一个定义明

确的名字标识

数据流的流向

从一个加工流向另一•个加工

从加工流向文件（写文件）

从文件流向加工（读文件）

从源流向加工

从加工流向宿

示例：图书订购系统DFD

5.2.1.2数据流图中的扩充符号

描述一个加工的多个数据流之间的关系

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

所有输入数据流同时存在时，才能进行加工处理

或加工处理的结果是同时产生所有输出数据流

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

至少存在一个输入数据流时才能进行加工处理

或加工处理的结果是至少产生一个输出数据流

③异或（©）：表示数据流之间存在“异或"（互斥）关系

必须存在且仅存在一个输入数据流时，才能进行加工处理

或加工处理的结果是产生且仅产生一个输出数据流

5.2.1.3数据流图的层次结构

顶层图只有代表整个软件系统的1个加工，描述了软件系统与外界（源

或宿）之间的数据流

顶层图中的加工经分解后的图称为0层图（只有1张）

中间层图中至少有一个加工（也可以有多个）在下层图中分解成一张子

图

处于最底层的图称为底层图，其中所有的加工不再分解成新的子图

顶层图只有一个代表整个软件系统的加工，该加工不必编号。

。层图中的加工编号分别为1,2,3,-

子图号：若父图中的加工号x分解成某一子图，则该子图号记为“图

X”

子图中加工的编号：若父图中的加工号为X的加工分解成某一子图，

则该子图中的加工编号分别为x.l、x.2、X.3-

小技巧：对于层次较多的DFD,较底层加工号可能很长，则可以在图

中先标上图号，然后其中的加工号则可写作：.1,.2,.3

5.2.2分层数据流图的画法

这例子是某考务处理系统

①画出系统的输入和输出

确定源或宿：考生、阅卷站和考试中心

它们都既是源又是宿

顶层图唯一的加工：软件系统（考务处理系统）

确定数据流：系统的输入/输出信息

输入数据流：报名单（来自考生）、成绩清单（来自阅卷站）、合格标准卜来自考

试中心）

输出数据流：准考证（送往考生）、考生名单（送往阅卷站）、考生通知书（送往

考生）、统计分析表（送往考试中心）

额外的输出流（考虑系统的健壮性）：不合格报名单（返回给考生），错误成绩

清单（返回给阅卷站）

顶层图通常没有文件

于是得到了：

不合格报名单统计分析表,

考生考试中心

阅卷站

②画出系统内部

以下确定加工、数据流、文件、源或宿的一般方法适用于0层图及其各层

子图

确定加工：将父图中某加工分解而成的子加工

根据功能分解来确定加工：将一个复杂的功能分解成若干个较小的功能，

较多应用于高层DFD中的分解

根据业务处理流程确定加工：分析父图中待分解加工的业务处理流程，业

务流程中的每一步都可能是一个子加工

特别要注意在业务流程中数据流发生变化或数据流的值发生变化的地方，

应该存在•个加工，例如：

合格报名单正式报名单

1确定数据流

在父图中某加工分解而成的子图中，父图中相应加工的输入/输出数据流都

是且仅是子图边界上的输入/输出数据流

分解后的子加工之间应增添相应的新数据流表示加工过程中的中间数据

如果某些中间数据需要保存以备后用，那么可以成为流向文件的数据流

同一个源或加工可以有多个数据流流向一个加工，如果它们不是一起到达

和一起加工的，那么可以将它们分成若干个数据流。

2确定文件

如果父图中该加工存在读写文件的数据流，则相应的文件和数据流都应画

在子图中

在分解子图中，如果需要保存某些中间数据以备后用，则可以将这些数据

组成一个新的文件

新文件（首次出现的文件）至少应有一个加工为其写入记录，同时至少存在

另一个加工来读该文件的记录

注意：从父图中继承下来的文件在子图中可能只对其进行读，或只进行写

3确定源和宿

0层图和其它子图中通常不必画出源和宿

有时为了提高可读性，可以将顶层图中的源和宿画在0层图中

4最终得到考务处理系统0层图

不合格报名单考生通知单

2

报名单统计分析表

统计

考试成绩

报名

准考证错误成绩清单

考

生

名、成绩清单

单

根据功能分解方法谡别出两个加工：考试报名、统计成绩

数据流

继承顶层图中的输入数据流和输出数据流

定义二个加工之间的数据流：由于这二个加工分别在考试前后进行，因此

登记报名单所产生的结果“考生名册”应作为文件保存以便考试后由统计成绩

加工引用

③画出加工内部

复杂的加工可以继续分解成1张DFD子图

分解方法

将该加工看作一个小系统，该加工的输入/输出数据流就是这个假设的小系统的

输入/输出数据流

然后采用画0层图的方法，画出该加工的子图

④重复第3步，直至每个尚未分解的加工都足够简单（即不必再分解）

总结：画分层数据流图的步骤

1.画系统的输入和输出

2.画系统内部

3.画加工内部

4.重复第3步，直至每个尚未分解的加工都足够简单（即不必再分解）

5.4数据字典

数据流图与数据字典是密不可分的，两者结合起来构成软件的逻辑模型（分析模

型）

5.4.1字典条目的种类及描述符号

数据字典由字典条目组成，每个条目描述DFD中的一个元素

①字典条目的种类

数据字典条目包括：数据流、文件、数据项（组成数据流和文件的数据）、

加工、源或宿

②数据字典使用的描述符号

符号名称举例

=定义为X=...表示X由…组成

4-与a+b表示a和b

...1或[a,bl表示a或b

或[a|bJ表示a或b

{...)重复{a}表示a重复0或多次

n

{…}加重复{a}：表示a重复3到8次

(...)（a）新重复0或1次

99，，基本数据元素表a是基本数据

5.4.2字典条目

不同的开发组织或团队可以根据项目的需要定义字典条目的描述内容

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

DFD元素的基本信息（名称、别名、简述、注解）

定义（数据类型、数据组成）

使用特点（取值范围、使用频率、激发条件）

控制信息（来源、去向、访问权限）等

卜面的条目内容太多，忽略。

D数据流条目

2）文件条目

3）数据项条目

④加工条目

⑤源或宿条目

⑥别名条目：为有必要补充说明的别名给出

5.4.3字典条目实例

培训报名单=姓名+单位+课程

运动员报名单=队名+姓名+性别+｛参赛项目｝

5.4.4数据字典的实现

提倡采用专用的软件工具或者常用的实用程序（如，正文编辑程序、电子表

格）来建立数据字典的电子文档，其好处是便于字典条目的检索，字典的管理和

维护。

如果数据字典由辅助绘制DFD的工具自动产生的话，那么可以利用数据字

典来检查DFD的一致性和完整性，并保持数据字典与DFD的一致。

如果数据字典是由人工制作的，我们可以为每个字典条目制作一张卡片，

所有卡片按字典条目的种类（数据流、文件、加工等）分类成册，每类卡片按某

种约定排序。

以下小节在提纲中未出现，但有过作业，所以也加进来了

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

结构化设计是将结构化分析的结果（数据流图）映射成软件的体系结构（结构图）

将数据流图分为变换型数据流图和事务型数据流图，对应的映射分别称为变换

分析和事务分析

5.7.1信息流可分为变换流和事务流

①变换流

特征：数据流图可明显地分成输入、变换、输出三部分

信息沿着输入路径进入系统，并将输入信息的外部形式经过编辑、格式转

换、合法性检查、预处理等辅助性加工后变成内部形式

内部形式的信息由变换中心进行处理

然后沿着输出路径经过格式转换、组成物理块、缓冲处理等辅助性加工后

变成输出信息送到系统外

②事务流

特征：数据流沿着输入路径到达一个事务中心，事务中心根据输入数据的

类型在若干条动作路径中选择一条来执行

事务中心的任务是：接收输入数据（即事务）；分析每个事务的类型；根据

事务类型选择执行-•条动作路径。

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

①复审和精化数据流图

②确定数据流图的类型（变换型、事务型）

③将DFD映射成初始结构图：采用变换分析（5.7.3节）或事务分析（574

节）技术。

④改进初始结构图（5.8节）

5.7.3变换分析

变换分析的任务是将变换型的DFD映射成初始的结构图，步骤如下：

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

进行第一级分解：将DFD映射成变换型的程序结构

进行第二级分解：将DFD中的加工映射成结构图中的一个适当的模块

标注输入输出信息：根据DFD,在初始结构图上标注模块之间传递的

主控模块

输入变换输出

控制模块控制模块控制模块

5.7.4事务分析

事务分析的任务是将事务型的DFD映射成初始的结构图，步骤如下：

确定事务中心：事务中心位于数条动作路径的起点，这些动作路径呈幅射

状从该点流出

①将DFD映射成事务型的结构图

②分解每条动作路径所对应的结构图

③接收模块的分解：从事务中心开始，沿着输入路径向外移动，把输入

路径上的每个加工映射成结构图中受接收模块控制的一个低层模块

④动作路径控制模块的分解：首先确定每条动作路径的流类型（变换流或

事务流），然后，运用变换分析或事务分析，将每条动作路径映射成与其流特性

相对应的以动作路径控制模块为根模块的结构图

5.8初始结构图的改进

>结构图改进技巧

①

减少模块间的耦合度

②

③消除重复功能

④消除“管道”模块

⑤模块大小适中

⑥避免高扇出

应尽可能研究整张结构图，而不是只考虑其中一部分。

第七章面向对象的分析和设计〃重点

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

7.2.1面向对象分析过程(00A)

7.2.1.1面向对象分析的任务

目标是完成对所解问题的分析，确定待建的系统要做什么，并建立系统模

型。

7.2.1.2面向对象分析的步骤

①获取客户对系统的需求，建造需求模型；

②用基本的需求为指南来选择类和对象(包括属性和操作)

③定义类的结构和层次

④建造对象-行为模型

⑤利用用况/场景来复审分析模型

7.2.2面向对象设计过程(00D)

00D是将00A所创建的分析模型转化为设计模型。

与传统方法不同QOD和00A没有明确的分界线，往往反复迭代进行。00A主

要考虑系统做什么，00D则考虑系统怎么做，因此需要在00A的模型上增加一些

类或者在原有类中补充一些属性和操作。

00D同样应该遵循抽象、信息隐蔽、功能独立、模块化等设计原则。

7.2.2.100D的一般步骤

①系统设计

②对象设计

③消息设计

④复审

内容各种多..有兴趣自行P155~157

7.2.3设计模式

在许多面向对象系统中，存在一些类和通信对象重复出现的模式。这些模式求

解特定的设计问题，使面向对象设计更灵活，并最终可复用。

•个设计模式通常可用4个信息来描述

①模式名

②模式的环境和条件

③设计模式的特征

④应用设计模式的结果

7.3UML概述

用于对软件密集型系统的制品进行可视化、祥述、构造和文档化的图形语言，

是一种描绘系统蓝图的标准方法。

PPT和课本的UML视图和图的分类不同..统•建模语言不统了怎么办！

这里以PPT为准，因为懒得打字。

图形化的表示机制，十多种视图，分4类：

用例图：用户角度：功能、执行者

静态图：系统静态结构