《软件架构设计文档》模板.doc

vProject Name〉Versio n: <1.0>Software Architecture Docume ntDate: < yyyy-mm-dd >vdocument identifier>目录1.文档简介31.1 文档目的31.2 文档范围31.3 定义、缩写词和缩略语31.4 参考资料32.架构描述方式32.1 架构视图阅读指南32.2 图表与模型阅读指南43.架构设计目标43.1 关键功能43.2 关键质量属性43.3 业务需求和约束因素54.架构设计原则54.1 架构设计原则54.2 备选架构设计方案及被否原因54.3 架构设计对后续工作的限制（详设，部署等）55.逻辑架构视图65.1 职责划分与职责确定65.2 接口设计与协作机制75.3 重要设计包96.开发架构视图106.1 Project 划分106.2 Project 1106.2.1 Project目录结构指导116.2.2程序单元组织116.2.3框架与应用之间的关系（可选）116.3 Project 2 126.4 Project n 127.运行架构视图127.1 控制流组织127.2 控制流的创建、销毁、通信137.3 加锁设计138.物理架构视图138.1 物理拓扑138.2 软件到硬件的映射148.3 优化部署15vProject Name〉Versio n: <1.0>Software Architecture Docume ntDate: < yyyy-mm-dd >vdocument identifier>9. 数据架构视图159.1持久化机制的选择169.2持久化存储方案169.3数据同步与复制策略1610.关键质量属性的设计原理16ADMEMS Page # of 17vProject Name〉Versio n: <1.0>Software Architecture Docume ntDate: < yyyy-mm-dd >vdocument identifier>1. 文档简介［帮助读者对本文档建立基本印象，并为阅读后续内容扫清障碍。

］1.1 文档目的［文档目的，非项目目的否则造成同一项目多个文档之间的内容重复，不利于文档维护本 小节应指明文档针对的读者对象，最好列出各种读者角色，并说明每种读者角色应该重点阅读 的章节］1.2 文档范围［文档的Scope，非项目的Scope否则造成同一项目多个文档之间的内容重复，不利于文档 维护］1.3 定义、缩写词和缩略语［集中列举文档中的定义、缩写词和缩略语 ］1.4 参考资料［本项目经审核的计划书、合同、上级批文；本项目的其他已发表文件；本文档引用的文件资 料，如软件开发标准具体而言，应包括参考资料的题目（必须）、编号、版本号（必须）、 发表日期、发布方，必要时还可以说明如何使用这些资料 ］2. 架构描述方式［为了让读者更好地理解《架构文档》，在本节应当说明文档涉及的架构视图，并指明为了描 述设计决策用到了哪些图表和模型 ］2.1 架构视图阅读指南［以多视图的方式来组织《架构文档》是大势所趋 ADMEMS推荐的是经过优化的 5视图方法，如下图所示］vProject Name〉Versio n: <1.0>Software Architecture Docume ntDate: < yyyy-mm-dd >vdocument identifier>面向控制流面向文件面向Table 或文杵而向对彖 或结构化逻辑架构、职奇划分 职责间协作运行架构 控制流 控制流组织程序单元 程序单元组织数扌居架构y捋久数据单元物理架构、、 物理节点 、 物理节点拓卅1. /面向节点22 图表与模型阅读指南［对后续文档内容中所用到的建模语言（例如 UML ）、表格（例如目标-场景-决策表）等进行说明。

］3. 架构设计目标［功能、质量、约束，一个都不能少 ］3.1 关键功能［对架构设计至关重要的功能，包括如下 4类：核心功能、必做功能、高风险功能、独特功能所谓独特功能，指这个功能覆盖了上述 3类功能没有涉及到的职责］3.2 关键质量属性［人之所以痛苦，很多时候是因为追求错误的东西下图是 ADMEMS方法确定关键质量的 5ADMEMS Page # of 17vProject Name〉Versio n: <1.0>Software Architecture Docume ntDate: < yyyy-mm-dd >vdocument identifier>3.3 业务需求和约束因素[ADMEMS方法创造性地提出约束需求的 4大类型，这是一种极为实用的分类方式特别是业 务需求对架构设计而言是一种约束的观点，解决了很多架构师的现实困惑下图标明了 4类约束在“需求层次-需求方面矩阵（又称 ADMEMS矩阵）”中的位置，可以帮助我们理解产生 约束需求的根源]广义功能质量约東ADMEMSec口慈ifiH力潘IPage # of 17ADMEMSec口慈ifiH力潘IPage # of 17业务级用户级需求开发级需求用户需求彳了为需求运行期质量开发期质量/ I I.** I耳开发团臥磨餚長 尸 n ■ " 省石构建坏境■I业务环境分批丈施竞争因丟与咅浄并X堆沪4. 架构设计原则[投标时经常讲“架构设计原则”，但到了《架构文档》，这些着眼大局的考虑却“丢了”。

ADMEMS方法推荐的本文档模板，认为应当把它们“找回来” ]4.1 架构设计原则[着重描述重大的权衡取舍考虑 ]4.2 备选架构设计方案及被否原因[在概念架构一级，对备选架构设计方案进行描述，并阐述它们未被采用的原因这有利于团 队了解当前架构设计方案的来龙去脉，提高团队对当前架构设计方案的认可度 ]4.3 架构设计对后续工作的限制（详设，部署等）[架构设计不仅应该包含“指导”，也应该包含重要的“限制”例如，一份只是说明“性能 和可扩展性都重要”的《架构文档》，实际上忽视了“可扩展性和性能之间存在的矛盾关 系”此时，最有效的办法就是在《架构文档》中明确说明“任何提升可扩展性的架构设计和 详细设计，都应通过架构团队的评审才能引入，以确保性能目标不受重大影响” ]ADMEMSec口慈ifiH力潘IPage # of 17vProject Name〉Versio n: <1.0>Software Architecture Docume ntDate: < yyyy-mm-dd >vdocument identifier>5.逻辑架构视图［关注点：此架构设计视图的关注点是职责划分 ］［注意：逻辑架构视图无疑是最重要的，但同时也应避免“架构 =模块+接口”等以偏概全的认识。

］［参考：任何复杂系统的架构设计都不是一蹴而就的，所以架构师需要理性思维过程的指导针对逻辑架构设计这个关键环节，《一线架构师实践指南》一书给出了 2条建议：一是“以质疑驱动的螺旋思维”，二是相对分离地考虑“结构方面的切分”和“行为方面的定义”下图 所示即为ADMEMS方法推荐的逻辑架构设计理性思维过程 ］质就自已的设计， 特殊功能场景支持吗 耦合性、重用性咋样结构方面的切分5.1包接口± .-I d aa完善序列图行为方面的约定让职责协作起来* 验还能否完成功能? 功能完成得是否好?职责划分与职责确定［内容：将系统切分成更小的单元，并明确这些单元的职责具体而言，职责单元可以是层、 子系统、模块、关键类等］［意义：一句话，职责划分不合理，功能和质量都会受到影响也就是说，功能需求和质量需 求无一不和职责划分相关：一方面，每个功能都是由一条职责协作链完成的；另一方面，职责 划分方式也影响着质量，于是需要职责模型针对特定质量属性要求做出相应调整和优化很多 人认为架构设计就是职责划分的艺术，虽略显片面，但足以表明职责划分的重要性 ］［参考：基于对业界大量案例的研究， ADMEMS方法梳理出了 “模块划分的 3种必用手段”，如下图所示，更多内容可参考《一线架构师实践指南》一书。

］ADMEMS Page # of 17vProject Name〉Versio n: <1.0>Software Architecture Docume ntDate: < yyyy-mm-dd >vdocument identifier>架构本身考虑人的因素考虑5.2 接口设计与协作机制［内容：本节描述接口的定义，以及协作的方式和规范 ］［意义：恰恰是因为有了各模块之间“未来合作的契约”，分头开发各模块才有了基本保证 ］［参考：ADMEMS方法推荐利用“包-接口”图，来识别接口下图为一个“包 -接口”图的示例］ADMEMS Page # of 17vProject Name〉Versio n: <1.0>Software Architecture Docume ntDate: < yyyy-mm-dd >vdocument identifier>进度展现 回到接口Facade 甜眷描述铁种搖口習能援冲机制内祚抚冲达“瓠定血11客ijT M相剛童口进行回返对超出额定九11喜債的内容进打肖催廉右接口［参考：ADMEMS方法推荐使用序列图，建议少用、甚至杜绝使用协作图下图为一个序列图 的示例。

］vProject Name〉Versio n: <1.0>Software Architecture Docume ntDate: < yyyy-mm-dd >vdocument identifier>㈢龍扌拧痒轴，i論阿耀出gL11IiiiWrite C）"J—11111亠Callbsak （Buffer A IIT1 1110ulpui（ Jh 用缓紳区）「滿 f ]IJ—IIIL——11Callback £ 吐度）] L—1il炜进度J1。