如何编写一份合格的架构设计文档（一）
在软件开发中，作为一名工程师，经常会遇到需要技术设计文档的场景。比如项目验收时，需要技术设计文档作为验收材料；进行岗位晋升时，需要技术设计文档作为晋升材料；解决遗留系统问题时，如果有设计文档会使问题得到更快速的解决 ......
总之，作为一位软件工程师，会编写一份合格的架构设计文档是必备技能。今天，根据最近的学习，对如何编写架构设计文档做一个简单的总结。
主要从三个方面进行介绍：
谁需要编写架构设计文档
为什么需要架构设计文档
架构设计文档应该包含哪些内容
谁需要编写架构设计文档
很明显，是架构师需要编写架构设计文档。但是什么是架构师？
架构师是做架构设计、对系统架构负责的那个人。
架构师是是一顶帽子，而不是一把椅子；架构师是一个角色而不是一个职位。
架构师不是一个职位，不是一个 title , 而是做架构设计这件事的人。任何一个简单的系统都需要做架构设计，只是架构设计的复杂度不同。只要你在负责对一个系统进行架构设计，你就是这个系统的架构师。
架构师的主要职责
架构师的主要能力
为什么需要架构设计文档
架构设计文档是对一个系统的软件架构的具象化描述，是架构师系统设计思维的具体展示。
什么是软件架构
维基百科中对软件架构的描述如下：
软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
软件架构的组成，如下图：
从上图可以看出，架构文档是针对不同相关方，对系统软件架构的一种描述，用于阐述系统的架构设计，有利于指导后期系统的研发和运维等工作，是架构师进行软件架构设计过程中的输出产物。
架构设计文档应该包含哪些内容
架构设计文档是由 架构视图 组成。
4+1 视图模型
软件架构 = { 元素 ，形式 ，关系/ 约束 }
根据不同相关方的关注点不同，架构由多个视图组成，单一视图无法完整表达架构。
4+1 视图模型是由 IBM 提出，具体描述可以参见参考资料链接 2 。
该模型主要包含 5 个视图，具体如下：
逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
过程视图（Process View），捕捉设计的并发和同步特征。
物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
开发视图（Development View），描述了在开发环境中软件的静态组织结构。
场景视图（scenarios）,描述用例场景。
逻辑视图
相关方：客户、用户、开发组织管理者
视角：系统的功能元素，以及它们的接口，职责，交互
主要元素：系统，子系统，功能模块，子功能模块，接口
用途：开发组织划分，成本、进度评估
开发视图
相关方：开发相关人员，测试人员
视角：系统如何开发实现
主要元素：描述系统的层，分区，包，框架，系统通用服务，业务通用服务，类和接口，系统平台和相关基础框架
用途：指导开发组织设计和开发实现
物理视图
相关者：系统集成商，系统运维人员
视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置
主要元素：物理节点以及节点的通信
过程视图
相关者：性能优化，开发相关人员
视角：系统运行时线程，进程的情况
主要元素：系统进程，线程以及处理队列等
场景视图
相关者：用户，设计和开发人员
视角：概括了架构上最重要的场景（最典型或者最有危险）及其非功能性需求，通过这个场景的实现，阐明了架构的广度或众多架构元素运行的方式
总结
以上，就是针对架构设计文档主要由哪些架构视图组成做了简单介绍，文章中主要介绍了概念，对于具体如何建立模型，绘制视图未做具体介绍，后期会对如何使用 UML 进行软件架构设计进行学习总结。希望对大家有所帮助。
参考资料:
版权声明: 本文为 InfoQ 作者【izerone】的原创文章。
原文链接:【http://xie.infoq.cn/article/cea456c407b79a77939d028d0】。
本文遵守【CC BY-NC-ND】协议，转载请保留原文出处及本版权声明。
还未添加个人签名 2015.01.07 加入
还未添加个人简介
评论