软件工程基本概念
(1)软件:是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。 (2)软件工程:开发、运行、维护和修复软件的系统方法。
(3)软件工程方法学:通常把在软件生命周期全过程中使用的一整套技术的集合，称为软件工程方法学。 (4)软件开发模型:是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。
(5)系统流程图:描绘物理系统的一种传统工具，它的基本思想是用图形符号以黑盒子形式描绘系统里面的每一个部件（程序、文件、数据库、表格、人工过程等）。
(6)数据流图(Data Flow Diagram ,DFD):描绘系统的一种逻辑模型，图中没有任何具体的物理元素，只是描绘信息在系统中流动和处理的情况。
(7)数据字典(Data Dictionary, DD): 对于数据流图中所出现的所有被命名的图形元素作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。 (8)模型:对对象系统的形式化的特征抽象，概括性或近似地表示
(9)结构化分析方法(Structured Analysis, SA):70年代中期提出的一种面向数据流、自顶向下、逐步求精进行需求分析的方法。
(10)模块(module):数据说明和可执行语句等程序对象的集合，每个模块单独命名并且可以通过名字对模块进行访问。
(11)模块化设计(modular design):把大型软件按照规定的原则划分为一个个较小的、相对独立但又相关的模块的设计方法。
(12)深度:软件中指模块的最大层数。
(13)扇出:软件中指一个模块直接调用的模块数。 (14)扇入:软件中指调用一个给定模块的模块个数。 (15)宽度:软件中指同一层最大模块数。
(16)信息隐藏(Information Hiding):模块内部的数据与过程，应该对不需要了解这些数据与过程的模块隐藏起来。
(17)内聚:用于衡量一个模块内部各个元素间彼此结合的紧密程度。 (18)耦合:用于衡量不同模块彼此间互相依赖（连接）的紧密程度。
(19)层次图:也称H 图，是在总体设计阶段最常使用的图形工具之一，它常用于描绘软件的层次结构。层次图中的每个方框代表一个模块，方框间的连线表示模块间的调用关系。
(20)结构化设计:一种设计程序的技术，它采用自顶向下逐步求精的设计方法和单入口、单出口的控制结构。
（21) 编码：就是把软件设计的结果翻译成计算机可以“理解”的形式——用某种程序设计语言书写的程序。
（22) 测试:为了发现程序中的错误而执行程序的过程。
(23)白盒测试:也称结构测试/开盒测试/玻璃盒测试，是一种基于覆盖的测试方法；根据被测程序的逻辑结构设计测试用例，检验产品内部动作是否按照规规格说明书的规定正常进行。
(24)黑盒测试:从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例，是根据程序外部特征进行测试。
25) 穷尽测试:包含所有可能情况的测试。
(26)模块测试:又称单元测试，发现编码和详细设计的错误。
(27)验收测试:由用户参与、使用实际数据来发现需求说明书中的错误的测试。
(28)平行运行:同时运行新开发出来的系统和将被取代的旧系统，以便比较新旧两个系统的处理结果。 (29) Alpha测试:用户在开发者的场所进行，并在开发者的指导下进行； (30) Beta测试:在一个或多个用户场所进行，开发者不在现场。 (31)软件维护:为了改正错误或满足新的需要而修改软件的过程。 (32)纠错性维护:针对原有错误而进行的维护过程。 (33)适应性维护:针对硬件发展而进行的维护过程。 (34)完善性维护:针对功能扩展而进行的维护过程。 (35)预防性维护:针对未来发展而进行的维护过程。
(36)等价类:每类中的一个典型值在测试中的作用与这一类中所有其他值的作用相同。 (37)对象:具有相同状态的一组操作的集合。
(38)消息:要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明。对象:对问题域中某个东西的抽象，这种抽象反映了系统保存有这个东西的信息或与它交互的能力。对象是对属性值和操作的封装。
(39)类:对具有相同属性和行为的一个或多个对象的描述。 (40)实例:由某个特定的类所描述的一个具体的对象。
(41)消息:要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明。 (42)方法:对象所能够执行的操作。也就是类中所定义的服务。
(43)属性:类中所定义的数据，它是对客观实践实体所具有的性质的抽象。
(44)封装:在面向对象的程序中，把数据和实现操作的代码集中起来放在对象的内部，称之为封装。 (45)继承:指能够直接获得已有的性质和特征，而不必重复定义它们。 (46)多态性:子类对象可以象父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对象。
软件工程常用工具与模型
(1)瀑布模型：
定义：将软件生存周期的各项活动规定为依照固定顺序连接的若干阶段工作，形如瀑布流水，最终得到软件产品。 实例：
(2)系统流程图 定义：系统流程图是描绘物理系统的传统工具，它的基本思想是用图形符号以黑盒子形式描绘系统里面的每一个部件（程序、文件、数据库、表格、人工过程等）。
(3)数据流图
定义：英文Data Flow Diagram ，简称 DFD 。DFD 是一种描述逻辑模型的图形工具，表示数据在系统内的变化。图中没有任何具体的物理元素，只是描绘信息在系统中流动和处理的情况。DFD 从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。它由数据流、加工、文件和数据流的源点和终点构成。
(4)数据字典
定义：英文Data Dictionary，简称DD 。是一种描述逻辑模型的工具。它对于数据流图中所出现的所有被命名的图形元素作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。DD 的内容包括：图形元素的名字、别名或编号、分类、描述、定义、位置等。 实例：《客房管理系统》字典建模
预订请求＝客人数据＋住宿期限+客房类别
客人数据＝客人姓名+地址+身份证号码+[护照号码] +支付方式 身份证号码=十进制15{数字}18 护照号码＝字母 + 8{数字}8 字母＝“A”…“Z”
十进制数字＝“0”…“9” (5) 实体—联系图
定义：实体—联系图(ERA，Entity-Relationship Approach)或实体联系图（ERD ，Entity- Relationship Diagram）。ERD 描绘了系统的数据关系 。分析实体联系图有助于对业务或系统数据组成的理解和交互，并暗示产品将有必要包含一个数据库。 ER
模型三要素：数据对象、属性和联系。
(6)状态转换图 定义：状态转换图简称状态图。通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。它由1个初态/初始状态、0~N个终态/最终状态和若干个中间状态组成。
(7)层次方框图
定义：用属性结构的一系列多层次的矩形框描述数据的层级结构。
(8)IPO图
定义：输入、处理、输出图的简称。是IBM 公司发展完善的一种图形工具
。
(9)层次图
定义：层次图（也称H 图）是在总体设计阶段最常使用的图形工具之一，它常用于描绘软件的层次结构。它矩形代表一个模块，连线表示调用关系，适于在自顶向下设计软件的过程中使用；与层次方框图类似。
(10) HIPO图 定义：HIPO:是IBM 公司发明的“层次图加输入/处理/输出图的缩写；为了能使HIPO 图具有可跟踪性，在H 图里除了最顶层的方框之外，每个方框都加了编号；和H 图中的每个方框相对应，有一张IPO 图描述这个方框代表的模块的处理过程。IPO 图能够方便地描述数据输入、数据处理和数据输出之间的关系。
(12)结构图
定义：Yourdon 提出的一种软件结构设计工具。一个方框/矩形代表一个模块，箭头连线/直线表示调用关系，带有注释的箭头表示模块调用过程中来回传递的信息。
(13)程序流程图
定义：也称为程序框图；箭头代表控制流而不是数据流；20 世纪70 年代的主要工具；趋势是越来越多的人不再使用。它的主要缺点包括：不是逐步求精的好工具；用箭头代表控制流，可以随意转移控制；不宜表示数据结构。
(14)盒图（N-S 图）
定义：由Nassi 和Shneiderman 提出的一种程序设计方法；其主要特点包括：[1] 功能域明确；[2] 不可以随意转移；[3] 容易确定局部和全程数据的作用域；[4]容易表达嵌套关系。实例：
(15)PAD图
定义：PAD 图是一种问题分析图(ProblemAnalysis Diagram)，1973年由日本日立公司提出。其主要特点包括：
[1] 必是结构化程序； [2] 程序结构清晰；
[3] 易读、易懂、易记；
[4] 支持自顶向下，逐步求精的方法；
[5] 既可以表示程序逻辑，也可以表示数据结构。
(16)判定表
定义：判定表在某些数据处理中，某数据流图的加工需要依赖于多个逻辑条件的取值，就是说完成这一加工的一组动作是由于某一组条件取值的组合而引发的。这时使用判定表来描述比较合适。判定表通常由四部分组成，即：条件桩、操作桩、条件条目和操作条目。
(17)判定树
定义：判定树是判定表的变种，它也能清晰地表达复杂的条件组合与所对应的操作之间的关系。判定树的优点在于它无须任何说明，一眼就能看出其含义，易于理解和使用。
(18)过程设计语言（PDL ）
定义：也称“伪码 ”，用正文形式表示数据和处理的过程的工具。其具有如下特点：
[1] 具有关键字固定语法； [2] 自然语言表述； [3] 数据说明； [4] 提供接口模式。 (19)用例图 定义：用例图是被称为参与者的外部用户所能观察到的系统共呢概念的模型图；用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用；用例图的用途是列出系统中的用例和参与者，并显示哪个参与者参与了那个用例的执行。
(20) 活动图
定义：活动图描述了活动发生的顺序。其图形表示规则如下：
圆角矩形表示方框中的活动； 矩形表示工作流影响的对象；
实心圆表示工作流开始的开始状态； 双层圆表示工作流结束的结束状态； 菱形表示决策点；
垂直泳道表示工作流中的不同参与者及相关活动。
(21)顺序图
顺序图表示对象之间传送消息的时间顺序。 图形表示法：
垂直线，即生命线，表示在整个交互过程中一个对象的生命周期。 生命线之间的箭头连线表示消息。 箭头连线上的文字表示相关的事件。
(22)协作图
协作图对在一次交互中有意义的对象和对象间的链建模。
图形表示法：
直线表示对象之间直接通信关系。
附在直线上箭头表示消息传送方向。
箭头旁文字表示消息及消息编号。
(23) 类图
以类为中心组织起来的图形，用以表示软件系统中各类之间的相互关系。
图形表示法：
矩形框表示类图中的类。
连线表示类之间的关系。
类之间的关系有关联、 聚集、泛化和依赖。
(24)状态图
状态图是一个类对象所经历的所有历程的模型图。状态图有对象的各个状态和连接这些状态的变迁组
成。
图形表示法：
圆角矩形表示状态；
带箭头的直线表示对象从一种状态变迁到另一种状态的过程。
附在直线上的信息表示触发对象状态变迁的条件。
(25)组件图
组件图表示了系统中的各种组建。
组件可以是源代码、二进制文件或可执行文件。
逻辑视图与组件视图之间存在着映射关系。
组件可以与公开的任何接口一起显示。
(26)部署图
用来描述位于节点实例上的运行组件的安排，描述系统的实际物理结构。
图形表示法：
立方体表示节点，节点可以是一组运行的资源，如计算机、设备或存取器等。
直线表示节点之间连接方式。
软件工程原理/技术/方法
1、软件工程的本质特性
(1) 软件工程关注于大型程序的构造；
(2) 软件工程的中心课题是控制复杂性；
(3) 软件经常变化；
(4) 开发软件的效率非常重要；
(5) 和谐地合作是开发软件的关键；
(6) 软件必须有效地支持它的用户
(7) 在软件工程领域中是由具有一种文化背景的人代替具有另一种文化背景的人创造产品。
2、软件工程的七条基本原理
(1)用分阶段的生命周期计划严格管理；
(2)坚持进行阶段评审；
(3)实行严格的产品控制；
(4)采用现代程序设计技术；
(5)结果应能够清楚地审查；
(6)开发小组的人员应少而精；
(7)承认不断改进软件工程实践的必要性；
3、软件生存期的阶段划分
(1)可行性研究与计划
(2)需求分析
(3)总体设计
(4)详细设计
(5)实现(编码)
(6)集成测试
(7)确认测试
(8)使用和维护
4、传统方法学
(1)传统方法学夜车概念生命周期方法学或结构化范型；
(2)采用结构化技术(分析/设计/实现) ，来完成软件开发各项任务；
(3)把软件生命周期的全过程依次划分为若干阶段。本质是面向过程的开发。
(4)每个阶段对立完成，各阶段有严格的开始和结束标准。前一阶段结束，才能开始下一个阶段。
(5)在相当长的一段时间内仍有生命力。
5、面向对象的方法学
面向对象方法以数据为主线，把是数据和对数据的操作紧密地结合起来的方法。
(1)把对象作为融合数据机在数据上的操作行为的统一的软件构件。
(2)把所有对象划分成类。
(3)按照父类与子类的关系，把若干个相关类组成一个层次结构的系统。
(4)对象彼此间仅能通过发送消息互相联系。
6、可行性研究的主要内容
一般来说，至少要从以下三个方面开展研究 ：
(1) 技术可行性：使用现有技术能实现这个系统吗？
(2) 经济可行性：这个系统的经济效益能超过它的开发成本吗？
(3) 操作可行性：系统的操作方式在这个用户组织内行得通吗？
此外，还应从法律、社会效益等更广泛的方面研究每种解法的可行性。
7、可行性研究过程
(1) 复查系统规模和目标；
(2) 研究目前正在使用的系统；
(3) 导出新系统的高层逻辑模型；
(4) 进一步定义问题；
(5) 导出和评价供选择的解法；
(6) 推荐行动方针；
(7) 草拟开发计划；
(8) 书写文档提交审查。
8、成本/效益分析内容
(1)成本估计
代码行技术
任务分解技术
自动估计成本技术
(2) 成本/效益分析的方法
货币的时间价值
投资回收期
纯收入
投资回收率
9、各种需求分析方法所应遵循的准则
(1)必须理解并描述问题的信息域，建立数据模型；
(2)必须定义软件应完成的功能，建立功能模型；
(3)必须描述作为外部事件结果的软件行为，建立行为模型；
(4)必须对描述信息、功能和行为的模型进行分解，用层次的方式展开细节。
10、需求分析的具体任务
(1)确定软件系统的综合需求；
(2)分析系统的数据需求：数据模型/信息模型E-R/层次方框图 ；
(3)导出软件系统的逻辑模型：数据流图/E-R图/状态转换图/数据字典/算法；
(4)修正系统开发计划；
(5)验证软件需求分析的正确性；
(6)编写软件需求规格说明书。
11、系统的综合要求/需求
(1) 功能需求：系统必须提供的服务
(2) 性能需求：系统必须满足的定时约束或容量约束等。
(3) 可靠性和可用性需求。
(4) 出错处理需求：系统对环境错误应该怎样响应。
(5) 接口需求：系统与它的环境通信格式要求。
(6) 约束：设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件：精度/工具/语言/设计/标准/平台。
12、需求获取的常用方法
(1)访谈
(2)面向数据流自顶向下求精
(3)简易的应用规格说明技术
(4)快速建立软件原型
13、总体设计过程
1 .设想供选择的方案
2 .选取合理的方案
3 .推荐最佳方案
4 .功能分解
5. 设计软件结构
6. 设计数据库
7. 制定测试计划
8. 书写文档
9. 审查和复审
14、软件设计中的常用启发规则
(1) 改进软件结构提高模块独立性；
(2) 模块规模应该适中；
(3) 深度、宽度、扇出、扇入都应适当；
(4) 模块的作用域应该在控制域之内；
(5) 力争降低模块接口的复杂程度；
(6) 设计单入口单出口的模块；
(7) 模块功能应该可以预测。
15、耦合设计原则
(1)尽量使用数据耦合
(2)少用控制耦合
(3)限制公共环境耦合范围
(4)完全不用内容耦合
16、内聚设计原则
(1)力求高内聚；
(2)中等内聚也可以采用；
(3)低内聚不要用。
17、面向数据流的设计方法
(1)系统结构特征可归纳为两种典型形式
变换型结构
事务型结构
(2)数据流图可分为两种类型
变换型数据流
事务型数据流
(3)面向数据流设计方法的设计步骤
(1)精化DFD 。
(2)确定DFD 类型。
(3)把DFD 映射到系统模块结构，设计出模块结构的上层。
(4)基于DFD ，逐步分解高层模块，设计出下层模块。
(5)根据模块独立性原理，精化模块结构。
(6)模块接口描述
18、人机界面设计中经常遇到的4个设计问题
(1)系统响应时间
(2)用户帮助设施
(3)出错信息处理
(4)命令交互
19、人机界面设计一般交互指南
(1) 保持一致性
(2) 提供有意义的反馈
(3)在执行有较大破坏型的动作之前，要求用户确认
(4)允许取消绝大多数操作
(5)减少在两次操作之间必须记忆的信息量
(6)提高对话、移动和思考的效率
(7)允许犯错误
(8)按功能对动作分类，并据此设计屏幕布局
(9)提供对用户工作内容敏感的帮助设施
(10)用简单动词或动词短语作为命令名
20、人机界面设计信息显示指南
(1)只显示于当前工作内容有关的信息
(2)不要用数据淹没用户
(3)使用一致的标记、标准的缩写和可与之的颜色
(4)允许用户保持可视化的语境
(5)产生有意义的出错信息
(6)使用大小写、缩进和文本分组以帮助理解
(7)使用窗口分隔不同类型的信息
(8)使用模拟显示方式显示信息
(9)高效率地使用显示屏
21、数据输入指南
(1)尽量减少用户的输入动作
(2)保持信息显示和数据输入之间的一致性
(3)允许用户自定义输入
(4)交互应该是灵活的
(5)使在当前语境中不适用的命令不起作用
(6)让用户控制交互流
(7)对所有输入动作都提供帮助
(8)消除冗余的输入
22、选择一种语言的标准是什么？
(1)系统用户的要求：用户知识和用户环境要求；
(2)可以使用的编译程序：软件平台要求；
(3)可以得到的软件工具：软件条件要求；
(4)工程规模：实践要求；
(5)程序员的知识：方便性要求；
(6)软件可移植性要求：造价要求；
(7)软件的应用领域：对象特点要求。
23、编码风格应该遵循的规则
(1) 程序内部的文档化：
指编码时适当选择标识符的名字
适当安排注释
注重程序的整个组织形式
(2) 数据说明
(3) 语句构造
(4) 输入/输出
24、软件测试准则
(1)所有测试都应该能追溯到用户需求。
(2)应该远在测试开始之前就制定出测试计划。
(3)把Pareto 原理应用到软件测试中。
Pareto 原理：测试发现的错误中80%很可能是由程序中20%的模块造成的。
(4) 应该从“ 小规模” 测试开始，并逐步进行“ 大规模”测试。
(5)穷举测试是不可能的。
(6)应该由第三方从事测试工作。
25、划分等价类的原理
每类中的一个典型值在测试中的作用与这一类中所有其他值的作用相同。
划分等价类的标准：
覆盖
不相交
代表性
26、划分等价类的几条启发式规则：
(1)如果规定了输入值的范围则可划分出一个有效的等价类(输入值在此范围内), 两个无效的等价类（输入值小于最小值或大于最大值）；
(2)如果规定了输入数据的个数，则类似地也可以划分出一个有效的等价类和两个无效的等价类；
(3)如果规定了输入数据的一组值，而且程序对不同输入值做不同处理，则每个允许的输入值是一个有效的等价类，此外还有一个无效的等价类（任一个不允许的输入值）；
(4)如果规定了输入数据必须遵循的规则，则可以划分出一个有效的等价类（符合规则）和若干个无效的等价类（从各种不同角度违反规则）。
(5)如果规定了输入数据为整型，则可以划分出正整数、零和负整数等三个有效类；
(6)如果程序的处理对象是表格，则应该使用空表，以及含一项或多项的表。
27、自顶向下结合测试法
自顶向下的结合方法是一个日益为人们广泛采用的组装软件的途径。
由下述四个步骤完成：
第一步，对主控制模块进行测试，测试时用存根程序代替所有直接附属于主控制模块的模块；
第二步，根据选定的结合策略（深度优先或宽度优先）每次用一个实际模块代换一个存根程序（新结合进来的模块往往又需要新的存根程序）。
第三步，在结合进一个模块的同时进行测试；
第四步，为了保证加入模块没有引进新的错误，可能需要进行回归测试，全部或部分地重复以前做过的测试；
自顶向下的结合策略能够在测试的早期对主要的控制或关键的抉择进行检验；
28、自底向上结合测试法
用下述步骤可以实现自底向上的结合策略把低层模块组合成实现某个特定的软件子功能的族； 写一个驱动程序（用于测试的控制程序），协调测试数据的输入和输出；
对由模块组成的子功能族进行测试；
去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能族。
29、白盒测试
也称结构测试、也称开盒测试或玻璃盒测试；
基于覆盖的测试；
根据被测程序的逻辑结构设计测试用例；力求提高测试覆盖率；
检验产品内部动作是否按照规格说明书的规定正常进行。
主要用户与测试过程的早期。
30、逻辑覆盖
一系列测试过程的总称；
逻辑覆盖包括：
语句覆盖；
判断覆盖；
条件覆盖；
判定／条件覆盖；
条件组合覆盖
点覆盖；
边覆盖；
路径覆盖；
31、语句覆盖:使程序中每个语句至少执行一次。
32、判定覆盖(分支覆盖):使每个判定的真假分支都至少执行一次。
33、条件覆盖:使每个判定的每个条件的可能取值至少执行一次
34、判定/条件覆盖:选取足够多的测试用例，使判断中的每个条件的所有可能取值至少执行一次。选
取足够多的测试用例，同时每个判断本身的所有可能判断结果至少执行一次。
35、条件组合覆盖:使每个判断表达式中条件的各种可能组合至少出现一次。
软件工程基本概念
(1)软件:是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。 (2)软件工程:开发、运行、维护和修复软件的系统方法。
(3)软件工程方法学:通常把在软件生命周期全过程中使用的一整套技术的集合，称为软件工程方法学。 (4)软件开发模型:是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。
(5)系统流程图:描绘物理系统的一种传统工具，它的基本思想是用图形符号以黑盒子形式描绘系统里面的每一个部件（程序、文件、数据库、表格、人工过程等）。
(6)数据流图(Data Flow Diagram ,DFD):描绘系统的一种逻辑模型，图中没有任何具体的物理元素，只是描绘信息在系统中流动和处理的情况。
(7)数据字典(Data Dictionary, DD): 对于数据流图中所出现的所有被命名的图形元素作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。 (8)模型:对对象系统的形式化的特征抽象，概括性或近似地表示
(9)结构化分析方法(Structured Analysis, SA):70年代中期提出的一种面向数据流、自顶向下、逐步求精进行需求分析的方法。
(10)模块(module):数据说明和可执行语句等程序对象的集合，每个模块单独命名并且可以通过名字对模块进行访问。
(11)模块化设计(modular design):把大型软件按照规定的原则划分为一个个较小的、相对独立但又相关的模块的设计方法。
(12)深度:软件中指模块的最大层数。
(13)扇出:软件中指一个模块直接调用的模块数。 (14)扇入:软件中指调用一个给定模块的模块个数。 (15)宽度:软件中指同一层最大模块数。
(16)信息隐藏(Information Hiding):模块内部的数据与过程，应该对不需要了解这些数据与过程的模块隐藏起来。
(17)内聚:用于衡量一个模块内部各个元素间彼此结合的紧密程度。 (18)耦合:用于衡量不同模块彼此间互相依赖（连接）的紧密程度。
(19)层次图:也称H 图，是在总体设计阶段最常使用的图形工具之一，它常用于描绘软件的层次结构。层次图中的每个方框代表一个模块，方框间的连线表示模块间的调用关系。
(20)结构化设计:一种设计程序的技术，它采用自顶向下逐步求精的设计方法和单入口、单出口的控制结构。
（21) 编码：就是把软件设计的结果翻译成计算机可以“理解”的形式——用某种程序设计语言书写的程序。
（22) 测试:为了发现程序中的错误而执行程序的过程。
(23)白盒测试:也称结构测试/开盒测试/玻璃盒测试，是一种基于覆盖的测试方法；根据被测程序的逻辑结构设计测试用例，检验产品内部动作是否按照规规格说明书的规定正常进行。
(24)黑盒测试:从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例，是根据程序外部特征进行测试。
25) 穷尽测试:包含所有可能情况的测试。
(26)模块测试:又称单元测试，发现编码和详细设计的错误。
(27)验收测试:由用户参与、使用实际数据来发现需求说明书中的错误的测试。
(28)平行运行:同时运行新开发出来的系统和将被取代的旧系统，以便比较新旧两个系统的处理结果。 (29) Alpha测试:用户在开发者的场所进行，并在开发者的指导下进行； (30) Beta测试:在一个或多个用户场所进行，开发者不在现场。 (31)软件维护:为了改正错误或满足新的需要而修改软件的过程。 (32)纠错性维护:针对原有错误而进行的维护过程。 (33)适应性维护:针对硬件发展而进行的维护过程。 (34)完善性维护:针对功能扩展而进行的维护过程。 (35)预防性维护:针对未来发展而进行的维护过程。
(36)等价类:每类中的一个典型值在测试中的作用与这一类中所有其他值的作用相同。 (37)对象:具有相同状态的一组操作的集合。
(38)消息:要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明。对象:对问题域中某个东西的抽象，这种抽象反映了系统保存有这个东西的信息或与它交互的能力。对象是对属性值和操作的封装。
(39)类:对具有相同属性和行为的一个或多个对象的描述。 (40)实例:由某个特定的类所描述的一个具体的对象。
(41)消息:要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明。 (42)方法:对象所能够执行的操作。也就是类中所定义的服务。
(43)属性:类中所定义的数据，它是对客观实践实体所具有的性质的抽象。
(44)封装:在面向对象的程序中，把数据和实现操作的代码集中起来放在对象的内部，称之为封装。 (45)继承:指能够直接获得已有的性质和特征，而不必重复定义它们。 (46)多态性:子类对象可以象父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对象。
软件工程常用工具与模型
(1)瀑布模型：
定义：将软件生存周期的各项活动规定为依照固定顺序连接的若干阶段工作，形如瀑布流水，最终得到软件产品。 实例：
(2)系统流程图 定义：系统流程图是描绘物理系统的传统工具，它的基本思想是用图形符号以黑盒子形式描绘系统里面的每一个部件（程序、文件、数据库、表格、人工过程等）。
(3)数据流图
定义：英文Data Flow Diagram ，简称 DFD 。DFD 是一种描述逻辑模型的图形工具，表示数据在系统内的变化。图中没有任何具体的物理元素，只是描绘信息在系统中流动和处理的情况。DFD 从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。它由数据流、加工、文件和数据流的源点和终点构成。
(4)数据字典
定义：英文Data Dictionary，简称DD 。是一种描述逻辑模型的工具。它对于数据流图中所出现的所有被命名的图形元素作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。DD 的内容包括：图形元素的名字、别名或编号、分类、描述、定义、位置等。 实例：《客房管理系统》字典建模
预订请求＝客人数据＋住宿期限+客房类别
客人数据＝客人姓名+地址+身份证号码+[护照号码] +支付方式 身份证号码=十进制15{数字}18 护照号码＝字母 + 8{数字}8 字母＝“A”…“Z”
十进制数字＝“0”…“9” (5) 实体—联系图
定义：实体—联系图(ERA，Entity-Relationship Approach)或实体联系图（ERD ，Entity- Relationship Diagram）。ERD 描绘了系统的数据关系 。分析实体联系图有助于对业务或系统数据组成的理解和交互，并暗示产品将有必要包含一个数据库。 ER
模型三要素：数据对象、属性和联系。
(6)状态转换图 定义：状态转换图简称状态图。通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。它由1个初态/初始状态、0~N个终态/最终状态和若干个中间状态组成。
(7)层次方框图
定义：用属性结构的一系列多层次的矩形框描述数据的层级结构。
(8)IPO图
定义：输入、处理、输出图的简称。是IBM 公司发展完善的一种图形工具
。
(9)层次图
定义：层次图（也称H 图）是在总体设计阶段最常使用的图形工具之一，它常用于描绘软件的层次结构。它矩形代表一个模块，连线表示调用关系，适于在自顶向下设计软件的过程中使用；与层次方框图类似。
(10) HIPO图 定义：HIPO:是IBM 公司发明的“层次图加输入/处理/输出图的缩写；为了能使HIPO 图具有可跟踪性，在H 图里除了最顶层的方框之外，每个方框都加了编号；和H 图中的每个方框相对应，有一张IPO 图描述这个方框代表的模块的处理过程。IPO 图能够方便地描述数据输入、数据处理和数据输出之间的关系。
(12)结构图
定义：Yourdon 提出的一种软件结构设计工具。一个方框/矩形代表一个模块，箭头连线/直线表示调用关系，带有注释的箭头表示模块调用过程中来回传递的信息。
(13)程序流程图
定义：也称为程序框图；箭头代表控制流而不是数据流；20 世纪70 年代的主要工具；趋势是越来越多的人不再使用。它的主要缺点包括：不是逐步求精的好工具；用箭头代表控制流，可以随意转移控制；不宜表示数据结构。
(14)盒图（N-S 图）
定义：由Nassi 和Shneiderman 提出的一种程序设计方法；其主要特点包括：[1] 功能域明确；[2] 不可以随意转移；[3] 容易确定局部和全程数据的作用域；[4]容易表达嵌套关系。实例：
(15)PAD图
定义：PAD 图是一种问题分析图(ProblemAnalysis Diagram)，1973年由日本日立公司提出。其主要特点包括：
[1] 必是结构化程序； [2] 程序结构清晰；
[3] 易读、易懂、易记；
[4] 支持自顶向下，逐步求精的方法；
[5] 既可以表示程序逻辑，也可以表示数据结构。
(16)判定表
定义：判定表在某些数据处理中，某数据流图的加工需要依赖于多个逻辑条件的取值，就是说完成这一加工的一组动作是由于某一组条件取值的组合而引发的。这时使用判定表来描述比较合适。判定表通常由四部分组成，即：条件桩、操作桩、条件条目和操作条目。
(17)判定树
定义：判定树是判定表的变种，它也能清晰地表达复杂的条件组合与所对应的操作之间的关系。判定树的优点在于它无须任何说明，一眼就能看出其含义，易于理解和使用。
(18)过程设计语言（PDL ）
定义：也称“伪码 ”，用正文形式表示数据和处理的过程的工具。其具有如下特点：
[1] 具有关键字固定语法； [2] 自然语言表述； [3] 数据说明； [4] 提供接口模式。 (19)用例图 定义：用例图是被称为参与者的外部用户所能观察到的系统共呢概念的模型图；用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用；用例图的用途是列出系统中的用例和参与者，并显示哪个参与者参与了那个用例的执行。
(20) 活动图
定义：活动图描述了活动发生的顺序。其图形表示规则如下：
圆角矩形表示方框中的活动； 矩形表示工作流影响的对象；
实心圆表示工作流开始的开始状态； 双层圆表示工作流结束的结束状态； 菱形表示决策点；
垂直泳道表示工作流中的不同参与者及相关活动。
(21)顺序图
顺序图表示对象之间传送消息的时间顺序。 图形表示法：
垂直线，即生命线，表示在整个交互过程中一个对象的生命周期。 生命线之间的箭头连线表示消息。 箭头连线上的文字表示相关的事件。
(22)协作图
协作图对在一次交互中有意义的对象和对象间的链建模。
图形表示法：
直线表示对象之间直接通信关系。
附在直线上箭头表示消息传送方向。
箭头旁文字表示消息及消息编号。
(23) 类图
以类为中心组织起来的图形，用以表示软件系统中各类之间的相互关系。
图形表示法：
矩形框表示类图中的类。
连线表示类之间的关系。
类之间的关系有关联、 聚集、泛化和依赖。
(24)状态图
状态图是一个类对象所经历的所有历程的模型图。状态图有对象的各个状态和连接这些状态的变迁组
成。
图形表示法：
圆角矩形表示状态；
带箭头的直线表示对象从一种状态变迁到另一种状态的过程。
附在直线上的信息表示触发对象状态变迁的条件。
(25)组件图
组件图表示了系统中的各种组建。
组件可以是源代码、二进制文件或可执行文件。
逻辑视图与组件视图之间存在着映射关系。
组件可以与公开的任何接口一起显示。
(26)部署图
用来描述位于节点实例上的运行组件的安排，描述系统的实际物理结构。
图形表示法：
立方体表示节点，节点可以是一组运行的资源，如计算机、设备或存取器等。
直线表示节点之间连接方式。
软件工程原理/技术/方法
1、软件工程的本质特性
(1) 软件工程关注于大型程序的构造；
(2) 软件工程的中心课题是控制复杂性；
(3) 软件经常变化；
(4) 开发软件的效率非常重要；
(5) 和谐地合作是开发软件的关键；
(6) 软件必须有效地支持它的用户
(7) 在软件工程领域中是由具有一种文化背景的人代替具有另一种文化背景的人创造产品。
2、软件工程的七条基本原理
(1)用分阶段的生命周期计划严格管理；
(2)坚持进行阶段评审；
(3)实行严格的产品控制；
(4)采用现代程序设计技术；
(5)结果应能够清楚地审查；
(6)开发小组的人员应少而精；
(7)承认不断改进软件工程实践的必要性；
3、软件生存期的阶段划分
(1)可行性研究与计划
(2)需求分析
(3)总体设计
(4)详细设计
(5)实现(编码)
(6)集成测试
(7)确认测试
(8)使用和维护
4、传统方法学
(1)传统方法学夜车概念生命周期方法学或结构化范型；
(2)采用结构化技术(分析/设计/实现) ，来完成软件开发各项任务；
(3)把软件生命周期的全过程依次划分为若干阶段。本质是面向过程的开发。
(4)每个阶段对立完成，各阶段有严格的开始和结束标准。前一阶段结束，才能开始下一个阶段。
(5)在相当长的一段时间内仍有生命力。
5、面向对象的方法学
面向对象方法以数据为主线，把是数据和对数据的操作紧密地结合起来的方法。
(1)把对象作为融合数据机在数据上的操作行为的统一的软件构件。
(2)把所有对象划分成类。
(3)按照父类与子类的关系，把若干个相关类组成一个层次结构的系统。
(4)对象彼此间仅能通过发送消息互相联系。
6、可行性研究的主要内容
一般来说，至少要从以下三个方面开展研究 ：
(1) 技术可行性：使用现有技术能实现这个系统吗？
(2) 经济可行性：这个系统的经济效益能超过它的开发成本吗？
(3) 操作可行性：系统的操作方式在这个用户组织内行得通吗？
此外，还应从法律、社会效益等更广泛的方面研究每种解法的可行性。
7、可行性研究过程
(1) 复查系统规模和目标；
(2) 研究目前正在使用的系统；
(3) 导出新系统的高层逻辑模型；
(4) 进一步定义问题；
(5) 导出和评价供选择的解法；
(6) 推荐行动方针；
(7) 草拟开发计划；
(8) 书写文档提交审查。
8、成本/效益分析内容
(1)成本估计
代码行技术
任务分解技术
自动估计成本技术
(2) 成本/效益分析的方法
货币的时间价值
投资回收期
纯收入
投资回收率
9、各种需求分析方法所应遵循的准则
(1)必须理解并描述问题的信息域，建立数据模型；
(2)必须定义软件应完成的功能，建立功能模型；
(3)必须描述作为外部事件结果的软件行为，建立行为模型；
(4)必须对描述信息、功能和行为的模型进行分解，用层次的方式展开细节。
10、需求分析的具体任务
(1)确定软件系统的综合需求；
(2)分析系统的数据需求：数据模型/信息模型E-R/层次方框图 ；
(3)导出软件系统的逻辑模型：数据流图/E-R图/状态转换图/数据字典/算法；
(4)修正系统开发计划；
(5)验证软件需求分析的正确性；
(6)编写软件需求规格说明书。
11、系统的综合要求/需求
(1) 功能需求：系统必须提供的服务
(2) 性能需求：系统必须满足的定时约束或容量约束等。
(3) 可靠性和可用性需求。
(4) 出错处理需求：系统对环境错误应该怎样响应。
(5) 接口需求：系统与它的环境通信格式要求。
(6) 约束：设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件：精度/工具/语言/设计/标准/平台。
12、需求获取的常用方法
(1)访谈
(2)面向数据流自顶向下求精
(3)简易的应用规格说明技术
(4)快速建立软件原型
13、总体设计过程
1 .设想供选择的方案
2 .选取合理的方案
3 .推荐最佳方案
4 .功能分解
5. 设计软件结构
6. 设计数据库
7. 制定测试计划
8. 书写文档
9. 审查和复审
14、软件设计中的常用启发规则
(1) 改进软件结构提高模块独立性；
(2) 模块规模应该适中；
(3) 深度、宽度、扇出、扇入都应适当；
(4) 模块的作用域应该在控制域之内；
(5) 力争降低模块接口的复杂程度；
(6) 设计单入口单出口的模块；
(7) 模块功能应该可以预测。
15、耦合设计原则
(1)尽量使用数据耦合
(2)少用控制耦合
(3)限制公共环境耦合范围
(4)完全不用内容耦合
16、内聚设计原则
(1)力求高内聚；
(2)中等内聚也可以采用；
(3)低内聚不要用。
17、面向数据流的设计方法
(1)系统结构特征可归纳为两种典型形式
变换型结构
事务型结构
(2)数据流图可分为两种类型
变换型数据流
事务型数据流
(3)面向数据流设计方法的设计步骤
(1)精化DFD 。
(2)确定DFD 类型。
(3)把DFD 映射到系统模块结构，设计出模块结构的上层。
(4)基于DFD ，逐步分解高层模块，设计出下层模块。
(5)根据模块独立性原理，精化模块结构。
(6)模块接口描述
18、人机界面设计中经常遇到的4个设计问题
(1)系统响应时间
(2)用户帮助设施
(3)出错信息处理
(4)命令交互
19、人机界面设计一般交互指南
(1) 保持一致性
(2) 提供有意义的反馈
(3)在执行有较大破坏型的动作之前，要求用户确认
(4)允许取消绝大多数操作
(5)减少在两次操作之间必须记忆的信息量
(6)提高对话、移动和思考的效率
(7)允许犯错误
(8)按功能对动作分类，并据此设计屏幕布局
(9)提供对用户工作内容敏感的帮助设施
(10)用简单动词或动词短语作为命令名
20、人机界面设计信息显示指南
(1)只显示于当前工作内容有关的信息
(2)不要用数据淹没用户
(3)使用一致的标记、标准的缩写和可与之的颜色
(4)允许用户保持可视化的语境
(5)产生有意义的出错信息
(6)使用大小写、缩进和文本分组以帮助理解
(7)使用窗口分隔不同类型的信息
(8)使用模拟显示方式显示信息
(9)高效率地使用显示屏
21、数据输入指南
(1)尽量减少用户的输入动作
(2)保持信息显示和数据输入之间的一致性
(3)允许用户自定义输入
(4)交互应该是灵活的
(5)使在当前语境中不适用的命令不起作用
(6)让用户控制交互流
(7)对所有输入动作都提供帮助
(8)消除冗余的输入
22、选择一种语言的标准是什么？
(1)系统用户的要求：用户知识和用户环境要求；
(2)可以使用的编译程序：软件平台要求；
(3)可以得到的软件工具：软件条件要求；
(4)工程规模：实践要求；
(5)程序员的知识：方便性要求；
(6)软件可移植性要求：造价要求；
(7)软件的应用领域：对象特点要求。
23、编码风格应该遵循的规则
(1) 程序内部的文档化：
指编码时适当选择标识符的名字
适当安排注释
注重程序的整个组织形式
(2) 数据说明
(3) 语句构造
(4) 输入/输出
24、软件测试准则
(1)所有测试都应该能追溯到用户需求。
(2)应该远在测试开始之前就制定出测试计划。
(3)把Pareto 原理应用到软件测试中。
Pareto 原理：测试发现的错误中80%很可能是由程序中20%的模块造成的。
(4) 应该从“ 小规模” 测试开始，并逐步进行“ 大规模”测试。
(5)穷举测试是不可能的。
(6)应该由第三方从事测试工作。
25、划分等价类的原理
每类中的一个典型值在测试中的作用与这一类中所有其他值的作用相同。
划分等价类的标准：
覆盖
不相交
代表性
26、划分等价类的几条启发式规则：
(1)如果规定了输入值的范围则可划分出一个有效的等价类(输入值在此范围内), 两个无效的等价类（输入值小于最小值或大于最大值）；
(2)如果规定了输入数据的个数，则类似地也可以划分出一个有效的等价类和两个无效的等价类；
(3)如果规定了输入数据的一组值，而且程序对不同输入值做不同处理，则每个允许的输入值是一个有效的等价类，此外还有一个无效的等价类（任一个不允许的输入值）；
(4)如果规定了输入数据必须遵循的规则，则可以划分出一个有效的等价类（符合规则）和若干个无效的等价类（从各种不同角度违反规则）。
(5)如果规定了输入数据为整型，则可以划分出正整数、零和负整数等三个有效类；
(6)如果程序的处理对象是表格，则应该使用空表，以及含一项或多项的表。
27、自顶向下结合测试法
自顶向下的结合方法是一个日益为人们广泛采用的组装软件的途径。
由下述四个步骤完成：
第一步，对主控制模块进行测试，测试时用存根程序代替所有直接附属于主控制模块的模块；
第二步，根据选定的结合策略（深度优先或宽度优先）每次用一个实际模块代换一个存根程序（新结合进来的模块往往又需要新的存根程序）。
第三步，在结合进一个模块的同时进行测试；
第四步，为了保证加入模块没有引进新的错误，可能需要进行回归测试，全部或部分地重复以前做过的测试；
自顶向下的结合策略能够在测试的早期对主要的控制或关键的抉择进行检验；
28、自底向上结合测试法
用下述步骤可以实现自底向上的结合策略把低层模块组合成实现某个特定的软件子功能的族； 写一个驱动程序（用于测试的控制程序），协调测试数据的输入和输出；
对由模块组成的子功能族进行测试；
去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能族。
29、白盒测试
也称结构测试、也称开盒测试或玻璃盒测试；
基于覆盖的测试；
根据被测程序的逻辑结构设计测试用例；力求提高测试覆盖率；
检验产品内部动作是否按照规格说明书的规定正常进行。
主要用户与测试过程的早期。
30、逻辑覆盖
一系列测试过程的总称；
逻辑覆盖包括：
语句覆盖；
判断覆盖；
条件覆盖；
判定／条件覆盖；
条件组合覆盖
点覆盖；
边覆盖；
路径覆盖；
31、语句覆盖:使程序中每个语句至少执行一次。
32、判定覆盖(分支覆盖):使每个判定的真假分支都至少执行一次。
33、条件覆盖:使每个判定的每个条件的可能取值至少执行一次
34、判定/条件覆盖:选取足够多的测试用例，使判断中的每个条件的所有可能取值至少执行一次。选
取足够多的测试用例，同时每个判断本身的所有可能判断结果至少执行一次。
35、条件组合覆盖:使每个判断表达式中条件的各种可能组合至少出现一次。