|
软件工程考试重点
1.定义软件:
(1)指令的集合,通过执行这些指令可以满足预期的特性、功能和性能需求
（2）数据结构，使得程序可以合理利用星系
（3）软件描述信息，它可以硬拷贝和虚拟形式存在，用来描述程序的操作和使用
2.计算机软件的七个大类：
系统软件、应用软件、工程/科学软件、嵌入式软件、产品线软件、Web/移动App、人工智能软件
3.遗留软件：
遗留软件系统，在几十年前诞生，他们不断被修改以满足商业需要和计算平台的变化
4.定义软件工程：
（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法用于软件；
（2）对（1）中所述方法的研究
5.软件过程：
是工作产品构建时所执行的一系列活动、动作、和任务的集合。活动主要实现宽泛的目标（如于利益相关者进行沟通），与应用邻域、项目大小、结果复杂性或者实施软件工程的重要程度没有直接关系。动作包含了主要工作产品（如体系结构设计模型）生产过程的一系列任务。任务关注小而明确的目标，能够产生产品（如构建一个单元测试）。
6.过程框架：
过程框架定义了若干个框架活动：沟通------策划----建模------构建----部署
7.普适性活动（P13）：
软件工程过程框架活动由很多普适性活动来补充实现（了解即可）：
软件项目的跟踪和控制、风险管理、软件质量保证、技术评审、测量、软件配置管理、可复用管理、工作产品的准备和生产
8.软件开发神话（P16）：
关于软件及其开发过程的一些被人盲目相信的说法，这可以追溯到技术发展初期
9.过程流（P23~P24）：
描述了在执行顺序和执行时间上如何组织框架中的活动、动作和任务。
线性过程流：从沟通到部署顺序执行五个框架活动
迭代过程流：在执行下一个活动之前重复执行之前的一个或者多个活动
演化过程流：采用循环的方式执行各个活动，每次执行都能产生更为完善的软件版本
并行过程流：将一个或者多个活动与其它活动并行执行（例如，软件一个方面的建模可以同软件另一个方面的构建活动并行执行）
10.瀑布模型（P30）
又称为经典生命周期，它提出了一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供完整的软件支持。
11.增量过程模型（P32）
增量模型综合了线性过程流和并行过程流的特征。随着时间的推移，增量模型在每个阶段都运用线性序列。每个线性序列生产出软件的可交付增量。
12.演化过程模型（P33）
是迭代的过程模型，这中模型使得软件开发人员能够逐步开发出更完整的软件版本。有两种常用的演化过程模型：原型开发、螺旋模型（是一种演进式软件工程模型，它结合了原型的迭代性质和瀑布模型的可控性和系统特点。它具有快速开发越来越完善的软件版本的潜力，螺旋模型是一种风险驱动型的过程模型生成器）
13.专用过程模型（P38）
专业过程模型往往应用面窄且专一，只适用于某写特定的软件工程方法：基于构建的开发、形式化方法模型、面向方面的软件开发
14、统一过程（P40）
Xxxx关于统一过程的著作中，讨论了有必要建立一种“用例驱动，以架构为核心，迭代并且增量”的软件过程的问题
15.敏捷软件开发宣言（P45）
个人和他们之间的交流胜过了开发过程和工具
可运行的软件胜过了宽泛的文档
客户合作胜过了合同谈判
对变更的良好响应胜过了按部就班的遵循计划
16.极限编程定义（P49）
XP（极限编程）使用面向对象的方法作为推荐的开发范型，它包括了策划、设计、编码和测试4个框架活动的规则和实践。
17.重构（P50）：
是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程；
18.结对编程（P51）
是编码活动中的关键概念，XP建议两个人面对同一台计算机共同作为一个故事开发代码
19.需求工程（P73）
RE（需求工程）是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通并持续到建模活动。
20.需求工程的任务（P74）
需求工程包括七项明确的任务：起始、获取、细化、协商、规格说明，确认和管理。其中获取需求的过程中存在以下问题，
范围问题：发生在系统边界不清楚的情况下，或是客户和用户的说明带有不必要的技术细节，这些细节可能会导致混淆而不是澄清系统的整体目标
理解问题：发生在客户和用户并不完全确定需要什么的情况下包括：对其计算环境的能力和限制所知甚少，对问题域没有完整的认识，与系统工程师沟通存在问题，忽略了那些他们认为是“明显的”信息，确定的需求和其他客户及用户的要求相冲突，需求说明有有歧义或者不可测试。
易变问题：发生在需求随时间推移而变更的情况下。
21.规格说明（P75）
规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或者上述各项的任意组合
22.利益相关者定义（P78）
直接或者间接的从正在开发的系统中获益的人。
23.质量功能部署（P82）：
QFB（质量功能部署）是一种将客户要求转化成软件技术需求的技术。其中存在以下3类需求:
常规需求：是指子啊会议中向客户陈述一个产品或者系统时的目标，如果这些需求存在，客户就会满意。
期望需求：暗指在产品或系统中客户没有清晰表述的基础功能，缺少了这些将会引起客户不满。
兴奋需求：超出客户预期的需求，当这些需求存在时会令人非常满意。
24.使用场景（P83自己看书，写的有点问题）
用例是场景的抽象、场景是用例的一个实例、类是所有对象的抽象
25.需求模型必须实现的三个主要目标：（P96）
描述客户需要什么；
为软件设计奠定基础；
定义在软件完成后可以被确认的一组需求；
26.需求建模的方法（P99）
结构化分析：考虑数据和处理的需求建模方法。
面向对象分析：这种方法关注类的定义和影响客户需求的类之间的协作方式
贴图：（图8——3）
27.类-职责-协作者建模（P113）
CRC（同上）模型实际上是表示类的标准索引卡片的集合。这些卡片分三部分，顶部写类名，卡片主体左侧部分列出类的职责，右侧部分列出类的协作者
28.设计概念（P133）
设计的目标：创作出坚固、适用、和令人愉悦的模型或表示
29.软件工程的设计（P133）
需求模型的每个元素都提供了创建四种设计模型所必须的信息，这四中设计模型是完整的设计规格说明所必须的。贴图（图11-1）
30.良好设计演化的三个特征：（P134）
设计应当实现所有包含在需求模型中的明确需求，而且必须满足利益相关者期望的所有隐含需求；
对于那些编码者和测试者以及随后的软件维护者而言看，设计应当是可读的、可理解的指南；
设计应当提供软件的全貌，从实现的角度对数据域、功能域和行为域进行说明
31.质量属性（P135）
Xxx制定了一系列的软件质量属性，并取首字母组合为FURPS，其中各字母代表功能性（functionality）、易用性（usability）、可靠性（reliability）、性能（performance）及可支持性（supportability）
32.信息隐蔽（P139）
信息隐蔽原则建议模块应该“具有的特征是：每个模块对其他所有模块都有隐蔽自己的设计决策。”换句话说，使信息（算法和数据）都包含在模块内，其他模块无需对这些信息进行访问。隐蔽的含义是，
33.五种不同类型的设计类：（P142）
用户接口类，定义人机交互所必须的所有抽象对象，并且经常在隐喻的环境下实施HCI（人机交互）；
业务域类，识别实现某些业务域元素所必须的属性和服务（方法），通过一个或者更多的分析类进行定义；
过程类，实现完整的管理业务域类所必须的低层业务抽象；
持久类，用于表示将在软件执行之外的持续存在的数据存储（例如，数据库）；
系统类，实现软件管理和控制功能，使得系统能够运行，并在其计算环境内与外界通信
34.组织良好的设计类的四个特征（P143）
完整性与充分性；
原始性；
高内聚性；
低耦合性；
35.设计模型的4个主要元素(P145)
数据；
体系结构；
构建；
接口；
36.体系结构模型的三个导出来源（P146）
关于将要构建的软件的应用域信息；
特定的需求模型元素，如数据流图或分析类、现有问题中他们的关系和协作；
可获得的体系结构风格和模式；
37.接口设计的三个重要元素（P147）
用户界面（UI）；
和其他系统、设备、网络、信息生成者或使用者的外部接口；
各种设计构件之间的内部接口
38.软件体系结构定义（P153）
程序或计算系统的软件体系结构是指系统的一个或者多个结构，它包括软件构建、构建的外部可见属性以及它们之间的相互关系
39.体系结构风格的简单分类（P157）
以数据为中心的体系结构；
数据流体系结构；
调用和返回体系结构；
面向对象体系结构；
层次体系结构；
40.体系结构模式（P160）
体系结构模式在特定环境和一系列限制于约束下处理特定的应用问题
41.什么是构件（P176~P177）
构建是计算机软件中的一个模块化的构造块，更为正式的定义是OMG中，系统中模块化的、可部署的和可替换的部件；
41-1 面向对象的观点
在面向对象软件工程环境中，构件包括一个协作集；
41-2 传统的观点
在传统的软件工程环境中，一个构件就是程序的一个功能要素……….(此处省略，感觉不重要)。传统构件也称为模块，作为软件体系的一部分，它扮演了如下三个重要角色之一:(1)控制构件，协调问题域中所有其他构件的调用(2)问题域构件，完成客户需要的全部功能或部分功能(3)基础设施构件，负责完成问题域所需的支持处理的功能
42.适用于构件级设计的基本设计原则（P180）
开闭原则（OCP）；
Liskov替换原则（LSP）；
依赖倒置原则（DIP）；
接口分离原则（ISP）；
发布复用等价性原则（REP）；
共同封装原则（CCP）；
共同复用原则（CRP）
想看全称自己翻书，每一类原则自己需要了解哟！
43.内聚性的不同类型（P183）
按照内聚性的级别排序：
功能内聚，主要通过操作来体现，当一个模块完成一组且只有一组操作并返回结果时，就称此模板是功能内聚；
分层内聚，由包、构件和类来体现。高层能够访问底层的服务，但底层不能访问高层的服务；
通信内聚，访问相同数据的所有操作被定义在一个类中。一般来说，这些类只着眼于数据的查询、访问和存储；
44.耦合性（P184）
耦合是类之间彼此联系程度的一种定性度量；
耦合分类：
内容耦合：发生在当一个构件“暗中修改其他构件的内部数据”，但是这违背了基本设计概念中的信息隐蔽原则；
控制耦合：发生在当操作A调用操作B，并且向B传递了一个控制标记时。、、、、、、
外部耦合：发生在当一个构件和基础设施构件（例如：操作系统的功能、数据库容量、无线通信功能）进行通信和协作时
45.基于构件的软件工程（P191）
基于构建的软件工程（CBSE）是一种强调使用可复用的软件构件来设计于构造计算机系统的过程。
46.软件构建标准(P193)
这些标准包括：CCM（Corba Component Model，Corba构件模型），Microsoft COM 和NET,JavaBeans，以及OSGI（Open Services Gateway Initiative开发服务网关协议【OSGI3】）
47.用户界面设计的黄金规则（P198）
把控制权交给用户；
减轻用户的记忆负担；
保持界面一致；
48.用户界面分析和设计要考虑的四种模型（P201）
工程师（或者软件工程师）建立用户模型；
软件工程师创建设计模型；
最终用户在脑海里对界面产生映像，称为用户的心里模型或系统感觉；
系统的实现者创建实现模型；
49.用户界面分析和设计的过程（P202）
其设计过程是迭代的，贴图（图14-1）
50.软件质量的定义（P218）
在一定程度上应用有效的软件过程，创造有用的产品，为生产者和使用者提供明显的价值。。。。。
51.McCall的质量因素（P219）
贴图（图15-1）
52.软件质量困境（P222）
一方面，产品要足够好，不会立即被抛弃（比如在评估期）；
另一方面，又不是那么完美，不会花费太长时间和太多成本。
53.质量成本的分类（P223）
预防成本：
（1）计划和协调所有质量控制和质量保证所需管理活动的成本；（2）为开发完成的需求模型和设计模型所增加的技术活动的成本；（3）测试计划的成本（4）与这些活动有关的所有培训成本；
评估成本：
评估成本包括为深入了解产品 “第一次通过”每个过程的条件而进的活动。评估成本的例子包括: (1)对软件工程工作产品进行技术评审的成本: (2)数据收集和度量估算的成本; (3)测试和调试的成本。
失效成本：内部失效成本包括: (1) 为纠正错误进行返工(修复)所需的成本; (2)返工时无意中产生副作用，必须对副作用加以缓解解而发生的成本; (3)组织为评估失效的模型而收集质量数据，由此发生的相关成本。 外部失效成本是在产品已经发布给客户之后发现了缺陷时的相关成本。（发布后—错误）
54.软件测试策略（P249）
软件测试策略也可以放在螺旋模型中来考虑 贴图（图17-1）
软件测试策略也可以放在螺旋模型中来考虑(图17-1)。单元测试起始于螺旋的旋涡中心，侧重于以源代码形式实现的每个单元(例如，构件举或WebApp内容对象)。沿着螺旋向外就是集成测试，这时的测试重点在于软件体系结构的设计和构建。沿着螺旋向外再走一圈就是 确认测试，在这个阶段，依据已经建立的软件，对需求(作为软件需求建模的一部分而建立) 进行确认。最后到达系统测试阶段，将软件与系统的其他成分作为一个整体来测试。为了测试计算机软件，沿着流线向外螺旋前进，每转一圈都拓宽了测试范围。
55.黑盒测试（P270）
|