【软件工程】简答题知识点

一、软件与软件工程

1.1 软件

1.1.1 定义

软件并非仅指计算机可执行的代码，而是程序、数据与描述信息（文档）的集合，是贯穿"定义 → 开发 → 使用 → 维护 → 废弃"全生命周期的逻辑产品。

其核心价值在于通过程序实现特定功能，通过数据支撑功能运行，通过文档（如需求规格说明书、设计文档、维护手册）保障开发协作与后续迭代，最终满足用户或业务的实际需求。

1.1.2 特点

1. 抽象性：功能和性能需要通过运行才能体现。
2. 无明显的制造过程特征：不存在重复生产的产品质量差异，且重复生产的成本较低。
3. 无备件特征：不存在机械磨损、元件老化而需更换备件的现象。

1.2 软件过程

1.2.1 生命周期（3时期、8阶段）

（1）框架内容

1. 定义时期：
   • 问题定义：确定要解决的问题是什么；
   • 可行性研究：用最小的代价在尽可能短的时间内判断上述问题是否有行得通的解决办法；
   • 需求分析：对目标系统提出完整、准确、清晰、具体的要求。
2. 开发时期：
   • 总体设计：概括地提出解决问题的大体方案；
   • 详细设计：把总体设计方案具体化，即怎样具体地实现该系统；
   • 软件编码：用一种适当的高级程序设计语言写出各模块的编码，并对模块进行单元测试；
   • 软件测试：通过各类测试和相应的调试使软件达到预期要求。
3. 维护时期：
   • 软件维护：通过各种维护活动使系统持久地满足用户要求：
     • 改进性维护：诊断和改正使用过程中发现的软件错误；
     • 适应性维护：修改软件以适应环境的变化；
     • 完善性维护：根据用户要求改进或扩充软件；
     • 预防性维护：修改软件为将来的维护活动预先做准备。

（2）优缺点

1. 优点：
   1. 管理与分工清晰：阶段划分明确，每个阶段有固定任务与输出文档，便于制定计划、跟踪进度，适合大型团队协作。
   2. 文档规范完整：各阶段产出标准化文档，为后续维护、人员交接提供清晰依据，降低知识断层风险。
   3. 早期风险可控：通过可行性研究提前识别技术、经济风险，避免盲目开发。
   4. 适配稳定需求场景：当用户需求清晰、变更少时，可高效推进开发，保障产品一致性。
2. 缺点：
   1. 需求变更适应性差：呈线性推进特征，若后期发现需求偏差，修改成本极高。
   2. 用户参与度低：用户仅在需求分析 和软件测试阶段深度参与，中间开发过程脱节，易导致最终产品与用户实际需求不符。
   3. 测试滞后：核心测试（集成测试、验收测试）集中在开发后期，若早期存在错误，难以发现且排查成本高。
   4. 灵活性不足：无法适应快速迭代场景，易导致项目周期延长或产品落后于市场需求。

1.2.2 通用软件过程框架

（1）框架内容

1. 沟通：与利益相关者（用户、项目方）沟通需求、明确目标；
2. 策划：制定项目计划（进度、资源、风险应对）；
3. 建模：将需求转化为可执行的设计方案（如需求模型、架构模型）；
4. 构建：编写代码、进行单元测试与集成测试，生成可运行版本；
5. 部署：将软件交付用户使用，收集反馈以支持后续迭代。

（2）优缺点

1. 优点：
   1. 普适性强：不局限于特定软件类型（Web/移动/云计算软件均适用），可根据项目规模（小型App/大型系统）调整任务粒度，灵活性高于传统生命周期框架。
   2. 质量保障贯穿全流程：通过普适性活动实时监控开发质量，避免传统框架后期测试滞后的问题，早期错误可及时发现。
   3. 用户反馈闭环：部署阶段强调收集用户反馈，并反哺"沟通 - 建模"阶段，支持快速迭代，适配需求动态变化的场景。
   4. 可度量性强：每个活动对应明确的工作产品，便于跟踪项目进度与开发质量，降低管理难度。
2. 缺点：
   1. 过程规范成本高：对小型项目（如个人开发的工具类App）而言，"沟通 - 策划 - 建模"等流程可能增加冗余工作量，降低开发效率。
   2. 依赖团队执行能力：框架仅提供活动框架，需团队明确每个活动的具体标准，若执行不到位，易流于形式。
   3. 阶段边界模糊：未像传统框架那样明确"需求分析结束 → 设计开始"的节点，若团队协作不畅，可能出现需求未明确就启动编码的混乱。
   4. 对新手不友好：框架需要团队理解"活动 - 任务 - 产物"的逻辑关系，新手团队可能因经验不足导致流程衔接断层。

二、过程模型

2.1 瀑布模型

2.1.1 定义

一种系统的、顺序的软件开发方法，采用线性工作流，从沟通（需求获取）、策划、建模（分析/设计）、构建（编码/测试）到部署（交付/反馈）依次推进，强调阶段化、文档化、顺序执行。

2.1.2 适用场景

需求准确定义且相对稳定的项目（如对已有系统的适应性调整或功能增强），较少用于全新开发。

2.1.3 优缺点

1. 优点：
   • 容易理解和计划
   • 适用于充分了解的小型项目
   • 分析和测试是顺序线性的
2. 缺点：
   • 不能很好地适应变化
   • 测试在过程的后期进行
   • 客户确认在最后阶段

2.2 原型模型

2.2.1 定义

以快速构建原型为核心，通过原型验证需求、技术可行性或人机交互形式的过程模型。原型可作为独立模型或辅助技术，部分原型可演化为最终产品，多数为临时系统会被废弃。

2.2.2 适用场景

客户仅定义基本任务，未详细说明功能和特性；或开发人员对算法效率、操作系统适用性、人机交互形式等关键技术点无把握的项目。

2.2.3 优缺点

1. 优点：
   • 变更需求对后续设计影响较小
   • 客户很早并频繁地参与其中
   • 对小型项目来说效果好
   • 产品失败的可能性降低
2. 缺点：
   • 客户的参与可能造成进度延误
   • "提交"一个原型，可能造成初步完成的假象
   • 原型被抛弃导致工作白干了
   • 很难计划和管理

2.3 螺旋模型

2.3.1 定义

一种风险驱动的演进式模型，结合了原型的迭代性质和瀑布模型的可控性、系统性，以螺旋循环的形式推进：每一圈迭代包含"制定计划 → 风险分析 → 沟通/建模/构建 → 部署/反馈"，逐步加深系统定义和实现深度，同时降低风险。

2.3.2 适用场景

大型、复杂、高风险的软件开发项目（如大型企业级系统、核心业务平台），尤其适合需求不明确但风险点较多的项目。

2.3.3 优缺点

1. 优点：
   • 有持续不断的客户参与
   • 开发风险得到控制
   • 适用于大型复杂项目
   • 适用于可扩展的产品
2. 缺点：
   • 风险分析失效可能导致项目失败
   • 项目可能难于管理
   • 需要一个专家开发团队

2.4 统一过程模型

2.4.1 定义

将软件模块化拆分为增量组件，分批次分析、设计、编码、集成和测试，每次交付一个可运行的增量版本（首个增量通常为核心产品），逐步迭代至完整系统。综合了线性过程流和并行过程流的特征，不同增量可并行推进。

2.4.2 适用场景

初始需求明确，但需快速交付核心功能以满足业务需求，后续需根据用户反馈扩展功能的项目（如电商平台、办公软件）。

2.4.3 优缺点

1. 优点：
   • 重视质量文档
   • 有持续不断的客户参与
   • 适合需求变更的情况
   • 对维护项目非常有效
2. 缺点：
   • 用例并不总是精确的
   • 具有复杂的软件增量集成
   • 阶段的重叠可能会带来问题
   • 需要一个专家开发团队

三、敏捷和敏捷过程

3.1 敏捷宣言

1. 个体与交互胜过过程与工具：即个人和他们之间的交流胜过开发过程和工具，强调团队成员间的直接沟通（如面对面交流）比依赖复杂流程或工具更重要，人是软件开发的核心。
2. 可用的软件胜过完备的文档：即可运行的软件胜过宽泛的文档，认为能运行的软件是满足客户需求的关键，无需过度追求详尽但冗余的文档，优先保证产品可用。
3. 客户协作胜过合同谈判：即客户合作胜过合同谈判，倡导客户全程参与开发过程，通过持续协作对齐需求，而非依赖固定合同限制变更。
4. 响应变化胜过遵循计划：即对变更的良好响应胜过按部就班地遵循计划，承认需求变更的必然性，主张通过灵活调整适应变化，而非严格遵守僵化计划，以变化创造客户竞争优势。

3.2 敏捷

3.2.1 本质

敏捷并非单一方法，而是一种软件开发的思想与态度，核心倡导：简单设计、快速交付、价值导向、响应变化 ，旨在解决传统软件开发中需求难预测、变更成本高、客户参与度低的痛点。

3.2.2 敏捷开发

1. 以人为核心：围绕有积极性的个人构建团队，提供必要环境与支持，信任团队自主完成工作（如自组织决策、跨职能协作）。
2. 迭代式开发：将软件开发拆分为短周期迭代，每次迭代交付可运行的软件增量，而非一次性交付完整产品。
3. 循序渐进响应变化：不追求初期完全明确需求，而是通过客户反馈持续调整产品，即使开发后期也欢迎需求变更，以适配动态商业环境。

3.3 敏捷过程

3.3.1 定义

敏捷过程是基于敏捷原则的轻量级软件过程 ，核心是快速响应软件需求、过程与产品的变化 ，通过团队协作实现需求与产品的持续演化，而非遵循传统过程的固定阶段式流程（如瀑布模型）。

3.3.2 三大假设

1. 提前预测稳定需求与变化需求非常困难，且需求优先级难以精准预判；
2. 理论上先设计、后构建，但实际中两者常交错进行（设计者无法完全预判所有问题，需通过构建反馈优化设计）；
3. 从计划角度，分析、设计、构建、测试的进度难以精准预测，僵化计划易导致项目失控。

3.3.3 敏捷原则

1. 优先交付价值：最优先通过尽早、持续交付有价值的软件使客户满意；
2. 拥抱需求变更：即使开发后期，也欢迎需求变更，利用变更为客户创造竞争优势；
3. 频繁交付软件：经常交付可运行软件，交付间隔从几周到几个月，越短越好；
4. 持续客户协作：整个项目开发期间，业务人员与开发人员需天天一起工作；
5. 信任自驱团队：围绕有积极性的个人构建项目，提供环境与支持，信任其完成工作；
6. 面对面沟通：团队内部最有效率的信息传递方式是面对面交谈；
7. 软件度量进度：可运行软件是衡量进度的首要标准，而非文档或计划；
8. 可持续开发速度：责任人、开发者、用户需长期保持稳定的开发速度，避免过度加班；
9. 关注优秀设计：不断关注优秀的技能与设计，增强团队的敏捷能力；
10. 追求简单：使不必做的工作最大化（即避免冗余）是必要的；
11. 自组织团队出佳作：最好的架构、需求和设计出自自组织团队；
12. 定期反省优化：每隔一定时间，团队反省如何更有效工作，并调整自身行为。

四、软件工程的人员方面

4.1 技术角色 VS 管理角色

维度	技术角色	管理角色
核心职责	聚焦用技术落地需求，完成具体技术任务，将业务需求转化为可运行的技术成果，保障技术可行性与产品技术质量（如性能、稳定性、安全性）	聚焦确保项目按目标交付，统筹项目全局，协调资源、规范流程、解决协作问题，确保项目在时间、范围、质量目标内落地，而非直接参与技术实现
关注重点	关注技术可行性与细节可靠性，聚焦技术落地的具体细节，如代码逻辑、技术选型、漏洞修复、性能优化，避免因技术细节疏漏导致产品故障	关注目标对齐与风险规避，聚焦项目整体目标（如交付时间、业务价值）、团队协作效率、资源分配合理性，避免因流程混乱、角色模糊等团队毒性导致项目失败
所需能力	依赖专业技术技能与问题解决能力，核心能力是技术硬实力，需精通编程语言、框架、工具，能独立攻克技术难题，同时具备细节敏感度与务实精神	依赖沟通协调与流程设计能力，核心能力是软技能与统筹能力，需擅长沟通、决策、资源整合，能规范流程、化解团队矛盾，而非精通具体技术
工作内容	具体技术动作落地，日常工作围绕技术执行展开，如编码、技术评审、Bug 修复、技术预研等	统筹性协作推动，日常工作围绕项目推进展开，如制定计划、组织会议、协调资源、规范流程等
价值体现	产出可落地的技术成果（如API接口、功能模块、优化方案），直接决定产品的技术性能与可靠性	保障团队高效协作、项目有序推进，降低沟通成本与风险，确保产品符合业务目标与交付要求

4.2 具体示例

4.2.1 维度：核心职责

（1）技术角色：聚焦用技术落地需求

• 案例1（选课系统）：
  • 后端工程师负责设计"高并发选课API"；
  • 数据库专家优化表结构与查询逻辑，确保5000名学生同时选课不崩溃；
  • 前端工程师优化页面加载速度，避免卡顿影响选课体验。
• 案例2（校园生活通App）：
  • 后端工程师解决"二手交易商品图片上传Bug"，通过调试接口返回逻辑、排查服务器存储路径，确保图片能正常上传并显示；
  • 测试工程师设计压力测试用例，验证功能稳定性。

（2）管理角色：聚焦确保项目按目标交付

• 案例1（校园生活通App）：
  • 项目经理发现"任务分配靠微信群喊话、需求变更无记录"的混乱问题后，引入看板工具，明确任务状态（待办/进行中/已完成），每周组织站会同步进度，避免团队成员忙于刷消息、无法专注编码。
• 案例2（选课系统）：
  • 项目经理在启动会上明确"3个月内上线、成功率>99.9%"的统一目标，在迭代过程中协调跨职能团队（前端/后端/测试）的工作衔接，当技术团队遇到高并发锁机制难题时，联系外部技术专家提供支持，避免项目卡顿。

4.2.2 维度：关注重点

（1）技术角色：关注技术可行性与细节可靠性

• 案例1（骑手位置更新API）：
  • 工程师小王（技术角色）不仅完成API基本功能，还关注"经纬度为null"的极端场景------主动修复后端代码，确保永不返回null（而是返回默认安全坐标），并更新API文档，避免前端解析崩溃；若缺乏细节关注，仅认为后端返回正常、是前端问题，会导致APP闪退。
• 案例2（高并发选课）：技术角色会争论"用乐观锁还是行级锁解决超卖问题"，关注锁机制对数据库性能的影响、是否会引发死锁等技术细节，而非仅考虑能否按时上线。

（2）管理角色：关注目标对齐与风险规避

• 案例1（校园生活通App）：
  • 项目经理（管理角色）发现"团队用不熟悉的新框架导致效率低、Bug多"（技术挫折引发团队分裂），及时调整策略------改用团队熟悉的成熟框架，同时安排技术预研小组研究新框架，平衡技术探索与项目进度，避免团队因持续挫败而消极推诿。
• 案例2（零食外卖小程序）：
  • 当项目从"服务本班"扩展到"服务全国大学生"时，产品经理（管理角色）关注如何对接学校后勤系统、支付平台等外部资源，而非具体用哪种语言编写对接接口，确保业务范围能顺利扩展。

4.2.3 维度：所需能力

（1）技术角色：依赖专业技术技能与问题解决能力

• 案例1（系统上线前Bug）：
  • 工程师小陈（技术角色）在上线前4小时发现"订单丢失Bug"，未盲目提议"重构核心代码"（需2天），而是务实选择"加数据库临时锁"（1小时完成），确保准时上线；这依赖其快速技术判断能力与务实精神，而非管理能力。
• 案例2（算法优化）：
  • 零食外卖小程序后期需"配送员最优路径规划"，算法工程师（技术角色）需掌握图论、动态规划等专业知识，设计路径算法，这是管理角色无需具备的技术深度。

（2）管理角色：依赖沟通协调与流程设计能力

• 案例1（角色模糊问题）：
  • 校园生活通App出现"商品图片上传Bug"后，前端、后端、测试互相推诿，项目经理（管理角色）立即明确"Bug追踪责任人"（测试牵头、前后端配合排查），组织快速复盘会，界定"接口返回逻辑由后端负责、前端显示由前端负责"，2小时内解决问题；这依赖其责任界定能力与冲突化解能力，而非技术编码能力。
• 案例2（跨部门对接）：选课系统需对接学校教务系统获取课程数据，产品经理（管理角色）频繁与教务处沟通数据格式、接口权限，协调双方时间节点，确保数据按时同步；这依赖其跨部门沟通能力，而非技术实现能力。

4.2.4 维度：工作内容

（1）技术角色：具体技术动作落地

• 编写选课系统的"课程查询接口"代码、参与代码审查（指出同事数据库设计的并发缺陷）、用Docker优化系统部署流程、编写自动化测试用例。

（2）管理角色：统筹性协作推动

• 制定选课系统的"3个月迭代计划"（拆分需求到每周）、组织每日站会（同步进度与阻塞问题）、优化"校园生活通"的任务分配流程（用看板工具替代微信群）、对接学校后勤部门确认"校园生活通"的食堂数据接入细节。

五、理解需求

5.1 需求工程

1. 起始：建立项目根基，明确问题边界------提出基础性问题（如 "谁需要解决方案""解决方案的性质是什么"），确认利益相关者（用户、开发团队、管理层等），形成对问题的基本理解，与利益相关者达成初步交流合作意向。
2. 导出：收集需求信息------全面获取所有利益相关者的需求（含明确需求与潜在需求）。
3. 精化：构建需求模型------基于收集的需求，开发需求模型（如用例图、类图、状态图、数据流图），说明软件的功能特征、用户交互流程、数据对象关系，避免需求模糊。
4. 协商：平衡多方利益------识别关键利益相关者的赢条件（如用户需操作便捷，开发方需技术可行），针对冲突需求（如复杂功能与短期交付）进行协商，最终确定优先级与折中方案。
5. 规格说明：固化需求成果------将协商后的需求转化为以下一种或多种形式：①书面文档（如需求规格说明书）；②模型（用例图、类图）；③形式化数学模型；④原型（如Axure原型）；⑤一组使用场景。
6. 确认：验证需求有效性------通过检查机制排查需求问题，包括：①需求与系统目标是否一致；②是否存在丢失信息、不一致或冲突需求；③需求是否可实现、可测试；④需求模型是否恰当反映系统信息/功能/行为；⑤明确项目边界（避免冗余功能）。
7. 需求管理：全生命周期跟踪------在软件开发全周期中，对需求进行可追溯性管理（记录需求从设计、开发、测试到维护的全流程进展），跟踪需求变更的影响，及时调整开发计划，避免需求失控。

5.2 开发用例

1. 参与者：明确与系统交互的角色，分主要参与者（直接发起交互，如提交合同的教师）和次要参与者（间接支持，如审核的副院长）；
2. 核心目标：参与者通过该用例要实现的最终目的（如完成合同线上审批并生效）；
3. 前提条件：用例启动前必须满足的系统/环境状态（如教师已拟定合同文本、系统已分配审批权限）；
4. 核心流程：参与者与系统的关键操作步骤（按时间顺序描述，需体现分支逻辑，如金额不同审批流程不同）；
5. 异常场景：流程中可能出现的问题及处理方式（如审批驳回、超时未处理）；
6. 数据交互：参与者与系统之间的信息传递（如教师提交合同文本/金额，系统反馈审批进度）；
7. 外部环境关联：参与者是否需通知系统外部环境变化（如无需，本用例为内部审批流程）；
8. 后置条件：用例结束后系统的最终状态（如合同生效并留存记录，或驳回并反馈理由）。

六、设计概念

6.1 8大设计概念

6.1.1 抽象

（1）概念

对软件中的数据、过程、控制三类元素进行简化描述，提取本质特征而忽略非关键细节，形成统一的、可理解的表示形式。

• 数据抽象：描述数据对象的命名数据集合（如"门"的抽象包含制造商、产品型号、开门方法等核心属性）；
• 过程抽象：具有明确且有限功能的指令序列（如"开门"的抽象包含"走向门口 → 转动把手 → 开门"的核心步骤）。

（2）核心任务

剥离复杂实体的冗余信息，聚焦核心属性与功能，为后续设计提供简洁通用的模型基础，降低大型软件的理解与实现难度。

6.1.2 体系结构

（1）概念

软件的整体结构及这种结构为系统提供概念完整性的方式（SHA95a定义），包含三大核心特性：

• 结构特性：定义系统构件（模块、对象等）、构件封装方式及交互关系；
• 外部功能特性：说明架构如何满足性能、可靠性、安全性等需求；
• 相关系统族：提取同类系统的重复性模式，支持架构构件重用。

（1）核心任务

确定系统的核心构件及相互协作逻辑，选择适配的架构风格（如分层、微服务），确保系统整体逻辑清晰、符合需求，且具备可扩展性与可重用性。

6.1.3 模式

（1）概念

传递已验证设计方案精髓的标准化解决方案，需包含完整的模板要素：模式名称、目的、别名、动机（问题实例）、适用性（使用场景）、结构（所需类）、关联者（类的职责）、协作（其他模式贡献）、效果（折中与影响）、相关模式（交叉索引）。

（2）核心任务

复用成熟的设计经验，避免重复解决同类问题，降低设计风险，确保解决方案的合理性与高效性（如用"单例模式"解决"全局仅需一个实例"的问题）。

6.1.4 关注点分离

（1）概念

将复杂问题分解为若干独立的关注点（即软件需求中某一特征或行为），每个关注点可单独解决、优化，无需依赖其他关注点。

（2）核心任务

简化复杂问题的处理难度，使每个关注点可独立设计、开发与维护（如将"电商系统"拆分为"商品管理""订单处理""支付"等关注点），提升整体开发效率与质量。

6.1.5 模块化

（1）概念

将软件的逻辑（数据和功能）分割为若干独立的模块，是使大型程序能被人类智力管理的核心属性（Mye78定义）。模块数量需平衡：过少则模块臃肿难理解，过多则接口复杂成本高。

（2）核心任务

根据成本曲线（模块开发成本随数量增加下降，接口成本随数量增加上升）确定最优模块数量，拆分软件为小而可控的单元，确保模块边界清晰，便于开发、测试与维护。

6.1.6 信息隐蔽

（1）概念

设计模块时，使模块内的秘密（算法、数据结构、外部接口细节、资源分配方案等）对不需要这些信息的模块不可访问，仅通过控制接口暴露必要功能。

（2）核心任务

隔离模块内部细节，减少修改模块时的副作用（如修改某模块算法不影响其他模块），阻止全局数据滥用，促进封装，提升系统的可维护性与安全性。

6.1.7 功能独立

（1）概念

模块具备专一功能且避免与其他模块过多交互，核心衡量指标为：

• 内聚性：模块内部元素结合的紧密程度（理想状态为功能内聚，即模块仅完成一件事）；
• 耦合性：模块间相互依赖的程度（理想状态为数据耦合，即仅通过数据交互）。

（2）核心任务

追求高内聚、低耦合，确保模块可独立测试、重用，减少模块间的相互影响（如"用户登录模块"仅负责登录验证，不包含订单处理功能）。

6.1.8 逐步求精

（1）概念

从抽象的高层设计方案出发，逐步细化所有抽象细节，使设计从框架落地为具体可实现的方案（如先确定"订单系统"的模块划分，再细化每个模块的接口参数、数据结构、处理流程）。

（2）核心任务

分阶段完善设计，先确定整体逻辑，再逐步补充模块内部流程、数据格式、异常处理等细节，确保设计的连贯性与完整性，避免因细节缺失导致后期返工。

6.2 10条设计建模原则

1. 设计应可追溯到需求模型 ：
   • 核心含义：设计的每一步都需有明确的需求依据，不新增无需求支撑的功能或结构。
   • 示例：设计"在线支付模块"时，需对应需求中"支持信用卡/支付宝支付"的描述，不可擅自添加"人脸识别支付"（无需求时）。
2. 始终考虑到构建系统的体系结构 ：
   • 核心含义：设计需在架构约束下进行，遵循架构风格与规则，不破坏系统整体的概念完整性。
   • 示例：微服务架构中，模块设计需遵循"服务间通过API通信、数据库私有"原则，不可设计为"多服务共享中心数据库"。
3. 数据设计与处理功能设计同等重要 ：
   • 核心含义：数据（数据对象、关系、存储方式）与功能（处理逻辑、流程）是系统的两大核心，不可偏废。
   • 示例：设计电商系统时，既要设计"下单流程"，也要设计"订单""商品"等数据实体的关系与状态。
4. 接口（内部和外部）的设计必须谨慎 ：
   • 核心含义：接口是模块交互的合约，一旦发布修改成本极高，需明确其格式、功能与兼容性。
   • 示例：设计API时，需确定URL结构、请求/响应格式、版本管理策略，避免频繁修改导致调用方返工。
5. 用户界面设计应适应最终用户的需求 ：
   • 核心含义：以用户为中心，根据用户类型（专业/普通）与使用场景设计交互方式。
   • 示例：医疗诊断系统界面可信息密集（专业医生使用），购物App界面需简洁直观（普通消费者使用）。
6. 构件级设计应在功能上独立 ：
   • 核心含义：构件需聚焦单一功能，避免承担过多职责，确保构件的可重用性与可维护性。
   • 示例："订单查询构件"仅负责查询订单，不包含"订单修改""支付处理"功能。
7. 构件应彼此松耦合，并与外部环境松耦合 ：
   • 核心含义：构件间依赖需简单、松散，减少相互影响；构件与外部系统（如第三方接口）的依赖也需可控。
   • 示例："支付构件"通过标准化接口调用第三方支付服务，不直接嵌入第三方代码，便于替换支付服务商。
8. 设计表示（模型）应易于理解 ：
   • 核心含义：设计模型（类图、流程图、文档等）需简洁清晰，便于开发、测试、维护人员理解，降低沟通成本。
   • 示例：用例图需明确参与者与系统交互逻辑，避免使用复杂术语或冗余元素。
9. 设计应迭代式开发 ：
   • 核心含义：设计非一次性完成，需通过迭代持续优化，适配需求变化与开发反馈。
   • 示例：先完成"用户注册模块"的初步设计，根据测试中发现的"手机号重复验证漏洞"，迭代优化设计。
10. 设计模型的创建并不排除采用敏捷方法的可能性 ：
    • 核心含义：设计可结合敏捷原则，精简冗余文档，聚焦可运行软件，同时保持核心逻辑清晰。
    • 示例：敏捷开发中，可先用简单类图确定模块关系，再通过迭代补充细节，而非一开始就编写完整设计文档。

七、体系结构设计

7.1 软件体系结构

7.1.1 定义

软件体系结构是软件设计的高层抽象层次 ，核心是描述软件系统的整体结构与概念完整性，超越底层算法与数据结构设计，聚焦全局控制、通讯协议、数据存取、构件功能分配、物理分布等关键问题。其本质是一种系统表达，包含三大核心要素：

1. 构件：系统的基本组成单元（如业务服务、基础设施模块）；
2. 连接件：构件间的交互机制（如API、消息队列、远程调用协议）；
3. 约束与原则：构件集成规则、设计决策依据及系统演化指导方针。

权威定义核心共识：

• Mary Shaw & David Garlan：是处理全局组织、通讯协议、构件功能分配的设计层次，不局限于具体算法；
  Bass等人：包含构件、构件外部可见特性（服务、性能、错误处理）及相互关系；
  IEEE标准：是记录体系结构的产品集合，通过多视图（概念视图、运行视图等）适配不同利益相关者需求，而非可运行软件本身。

7.1.2 核心目标

1. 分析设计在满足既定需求方面的有效性：体系结构通过构建简化的系统模型，帮助设计者提前验证设计是否匹配需求。例如，通过架构原型分析"微服务架构能否支撑电商系统'每秒10万并发'的性能需求"，或"分层架构是否满足办公系统'数据安全隔离'的需求"，避免设计与需求脱节。
2. 在设计变更相对容易的阶段，考虑体系结构可能的选择方案：体系结构设计处于软件开发早期（变更成本低），此时可对比多种架构风格（如单体架构vs微服务架构、以数据为中心架构vs分层架构），选择最适配场景的方案。例如，开发"校园课表查询系统"时，早期可评估"单体架构（快速开发）"与"轻量级分层架构（便于后续扩展）"的优劣，避免后期因架构选型错误导致大规模返工。
3. 降低与软件构建相关的风险：体系结构通过提前暴露设计缺陷（如构件交互冲突、技术栈不兼容）降低构建风险。例如，设计"分布式支付系统"时，通过架构模型发现"跨服务数据一致性"问题，提前引入"分布式事务"方案；或通过原型验证"第三方支付接口集成"的可行性，避免开发后期因技术障碍导致项目延期。

7.2 体系结构设计

7.2.1 定义

体系结构设计是软件开发生命周期的高层设计阶段 ，核心是将需求转化为系统可落地的蓝图，通过4个关键子环节明确构件、连接件及设计原则，为后续详细设计、开发与部署提供指导。4个子环节具体如下：

1. 系统在上下文中的表示（上下文建模） ：核心是将系统视为黑盒，通过体系结构上下文图 明确系统与外部实体的交互关系：
   • 识别外部实体：包括上级系统、用户、下级设备（如"SafeHome安全系统"的外部实体为"房主"、"传感器"、"Internet-based监视系统"）；
   • 定义交互方式：明确数据流/控制流（如房主通过"控制面板"向系统发送"布防指令"，传感器向系统传输"异常信号"）；
   • 划定系统边界：避免需求蔓延（如明确"SafeHome系统"仅负责安全监控，不包含"家电控制"功能）。
2. 定义体系结构原型 ：体系结构原型是表达核心抽象的类或模式，是构件设计的模板：
   • 来源：从需求模型的分析类中提取核心抽象（如从"用户认证"分析类提炼"认证原型"，从"设备监控"分析类提炼"探测器原型"）；
   • 核心任务：明确原型间的关系（如"探测器原型"向"控制器原型"发送报警信号，"控制器原型"触发"指示器原型"），用UML类图描述原型交互逻辑（如SafeHome系统的"控制器-探测器-指示器"原型关系）。
3. 将体系结构细化为构件 ：从应用域 （业务相关）和基础设施域 （技术支撑）两个维度拆分构件，确保高内聚、低耦合：
   • 应用域构件：实现业务价值，直接对应需求（如电商系统的"商品服务"、"订单服务"、"支付服务"）；
   • 基础设施域构件：提供技术支撑，与业务无关（如"API网关"（路由请求）、"消息队列"（异步通信）、"配置中心"（统一配置管理））；
   • 关键要求：明确构件职责与接口（如"订单服务"的核心接口为createOrder(订单信息)），避免构件功能重叠或依赖混乱。
4. 描述系统实例（验证与完善） ：通过典型业务场景的"实例开发"，验证架构合理性并细化设计：
   • 选择场景：优先覆盖核心需求（如SafeHome系统的"布防 - 异常检测 - 报警"场景、电商系统的"下单 - 支付 - 库存扣减"场景）；
   • 核心任务：落地构件交互逻辑（如"用户下单 → 订单服务调用库存服务扣减库存 → 调用支付服务完成支付"），发现并修复架构漏洞（如"库存服务响应延迟"，需优化为"异步扣减 + 库存锁定"机制），确保架构从"蓝图"转化为可执行方案。

7.2.2 核心目标

1. 将需求精准转化为可落地的架构方案：把业务需求（功能）与非功能需求（性能、安全性等）转化为"构件 + 连接件"的具体设计，确保每个架构决策都有需求支撑。例如"高可用"需求转化为"服务集群 + 降级容错"设计，"可扩展性"需求转化为"微服务 + 独立数据库"设计，避免设计脱离实际需求。
2. 提前规避项目风险（技术风险、集成风险）：在开发早期（变更成本低）暴露并解决风险。例如，通过原型验证"第三方系统集成"的可行性，通过构件拆分发现"跨服务数据一致性"问题，避免后期因架构缺陷导致大规模返工（如单体架构后期拆分微服务的高成本）。
3. 为全生命周期提供统一指导标准：架构方案是开发、测试、运维团队的共同语言，为详细设计（如构件内部数据结构设计）提供约束，为开发（如接口编码）提供规范，为测试（如性能测试场景设计）提供依据，为部署（如云端节点分配）提供参考，确保各环节目标一致、协作高效。

八、构件级设计

8.1 内聚性

内聚性是衡量构件（或类）内部元素（属性、操作）彼此结合紧密程度的指标，核心体现构件功能的专一性与关联性，内聚性越高，构件逻辑越清晰、可维护性与复用性越强。

8.1.1 功能内聚

1. 概念 ：构件或类的所有元素围绕单一、明确的功能展开，仅完成一件核心任务，内部属性与操作高度关联且为该功能服务，是最理想的内聚类型。
2. 核心特点：功能纯粹，无冗余操作，构件仅对外暴露与核心功能相关的接口，内部细节完全封装。
3. 案例：
   • 订单金额计算构件：仅包含"计算订单基础金额"、"叠加税费"、"扣除优惠"三个操作，所有属性（订单商品列表、税率、优惠规则）均为该计算功能服务，不涉及库存扣减、物流安排等无关操作；
   • 用户登录验证构件：仅负责"校验用户名密码"、"生成登录令牌"两个核心操作，无用户信息修改、权限分配等其他功能。

8.1.2 分层内聚

1. 概念 ：构件或类按层次职责 组织，每层仅为上层提供服务（或接收下层服务），内部元素围绕该层次的特定职责关联，层次间通过标准化接口交互，不跨越层次依赖。
2. 核心特点：按抽象程度或功能层级划分（如"表现层 → 业务层 → 数据层"），每层聚焦自身职责，修改某一层时对其他层影响极小。
3. 案例：
   • Web应用的分层架构中，表现层构件仅负责用户界面渲染与输入接收，所有业务逻辑（如数据校验、业务规则判断）均委托给业务层构件；业务层构件仅处理业务逻辑，数据存取委托给数据层构件，三层内部元素分别围绕"界面交互"、"业务处理"、"数据操作"职责关联，形成分层内聚。

8.1.3 通信内聚

1. 概念 ：构件或类的所有元素使用同一个输入数据 或产生同一个输出数据，围绕同一数据对象交互，虽功能可能不同，但因数据关联而聚合。
2. 核心特点：内聚性低于功能内聚，构件内操作虽围绕同一数据，但可能涉及不同类型的功能（如数据修改、计算、展示），需避免功能过度混杂。
3. 案例：
   • 学生数据处理器构件：内部包含"更新学生信息"、"计算成绩等级"、"生成报告卡"三个操作，所有操作均基于"Student数据对象"（输入/输出均为该对象），虽功能不同（数据维护、业务计算、报表生成），但因共享同一数据而形成通信内聚；
   • 订单数据管理构件：包含"订单状态更新"、"订单金额统计"、"订单日志记录"操作，均围绕"Order数据对象"展开，属于通信内聚。

8.2 耦合

耦合是衡量构件（或类）之间、构件与外部环境之间相互依赖程度的指标，核心体现模块间的关联复杂度，耦合度越低，模块独立性越强，修改与维护越便捷。

8.1.2 内容耦合

1. 概念 ：两个构件间存在直接访问内部细节的强依赖，违反封装原则，是最紧密、最危险的耦合类型。
2. 核心场景：
   1. 一个构件直接访问另一个构件的内部数据（如直接读取/修改对方的私有属性、局部变量）；
   2. 一个构件不通过正常入口（如公共方法），直接跳转到另一个构件的内部逻辑（如调用私有方法、跳转到代码片段）；
   3. 两个构件存在代码重叠（如共享同一代码块，修改一处影响两处）；
   4. 一个构件存在多个入口（如多个公共方法均可作为初始化入口，导致逻辑混乱）。
3. 案例：
   • 类A的money属性为私有，类B直接通过A.money = 0修改该属性（访问内部数据）；
   • 类C的play()方法为私有（仅内部调用），类D直接调用C.play()（不通过正常入口）。

8.1.3 控制耦合

1. 概念 ：两个构件间通过控制信息（如标志位、开关值、状态码）交互，传递的信息不仅是数据，还会直接影响接收方的内部逻辑流程，接收方需根据控制信息调整执行路径。
2. 核心特点：耦合度较高，接收方的逻辑依赖发送方的控制信息，修改控制规则（如新增控制类型）需同时修改双方，破坏独立性。
3. 案例：
   • 构件A向构件B传递参数format_type = "JSON"，构件B根据该参数判断"执行JSON格式转换"还是"XML格式转换"（控制信息影响内部流程）；
   • 构件C向构件D传递status = "PAUSE"，构件D根据该状态暂停当前任务，若后续新增status = "STOP"，需同时修改构件C的参数传递逻辑与构件D的判断逻辑。

8.1.3 外部耦合

1. 概念 ：构件依赖外部系统、硬件环境或第三方服务，与外部环境的关联紧密，构件的正常运行依赖外部环境的稳定性与接口兼容性，无法独立存在。
2. 核心特点：耦合度受外部环境约束，外部环境变更（如硬件升级、第三方接口调整）会直接导致构件失效，需针对性修改。
3. 案例：
   • 构件依赖"特定数据库的驱动程序"（如仅适配MySQL 5.7），若数据库升级为MySQL 8.0或更换为PostgreSQL，需修改构件的数据库连接逻辑；
   • 移动应用的"GPS定位构件"依赖手机硬件的GPS模块，若设备无GPS功能或权限被禁用，构件无法正常工作；
   • 构件依赖"第三方支付接口（如微信支付V2版）"，若微信支付升级为V3版接口，构件需重新适配新接口格式。

九、用户体验设计

9.1 定义

用户体验（UX）设计的核心是通过在产品与用户之间创建可用、可访问且令人愉悦的交互，提升用户对产品的满意度。

其本质是围绕用户需求和客户业务目标，覆盖产品从策略、范围、结构、框架到界面的全方面设计，确保软件的每个交互细节都经过明确规划，最终让用户在使用过程中感到便捷、舒适，同时满足业务核心目标。

9.2 3条黄金规则

9.2.1 把控制权交给用户

核心是让用户主导交互过程，而非被动接受系统约束：

• 提供灵活的交互模式，不强迫用户进行不必要或不希望的操作；
• 允许用户中断、撤销操作，支持定制化交互（如自定义快捷按键）；
• 将用户与内部技术细节隔离开，让用户可直接与屏幕对象交互，无需关注底层原理。

9.2.2 减轻用户的记忆负担

核心是减少用户在使用过程中的认知消耗：

• 降低对短期记忆的依赖，避免让用户记忆复杂操作步骤或信息；
• 建立有意义的默认设置、直观的快捷方式，界面视觉布局贴合真实世界象征（如用"垃圾桶"图标表示删除）；
• 以渐进式方式揭示信息，避免一次性呈现过多复杂内容。

9.2.3 保持界面一致

核心是建立稳定的交互预期，降低用户学习成本：

• 让用户能将当前任务放入有意义的环境中，理解操作上下文；
• 在完整产品线内保持一致（如导航控制、图标、颜色风格统一）；
• 若已建立用户熟悉的交互模型，无不得已的理由不轻易改变，避免打破用户既有使用习惯。