软件工程复习笔记

简答题测验

说明：请根据所学知识，用2-3句话简要回答以下问题。

1. 什么是耦合性与内聚性？它们如何影响模块的功能独立性？
2. UML中的类图和对象图的主要用途是什么？它们之间有何关键区别？
3. 简述增量过程模型的核心特点及其主要优点之一。
4. 根据质量功能部署（QFD）理论，需求可以分为哪三个类别？
5. 在面向对象建模中，聚合（Aggregation）与组合（Composition）关系有何区别？
6. 软件工程过程包含哪五个基本框架活动？
7. 什么是CMMI？它定义了哪五个能力成熟度级别？
8. 请解释黑盒测试与白盒测试之间的主要区别。
9. 将类图中的泛化（继承）关系映射到关系数据库时，可以采用哪一种策略？
10. 软件设计中的信息隐藏原则是什么？它能带来哪些好处？

---

简答题答案

1. 什么是耦合性与内聚性？它们如何影响模块的功能独立性？ 耦合性是衡量软件结构中各个模块之间相互关联程度的度量，而内聚性则是衡量一个模块内部各成分彼此结合紧密程度的度量。为了实现功能独立性，软件设计应追求尽可能松散的耦合和尽可能高的内聚。
2. UML中的类图和对象图的主要用途是什么？它们之间有何关键区别？ 类图用于描述系统的静态结构，展示了系统的类、属性、操作以及类之间的关系。对象图则展示了系统在特定时刻的一个快照，描述了类的实例（对象）及其当前的属性值。关键区别在于，类图是对类型的建模，而对象图是对实例的建模。
3. 简述增量过程模型的核心特点及其主要优点之一。 增量模型的核心特点是将软件产品作为一系列增量构件来设计、实现、集成和测试，每个增量都会发布一部分功能。其主要优点之一是能在较短时间内向用户提交有用的工作产品，使用户能尽早使用系统并提供反馈。
4. 根据质量功能部署（QFD）理论，需求可以分为哪三个类别？ 质量功能部署（QFD）将需求分为三类：正常需求，即客户明确提出的需求；期望需求，即客户认为理所当然、隐含在产品中的需求；以及令人兴奋的需求，即超出客户期望、能带来极大满意度的需求。
5. 在面向对象建模中，聚合（Aggregation）与组合（Composition）关系有何区别？ 聚合与组合都是表示“整体-部分”关系的特殊关联。主要区别在于，聚合关系中，一个部分可以属于多个整体；而组合关系（强聚合）中，部分对象的生命周期取决于整体，部分唯一属于一个整体，会随着整体的创建和销毁而被创建和销毁。
6. 软件工程过程包含哪五个基本框架活动？ 软件工程过程的五个基本框架活动是：沟通（Communication），包括需求获取；策划（Planning），包括项目估算和进度计划；建模（Modeling），包括分析和设计；构建（Construction），包括编码和测试；以及部署（Deployment），包括交付、支持和反馈。
7. 什么是CMMI？它定义了哪五个能力成熟度级别？ CMMI（能力成熟度模型集成）是由卡耐基梅隆大学软件工程研究院制定的软件过程改良与评估模型，是目前世界公认的软件产品进入国际市场的通行证。它定义了五个能力成熟度级别：已执行级（Level 1）、已管理级（Level 2）、已定义级（Level 3）、已定量管理级（Level 4）和已优化级（Level 5）。（注：还有一个级别为不完全级 Level 0）。
8. 请解释黑盒测试与白盒测试之间的主要区别。 主要区别在于测试的视角和依据。黑盒测试是一种确认技术，它从产品功能角度出发，不关心内部实现逻辑，回答“我们在构造一个正确的系统吗？”。白盒测试是一种验证技术，它基于代码的内部逻辑结构进行测试，回答“我们在正确地构造一个系统吗？”。
9. 将类图中的泛化（继承）关系映射到关系数据库时，可以采用哪一种策略？ 可以采用“一类一表”的策略，即分别为父类和每个子类建立数据表。子类表中包含其特有属性，并通过一个外键与父类表的主键关联，访问完整对象时需要进行表连接。另外两种策略是将子类属性上拉到父类表，或将父类属性下推到各子类表。
10. 软件设计中的信息隐藏原则是什么？它能带来哪些好处？ 信息隐藏原则是指模块的设计应使其所包含的信息（过程和数据）对于不需要这些信息的其他模块来说是不可访问的。这样做的好处包括降低“副作用”的可能性、减少局部设计决策对全局的影响、促进封装以及形成更高质量的软件。

---

论述题

说明：请根据相关材料，对以下问题进行深入分析和阐述。无需提供答案。

1. 结合外卖平台数据库性能瓶颈的案例，论述良好软件设计的重要性。详细解释技术团队采用的“混合持久化（Polyglot Persistence）”策略是如何通过读写分离、专用搜索引擎和内存加速等技术解决不同类型数据的处理需求的。
2. “秋千”漫画和“Phil与Maria”的对话揭示了需求获取过程中的哪些典型挑战？请阐述需求工程中的起始、导出、精化、协商和确认等活动是如何系统性地应对这些挑战，以确保最终交付的软件能满足用户的真实需求。
3. 对比分析瀑布模型与敏捷开发模型（如Scrum）在过程流程、需求处理和客户交互方面的核心差异。结合“图像浏览软件”开发场景，讨论在需求初期不明确且可能频繁变更的情况下，哪种过程模型更为适用，并说明理由。
4. 解释里氏替换原则（LSP）和开闭原则（OCP）的核心思想。以“鸟”与“企鹅”的例子或“矩形”与“正方形”的例子说明违反这些原则可能导致的问题，并探讨如何重新设计以更好地遵循这些原则，从而提高软件的可扩展性和可维护性。
5. 从提供的“教室管理系统”、“房屋发布系统”或“兼职招聘系统”的需求描述中任选其一，识别出其核心实体类、边界类和控制类。绘制一个简要的类图，标明主要类的属性以及类之间的关联关系（包括名称、角色和多重性），并解释你的建模决策。

---

核心术语词汇表

术语 (Term)	定义 (Definition)
软件工程 (Software Engineering)	涵盖了方法、工具和过程三个要素，旨在系统化、规范化地开发和维护软件。
软件过程模型 (Software Process Model)	软件过程的一种抽象表示，通常是对软件过程某一特定方面的抽象描述。
瀑布模型 (Waterfall Model)	一种线性的、顺序的软件开发模型，开发过程像瀑布一样自上而下地流动。
增量模型 (Incremental Model)	将软件作为一系列增量构件来设计、实现和测试的过程模型，每个增量都为用户提供部分功能。
螺旋模型 (Spiral Model)	一种演化过程模型，它将原型开发的迭代性质与瀑布模型的系统性和可控性结合起来，并增加了风险分析。
敏捷开发 (Agile Development)	一种以人为核心、迭代、循序渐进的开发方法，强调快速响应变化，其代表有极限编程（XP）和Scrum。
需求工程 (Requirement Engineering)	通过执行起始、导出、精化、协商、规格说明、确认和管理七个活动来帮助软件工程师理解待解决问题的过程。
功能需求 (Functional Requirement)	描述系统应该提供的服务，即用户希望软件做什么事情，完成什么功能。
非功能需求 (Non-functional Requirement)	对系统提供服务或功能时受到的约束进行描述，如性能、安全性、可靠性等。
领域需求 (Domain Requirement)	来自于系统应用领域并反映该领域特征的需求。
UML (Unified Modeling Language)	面向对象技术领域的标准建模语言，它独立于软件过程，可用于可视化、说明、构造和文档化软件。
类图 (Class Diagram)	一种结构图，用于描述系统的静态结构，包括系统的类、属性、操作以及它们之间的关系。
对象图 (Object Diagram)	描述系统在某个特定时刻的静态结构，是类图的一个实例，显示了对象及其属性的当前值。
关联 (Association)	描述类与类之间的一种结构关系。一个完整的关联关系可包含名称、角色和多重性。
多重性 (Multiplicity)	指明有多少个关联端点的对象可以与另一个端点的一个对象相关联，格式通常为“minimum..maximum”。
聚合 (Aggregation)	关联的一种特殊形式，表示“整体-部分”关系，一个部分可以属于多个整体。
组合 (Composition)	聚合的更强形式，部分的生命周期取决于整体，部分唯一属于一个整体。
软件设计 (Software Design)	一个将需求变换为用于构建软件的“蓝图”的迭代过程，是更高层次的抽象表达。
耦合性 (Coupling)	对软件程序结构中各个模块之间相互关联程度的一种度量。设计目标是低耦合。
内聚性 (Cohesion)	标志一个模块内部各成分彼此结合的紧密程度。设计目标是高内聚。
信息隐藏 (Information Hiding)	一项设计原则，要求模块应设计得使其所含信息（过程和数据）对不需要这些信息的模块不可访问。
重构 (Refactoring)	在不改变代码外部行为的前提下，改进其内部结构的过程。
里氏替换原则 (LSP)	如果一个子类可以替换其基类，那么使用基类的模块在无需修改的情况下就可以扩展。
开闭原则 (OCP)	软件实体（类、模块等）应该对扩展开放，对修改关闭。
CMMI (能力成熟度模型集成)	由美国国防部委托卡耐基梅隆大学软件工程研究院制定的软件过程改良、评估模型，用于评估企业的过程能力成熟度。
黑盒测试 (Black-box Testing)	一种确认技术，从产品功能角度测试，不关心内部实现，验证系统是否正确。
白盒测试 (White-box Testing)	一种验证技术，测试程序的内部结构或工作原理，验证系统构造是否正确。
边界值分析 (Boundary Value Analysis)	一种测试方法，指找到等价类中稍高于其边界值及稍低于其边界值的一些特定情况进行测试。
Redis	一个开源的、跨平台的非关系型键值（key-value）存储系统，常被描述为“数据结构服务器”，因其高性能常被用于缓存、消息队列等场景。

速记表格

概念/原则名称	核心定义	主要特征/属性	设计目标/作用	度量或启发式规则
模块化	将软件划分为可独立命名和编址的构件（模块），每个模块完成一个子功能。	表现为数据和功能的分割，是关注点分离（SoC）的常见表现。	使软件更容易构造、应对变更和维护；实现分而治之，降低系统复杂性。	规模适中：模块长度建议控制在 30-50 条语句左右；扇出（Fan-out）以 3 到 9 为宜；扇入（Fan-in）越大说明共享程度越高。
功能独立性	一个模块在不需要另一个模块的情况下，能够完整地执行其特定子功能。	由抽象、模块化和信息隐藏概念直接产出；通过评价指标“内聚”与“耦合”来衡量。	提升系统的可理解性、可测试性、可靠性和可维护性。	评估准则：增加内聚，减少耦合。目标是实现高内聚、低耦合。
内聚性	标志一个模块内部各成分彼此结合的紧密程度，是信息隐藏和局部化概念的自然扩展。	体现了模块内部功能的单一性和纯粹性。	度量模块功能相对强度的定性准则；高内聚有助于提高模块独立性。	尽量做到“一个模块一个功能”，内聚程度越高越好。
耦合性	对软件程序结构中各个模块之间相互关联程度的一种度量。	取决于模块间接口的复杂性、进入模块的方式以及通过接口的数据量。	追求尽可能松散耦合的系统，以降低修改带来的副作用及错误传播可能性。	避免“病态连接”；减少控制耦合和公共耦合；将特征耦合转化为数据耦合。
软件设计的启发式规则	基于工程经验总结出的用于改进设计质量和优化软件结构的规律。	涵盖模块独立性、规模、深度、宽度、扇入、扇出、作用域与控制域等维度。	作为优化软件内部结构的指导，提升软件的可读性、可靠性和可维护性。	模块作用域应在控制域之内；遵循“模块化”及“体系结构设计”中的经验数值（如扇出 3-9）。
体系结构设计	定义了软件的主要结构元素之间的联系，包括体系结构风格和设计模式。	体现为模块（构件）的层次结构。	提供软件的全貌，从实现角度说明数据域、功能域和行为域的设计。	度量指标包括深度（控制层数）和宽度（同一层模块总数）。
抽象	抽出事物的本质特性而暂时不考虑其细节，概括事物间的相似方面。	包括数据抽象、过程抽象和控制抽象。	作为认识复杂现象的思维工具，通过不同层次的抽象解构复杂系统。	每一层抽象是对高一级抽象的较具体化描述（精化）。
信息隐藏	模块的设计应使其所含信息（算法、数据结构等）对于不需要这些信息的模块不可访问。	通过定义明确的接口实现对内部“秘密”的封装。	降低副作用；减少局部设计决定对全局的影响；阻止非法或不必要的全局数据使用。	促进封装，作为形成高质量功能独立性的重要手段。