2026UG_SysArch1_introduction 逐页中文翻译

第 1 页

软件系统设计
Software Systems Design

第 2 页

课程事务 / 课程安排
Course Logistics

第 3 页

联系方式
Contact Information

  • 课程负责人：张贺教授
  • 助教老师：李杉杉
  • 助理研究员：吕骏
  • 右侧为课程群二维码

第 4 页

为什么学习软件设计与架构？

  • 软件 / IT 系统无处不在
  • 每一个软件密集型系统都有软件设计和软件架构
  • 软件设计与架构在实践、教育和研究中都变得越来越重要
  • 作为一种职业：软件架构师
  • 作为研究领域：
    • 最早大约从 1960 年开始
    • 自 1990 年以来受到大量关注
  • 本课程关注：
    • 软件设计与架构的概念、原则、方法和模式
    • 软件设计与架构的前沿实践

第 5 页

自 2010 年代以来，美国最佳职业排名前 1-3：软件架构师

这一页用职业排名和行业数据说明：软件架构师是重要且高价值的软件职业。右侧图表也展示了软件工程相关任务中，开发、维护、质量保证、需求工程、软件设计和管理等活动的比例，以及大语言模型在软件工程任务中的应用分布。

第 6 页

学习目标

  • 理解软件设计与软件架构的概念和原则
  • 能够通过需求分析或逆向架构来创建软件架构
  • 在创建软件架构和设计时应用模式、风格和框架
  • 系统地分析软件设计并评价软件架构
  • 理解软件设计与架构中使用的前沿方法
  • 理解软件设计、软件架构与其他软件工程主题领域之间的关系

第 7 页

课程设计：架构部分 1

资料来源：

  • SECS 软件工程课程标准
    • 第 4.11 节：软件建模与分析
    • 第 4.12 节：软件设计
    • 与其他领域有紧密关系
  • SWEBOK 软件工程知识体系
    • 第 3 章：软件设计

参考过的以往课程：

  • UNSW COMP9117
  • USYD INFO3220
  • ITU & SMU
  • NJU 2014-2025

2026 年安排：

  • 4 月 / 5 月，第 8-10 周：软件架构概念、质量属性与战术
  • 5 月 / 6 月，第 11-14 周：架构模式、设计方法、架构评价、微服务架构
  • 6 月，第 16 周：课程复习

第 8 页

课程设计：架构部分 2

授课：

  • 课堂中鼓励互动

作业：

  • 应用你学到的原则和方法
  • 针对技术进行独立调研
  • 利用你的编程和技术背景
  • 所有作业都会进行查重

小组练习：

  • 学生将独立完成个人作业，并被分配到小组完成小组任务
  • 这些环节用于强化对课堂材料的学习，帮助你获得理解和技能
  • 小组练习中，需要系统地创建和 / 或评价一个带有部分设计的软件架构

第 9 页

最终成绩

  • 期末考试组成：
    • 50% 来自架构设计
    • 50% 来自设计模式
  • 总评成绩 = 期末考试 × 60% + 作业 × 40%
  • 期末考试包括多种题型：
    • 简答题
      • 知识：回忆概念、原则和方法
      • 理解：解释、比较、对比等
    • 设计与评价练习
      • 理解：将知识迁移到新场景中，推断原因等
      • 应用：把学过的内容应用到新的具体情境中
  • 考试会提供必要的参考材料

第 10 页

参考书目：没有指定官方教材

  • Bass、Clements、Kazman：《Software Architecture in Practice》
  • Cervantes、Kazman：《Designing Software Architecture: A Practical Approach》
  • Richardson：《Microservices Patterns》
  • Clements 等：《Documenting Software Architectures: Views and Beyond》
  • Taylor、Medvidovic、Dashofy：《Software Architecture: Foundations, Theory, and Practice》
  • Bass、Lu、Weber、Zhu：《Engineering AI Systems: Architecture and DevOps Essentials》

第 11 页

课程事务页面汇总

这一页是前面课程安排、联系方式、评分方式、参考书等内容的缩略图总览。

第 12 页

导论
Introduction

第 13 页

理解软件工程

  • 软件 × 工程
    • 软件 vs. ?
    • 科学 vs. 工程

图中表达的是：

  • 科学路径：研究已有事物，例如天文学、生物学、化学等；常用观察、测量和实验
  • 工程路径：制造新的事物，例如金字塔、船、汽车、电话等；常用构造和评价
  • 更好的工具、更好的材料理解和测量方法，会让科学与工程相互促进

第 14 页

什么是软件架构？

定义 1：

一个程序或计算系统的软件架构，是该系统的一个或多个结构。这些结构由软件元素、这些元素的外部可见属性，以及它们之间的关系组成。——SEI 软件工程研究所

定义 2：

软件架构是一个系统的基本组织结构，体现在系统的组件、组件之间的关系、组件与环境之间的关系，以及指导系统设计和演化的原则中。——IEEE 1471-2000

第 15 页

架构 vs. 设计

  • 架构属于软件设计
    • 所有架构都是软件设计，但不是所有设计都是软件架构
    • “架构化”活动是设计过程的一部分
  • 其他观点：
    • 架构是高层设计
    • 架构是一组设计决策
  • 架构描述系统的结构 / 组织：
    • 元素：组件与连接件
    • 关系：静态关系与动态关系
  • 架构还描述属性：
    • 元素的属性
    • 元素组合的属性
    • 整个系统的属性

第 16 页

架构 vs. 结构

  • 结构指将系统分解为组件、模块或子系统
  • 架构进一步定义：
    • 组件接口
      • 一个组件能做什么？
    • 组件通信和依赖
      • 组件之间如何通信？
    • 组件职责
      • 当你请求一个组件时，它到底会做什么？

第 17 页

结构与架构

这一页通过图示说明：架构不仅是组件的分解，还包含组件之间的依赖、交互方式和组织方式。不同的结构组织会导致不同的依赖关系，也会影响系统的可维护性和演化成本。

第 18 页

架构规定通信

通信包括：

  • 数据传递机制，例如：
    • 函数调用
    • 远程方法调用
    • 异步消息
  • 控制流
    • 组件之间的消息流如何配合以实现所需功能
    • 顺序执行
    • 并发 / 并行执行
    • 同步机制

第 19 页

架构处理非功能需求

  • 非功能需求 NFRs 定义“系统工作得有多好”
  • 非功能需求很少被完整地包含在功能需求中
    • 也叫架构需求
    • 必须由架构师主动挖掘
  • 非功能需求包括：
    • 技术约束
    • 业务约束
    • 质量属性
  • 讨论：你能列出哪些质量属性？

第 20 页

设计是一种抽象

  • 架构提供了设计的更高层次抽象视图
    • 隐藏设计复杂性和实现细节
    • 架构元素与软件元素之间不一定存在直接映射关系
  • 黑盒设计与白盒设计
    • 对系统结构和交互进行非正式描述
    • 体现架构中包含的设计哲学
  • 讨论：为什么设计中需要抽象？

第 21 页

架构视图

  • 软件架构代表一个复杂的设计产物
  • 架构可能有很多种视图
    • 可以类比建筑：平面图、外部视图、电气图、管道图、空调图等

含义是：同一个系统可以从不同角度观察，不同视图服务于不同关注点和不同利益相关者。

第 22 页

如何开展设计？

通用设计策略：

  • 分解
  • 抽象
  • 逐步进行：分而治之
  • 生成并测试
  • 迭代：增量式求精
  • 可复用元素

第 23 页

P. Krutchen 的 4+1 视图模型

  • 逻辑视图：描述架构中具有架构意义的元素，以及它们之间的关系
  • 进程视图：描述架构中的并发和通信元素
  • 物理视图：描述主要进程和组件如何映射到应用硬件上
  • 开发视图：描述软件组件在开发环境中的内部组织方式，例如配置管理工具中的组织
  • 架构用例：捕获架构需求，通常与多个特定视图相关

第 24 页

建筑师与软件架构师

引用：

建筑师设计结构，以满足人的需要。——James Fitch, 1972

架构师的角色保持一致：

  • 倾听客户，理解整体需求
  • 审查可行性
  • 形成结构的实践愿景并创建蓝图
  • 监督构建过程，确保符合计划
  • 在设计变化、危机和模糊性中引导愿景

软件架构师监督软件构建专业人员：

  • 程序员、工程师、设计师

著名软件架构师：

  • Bill Gates：微软首席软件架构师
  • Tim Berners-Lee：万维网发明者和首席架构师
  • Roy Fielding：REST 架构风格提出者

第 25 页

软件架构师做什么？

  • 沟通协调
    • 在客户、技术团队、业务 / 需求分析人员之间沟通
    • 与管理层或市场人员沟通
  • 软件工程
    • 掌握软件工程最佳实践
  • 技术知识
    • 深入理解技术领域
  • 风险管理
    • 管理与设计和技术选择相关的风险
    • 以及其他风险

第 26 页

通用设计模型

设计过程的输入包括：

  • 需求规约
  • 约束条件，例如资源、组织、经验、已有软件复用等
  • 设计者的决策

设计过程的输出是：

  • 程序描述

也就是说，设计过程是在需求、约束和设计者决策共同影响下，把需求转化为可实现的程序描述。

第 27 页

软件设计过程

左侧图示：

  • 需求规约
  • 架构设计决策
  • 逻辑设计细节
  • 详细设计决策
  • 物理设计细节

右侧图示：

  • 澄清需求本质
  • 分析需求并建立问题的黑盒模型
  • 提出白盒设计方案
  • 验证方案，包括使用原型
  • 以合适形式实现设计方案

这一页强调：设计是从需求到架构、逻辑设计、详细设计和物理设计逐步细化的过程。

第 28 页

架构活动

  • 为系统创建业务案例
  • 理解需求
  • 创建和选择架构
  • 与利益相关者沟通架构，包括开发者
  • 分析或评价架构
    • 总体方法论
    • 面向特定质量属性的技术
  • 实现架构
  • 确保实现符合架构

第 29 页

软件架构过程

图中过程包括：

  • 明确架构显著需求 ASRs
  • 识别并优先排序质量属性场景
  • 结合需求、约束、模式和战术进行架构设计
  • 得到候选视图草图
  • 选择并合并视图
  • 进行架构文档化
  • 进行架构评价
  • 利益相关者持续参与反馈

第 30 页

架构生命周期

主要阶段包括：

  • 架构分析：检查架构关注点和上下文，形成架构显著需求
  • 架构综合：针对给定的架构显著需求设计架构方案
  • 架构评价：用架构显著需求评价候选架构方案
  • 架构实现：通过详细设计和开发实现架构
  • 架构维护：修改或演化架构，以进行修正和扩展

第 31 页

软件设计与架构知识领域

  • 软件设计基本概念
    • 通用设计概念
    • 软件开发生命周期中的上下文：需求、设计、构造和测试
    • 设计过程：策略、角色、活动
  • 关键技术问题：
    • 并发
    • 控制与事件处理
    • 分布式
    • 异常处理
    • 交互式系统
    • 持久化
  • 软件结构与架构
    • 架构结构与视点
    • 架构风格和模式：宏观架构
    • 设计模式：微观架构
  • 软件设计方法
    • 架构方法，例如属性驱动设计
    • 设计方法，例如领域驱动设计

第 32 页

软件设计与架构知识领域

  • 软件设计质量分析与评价
    • 质量属性
    • 质量分析与评价方法、技术和工具
      • 设计评审，例如 SEI 的架构权衡分析方法 ATAM
      • 静态分析和动态分析
      • 仿真和原型
    • 度量
      • 架构层面度量
      • 技术特定度量
  • 设计建模与表示
    • 架构与设计符号，例如架构描述语言 ADL
    • 统一建模语言 UML
    • 设计文档：视图以及更多内容
    • 其他：能力、关注点和领域各不相同，例如 ACME、Rapide

第 33 页

架构课程预览

  • 第 1 讲：导论
    • 软件架构概念
  • 第 1-3 讲：质量属性与架构战术
    • 质量属性、非功能需求和场景
    • 实现质量属性的战术
    • 架构显著需求
  • 第 4 讲：架构模式
    • 软件设计中的模式
    • 架构风格和模式
  • 第 5/6 讲：架构设计方法
    • 通用设计策略
    • 软件设计过程与架构化过程
    • ADD 方法：属性驱动设计

第 34 页

架构课程预览

  • 第 7 讲：微服务架构
  • 第 8 讲：课程复习 —— 软件架构
  • 期末考试

第 35 页

参考书

这一页展示了若干软件架构参考书封面，包括：

  • Software Architecture in Practice
  • Designing Software Architectures
  • Engineering AI Systems
  • Microservices Patterns
  • Documenting Software Architectures
  • Software Systems Architecture

第 36 页

导论部分页面总览

这一页是前面导论相关页面的缩略图总览。

第 37 页

架构的作用

  • 架构是最早的设计产物之一，它表示关于“需求如何被实现”的决策。作为早期设计决策的体现，架构代表那些最难改变的设计决策，因此值得最谨慎地考虑
  • 架构是在产品线工程中取得成功的关键产物。产品线工程是以更少的努力、费用和风险，系统化开发一族相似系统的学科
  • 当有人开始处理一个系统时，架构通常是第一个被检查的设计产物
  • 软件架构为维护和修改决策提供参考框架

第 38 页

为什么软件架构重要？

  • 软件架构提供沟通工具
    • 它是一个参考框架，在其中可以识别并协商相互竞争的利益
    • 与用户协商需求
    • 让客户了解进度、成本等情况
    • 落实管理决策和资源分配
  • 软件架构体现最早的一组设计决策
    • 它约束实现和开发人员
    • 实现必须符合架构
    • 资源分配决策会约束各个组件的实现

第 39 页

为什么软件架构重要？

早期设计决策的体现：

  • 软件架构决定开发和维护工作的组织结构，例如：
    • 团队划分
    • 预算和计划单位
    • 工作分解结构的基础
    • 文档组织
    • 配置管理库的组织
    • 集成的基础
    • 测试计划和测试的基础
    • 维护的基础

第 40 页

为什么软件架构重要？

  • 架构会促进或阻碍质量属性的达成，例如可修改性、安全性、易用性等
  • 架构会影响质量，但不能保证质量，因为还有许多其他因素参与其中
  • 架构会引发关于潜在变化的讨论。一个系统 80% 的工作量可能发生在部署之后
  • 架构把变化分为三类：
    • 局部变化：修改单个组件
    • 非局部变化：修改多个组件
    • 架构级变化：修改系统的基本结构、通信机制和协调机制

第 41 页

为什么软件架构重要？

  • 架构是一种可迁移、可复用的抽象，是一对多映射：一个架构可以对应多个系统
  • 架构是产品共性的基础：一整条产品线可以共享一个架构
  • 系统可以通过架构来集成独立开发的组件，这就是基于组件的软件工程 CBSE

第 42 页

手机系统架构

这一页展示一个移动电话系统架构示例。图中包含电话呼入呼出、移动性管理、无线资源管理、认证、寻呼、加密、切换、位置登记、数据库等组件及其交互关系。

第 43 页

洗衣机架构

这一页展示洗衣机系统的架构示例。它说明嵌入式系统也有架构：传感器、控制逻辑、洗涤流程、用户输入、执行部件等需要通过清晰结构协作。

第 44 页

AI 护栏架构

这一页展示 AI Guardrail Architecture。图中包含输入护栏、RAG 护栏、执行护栏、输出护栏、多模态护栏、知识库、检索式 AI 模型、外部工具、基础模型等元素。

含义是：AI 系统也需要架构设计，通过多层护栏、知识检索、工具调用和模型服务来控制风险并提升系统质量。

第 45 页

软件研发效能实验室

这一页是实验室宣传与联系方式，包括 DevOps 相关活动、公众号和联系二维码。