文档核心要素：架构视图、质量属性与决策记录
好，咱们接着聊。上一章我讲了文档的定位和框架，这一章咱们深入核心——到底一份嵌入式架构文档里，哪些东西是必须写清楚的？
我个人习惯，把架构文档的“灵魂”归结为三块：架构视图、关键质量属性、设计决策记录。这三样东西，缺一个，文档就瘸腿了。
一、4+1视图模型：把架构“看”清楚
你想想看，一个嵌入式系统有多复杂？硬件、软件、网络、部署、场景……如果只用一张图去描述，那肯定是一团浆糊。所以，我们得用多视角去看它。
Philippe Kruchten 提出的 4+1 视图模型，我用了十几年，真心觉得好用。它不是说让你画五张图就完事，而是让你从五个维度去思考架构。
| 视图名称 | 关注点 | 嵌入式场景举例 |
|---|---|---|
| 逻辑视图 | 功能分解、模块职责 | 传感器数据采集模块、控制算法模块 |
| 进程视图 | 并发、同步、通信 | RTOS任务划分、中断优先级、消息队列 |
| 开发视图 | 代码组织、编译单元 | 静态库/动态库划分、头文件依赖 |
| 物理视图 | 硬件拓扑、部署映射 | MCU选型、外设总线连接、PCB布局 |
| 场景视图 | 关键用例、交互流程 | 启动流程、异常处理流程、OTA升级 |
我在项目中遇到过最典型的反面教材：团队只画了逻辑视图，结果到了联调阶段，发现两个模块在同一个中断里抢资源，死锁了。这就是进程视图没画清楚的后果。
我的建议： 别贪多。对于嵌入式系统，进程视图和物理视图往往是重中之重。先把这两个画透，再补其他视图。
二、关键质量属性：架构的“硬指标”
架构好不好，不能光靠感觉。得有指标。这些指标，就是关键质量属性（Quality Attributes）。
说白了，功能决定你能不能跑，质量属性决定你跑得好不好。
常见的嵌入式质量属性包括：
- 可靠性：系统能不间断运行多久？看门狗怎么喂？
- 实时性：中断响应时间、任务切换延迟，有没有硬性要求？
- 安全性：功能安全（如ISO 26262）等级是多少？
- 可维护性：代码模块化程度高不高？换一个传感器型号要改多少代码？
- 功耗：电池供电设备，待机电流多少？
嗯，这里要注意。质量属性之间往往是冲突的。比如，你要高可靠性，可能就得加冗余硬件，功耗和成本就上去了。你要极致实时性，可能就得牺牲一些模块化设计。
我曾经踩过的坑： 在一个车载项目中，我们一味追求实时性，把所有中断优先级都设得很高。结果系统在高负载下频繁触发中断嵌套，反而导致低优先级任务饿死，系统整体吞吐量下降。后来我们重新梳理了质量属性优先级，才把问题解决。
所以，在架构文档里，你必须明确列出：哪些质量属性是“必须满足”的，哪些是“尽量优化”的。 最好用表格把每个属性的优先级、量化指标、验证方法写清楚。
三、设计决策记录：为什么这么干？
这是我最想强调的一点。很多工程师写文档，只写“做了什么”，不写“为什么这么做”。
结果呢？三个月后，你自己看着代码都发懵：“我当时为啥要用这个方案？”
设计决策记录（Architecture Decision Record, ADR），就是用来解决这个问题的。它记录的是：在某个时间点，面对某个问题，我们考虑了哪些方案，最终选了哪个，理由是什么。
我习惯用这种格式来写：
# ADR-001：选择 FreeRTOS 作为实时操作系统
## 背景
项目需要支持多任务调度，且对实时性有要求。
## 备选方案
1. FreeRTOS（开源，社区活跃）
2. uC/OS-III（商业授权，功能稳定）
3. 裸机轮询（无OS，资源占用最低）
## 决策
选择 FreeRTOS。
## 理由
- 开源免费，无授权风险
- 社区资源丰富，遇到问题容易找到解决方案
- 团队已有使用经验，学习成本低
- 内存占用可控，适合当前MCU（STM32F4系列）
## 影响
- 需要额外学习RTOS编程模型
- 任务栈大小需要仔细配置，避免溢出
一个小技巧： 每个决策记录都加上日期和作者。这样以后追溯起来，能知道是谁在什么背景下做的决定。我见过有些团队用Git来管理ADR，每次决策就是一个commit，效果很好。
你想想看，有了这些记录，新同事接手项目时，就不用再猜来猜去了。直接看ADR，就能理解整个架构的演进脉络。
总结一下
这一章咱们聊了三块核心内容：
- 4+1视图：从不同角度看清架构，重点抓进程视图和物理视图。
- 关键质量属性：给架构定硬指标，明确优先级和冲突处理。
- 设计决策记录：把“为什么”写清楚，让文档有灵魂。
下一章，我会讲讲文档的写作流程和工具链。嗯，到时候咱们聊聊怎么用Markdown和PlantUML高效产出这些内容。