HNUST-2025年秋-软件工程复习资料

最新推荐文章于 2025-12-21 17:09:26 发布

原创最新推荐文章于 2025-12-21 17:09:26 发布 · 782 阅读

17 ·

CC 4.0 BY-SA版权

文章标签：

#软件工程 #大数据

第一章

定义软件

指令的集合(计算机程序)，通过执行这些指令可以满足预期的特性、功能和性能需求
数据结构，使得程序可以合理利用信息
软件描述信息，它以硬拷贝和虚拟形式存在，用来描述程序的操作和使用
软件的特性：不会磨损。软件的失效曲线是在基于硬件的浴缸曲线上，一次变更就能让曲线发生一次上升。

过程框架

过程框架定义了若干个框架活动

过程是事情进行或事物发展所经过的顺序
当开发产品或构件系统时，遵循一系列可预测的步骤（即路线图）是非常重要的，它有助于及时交付高质量的产品
软件开发中所遵循的路线图就称为”软件过程“

过程框架包括：

1. 沟通：在技术工作开始前，理解利益相关方(包括客户)的项目目标，并收集需求来定义软件特性和功能
2. 策划：创建一个软件项目计划来定义和描述软件工程工作，包含：需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划
3. 建模：画一张草图来理解项目的体系结构、不同构件的组合方案，以及其他的特性
4. 构建：必须对所做的设计进行构建，包含手动编码与测试
5. 部署：将软件全量或者部分增量地交付给用户

过程的普适性调整

过程框架由很多普适性活动补充实现，这些活动贯穿项目始终

a. 软件项目跟踪和控制

理解内容：需基于预先制定的项目计划（如进度基准、里程碑节点、资源分配方案等），通过定期收集实际进展数据（如任务完成率、代码提交量、测试通过率等），对比计划目标识别偏差（如进度延迟、成本超支），并分析偏差产生的根本原因（如需求变更频繁、资源不足）。进一步基于分析结果采取纠正措施（如调整任务优先级、增加开发人员、协商需求范围），同时向相关方透明化进展状态，确保项目始终朝着既定目标推进。

b. 风险管理

理解内容：核心是对项目全生命周期中可能影响成果交付或产品质量的不确定性因素（如技术难点未突破、关键人员离职、外部依赖延迟、法规政策变化）进行系统性识别（通过头脑风暴/历史数据/专家访谈）、定性/定量评估（分析发生概率与影响程度，划分高/中/低优先级），并制定针对性应对策略（如规避风险——调整方案避开技术瓶颈；转移风险——购买保险或外包；减轻风险——提前技术预研；接受风险——预留应急储备）。同时需持续监控风险状态（如触发条件是否出现），动态更新风险登记册。

c. 软件质量保障（SQA）

理解内容：聚焦于通过建立并执行一套覆盖全流程的质量保证体系（如符合CMMI/ISO 9001标准的过程规范、代码/文档/测试的标准化要求），验证软件开发过程及工作产品（如需求文档、设计模型、源代码、测试用例）是否严格遵循既定流程与标准，而非直接检查产品质量本身。目标是预防缺陷产生（通过过程合规减少人为失误），而非仅依赖后期测试发现问题，最终确保项目交付的成果具备可靠性、可维护性等质量属性。

d. 技术评审

理解内容：通过组织具备专业能力的人员（如架构师、领域专家、测试代表）对关键工作产品（如需求规格说明书、系统设计文档、关键代码模块）进行结构化审查（如走查、轮查、正式评审会议），目标是早期发现逻辑错误（如需求矛盾）、设计缺陷（如架构扩展性不足）、实现隐患（如代码安全漏洞）等，避免缺陷向下游传递导致返工成本激增。评审需明确检查清单（如需求完整性、设计一致性）、记录问题并跟踪闭环。

e. 测量

理解内容：通过定义与项目目标强相关的量化指标（如需求变更频率、缺陷密度、代码行生产率、测试覆盖率、用户满意度），系统性地收集数据并进行分析，以客观反映项目状态（如当前进度是否符合预期）、过程效率（如开发迭代周期时长）、产品质量（如缺陷修复响应时间）。测量结果不仅用于当前项目的决策支持（如调整资源投入），还可为组织级过程改进提供数据依据（如优化需求管理流程）。

f. 软件配置管理（SCM）

理解内容：本质是通过版本控制工具（如Git/SVN）和配置管理流程，对软件开发过程中产生的所有工作产品（如代码、文档、配置文件、测试脚本）进行标识（唯一版本号）、控制（变更需审批）、状态记录（谁在何时修改了什么）和审计（验证变更是否符合规范），重点管理因需求变更、缺陷修复、功能迭代等引发的变更影响（如某个模块修改是否导致其他模块兼容性问题），确保团队始终基于正确的版本协作，避免“版本混乱”导致的交付风险。

g. 可复用性管理

理解内容：旨在通过建立组织级的可复用资产库（如通用组件、业务模块、设计模式、工具类库），并对资产的创建、评估、存储、检索和复用过程进行规范化管理（如定义复用标准、记录资产使用场景与效果），主动推动开发团队优先选用已验证的高质量复用资产（而非重复造轮子），从而提升开发效率（减少重复劳动）、降低成本（共享维护资源）、保证一致性（统一技术实现），最终形成组织的知识沉淀和技术竞争力。

h. 工作产品的准备和生产

理解内容：聚焦于明确软件开发各阶段所需交付的工作产品（如需求文档、设计模型、测试用例、用户手册）的具体内容、格式、质量要求及生产流程（如需求需经干系人确认、设计需通过评审），确保这些产物不仅是开发过程的中间输出，更是支撑后续活动（如编码、测试、运维）的关键输入。重点关注工作产品的完整性与可用性（如需求覆盖所有用户场景、测试用例匹配需求条目），避免因产物缺失或质量不达标导致项目阻塞或返工。

第二章

惯用过程模型

瀑布模型：线性顺序模型

1. 顺序的执行：沟通、策划、建模、构建、部署
2. 好处：

1. 1. 充分理解计划
  2. 适用于充分了解的小型项目
  3. 分析和测试是顺序线性的

1. 问题：

1. 1. 实际的项目很难遵守顺序
  2. 客户难以一次性说清楚需求
  3. 客户要有耐心，因为只有等完整开发结束才能拿到产品
  4. 在评审程序之前，无法发现错误

原型开发过程模型：

关键词：客户只给基本任务/开发也对算法/os/人机交互没把握先开发功能简单原型(瀑布模型) 好：足够小，掉头方便不好：视野局限/实现折中

1. 客户定义了软件的基本任务，没有详细阐明功能和特征；开发人员对算法的效率、操作系统的适用性、人机交互的形式也没产出确切的把握。于是双方确定好——先开发一个功能简单的原型。一个原型本质就是一个微小的瀑布模型。
2. 好处：

1. 1. 变更需求对后续设计影响很小
  2. 客户很早就频繁参与设计中
  3. 小型项目效果好
  4. 产品失败概率低

1. 原型开发过程模型的问题：

1. 1. 利益相关方只看到了眼前软件工作版本，没有意识到原型本身也在演化，会错失对软件质量和长期可维护性的把握
  2. 软件工程师为了让原型尽快跑起来，实现过程中采取折中的手段而不是最优的设计

演化过程模型（螺旋模型）：

1. 螺旋模型将软件开发归纳为一系列演进的版本，早期迭代是原型，后来迭代会产生一系列完整的系统版本
2. 螺旋第一圈一般开发出产品的规格说明，接下来开发原型系统。每次迭代中逐步完善。螺旋每次都会跨过策划区域，此时会调整项目计划，根据交付后用户反馈调整预算和进度，同时调整需要开发完整项目的迭代次数
3. 其他过程模型在软件交付后就结束了，螺旋模型会关注整个软件的生命周期。在每一个演进层次上，开发者和用户都可以很好的理解和应对风险。螺旋模型要求在项目所有阶段始终考虑技术风险
4. 螺旋模式的好处：

1. 1. 有持续不断的用户参与
  2. 开发风险得到控制
  3. 适合大型复杂项目
  4. 适合可拓展的产品

1. 螺旋模式的风险：

1. 1. 依赖大量风险评估专家来保证成功

统一过程模型(客户)：

l. 核心理念

注释：统一过程模型认识到客户沟通和从客户的角度描述系统的并且保持该描述一致性的重要性，强调软件体系的重要作用。
详解：

- 客户沟通与一致性：UP认为软件开发不是一次性收集需求，而是贯穿整个项目周期的持续对话。它使用用例作为核心工具，从用户（客户）的角度来描述系统功能（即“谁”为了“什么目的”要“做什么”）。这确保了所有开发人员、测试人员和客户都对系统行为有统一、一致的理解。
- 强调软件体系结构：UP要求在项目早期就建立并验证一个稳定、可扩展的系统架构。对客户而言，这意味着系统的基础是牢固的，能够适应未来的需求变化，降低了项目因技术债务而失败的风险。一个好的架构是应对需求变更的基石。

m. 优势

ⅰ. 重视质量文档

- 详解：UP要求在每个阶段和迭代中产生特定的工件（文档、模型等），如用例模型、设计模型等。对客户来说，这提供了项目的透明度和可追溯性。客户可以清晰地看到需求是如何被设计、实现和测试的，便于审计和知识传承，减少了因人员流动导致的项目风险。

ⅱ. 有持续不断的客户参与

- 详解：与瀑布模型（客户主要在开始和结束参与）不同，UP的每个迭代周期（通常是2-6周）结束时，都会向客户交付一个可运行的软件增量，并获取反馈。这种持续的参与感让客户能够及时纠正偏差，确保项目始终朝着正确的方向前进，大大增强了客户对项目的控制力和信心。

ⅲ. 适合需求变更

- 详解：由于采用迭代开发，UP承认需求会随时间变化。新的需求或变更的需求可以被安排到后续的迭代周期中实现。这种灵活性使得项目能够更好地适应市场变化和客户业务需求的调整。

ⅳ. 对维护项目很有效

- 详解：UP的迭代和增量模式与软件维护（修复缺陷、增加新功能）的工作方式非常契合。每个维护版本或功能更新都可以被视为一个小的迭代项目，遵循相同的起始、细化、构建、移交的 disciplined 过程，使得维护工作更有条理，而非混乱的“打补丁”。

n. 劣势

ⅰ. 用例并非永远准确

- 详解：用例主要描述系统的功能需求，但可能无法完美覆盖所有非功能需求（如性能、安全性、用户体验等）。此外，客户或用户可能在开始时无法通过用例完整、精确地表达所有隐含需求，导致早期用例存在不完整性或歧义，需要在后续迭代中不断澄清和修正。

ⅱ. 具有复杂软件增量集成

- 详解：在每次迭代中，团队需要将各个开发人员完成的功能模块集成成一个可工作的增量。随着项目进行，系统越来越复杂，集成工作的难度和风险也会显著增加。如果自动化集成和测试做得不好，集成阶段可能会成为项目的瓶颈，甚至引发大量缺陷。

ⅲ. 阶段重叠带来问题

- 详解：UP的四个阶段（初始、细化、构建、移交）在时间上并非完全割裂，而是有所重叠。例如，在“构建”阶段后期，可能已经开始了对早期功能的“移交”（测试和部署）工作。这种重叠需要精细的项目管理和团队协作，否则容易造成混乱，例如，开发人员还在修改代码，而测试人员已经开始基于不稳定的版本进行测试。

ⅳ. 需要专家团队

- 详解：要成功实施UP，对团队成员的要求较高。需要系统架构师能设计出稳健的架构，需要分析师能熟练运用用例技术捕捉需求，需要项目经理能熟练地进行迭代规划和风险管理。如果团队经验不足，很容易将UP退化为一种缺乏纪律的、混乱的“ hacking ”，反而失去了其流程规范化的优势。

极限编程(XP)

记住：客户直接参与/测试驱动/结对编程

好处（优点）：

- ∙质量高：测试先行，且常采用结对编程，代码错误少、质量好。
- ∙很灵活：能快速响应客户需求变化，避免无效开发。
- ∙风险低：客户全程参与，可及时看到可用成果，项目不易偏离预期。
- ∙知识共享：代码共有，避免因个别成员离职导致项目受阻。

∙坏处（缺点和挑战）：

- ∙客户压力大：需客户投入大量时间配合，现实中较难实现。
- ∙团队容易累：持续沟通和结对编程对成员精力和纪律要求高。
- ∙设计可能太简单：侧重当前需求，未来扩展时可能需大幅调整。
- ∙不适合大项目：协调难度随团队规模增大，更适合小规模集中团队。

第三章

什么是敏捷

敏捷是一种以人为核心、迭代、循序渐进的开发方法。它强调团队协作、客户合作，以及对变更的快速响应能力，旨在通过持续交付有价值的软件来满足客户需求。与传统的瀑布模型不同，敏捷方法认为需求和解决方案会在项目进行中不断演变，因此团队需要具备高度的灵活性和适应性。

敏捷宣言

敏捷软件开发宣言（The Agile Manifesto）是敏捷方法的指导思想，由17位软件开发者于2001年共同提出。它包含四个核心价值和十二个原则。

四个核心价值：

个体与互动 高于流程与工具

1. 注释：优秀的团队成员和顺畅的沟通是项目成功的关键。虽然流程和工具重要，但人的能动性和协作更能解决复杂问题。

可工作的软件 高于详尽的文档

1. 注释：衡量进展的首要标准是交付可以正常运行的软件，而不是文档的完备程度。敏捷强调简洁的文档，但并非完全不要文档。

客户合作 高于合同谈判

1. 注释：与客户建立伙伴关系，通过持续沟通和反馈来明确需求，比固守合同条款更能交付真正有价值的产品。

响应变化 高于遵循计划

1. 注释：项目进行中需求变更是不可避免的。敏捷团队能够拥抱变化，并利用变化为客户创造竞争优势，而不是死板地遵循一个固定的计划。

需要强调的是：宣言在肯定左侧项价值的同时，并未完全否定右侧项的重要性。例如，流程、工具、文档、合同和计划仍然有其价值，只是当面临选择时，应更侧重于左侧项所代表的方向。

敏捷开发的定义

敏捷开发是一系列遵循敏捷宣言价值观和原则的开发方法论的总称（如Scrum、极限编程XP、看板等）。其核心在于通过短周期的迭代（通常为1-4周），在每次迭代中完成一个小的、可交付的功能增量，从而快速获得反馈，并据此调整后续开发方向。这种“小步快跑、持续验证”的模式，极大地降低了项目失败的风险。

敏捷与变更成本

在传统的瀑布开发模型中，变更的成本会随着项目时间的推移呈指数级增长。因为在项目后期（如测试或上线阶段）才发现需求错误或需要变更，将导致大量前期工作（如设计、编码）需要返工，代价高昂。

而敏捷方法通过其迭代和增量的特性，有效地控制了变更的成本。由于每个迭代周期短，并能快速交付和验证，问题和变更可以在早期就被发现和响应。这使得变更成本的增长曲线变得更为平缓，团队能够以可接受的代价来适应变化，从而将变更从一种“威胁”转变为一种“机遇”。

什么是敏捷过程？

敏捷过程并不是一个单一的、固定的流程，而是一个基于敏捷思维框架的实践集合。一个典型的敏捷过程通常包含以下关键实践：

迭代开发：将项目分解为一系列固定时长的小周期（迭代）。
需求待办列表：一个动态的、按优先级排序的需求列表，作为产品开发的唯一需求来源。
每日站会：团队每日进行15分钟左右的简短会议，同步进度、发现障碍。
评审会：在每个迭代结束时，向客户或利益相关者演示已完成的工作，并获取反馈。
反思会：在迭代结束后，团队共同反思如何改进流程和效率，并付诸行动。

常见的敏捷过程框架包括：

Scrum：强调通过固定角色的分工（产品负责人、Scrum主管、开发团队）和固定的事件（冲刺规划会、每日站会、评审会、反思会）来管理迭代过程。
看板：通过可视化工作流（看板板）和限制在制品数量，来实现持续交付和流程优化。
极限编程：包含大量具体的工程实践（如结对编程、测试驱动开发、持续集成），旨在提高软件质量和响应能力。

第四章

无内容

第五章

软件团队-技术和管理上的差异

要从技术和管理上关注
有凝聚力的团队：目标意识，参与意识，信任意识，进步意识
团队毒性：

1. 混乱的工作氛围
2. 造成团队成员分裂的挫败
3. 支离破碎或协调不当
4. 对软件团队中角色的模糊定义
5. 持续可重复性的失败

第六章

需求工程的定义与七个核心任务

1 起始

注释：这是需求发现的起点。识别项目的主要利益相关者，定义项目的目标和范围，并初步了解核心问题和机遇。在此阶段，需求以非常高层和模糊的形式出现。

2 获取

注释：也称为需求收集。通过访谈、问卷调查、研讨会、观察用户工作等方式，从客户、用户和其他利益相关者那里主动收集详细的需求信息。这个阶段的关键是深入理解真实需求。

3 细化

注释：对获取到的原始、混乱的需求信息进行加工。包括进行分析、分类、整合、排序，并识别出需求之间存在的模糊、不一致、遗漏或冲突之处。这是一个创造性的分析过程。

4 协商

注释：由于资源有限，不同利益相关者的需求可能存在冲突。此任务旨在通过协商，确定各项需求的优先级、平衡不同方的期望，并就“做什么”和“何时做”达成共识。通常需要做出权衡。

5 规格说明

注释：将协商一致的需求以清晰、结构化、可验证的文档形式固定下来。产出物通常是软件需求规格说明（SRS）。它可能包含用户故事、用例模型、功能需求列表、非功能需求定义等，是后续设计和测试的基础。

6 确认

注释：也称为需求验证。目的是确保需求规格说明是准确的、完整的，并且符合用户的真实意图。通常通过需求评审、原型演示等方式，让利益相关者检查并确认SRS是否正确无误。

7 需求管理

注释：这是一个贯穿始终的持续性任务。在项目进行中，需求变更是不可避免的。需求管理包括建立流程来跟踪、控制和管理需求的变更，维护需求的可追溯性，并确保所有相关人员都基于最新版本的需求进行工作。

开发用例的核心要素-编号-用例描述，参考P75

用例示例：预约医生门诊

1. 用例名称：

预约医生门诊

2. 主要参与者：

患者（或为患者代劳的家属）

3. 目标：

患者成功预约到未来某个特定日期和时间段的医生门诊号源。

4. 前提条件：

患者必须已经在该医疗系统注册并拥有一个有效的账户。
患者的账户必须处于正常（非冻结）状态。
系统必须正常运行，且与医院排班数据库连接正常。

5. 触发器：

患者登录系统后，点击主界面上的“预约挂号”按钮。

6. 场景（基本流程）：

系统验证患者登录状态，并显示可预约的科室列表。
患者选择目标科室（例如：“心血管内科”）。
系统显示该科室下所有可预约的医生列表及其未来7天的可预约时间概况。
患者选择一位医生（例如：“张伟医生”）。
系统显示张伟医生未来7天的详细可预约时间段（如：09:00-09:15, 09:15-09:30...）。
患者选择一个未被预约的时间段（例如：明天 10:00-10:15）。
系统要求患者确认预约信息（医生、时间、患者姓名）。
患者确认预约。
系统锁定该号源，生成一个唯一的预约号，并将状态标记为“已预约”。
系统向患者显示预约成功的页面，包含预约详情和预约号。

7. 异常（扩展流程）：

3a. 无可用科室/医生：

- 如果系统检索不到任何可预约的科室或医生，系统将显示提示信息“当前无可预约资源，请稍后再试”，并结束用例。

6a. 时间段已被占用：

- 如果患者在步骤6选择的时间段在确认前已被他人预约，系统将显示错误信息“您选择的时间段已被预约，请重新选择”，并返回步骤5，显示更新后的可预约时间段。

8a. 患者取消确认：

- 如果患者在步骤8选择“取消”，系统将放弃本次预约，释放锁定的号源，并返回医生详情页面。

9a. 系统提交失败：

- 如果在系统保存预约时发生错误（如数据库连接失败），系统将显示错误信息“系统繁忙，预约失败，请重试”，并记录错误日志。用例结束。

8. 优先级：

高。这是系统的核心功能，直接面向最终用户（患者），是实现线上服务的关键。

9. 何时可用：

在“用户身份验证与授权”模块和“医生排班管理”模块开发完成并集成之后可用。

10. 使用频率：

预计每天会被使用数百至数千次，取决于医院的规模。

11. 主要参与者使用方式：

患者通过Web浏览器或移动App与系统进行交互。这是一个典型的用户主动发起的请求/响应式交互。

12. 次要参与者：

医院排班系统： 提供医生和可预约时间段的原始数据。
短信/邮件网关服务： （可选）在预约成功后，向患者发送确认短信或邮件。
支付系统： （如果支持在线支付挂号费）处理支付请求。

13. 次要参与者使用方式：

医院排班系统： 在本用例中，预约系统会主动调用其API来查询和锁定号源。这是一种“服务”被调用的关系。
短信/邮件网关服务： 预约系统在用例成功完成后，异步调用该服务发送通知。这是一种单向的“通知”关系。
支付系统： 如果在预约流程中集成支付，系统会调用支付接口，并等待其返回支付结果。这是一种同步的“协作”关系。

14. 未解决的问题：

预约成功后，患者是否可以修改或取消预约？如果可以，规则是什么（例如，必须提前2小时）？
一个患者在同一时间段内是否允许为不同的科室预约？（即，防止号贩子）
是否需要设置“黑名单”机制？例如，对于多次预约但未就诊的患者，是否应限制其预约功能？
是否支持“候补预约”？当某个时间段已满时，患者可以排队，如果有人取消则自动补位。

第七章（重点）- 场景/类/功能/行为

UML图绘制PPT如下：一定要会画图

📎UML.ppt

建模原则：

设计应可追溯到需求模型。
始终考虑要构建系统的体系结构。
数据设计与处理功能设计同等重要。
接口（内部和外部）的设计必须谨慎。
用户界面设计应适应最终用户的需求。
构件级设计应在功能上独立。
构件应彼此松耦合，并应与外部环境松耦合。
设计表示（模型）应易于理解。
设计应迭代式开发。
设计模型的创建并不排除采用敏捷方法的可能性。

基于场景建模

基于场景的需求建模

基于场景的建模是需求工程的核心实践，它通过描述系统在未来运行时的具体故事（即场景）来捕获、阐明和分析功能需求。这种方法以用户为中心，易于利益相关者理解，是连接模糊的用户需求和精确的技术规格说明之间的关键桥梁。

1. UML对需求建模：用例图、活动图、序列图

UML提供了多种图形化工具来支持不同粒度和不同视角的场景建模。

a) 用例图 - 系统功能的上下文视图

目的：定义系统的边界，概括性地展示系统与外部参与者（用户、其他系统）的交互，以及系统提供的主要功能单元（用例）。它提供了系统功能的“目录”或“目录”。
核心元素：

- 参与者：系统外部与系统交互的实体（如用户、硬件设备或其他系统）。用小人图标表示。
- 用例：系统为参与者提供的、可产生有价值结果的功能单元。用椭圆表示。
- 系统边界：一个方框，将用例框在里面，参与者在外面，清晰地划分了系统内外。

关系：

- 关联关系：连接参与者和用例，表示二者之间存在交互。
- 包含关系：表示一个用例的行为包含了另一个用例的行为。被包含的用例是必需的。例如，“支付”用例总是“包含”“验证信用卡”用例。
- 扩展关系：表示一个用例的行为可以被可选地扩展到另一个用例中。扩展用例在特定条件下才执行。例如，“下单”用例可以被“使用优惠券”用例“扩展”。
- 泛化关系：类似于面向对象中的继承，表示一个子用例可以继承父用例的行为并增加自己的特性。

示例（在线购物系统）：

- 参与者：顾客、管理员、支付网关
- 用例：浏览商品、搜索商品、加入购物车、下订单、支付、管理库存
- 关系：支付用例 包含验证信用卡用例；下订单用例可以被 使用优惠券用例 扩展。

b) 活动图 - 描述业务或操作流程

目的：描述一个用例或一个业务流程内部的详细执行步骤、决策点和并行活动。它类似于流程图，但更强大，支持并行性。
核心元素：

- 开始节点/结束节点：标示流程的开始和结束。
- 活动：代表流程中的一个执行步骤或操作。
- 控制流：箭头，表示活动之间的执行顺序。
- 决策节点/合并节点：菱形。决策节点根据监护条件（如[余额充足]）将流程导向不同分支；合并节点将多个分支汇合。
- 分岔节点/结合节点：粗黑线。用于表示并行活动的开始和结束。

应用：非常适合描述复杂的业务逻辑，例如“订单处理”流程，可能涉及并行执行的库存检查和支付验证。

d) 序列图 - 对象间的交互时序视图

目的：按时间顺序展示特定场景执行过程中，系统内部对象之间以及对象与参与者之间传递消息的序列。它强调交互的时序性。
核心元素：

- 生命线：代表场景中的一个对象或参与者，用垂直虚线表示，其存在的时间段。
- 激活条：生命线上的矩形条，表示对象处于活动状态、执行某个操作的时间段。
- 消息：生命线之间的水平箭头，表示调用、通信或数据传递。可以是同步消息、异步消息、返回消息等。

应用：当需要深入理解一个用例场景背后，系统各个组件如何协作以完成功能时，序列图是最佳选择。例如，绘制“用户成功支付”这个场景的序列图，可以清晰看到顾客、支付界面、支付控制器、信用卡验证器、数据库等对象之间按时间顺序的消息交互。

2. 参与者和用户概要文件

a) 参与者

参与者不是系统的一部分，而是与系统进行交互的任何事物。识别参与者是需求分析的第一步。

主要类型：

- 主要参与者：为达成特定目标而使用系统服务的用户或系统（如顾客）。他们是用例的驱动者。*- 辅助参与者：为系统提供服务的外部系统（如支付网关、短信服务平台）。
- 幕后参与者：对系统行为感兴趣但不直接参与交互的实体（如政府审计系统）。

b) 用户概要文件

用户概要文件是对参与者（特别是人类用户）的详细描述，它是“以用户为中心”设计思想的具体体现。一个典型的用户概要文件（或人物角色）包括：

基本信息：角色名称（如“新手顾客”、“资深采购员”）。
职责/目标：他们希望通过系统完成什么任务。
特征：年龄、计算机熟练程度、领域知识水平等。
使用环境：在什么场景下使用系统（如办公室、移动中）。
需求和期望：对系统的功能性及非功能性期望。

示例 - 用户概要文件：新手顾客李华

目标：快速、安全地购买到心仪的商品，不希望过程复杂。
特征：25岁，白领，熟悉手机App操作，但对在线支付安全性有顾虑，追求效率。
使用场景：通勤地铁上，利用碎片时间浏览和下单。
需求：界面简洁直观，搜索精准，支付流程安全且步骤少，有清晰的订单状态跟踪。

创建用户概要文件有助于开发团队在设计和开发过程中始终牢记真实用户的需求，避免设计出偏离用户期望的系统。

3. 创建用例

用例是描述参与者与系统之间为达到特定目标而进行的一系列交互的文本叙述。一个结构良好的用例是需求规格说明的核心。

创建用例的步骤：

识别参与者和目标：基于用户概要文件和初步分析，列出所有主要参与者及其希望通过系统达成的目标。每个目标都可能成为一个用例。
写出主成功场景：这是最典型、无任何错误的交互流程。按步骤（1， 2, 3...）清晰描述参与者的动作和系统的响应。
列出扩展场景：考虑主成功场景中每一步可能出现的异常或分支情况（如输入错误、资源不可用、用户取消操作等），并描述系统应如何处理。
细化前置和后置条件：

- 前置条件：在用例开始执行前，系统必须满足的条件（如“用户已登录”）。
- 后置条件：在用例成功结束后，系统所处的状态（如“订单已生成，库存已扣减”）。

用例模板示例：

用例名称	下订单
参与者	顾客（主要）
描述	顾客将购物车中的商品生成一个待支付的订单。
前置条件	顾客已登录，购物车中至少有一件商品。
后置条件	新订单被创建，状态为“待支付”。
主成功场景	1. 顾客点击“去结算”。 2. 系统显示订单确认页面（商品列表、收货地址、总价）。 3. 顾客确认信息无误，点击“提交订单”。 4. 系统创建订单，清空购物车，并跳转到支付页面。
扩展场景	2a. 顾客需要修改收货地址： 2a1. 顾客点击“修改地址”。 2a2. 系统允许顾客选择或新增地址，然后回到步骤2。 3a. 提交时某商品库存不足： 3a1. 系统提示库存不足，并将该商品从订单中移除。 3a2. 用例回到步骤2，显示更新后的订单信息。
特殊需求	性能：订单生成响应时间应小于2秒。

总结

基于场景的建模是一个迭代的过程：从识别参与者和用户概要文件开始，创建高层的用例图来划定范围，然后为每个关键用例编写详细的用例描述，对于复杂的业务流程可以用活动图来厘清，最后对技术实现关键场景用序列图进行深入剖析。这套方法确保了需求从用户视角到系统内部设计的平滑过渡，是软件工程中确保软件质量的第一步，也是至关重要的一步。

基于类建模

定义/三个核心要素/每个要素的作用

定义：

三个核心要素：

SOP：

识别分析类：

1. 外部实体：其他系统/设备/人员
2. 事物：报告/显示/字母/信号
3. 偶发事件：所有权转移or机器人的一组移动动作
4. 角色：经理/工程师/销售人员
5. 组织单元：部门/组/团队
6. 场地：制造车间或者码头
7. 结构：传感器/四轮交通工具...

定义属性和操作：

1. 以某种方式操纵数据：CRUD
2. 执行计算的操作
3. 请求讴歌对象的状态的操作
4. 监视某个对象发生某个控制事件的操作

UML类模型

1. 类图标由三个部分组成：第一个部分是类名，第二个部分是属性，第三个部分是操作。

- 公有可见性（+）：对能看到这个类的任何元素都可见。
- 保护可见性（#）：对这个类及其子类的其他元素可见。
- 私有可见性（-）：对这个类的其他元素可见。
- 包可见性（~或者*）：对同一个包中的其他元素可见。

一、关系分类逻辑

先按等级分：平等 vs 不平等
再按时间分：临时 vs 永久

二、六种关系详解

依赖（Dependency）

- 等级：平等 | 时间：临时
- 本质：临时借用工具
- 代码：方法参数、局部变量
- 例子：订单临时使用支付工具

关联（Association）

- 等级：平等 | 时间：永久
- 本质：长期合作关系
- 代码：成员变量（单个引用）
- 例子：客户长期拥有地址

聚合（Aggregation）

- 等级：不平等 | 时间：永久
- 本质：松散的整体-部分
- 代码：成员变量（容器），部分来自外部
- 例子：团队拥有成员，但成员可独立

组合（Composition）

- 等级：极度不平等 | 时间：永久
- 本质：紧密的整体-部分，同生共死
- 代码：成员变量，在构造函数创建
- 例子：汽车拥有引擎，引擎随汽车消亡

继承（Generalization）

- 本质：is-a 父子关系
- 代码：extends
- 例子：狗继承自动物

实现（Realization）

- 本质：履行接口契约
- 代码：implements
- 例子：类实现接口方法

三、快速判断流程

临时使用？→ 是：依赖
父子关系？→ 是：继承
实现接口？→ 是：实现
整体-部分关系？

- 是：部分能独立？能→聚合，不能→组合
- 否：关联

四、核心区别

依赖/关联：平等合作关系（临时/永久）
聚合/组合：不平等拥有关系（松散/紧密）
继承/实现：分类与契约关系

类-职责-协作者模型

1. 类就是被识别出的类
2. 职责：属性和操作
3. 协作：类来实现职责

1. 1. 类用自身的操作控制各自的属性，实现特定的职责
  2. 类可以和其他类协作

功能建模

过程视图

UML顺序图

行为建模

评估所有的用例，保证完全理解系统的交互顺序
识别驱动交互的事件，理解事件如何与特定的对象相互关联
为每个用例生成序列
创建系统状态图
评审行为模型来验证准确性和一致性

UML状态图

根据圆角矩形中的内容是动宾短语还是名词，可以区分是活动图还是状态图。

UML活动图

第八章

定义

设计概念：

1. 抽象
2. 体系结构
3. 设计模式
4. 关注点分离
5. 模块化
6. 信息隐蔽
7. 功能独立
8. 逐步求精
9. 重构
10. 设计类

体系结构(如何在泳道图中体现高内聚)

体系结构并非可运行的软件。确切地说，它是一种表达，使能够：

(1) 在满足既定的需求方面下，分析设计有效性：满足需求是必须的，但是要思考——是否全部的设计都是有效的？

(2) 在设计变更相对容易的阶段，考虑体系结构可能的选择方案：体系结构的设计应该在编码的早期，这样不用做大的修改。

(3) 降低与软件构造相关的风险：要选择尽量稳妥的方案，也就是要降低风险

模块化思想(含义与概念)

模块化是为了使一个复杂的大型程序能被人的智力所管理，软件应该具备的惟一属性。
如果一个大型程序仅由一个模块组成，它将很难被人所理解。

系统的模块数目增加，每个模块的规模减小，开发单个模块的成本减小，但是，随着模块数目增加，设计模块间接口的工作量增也加。所以随着模块数目的增加，系统的总成本先降低后增加，总成本曲线出现一个最小成本区。如果一个大型程序仅有一个模块，它将很难被人所理解，模块化的目的之一是为了让一个大型的程序更容易被人所理解。

采用模块化原理可以使软件结构更加清晰，更加易于阅读和理解。程序错误通常出现在部分模块及它们间的接口，所以模块化思想使软件更加容易测试和调试，提高了软件的可靠性，模块化使得一个大型的程序分解成不同的模块，对难易程度不同的模块可以分配技术熟练程度不同的程序员编写，有助于软件开发的组织管理。模块化的缺点是会造成性能损耗，系统逐步分层，调用链长，模块间通信很耗性能。

逐步求精中每一层中的模块都是对系统抽象层次的一次精化。软件结构顶层的模块,控制系统的主要功能。软件结构底层的模块,完成对数据的一个具体处理，软件结构中，首先抽象出系统的主要功能，然后逐步实现低层细节采用自顶向下，由抽象到具体的方式分配控制，提高了软件的可理解性和可测试性。

信息隐藏与局部化。在软件结构中，各个模块间的信息应该彼此相对独立，隐藏模块的实现细节，仅允许访问其他模块中为了完成系统功能所需要的的信息，在模块中使用局部数据元素有助于实现信息隐藏。编写系统的不同模块时，可以根据实际需要自由命名局部变量。模块独立的概念是模块化、抽象、信息隐藏和局部化概念的直接结果。

第九章

什么是体系结构(核心目标3个/定义)

定义：

体系结构并非可运行的软件。确切地说，它是一种表达。

核心目标：

1. a: “分析设计在满足既定需求方面的有利性”

通俗解释： 这句话的意思是，体系结构是一个蓝图。在动手建造之前，我们先画好蓝图，用来分析和评估这个设计是否有利于实现我们所有的目标（即“既定需求”）。
核心思想： 体系结构不是代码本身，而是代码之上的一个抽象模型。这个模型帮助我们提前思考和推理，确保我们的设计方案是“好”的，是能够满足性能、安全、可扩展性等所有关键需求的。
简单来说： “用设计图来证明方案可行。”

2. b: “在设计变更相对容易的阶段，考虑体系结构的选择方案”

通俗解释： 在纸上改设计图很容易，但大楼盖到一半想改结构就难了。软件也一样，在写代码之前（即“设计变更相对容易的阶段”），体系结构要求我们充分考虑各种不同的技术选择和设计方案（比如用微服务还是单体架构？用哪种数据库？）。
核心思想： 体系结构的活动主要发生在项目早期，目的是降低后期修改的代价。提前做出正确的、经过深思熟虑的技术决策，可以避免项目后期因为架构问题而推倒重来的巨大风险。
简单来说： “在画图阶段多比较几种方案，避免盖楼时拆墙。”

3. c: “降低与软件构建相关风险的方式”

通俗解释： 这是对a和b的总结，点明了体系结构的根本目的。软件构建有很多风险，比如：性能不达标、无法维护、无法扩展、团队协作混乱、项目超期超预算等。一个好的体系结构正是为了识别和降低这些风险。
核心思想： 通过提前规划（定义a）和审慎选择（定义b），我们将很多潜在的技术风险和管理风险（如沟通成本）在早期就化解掉。体系结构是一种风险管理工具。
简单来说： “用提前规划来避免项目做不下去或做出来没法用。”

第十章

设计基于类的构件

功能内聚：最佳实践

功能内聚是最高级别的内聚形式，被视为设计的黄金标准。

学术说明

一个被设计为功能内聚的模块有且仅有一个明确的、单一的功能目标。模块内的所有代码元素都协同工作以完成这个单一功能，不存在任何与核心功能无关的操作。这类模块的命名通常可以直接反映其功能，例如 CalculateInterest或 ValidateEmailFormat。它完美遵循了单一职责原则。

主要特点

职责绝对单一：模块的存在只为完成一件事。任何修改都源于其单一功能的变更需求。
高度可复用：由于其功能纯粹且接口明确，可以在系统的任何需要该功能的地方被轻松调用。
易于测试与维护：输入、处理和输出流程清晰，便于编写单元测试。当需要修改时，影响范围被严格限制在该模块内部。

实际生产例子

微服务架构中的身份认证服务

- 服务名称：UserAuthenticationService
- 核心功能：专门负责验证用户身份（例如，处理登录、验证令牌）。
- 内聚性分析：该服务不处理用户资料更新（属于用户档案服务），不负责权限分配（属于授权服务），其唯一焦点就是身份认证。所有代码都围绕这一核心功能组织，是功能内聚的典范。

工具函数

- 函数名称：sanitizeUserInput(inputString)
- 核心功能：对用户输入的字符串进行净化和转义，以防止安全漏洞。
- 内聚性分析：该函数仅专注于输入净化这一件事。它不进行数据持久化，也不执行业务逻辑判断。任何需要处理用户输入的地方都可以调用它，具有极高的可复用性。

分层内聚：良好的顺序处理

分层内聚在实践中非常常见且有效，尤其适用于数据处理流程。

学术说明

分层内聚是指模块包含一系列顺序执行的处理步骤，前一个步骤的输出是后一个步骤的输入，形成一个处理流水线。这些步骤在逻辑上属于同一个更高级别的任务范畴。虽然模块内包含多个子步骤，但由于它们通过数据流紧密连接，并为同一个宏观目标服务，因此仍被认为是内聚性较好的设计。

主要特点

顺序执行与数据流驱动：处理过程是线性的、分阶段的，数据在各个环节间依次传递和变换。
明确的流程目标：整个模块有一个清晰的高级目标，例如“数据预处理流水线”。

实际生产例子

数据ETL管道

- 模块名称：DataProcessingPipeline
- 处理流程：

1. 1. 提取：从源系统（如数据库、API）读取原始数据。
  2. 转换：对数据进行清洗、验证、格式标准化和计算衍生字段。
  3. 加载：将处理后的高质量数据载入目标数据仓库或数据库。

- 内聚性分析：这三个步骤必须按顺序执行，且共同服务于“将原始数据转换为可用数据”这个统一目标。整个管道是一个内聚的、逻辑上紧密相关的整体。

网络请求中间件链

- 处理流程：一个HTTP请求依次通过以下中间件：

1. 1. 请求日志记录：记录请求的元数据。
  2. 身份验证：验证用户凭证。
  3. 授权检查：确认用户拥有访问权限。
  4. 速率限制：防止滥用。
  5. 业务逻辑处理器：最终处理请求。

- 内聚性分析：这些中间件构成了一个处理层级，请求像水流一样依次流过每一层，每一层对其执行特定操作。它们共同完成了“安全可靠地处理Web请求”这个高层任务。

通信内聚：需要警惕的设计信号

通信内聚是一种较低的内聚性，通常表明设计存在缺陷。

学术说明

通信内聚是指模块中的各个部分或函数被组合在一起的唯一理由，是它们都在操作或处理同一组数据（或数据结构）。然而，这些操作在功能上彼此之间没有必然的逻辑联系。这种设计通常是由于错误地将一个数据结构的所有相关操作都机械地集中在一个模块中导致的。

主要问题

职责模糊：模块的职责边界不清晰，难以用一个准确的名字概括其功能，容易演变成“上帝对象”。
可维护性差：修改一个功能可能会意外影响到模块内其他不相关的功能，因为它们共享同一个上下文和数据。
耦合度高：不同关注点的功能被捆绑在一起，导致模块与外部系统的依赖关系复杂。

实际生产例子

设计不佳的CustomerManager类

- 包含的方法：

- - updateCustomerAddress(customerId, newAddress)
  - calculateCustomerLifetimeValue(customerId)
  - sendBirthdayGreetingEmail(customerId)
  - generateCustomerInvoiceReport(customerId)

- 内聚性分析：

- - 共同点：这些方法都以customerId为参数，都“围绕”客户数据。
  - 问题：但它们的功能本质完全不同。更新地址是数据持久化操作，计算生命周期价值是数据分析，发送邮件是消息通知，生成报告是数据呈现。将它们强行塞进一个类中，使得这个类承担了过多不相关的职责。
  - 重构方向：应将其拆分为多个高内聚的类，如：

- - - CustomerRepository：负责数据增删改查。
    - CustomerAnalyticsService：负责计算分析指标。
    - NotificationService：负责处理所有通知。
    - ReportGeneratorService：负责生成报告。

总结对比

内聚类型	核心原则	模块职责清晰度	可维护性	实际应用评价
功能内聚	只做一件事	极高	极高	最佳实践，应作为首要设计目标
分层内聚	有顺序的数据处理	高	高	良好且实用，常见于流程化处理场景
通信内聚	操作相同数据但功能不同	低	低	设计警示信号，应识别并重构

在实际软件开发中，开发者应当持续追求功能内聚，合理运用分层内聚来组织清晰的流程，并时刻警惕和重构出现的通信内聚，以构建出健壮、灵活且易于维护的系统。

耦合性

传统观点：一个组件连接到其他组件和外部世界的程度。

面向对象的观点：耦合是类之间彼此联系程度的一种定性度量。耦合是必然存在的。

软件工程中的耦合类型详解

耦合性衡量的是软件系统中模块之间相互依赖的紧密程度。与追求高内聚相反，软件设计的目标是实现低耦合，即模块间尽可能独立，从而使系统更易于理解、维护和修改。以下是几种常见的耦合类型，按强度从高到低排列。

内容耦合

内容耦合是程度最高、也是最有害的耦合类型，在现代结构化程序设计中应严格避免。

当一个模块直接访问或修改另一个模块的内部数据、内部逻辑或执行流程时，就发生了内容耦合。这破坏了模块的封装性，使得模块的边界名存实亡。

具体表现为模块直接修改另一个模块的内部数据，或者直接跳转至另一个模块的内部逻辑。

在实际生产中，例如在一个C程序中，某个模块通过全局指针直接修改另一个模块内部用于管理数据库连接状态的私有变量。这种做法会导致系统极度脆弱，如果被修改模块的内部实现发生改变，修改模块将立即失效，且这种错误在编译时可能无法发现。同时，由于问题的根源可能出现在被侵入的模块中，但原因却来自外部模块的非法操作，会导致调试异常困难。这完全破坏了信息隐藏这一基本的软件设计原则。

公共耦合

公共耦合的强度很高，在设计中应尽量避免或严格控制。

多个模块共同访问和修改同一个全局变量、全局数据结构或共享的存储区时，就会产生公共耦合。模块通过这些共享环境间接地产生联系。

具体表现为多个模块都直接读写同一个全局变量，或者多个服务实例同时读写同一个数据库表中的某一行，且逻辑上相互影响。

例如，一个应用有一个全局的当前用户对象。用户界面模块用它来显示用户名，权限检查模块用它来检查权限，日志记录模块用它来记录操作日志。当某个模块修改了全局用户对象的某个字段时，可能会意外导致其他模块出现异常或逻辑错误。这种耦合的主要问题在于会产生连锁反应，当全局数据出现异常值时，很难确定是哪个模块在何时修改了它。同时，在单元测试时，测试每个模块前都必须先正确设置复杂的全局状态，测试之间容易相互干扰。

外部耦合

外部耦合是一种相对可接受的耦合，源于模块需要与外部系统协作的现实。

当模块之间通过外部环境相关联时，就会产生外部耦合。这些外部环境包括共享的文件格式、数据库结构、网络通信协议或第三方服务的应用程序编程接口。

具体表现为多个模块都必须遵循同一个特定的文件格式，或者多个服务都必须与同一个数据库进行交互，并依赖于特定的表结构。

例如，一个前端应用和一个后端应用程序编程接口通过表征状态传输应用程序编程接口进行通信。它们共同耦合于应用程序编程接口的接口规范，包括端点统一资源定位器和请求响应数据格式。这种耦合的主要问题是，如果外部接口发生变更，所有依赖它的模块都必须同步进行修改和测试。例如，数据库结构的变更往往需要同时修改多个访问它的服务。

控制耦合

控制耦合是一种中等强度的耦合，在设计中应保持警惕，并思考是否能优化。

当一个模块通过向另一个模块传递控制信号来显式地控制被调用模块的内部逻辑流程时，就产生了控制耦合。这些控制信号包括标志、开关参数等。

具体表现为调用模块时传递一个标志参数，被调用模块内部根据这个参数的值执行不同的分支逻辑。

例如，有一个渲染用户界面函数，当传入完整格式参数时，它渲染用户的完整详细信息视图；当传入摘要格式参数时，它只渲染摘要卡片。这种耦合的主要问题是调用方需要了解被调用方的内部逻辑，调用者必须知道被调用函数内部有不同的逻辑分支，并正确传递参数，这增加了心智负担。同时，被调用方职责不单一，承担了多种功能，违反了单一职责原则，内聚性降低。更好的设计是消除控制标志，将不同功能拆分为两个高内聚的函数，如分别创建渲染完整用户档案函数和渲染用户摘要卡片函数，这样就能将耦合降低到更理想的数据耦合级别。

我在实习中遇到过这个问题：当时我们在开发一款Devops平台，在Dashboard看板，我们提供了一个接口，通过传入optype字段为manage/add/remove来决定对一个program的操作。这里前端如果不清楚后端有哪些分支逻辑，就会导致控制耦合的出现

第十一章

用户体验设计的核心定义(一定会考)

用户体验设计（User Experience Design，简称UXD或UED）是一种以用户为中心的设计方法，旨在通过满足用户需求来提升产品的使用体验。用户体验设计贯穿于产品开发的整个过程，从最早期的概念设计到最终的产品发布。

书上写的是：策略/范围/结构/框架/界面

首先，一个关键点是，这五个层次实际上涉及网站或产品两个方面的思考，它们像两条平行线一样贯穿始终：

作为“功能型”产品的本体：软件如何工作（功能、交互）。
作为“信息型”媒介的呈现：信息如何被获取和认知（内容、信息）。

现在我们开始从底层到顶层讲解：

1. 策略层 - “我们为什么要做这个产品？用户想要什么？”

核心问题： 产品目标是什么？商业目标是什么？用户需求是什么？
工作内容： 确定项目愿景，进行用户研究，分析市场机会，定义成功标准。
产出物： 产品战略文档、用户画像、用户需求列表、商业案例。
外卖App例子：

- 产品目标： 成为本地最快捷的外送平台，增加订单量和用户粘性。
- 用户需求： 用户想快速找到想吃的食物、方便地支付、准时收到外卖。

理解： 这是地基。如果没想清楚“为什么做”，上面所有层都可能建歪。

2. 范围层 - “我们要做哪些功能？提供哪些内容？”

核心问题： 产品应该包含什么功能？内容范围有多大？
工作内容： 将策略层的用户需求转化为具体的功能需求清单和内容需求。定义功能优先级，确定项目范围。
产出物： 产品需求文档、功能规格说明、内容大纲。
外卖App例子：

- 功能： 餐厅搜索、菜品浏览、购物车、在线支付、订单跟踪。
- 内容： 餐厅介绍、菜品图片和描述、用户评论。

理解： 在地基上，画出房子的功能分区图——几个卧室、几个卫生间。防止项目范围无限扩大（范围蔓延）。

3. 结构层 - “这些功能和信息如何被组织起来？用户如何与之互动？”

核心问题： 产品的流程是怎样的？信息如何分类和组织？
工作内容：

- 交互设计（针对功能）： 设计用户完成任务的流程。例如，下单流程需要几步？
- 信息架构（针对信息）： 设计信息的组织方式，如何分类、导航，让用户容易找到内容。

产出物： 用户流程图、网站地图、信息架构图。
外卖App例子：

- 交互设计： 用户下单流程是：选菜 -> 加购 -> 结算 -> 支付 -> 等待。
- 信息架构： 餐厅是按“美食分类”（中餐、西餐）组织，还是按“距离”组织？

理解： 设计房子的动线（从客厅到厨房怎么走）和房间布局（书放在书房还是卧室）。

4. 框架层 - “每个页面的具体布局是怎样的？按钮和菜单放在哪里？”

核心问题： 界面元素如何安排？导航如何呈现？
工作内容：

- 界面设计： 安排界面元素（按钮、输入框、图片）的位置，方便用户使用功能。
- 导航设计： 设计全局导航、局部导航，帮助用户知道自己在哪里，能去哪里。
- 信息设计： 如何呈现信息，使其清晰易懂（比如用图表还是列表）。

产出物： 线框图、导航规范。
外卖App例子：

- 底部Tab栏有“首页”、“订单”、“我的”三个主要入口。
- “首页”顶部是搜索框，下面是轮播图，再下面是餐厅列表。
- “结算”按钮是固定在页面底部还是跟随页面滚动？

理解： 画出每个房间的详细施工图，标出门窗、插座、家具的具体位置。

5. 表现层 - “产品看起来怎么样？给人的感觉如何？”

核心问题： 产品在视觉上如何呈现？
工作内容： 视觉设计，包括配色方案、字体排版、图标设计、图片风格等。旨在通过视觉传达品牌形象，营造情感共鸣，并优化信息的可读性和易用性。
产出物： 视觉设计稿、高保真原型、风格指南。
外卖App例子：

- 主色调是激发食欲的橙色还是代表干净的蓝色？
- 用什么字体？logo设计成什么样？图片是写实风格还是插画风格？

理解： 进行室内外装修、粉刷墙面、选择家具和装饰品，最终决定房子的“颜值”和“感觉”。

黄金规则(一定会考)

把控制权交给用户
减轻用户的记忆负担
保持界面一致

预估可能的重点

分析角色和主要动作

判断分支极其作用

泳道图

活动图

分析其内聚性和耦合性，讲下如何体现高内聚低耦合的

新加规则，你该怎么把这个规则融入流程里

今年必考题：

1.简述用户体验设计的核心定义和三条原则

核心定义：

用户体验设计是指以用户为中心，通过系统化的设计方法，创造产品在可用性、可访问性、情感体验等方面的最佳用户交互体验，确保用户能够高效、愉悦地完成目标任务。

三条黄金规则：

让用户拥有控制权：设计应当让用户感受到对交互的掌控，提供灵活的交互方式，允许用户中断和撤销操作。1
减少用户的记忆负担：设计应尽量降低用户需要记住的信息量，通过提供清晰的提示、默认值和上下文帮助来减轻认知负荷。3
保持界面的一致性：在视觉、交互和术语等方面保持统一，使用户能够建立稳定的心理模型，提高学习效率和使用流畅度。3

2.软件概要设计的定义和三个核心任务

定义：

概要设计是软件开发中将需求分析转化为系统逻辑模型的关键阶段，通过模块划分和接口设计构建软件结构，同时根据用户交互过程和需求形成交互框架与视觉框架。14

三个核心任务：

模块划分：将软件系统按照高内聚低耦合的原则，拆分成符合业务需求的功能模块，确定整体软件结构及模块的划分。12
接口设计：定义模块之间的调用与返回关系，设计模块接口数据结构，明确各模块之间的交互方式和数据传递机制。13
系统架构设计：确定软件体系结构、构件关系以及整体应用框架，为详细设计阶段提供清晰的系统蓝图和设计指导。18

3.活动图与泳道图的绘制(高内聚与低耦合)

企业员工培训成果审核流程建模（20 分）企业员工培训成果审核流程如下：员工登录 “企业培训管理系统”，上传培训结业报告及考核成绩证明，提交审核申请；系统自动校验：①考核成绩是否≥60 分（成绩不达标则驳回并提示重考）；②是否在培训结束后 7 个工作日内提交（超时则驳回）；校验通过后，系统判断培训类型：若为 “技术类培训”，申请先提交给技术部门主管审核；若为 “管理类培训”，申请先提交给人力资源部门初审；技术部门主管 / 人力资源部门审核通过后，申请流转至企业培训办复核；审核不通过则退回员工并附修改意见；企业培训办复核通过后，系统生成 “审核通过” 回执并同步至员工个人档案；复核不通过则终止流程，员工需重新参加培训或补充材料。

要求：

（1）列出该流程的核心参与者（角色），并简述其在流程中的核心动作；（3 分）

（2）指出流程中最关键的两个分支判断点，说明其对流程走向的影响；（4 分）

（3）绘制泳道图（5 分）：以 “员工、培训管理系统、技术部门主管、人力资源部门、企业培训办” 为泳道，标注各角色的核心活动（如 “员工上传结业报告”）及活动间的流转关系（用箭头表示）；

（4）绘制活动图（5 分）：聚焦 “系统双校验→培训类型分支→多级审核” 环节，需包含开始节点、结束节点、活动节点、分支 / 合并节点，并标注分支条件（如 “考核成绩≥60 分？”“是否为技术类培训？”）；

（5）结合软件设计的 “模块化” 思想，说明：①该流程中 “多级审核” 环节如何体现 “高内聚、低耦合” 原则；（2 分）②若流程新增 “考核成绩在 60-79 分之间需额外提交培训心得”，活动图应如何调整？（1 分）

1）核心参与者（角色）及核心动作（3分）

员工：

- 核心动作：登录系统，上传培训结业报告及考核成绩证明，提交审核申请；根据审核意见修改并重新提交材料，或重新参加培训。

培训管理系统：

- 核心动作：自动校验成绩是否达标、提交是否超时；根据培训类型自动分配审核路径；流转申请单；生成并发送审核回执，同步结果至员工档案。

技术部门主管：

- 核心动作：对“技术类培训”的申请进行专业性审核，做出通过或退回（附意见）的决定。

人力资源部门：

- 核心动作：对“管理类培训”的申请进行初审，做出通过或退回（附意见）的决定。

企业培训办：

- 核心动作：对所有通过初审的申请进行最终复核，做出通过（流程结束）或不通过（终止流程）的最终决定。

（2）最关键的两个分支判断点及影响（4分）

系统自动校验分支点（成绩与时效校验）

- 判断条件：考核成绩是否≥60分，且是否在培训结束后7个工作日内提交。
- 对流程走向的影响：此分支是流程的“准入关卡”。若任一条件不满足，系统将直接驳回申请，流程终止，员工需处理当前问题（重考或因超时无法继续）。只有双项校验均通过，申请才会进入后续的实质审核环节。此判断点决定了流程能否正式开始。

培训类型判断分支点

- 判断条件：培训类型是“技术类培训”还是“管理类培训”。
- 对流程走向的影响：此分支决定了后续审核路径的走向。若为技术类培训，申请流转至技术部门主管；若为管理类培训，则流转至人力资源部门。此判断点实现了审核任务的专业化分流，确保了审核的准确性和效率。

（3）泳道图（5分）

（4）流程图（5分）

（5）模块化思想应用（3分）

① “多级审核”环节如何体现“高内聚、低耦合”原则（2分）

高内聚：将“多级审核”设计为一个独立的审核模块。该模块内部封装了完整的审核逻辑，包括接收申请、根据规则（如培训类型）路由至相应的审核角色、记录各环节审核结果、以及向后续环节传递结果等。所有这些与“审核”密切相关的功能都聚集在同一模块内，职责单一且完整。
低耦合：该审核模块通过定义清晰的接口与流程中的其他部分交互。例如，它只需从上游接收一个“校验通过的申请”对象，而无需关心校验的具体细节；它向下游（如档案模块）也只传递“最终审核结果”这一明确信息。如果未来审核规则发生变化（如增加审核部门），只需修改此模块内部逻辑，而不会影响前期的校验环节或后续的归档环节，体现了模块间的低耦合。

② 新增“提交培训心得”要求的活动图调整（1分）

在活动图的“系统自动校验”环节后、判断“培训类型”之前，增加一个决策节点。

调整方案：在“校验通过”后，增加一个判断节点 “考核成绩是否在60-79分之间？”。

- 如果“是”，则增加一个活动节点 “员工上传培训心得”，该活动完成后，再进入“判断培训类型”节点。
- 如果“否”（即成绩≥80分），则直接进入“判断培训类型”节点。

这样调整确保了新需求被嵌入流程，且逻辑清晰。

4.软件工程团队中，技术角色与管理角色的核心职责有什么差异？各举两个具体角色说明。

技术角色：

工程师：负责具体的代码编写与实现，将需求文档转化为计算机可以执行的指令
系统架构师：负责系统的顶层设计与技术选型，保证系统的可拓展性，安全性和性能

管理角色：

项目经理：负责进度控制与风险管理，确保项目在规定的时间和预算内完成
研发经理：负责人员管理和团队建设，关注下属的成长，绩效考核，招聘解聘以及团队文化的建设。

今年大概率可能考的题目：

1.CRC建模- 类-职责-协作者模型

定义：CRC建模提供了一个简单方法，可以识别和组织与系统或者产品需求相关的类 (需求建模的一个环节)

1. CRC模型可以看作是索引卡的集合
2. 每一个索引卡左侧都有一个职责列表
3. 索引卡的右侧是履行这些职责对应的协作者
4. 职责是类相关的属性和操作
5. 协作：采取一种或者两种特定方法来实现特定的职责

1. 1. 类可以使用自身的操作控制各自的属性，从而实现特定的职责
  2. 类可以和其他类协作，要识别协作可以通过确认类本身是否能够实现自身的每个职责。

1. 协作者是提供完成某个职责所需要的信息或者动作的类

好的，这是对CRC模型评审过程的详细注释，解释了每个步骤的目的和意义。

2. CRC模型的评审：

a. 参加CRC评审的人员拿到一部分CRC模型索引卡

注释：评审开始前，将代表不同“类”的索引卡分发给所有评审参与者。这样做是为了让每个人都具体地“扮演”一个或多个类的角色，参与到动态的用例场景模拟中，而不是仅仅作为一个被动的听众。这有助于提高参与度和集中注意力。

b. 每个评审员不能有两张存在协作关系的卡片

注释：这是为了保证评审的客观性和发现潜在的设计问题。如果一个评审员同时持有两个需要紧密协作的类（例如，“订单”类和“订单明细”类），他可能会在潜意识里忽略这两个类之间本该存在的复杂交互逻辑，因为他已经提前知道了“答案”。将存在协作关系的卡片分开，可以强制这些交互必须通过明确的“协作”来体现，从而暴露出沟通不清晰的接口或缺失的职责。

c. 评审组长细致阅读用例，他看到一个已经命名的对象时，给有相应类索引的人员一个令牌

注释：评审组长作为“导演”，引导整个评审过程。他按照预先写好的“用例”（即用户故事或功能场景）来推进。令牌（可以是一个实物，如硬币，或只是一个象征）代表当前系统的“控制权”或“焦点”。当用例中提及某个对象（如“系统创建一个新订单”），控制权就交给代表该对象（“订单”类）的参与者。这模拟了程序执行过程中对象的创建和激活。

d. 当令牌传递时，该类卡的拥有者要描述卡上记录的职责，评审组确定职责是否满足用例需求

注释：这是评审的核心环节。拿到令牌的评审员必须大声说出他的“类”在当前场景下应该承担什么“职责”（即类的方法或行为）。然后，整个团队（而不仅仅是组长）共同判断：

1. 这个职责是否合理？
2. 这个类是否已经定义了相应的职责来完成它？
3. 单靠这个类自己能完成吗？是否需要其他类（协作方）的帮助？这个过程旨在动态地验证CRC模型是否能正确实现用例所描述的功能，并检查职责分配是否得当。

e. 如果发现错误，需要对索引卡修改，修改包括定义新类，或者在已有的类上修改职责和协作列表

注释： CRC评审是一个高度迭代和动态的设计过程，其首要目的是发现设计缺陷，而不是简单地走流程。当在步骤d中发现问题时，应立即在现场修改索引卡。常见的修改包括：

- 职责不清晰或缺失：在已有的类卡上增加或修改职责。
- 协作关系缺失或错误：在协作列表中添加、删除或修改协作类。
- 职责分配不当：将一个职责从一个类转移到另一个更合适的类。
- 发现新的类：当某个职责无法由现有任何类承担时，就需要创建一张新的类卡。这正是面向对象设计中“发现对象”的关键过程。

总结： CRC模型评审是一种通过角色扮演和场景模拟来验证面向对象设计的手段。它利用索引卡、令牌等实体工具，将静态的类图转化为动态的交互过程，从而在编码之前高效、低成本地发现软件架构中的职责分配和协作关系问题。

2.简答题押题：

（1）请简述 “软件过程改进” 的定义，并列举 3 种常见的软件过程改进模型（如 CMMI、SPICE 等，需简要说明各模型核心特点）

软件过程改进是指通过系统性地分析、评估和优化软件开发与维护的流程、方法及实践，以提高软件产品质量、开发效率和团队能力的一系列活动。

常见模型包括：

CMMI（能力成熟度模型集成）：核心特点是将组织的过程能力划分为 5 个等级（初始级、可重复级、已定义级、量化管理级、优化级），通过阶段性改进实现过程标准化和量化管理。
SPICE（ISO/IEC 15504）：核心特点是提供过程评估的国际标准框架，通过过程能力维度（0~5 级）和过程性能维度进行评价，支持跨行业对标。
敏捷开发（如 Scrum、XP）：核心特点是迭代式开发、持续交付和快速响应变化，通过短周期迭代和用户反馈优化过程。

（2）请简述 “需求获取” 的定义，并列出 4 种常用的需求获取方法（如访谈法、问卷调查法等，需说明各方法适用场景）

需求获取是通过与用户、利益相关者交流，系统性地收集、分析和定义软件系统需满足的功能与非功能需求的过程。

常用方法包括：

访谈法：适用于需深入理解特定用户需求的场景（如关键用户个性化需求挖掘）。
问卷调查法：适用于需求范围广、需快速收集大量用户意见的场景（如大众软件的功能偏好调查）。
观察法：适用于用户难以准确描述操作流程的场景（如现场观察工作流程以发现隐性需求）。
原型法：适用于需求不明确或需快速验证的场景（通过可交互原型收集用户反馈）。

（3）请简述 “UML 时序图” 的核心作用，并列出其 4 个核心组成元素（如对象、生命线、消息等）及表示方式

UML 时序图的核心作用是描述对象之间动态交互的时间顺序，重点展示消息传递的时间线。

核心组成元素包括：

对象：表示为矩形框，内部标注对象名称（如 UserController）。
生命线：从对象向下延伸的虚线，表示对象存在的时间段。
消息：生命线之间的水平箭头，标注消息名称（如 login()），表示方法调用或信号传递。
激活条：生命线上的窄矩形，表示对象执行操作的时间段。

（4）请简述 “软件架构风格” 的定义，并列举 4 种经典的软件架构风格（如客户机 / 服务器、分层架构等，需说明各风格核心特征）

软件架构风格是描述系统组件组织方式、交互模式和设计原则的抽象模式。

经典架构风格包括：

客户机/服务器：核心特征是功能分离，服务器集中提供资源或服务，客户端发起请求（如 Web 应用）。
分层架构：核心特征是层次化分工，每层仅依赖相邻下层（如表现层、业务层、数据层）。
微服务架构：核心特征是将应用拆分为小型独立服务，通过轻量级通信协作（如 RESTful API）。
事件驱动架构：核心特征是组件通过事件发布/订阅解耦，异步响应变化（如消息队列处理订单）。

（5）请简述 “软件测试” 的定义，并区分单元测试、集成测试、系统测试的核心测试范围与测试目标（各举 1 例说明）

软件测试是通过执行程序发现缺陷，评估软件是否满足需求的过程。

区别如下：

单元测试：测试范围是单个代码单元（如函数、类），目标是验证逻辑正确性（例如测试“计算运费”函数的结果）。
集成测试：测试范围是模块间的接口，目标是检查数据传递与协作（例如测试“用户登录模块”与“数据库模块”的交互）。
系统测试：测试范围是整个系统，目标是从用户角度验证功能完整性（例如测试“在线支付流程”端到端是否成功）。

（6）软件工程中，“耦合” 的定义是什么？请列举 4 种常见的耦合类型（按耦合程度从高到低排序），并说明各类型的表现形式

耦合指模块之间相互依赖的程度，高耦合会导致系统难以维护。

常见类型（从高到低）：

内容耦合：一个模块直接修改或依赖另一模块的内部数据（如模块 A 直接修改模块 B 的局部变量）。
控制耦合
外部耦合

（7）请简述 “用户界面（UI）设计” 与 “用户体验（UX）设计” 的核心区别，并列出 UI 设计中需遵循的 3 条视觉设计原则

UI 设计关注界面的视觉呈现（如布局、色彩），UX 设计关注用户使用产品的整体体验（如流程效率、情感反馈）。

UI 设计的视觉原则包括：

一致性：保持界面元素（按钮、字体）风格统一，降低用户学习成本。
层次清晰：通过大小、颜色对比突出重要信息（如主要按钮用醒目色）。
简洁性：避免无关元素，减少界面干扰（如使用留白聚焦核心功能）。

（8）开发用例规约需包含哪些核心部分（如前置条件、后置条件等）？请以 “企业图书馆管理系统‘图书续借’功能” 为例，编写完整的用例规约

用例规约核心部分包括：用例名称、参与者、前置条件、后置条件、基本事件流、扩展事件流、异常流程。

示例：

用例名称：图书续借
参与者：读者
前置条件：用户已登录系统，且所借图书未超最大续借次数。
后置条件：图书借阅期延长，系统更新归还日期。
基本事件流：

1. 用户进入“我的借阅”列表；
2. 选择需续借的图书，点击“续借”按钮；
3. 系统验证图书可续借（未逾期、未超次数）；
4. 系统更新归还日期，显示“续借成功”。

扩展事件流：

- 3a. 若图书已超续借次数：系统提示“续借次数已用尽”，用例结束。

异常流程：

- 3b. 若用户借书已逾期：系统提示“逾期图书不可续借”，用例结束。

3.分析题：

请阐述软件工程中 “敏捷开发” 与 “瀑布模型” 的核心差异（从需求管理、开发流程、文档要求、风险控制 4 个维度对比），并结合一个具体项目场景（如社交 APP 迭代开发、企业管理系统定制开发），分析在该场景下选择敏捷开发的优势及需规避的潜在问题（需说明规避策略）。

好的，我们来详细阐述敏捷开发与瀑布模型的核心差异，并结合具体项目场景进行分析。

一、敏捷开发与瀑布模型的核心差异对比

对比维度	瀑布模型	敏捷开发
需求管理	前期固定：要求在项目初期明确并固化所有需求。需求变更在开发中后期代价高昂，难以接受。客户在开发过程中参与度低，主要在开始（需求确认）和结束（验收）时介入。	持续演进：接受并拥抱需求变化。需求以“用户故事”的形式存放在产品待办列表中，在每个迭代周期内按优先级动态调整和细化。客户或产品负责人全程深度参与。
开发流程	顺序式、阶段化：严格按照需求分析、设计、编码、测试、维护的顺序进行。前一阶段不结束，后一阶段不开始。像一个瀑布，逐级下落。	迭代式、增量式：将整个项目划分为一系列短周期（通常为1-4周，称为迭代或冲刺）。每个迭代都完成一个小型、可交付的功能增量，逐步构建完整产品。
文档要求	重文档：极度依赖文档。每个阶段都必须产生详尽、规范的文档（如需求规格说明书、设计文档等），作为下一阶段的输入和凭证。文档工作量巨大。	轻文档，重可工作软件：认为可运行的软件胜过面面俱到的文档。文档以“刚刚好”为原则，强调团队成员和客户之间的直接沟通。文档多为即时性的（如任务卡、迭代计划）。
风险控制	后期暴露风险：由于集成和测试都集中在开发末期，技术风险、需求理解偏差等重大风险往往在项目后期才被发现，此时纠正成本极高，容易导致项目失败。	早期且持续化解风险：每个迭代结束时都会产生一个可演示的软件增量，能快速获得用户反馈，及时纠正偏差。技术难题和高风险任务可以优先在早期迭代中解决，持续降低项目不确定性。

二、具体项目场景分析：社交APP迭代开发

我们以一款新型社交APP（例如，主打“兴趣圈子匹配”的社交应用）的迭代开发为例进行分析。

为什么选择敏捷开发？

对于社交APP这类面向海量用户、市场竞争激烈、需求瞬息万变的项目，敏捷开发具有压倒性优势：

应对市场不确定性：没人能在一开始就完全确定什么样的功能最能吸引用户。敏捷允许团队根据上线后用户的真实反馈和数据（如A/B测试结果、用户行为分析），快速调整后续版本的功能优先级。例如，原计划下个迭代做“虚拟礼物”功能，但数据发现“匿名树洞”功能更受欢迎，可以立即调整开发计划。
快速验证与试错：通过每个迭代发布一个最小可行产品或新功能，可以快速投入市场进行验证。如果某个功能不受欢迎，可以迅速放弃，将损失降到最低，避免在错误的方向上投入数月时间。
持续交付价值：可以每隔几周就向应用商店发布一次更新，持续为用户带来新功能，提升用户粘性和活跃度，保持市场竞争力。
有效控制技术风险：可以将“第三方登录集成”、“消息推送稳定性”等技术难点放在早期迭代中攻克，避免在项目后期才发现无法实现，导致整个项目延期或重构。

需规避的潜在问题及规避策略

尽管敏捷非常适合此类项目，但如果实施不当，也会带来以下问题：

潜在问题	描述	规避策略
1. 范围蔓延与迭代目标模糊	产品负责人可能不断加入新想法，导致单个迭代内容过多，目标不聚焦，团队疲于奔命，最终无法在迭代结束时完成承诺的功能。	策略： • 严格执行迭代规划会：在迭代开始时，团队根据自身速率（Velocity）共同承诺本次迭代要完成的任务量，一旦承诺，迭代期间原则上不加入新需求。 • 维护清晰的产品待办列表：产品负责人必须持续梳理和优化待办列表，明确每个用户故事的优先级，确保团队始终在开发最有价值的功能。
2. 技术债累积	为了追求快速交付，团队可能采取“走捷径”的编码方式（如不写测试、复制粘贴代码、忽略重构），导致代码质量下降，形成“技术债”。长期下来，系统会变得难以维护，开发效率急剧下降。	策略： • 定义“完成”标准：明确约定每个功能的“完成”必须包含代码审查、自动化测试、文档更新等。 • 专设重构迭代/故事：定期（如每3-4个迭代一次）安排专门的时间用于偿还技术债和重构代码。 • 持续集成：每次代码提交都自动触发构建和测试，快速发现集成问题。
3. 对团队成员要求高	敏捷强调沟通、协作和自我管理。需要团队成员（尤其是产品负责人和Scrum Master）具备较强的专业能力和软技能。如果团队成员不适应或能力不足，敏捷会流于形式。	策略： • 持续培训与引导：引入专业的敏捷教练对团队进行培训，特别是在项目初期。 • 营造开放、信任的团队文化：定期召开有效的复盘会议，鼓励团队成员坦诚讨论问题和改进点，共同成长。
4. 缺乏宏观设计	过于关注短期迭代，可能导致系统架构缺乏长远规划，使得后续功能扩展困难，各个模块之间耦合度过高。	策略： • 推行“演进式架构”：在项目初期进行足够的架构探索，建立一套允许未来变化的架构原则和指引。同时，架构设计本身也是演进的，在每个迭代中根据新认知进行微调。 • 架构师深度参与：架构师不应脱离团队，而应作为团队成员之一，参与日常开发和迭代规划，确保技术决策与业务发展同步。

结论

在社交APP迭代开发这类需求多变、需要快速响应市场的项目中，敏捷开发通过其迭代、增量、拥抱变化的特点，相比线性的瀑布模型具有显著优势。它能极大地降低项目风险，加速价值交付。

然而，成功实施敏捷并非易事，需要团队（尤其是管理者和产品负责人）深刻理解其精髓，并通过严格的迭代纪律、对技术债的零容忍、持续的团队建设以及平衡的架构规划等策略，来规避其潜在的陷阱，最终发挥出敏捷开发的巨大威力。反之，如果项目需求极其稳定、变更很少（如某些军工、航天软件），或者有严格的法规和合同约束，瀑布模型可能仍是更合适的选择。

今年大概率考的简答题

1.黄金规则和用户体验设计的定义

核心定义：用户体验设计是指以用户为中心，通过系统化的设计方法，创造产品在可用性、可访问性、情感体验等方面的最佳用户交互体验，确保用户能够高效、愉悦地完成目标任务。

三条黄金规则：

让用户拥有控制权：设计应当让用户感受到对交互的掌控，提供灵活的交互方式，允许用户中断和撤销操作。1

减少用户的记忆负担：设计应尽量降低用户需要记住的信息量，通过提供清晰的提示、默认值和上下文帮助来减轻认知负荷。3

保持界面的一致性：在视觉、交互和术语等方面保持统一，使用户能够建立稳定的心理模型，提高学习效率和使用流畅度。3

2.用例的描述

用例的描述

用例的描述是软件工程中用于捕获系统功能需求的一种技术，它从用户视角描述了系统为达成一个特定目标而执行的一系列交互序列。一个结构化的用例描述通常包含以下要素：

1. 用例名称：

预约医生门诊

2. 主要参与者：

患者（或为患者代劳的家属）

3. 目标：

患者成功预约到未来某个特定日期和时间段的医生门诊号源。

4. 前提条件：

患者必须已经在该医疗系统注册并拥有一个有效的账户。
患者的账户必须处于正常（非冻结）状态。
系统必须正常运行，且与医院排班数据库连接正常。

5. 触发器：

患者登录系统后，点击主界面上的“预约挂号”按钮。

6. 场景（基本流程）：

系统验证患者登录状态，并显示可预约的科室列表。
患者选择目标科室（例如：“心血管内科”）。
系统显示该科室下所有可预约的医生列表及其未来7天的可预约时间概况。
患者选择一位医生（例如：“张伟医生”）。
系统显示张伟医生未来7天的详细可预约时间段（如：09:00-09:15, 09:15-09:30...）。
患者选择一个未被预约的时间段（例如：明天 10:00-10:15）。
系统要求患者确认预约信息（医生、时间、患者姓名）。
患者确认预约。
系统锁定该号源，生成一个唯一的预约号，并将状态标记为“已预约”。
系统向患者显示预约成功的页面，包含预约详情和预约号。

7. 异常（扩展流程）：

3a. 无可用科室/医生：

- 如果系统检索不到任何可预约的科室或医生，系统将显示提示信息“当前无可预约资源，请稍后再试”，并结束用例。

6a. 时间段已被占用：

- 如果患者在步骤6选择的时间段在确认前已被他人预约，系统将显示错误信息“您选择的时间段已被预约，请重新选择”，并返回步骤5，显示更新后的可预约时间段。

8a. 患者取消确认：

- 如果患者在步骤8选择“取消”，系统将放弃本次预约，释放锁定的号源，并返回医生详情页面。

9a. 系统提交失败：

- 如果在系统保存预约时发生错误（如数据库连接失败），系统将显示错误信息“系统繁忙，预约失败，请重试”，并记录错误日志。用例结束。

8. 优先级：

高。这是系统的核心功能，直接面向最终用户（患者），是实现线上服务的关键。

9. 何时可用：

在“用户身份验证与授权”模块和“医生排班管理”模块开发完成并集成之后可用。

10. 使用频率：

预计每天会被使用数百至数千次，取决于医院的规模。

11. 主要参与者使用方式：

患者通过Web浏览器或移动App与系统进行交互。这是一个典型的用户主动发起的请求/响应式交互。

12. 次要参与者：

医院排班系统： 提供医生和可预约时间段的原始数据。
短信/邮件网关服务： （可选）在预约成功后，向患者发送确认短信或邮件。
支付系统： （如果支持在线支付挂号费）处理支付请求。

13. 次要参与者使用方式：

医院排班系统： 在本用例中，预约系统会主动调用其API来查询和锁定号源。这是一种“服务”被调用的关系。
短信/邮件网关服务： 预约系统在用例成功完成后，异步调用该服务发送通知。这是一种单向的“通知”关系。
支付系统： 如果在预约流程中集成支付，系统会调用支付接口，并等待其返回支付结果。这是一种同步的“协作”关系。

14. 未解决的问题：

预约成功后，患者是否可以修改或取消预约？如果可以，规则是什么（例如，必须提前2小时）？
一个患者在同一时间段内是否允许为不同的科室预约？（即，防止号贩子）
是否需要设置“黑名单”机制？例如，对于多次预约但未就诊的患者，是否应限制其预约功能？
是否支持“候补预约”？当某个时间段已满时，患者可以排队，如果有人取消则自动补位。

3.概要设计的定义以及三大核心任务

定义：概要设计是软件开发中将需求分析转化为系统逻辑模型的关键阶段，通过模块划分和接口设计构建软件结构，同时根据用户交互过程和需求形成交互框架与视觉框架。14

三个核心任务：

模块划分：将软件系统按照高内聚低耦合的原则，拆分成符合业务需求的功能模块，确定整体软件结构及模块的划分。12

接口设计：定义模块之间的调用与返回关系，设计模块接口数据结构，明确各模块之间的交互方式和数据传递机制。13

系统架构设计：确定软件体系结构、构件关系以及整体应用框架，为详细设计阶段提供清晰的系统蓝图和设计指导。18

4.需求工程的定义和七个核心任务

需求工程的定义：需求工程指的是致力于不断理解需求的大量任务和技术。就软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通并且持续到建模活动。

1 起始

2 获取

3 细化

4 协商

5 规格说明

6 确认

7 需求管理

5.软件过程的定义，举例过程模型

过程框架定义了若干个框架活动

过程是事情进行或事物发展所经过的顺序
当开发产品或构件系统时，遵循一系列可预测的步骤（即路线图）是非常重要的，它有助于及时交付高质量的产品
软件开发中所遵循的路线图就称为”软件过程“

瀑布模型、原型模型、螺旋模型、统一过程模型、XP模型

6.(新)类建模的定义以及三个核心要素

类建模的定义：基于类建模是一套用于描绘系统静态结构的技术和规范。它通过定义系统中的类、类的内部构成（属性和操作）以及类与类之间的关系，来构建一个面向对象的软件模型。

三个核心要素：

类和对象
属性和方法
关系

7.软件团队职责上的差异：

技术角色：

工程师：负责具体的代码编写与实现，将需求文档转化为计算机可以执行的指令
系统架构师：负责系统的顶层设计与技术选型，保证系统的可拓展性，安全性和性能

管理角色：

项目经理：负责进度控制与风险管理，确保项目在规定的时间和预算内完成
研发经理：负责人员管理和团队建设，关注下属的成长，绩效考核，招聘解聘以及团队文化的建设。

8.体系结构的定义和三个核心目的

定义：软件的整体结构以及这种结构能为系统提供概念完整性的方式

体系结构并非可运行的软件。确切地说，它是一种表达，使能够：

(1) 在满足既定的需求方面下，分析设计有效性：满足需求是必须的，但是要思考——是否全部的设计都是有效的？

(2) 在设计变更相对容易的阶段，考虑体系结构可能的选择方案：体系结构的设计应该在编码的早期，这样不用做大的修改。

(3) 降低与软件构造相关的风险：要选择尽量稳妥的方案，也就是要降低风险

9.设计概念

定义：定义一套将软件分割为独立构件的标准，从软件的概念中分离出数据结构的细节，为定义软件设计技术质量确定标准

策略

抽象
体系结构
关注点分离
模块化
信息隐蔽
功能独立
逐步求精
重构

往年简答题

1.什么是软件过程？有哪些常见的过程模型？

过程是事情进行或事物发展所经过的顺序
当开发产品或构件系统时，遵循一系列可预测的步骤（即路线图）是非常重要的，它有助于及时交付高质量的产品
软件开发中所遵循的路线图就称为”软件过程“

常见的模型有：瀑布模型、原型模型、增量模型、螺旋模型

2.软件构件的内聚性指的是什么？

1.内聚性是构件的专一性。

2.内聚性意味着构件or类只封装那些相互关联密切，以及与构件或类本身有密切关联的操作。

3.常见的内聚性有：功能内聚、分层内聚、通信内聚。

3.工程的基础属性是什么？软件工程的主要特点是什么？

软件工程：把系统的、规范的、可度量的途径应用到软件开发、运行、维护的过程，也就是把工程应用于软件。

4.陈述四个软件过程模型

瀑布模型、原型模型、增量模型、螺旋模型

5.简述瀑布模型

瀑布模型，又称为经典生命周期。它提出来一个系统的顺序软件开发方法，从用户需求规格说明开始，通过计划、建模、构建和部署，提供一个完整的软件和持续的技术支持

6.简述敏捷软件开发宣言

1.个体和交互胜过过程和工具

2.可以工作的软件胜过面面俱到的文档

3.客户合作胜过合同谈判

4.响应变化胜过遵循计划

7.简述软件设计过程中应该遵循的基本原理

1.模块化

2.抽象

3.逐步求精

4.信息隐藏和局部化

5.模块独立

8.简述一个通用的软件工程过程框架包含哪五个活动？

1.沟通

2.策划

3.建模

4.构建

5.部署

9.谈谈你理解的软件开发的敏捷性

1.个体和交互胜过过程和工具

2.可以工作的软件胜过面面俱到的文档

3.客户合作胜过合同谈判

4.响应变化胜过遵循计划

10.软件工程的项目设计阶段可以使用哪些工具？

EA、ApiFox、Axure、Postman、PowerDesginer

11.名词解释：软件工程、数据字典、耦合、系统测试、软件维护

软件工程：把系统的、规范的、可度量的途径应用到软件开发、运行、维护的过程，也就是把工程应用于软件。

数据字典：关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合

耦合：对一个软件结构内不同模块之间互联程度的度量

系统测试：把经过测试的子系统装配成一个完整的系统的测试

软件维护：在软件交付使用后，为了改成错误和满足新的需要而修改软件的过程

12.什么是软件

1.软件是指令的集合，通过执行指令可以满足预期的特征、功能、性能的需求

2.其次软件还有数据结构与描述信息

13.什么是瀑布模型

瀑布模型，又称经典的生命周期。它提出来一个系统的顺序的软件开发方法，从用户需求规格说明开始，到策划，建模，构建，部署的过程，最终提供了一个完整的软件和持续的技术支持

14.简述极限设计的过程

1.严格坚持Keep it Simple 原则

2.鼓励使用CRC卡

3.在设计中遇到困难，推荐使用Spike解决方案

4.鼓励重构——已不改变代码外部行为而改进内部结构的方式来修改系统的过程

15.简述需求建模动作结果又哪些模型？

场景模型、面面向类的模型、基于行为和模式的模型、数据模型、面向流的模型

16.简述软件工程设计中包含了哪些设计以及这些设计的作用

1.数据和类的设计：将分析类模型变化为软件实现类模型与数据结构

2.体系结构的设计：描述软件主要构造元素之间的关系

3.接口的设计：描述软件元素，硬件元素和终端用户如何通信

4.构件级的设计：将软件体系结构的构造元素变化为对软件构件的过程性描述

17.简述一个通用的软件工程过程框架包含哪五个活动？

沟通、策划、建模、构建、部署

18.用自己的话来描述软件工程的敏捷性

1.个体和交互胜过过程和工具

2.可以工作的软件胜过面面俱到的文档

3.客户合作胜过合同谈判

4.响应变化胜过遵循计划

19.可以指导良好软件设计演化的三个特征

1.设计必须实现所有包含在需求模型的明确需求，满足相关利益人的需求

2.对于那些生成代码的人和测试的人而言，设计必须是可读可理解的指南

3.设计必须提供软件的全貌，从实现的角度讲明白：数据域、功能域、行为域

20.体系结构风格有哪些简单的分类？

1.以数据为中心的体系结构

2.数据流体系结构

3.调用和返回体系结构

4.面向对象体系结构

5.层系体系结构

21.简述基于类的构件的基本设计原则

1.开闭原则

2.Liskov替换原则

3.依赖倒置原则

4.接口隔离原则

5.发布复用等价性原则

6.共同封装原则

7.共同复用原则。