ELEC5620 Week 01 Introduction to Software Architecture 讲课总结
ELEC5620 Week 01 讲课总结：Introduction to Software Architecture
课程：ELEC5620 — Model Based Software Engineering，Semester 2 2026 讲师：Dong Yuan（Associate Professor，School of Electrical and Computer Engineering） Email: dong.yuan@sydney.edu.au｜Office: Rm. 323, PNR Building｜Phone: 8627 2007 研究方向：Cloud/edge computing、AI、Internet of Things Head Tutor：Yuning Zhang（yuning.zhang1@sydney.edu.au），全课共 5 位 tutor 来源：
1 Introduction.pdf（45 页）+ Week 01 讲课字幕本学期选课 400 人。老师开场就说：这门课传统上被学生认为"很无聊"，因为讲的都是原则和经验，不是给 junior developer 用的——它的目的是把你训练成 software architect。但他认为 AI 的到来给了这门课新的生命。
一、课程组织与考核
1.1 三个课程目标
- 学习软件架构设计的基础
- 学习支撑架构设计的 model-based 技术的基础
- 用最新的软件开发模型和技术把设计实现出来
1.2 考核构成
| 评估 | 权重 | 形式 | 时间 |
|---|---|---|---|
| Project Stage 1 | 30% | 架构设计与建模：报告提交 + presentation 和 in-class interview | checkpoint 在 Week 5，Week 8 截止（tentative） |
| Project Stage 2 | 20% | 实现：代码提交 + in-class demonstration | Week 13 截止（demo 在最后一周，代码在最后一周周一前上传） |
| Mid-semester exam | 10% | 线上 quiz | Week 9（tentative） |
| Final exam | 40% | 闭卷，考试周 | — |
关于两场考试的关键信息（来自课堂问答，比 slide 详细）：
| 项目 | Midterm | Final |
|---|---|---|
| 形式 | 线上，在家做，开卷 | 闭卷，线下 |
| 时长 | 1 小时，在 lecture 时段进行；第二小时的 lecture 照常线上进行 | — |
| 限制 | ⭐ 没有 lockdown browser，没有任何限制，可以用 AI | 无 |
| 题型 | 开放式，考察理解 | ⭐ 以建模为主——"给定场景，画模型、设计模型" |
⭐ 老师关于 final exam 最重要的一句话： "你不需要担心背诵。这是一门软件建模课，我们评估的是你会不会某些建模方法。所以期末考也是 modeling-based——我们会要求你针对给定场景画出一些模型、设计一些模型。" 他还明确说："我不会出'请写出软件架构的定义'这种题，完全不会。"
为什么 Stage 1 加了 interview（老师原话）：
"如果只看报告，你给足提示词的话，用 AI 10 分钟就能生成一份报告。我们需要确认你真的理解自己设计了什么。"
1.3 分组规则
- 3–5 人，在 Canvas 上注册小组
- ⭐ 必须是同一个 lab session 的人——跨 lab 组队不允许
- 如果无法参加分配的 lab，要向 student centre 申请调整；调整后只能和新 lab 的同学组队
- Tutorial 则可以随便换场次（老师不推荐但允许）
1.4 Lab 与 Tutorial
| Lab Session | Tutorial Session | |
|---|---|---|
| 内容 | 实践练习，围绕课程内容和项目 | Lecture 复习 + lab 相关材料 + Q&A |
| 形式 | 小组聚在一起讨论、推进项目，tutor 在场答疑；每次 lab 有 handout 定义当周任务和目标 | 更像一节小课，tutor 快速回顾 lecture 并教实用工具 |
| 要求 | — | ⭐ 提前 24 小时把问题发邮件给你的 tutor |
Lab 用到的工具/服务：StarUML、IDE（VS Code、PyCharm、Spring Tools Suite、Papyrus UML）、Amazon Web Services、AI services 等。
1.5 ⚠️ 出勤规则（很重要）
⭐ 这门课没有任何一节课是强制出勤的，也不点名。 但是——in-class assessment 的场次必须到：Stage 1 的 interview 和 Stage 2 的 demo。缺席就没有分。
老师的建议：
- Lecture 有录播，lab 和 tutorial 没有。所以如果撞课，优先保 lab 和 tutorial。
- 老师的数据观察：到场人数 + 录播观看人数加起来只有全班的一半——另一半既不来也不看。
- ⭐ 最实用的一句话："拿高分最直接的方式，是直接从打分的人那里拿到要求。" 设计项目时不确定就去问 tutor——他们就是给你打分的人。
1.6 关于 Ed 讨论区
| 是 | 不是 |
|---|---|
| 学生自由讨论、找队友、解决团队问题的地方 | ⭐ 不是教学平台 |
| 教学团队会监看，必要时回复 | 不保证回复每一个帖子 |
| — | ⭐ 官方信息、评分要求、作业要求一律以 Canvas 为准 |
老师点名了一个往年的误区：有学生完全依赖 Ed 来学这门课，甚至连录播都不看。"如果你打算这么做——抱歉，你会错过大量关键信息。"
1.7 先修要求
| 要求 | 老师的实际说法 |
|---|---|
| Basic familiarity with UML | 课程会深入 UML 及其语义。⭐ 没学过的话，去 YouTube 或 B 站找个短课，花一小时看完就够了；tutorial 也会补充 UML 材料 |
| 至少一门编程语言（C/C++、Java、C#…） | 这是传统要求。⭐ 老师补充：今天如果你完全没编程背景也没关系，因为这门课会做 vibe coding |
⭐ 老师对 UML 的定位（slide 10 原文，值得记）： "UML is not helpful to coding in many cases (e.g., Agile). But it is a good language for communication." UML 在很多情况下（比如敏捷开发）对写代码没什么帮助——但它是一门很好的沟通语言。
1.8 课程主题地图
| 板块 | 内容 |
|---|---|
| Introduction | Software Architecture、Model Based Software Engineering |
| Fundamentals | Requirements Modeling、Architectural Design and Modeling、Modeling Structure、Modeling Behaviour、Software Development Process |
| Practical and Advanced Topics | Metamodeling、Software Modeling Languages、Security in Software Architecture、New Technologies and Software Modelling |
二、AI 时代软件工程师的角色（本讲的思想主线）
这部分是老师最想传达的东西，也是他给这门课"重新赋予意义"的方式。
2.1 一句核心判断
⭐ "Traditional software developer will soon disappear." ⭐ "When code becomes cheap, judgement becomes valuable."（当代码变得廉价，判断力变得有价值）
价值链上的位置转移（slide 6）：
- 越往左，AI 的杠杆越大
- ⭐ 越往右，人类的问责（accountability）越集中
两句关于架构的定位：
⭐ "Architecture controls the blast radius of fast generation."（架构控制快速生成的爆炸半径） ⭐ "Agents can multiply implementation speed. Architecture decides whether that speed compounds value or debt."（智能体能倍增实现速度；架构决定这个速度是在复利价值，还是在复利债务）
2.2 新角色在哪里（slide 7）
New roles sit at the boundary between intent and automation.（新角色位于意图与自动化的交界处）
两个新职位：
| 角色 | 做什么 |
|---|---|
| AI-native architect | 塑造约束、接口和质量属性（shapes constraints, interfaces and quality attributes） |
| Model-based systems engineer | 构建可执行、可追溯的系统模型（builds executable, traceable system models） |
2.3 Career takeaway：六项稀缺技能
| Architecture trade-offs | System modelling | Requirements & traceability |
| Verification & assurance | AI-agent orchestration | Communication & decision records |
⭐ "Do not compete with AI at typing code. Compete at defining, structuring and proving the system." （不要在敲代码上和 AI 竞争。要在定义、结构化和证明系统上竞争。）
2.4 老师的亲身经历（值得记的一段）
老师 2001 年上大学，正好赶上互联网泡沫破裂：
- 前一年（2000）同专业约 400 人
- 他那一届涨到 600 人，学校还新开了软件工程专业再招 500 人 → 总人数是前一年的三倍
- 泡沫破裂后第二年，人数又跌回 400 左右
- 结果：他那一届找工作、考研究生都超级卷
他用这个类比今天：美国计算机专业本科招生已经腰斩，中国同样，而澳洲因为在南半球、招生比北半球晚半年，明年入学人数预计会显著下滑。
但他的结论不是悲观的："不是说不再需要软件工程师了。传统的 developer 角色可能会消失，但我们仍然需要工程师来构建软件系统——用 AI 来构建。我们只需要把重心从代码生成转移到高层决策上。" 并且他指出：⭐ "从软件架构师的视角看，编码长期以来本来就是最不重要的事。他们的重心一直是系统设计和高层决策、权衡。"
2.5 为什么这门课"活过来了"
老师的完整逻辑链：
- 传统上，架构和建模技术只在大公司、大型软件团队里有用
- 因为产出代码是昂贵的——一两个人几乎不可能建出大规模系统
- AI 到来后，编码变得廉价 → 每个人都有机会构建比以前大得多的系统
- ⭐ 所以架构和建模不再是"只有大公司才用得上的技术"——每个个体都有机会去建模、设计自己的软件架构，然后用 AI 生成大规模软件
关于自然语言的局限（老师抛出的核心问题，本课要贯穿讨论）：
"我们现在用自然语言描述软件需求、生成代码。那么——自然语言是描述软件需求的完美方式吗？" 答案是否定的。 小规模产品用自然语言可能够用：很多需求是固定的，大模型都知道，即使你描述得不准确它也能给出正确答案。 ⭐ 但一旦你开发大规模系统，还全靠自然语言描述一切，就会出问题。 这门课要探索的，就是如何用"模型"来描述软件需求。
三、什么是软件架构
3.1 从 Software 到 Software Architecture
| 概念 | 定义 |
|---|---|
| Software | 一组指令（通常以代码形式），告诉计算机如何行动 |
| Hardware | 平台（通常以机器形式），实际完成工作 |
| 一句话 | ⭐ 软件就是任何"告诉硬件做什么、怎么做"的东西 |
老师的补充："software" 这个词是从 "hardware" 衍生来的，hardware 这个词老得多。 而且软件无处不在——显示器、手机、智能手表、电视、洗衣机都有软件。 软件项目可能极其庞大，也可能极其多样，所以构建软件很有挑战。
Software Engineering 的定义：
一门工程学科，聚焦于开发和使用严格的方法，来设计和构造能可靠执行既定任务的软件制品。
超出 IT 技能之外还需要：engineering math、professional engagement、其他工程领域的知识。
⭐ 老师的关键框架：软件工程是"横向"的。 其他工程领域（土木、机械、化工、生物）都是纵向的；每一个工程领域都需要软件工程师来为他们构建软件、处理数据。 这也是为什么悉尼大学的软件工程本科生要修和其他工程专业一样的数学，并且要从电气、通信、生物医学等其他领域选修课。
3.2 Software Engineering vs Computer Science
| Software Engineering | 共同基础 | Computer Science |
|---|---|---|
| Broad knowledge of engineering domains（工程领域的广博知识） | IT fundamentals & programming | In-depth knowledge of computer science areas（计算机科学领域的深入知识） |
⭐ Career-wise difference: Specialist or Generalist? IT Companies or Others?
- 想成为 specialist / tech lead，在 Google、Microsoft 这类大 IT 公司做专家 → Computer Science，找一个方向深挖
- 想要广博知识、在不同行业工作（银行 IT 部门、机构、其他工程公司）→ Software Engineering，做 generalist
老师还给出了本课在专业中的定位：
软件工程有三大方向： 1. Software design —— 如何构建软件架构 ← 本课在这个分支 2. Software quality —— 软件测试，如何保证软件可靠 3. Software process —— 如何管理软件团队和整个生命周期
层级关系（slide 20）：
软件架构是软件工程领域中的一种软件设计；架构的细节是软件设计的子集。
3.3 ⭐ 定义一：Clements, Bass, Kazman (2012)
动机：软件设计太复杂、太耗时、涉及太多风险 → 用模型来简化问题。
⭐ The software architecture of a system is the set of structures needed to reason about the system, which comprise software element, relations among them, and properties of both.
（一个系统的软件架构，是为了对该系统进行推理所需要的一组结构，它由软件元素、元素之间的关系、以及两者的属性组成。）
老师的通俗解释：
软件架构就是软件的模型——不是一个简单的模型，而是由不同类型的模型组成的一组结构。通过看这个架构，我们就能对整个系统进行推理。
3.4 ⭐ 定义二：IEEE 42010 标准
全称：IEEE Recommended Practice for Architectural Description of Software-Intensive Systems，即 ISO/IEC/IEEE 42010。
标准的目标：
- 促进架构的表达与沟通（specification/design、documentation）
- 定义关键术语、原则和指南
- 为其他相关 IEEE 标准提供框架
两个定义：
| 术语 | 定义 |
|---|---|
| System | A collection of components organized to accomplish a specific function or set of functions.（为完成特定功能而组织起来的一组组件） |
| Architecture | The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. |
⭐ 关键词拆解（这是最可能被考的部分）：
| 关键词 | 含义 |
|---|---|
| "fundamental" | ⇒ 无关的细节被省略 ⇒ abstraction（抽象） |
| "organization" | ⇒ structural and behavioral（结构的 + 行为的） |
| "components" | ⇒ 架构涉及 decomposition（分解） |
| "relationships" | ⇒ 部件被组装起来的方式，是架构的根本 |
| "guiding principles" | ⇒ 像宪法的基本原则一样 |
⭐ 老师的应试提示："我不会让你默写软件架构的定义，完全不会。" 但是——"这里有一些关键词，你需要理解它们的含义；读完这个定义后，你要理解背后的哲学，这就够了。"
3.5 一个架构模型长什么样（slide 24）
一个简单的架构模型包含：
| 成分 | 例子 |
|---|---|
| Design Principles | "为支持高可用：系统必须没有单点故障（must not have a single point of failure）" |
| Layering Structure | Application Layer / Services Layer |
| Horizontal Structure | 各层内部的组件（Boobler、Fuber、Gruber、Dabbler）及其连接 |
| End-to-End Behaviors | 端到端的行为流程 |
⭐ Slide 上专门标注："在我们关于架构的讨论中，会同时覆盖软件架构的 structural（结构）和 behavioral（行为）两个方面。"
老师的层层深入解释：先用分层结构描述系统 → 再看某一层内部有哪些组件、如何连接 → 再看每个组件的功能、组件之间如何通信，每一层都需要不同的图来描述。所有这些加在一起，就是软件架构。
四、架构为什么重要、什么时候重要
4.1 System Inception：架构师与利益相关者
架构师站在所有利益相关者的中间（slide 26，图源 P. Kruchten）：
| 利益相关者 | 关注点 |
|---|---|
| End-user | Functionality、Ease of use |
| Sales and field support | Functionality、Ease of integration、Ease of customization、Ease of use |
| Development manager | Price、Development costs、Skills、On time delivery |
| Developer | Performance and throughput、Stability and maintainability、Ease of diagnosing problems、Ease of introducing modifications、Testability and tractability、Structure and dependencies between parts |
| System administrator | Ease of installation |
架构师需要平衡的维度：Functionality、Process、Technology、Qualities、Complexity、Skills、Organization and culture、Business Concerns、Reliability。
老师的总结：架构师的工作就是——收集所有需求，平衡软件设计的各个方面，然后拿出一组模型来表示软件架构。
4.2 架构与演化
⭐ The architecture of a software system is a fundamental determinant of its capacity to support evolution. （一个软件系统的架构，从根本上决定了它支持演化的能力。）
老师讲的架构演化史（很好的记忆线索）：
| 时期 | 计算平台 | 主导架构 |
|---|---|---|
| 早期 | 大型机（mainframe） | 基于主机的架构 |
| 1960s–70s | 分布式系统出现 | Client/Server |
| 1970s | 网络出现 | Layered（分层）架构 |
| 互联网普及后 | 软件不再基于本地代码 | ⭐ SOA（Service Oriented Architecture） —— 软件成为不同服务的组合 |
| 近二十年 | 云计算 | Everything as a Service（SaaS、PaaS） |
| ⭐ 今天 | AI Agent | ⭐ "软件不再只是服务，而是 agentic service。软件架构又变了。" |
结论：软件架构是一个持续演化的过程，取决于当时的计算机系统形态。
4.3 ⭐ Architectural Decay（架构腐化）
⭐ The gradual corruption of architectural design decisions through seemingly minor fixes and modifications. （通过看似微小的修复和修改，架构设计决策被逐渐侵蚀。）
两个主要成因：
| # | 成因 |
|---|---|
| 1 | ⭐ 通过观察细节来理解一个架构，是困难的（The difficulty of comprehending an architecture by observing details） |
| 2 | ⭐ 在实现过程中强制执行架构设计决策，是困难的（The difficulty of enforcing architectural design decisions in the process of implementation） |
老师的展开：
学生可能会想："如果我放着不更新，它会腐化吗？" 极端情况下你确实可以用同一份软件很多年。但想想我们每天用的软件——手机 App 每隔几天几周就更新；就算 App 不更新，操作系统每一两年也会更新。 ⭐ 一切都在变。当变化发生时，如果我们对整体架构没有清晰的理解，这个变化就可能对整个软件造成伤害。 研究软件架构的原因之一，就是防止架构腐化。
（老师还提到了那张著名的漫画：按需求不断往上加积木，如果不注意架构，最后会得到一个完全无法维护的产品，只能推倒重来。）
4.4 When Architecture Matters
答案：软件生命周期的每一个阶段。
| 阶段 | 架构的作用 |
|---|---|
| During inception and design | 促进系统一致性并简化设计；帮助预测关键系统质量；⭐ 帮助识别需求（helps identify requirements） |
| During implementation | 帮助识别和分配开发工作；指导更细粒度的设计决策 |
| During maintenance and system evolution | 降低细粒度维护中架构腐化的可能性；识别演化方案的可行性和潜在成本 |
老师对"实现阶段"的补充：最好每个实现自己那部分的团队成员，都遵循架构师的决策、或者本身就理解架构，这样他们做的修改才不会伤害整个软件。但这在传统开发团队里非常难做到。
4.5 Why is Architecture Important（七点）
| # | 理由 |
|---|---|
| 1 | 架构是最早期设计决策的载体（carrier of the earliest design decisions） |
| 2 | 架构会制约系统的驱动性质量属性及其早期预测 |
| 3 | 提供管理变更的推理依据 |
| 4 | 架构会改善成本和进度估算 |
| 5 | 基于架构的开发聚焦于组件的组装（assembly of components） |
| 6 | 有文档的架构增强了利益相关者之间的沟通 |
| 7 | ⭐ 架构是一个可迁移、可复用的模型（transferable and reusable model） |
老师说这一页他不会逐条讲："如果我觉得某个点很重要，我会给例子帮你记住。其他的你自己读就能理解。"——但复习时要把这七条读一遍。
五、架构师的必备素质与设计流程
5.1 Necessary Qualifications of an Architect
两大类：
A. The ability to design（设计能力）
| 素质 | 说明 |
|---|---|
| Capacity for abstract thinking | ⭐ 看到技术/代码之外的东西（Seeing beyond the technology/code） |
| Focus on the product and its usage/users | ⭐ 技术深度和技能是不够的 |
| Deep knowledge and understanding of the problem domain | 包括对类似问题的既往解法 |
B. The technical knowledge to implement（实现的技术知识）
- General software engineering and programming
- Architectural description languages and tools
- Model-based software engineering techniques and tools
- Relevant platform technologies
- System analysis methods
5.2 ⭐ 老师给的职业路径与薪资（澳洲，SEEK 数据）
| 阶段 | 年薪范围 | 备注 |
|---|---|---|
| Internship | $0 – 50k | 类型差异很大 |
| Software developer | $70k – 100k | "如果你毕业时这个岗位还存在的话" |
| Team lead（3–5 人，工作 3–5 年后） | $150k – 200k | 大公司可达 200k |
| ⭐ Software architect | ⭐ $250k – 300k+ | 岗位非常有限——小公司只有 CTO；只有 in-house 团队超过 30–50 人的大公司才会设这个角色 |
⭐ 老师用这个解释了"为什么这门课历来被觉得无聊"： 它教的是普通开发者永远用不到的原则和知识——除非你成为架构师，才会觉得"这很重要"。而传统上从 developer 升到 architect 极其困难，因为岗位太少了。 "但今天 AI 给了这门课新生命。你们每一个人——哪怕没有公司雇你——都可以成为软件架构师，用 AI 构建一个非常大规模的软件。" 阻挡普通开发者成为架构师的核心障碍，就是"产出代码很昂贵"。今天这个障碍消失了。
5.3 架构设计是一个迭代过程
Refining the design over time until it satisfies all the requirements.
不是一次性设计出来的：和利益相关者沟通 → 获取需求 → 每次迭代解决一小部分 concern → 多轮迭代后逐渐建成架构，并随时间不断精化设计。
5.4 ⭐ Architectural Exploration Reduces Risk（最重要的一张图）
做法：
- 反复评估架构模型（使用仿真、形式化与非形式化分析）
- 及早获得设计经验
- ⭐ 及早发现潜在的设计缺陷 ⇒ 修复成本更低
图的读法（slide 38）：
- X 轴 = 时间
- Problem Understanding / Confidence（问题理解与信心）随时间上升
- Design Risk（设计风险）随之下降
- ⭐ Cost of Design Change（变更成本）随时间上升
- 图上有两个时间点：
：通过 model evaluation（模型评估）提早达到"关键理解阈值" ：通过 implementation evaluation（实现后评估）才达到该阈值
⭐ 本图的核心结论： 我们要把"critical understanding threshold（关键理解阈值）"尽可能推到早期（
），因为项目越到后期，变更成本越高。 在早期就理解项目的全部问题；如果需要改动，尽早改，而不是拖到后期花更多钱。
六、本学期项目主题：One-Person AI Company
老师的做法：每年挑一个当年的 buzzword 作为项目主题。他教这门课约 10 年，历年主题包括 5G、IoT、edge computing、computer vision；去年是 AI agent；今年是 One-Person AI Company。 原因：这是一门很传统的软件工程课，学生抱怨知识陈旧。他希望大家不只学经典知识，还能把知识用在非常时新的题目上。
6.1 定义
⭐ A one-person AI company is owned and directed by one founder. AI agents, software and specialist contractors perform repeatable work under the founder's control.
It can research markets, create content, sell, support customers, analyse data and run back-office workflows, while the founder owns judgment, relationships and accountability.
（AI 智能体、软件和专业外包在创始人的控制下执行可重复的工作；而 ⭐ 创始人拥有判断力、关系和问责。）
6.2 ⭐ 怎么设计：从客户价值倒推
⭐ Design from customer value backward, not from available tools. （从客户价值倒推来设计，而不是从手上有什么工具出发。）
| # | 步骤 | 内容 |
|---|---|---|
| 01 | Narrow promise（收窄承诺） | 一个客户，一件痛苦的事，一个可测量的结果 |
| 02 | Map the work（梳理工作） | 区分 judgment（判断）、repeatable tasks（可重复任务） 和 risky exceptions（高风险例外） |
| 03 | Build guardrails（建立护栏） | 定义数据访问、质量检查、审批和降级方案（fallbacks） |
| 04 | Create memory（建立记忆） | 把决策、样例、指标和经验教训存在一个系统里 |
⭐ DESIGN TEST（设计检验）：
Can the company deliver value repeatedly without the founder touching every step? （这家公司能否在创始人不介入每一步的情况下，反复地交付价值？）
If not, simplify the promise or redesign the workflow.（如果不能，就收窄承诺或重新设计工作流。）
老师对第 01 步的补充：为什么必须收窄？一是 AI 的能力仍然有限，处理不了太大的任务；二是 token 会烧钱。
6.3 示例：一人医疗代理公司
一个假想的 patient-navigation agency（患者导航代理）：
- 创始人与诊所和雇主合作，帮助患者理解转诊、准备就诊、完成非临床的后续事项
- ⭐ AI 负责协调（coordination）
- ⭐ 持证临床医生保留每一项诊断和治疗决策
这个例子完美体现了 6.2 中的 "judgment vs repeatable tasks" 分离。
6.4 技术栈与可选应用领域
| 类别 | 内容 |
|---|---|
| Vibe coding 工具 | Codex、Claude Code、Cline、Continue（⭐ 课程会提供 API keys） |
| 编程框架 | LangGraph、Llama-Index（tutorial 还提到 LangChain） |
| 应用领域 | Social Networks、Health、Entertainment、Manufacturing、Education 等 |
⭐ 关于 API key 的实际情况（课堂说明，很重要）：
- 老师让 tutor 架了一台本地服务器，会发 API keys
- ⚠️ 这些 key 是基于老师自己的账号，所以额度很小——目前每组只有 $10
- 不是 Codex / Claude Code，只能用于开源的 coding agent
- 老师正在申请经费，若拿到会加额度
- 好消息：OpenAI 新出的低价模型使得 $10 足够构建一个相当大的 web 应用
- ⭐ 不强制用 AI——用传统方式实现也完全可以。"我们看的是结果，不是过程。"
6.5 ⭐ 老师串起 Stage 1 和 Stage 2 的那句话
"如果你有一个非常好的设计——设计报告里一切都清楚地写明了——那么 Stage 2 的工作可能会非常简单。你只要把每一部分丢进 Claude Code 或者别的编码 agent，你的软件就会被自动生成出来。"
并且他强调：⭐ "这个项目主要面向 Stage 2，但这门课真正的学习目标是设计（Stage 1）——它也占了更大比重的分数。"
⚠️ 一个实用提醒（课后问答）：Canvas 上遗留的往年项目文件已经过时，老师说不要看，marking 的分配会不一样，他会重新发布新的评分文档。
七、考点重点
- ⭐
软件架构的两个定义要能复述含义（不要求默写原文）：
- Clements/Bass/Kazman：为推理系统所需的一组结构，包含软件元素、元素间关系、以及两者的属性
- IEEE 42010：系统的基本组织，体现在其组件、组件之间及与环境的关系、以及指导其设计与演化的原则中
- ⭐⭐ IEEE 42010 五个关键词的含义：fundamental → 抽象；organization → 结构 + 行为；components → 分解；relationships → 组装方式是根本；guiding principles → 如宪法基本原则
- System 的定义：为完成特定功能而组织起来的一组组件。
- 层级关系：Software Engineering ⊃ Software Design ⊃ Software Architecture。
- SE vs CS：广博的工程领域知识 vs 计算机科学的深入知识；generalist vs specialist。
- ⭐ Architectural decay 的定义与两个成因（难以通过细节理解架构；难以在实现中强制执行架构决策）。
- ⭐ When architecture matters 的三个阶段及各自作用——注意 inception 阶段"帮助识别需求" 这一条容易被忽略。
- Why architecture is important 的七点。
- ⭐ Architect 的必备素质：设计能力（抽象思维 / 关注产品与用户 / 领域深度）+ 实现的技术知识（含 architectural description languages、MBSE 技术与工具、system analysis methods）。
- ⭐⭐ Architectural exploration
的风险图：随时间理解上升、风险下降、变更成本上升；要把
critical understanding threshold 从
推到 ，即用模型评估而非实现评估来提早达到理解阈值。 - 架构设计是迭代过程，不是一次成型。
- 架构演化史：mainframe → client/server → layered → SOA → agentic。要能说明架构如何随计算平台演化。
- ⭐ AI 时代的定位：code 廉价 → judgement 昂贵；架构控制快速生成的爆炸半径；新角色在 intent 与 automation 的边界上。
- ⭐ 期末考是 modeling-based —— 复习重点应放在"会画、会设计模型"，而不是背定义。