《软件架构设计文档模板》由会员分享，可在线阅读，更多相关《软件架构设计文档模板（18页珍藏版）》请在金锄头文库上搜索。
1、Software Architecture DocumentVersion Revision HistoryDate Version Description Author Version: Software Architecture Document Date: Page 2 of 18目录1. 文档简介 41.1 文档目的 41.2 文档范围 41.3 定义、缩写词和缩略语 41.4 参考资料 42. 架构描述方式 42.1 架构视图阅读指南 42.2 图表与模型阅读指南 53. 架构设计目标 53.1 关键功能 53.2 关键质量属性 53.3 业务需求和约束因素 54. 架构设计原则 6
2、4.1 架构设计原则 64.2 备选架构设计方案及被否原因 64.3 架构设计对后续工作的限制（详设，部署等） 65. 逻辑架构视图 65.1 职责划分与职责确定 75.2 接口设计与协作机制 85.3 重要设计包 106. 开发架构视图 116.1 Project 划分 116.2 Project 1 116.2.1 Project 目录结构指导 126.2.2 程序单元组织 126.2.3 框架与应用之间的关系（可选） 126.3 Project 2 136.4 Project n 137. 运行架构视图 137.1 控制流组织 137.2 控制流的创建、销毁、通信 137.3 加锁设计
3、148. 物理架构视图 148.1 物理拓扑 148.2 软件到硬件的映射 15 Version: Software Architecture Document Date: Page 3 of 188.3 优化部署 169. 数据架构视图 169.1 持久化机制的选择 179.2 持久化存储方案 179.3 数据同步与复制策略 1710. 关键质量属性的设计原理 17 Version: Software Architecture Document Date: Page 4 of 181. 文档简介帮助读者对本文档建立基本印象，并为阅读后续内容扫清障碍。1.1 文档目的文档目的，非项目目的。否则
4、造成同一项目多个文档之间的内容重复，不利于文档维护。本小节应指明文档针对的读者对象，最好列出各种读者角色，并说明每种读者角色应该重点阅读的章节。1.2 文档范围文档的 Scope，非项目的 Scope。否则造成同一项目多个文档之间的内容重复，不利于文档维护。1.3 定义、缩写词和缩略语集中列举文档中的定义、缩写词和缩略语。1.4 参考资料本项目经审核的计划书、合同、上级批文；本项目的其他已发表文件；本文档引用的文件资料，如软件开发标准。具体而言，应包括参考资料的题目（必须）、编号、版本号（必须）、发表日期、发布方，必要时还可以说明如何使用这些资料。2. 架构描述方式 为了让读者更好地理解架构文
5、档 ，在本节应当说明文档涉及的架构视图，并指明为了描述设计决策用到了哪些图表和模型。2.1 架构视图阅读指南以多视图的方式来组织架构文档 是大势所趋。ADMEMS 推荐的是经过优化的 5 视图方法，如下图所示。 Version: Software Architecture Document Date: Page 5 of 182.2 图表与模型阅读指南对后续文档内容中所用到的建模语言（例如 UML）、表格（例如目标-场景- 决策表）等进行说明。3. 架构设计目标功能、质量、约束，一个都不能少。3.1 关键功能对架构设计至关重要的功能，包括如下 4 类：核心功能、必做功能、高风险功能、独特功能。
6、所谓独特功能，指这个功能覆盖了上述 3 类功能没有涉及到的职责。3.2 关键质量属性人之所以痛苦，很多时候是因为追求错误的东西。下图是 ADMEMS 方法确定关键质量的 5大原则的整体思路图。3.3 业务需求和约束因素ADMEMS 方法创造性地提出约束需求的 4 大类型，这是一种极为实用的分类方式。特别是业务需求对架构设计而言是一种约束的观点，解决了很多架构师的现实困惑。下图标明了 4 类约束在“需求层次-需求方面矩阵（又称 ADMEMS 矩阵）”中的位置，可以帮助我们理解产生约束需求的根源。 Version: Software Architecture Document Date: Page
7、 6 of 184. 架构设计原则投标时经常讲“架构设计原则 ”，但到了架构文档，这些着眼大局的考虑却“丢了”。ADMEMS 方法推荐的本文档模板，认为应当把它们“找回来”。4.1 架构设计原则着重描述重大的权衡取舍考虑。4.2 备选架构设计方案及被否原因在概念架构一级，对备选架构设计方案进行描述，并阐述它们未被采用的原因。这有利于团队了解当前架构设计方案的来龙去脉，提高团队对当前架构设计方案的认可度。4.3 架构设计对后续工作的限制（详设，部署等）架构设计不仅应该包含“指导 ”，也应该包含重要的“限制”。例如，一份只是说明“性能和可扩展性都重要”的架构文档，实际上忽视了“可扩展性和性能之间存
8、在的矛盾关系”。此时，最有效的办法就是在架构文档中明确说明“任何提升可扩展性的架构设计和详细设计，都应通过架构团队的评审才能引入，以确保性能目标不受重大影响”。5. 逻辑架构视图 关注点：此架构设计视图的关注点是职责划分。注意：逻辑架构视图无疑是最重要的，但同时也应避免“架构 = 模块 + 接口”等以偏概全的认识。参考：任何复杂系统的架构设计都不是一蹴而就的，所以架构师需要理性思维过程的指导。针对逻辑架构设计这个关键环节，一线架构师实践指南一书给出了 2 条建议：一是“以质疑驱动的螺旋思维”，二是相对分离地考虑“结构方面的切分”和“行为方面的定义”。下图所示即为 ADMEMS 方法推荐的逻辑架
9、构设计理性思维过程。 Version: Software Architecture Document Date: Page 7 of 185.1 职责划分与职责确定内容：将系统切分成更小的单元，并明确这些单元的职责。具体而言，职责单元可以是层、子系统、模块、关键类等。意义：一句话，职责划分不合理，功能和质量都会受到影响。也就是说，功能需求和质量需求无一不和职责划分相关：一方面，每个功能都是由一条职责协作链完成的；另一方面，职责划分方式也影响着质量，于是需要职责模型针对特定质量属性要求做出相应调整和优化。很多人认为架构设计就是职责划分的艺术，虽略显片面，但足以表明职责划分的重要性。参考：基于对业
10、界大量案例的研究，ADMEMS 方法梳理出了“模块划分的 3 种必用手段”，如下图所示，更多内容可参考一线架构师实践指南一书。 Version: Software Architecture Document Date: Page 8 of 185.2 接口设计与协作机制内容：本节描述接口的定义，以及协作的方式和规范。意义：恰恰是因为有了各模块之间“未来合作的契约”，分头开发各模块才有了基本保证。参考：ADMEMS 方法推荐利用 “包-接口”图，来识别接口。下图为一个“包-接口”图的示例。 Version: Software Architecture Document Date: Page 9
11、of 18参考：ADMEMS 方法推荐使用序列图，建议少用、甚至杜绝使用协作图。下图为一个序列图的示例。 Version: Software Architecture Document Date: Page 10 of 185.3 重要设计包内容：对重要子系统的设计进行“灰盒”级描述。意义：“每个子系统在架构设计中都应保持黑盒子 ”的观点，过于理想化了。对于业务层、通用协作机制而言，经常需要在架构设计期间就引入“灰盒”级描述。参考：类图和灰盒包图，在本节中较多出现。下图为一灰盒包图示例。 Version: Software Architecture Document Date: Page 11
12、 of 186. 开发架构视图关注点：此架构设计视图的关注点是程序单元组织。注意：此架构设计视图是必须的、不应“剪裁”掉的。但实际情况却是，很多架构师不关注开发架构视图，导致很多程序开发人员抱怨“架构师就知道高来高去，架构对编程工作没什么指导性”。6.1 Project 划分内容：本节说明整个系统将划分成哪几个 Project 来开发，其中，Project 指开发环境所感知到的“工程”。意义：基本好处是，有利于开发的组织；而对一些大型的集成系统而言，由于同时涉及了Web 应用、桌面应用、嵌入式应用等软件形态，所以此时 Project 划分其实是不得不做的；最后，我们推荐核心代码应主动地切分到单
13、独的 Project 以进行独立的软件配置管理（ SCM），以降低核心代码外泄的风险。参考：Project 划分必然是属于 “架构设计”的工作，严格来讲仅靠“需求分析”划分的业务域（Business Area）直接映射到 Project 经常意味着工作内容的遗漏。其实，业界不少有见地的专家已经认识到 WBS（工作分解结构）做得太早太草率危害很大，就与“Project 划分不到位”不无关系。 6.2 Project 1内容：对 Project 划分后的每个 Project 进行目录结构、程序单元组织、框架与应用关系的说明。 Version: Software Architecture Docum
14、ent Date: Page 12 of 186.2.1 Project 目录结构指导内容：关于该 Project 一级目录、二级目录等基本目录结构的约定。意义：为团队并行开发提供必要基础，让不同程序小组看到自己应该负责的程序目录。参考：不要把所有程序目录的约定都定义得太细，否则这份架构文档就要天天更新了。 6.2.2 程序单元组织内容：源码、程序库、框架、目标码等类型程序单元之间的编译依赖关系。意义：或许有人认为这没什么技术含量，但架构设计本来就不是只关心技术含量最高问题的。君不见，很多软件工程师跳槽到新的企业之后，竟然连一个能正常编译源码的开发环境都建不起来其实，他们“不知道 Projec
15、t 所依赖的 Library 有哪些”是其中重要原因这本应在架构文档中给出明确描述的。 6.2.3 框架与应用之间的关系（可选）内容：框架（Framework）。意义：既然不适用 Framework 的开发越来越少了，既然程序员犯的很多错误都和对Framework 理解不到位有关，架构师就有责任明确说明 Framework 和待开发系统之间的关系。 参考：下图描述了 JGraph 框架和待开发应用的关系。 参考：下图描述了 Struts 框架和待开发应用的关系。 Version: Software Architecture Document Date: Page 13 of 186.3 Project 2内容：对 Project 划分后的每个 Project 进行目录结构、程序单元组织、框架与应用关系的说明。6.4 Project n内容：对 Project 划分后的每个 Project 进行目录结构、程序单元组织、框架与应用关系的说明。7. 运行
