三大块内容：

软件危机与软件工程

传统软件开发方法

面向对象方法

一、软件危机与软件工程：

软件、软件危机、软件生存期、软件开发模型、软件管理

1、软件： 软件是能够完成预定功能和性能的可执行的计算机程序

+使程序正常运行所需要的数据

+描述软件开发过程及其管理、程序的操作和使用的有关文档。

文档：分开发、管理、用户、维护文档，作用是记录及解决不可视性、通信与交流、管理与维护、用户服务

2、软件危机

a)表现：软件成本高、难于控制开发进度、软件工作量估计困难、软件质量低、软件修改维护困难

b)原因：需求问题(描述不精确、理解不一致)、管理问题、方法和工具问题、软 件本身的特点

3、软件生存期：

a)三个时期： 定义时期(软件计划、需求分析)—>开发时期(软件设计、编码实现、测试)—>使用和维护时期(维护)

b)六个阶段：软件计划 需求分析 设计 编码 测试 使用与维护

c)生命周期方法特点：顺序性、依赖性，推迟程序的物理实现、质量保证的观点(利于尽早发现错误，如阶段文档、评审)

4、软件开发模型

a)瀑布模型：文档驱动

i.阶段划分、分而治之、控制开发过程的复杂性

ii.自顶向下、由抽象到具体，顺序进行

优点：规范管理开发过程、文档驱动

缺点：初期系统的需求难以完全确定、文档驱动、周期长

b)原型模型：

i.针对：软件开发初期需求难以确定

ii.基本思想：快速建立原型，完善用户需求

iii.优点：用户参与、快速

iv.缺点：快速弱功能、对开发环境要求高

c)螺旋模型(风险驱动)

d)增量模型(模块、功能驱动)

e)迭代模型

f)喷泉模型

5、软件管理

a)区别于其他工业产品生产管理的特点

b)主要内容：开发计划与进度管理、文档管理、人员组织管理、成本管理、质量管理

二、传统软件工程方法：

a)软件计划

i.问题定义

ii.可行性研究

1.经济可行性

2.技术可行性

3.法律可行性

b)需求分析

i.结构化分析SA

ii.面向数据流的分析方法

1.DFD四个组成部分(表示方法、命名)

2.DFD作图：需求描述 DFD

3.层次分解法(保持父图和其子图的平衡)

4.数据字典(符号)

c)软件设计

i.总体设计

1.模块独立性：高内聚

2.作用域是控制域的子集

3.单入单出

4.规模、深度、宽度、扇入、扇出适当

ii.传统设计方法

1.面向数据流的设计方法(数据流图)

a)结构化设计SD- 对应有SD结构化需求分析、SP结构化实现

b)DFD 软件结构(层次图)

i.变换设计

ii.事务设计

c)优缺点

2.面向数据结构的设计方法

a)Jackson方法

b)Jackson图

i.三种元素间的逻辑关系：顺序、选择、重复

ii.可描述两种数据结构:数据结构、程序结构

c)思想：数据结构与程序处理过程相互转换

d)步骤：I/O DS 对应关系 Program Structure 细化求精

e)优缺点：

i.数据入手

ii.简化数据处理程序的设计

iii.模块与独立性原则没有给予应有的重视

iv.求提供对复杂系统设计过程的支持

3.Parnas方法

iii.详细设计

1.结构化程序设计SP

a)高效率---良结构

b)三种基本控制结构、单入单出

2.过程设计的工具

d)实现/编码

i.语言

1.功能等价

2.描述问题方便性有差异

a)例如：OOPL---非OOPL

ii.程序设计风格

e)软件测试

i.目标

ii.方法

1.正确性证明

2.静态测试

3.动态测试

a)黑盒(功能)测试

i.等价类划分

ii.边界值分析

iii.错误推测

b)白盒(结构)测试

i.语句覆盖

ii.判定覆盖

iii.条件覆盖

iv.判定—条件覆盖

v.条件组合覆盖

iii.步骤

f)软件维护

i.四种类型

1.校正性

2.适应性

3.完善性

4.预防性

ii.提高可维护性的措施

三、面向对象方法(Object-oriented Method)

a)OOM与CM对比：区别—优点

i.思维方式 iv. 稳定性

ii.可重用性 v. 可维护性

iii.大型软件

b)OOSE方法

i.三个阶段、五个模型、

ii.USE CASE

第二章．传统软件工程方法：软件计划

具体任务：项目定义、可行性分析、软件计划

其中：可行性分析：

1、可行性研究实质：可行性研究试一次大大压缩和简化了的系统分析和设计过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计过程。

2、主要内容：

a)经济可行性:资金有无落实、成本—效益分析

b)技术可行性:开发的风险、资源的有效性、技术方案

c)操作可行性:用户组织内的管理制度、人员素质、操作方式等是否可行。

d)法律及社会可行性

e)开发方案的选择:折衷手段权衡。

3、可行性研究的主要步骤：

a)复查系统规模

b)研究正在使用的旧系统

c)导出高层逻辑模型

d)重新定义问题

e)导出多种解法

f)推荐行动方针

g)草拟开发计划

h)书写文档并提交审查

系统流程图(物理建模工具)：会读、读懂。

数据流图：

概述

• 描绘系统的逻辑模型的工具

• DFD: Data Flow Diagram

• 描绘信息流和数据从输入移动到输出的过程中所经

受的变换

数据从哪里来，到哪里去，经过怎样的处理，保存在哪里

• 没有任何具体的物理部件，只是描绘数据在软件中

流动和被处理的逻辑过程。是系统逻辑功能的图形表

示。

•是分析员和用户沟通的工具 是后期设计的出发点

DFD的绘制一般采用自顶向下、逐步细化的方法，主要步骤如下：

·明确系统界面。识别出那些不受系统控制但又影响系统运行的外部环境。

·绘制基本系统模型。

基本系统模型由若干源点、终点和一个基本处理组成，表明系统对数据加工变换的基本功能。

·逐层细化基本系统模型得到功能级DFD和详细DFD。下面即分层数据流图。

假设一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据；零件编号零件名称、定货数量、目前价格、主要供应者和次要供应者。 零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。

从问题描述中提取数据流图的四种成分。

首先考虑数据的源点和终点：

• “采购部每天需要一张定货报表”

• “通过放在仓库中的CRT终端把事务报告给定货系统”

可知：

采购员是终点

仓库管理员是源点

接下来考虑处理：

• “采购部每天需要一张定货报表” --采购部需要报表

• “零件入库或出库称为事务，通过放在仓库中的

CRT终端把事务报告给定货系统。” --事务的后果是改变库存量

可知：

产生报表是一个处理

处理事务是另一个处理

最后考虑数据流和数据存储：

• 系统把定货报表送给采购部----定货报表

• 事务需要从仓库送到系统中----事务----需把事务数据存储起来

产生报表和处理事务在时间上不匹配, 当某种零件的库存数量少于库存量临界值时就应该再次定货，而每天打印一次定货报表-----需把定货信息存储起来

可知：

定货报表、事务是数据流(数据流如报表包含零件编号零件名称、定货数量、目前价格、主要供应者和次要供应者等信息。事务包含零件编号、事务类型、数量等。)

库存清单、定货信息是数据存储

基本系统模型：

功能数据流图：注意符号

进一步分解处理事务：

命名

1）为数据流(或数据存储)命名

• 名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分

• 不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)

• 如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的

2 ）为处理命名

• 通常先为数据流命名，然后再为与之相关联的处理命名，体现了人类习惯的“由表及里”的思考过程

• 名字应该反映整个处理的功能

• 名字最好由一个具体的及物动词，加上一个具体的宾语组成。

• 通常名字中仅包括一个动词

• 如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解

应注意的问题

1 ）是数据流不是控制流

画数据流不是控制流；数据流图反映系统“做什么”，不反映“如何做”，因此箭头上的数据流名称只能是名词或名词短语，整个图中不反映加工的执行顺序。

2 ）一般不画物质流

数据流反映的是能用计算机处理的数据，并不是实物，因此系统的数据流图上一般不要画物质流。

3 ）加工的画法

每个加工至少有一个输入数据

数据流图的用途：

1）建立新系统逻辑模型的工具

2）作为与用户和开发人员交流信息的工具

3）作为分析、设计乃至维护的依据

数据字典：

概念

• 数据字典是关于数据的信息的集合

• DD: Data Dictionary

• 是对DFD中包含的所有元素的定义的集合

• 在分析、设计和维护过程中供查阅用

内容

1）数据流

2）数据流分量（即数据元素）

3）数据存储

4）处理（IPO图或PDL更加方便）——是对上述四类元素的定义

具体信息

• 名字——数据、控制项、数据存储或外部实体的主要名称

• 别名——该元素等价的其他名字，尽量减少

• 使用地点与方式——使用数据或控制项的处理的列表，以及使用这些对象的方式(例如作为处理的输入，从处理输出， 作为数据存储，作为外部实体)

• 内容描述——描述数据或控制项内容的符号

• 补充信息——关于数据类型、预置值、限制等的其他信息

软件项目的量化估算

⏹成本估算 & 工作量估算

⏹工程进度安排

行成本估算

阶段成本估算

甘特图：历史悠久、应用广泛的进度计划工具

进度安排的任务网络图

优点：简单，能动态地反映开发进展

缺点：难以反映多个任务间的逻辑关系

第三章．传统软件工程方法：需求分析

需求分析

⏹1 目标和任务

⏹2 需求获取技术

⏹3 需求内容

⏹4 需求建模方法

需求分析任务

⏹问题分析

⏹需求描述

⏹需求评审

需求建模方法

1.面向数据流的分析方法

2.面向对象的分析方法

3.面向数据结构的分析方法

需求工程的任务

需求开发包含四个过程：需求获取、需求整理与分析、需求定义、需求验证。

需求分析的具体任务：需求获取、确定和分析需求、开发原型系统、编写SRS、需求验证、变更管理、修正计划

软件需求及需求的分类

软件需求：以一种清晰、简洁、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对系统的约束。（表达做什么而不描述如何做。）

Requirement is the Basics of Quality，软件需求的作用：

①分理解现实中的业务问题，并作为软件设计的基础；②为软件项目的成本、时间、风险估计提供准确的依据；③少开发工作量，避免将时间与资源浪费在设计与实现错误的需求上；④通提供需求文档和需求基线，来有效的管理系统演化与变更；⑤为顾客与开发团队之间正式合同的一部分；⑥最终的验收测试提供标准和依据

需求的分类：

业务需求 业务需求指导需求获取 用户需求 转化用户需求为系统需求 系统需求

前四个为原始问题空间、后面系统需求为解决方案空间。

业务需求(Business Requirements)： 客户对于系统的高层次目标要求(highlevel objectives) ，定义了项目的远景和范畴(vision and scope)

1、业务：属于哪类业务范畴？应完成什么功能？为何目的？

2、客户：软件为谁服务？目标客户是谁？

3、特性：区别于其他竞争产品的特性是什么？

4、价值：价值体现在那些方面？

5、优先级：功能特性的优先级次序是什么？

用户需求(User Requirements)： 从用户角度描述的系

统功能需求与非功能需求，通常只涉及系统的外部行

为而不涉及内部特性。

系统需求(System Requirements, SR)： 系统应该提供

的功能或服务，通常涉及用户或外部系统与该系统之

间的交互，不考虑系统内部的实现细节

系统需求的类型分：

功能性需求：描述了系统与其实现环境之间的交互。环境包括用户和任何其他与该系统进行交互的外部系统。

功能需求可以以不同的详细程度反复编写和细化

功能需求描述应该完整而且一致和准确

完整性意味着用户所需的所有的服务应该全部给出描述

一致性意味着需求描述不能前后矛盾

准确性是指需求不能出现模糊和二义性的地方

非功能性需求：

描述了不直接关联到系统功能行为的系统的方方面面。从各个角度对系统的约束和限制，反映了客户对软件系统质量和性能的额外要求，如响应时间、数据精度、可靠性等。

可用性(Usability):是一种用户可以学会的操作、输入准备、解释一个系统或者构件输出的状况。

可靠性(Reliability):是系统或构件在给定时间内、指定条件下，完成其要求功能的能力。

性能(Performance):需求要考虑系统的定量属性，比如响应时间，吞吐量、有效性和准确性。

可支持性(Supportability):需求关注于在进行部署后系统的变化状况，比如包括可适配性、可维护性、可移植性等。

需求获取技术 略

需求分析：分析方法

结构化分析方法SA

核心思想是模块化，自顶向下逐步求精对系统进行分析。

使用多个需求分析视图，建立系统的数据、功能和行为模型

数据流图DFD

加工说明PSPEC

数据字典DD

状态迁移图STD

关联图

E-R图

面向对象分析方法OOA

核心思想是利用OO的概念和方法对软件需求建造模型，以使用户需求逐步精确化、一致化、完全化。

结构化分析建模(与SA区分)，就是面向数据流的分析方法

结构化分析方法是一种传统的系统建模技术，它提出来一组提

高软件结构合理性的准则。

结构化分析：使用数据流程图、数据字典、结构化英语、判定

表和判定树等工具，来建立一种新的、称为结构化说明书的目

标文档－需求规格说明书。

结构化分析方法的要点是：面对数据流的分解和抽象；把复杂

问题自顶向下逐层分解

、

其中，只要求数据流图和数据字典。

DFD是描绘系统逻辑模型的常用图形工具。它描绘了信息流和数据从输入端移动到输出端的过程中所经受的变换。

在DFD中没有具体的物理元素，只是描述信息在系统中的流动、处理和存储的逻辑过程，表明系统必须完成的基本逻辑功能。

DFD中只有四种元素，不包括任何有关物理实现的细节，所以，绝大多数用户可以理解和评价它。

DFD是分析和设计的工具。

实体关系图—E-R图

数据流图--DFD图

状态转换图—STD图

DFD组成成分：

（4）加工分解原则

a)1加工 ≤7子加工

b) 按问题的逻辑特性分解

c) 尽量少分解层次

d) 分解均匀

模型中还需要描述数据是如何被加工处理的：1、结构化语言 2、判定表 3、判定树

判定表：

第四．传统软件工程方法：软件设计中的总体设计。

软件设计两个阶段：概要设计 详细设计

作用：SE核心过程

软件设计阶段的任务

从工程管理的角度，分为总体设计阶段和详细设计阶段；

技术的角度，分体系结构设计、数据设计、接口设计和过程设计

总体设计分两个阶段：

① 系统设计阶段

确定系统的具体实现方案。

② 结构设计阶段

确定软件结构

确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系。

总体设计的重要性：总体设计是软件开发过程中一个非常重要的阶段。可以肯定，如果软件系统没有经过认真细致的总体设计，就直接考虑它的算法或直接编写源程序，这个系

统的质量就很难保证。许多软件就是因为结构上的问题，使得它经常发生故障，而且很难维护

什么是好的软件设计

软件质量评价标准：

定性评价：

❑用户角度：达到需求、界面友好、简单易学

❑开发人员角度：良结构、易测试、易维护、可移植 …

定量评价：软件度量

宏观标准：可靠性 良软件结构 文档齐全

软件结构

软件的各个组成部分之间的关系的表示，

决定了整个系统的结构和质量

扇出：直接由一个块所控制的块数

扇入：直接调用它的上级块数目

深度：控制的总层数

宽度：跨度最宽层的跨度数

模块化

依据：复杂程度 工作量

模块重要特征：

1.抽象：忽略细节，分层理解问题，自顶向下层层细化。

2. 信息隐藏

☞细节隐藏

☞ 可理解性

☞ 修改副作用小

☞ 错误副作用小

模块独立性

度量：耦合—块间联系 内聚—块内联系

耦合

零耦合：块间无任何连接

数据耦合：两模块通过参数交换信息，只交换数据。

控制耦合：传递的信息有控制信息（有时以数据形式出现）

公共环境耦合：两个多个模块通过一个公共数据环境相互作用

问题： 公共部分的改动将影响所有调用它的模块

公共部分的数据存取无法控制

复杂程度随耦合模块的个数增加而增加

内容耦合：

⏹一个模块访问另一个模块的内部数据

⏹一个模块不通过正常入口而转到另一个模块的内部

⏹两个模块有一部分程序代码重叠（只可能出现在汇编程序中）

⏹一个模块有多个入口

耦合度与软件结构

原则：尽量使用数据耦合，少用控制耦合，限制公共环境耦合的范围，完全不用内容耦合。

内聚

高内聚意味着松耦合，内聚更重要

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

内聚度与软件结构

软件模块分解的过程：

业务域分解/问题域分解

领域专家，企业战略；系统 子系统

业务功能域分解

服务，资源；子系统拆分为多个服务

技术域分解

功能需求和非功能需求，当前IT技术；业务域和业务功能域分解出的元素进行整合

在模块分解时，要注意以下几点：

低耦合高内聚：“从弱耦合入手，切断联系”

层次性：先业务后技术，循序渐进

正交原则：相互独立，职责没有重叠

抽象原则

稳定性原则

复用性原则度量

(迭代演化 面向对象)

软件度量

度量 测量 估算

软件度量

⏹软件复杂性度量

❑ 规模

❑ 文本复杂性

❑ 控制结构的复杂性

⏹ 软件可靠性度量

❑ 系统故障率

❑ 软件修复与软件有效性

❑ 软件可靠性估算

软件设计的启发规则

1.提高模块独立性

❑ 松耦合，高内聚

❑ 增加内聚，减少耦合

2.模块规模适中

3.深度/宽度/扇入/扇出适当

4.作用域在控制域内

☞控制域：模块本身以及所有直接或间接从属于它的模块的集合

☞作用域：受该模块内一个判定影响的所有模块的集合

⏹修改软件结构

❑判断点上移

❑受影响块下移

5.降低接口的复杂程度

❑接口复杂可能表明模块的独立性差

❑ 接口复杂或不一致（看起来传递的数据间无联系），是紧耦合或低内聚的征兆

6、单出单入，避免内容耦合

7、模块功能可预测

❑相同输入必产生相同输出

❑ 模块中使用全局变量可能导致不可预测

软件结构划分方式

水平划分

⏹按主要功能定义模块结构的各分支

⏹ 顶层控制模块，下层输入、处理、输出三个分支

⏹ 优点：功能分离，易修改扩充

⏹ 缺点：模块接口传递数据多，信息流的整体控制复杂化

垂直划分

⏹自顶向下逐层分布工作

⏹ 顶层模块控制，低层模块实际处理

⏹ 优点：对低层模块的修改不易引起副作用

⏹ 便于将来的维护

软件系统设计技术

面向数据流(DFD)的设计方法

面向数据结构的设计方法

原型法

结构化设计（Structured Design, SD）

基于模块化、自顶向下求精、结构化程序设计技术基础上发展起来

面向数据流的设计方法

数据流图映射到软件结构

用启发式规则对结构进行细化

面向数据流的设计方法(结构化设计SD)

软件结构设计中的图形工具

层次图(H图)-----系统结构图; ------Hierarchy

⏹ 描述软件结构，而非数据结构

⏹ 矩形框：模块

⏹ 连线：调用关系，而非组成关系

HIPO图=H图+IPO表

⏹ H图 + IPO图（Input-process-output Diagram）

⏹在H图中,除最顶层方框外,在每一个方框内加上一个编号,编号次序依次为:1.0,2.0,…；

2.1,2.2,…；3.1,3.2…

⏹对于H图中的每一个方框,有一张IPO图描述这个方框所代表模块的处理过程

结构图------模块联系图

1.结构图是软件结构设计的另一种工具, 与层次图类似。

2.它在层次图的每一个方框内注明的是模块的名字或主要功能。

3.方框之间的直线表示模块的调用关系。

4.用带注解的箭头表示模块调用过程中传递的信息

基于数据流（SD ）的设计方法

又称为结构化设计方法；

目标：给出设计软件结构的一个系统化途径；

作用：该方法定义了一些不同的“映射”，利用这些映射可以把数据流图变换成软件结构图。

另注: 通过结构化分析来得到DFD，SA是结构化需求分析、SD是结构化设计、SP是结构化实现

数据流的类型:变换流、事务流、混合型

1.变换流:所有信息都可以归结为变换流

变换流参看图形，信息沿输入通路进入系统，同时由外部形式变换成内部形式，进入系统的信息通过变换中心，经过加工处理以后再沿输出通路变换成外部形式离开软件系统。当数据流具有这些特征时，这种信息流称为变换流。

变换型的软件结构图

2.事务流：当信息流具有明显的“事务中心”时，可归结为事务流

输入通路到达一个处理T，这个处理根据输入数据的类型在若干个动作序列中选出一个来执

行。这种“以事务为中心的”的数据流，称为“事务流”。

T称为事务中心

接收输入数据；

分析每个事务以确定它

的类型；

根据事务类型选取一条

活动通路

事务型软件结构图

3.混合型，兼具两种特征。

面向数据流方法的设计过程

一定要重点看总体设计部分后面的P140左右的例题

第五．传统软件工程方法：软件设计中的详细设计

详细设计的任务

结构化程序设计

详细设计的工具

面向数据结构设计

人机界面设计

详细设计说明书

程序复杂性的度量

详细设计的任务：

1. 用伪代码、图或表等工具描绘每个模块的算法流程。

2. 确定每个模块的局部数据结构、数据库的物理结构、模块间的接口和输入输出数据

3. 为每个模块设计测试用例，使得编码阶段对具体模块的调试测试更加方便

4. 编写详细设计说明书

结构化程序设计(SP结构化实现，与结构化设计SA区分)

a) 高效率---良结构

b) 三种基本控制结构、单入单出

程序代码仅使用顺序、选择和循环这三种基本的控制结构进行连接，且每个代码块只有一个

入口和一个出口，只在检测错误和退出循环处使用非基本结构技术。

详细设计的工具

图形描述

程序流程图（ PFC）趋势是使用的人越来越少。

优点：直观清晰、广泛易学

缺点:不能逐步求精，不易表示数据结构，随意转移控制造成非结构化

盒图（ N-S）

本质上的改进是没有箭头，不能随意转移控制。

PAD图

PAD图优点:本质上的改进是层次清晰。

结构化程序

结构清晰表现程序逻辑，易读、易懂、易记

描绘数据结构

支持自顶向下、逐步求精方法的使用

PAD图 高级程序设计语言

表格描述

判定表

判定树

语言描述

过程设计语言PDL/伪码

优点:可作注释直接插在源程序中、编辑简单、PDL codes

缺点：不如“图”直观、复杂条件 — 不如判定表清晰、简单

面向数据结构的设计方法

JSD法：将Jackson方法用于大系统设计时会出现复杂的难以对付的结构冲突。

Jackson图

优点

便于表示层次结构，结构的自顶向下分解，直观，可读性好

数据入手

简化数据处理程序的设计

既能表示数据结构，也能表示程序结构

缺点

没有表示条件，不易直接把图翻译成程序，斜线不易打印

模块与独立性原则没有给予应有的重视

求提供对复杂系统设计过程的支持

改进的Jackson图

Jackson方法

1. 画数据结构的Jackson图

2. 找输入—输出数据结构的对应关系

3. 以输出数据结构为基础，导出程序结构的Jackson图

有关系的数据单元 –– 合画一个处理框

输入数据结构中余下的数据单元 –– 各画一个

输出数据结构中余下的数据单元 –– 各画一个

4. 列出所有操作、条件

5. 伪码表示程序

JACKSON的伪码表示程序

（1）顺序结构

A seq

B

C

D

A end

（2）选择结构

A select condition1

B

A or condition2

C

A or condition3

D

A end

（3）重复结构

A iter until（或while）condition

B

A end

第六章．传统软件工程方法：实现与测试。

编码

软件测试基础

测试用例设计

软件测试步骤与策略

调试

软件可靠性

一、编码

语言：

1、语言的元计算模型等价 → 功能等价

2、描述问题的方便性有差异

程序设计语言的特点及其对软件的影响：

机器求解问题的基本工具:思维方式、解题方式、人机通信的方式、理解程序的难以程度

选择程序设计语言的理想标准：模块化机制、语言特点、开发工具、独立编译机制、标准化

选择程序设计语言的实用标准：系统用户的要求、工程规模、程序员的知识、软件的应用领域

程序设计风格：

“好”程序的标准

源程序代码的逻辑简明清晰、易读易懂

遵循原则：

程序内部的文档、数据说明、语句构造尽量简单而直接、输入输出规则、效率

效率：效率主要指处理机时间和存储器容量两个方面

关于效率的三条原则

第一，效率是性能要求，应该在需求分析阶段确定效率方面的要

求；

第二，效率是靠好设计来提高的；

第三，程序的效率和程序的简单度是一致的，不要牺牲程序的清

晰性和可读性来不必要地提高效率

三个方面

程序的运行时间

存储器效率

输入输出效率

二、软件测试基础

测试目标: 为了发现程序中的错误而执行程序的过程

测试用例:一组用于测试的输入数据和预期得出的正确输出

测试方案:测试用例和用例预定要检验的功能、测试环境的规划、测试工具的选择。

测试计划:要进行的测试的组织、资源、风险、原则和进度安排等进行规定和约束

软件测试方法分：静态测试(人工检查代码，不在机器上运行)和动态测试(白盒与黑盒)。

穷尽测试：(不可能，只能选少量”最有效”做到完备)：包含所有可能情况的测试

黑盒测试 —— 功能测试

目的：

功能是否正常使用？

输入 → 正确输出？

保持外部信息的完整性？

时机：测试的后期，如：集成测试、确认测试

白盒测试

关注软件内部逻辑结构（ control structure）

测试每条逻辑通路

检查断点（ break point） 状态

测试方案对程序逻辑的覆盖程度决定测试的完全性程度

时机：测试的早期，例如：单元测试

成本高，通常对结构比较复杂的模块进行白盒测试

三、测试用例设计

黑盒法——依据对程序的需求和说明

等价划分法

边界值分析法

错误推测法

白盒法

逻辑覆盖

控制结构

测试用例是为某个特殊目标而编制的一组测试输入、执行条件、执行步骤以及预期结果等等。

黑盒测试技术

a.黑盒(功能)测试

i.等价类划分

ii.边界值分析

iii.错误推测

白盒测试技术

白盒测试技术是基于程序的内部实现结构和逻辑

寻找软件中的缺陷

覆盖准则可以作为测试停止或/和选取测试数据的

标准

软件测试的步骤与策略

第七章．传统软件工程方法：维护。

软件维护的概念和内容

软件维护的过程

软件的可维护性

软件再工程过程

一、软件维护的概念和内容

定义： 就是在软件已经交付使用之后，因为下列原因而修改软件的过程。

软件中的bug需要修复——改正性维护

软件在使用过程中，新的需求不断出现——完善性维护

商业环境在不断地变化、计算机硬件和软件环境的升级需要更新现有的系统—适应性维护

软件的性能和可靠性需要进一步改进——预防性维护

类型:

⏹校正性维护/纠错性维护（corrective maintenace）

⏹适应性维护（adaptive maintenance）

⏹完善性维护（perfective maintenance）

⏹预防性维护（preventive maintenace）

维护的代价：

⏹表面上看来合理的改错或修改不能完全满足用户的要求，就会引起用户的不满。

⏹由于维护时对软件的改动，哪怕是很小的改动，在软件中也会引入潜在的隐患或错误，使得整个软件的质量降低， 特别是不可再现错误。

⏹在开发工作期间，由于工作需要必须把软件工程师调去从事维护工作，就会对开发工作造成不良影响。

⏹软件维护会使生产率大幅度下降

维护中的问题

⏹阅读和理解问题

⏹人员问题

⏹文档资料

⏹软件的修改

⏹软件维护相对于软件系统开发工作来说则毫无吸引力

二、软件维护过程

软件维护过程定义：本质上是修改和压缩了的软件定义和开发过程。

建立维护组织

提出维护申请报告及评价

维护实施

保存维护记录

评价维护活动

三、可维护性

软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度

可维护性的决定因素

可理解性 可测试性

可修改性 可靠性

可移植性 可使用性

效率。

提高可维护性的措施

维护的副作用

☞修改软件后导致新错误的发生

⏹ 编码的副作用

⏹ 数据的副作用

文档资料的副作用

完善的设计文档资料可以减少数据的副作用。利用文档资料对数据及其用途所作的详细描述 ，提供了数据项、记录、文件及其他结构与软件模块间相关的参照表，是维护期间对数据结构进行修改的主要依据。

第七章 软件管理

软件管理内容

⏹开发计划与进度管理

⏹ 成本估算与控制

⏹ 人员管理、组织管理

⏹ 质量管理

⏹ 文档管理

软件管理原则

⏹软件生存期

⏹ 按阶段确认

⏹ 质量检查

⏹ 自顶向下SP/OOP

⏹ 职责分明

⏹ 人员少而精

⏹ 不断充实

软件管理特点

⏹知识密集，非实物性

⏹ 单品生产，开发过程不确定

⏹ 开发周期长

⏹ 内容复杂，正确性难保证

⏹ 劳动密集，自动化程度低

⏹ 软件用法繁琐，维护困难，费用高

指定软件开发计划三要素：规模 人员 交付日期

进度安排与控制

⏹软件开发进度安排，实际上就是对软件开发中各个阶段所需要的工作量，结合项目的起始时间，体现在一张编制的进度表里(甘特图)。

⏹软件开发的进度往往与人的因素有关，对人的依赖性很大。

⏹进度控制是对计划执行情况的监督、调整和修改。

成本管理与控制

⏹工时数成本管理

⏹ 开发设备的购置、使用管理

人员管理、组织管理

⏹人员管理

❑ 高技术、高知识，个人作用突出

❑ 多层次 —— 合理配备各类人员

❑ 知识更新快

❑ 流动性大 —— 保持人员相对稳定，吸引优秀人才

⏹ 组织管理

❑ 集中式 —— 易决断、易管理，难发挥多数人的积极性

❑ 非集中式 —— 发挥大家主观能动性、难管理

质量管理

⏹软件生产

❑ 分阶段

❑ 规范化

❑ 合理分工

⏹ 度量软件质量的标准

文档管理

第八章--面向对象方法学引论。

面向对象方法学概述

面向对象的概念

面向对象建模

一、面向对象方法学概述

OO和PO的本质区别是：对象是一元的还是过程是一元

OOM四要素：1对象 2类 3继承 4方法与消息

二、面向对象的概念

对象： 对象是一个程序模块，该模块由一组操作构成的集合

对象是对问题域中某个东西的抽象，这种抽象反应了系统保存有关这个东西的信息或与它交互的能力。

对象是一台自动机

对象特点

⏹数据为中心

⏹ 主动的

⏹ 数据封装

⏹ 并行性

⏹ 模块独立性好

继承的优点

⏹共享程序代码和数据结构

⏹ 减少了冗余信息

⏹ 修改方便

❑ 扩充：调用基类方法并增加代码

❑ 改变：改写同名方法

❑ 新增：定义新方法

⏹ 软件重用

OOM的主要优点

⏹与人类习惯的思维方法一致

CM

⏹ 面向过程设计，以算法为核心，送数据到函数

⏹ 数据与操作分离，不易理解

OOM

❑以object 为核心，强调对现实概念的模拟而不强调算法

❑“面向对象方法学的基本原则，是按照人们习惯的思维方式建立问题域的模型，开发出尽可能直观、自然地表现求解方法的软件系统”

❑数据和操作封装成统一体，送消息到对象

⏹ 稳定性好

Cm

❑结构依赖于功能，不稳定

❑功能需求变，易引起软件结构整体修改

Oom

❑软件系统结构根据问题域模型建立

❑以object模拟实体，实体相对稳定，故系统也相应稳定

❑需求变化不会引起结构的整体变化，只需局部性修改

⏹ 可重用性好

CM

❑过程（函数）是重用层

❑建立标准函数库来重用软构件

❑标准函数缺乏“柔性”，难以适应不同场合的不同需要

❑功能内聚的模块不是自含和独立的

OOM

❑类是重用层

❑object具有较强的自含性和独立性

❑object和class提供了理想的模块化机制和可重用的软件成分

❑继承性为OOM提供了比CM更广泛、更规范、更简单的重用机制

⏹ 可维护性好

CM

❑开发出来的软件难维护

OOM

❑稳定性好：功能需求变化不牵动全局，只需局部修改

❑容易修改

⏹Class 独立性强

⏹Inheritance和多态性(polymorphism)

❑容易理解

❑容易测试、调试

⏹ 较易开发大型软件产品，对系统的复杂性具有较强的处理能力

CM

❑组织开发人员的方法不恰当

❑强调自顶向下功能分解，限制了可重用性，重复工作，生产率低

❑好的SD将控制集中在高层模块，因而对于复杂系统、GUI的交互式系统、控制要求突出的系统，不能适应需求的变动

OOM

❑把一个大型产品看作是一系列本质上相互独立的小产品来处理

❑降低了开发的技术难度，而且也使得对开发工作的管理变得容易

❑自底向上分析和设计，自顶向下实现（继承），可重用性好

❑OOM并不是减少了开发时间，而是通过提高可重用性、可维护性，进行扩充和修改的容易程度等，从长远角度改进了软件的质量

OO建模方法

Booch的面向对象开发方法

OOA和OOD法

对象建模技术（OMT）

面向对象软件工程(OOSE)

统一建模语言UML

对象模型技术（OMT）

对象模型(OM)

结构：归纳关系 组合关系 关联关系（看书！）

动态模型（DM）

⏹基于事件共享而互相关联的一组状态图的集合

⏹表示系统瞬时的控制性质

⏹三要素

❑事件 (event)：引发 object 状态改变的控制信息（瞬时）

❑状态(status):即 object 的 attributes 所处的情形（可持续）

❑行为(action): Object 要达到某种 status 所做的操作（耗时）

功能模型(FM)

表明系统应该做什么 数据流图 IPO图

OOM的工作重点在分析阶段，确定objects

三模型关系

⏹FM：做什么（What）

⏹DM：何时做（When）

⏹OM：操作的实体（Who）

面向对象程序设计语言（OOPL）

优点

一致的表达方式

可重用性好

可维护性好

类型检查

按编译时进行类型检查的严格程度，分为强类型（每个变量（属性）必须准确属于某个类） 弱类型（仅要求每个变量（属性）隶属于一个对象）

面向对象分析（OOA）

1.提取用户需求—理解 表达 验证

2.建立三个模型—OM FM DM

面向对象设计（OOD）

两个阶段： 系统设计 对象设计

界限模糊，不严格划分

SD设计准则：模块化 抽象 信息隐藏 模块独立性

OOD设计准则：

模块化（模块—类/对象）

抽象（过程抽象 数据抽象 参数化抽象）

信息隐藏（隐藏=对象封装）

弱耦合（交互耦合尽量松 继承耦合尽量紧）

强内聚（服务内聚 类内聚 一般-特殊内聚）

可重用（代码重用 设计重用 分析重用）

可重用两方面含义：

❑尽量使用已有的类

❑ 创建新类时应考虑将来的可重用性

面向对象实现

步骤：

OOA->OOD->OOP->OOT

面向对象分析->面向对象设计-面向对象编码->面向对象测试

OO软件开发模型---喷泉模型

面向对象开发技术

OOA／OOD：依据生命周期，按部就班的方法，便以执行线索途径寻找对象。

OMT：建立在实体／关系模型基础上，并延伸到类、继承和操作。

OOSE面向对象的软件工程，该方法建立在系列模式基础上，是一个操作性很强方法。

面向对象软件工程（OOSE）

模型及关系

⏹需求模型（RM：Requirement Model）

⏹ 分析模型（AM：Analysis Model）

⏹ 设计模型（DM：Design Model）

⏹ 实现模型（IM：Implementation Model）

⏹ 测试模型（TM：Test Model）

本文来源：https://www.2haoxitong.net/k/doc/c3615324ef06eff9aef8941ea76e58fafab045eb.html