¶写在前面

• 要期末了，开始预习
• 结合老师给的期末复习提纲

第一章 软件工程学概述

¶软件危机的概念（没说考不考）

• ****软件危机****是指在计算机软件开发和维护过程中所遇到的一系列严重问题

• 鉴于软件危机的长期性和症状不明显的特点，近年来有人建议将软件危机更名为：*软件萧条*

  （ Software depression）/*软件困扰*（Software affliction）

¶软件危机的主要表现（必考）

1. 对软件开发成本和进度的估计常常不准确。开发成本超出预算，实际进度比预定计划一再拖延的现象并不罕见。

2. 用户对“已完成”系统不满意的现象经常发生。

3. 软件产品的质量往往靠不住。

4. 软件的可维护程度非常之低。

5. 软件通常没有适当的文档资料。

6. 软件的成本不断提高。在计算机总成本占比不断提高。

7. 软件开发生产率的提高赶不上硬件的发展和人们需求的增长。

¶软件危机的原因（考吧）

1. 与软件本身的特点有关

2. 由软件开发和维护的方法不正确有关

¶软件复杂性（软件危机的根本原因）的组成（考吧）

(1) 软件固有复杂性（克服不了）

(2) 管理开发过程的困难

(3) 软件可能的灵活性

(4) 表征离散系统行为的困难（克服不了）

¶软件工程的概念（必考）

• 软件工程: 是指导计算机软件****开发*和*维护*的一门*工程学科**** 是为了经济地获得可靠的且能在实际机器上高效运行的软件，而建立和使用完善的工程原理（方法）
• 把系统的、规范的、可度量的****途径****应用于软件开发、运行和维护过程，也就是把工程应用于软件。并研究以上提到的途径
• 软件工程的**目的**是提高开发质量、降低成本

¶软件工程技术两个明显特点

• 强调规范化
• 强调文档化

¶软件工程三要素

过程—决定—>方法—决定—>工具

¶软件生命周期

• 由软件定义、软件开发、运行维护（软件维护）三个时期组成

¶软件生命周期模型-瀑布模型

• 瀑布模型将软件生命周期划分为：

  • 制定计划
  • 需求分析
  • 软件设计
  • 程序编写
  • 软件测试
  • 运行维护

• 等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落

• 传统的瀑布模型过于理想化，实际的瀑布模型是带"反馈环"的

¶软件过程与过程管理

¶增量模型

第二章 可行性研究

¶可行性分析的两个观点（需要记住）

1. 可行性分析的用处

2. 可行性分析方法

【注意：

软工课程提出的可行性方法必须能够结合现实案例进行分析】

¶数据流图（应该会考吧）

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

¶加工逻辑说明（应该会考吧）

（1）结构化语言

（2）判定表

（3）判定树

第三章 需求分析

¶实体-联系图（ER）（可能会考吧）

¶为什么要数据规范化

¶范式（其实没看懂）

¶第一范式

¶第二范式

¶第三范式

¶状态转换图

¶补充（非考试）–人月神话

啊啊啊啊啊啊啊啊啊啊啊啊啊我觉得你是对的尤其是在经历了这个困难之后

¶团队需求管理方法：需求工程

¶需求分析补充知识

第四章 形式化说明技术

第五章 总体设计

¶总体设计的任务

1. 划分出组成系统的物理元素，包括程序、文件、数据库、人工过程和文档等。

2. 设计软件的结构，确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系

¶典型的总体设计过程

¶总体设计所书写的文档

对我现阶段项目设计还是挺有帮助的看起来

¶总体设计原理

• 模块化

  模块：过程、函数、子程序、宏、对象等，都可作为模块

  模块化：把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求

• 抽象

  抽出事物的本质特性（共性），而暂时不考虑它们的细节

• 逐步求精

  为了能集中精力解决主要问题而尽量推迟对问题细节的考虑

• 抽象使得设计者能够说明过程和数据，同时 却忽略低层细节

  求精则帮助设计者在设计过程中逐步揭示出低层细节

• 信息隐藏和局部化

  信息隐藏：设计和确定模块，使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的

  局部化：是指把一些关系密切的软件元素物理地放得彼此靠近

• 模块独立

  软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他模块的接口是简单的

• 模块的独立程度可以由耦合、内聚两个定性标准度量

¶模块独立性-耦合

模块之间的相对独立性

• *耦合*：是对一个软件结构内不同模块之间互连程序的度量

¶耦合分类（了解，会举例）

1. 非直接耦合
2. 数据耦合
3. 标记耦合（特征耦合）
4. 控制耦合
5. 外部耦合
6. 公共环境耦合
7. 内容耦合

¶非直接耦合

¶数据耦合

¶标记耦合(特征耦合)

¶控制耦合

¶外部耦合

• 一组模块均与同一外部环境关联(例如, I/O模块与特定的设备、格式和通信协议相关联)，它们之间便存在外部耦合
• 外部偶合必不可少,但这种模块数目应尽量少。

¶公共环境耦合（公共数据区耦合）

¶内容耦合

¶耦合原则

• 尽量使用数据耦合
• 少用控制耦合和标记耦合
• 限制公共环境耦合的范围
• 完全不用内容耦合

¶模块独立性-内聚

模块内部元素在功能上相互关联的强度

• *内聚*：模块功能强度的度量，标志着一个模块内各个元素彼此结合的紧密程度

¶内聚分类（字体加粗应该是要考吧）

1. 功能内聚
2. 信息内聚
3. 通信内聚
4. 过程内聚
5. 时间内聚
6. 逻辑内聚
7. 巧合内聚

¶功能内聚

¶信息内聚

¶通信内聚

¶过程内聚

¶时间内聚

• 时间内聚又称为经典内聚
• 这种模块大多为多功能模块，但模块的各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行
• 例如初始化模块和终止模块，系统结束模块、紧急故障处理模块等均是时间性聚合模块

¶逻辑内聚

¶巧合内聚

¶模块独立性设计目标

• 力争强内聚、弱耦合

¶耦合、内聚与模块独立性关系

• 耦合与内聚都是模块独立性的定性标准，都反映模块独立性的良好程度。
• 但耦合是直接的主导因素
• 内聚则辅助耦合共同对模块独立性进行衡量

¶关于模块独立性的启发规则

1. 改进软件结构提高模块独立性
2. 模块规模应该适中
3. 深度、宽度、扇出和扇入都应适当
4. 模块的作用域应该在控制欲之内
5. 力争降低模块接口的复杂程度
6. 设计单入口单出口的模块
7. 模块功能应该

¶软件设计过程

1. 制定规范
2. 软件系统结构的总体设计
3. 处理方式设计
4. 数据结构设计
5. 可靠性设计【▷】
6. 编写概要设计阶段的文档
7. 概要设计评审

¶1. 制定规范

• 阅读和理解软件需求说明书，确认用户要求能否实现，明确实现的条件，从而确定设计的目标，以及它们的优先顺序

• 根据目标确定最合适的设计方法

• 规定设计文档的编制标准

• 规定编码的信息形式，与硬件，操作系统的接口规约，命名规则

¶2. 软件系统结构的总体设计

基于功能层次结构建立系统

• 采用某种设计方法，将系统按功能划分成模块的层次结构
• 确定每个模块的功能
• 建立与已确定的软件需求的对应关系
• 确定模块间的调用关系
• 确定模块间的接口
• 评估模块划分的质量

¶3. 处理方式设计

• 确定为实现系统的功能需求所必需的算法，评估算法的性能
• 确定为满足系统的性能需求所必需的算法和模块间的控制方式
  • 周转时间
  • 响应时间
  • 吞吐量
  • 精度
• 确定外部信号的接收发送形式

¶4. 数据结构设计

1. 文件系统与数据库设计
   • 设计文件系统的结构及数据库的模式和子模式
   • 规划数据的完整性和安全性措施
2. 数据结构定义
   • 明确输入、输出文件的具体数据结构
   • 根据算法需求，选择合适的逻辑数据结构，并定义其操作方法
3. 模块化设计
   • 确定实现数据结构操作所需的程序模块或软件包
4. 影响范围界定
   • 清晰地限定每个数据设计决策的影响范围
5. 接口数据结构
   • 当需与操作系统或调度程序交互时，明确控制表等数据的详细结构及使用规则
6. 数据保护性设计
   • 防卫性设计：集成自动检测、报告和修正错误的功能
   • 一致性维护：确保数据类型和值域的一致性；并发处理时通过锁定机制防止数据损坏
   • 冗余性设计：采用多版本开发策略，通过比较不同实现的结果来发现并纠正错误，或使用多数决技术确定正确的输出

¶5. 可靠性设计

• 也叫做质量设计
• 在软件开发的一开始就要确定软件可靠性和其它质量指标，以使得软件易于修改和易于维护。

¶6. 编写概要设计阶段的文档

• 概要设计说明书

• 数据库设计说明书

• 用户手册

• 制定初步的测试计划

¶7. 概要设计评审

1. 可追溯性
   • 确保设计覆盖所有已确定的需求
   • 每个软件组件都应能直接追溯到至少一个具体需求
2. 接口设计
   • 内部接口与外部接口均需明确定义
   • 模块设计应遵循高内聚低耦合原则
   • 确保模块的作用范围不超过其控制范围
3. 风险评估
   • 评估设计在现有技术和预算条件下的可行性
   • 确认项目能否按时完成
4. 实用性
   • 确认设计方案是否实际可行，能够有效解决用户需求
5. 技术清晰度
   • 设计应以一种易于转化为代码的方式呈现，便于开发团队理解和实施
6. 可维护性
   • 设计时应考虑未来的维护便利性，包括但不限于文档的完整性、代码的可读性和可扩展性
7. 质量保证
   • 确认设计展现出良好的质量特性，如稳定性、性能、安全性和用户体验等
8. 方案对比
   • 考虑多种设计方案的可能性，明确比较不同方案的标准
   • 选择最符合项目目标和资源状况的方案
9. 限制评估
   • 评估项目限制条件（如技术、时间、成本）的合理性
   • 确认这些限制条件与项目需求相匹配
10. 其他具体问题
    • 文档：确保文档的完整性和准确性，涵盖设计说明、用户手册和技术文档等
    • 可测试性：设计时应考虑到测试的便捷性，包括单元测试、集成测试和系统测试等。
    • 设计过程：评估设计流程的有效性，确保每一步骤都有明确的目标和标准。

¶面向数据流的设计方法——结构化设计（字体加粗了应该会考吧）

（1）首先研究、分析和审查数据流图。

（2）然后根据数据流图决定问题的类型（*变换型和事务型*）。

（3）由数据流图推导出系统的初始结构图。

（4）利用一些启发式原则来改进系统的初始结构图，直到得到符合要求的结构图为止。

（5）修改和补充数据词典.

（6）制定测试计划。

¶变换型系统结构图

• 由输入、中心变换和输出等三部分组成

¶事务型系统结构图

• 接受一项事务，根据事务处理的特点和性质，选择分派一个适当的处理单元，然后给出结果

¶变换分析

• *变换分析是软件系统结构设计的主要方法*

¶变换分析的步骤

（1）重画数据流图；

（2）区分有效(逻辑)输入、有效(逻辑)输出和中心变换部分；

（3）进行一级分解，设计上层模块；

（4）进行二级分解，设计输入、输出和中心变换部分的中、下层模块。

¶事务分析

• 将具有事务型的DFD图导出SC图

¶设计的后处理

（1）为每一个模块写一份处理说明

（2）为每一个模块提供一份接口说明

（3）确定全局数据结构和局部数据结构

（4）指出所有的设计约束和限制

（5）进行概要设计的评审

（6）进行设计的优化(如果需要和可能的话)****

第六章 详细设计

¶人机界面设计的4个问题

¶1. 系统响应时间

• 两个重要属性：

  • 长度和易变性

• 易变性：

  • 指系统响应时间相对于平均响应时间的偏差

¶2. 用户帮助设施

• 分为：集成的和附加的两类

• 集成的帮助设施从一开始就设计在软件里面

• 附加的帮助设施是在系统建成后再添加到软件中的，在多数情况下它实际上是一种查询能力有限的联机用户手册

¶3. 出错信息处理

¶4. 命令交互

¶人机界面设计指南【PPT中列出了一些常用的具体指南，要能够判断正误】

¶1. 一般交互指南

一般交互指南涉及信息显示、数据输入和系统整体控制，因此，这类指南是全局性的，忽略它们将承担较大风险

¶2. 信息显示指南

如果人机界面显示的信息是不完整的、含糊的或难于理解的，则该应用系统显然不能满足用户的需求。

可以用多种不同方式“显示”信息：

用文字、图形和声音；

按位置、移动和大小；

使用颜色、分辨率和省略

¶3. 数据输入指南

用户的大部分时间用在选择命令、键入数据和向系统提供输入。

在许多应用系统中，键盘仍然是主要的输入介质，

但是，鼠标、数字化仪和语音识别系统正迅速地成为重要的输入手段

¶过程设计的工具【感觉对项目设计有帮助hhh】

• 程序流程图、N-S 图、PAD 图、判定表、PDL 伪代码

¶需求分析阶段

理解用户需求

确定软件功能和性能要求

• –> 判定表：
  • 用于描述复杂的业务规则，通过列出所有可能的条件和相应的动作，帮助分析人员理解需求

¶概要设计阶段

关注于系统的总体结构设计，包括模块划分、接口定义等

• –> 程序流程图：
  • 用于描述系统的整体流程，展示模块之间的调用关系和数据流向

¶【必会画】程序流程图

五种基本控制结构

(a) 选择（分支）；(b) 注释；

© 预先定义的处理；

(d) 多分支；(e) 开始或停止；

(f) 准备；(g) 循环上界限；

(h)循环下界限；(i) 虚线；

(j) 省略符；(k) 并行方式；

(l) 处理；(m) 输入输出；

(n) 连接；(o) 换页连接；

(p) 控制流

¶详细设计阶段

关注于每个模块的具体实现

• –> N-S图：
  • 一种结构化程序设计工具，用于描述模块内部的逻辑结构，避免了流程图中过多的控制流箭头
• –> PAD图：
  • 问题分析图，用于描述模块的详细处理过程，具有直观、易读的特点
• –> PDL伪代码：
  • 伪代码是一种类似于自然语言的代码描述方式，用于详细描述算法的实现步骤。