第一次接触北欧神话时，我也把九界理解成一张完整地图：世界树立在中央，九个世界整齐地挂在树冠、树干和树根上，像一套早已画好的游戏关卡。

真正翻到《埃达》之后，事情反而变得模糊。

现存文本确实反复提到“九个世界”，也不断写到阿斯加德、米德加德、约顿海姆、尼福尔海姆等地方；但它们没有给出一份同时包含九个名称、坐标和层级的标准说明书。我们今天最熟悉的九界图，通常是后人把散落在不同诗篇和章节里的线索重新拼在一起的结果。

这不是缺陷。恰恰是这种无法被彻底整理的部分，让北欧宇宙显得像一个仍在呼吸的传说，而不是已经封存的数据库。

“我记得九个世界”，然后呢？

《诗体埃达》开篇的《女巫的预言》（Völuspá）让女先知回忆远古、巨人、九个世界，以及世界树尚未完全生长时的状态。诗知道听众早已熟悉这些观念，所以没有停下来解释“第一界是什么、第二界在哪里”。

《散文埃达》写得更系统一些。斯诺里·斯图鲁松讲述了世界树的根、诸神的居所、冰雾与火焰的原初区域，也写到海拉被赋予管理“九个世界”亡者的权力。然而这些信息仍然散落在叙事里，而不是一张官方清单。

原因并不神秘：这些故事先在口头传统中流动，后来才由中世纪冰岛的书写者整理下来。早期诗歌默认听众拥有共同背景；后来的记录者又站在自己的时代与信仰环境中回望更古老的材料。我们能读到的是几层记忆叠在一起后的断面。

因此，比较诚实的说法不是“古诺斯人认定九界一定如下”，而是：

下面这组名称，是现代读者最常使用的一种整理；它方便阅读，但不是唯一、完整且无争议的古代标准。

这是一张关系图，不是距离精确的地理图。中心位置只表示从人类视角出发阅读，并不宣称米德加德在宇宙中拥有固定坐标。

一份常见但需要保留问号的九界表

问题就藏在表格看起来最整齐的地方。

有些整理会把 Nidavellir 与 Svartalfheim 合并，有些会分别保留；有些把 Hel 视为独立世界，有些更强调 Niflhel 与 Niflheim 的关系。甚至“九界”究竟应理解为九个封闭空间，还是九类地域、居所与存在状态，也不能用今天的地图概念轻易框死。

所以我没有给每个石片刻所谓“正统卢恩文”。主页上的图形是现代图标，不是考古复原；英文与中文名称则直接写明，让它们不靠神秘感冒充史实。

世界树更像关系，而不是置物架

把九界画成挂在树上的九颗果实很直观，但容易制造一种过度确定的错觉。

在《埃达》的叙事里，Yggdrasil 更接近一条维系秩序的生命结构：树根伸向泉与深处，诸神在树旁议事，生灵啃噬或穿梭其间；到了诸神黄昏，树与世界一起震动。它把命运、时间、生长、腐朽和不同存在联系起来，而不只是替世界提供九个插槽。

我因此把关系图画成围绕米德加德展开的读取路径，而没有画成“上三界、中三界、下三界”的硬性楼层。这样做不是为了发明另一套权威，而是承认：我们看到的是连接，不是坐标。

冰与火之间，先有一道空隙

北欧创世叙事最吸引我的，并不是世界被迅速填满，而是世界开始于一段巨大的空白——Ginnungagap（金伦加鸿沟）。

一侧是尼福尔海姆的冰、雾与寒冷，另一侧是穆斯贝尔的热与火。两股力量在鸿沟中接近，融化与凝结开始发生，生命从边界而不是中心出现。

主页上的“誓约印”到底在表达什么

现在点击 WINTEROMEN 中的日蚀，中央石印会蓄力，九块界石依次展开。

它表达的是一次阅读动作：

1. 日蚀收缩：视线从标题收回到一个入口。
2. 石印锁合：散乱信息先获得临时秩序。
3. 九界展开：名称、领域与符号同时显现，传说被允许阅读。
4. 再次点击关闭：这套秩序被收回，而不是永远占据页面。

九块石头没有被做成九个完全相同的按钮。轮廓、倾角、展开路径与象征图形都略有差异，因为九界并不是九个换皮组件。英文名负责远距离辨认，中文说明负责让第一次来访的人知道自己看见了什么；铭牌只有在石阵展开后才出现，不会长时间压住标题。

它的意义也不在于“证明我懂北欧神话”，而在于提醒我：整理知识时，可以建立结构，但不该把结构伪装成唯一真相。

传说不是数据库

现代人们习惯先找设定表：几个世界、谁住哪里、彼此怎么连接、战斗力如何排序。北欧神话偏偏不断抵抗这种整理。它来自不同时间、地点与讲述者，经历口传、记录、翻译和再解释；名称会重叠，边界会漂移，矛盾也不会自动消失。

我最终保留九界，不是因为这份名单毫无争议，而是因为它足够有代表性，也足够诚实地暴露争议。主页的石阵是一张可打开、可关闭的阅读索引；真正的九界仍然留在文本之间。

如果一张图让所有问题都消失了，它可能只是把神话画得太整齐了。

延伸阅读

• 《诗体埃达》英译本，Project Gutenberg
• 《散文埃达 / The Younger Edda》，Project Gutenberg
• 《女巫的预言》Bellows 英译与注释，Wikisource
• Nine Realms of Norse Cosmology，World History Encyclopedia

配图为本站生成与绘制的原创视觉素材；九界关系图属于现代阅读辅助，不代表唯一的古代宇宙模型。

基于课程全部12章PPT逐页深度分析 | 考试结构：选择题30分 + 简答题20分 + 应用题50分
教材：《Introduction to Systems Analysis and Design, 6th Edition》Satzinger, Jackson & Burd

任务一：全部知识点提取

【知识点1】软件的定义 (Software Definition)

定义：软件是计算机中与硬件相互依存的另一部分，是程序、数据及其相关文档的完整集合。

核心内容：

• 程序(Program)：按事先设计的功能和性能要求执行的指令序列
• 数据(Data)：使程序能够正确处理信息的数据结构
• 文档(Document)：与程序开发、维护和使用有关的图文资料

关键术语：Software = Program + Data + Document

重要细节：

• 软件是逻辑产品（非物理产品）
• 软件不会磨损和老化（但会退化——维护引入新错误）
• 软件依赖硬件运行
• 目前仍以手工开发为主
• 软件技术发展三阶段：程序设计→程序系统→软件工程

常见陷阱：选择题干扰项”软件=代码+文档”（缺少数据）；”软件不会退化”（物理不磨损但逻辑退化）

考试出现形式：填空”软件的三个组成部分”；选择”以下哪项不属于软件”

重要程度：⭐⭐ 高频

【知识点2】软件危机 (Software Crisis)

定义：在软件开发和维护过程中遇到的一系列严重问题。

产生原因（6条）：

1. 忽视前期调研和需求分析
2. 缺乏开发经验和数据积累
3. 缺乏统一的、规范化的方法论指导
4. 忽视与用户、团队间的有效沟通
5. 文档资料不规范或不准确
6. 没有完善的质量保证体系

主要表现（5条）：

1. 软件不能满足用户需求
2. 开发成本严重超标，周期大大超过规定日期
3. 软件质量难于保证，可靠性差
4. 软件难于维护
5. 软件开发速度跟不上计算机发展速度

解决方案：

• 技术措施：好的方法(Methods) + 好的工具(Tools)
• 管理措施：良好的组织、严密的管理

为什么推动软件工程产生：软件危机的严重性迫使人们将工程化原则引入软件开发，1968年NATO会议首次提出”软件工程”概念。

经典案例：

• IBM OS/360（1961-1964）：100万条指令，5000人年，5亿美元，2000+错误
• 美国银行信托系统（1982-1987）：预算2000万→6000万，最终放弃，失去340亿美元信托账户

考试常见问法：简答”简述软件危机的主要表现和原因”；选择”以下哪项不是软件危机的表现”

重要程度：⭐⭐⭐ 必考

【知识点3】软件工程的诞生与定义 (Birth of Software Engineering)

定义：软件工程是从技术和管理两方面研究如何更好地开发和维护计算机软件的学科。

核心内容：

• 1968年，NATO（北大西洋公约组织）计算机科学会议
• Fritz Bauer 首次提出”软件工程”概念
• Edsger Dijkstra 同年发表”GOTO Statement Considered Harmful”

Boehm七条基本原理（必须完整记忆）：

1. 用分阶段的软件生存周期计划进行严格的质量管理
2. 坚持进行阶段评审
3. 实行严格的产品控制
4. 采用现代程序设计技术
5. 软件工程结果应能清楚地审查
6. 开发小组的人员应该少而精
7. 承认不断改进软件工程实践的必要性

记忆口诀：”计评审控技，审精改”

重要程度：⭐⭐⭐ 必考

【知识点4】软件生存周期 (Software Life Cycle / SDLC)

定义：软件从立项到废弃的整个过程。

六大阶段：

SDLC支持阶段三大活动：

• 维护系统(Maintaining)：修复错误，做小调整
• 增强系统(Enhancing)：添加新功能
• 支持用户(Supporting Users)：培训，帮助台

重要程度：⭐⭐ 高频

【知识点5】SDLC两种方法 (Predictive vs Adaptive)

定义：

预测性方法(Predictive Approach)：项目可以提前完整规划，按计划顺序开发。典型代表：瀑布模型。假设需求明确、技术风险低。

适应性方法(Adaptive Approach)：项目必须灵活适应变化中的需求，始终包含迭代。典型代表：螺旋模型、敏捷。假设需求不确定、技术风险高。

核心要点：大多数项目处于预测性和适应性之间的连续谱(continuum)上。

常见陷阱：选择”瀑布模型是适应性方法”（错，是预测性）；”螺旋模型是预测性方法”（错，是适应性）

重要程度：⭐⭐⭐ 必考

【知识点6】结构化方法 (Structured Approach)

定义：将系统视为一组与数据交互的过程的集合。

三个阶段：

• 结构化分析(SA)：用数据流图(DFD)建立功能模型
• 结构化设计(SD)：将DFD转换为软件体系结构
• 结构化程序设计(SP)：用标准控制结构表示模块功能

结构化程序设计五原则：

1. 使用有限的基本控制结构（顺序/选择/循环）
2. 每个控制结构只有一个入口和一个出口
3. 语句组成容易识别的块(Block)
4. 复杂结构用基本控制结构组合嵌套实现
5. 严格控制GOTO语句

五种基本控制结构：顺序型、选择型、当型循环(While)、直到型循环(Until)、多情况选择型(Case)

描述工具：

• 结构图(SC)：矩形框=模块，空心圆=传数据，实心圆=传控制
• 程序流程图：五种基本结构的图形表示
• N-S图（盒图）：Nassi-Shneideman图
• PAD图（问题分析图）

四种模块类型：

• 原子模块(Atomic)：不可再分的底层模块
• 传入模块(Input)：从下属模块取数据，处理后传给上级
• 传出模块(Output)：从上级获数据，处理后传给下属
• 变换模块(Transform)：从上级获数据，特定处理后返回上级
• 协调模块(Coordination)：管理所有下属模块

两种系统结构：

• 变换型(Transform)：传入→变换中心→传出
• 事务型(Transaction)：事务中心根据事务类型分配处理

重要人物：Dijkstra(1965提出结构化程序设计), Bohm & Jacopini(1966证明三种控制结构可实现任何程序)

重要程度：⭐⭐⭐ 必考

【知识点7】面向对象方法 (Object-Oriented Approach)

定义：将系统视为一组为完成任务而交互的对象的集合。

三个阶段：

• OOA(面向对象分析)：识别用例和类
• OOD(面向对象设计)：定义对象类型及交互
• OOP(面向对象编程)：编写类定义和行为代码

核心概念：对象=数据+操作，类(Class)，消息(Message)，继承(Inheritance)

vs 结构化方法：

重要程度：⭐⭐⭐ 必考

【知识点8】系统分析活动 (Systems Analysis Activities)

定义：理解业务需求并建立系统模型的过程。

五个步骤：

1. 收集详细信息(Gather Detailed Information)
2. 定义需求(Define Requirements)
3. 需求优先级排序(Prioritize Requirements)：Essential/Important/Nice to have
4. 开发用户界面对话(Develop User-Interface Dialogs)
5. 与用户评估需求(Evaluate Requirements with Users)

重要程度：⭐⭐ 高频

【知识点9】需求分类 (Requirements Classification)

定义：系统需求分为功能需求和非功能需求。

功能需求(Functional Requirements)：系统必须执行的活动/业务功能。描述系统”做什么”。

非功能需求(Non-functional Requirements)：约束条件和性能目标。描述系统”做得怎样”。

FURPS+ 模型（高频考点）：

常见陷阱：F(功能需求)本身不是非功能需求，U/R/P/S/+才是非功能需求

重要程度：⭐⭐⭐ 必考

【知识点10】利益相关者 (Stakeholders)

定义：对系统成功实施有兴趣的人。

四种分类：

重要程度：⭐⭐ 高频

【知识点11】信息收集技术 (Information-Gathering Techniques)

六种方法：

1. 访谈(Interviewing)：准备问题→讨论答案→记录→跟进
2. 问卷(Questionnaires)：大范围收集
3. 审查文档(Reviewing documents)：现有输入/输出/文档
4. 观察流程(Observing procedures)：直接观察业务流程
5. 研究供应商(Researching vendors)：白皮书、供应商方案
6. 收集反馈(Collecting comments)：活跃用户的意见和建议

重要程度：⭐⭐ 高频

【知识点12】活动图 (Activity Diagram)

定义：描述用户/系统活动、执行人员和活动顺序流的UML图。

组成元素：

• 初始节点(Initial Node)：黑色实心圆
• 活动(Activity)：圆角矩形
• 判断(Decision)：菱形
• 分叉/汇合(Fork/Join)：粗横线，表示并行路径
• 终止节点(Final Node)：带环的黑色实心圆

考试画图步骤：

1. 确定起始和终止节点
2. 识别主要活动
3. 添加判断分支
4. 添加并行路径(Fork/Join成对出现)
5. 连接所有节点

常见错误：Fork和Join不成对出现；判断菱形后没有分支

重要程度：⭐⭐⭐ 必考（应用题画图）

【知识点13】数据流图 DFD (Data Flow Diagram)

定义：描述系统中数据流动和加工的图形工具。

四种基本符号：

• 数据流(Data Flow)：箭头
• 加工(Process)：圆或圆角矩形
• 数据存储(Data Store)：开口矩形
• 外部实体(External Entity)：矩形

绘制步骤：

1. 画顶层DFD（确定系统边界）
2. 逐层分解（自顶向下）
3. 画总DFD

数据词典(DD)条目：名字、别名、分类、内容描述、何处使用

重要程度：⭐⭐⭐ 必考

【知识点14】需求规格说明书 SRS (Software Requirements Specification)

定义：用户与开发方之间的技术合同，描述系统必须做什么。

参照标准：GB/T 8567-2006

编写要求：

1. 准确无误无二义性
2. 规范书写
3. 允许适当调整
4. 后续设计和编码的基础

需求评审四个方面：

• 一致性(Consistency)：需求不矛盾
• 完整性(Completeness)：包含所有功能和性能
• 现实性(Feasibility)：现有技术可实现
• 有效性(Validity)：需求正确有效

重要程度：⭐⭐⭐ 必考

【知识点15】用例 (Use Case)

定义：系统执行的活动，通常是对用户请求的响应。

命名规则：动词-名词(Verb-Noun)，如”Create customer account”

EBP(基本业务流程)：由一个人在特定地点为响应交易事件执行的任务，增加可衡量的业务价值。

重要程度：⭐⭐⭐ 必考

【知识点16】识别用例的三种技术

1. 用户目标技术(User Goal Technique)
执行8步流程：识别所有潜在用户、按功能角色分类、按组织层次分类、采访用户收集目标、创建初步用例列表、去重和解决不一致、确定共享用例、与利益相关者审查。

2. 事件分解技术(Event Decomposition)
包含三种事件：

理想技术假设(Perfect Technology Assumption)：分析阶段只考虑最佳条件下需要响应的事件。排除Login/Logout/密码修改/备份恢复等系统控制事件。

3. CRUD技术
CRUD = Create/Read/Update/Delete。主要用于验证用例完整性，确保每种数据的每个操作都有对应用例。

重要程度：⭐⭐⭐ 必考

【知识点17】用例图关系 (Use Case Relationships)

• <<includes>> 包含关系：执行用例A时必须执行用例B才完整。箭头方向：A → B（主用例指向被包含用例）。类比调用子程序。举例：处理订单 <<includes>> 验证客户信息。
• <<extend>> 扩展关系：执行用例A时在某些条件下会执行B。箭头方向：B → A（扩展用例指向主用例）。特点：B是可选的扩展。举例：计算折扣 <<extend>> 处理订单。
• Generalization 泛化：继承关系，子用例指向父用例。

记忆口诀：”includes主指向被含（必须），extend被扩指向主（可选）”

重要程度：⭐⭐⭐ 必考（应用题画图核心）

【知识点18】完全开发的用例描述 (Fully Developed Use Case Description)

11个字段（必须全部记忆）：

重要程度：⭐⭐⭐ 必考（应用题核心）

【知识点19】系统顺序图 SSD (System Sequence Diagram)

定义：UML顺序图的特殊情况，只显示Actor和:System。

消息符号：

框架：Loop(循环)/Opt(可选)/Alt(条件分支)

重要程度：⭐⭐⭐ 必考（应用题画图）

【知识点20】状态机图 (State Machine Diagram)

定义：显示对象在状态和转换中的生命周期的UML图。

核心概念：

• 状态(State)：对象生命周期中的条件
• 转换(Transition)：从一种状态到另一种状态
• 伪状态(Pseudo state)：起始点（黑色圆点）
• 保护条件(Guard condition)：真/假测试，决定转换是否触发
• 行动表达(Action expression)：转换时执行的活动
• 复合状态(Composite state)：包含其他状态
• 并行路径(Concurrent paths)：复合状态中的独立路径

转换格式：触发器名称[保护条件] / 行动表达

重要程度：⭐⭐⭐ 必考

【知识点21】域建模 (Domain Modeling)

定义：识别问题域中的”事物”并建立域模型类图。

两种识别技术：头脑风暴法(Brainstorming) 和 名词技术(Noun Technique)。

域模型类图 vs 设计类图：

• 域模型类图没有方法（只有属性和关系）
• 设计类图有方法（含可见性、Stereotype）

重要程度：⭐⭐⭐ 必考

【知识点22】类图关系 (Class Diagram Relationships)

五种关系：

Multiplicity重数：0..1, 1, 0.., 1.., m..n

重要程度：⭐⭐⭐ 必考

【知识点23】内聚 (Cohesion) ⭐⭐⭐

定义：模块内部各元素之间联系的紧密程度。目标：高内聚。

七级（由低到高）：

记忆口诀：”巧逻时过通信顺功”

重要程度：⭐⭐⭐ 必考

【知识点24】耦合 (Coupling) ⭐⭐⭐

定义：模块之间相互依赖的程度。目标：松耦合（低耦合）。

七级（由低到高）：

记忆口诀：”非数标控外公内”

重要程度：⭐⭐⭐ 必考

【知识点25】SOLID设计原则

• SRP(Single Responsibility Principle)：一个类只有一个引起变化的原因。违反：OrderProcessor同时处理订单、发邮件、存数据库。
• OCP(Open-Closed Principle)：对扩展开放，对修改关闭。通过抽象/接口实现。
• LSP(Liskov Substitution Principle)：子类型必须能替换基类型而不改变程序正确性。
• ISP(Interface Segregation Principle)：客户端不应依赖不使用的接口。将大接口拆分为小接口。
• DIP(Dependency Inversion Principle)：高层模块不应依赖低层模块，都应依赖抽象。

重要程度：⭐⭐⭐ 必考

【知识点26】三层架构 (Three-Layer Architecture)

• View层(表示层)：用户界面，接收输入/展示输出
• Domain层(域层/业务逻辑层)：核心业务规则和逻辑
• Data Access层(数据访问层)：数据库交互，数据持久化

Controller模式：UI → Controller → Domain → DataAccess

用例实现流程：SSD → 添加Controller → 分配到Domain → 访问DataAccess

重要程度：⭐⭐⭐ 必考（应用题架构设计）

【知识点27】设计类Stereotype

五种类型：Entity（域对象/业务实体）、Boundary（界面边界）、Control（控制器/协调器）、Data Access（数据访问对象）、Persistent（持久化对象）

属性可见性：+ public, - private, # protected, ~ package

重要程度：⭐⭐ 高频

【知识点28】设计模式 (Design Patterns)

23种GoF设计模式：

• 创建型(5种)：Factory, Singleton, Builder, Prototype, Abstract Factory
• 结构型(7种)：Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
• 行为型(11种)：Observer, Strategy, Command, Template Method, Iterator, State, Chain of Responsibility, Mediator, Memento, Visitor, Interpreter

四个重点模式详解：

• Factory：封装对象创建逻辑，客户端无需知道具体类名
• Singleton：确保只有一个实例，提供全局访问点
• Adapter：将一个接口转换为客户端期望的接口
• Controller：将系统事件处理分配给协调类

重要程度：⭐⭐⭐ 必考

【知识点29】用户界面设计 (UI Design)

核心概念：

• 用户界面(UI)：直接涉及人类用户的输入输出
• 系统界面(SI)：需要最少人工干预的自动化输入输出
• HCI(人机交互)：研究用户与计算机系统交互效率和效果的学科
• Visibility(可见性)：控件必须对用户可见
• Affordance(可供性)：外观应暗示其功能

UI设计七大指南：一致性(Consistency)、快捷键(Shortcuts)、反馈(Feedback)、对话闭合(Dialog Closure)、错误处理(Error Handling with Guidance)、操作可逆(Reversal of Actions)、减轻短期记忆负担(Reduce Short Term Memory Load)

记忆口诀：”一快反闭错撤记”

以用户为中心设计原则：早期关注用户和工作、评估设计确保可用性、使用迭代开发

重要程度：⭐⭐⭐ 必考

【知识点30】V&V (Verification & Validation)

• Verification(验证)：”Are we building the product right?” — 检查是否正确实现了规格说明（关注过程）
• Validation(确认)：”Are we building the right product?” — 检查是否满足用户真实需求（关注结果）

SQA(Software Quality Assurance)：软件质量保证。测试只是SQA的一个元素。质量必须内建于开发过程，不能事后用测试来添加。

重要程度：⭐⭐⭐ 必考

【知识点31】测试组织 (Testing Organization)

• Developer(开发者)：了解系统，但倾向温和测试，被交付驱动
• ITG(Independent Test Group, 独立测试组)：不了解系统但倾向破坏，被质量驱动

正确做法：开发者做单元测试+集成测试，然后交给ITG。ITG应在分析和设计阶段就参与。

重要程度：⭐⭐ 高频

【知识点32】集成测试策略

• 大爆炸测试(Big-bang)：所有模块一次性集成。简单但难以定位错误。
• 自顶向下(Top-down)：从顶层开始，逐步加入底层。**需要Stub(桩模块)**模拟底层。
• 自底向上(Bottom-up)：从底层开始，逐步加入顶层。**需要Driver(驱动模块)**模拟上层。

Driver：模拟上层模块调用被测模块
Stub：模拟被测模块调用的下层模块

重要程度：⭐⭐⭐ 必考

【知识点33】测试级别

回归测试(Regression)：修改后重新测试确保无新错误
冒烟测试(Smoke)：快速检查核心功能是否正常

重要程度：⭐⭐⭐ 必考

【知识点34】系统测试四种类型

重要程度：⭐⭐ 高频

【知识点35】安装部署方式

重要程度：⭐⭐ 高频

【知识点36】形式化方法

有穷状态机 FSM (Finite State Machine)

• 5元组：$(J, K, T, S, F)$
  • J：有穷非空状态集
  • K：有穷非空输入集
  • T：转换函数 $(J-F) \times K \to J$
  • S：初始状态
  • F：终态集
• 6元组扩展：加入谓词集P

Petri网 (Petri Net)

• 4元组：$(P, T, I, O)$
  • P：位置集（圆圈）
  • T：转换集（短直线）
  • I：输入函数（位置→转换）
  • O：输出函数（转换→位置）
• 标记(Marking)：权标(token)分配
• 激发条件：每个输入位置的权标数 ≥ 该位置到转换的线数
• 禁止线(Inhibitor arc)：权标为零时转换才能触发

重要程度：⭐⭐ 高频

【知识点37】CRC卡技术

CRC = Class / Responsibility / Collaborator

• Class：类名
• Responsibility：该类的职责
• Collaborator：与该类协作的其他类

重要程度：⭐ 一般

【知识点38】版本管理

SCCS(Source Code Control System)：源代码控制系统

版本类型：Alpha（内部开发测试）、Beta（外部用户测试）、Production（正式发布）、Maintenance（维护修复）

重要程度：⭐ 一般

【知识点39】质量保证评审方法

重要程度：⭐⭐ 高频

【知识点40】氛围编程 (Vibe Coding)

定义：由Andrej Karpathy（2025年2月）提出的AI辅助编程方式。

流程：自然语言需求→AI生成代码→运行→反馈修改

工具：ChatGPT, Cursor AI, GitHub Copilot

重要程度：⭐ 一般（新知识点）

任务二：考试知识库

选择题考点精选（30道高频）

题1：软件危机中IBM OS/360项目的投资金额为？
A. 1亿美元 B. 5亿美元 C. 10亿美元 D. 5000万美元
答案：B | 干扰项：A太小，C太大

题2：以下哪个不属于敏捷宣言的核心价值观？
A. 个体和交互胜过过程和工具 B. 详细文档胜过工作软件
C. 客户合作胜过合同谈判 D. 响应变化胜过遵循计划
答案：B | 干扰项：正确的是”工作软件胜过文档”

题3：FURPS+中”R”代表什么？
A. Requirements B. Reliability C. Reusability D. Response
答案：B | Reliability可靠性

题4：<<includes>>的箭头方向是？
A. 被包含→主用例 B. 主用例→被包含 C. 双向 D. 无箭头
答案：B | 关键区分点

题5：聚合关系使用的符号是？
A. 实心菱形 B. 空心菱形 C. 实心三角 D. 空心三角
答案：B | 组合是实心菱形

题6：以下哪种内聚最强？
A. 通信内聚 B. 过程内聚 C. 功能内聚 D. 顺序内聚
答案：C | 功能内聚是最高级

题7：以下哪种耦合最弱？
A. 数据耦合 B. 标记耦合 C. 非直接耦合 D. 控制耦合
答案：C | 非直接耦合是最低级

题8：螺旋模型的核心特征是？
A. 迭代开发 B. 风险驱动 C. 原型驱动 D. 文档驱动
答案：B | 风险驱动是螺旋模型最大特点

题9：Verification关注的是什么？
A. 产品是否满足用户需求 B. 产品是否正确实现了规格说明
C. 产品是否通过验收测试 D. 产品是否有好的性能
答案：B | Verification=过程正确性

题10：自顶向下集成测试需要什么？
A. Driver B. Stub C. 两者都需要 D. 两者都不需要
答案：B | 自底向上需要Driver

题11：域模型类图与设计类图的区别是？
A. 域模型有方法 B. 设计类图没有方法 C. 域模型没有方法 D. 两者完全相同
答案：C | 域模型只有属性和关系

题12：XP的提出者是？
A. Booch B. Kent Beck C. Rumbaugh D. Jacobson
答案：B | 1996年提出

题13：以下哪种事件属于时间事件？
A. 顾客下单 B. 月末生成报表 C. 库存低于阈值 D. 用户登录
答案：B | 时间事件=到达时间点触发

题14：以下哪项不是理想技术假设排除的事件？
A. 登录 B. 备份数据库 C. 客户下单 D. 修改密码
答案：C | 客户下单是业务事件，不排除

题15：SSD中*号表示什么？
A. 条件判断 B. 循环/重复 C. 可选 D. 返回值
答案：B | *表示重复

题16：以下哪种安装方式风险最高？
A. 直接安装 B. 并行安装 C. 分阶段安装 D. 灰度安装
答案：A | 直接替换，出问题无法回退

题17：Petri网的4元组是？
A. (J,K,T,S,F) B. (P,T,I,O) C. (C,R,A,L) D. (P,T,I,M)
答案：B | FSM是5元组(J,K,T,S,F)

题18：Walkthrough和Inspection的主要区别是？
A. Walkthrough更正式 B. Inspection更正式 C. 没有区别 D. Walkthrough由用户执行
答案：B | Inspection是正式评审

题19：Controller模式中，请求的正确流向是？
A. UI→Domain→DataAccess B. UI→Controller→Domain→DataAccess
C. Controller→UI→Domain D. Domain→Controller→UI
答案：B | Controller是中间协调者

题20：以下哪个不是设计类的Stereotype？
A. Entity B. Boundary C. Interface D. Control
答案：C | 五种是Entity/Boundary/Control/DataAccess/Persistent

题21：喷泉模型的主要特点是？
A. 线性顺序 B. 风险驱动 C. 对象驱动，阶段重叠 D. 严格文档
答案：C | 面向对象、各阶段重叠

题22：结构化程序设计中严格控制的是什么语句？
A. IF B. WHILE C. GOTO D. RETURN
答案：C | Dijkstra主张消除GOTO

题23：变换型系统结构包含？
A. 事务中心 B. 传入部分→变换中心→传出部分 C. 并行处理 D. 递归调用
答案：B | 事务型包含事务中心

题24：Alpha测试和Beta测试的区别是？
A. Alpha由用户执行 B. Beta在开发环境中执行 C. Alpha在开发环境中执行 D. 没有区别
答案：C | Alpha=开发环境，Beta=真实用户环境

题25：SRP原则的含义是？
A. 一个系统只有一个类 B. 一个类只有一个变化原因 C. 一个方法只做一件事 D. 一个项目只有一个开发者
答案：B | Single Responsibility = 一个变化原因

题26：以下哪个不是系统测试类型？
A. 恢复测试 B. 单元测试 C. 安全测试 D. 压力测试
答案：B | 单元测试是单独的测试级别

题27：需求评审的四个方面不包括？
A. 一致性 B. 完整性 C. 创新性 D. 有效性
答案：C | 四方面：一致性/完整性/现实性/有效性

题28：以下哪个不是CRUD操作？
A. Create B. Replace C. Update D. Delete
答案：B | CRUD = Create/Read/Update/Delete

题29：OOA的全称是？
A. Object-Oriented Architecture B. Object-Oriented Analysis
C. Object-Oriented Application D. Open-Oriented Analysis
答案：B | 面向对象分析

题30：有穷状态机的初始状态用哪个字母表示？
A. J B. K C. S D. F
答案：C | S=初始状态，F=终态集

简答题考点精选（10道，标准答案结构）

简答题1：简述软件危机的主要表现和产生原因。
答题结构：表现5条(每条1分) + 原因6条(每条1分)
关键词：需求不满足、成本超标、质量差、难维护、速度跟不上

简答题2：简述Boehm的七条基本原理。
答题结构：逐条列举(每条1分)
关键词：分阶段计划、阶段评审、产品控制、现代技术、可审查、少而精、不断改进

简答题3：简述敏捷宣言的四大核心价值观。
答题结构：四组对比(每组2分)
关键词：个体交互>过程工具、工作软件>文档、客户合作>谈判、响应变化>计划

简答题4：比较 <<includes>> 和 <<extend>> 的区别。
答题结构：定义(各2分) + 箭头方向(各1分) + 举例(各1分)
关键词：必须执行/可选执行、箭头A→B/箭头B→A

简答题5：解释内聚和耦合的概念及追求”高内聚低耦合”的原因。
答题结构：内聚定义+7级(3分) + 耦合定义+7级(3分) + 原因(2分)
关键词：模块内部紧密度、模块间依赖度、独立性、可维护性、可重用性

简答题6：简述SOLID五大设计原则。
答题结构：每条原则名称+简要解释(每条2分)
关键词：单一职责、开闭、里氏替换、接口隔离、依赖倒置

简答题7：解释Verification和Validation的区别。
答题结构：定义(各3分) + 区别(2分)
关键词：building the product right / building the right product

简答题8：简述三种集成测试策略及其优缺点。
答题结构：三种策略(各3分)
关键词：大爆炸/自顶向下(需Stub)/自底向上(需Driver)

简答题9：简述FURPS+需求分类模型。
答题结构：每个字母含义(各1分) + +号扩展(1分)
关键词：Functional/Usability/Reliability/Performance/Security

简答题10：简述UI设计的七大指南。
答题结构：每条名称+简要解释(每条1分)
关键词：一致性、快捷键、反馈、对话闭合、错误处理、操作可逆、减轻记忆

应用题考点精选（50分重点，详细解题步骤）

应用题类型1：完整需求分析案例（最可能出大题）

• 典型题目：给定一个业务系统场景，完成完整的需求分析。
• 解题步骤：识别利益相关者（列出内部/外部等）；事件分解（识别外部/时间/状态事件）；画用例图（画矩形系统边界，椭圆写用例名，小人画参与者，实线连接参与者和用例，标注 <<includes>> 和 <<extend>> 关系）；编写用例描述（选取1-2个用例写完整11字段）；画SSD（Actor→:System的消息序列）。
• 评分点：用例图(15分) + 用例描述(10分) + SSD(10分) + 分析过程(5分)

应用题类型2：类图绘制与分析

• 典型题目：给定业务场景，画域模型类图或设计类图。
• 解题步骤：识别类（名词技术/头脑风暴）；确定属性；确定关系（关联/泛化/聚合/组合）；标注Multiplicity重数；如果是设计类图需添加方法、可见性、Stereotype。
• 评分点：类识别(5分) + 关系正确(10分) + 重数(5分) + 完整性(5分)

应用题类型3：架构设计分析

• 典型题目：分析系统架构问题，提出设计方案。
• 解题步骤：分析当前架构的问题（内聚/耦合分析）；识别违反的设计原则（SOLID）；提出重构方案（三层架构、设计模式）；画重构后的类图/架构图；说明改进效果。
• 评分点：问题分析(10分) + 方案(10分) + 图(10分) + 说明(5分)

应用题类型4：测试策略设计

• 典型题目：为给定系统设计测试方案。
• 解题步骤：确定测试级别（单元/集成/系统/验收）；选择集成策略（自顶向下/自底向上）；设计Driver/Stub；设计测试用例；规划回归测试和冒烟测试。
• 评分点：测试策略(10分) + 集成方案(10分) + 测试用例(10分)

应用题类型5：状态机图/活动图绘制

• 典型题目：给定对象生命周期或业务流程，画图。
• 解题步骤：状态机图（确定所有状态→确定转换→添加保护条件和行动表达→检查复合状态和并行路径）；活动图（确定起止节点→识别活动→添加判断→添加Fork/Join→连接）。
• 评分点：状态/活动识别(5分) + 转换/连接正确(10分) + 保护条件(5分) + 完整性(5分)

任务三：软件工程模型详细整理

瀑布模型 (Waterfall Model)

定义：线性顺序的软件开发模型，各阶段按顺序执行，前一阶段完成后才进入下一阶段。

原理：基于工程方法，假设需求可以在早期完整确定。

生命周期流程：需求分析 → 系统设计 → 详细设计 → 编码 → 测试 → 部署维护（每个阶段有验证和确认环节）。

优缺点与适用场景：

• 优点：原理简单易掌握，便于质量管理和项目跟踪，适合结构化方法。
• 缺点：缺乏灵活性，不能适应需求变化，回溯性差，用户很晚才能看到产品。
• 适用项目：需求明确且稳定、技术风险低、大型正规项目。

快速原型模型 (Rapid Prototyping)

定义：通过快速构建可运行的原型系统来理解和确认需求。

优缺点与适用场景：

• 优点：增强交流、及早发现问题、降低风险。
• 缺点：缺乏工具支持、原型可能被误当最终产品、难以彻底测试。
• 适用：需求不明确的交互式系统。

增量模型 (Incremental Model)

定义：以组件为单位分批交付软件，可看作重复执行的多个瀑布模型。

优缺点与适用场景：

• 优点：分批交付，用户及早使用，降低开发风险，灵活调整开发顺序。
• 缺点：总体需求定义困难，体系结构必须开放，每次增量必须可测试。
• 适用：需求可分优先级、需要分批交付的大型系统。

螺旋模型 (Spiral Model) ⭐⭐⭐

定义：结合瀑布和原型，强调风险分析的迭代模型。

原理：风险驱动(Risk-driven)

生命周期流程（每轮四象限）：计划(Planning) → 风险分析(Risk Analysis) → 工程(Engineering) → 客户评估(Customer Evaluation)

优缺点与适用场景：

• 优点：风险驱动、灵活、适合大型项目。
• 缺点：成本高、需要风险评估经验、不适合小项目。
• 适用：大型、复杂、高风险的系统。

喷泉模型 (Fountain Model)

定义：面向对象的开发模型，各阶段相互重叠。

五大特点：阶段重叠（并行性）；分析阶段消耗资源最多；返回低层无资源消耗；”分析一点、设计一点”；对象驱动。

V模型 (V-Model)

定义：瀑布模型的扩展，强调测试与开发阶段的对应关系。

对应关系：需求分析↔验收测试；系统设计↔系统测试；详细设计↔集成测试；编码↔单元测试。

RUP (Rational Unified Process)

定义：Rational公司推出的完整软件过程框架。

六大最佳实践：迭代式开发、管理需求、基于构件的体系结构、可视化建模(UML)、验证软件质量、控制变更。

四个阶段：初始(Inception)→细化(Elaboration)→构建(Construction)→交付(Transition)。

敏捷开发 (Agile Development)

定义：2001年17位专家联合发布敏捷宣言。

四大价值观：

1. 个体和交互 > 过程和工具
2. 可以工作的软件 > 面面俱到的文档
3. 客户合作 > 合同谈判
4. 响应变化 > 遵循计划

XP 极限编程 (Extreme Programming)

提出者：Kent Beck, 1996年

十大核心实践：以人为本、简单设计、结对编程(Pair Programming)、持续集成(Continuous Integration)、短周期迭代(1-2周)、代码重构(Refactoring)、测试驱动开发(TDD)、现场客户(On-site Customer)、可持续的开发速度、开放的工作环境。

Scrum

定义：一种敏捷框架，使用固定时间盒(Sprint)进行迭代开发。

三个角色：Product Owner, Scrum Master, Development Team
五个事件：Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
三个工件：Product Backlog, Sprint Backlog, Increment

模型对比总表

任务四：需求工程详细整理

需求获取 (Requirements Elicitation)

六种方法：

需求分析 (Requirements Analysis)

功能需求：系统必须做什么（业务功能）

非功能需求：约束条件和性能目标。包括可用性(Usability)、可靠性(Reliability)、性能(Performance)、安全性(Security)，以及设计限制、开发约束、接口要求、物理要求、支持要求等。

需求建模与验证

三种模型类型：文本模型(Textual)、图形模型(Graphical)、数学模型(Mathematical)。

需求验证四个方面：一致性（不矛盾）、完整性（包含所有）、现实性（可实现）、有效性（正确有效）。

优先级三级：Essential(必要) > Important(重要) > Nice to have(锦上添花)。

任务五：软件设计详细整理

模块化 (Modularity)

定义：将系统分解为可独立开发和测试的模块。

数学根据：$C(x_1+x_2) > C(x_1) + C(x_2)$，即整体复杂性大于部分之和，所以分解可降低复杂性。

原则：模块规模适度，既不太大（难维护）也不太小（接口太多）。

抽象与信息隐藏

过程抽象：用高级概念描述操作（如”排序”而非具体代码）
数据抽象：用高级概念描述数据结构（如”栈”而非数组实现）
信息隐藏：每个模块的实现细节对其他模块不可见。降低耦合、提高独立性。

软件体系结构与设计启发规则

常见架构风格：分层架构(Layered)、管道-过滤器(Pipe-Filter)、客户端-服务器(Client-Server)、事件驱动(Event-Driven)、MVC(Model-View-Controller)。

设计启发规则：模块规模适度；深度、宽度、扇出、扇入适度；作用域应在控制域之内；降低接口复杂程度；单入口单出口；模块功能可预测。

任务六：UML图详细整理

用例图 (Use Case Diagram)

用途：记录系统功能需求和用户交互。
关系：<<includes>>(包含)、<<extend>>(扩展)、Generalization(泛化)。
常见错误：includes/extend箭头方向搞反；Actor之间画关联线；用例之间画普通连线。

类图 (Class Diagram)

用途：描述系统静态结构。
关系类型：关联、聚合(空心菱形)、组合(实心菱形)、泛化(空心三角)、依赖(虚线箭头)。

活动图 (Activity Diagram)

用途：描述业务流程和工作流。
绘制规则：Fork和Join必须成对出现；判断后必须有多个分支。

顺序图 / SSD (Sequence Diagram / SSD)

用途：描述对象间的消息交互顺序。
SSD特殊规则：只有Actor和:System两个生命线。
消息符号：实线=输入消息、虚线=返回消息、*=循环、[condition]=条件。

状态机图与通信图

状态机图：描述对象的生命周期状态变化。转换格式为 触发器[保护条件]/行动表达。
通信图：描述对象间的关系和消息传递（强调结构而非时间）。

任务七：软件测试详细整理

测试层次

• 单元测试 (Unit Testing)：测试单个模块/类的正确性（开发者，白盒为主）。
• 集成测试 (Integration Testing)：测试模块间的接口和交互（大爆炸/自顶向下/自底向上）。
• 系统测试 (System Testing)：测试整个系统的功能和非功能特性（恢复/安全/压力/性能测试）。
• 验收测试 (Acceptance Testing)：用户确认系统是否满足需求（Alpha/Beta）。
• 回归测试 (Regression Testing)：修改后重新测试确保没有引入新错误。
• 冒烟测试 (Smoke Testing)：快速检查核心功能是否正常工作的初步测试。

测试方法与调试策略

白盒测试：知道内部结构，测试代码逻辑路径（语句覆盖、分支覆盖等）。
黑盒测试：不知道内部结构，测试功能和输出（等价类划分、边界值分析等）。

调试策略：蛮力法(Brute Force)、回溯法(Backtracking)、原因排除法(Cause Elimination)、归纳法(Induction)。

任务八：软件项目管理

• 项目计划：立项分析阶段确定项目愿景文档。
• 项目估算：专家判断、类比估算、参数模型(COCOMO)。
• 风险管理：螺旋模型核心，流程包含识别→评估→制定策略→监控。
• 配置管理：SCCS控制源代码版本。包含 Alpha/Beta/Production/Maintenance 版本。
• 质量管理：SQA 包含 Walkthrough（非正式）和 Inspection（正式）。质量必须内建于开发过程。
• 进度管理：甘特图(Gantt Chart)、PERT图、关键路径法(CPM)。

任务九：必考知识点 Top 30

任务十：预测考题

预测选择题考点（30道）

基础概念类（10道）

1. 软件三个组成部分 → 程序+数据+文档
2. 软件工程诞生时间和人物 → 1968, NATO, Fritz Bauer
3. Boehm原理的数量 → 七条
4. 软件危机案例（IBM OS/360的投资额） → 5亿美元
5. 敏捷宣言提出年份 → 2001年
6. XP提出者和年份 → Kent Beck, 1996
7. FURPS+中各字母含义
8. CRUD各字母含义
9. EBP的定义
10. SSD中消息符号(*、[]等)

模型与方法类（10道）
11. 螺旋模型核心特征 → 风险驱动
12. 喷泉模型特点 → 对象驱动、阶段重叠
13. 瀑布模型属于什么方法 → 预测性方法
14. 结构化程序设计控制GOTO → Dijkstra
15. Bohm和Jacopini证明年份 → 1966
16. 三种基本控制结构 → 顺序/选择/循环
17. 变换型vs事务型系统结构
18. RUP的六个最佳实践数量
19. Scrum的Sprint持续时间 → 通常2-4周
20. 预测性vs适应性SDLC

设计与测试类（10道）
21. 内聚最高级别 → 功能内聚
22. 耦合最低级别 → 非直接耦合
23. 聚合vs组合的符号区别
24. SOLID中OCP的含义 → 开闭原则
25. 三层架构的中间层 → Domain/业务逻辑层
26. Driver vs Stub的区别
27. 自顶向下集成需要什么 → Stub
28. Alpha测试在哪里执行 → 开发环境
29. 域模型类图有没有方法 → 没有
30. Verification关注什么 → 过程正确性

预测简答题考点（10道）

1. 软件危机的表现和原因
2. Boehm七条基本原理
3. 敏捷宣言四大价值观
4. 三种集成测试策略对比
5. V&V的区别
6. <<includes>> 和 <<extend>> 的区别
7. 内聚和耦合的概念及原则
8. FURPS+需求分类模型
9. UI设计七大指南
10. 三种安装部署方式对比

预测应用题考点（10道，50分重点）

应用题1：在线购物系统需求分析

• 解题步骤：识别角色→事件分解→画用例图(含includes/extend)→写用例描述→画SSD。
• 容易失分：includes/extend箭头方向搞反；遗漏异常条件；SSD消息格式不规范。

应用题2：图书馆管理系统类图设计

• 解题步骤：识别类→确定属性→确定关系(关联/聚合/组合/泛化)→标注Multiplicity。
• 容易失分：聚合和组合分不清；重数标注错误。

应用题3：订单处理系统架构重构

• 解题步骤：分析当前问题(内聚/耦合)→识别违反的SOLID原则→提出三层架构重构方案→画重构后类图。
• 容易失分：不能准确识别违反的设计原则；重构方案不具体。

应用题4：学生选课系统测试方案设计

• 解题步骤：确定测试级别→选择集成策略→设计Driver/Stub→设计测试用例→规划回归测试。
• 容易失分：Driver/Stub使用场景搞混。

应用题5：电梯控制系统状态机图

• 解题步骤：确定所有状态→确定转换→添加保护条件和行动表达。
• 容易失分：遗漏状态；保护条件描述不准确。

应用题6：医院预约系统活动图

• 解题步骤：确定起止→识别活动→添加判断→添加Fork/Join→连接。
• 容易失分：Fork/Join不成对；判断菱形后缺少分支。

应用题7：银行系统安全测试方案

• 解题步骤：确定系统测试类型(恢复/安全/压力/性能)→为每种类型设计测试用例。
• 容易失分：混淆系统测试和验收测试。

应用题8：电商系统UI设计评审

• 解题步骤：对照七大指南逐项检查→指出违反的原则→提出改进建议。
• 容易失分：不能将UI问题对应到具体原则。

应用题9：保险理赔系统形式化建模

• 解题步骤：用有穷状态机5元组建模或用Petri网4元组建模。
• 容易失分：5元组各分量定义不准确。

应用题10：企业ERP系统开发模型选择

• 解题步骤：分析项目特点→对比候选模型→选择最佳模型→说明理由。
• 容易失分：只说优点不说缺点；不结合项目特点分析。

附录：关键人物与年份速查表

附录：完整缩写对照表