《软件工程重点》由会员分享，可在线阅读，更多相关《软件工程重点（3页珍藏版）》请在金锄头文库上搜索。
1、重点：1. 用户关注软件质量的外部属性，如软件的正确性、可靠性、有效性、完整性、可用性、 可维护性、可移植性、可复用性等。P72. 软件工程的定义是：（1）将系统的、规范的、可量化的方法应用于软件的开发、运行和 维护的过程；（2）及上述方法的研究。P103. 软件工程的项目、人、过程、方法和工具、软件制品构成了软件工程的五要素。P11-124. 增量式开发的优点是：（1）在软件开发的过程中，按照增量持续不断地发布软件新版本，可及时获得客户 的反馈，用于调整后续的软件开发策略。（2）由于软件需求是确定的，可先对软件体系结构进行设计，增量开发过程能保持 良好的软件体系结构。增量式开发的缺点是：（1
2、）增量规模不能大（开发不要超过20k行代码），否则会暴露瀑布模型的缺点。（2）将客户需求分解成增量序列必须对系统需求十分了解，并有顶层设计的经验。（3）多数系统都需要基本服务，如何为基本服务定义增量，何时实现这些增量，处 理起来比较困难。P225. RUP将软件生存周期，即软件制品的逵化状态划分为出世、细化、构造、移交、生产5 个阶段。将软件开发过程分解为业务建模、需求、设计、实现、验证与确认V&V）、部 署、配置和变更管理、项目管理、环境9个工作流。P586. 软件需求的分类：（填空）功能需求是指利益相关方要求目标软件系统应该具有的功能，还包括软件系统在业务处 理过程中完成这些功能时必须遵守
3、的约定或限制。P68质量需求主要指利益相关方对目标软件系统的质量要求。P68约束性需求是指利益相关方对目标软件系统在项目预算、完成时间、技术选型、必须遵 循的标准语规范方面提出的要求，以及预期的开发、运行环境的特征而导致的针对目标软件 系统的约束。P687. 需求建模的基本方法包括抽象、分解与多视点分析3种。P728. 用例的概念：从外部用户的视角看，一个用例（Use Case）是执行者（Actor）与目标软 件系统之间一次典型的交互作用；从软件内部的视角出发，一个用例代表着系统执行的 一系列动作，动作执行的结果能够被外部执行者所察觉。P839. 用例的关系主要包含3种：包含（Include）
4、、扩展（Extend）和继承（inheritance）。P8610. 在用例模型已成的情形下为何还要构建分析模型？（1）分析模型比用例模型更加结构化、更加清晰直观。（2）分析模型是用例模型与软件设计模型之间的“桥梁”，它比用例模型更接近于设 计模型，更加适合于软件设计师设计软件系统的结构、构思软件求解算法，更 易于为不太熟悉业务的软件设计师所理解。P11711. 用于表示分析模型的UML图形机制主要是类图、活动图、交互图与状态图。P11712. 一般而言，需求优先级取决于3个因素的综合作用：需求项为利益相关方提供的价值、 需求项的实现成本及实现过程中的风险。P13513. 设计元素主要指出现在
5、设计模型中的模块，这些模块的表现形式包括子系统、构件和类。P15914. 软件设计的基本原则包括抽象与逐步求精、强内聚及松耦合、信息隐藏及关注点分离。P16215. 内聚度表示一个模块内部各成分彼此关联的紧密程度。内聚度的表象形式有以下7种。（1） 偶然性内聚（Coincidental Cohesion）：模块内各成分为完成一组功能而组合在一 起，它们相互之间即使有关系也很松散。（2） 逻辑性内聚（Logical Cohesion）：模块完成多项功能，这些功能在逻辑上具有某 种相关性。（3）时间性内聚（Temporal Cohesion）：模块完成的诸任务必须在同一时间段内执行。（4） 过程性
6、内聚（Procedural Cohesion）：在逻辑性内聚的基础上，进一步要求模块内 各功能必须按特定的次序执行。（5） 通信性内聚（Communicational Cohesion）：模块中各成分对数据结构的同一区域 进行操作，以达到通信的目的。例如，如果在类中若干方法（操作）对类中的 相同属性数据施加操作，那么此类的内聚度至少在通信性内聚（含）以上。（6） 顺序性内聚（Sequential Cohesion）：模块内各处理成分均与同一功能相关，且这 些处理必须依序执行。（简答）（7）功能性内聚（Functional Cohesion）：模块内各成分协同完成单一功能。P166-16716.
7、 体系结构包括组建（Component）、连接件（Connector）和约束（Constraints）三大要素， 连接件表示组件之间的连接和交互关系，约束表示组件中的元素应满足的条件，以及组 件经由连接件组装成更大模块时应满足的条件。P176 （填空）17. 本节一次介绍分层、管道与过滤器、黑板共3个通用的体系结构模式。P19018. 概念体系结构与精化后的逻辑体系结构之间的区别：（1）出现在概念体系结构中的模块 仅代表逻辑职责，而精化体系结构中的模块不仅代表逻辑职责，还必须有明确的接口定 义。（2）概念体系结构中的模块划分主要是职责的逻辑分组，精化体系结构中的模块划 分则必须考虑可用的设计资
8、产（如开源结构、开源框架）、技术支撑设施、分布部署、 开发技能的专业化分工甚至并行开发等因素。（3）概念体系结构与精化后的逻辑体系结 构之间更重要的区别是，前者不必、但后者必须具备设计充分性。P19819. 对详细设计模型的质量要求包括3个方面：正确性一一模型中若干设计元素通过模型指 定的协作方式能够实现所有的软件需求；优化性一一模型以充分优化的方式实现所有的 软件需求；设计充分性一一模型的细化和精确程度足以作为编程人员的全部工作基础， 没有含混、笼统和歧义之处。P23820. 软件实现是指通过程序设计及编码过程，把软件详细设计映照为计算机可以“理解”并 最终可运行的代码。P27121. 常用
9、的调试策略分为3中：原始法（Brute Force）、回溯法（Backtracking）和排除法（Cause Eliminations）。（1）原始的调试方法主要思想是“通过计算机找错”。在程序中安排若干输出语句等， 凭借大量的现场信息，从中找到缺陷线索。（2）回溯法性出现缺陷征兆处开始，人工的沿控制流程往回追踪，直至发现缺陷根 源。（3） 排除法基于归纳和演绎原理，采用“分治”的概念，首先手机与缺陷出现有关 的所有数据，假想一个缺陷原因，用这些数据证明或反驳它；或者一次列出所 有可能的原因，通过测试一一排除。只要某次测试结果说明某种假设已呈现端 倪，则立即精化数据，乘胜追击。P28622. 黑盒测试是按照设计目标测试产品应具备的功能，检验产品能偶在使用环境正常工作， 并提供产品应具备的功能。P32623. 白盒测试是按照产品工作原理和过程，测试产品内部各个子系统或部件功能、属性、动 作是否正常。P32624. 完善性维护是根据用户在软件使用过程中提出一些新需求而实施的维护活动。P352
