如何编写一份合格的架构设计文档

在软件开发中,作为一名工程师,经常会遇到需要技术设计文档的场景。比如项目验收时,需要技术设计文档作为验收材料;进行岗位晋升时,需要技术设计文档作为晋升材料;解决遗留系统问题时,如果有设计文档会使问题得到更快速的解决 ......

总之,作为一位软件工程师,会编写一份合格的架构设计文档是必备技能。今天,根据最近的学习,对如何编写架构设计文档做一个简单的总结。

主要从三个方面进行介绍:

  • 谁需要编写架构设计文档

  • 为什么需要架构设计文档

  • 架构设计文档应该包含哪些内容

谁需要编写架构设计文档

很明显,是架构师需要编写架构设计文档。但是什么是架构师

架构师是做架构设计、对系统架构负责的那个人。

架构师是是一顶帽子,而不是一把椅子;架构师是一个角色而不是一个职位。

架构师不是一个职位,不是一个 title , 而是做架构设计这件事的人。任何一个简单的系统都需要做架构设计,只是架构设计的复杂度不同。只要你在负责对一个系统进行架构设计,你就是这个系统的架构师。

架构师的主要职责

如何编写一份合格的架构设计文档_第1张图片

架构师的主要能力

如何编写一份合格的架构设计文档_第2张图片

为什么需要架构设计文档

架构设计文档是对一个系统的软件架构的具象化描述,是架构师系统设计思维的具体展示。

什么是软件架构

维基百科中对软件架构的描述如下:

软件架构是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。

软件架构的组成,如下图:

如何编写一份合格的架构设计文档_第3张图片

软件架构组成

从上图可以看出,架构文档是针对不同相关方,对系统软件架构的一种描述,用于阐述系统的架构设计,有利于指导后期系统的研发和运维等工作,是架构师进行软件架构设计过程中的输出产物

架构设计文档应该包含哪些内容

架构设计文档是由 架构视图 组成。

4+1 视图模型

软件架构 = { 元素 ,形式 ,关系/ 约束 }

根据不同相关方的关注点不同,架构由多个视图组成,单一视图无法完整表达架构。

4+1 视图模型是由 IBM 提出,具体描述可以参见参考资料链接 2 。

该模型主要包含 5 个视图,具体如下:

  • 逻辑视图(Logical View),设计的对象模型(使用面向对象的设计方法时)。

  • 过程视图(Process View),捕捉设计的并发和同步特征。

  • 物理视图(Physical View),描述了软件到硬件的映射,反映了分布式特性。

  • 开发视图(Development View),描述了在开发环境中软件的静态组织结构。

  • 场景视图(scenarios),描述用例场景。

如何编写一份合格的架构设计文档_第4张图片

逻辑视图

  • 相关方:客户、用户、开发组织管理者

  • 视角:系统的功能元素,以及它们的接口,职责,交互

  • 主要元素:系统,子系统,功能模块,子功能模块,接口

  • 用途:开发组织划分,成本、进度评估

开发视图

  • 相关方:开发相关人员,测试人员

  • 视角:系统如何开发实现

  • 主要元素:描述系统的层,分区,包,框架,系统通用服务,业务通用服务,类和接口,系统平台和相关基础框架

  • 用途:指导开发组织设计和开发实现

物理视图

  • 相关者:系统集成商,系统运维人员

  • 视角:系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置

  • 主要元素:物理节点以及节点的通信

过程视图

  • 相关者:性能优化,开发相关人员

  • 视角:系统运行时线程,进程的情况

  • 主要元素:系统进程,线程以及处理队列等

场景视图

  • 相关者:用户,设计和开发人员

  • 视角:概括了架构上最重要的场景(最典型或者最有危险)及其非功能性需求,通过这个场景的实现,阐明了架构的广度或众多架构元素运行的方式

总结

以上,就是针对架构设计文档主要由哪些架构视图组成做了简单介绍,文章中主要介绍了概念,对于具体如何建立模型,绘制视图未做具体介绍,后期会对如何使用 UML 进行软件架构设计进行学习总结。希望对大家有所帮助。

你可能感兴趣的:(框架设计,系统架构,架构设计,架构师)