阅读笔记

课程进行到现在，我越来越意识到一个之前被忽略的问题：好的架构设计如果无法清晰地表达出来，就没有价值。 架构师不仅要设计系统，还要让团队成员、客户、管理者理解这个设计。这就是架构描述的重要性。

4+1视图模型
课程重点讲了Kruchten的4+1视图模型，它从五个角度描述一个系统的架构：
逻辑视图（Logical View）：面向最终用户，描述系统的功能需求，通常用类图、对象图表示
开发视图（Development View）：面向开发人员，描述模块划分和代码组织结构
进程视图（Process View）：面向系统集成人员，关注运行时进程、线程的交互和并发
物理视图（Physical View）：面向运维人员，描述软件如何映射到硬件（服务器、网络等）
场景视图（Scenarios）：作为“+1”，用用例或场景来串联和验证其他四个视图

这个模型给我最大的启发是：没有一个视图能完整描述一个系统，必须从不同角度去看，每个视图服务于不同的利益相关者。

UML在架构描述中的使用
UML之前我学过，但一直停留在画类图、时序图的层面。课程让我知道，UML是架构描述的重要工具：

组件图描述系统的组件及其依赖关系
部署图描述物理节点的分配
包图描述模块的层次结构
用例图描述功能需求与用户的交互

一个具体的体会
这周我们小组在准备课程设计文档，我负责绘制架构图。以前我可能会画一张“大而全”的图，把所有东西塞在一起。现在我会按4+1视图的思路，分别绘制：类图（逻辑）、包图（开发）、部署图（物理），再配合核心功能的时序图（场景）。文档的可读性明显提升了，组内沟通也顺畅了许多。