名词解释
- 软件工程：software engineering
- 软件需求：software requirements
- 软件设计：software design
- 软件过程：software process
- 开源项目：open source project
- 人工智能：artificial intelligence
- 软件部署：software deployment
- 软件架构：software construction
- 系统软件：system software
- 应用软件：application software
- 嵌入式软件：embedded software
- 分布式计算：distributed computing
- 软件测试：software test
- 软件质量：software quality
- 软件危机：software crisis
测试用(中->英)
- 软件工程
- 软件需求
- 软件设计
- 软件过程
- 开源项目
- 人工智能
- 软件部署
- 软件架构
- 系统软件
- 应用软件
- 嵌入式软件
- 分布式计算
- 软件测试
- 软件质量
- 软件危机
测试用(英->中)
- software engineering
- software requirements
- software design
- software process
- open source project
- artificial intelligence
- software deployment
- software construction
- system software
- application software
- embedded software
- distributed computing
- software test
- software quality
- software crisis
重要名词缩写
注：保证题目中出现知道什么意思即可
- DFD：Data Flow Diagram，数据流程图(数据流图)
- E-R图：Entity-Relationship Diagram，实体关系模式图
- IPO图：Input-Processing-Output，输入加工输出图
- HIPO图：Hierarchy plus Input-Processing-Output，层次结构图+输入加工输出图
- PAD：Problem Analysis Diagram，问题分析图
- PDL：Process Design Language，过程设计语言
- UML：Unified Modeling Language，统一建模语言
- CASE：Computer Aided Software Engineering，计算机辅助软件工程
- OOP：Object-oriented programming，面向对象程序程序设计
- OOD：Object-oriented Design，面向对象设计
- SWEBOK：Software Engineering Body of Knowledge，软件工程知识体系
必考简答题
软件工程特点
关注点，中心课题，变化，效率，合作，支持，替代(关中变效合支替)
- 软件工程关注大型程序构造
- 软件工程的中心课题是控制复杂性
- 软件经常变化
- 开发软件的效率非常重要
- 和谐地合作是开发软件的关键
- 软件必须有效地支持它的用户
- 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品
为什么说需求获取和分析有一定的难度
难表达，缺知识，潜在，动态
- 项目相关人员难以准确表达需求(项目相关人员通常并不真正知道希望计算机做什么，让他们清晰的表达出需要系统做什么是件困难的事，他们或许提出不切实际的要求)
- 项目相关人员表达需求中包含一些专业术语和专业知识，系统分析员必须了解需求，但是缺乏相关知识和经验(项目相关人员用自己的语言表达需求，这些语言包含很多工作中的专业术语和专业知识。系统分析员没有这些知识和经验，而他们又必须了解这些需求)
- 不同项目相关人员可能以不同方式表示不同需求，分析人员需要发现其中潜在的需求资源，并能发现需求的相容或冲突之处(不同的项目相关人员有不同的需求，可能以不同的方式表达，分析人员必须发现所有潜在的需求资源，而且能发现这些需求的相容或冲突之处)
- 分析是动态的，需求在分析过程中会发生改变(经济和业务环境决定了分析是动态的，需求在分析过程中会发生变更。个别需求的重要程度会改变，新的需求会从新的项目相关人员那里得到)
总体设计过程包含的步骤
设选推功 设数制书 审
- 设想供选择的方案
- 选择合理的方案
- 推荐最佳方案
- 功能分解
- 设计软件结构
- 数据库设计
- 制定测试计划
- 书写文档
- 审查和复审
面向数据流设计软件结构的七个基本步骤
复确 确将基 运描
- 复审并精化数据流图
- 确定数据处理流图的类型
- 确定变换中心或事务中心
- 将数据流图映射成软件模块结构图，并设计出该数据流图对应的第一层模块结构
- 基于数据流图逐步分解，设计下层模块
- 运用模块设计和优化准则优化软件结构
- 描述模块的接口
PAD图的优点
结构清，通易转，两可支
- 使用表示结构化控制结构的PAD符号所设计出来的程序必然是结构化程序
- PAD图所描绘的程序结构十分清晰
- 用PAD图表现程序，通俗易懂
- 容易将PAD图转换成高级语言源程序
- PAD图可用于表示程序逻辑，也可用于描绘数据结构
- PAD图的符号支持自顶向下，逐步求精的方法
必考应用题
NS盒图(6.3.2)和程序流程图的转化
画程序流程图时注意写开始和结束两个方框要画上，是占分数的
循环结构左侧对应while语句，先判断再执行，对应到程序流程图就是先画一个菱形块再画矩阵快
右侧对应do-while语句，先执行再判断，对应程序流程图就是先画一个矩形块再画一个菱形块
环形复杂度计算
可能先来一步把程序流程图转换为数据流图，然后才是环境复杂度的计算
- 程序流程图转换为数据流图方法：
- 把顺序处理序列合并为一个结点
- 如果顺序处理序列下面有菱形判断框也一同合并为一个结点
- 如果一个菱形判断框不能和顺序处理序列合并则自己成为一个结点
- 需要把汇点(多入单出)也当作一个结点，例如下图中的9号点
- 不需要考虑开始结点和结束结点 示例： 程序流程图 流图
- 计算环形复杂度
- 环形复杂度$V(G)$等于流图中线性无关的区域数
- 环形复杂度$V(G) = E - N + 2$，$E$条边，$N$个点
- 环形复杂度$V(G) = P + 1$，$P$个判定结点
判定结点不需要管入度，只需要保证出度$>=2$即可，因为入度即使很多可以等效为1。注意判定结点不等同于谓词结点，谓词结点严格要求出度为2 注意：需要在图上进行标记，写出3个计算公式，最后进行计算
选择填空判断知识点
软件定义
- 指令的集合，通过执行这些指令来满足预期的特征，功能和性能需求
- 数据结构，使得程序可以合理的利用信息
- 文档描述，用来描述程序操作和使用
软件特点
- 软件是逻辑产品，不同于物理产品。软件更新复杂，硬件替换简单
- 硬件会磨损，软件不会磨损但会失效
- 软件本身复杂，设计开发复杂，人员要求高，成本进度难控制，风险大，维护困难
软件危机定义
软件开发和维护过程中遇到的一系列严重问题
软件危机的原因
- 客观原因：软件产品开发的复杂度和难度随软件规模呈指数级增长
- 主观原因：软件开发人员缺乏工程性，系统性的方法论
软件工程方法学三要素
- 方法
- 工具
- 过程
软件生命周期
- 软件定义
- 问题定义
- 可行性研究
- 需求分析
- 软件开发
- 总体设计
- 详细设计
- 编码
- 单元测试
- 综合测试
- 运行维护(持久满足用户需求)
瀑布模型
也称线性顺序模型，适用于用户需求明确，完整，无重大变化的项目
- 优点 文档驱动的模型
- 缺点
- 实际项目很少按照该模型给出的顺序进行
- 用户难以清楚给出所有需求
- 用户必须有耐心等待系统开发完成
喷泉模型
- 定义：是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程 主要用于支持面向对象开发过程，体现了软件创建所固有的迭代和无间隙的特征
可行性研究的目的
用最小的代价在尽可能短的时间内确定问题是否能够解决
可行性研究的内容
- 技术可行性
- 经济可行性
- 操作可行性
- 社会可行性(法律可行性)
- 抉择
几个图
- 系统流程图
- 概括地描述物理系统
- 基本思想：用图形符号以黑盒子形式描述系统各个部件
- 表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程
- 是物理数据流图，不是程序流程图
-
程序流程图 数据结构中涉及到的那一种，一种描述程序运行的控制结构流程和指令执行情况的有向图
-
数据流图(数据流程图)
- 描绘信息流和数据从输入移动到输出过程中经受的变换，是系统逻辑功能的图形表示
- 数据流图中没有物理部件，只描绘数据在软件中流动和被处理的逻辑过程
- 设计数据流图时只需考虑系统需要完成哪些逻辑功能，不需考虑如何实现这些功能
数据字典
- 作用：对于数据流图中出现的所有被定义的图形元素，在字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释，就是用来解释数据流图中出现的图形元素
- 数据流图和数据字典构成系统的逻辑模型
- 4类元素：数据流，数据流分量(数据元素)，数据存储，处理
需求分析
定义
- 需求分析是软件定义时期的最后一个阶段
- 基本任务不是确定系统怎样完成工作，而是确定系统需要完成哪些工作，不是
how，而是what。对目标系统提出完整，准确，清晰，具体的要求 - 在需求分析结束之前，由系统分析员写出软件需求规格说明书
具体任务
确分导修
- 确定对系统的综合要求
功性可出接约
- 功能需求
- 性能需求
- 可靠性和可用性需求
- 出错处理需求
- 接口需求
- 约束，逆向需求
- 分析系统的数据要求
- 导出系统的逻辑模型
- 修正系统开发计划
与用户沟通获取需求方法
访面简快
- 访谈（情景分析）
- 面向数据流自顶向下求精
- 简易的应用规格说明技术
- 快速建立软件原型
需求分析建立的3种模型及其工具
- 数据模型 ---- ER图 ---- 信息域
- 功能模型 ---- 数据流图 ---- 软件功能
- 行为模型 ---- 状态/活动图 ---- 软件行为
ER图
用来建立数据模型(一种面向问题的数据模型，是按照用户的观点对数据建立的模型，描述了从用户角度看到的数据，反映了用户的现实环境，与在软件系统中的实现方法无关)的工具
数据模型中包含的3种相互关联的信息：
- 数据对象 (每一个Entity都是一个数据对象)
- 数据对象属性 (Entity里面写的东西就是它的属性)
- 数据对象彼此相互连接的关系 (一条线就是一种关系)
状态转换图
描述系统状态和引起系统状态改变的事件来表示系统的行为
验证软件需求正确性的4个方面
一完现有
- 一致性
- 完整性
- 现实性
- 有效性
总体设计基本原理(5点)
模抽逐信模
- 模块化
- 抽象
- 逐步求精
- 信息隐蔽和局部化
- 模块独立 模块独立重要原因
- 有效的模块化软件容易开发
- 独立的模块容易测试和维护
深度，宽度，扇出，扇入
- 深度：软件结构中控制的层数
- 宽度：软件结构中同一个层次上的模块总数最大值
- 扇出：一个模块直接控制(调用)其他模块的数量
- 扇入：一个模块被其它模块调用的数目
模块独立程度
模块独立程度由2个定性标准度量：耦合 + 内聚
耦合
耦合即软件结构内不同模块彼此之间相互依赖的紧密程度
从上到下，程度依次升高 数控公内
- 数据耦合
- 控制耦合
- 公用耦合
- 内容耦合 尽量使用数据耦合，少用控制耦合，限制公用耦合，不用内容耦合
内聚程度排序
内聚指一个模块内部各元素彼此结合的紧密程度 是衡量一个模块内部组成部分间整体统一性的度量
从上到下，程度依次降低 功顺通过时逻偶
- 功能内聚
- 顺序内聚
- 通信内聚(数据内聚)
- 过程内聚
- 时间内聚(瞬时内聚)
- 逻辑内聚
- 偶然内聚
力求高内聚，少用中内聚，不用低内聚
数据流
面向数据流设计将得到以数据流图为基础的软件模块结构图
- 分类：变换型 和 事务型
- 变换型数据流图：具有明确的输入，变换和输出界面的数据流图
- 事务型数据流图：存在一个事务中心，将输入分离成若干个发散的数据流
详细设计遵循原则(目标)
确定如何具体实现系统，即how
仍是设计阶段，不是编码，因此不会具体编写程序
详细设计的结果决定最终程序代码的质量
结构化思想
-
设计方法：自顶向下，逐步求精
-
控制结构：单入口单出口
-
优点：
-
提高软件开发工程的成功率和生产率
-
系统有清晰的层次结构，容易阅读理解
-
程序逻辑结构清晰，有利于程序正确性证明
-
单入单出的控制结构，容易诊断纠正
-
模块化可以使得软件重用
- 5种结构
- 经典：顺序 和 IF_THEN_ELSE 和 DO_WHILE
- 扩展：DO_CASE 和 DO_UNTIL
- 修正：BREAK
程序流程图3种节点
- 函数结点 单入单出
- 谓词结点 一个入口，两个出口(单入双出)
- 汇点 $>=2$个入口，1个出口(多入单出)
软件测试目的
检验软件系统是否满足规定的需求 或 弄清实际结果与预期结果之间的差别
- 测试是为了发现程序中的错误而执行程序的过程
- 好的测试方案极有可能发现尚未发现的错误
- 成功的测试是发现了尚未发现的错误
软件测试的流程
- 模块测试
- 子系统测试
- 系统测试
- 验收测试(拿实际数据跑)
- 平行运行(就是对拍)
黑盒测试和白盒测试区别
- 黑盒测试 已知软件应该具有的功能了，需要检测每个功能能否正常使用，即功能检测
- 白盒测试 已知软件内部工作过程，需要检测软件是否按照规格说明书的规定正常进行，相当于在测试内部结构，即结构测试
集成测试
- 非渐增式测试 每个模块单独测试，最后把所有模块装配在一起
- 渐增式测试
每次增加一个模块进行测试，直到所有模块测试完成
- 自顶向下
- 深度优先策略
- 宽度优先策略
- 自底向上
- 自顶向下
