《软件架构设计资料文档》材料模板.docx

《《软件架构设计资料文档》材料模板.docx》由会员分享，可在线阅读，更多相关《《软件架构设计资料文档》材料模板.docx（13页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、- Software Architecture DocumentVersion DateVersionRevision HistoryDescriptionAuthor-目 录1. 文档简介41.1 文档目的41.2 文档范围41.3 定义、缩写词和缩略语41.4 参考资料42. 架构描述方式42.1 架构视图阅读指南42.2 图表与模型阅读指南53. 架构设计目标53.1 关键功能53.2 关键质量属性53.3 业务需求和约束因素54. 架构设计原则64.1 架构设计原则64.2 备选架构设计方案及被否缘由64.3 架构设计对后续工作的限制详设，部署等65. 规律架构视图65.1 职责划分与

2、职责确定75.2 接口设计与协作机制75.3 重要设计包76. 开发架构视图86.1 Project划分86.2 Project 186.2.1 Project名目构造指导86.2.2 程序单元组织86.2.3 框架与应用之间的关系可选86.3 Project 296.4 Project n97. 运行架构视图97.1 把握流组织107.2 把握流的创立、销毁、通信107.3 加锁设计108. 物理架构视图108.1 物理拓扑108.2 软件到硬件的映射118.3 优化部署119. 数据架构视图1210.9.19.29.3长期化机制的选择12长期化存储方案12数据同步与复制策略12关键质量属性

3、的设计原理131. 文档简介帮助读者对本文档建立根本印象，并为阅读后续内容扫清障碍。1.1 文档目的文档目的，非工程目的。否则造成同一工程多个文档之间的内容重复，不利于文档维护。本 小节应指明文档针对的读者对象，最好列出各种读者角色，并说明每种读者角色应当重点阅读的章节。1.2 文档范围文档的Scope，非工程的Scope。否则造成同一工程多个文档之间的内容重复，不利于文档 维护。1.3 定义、缩写词和缩略语集中列举文档中的定义、缩写词和缩略语。1.4 参考资料本工程经审核的打算书、合同、上级批文；本工程的其他已发表文件；本文档引用的文件资 料，如软件开发标准。具体而言，应包括参考资料的题目必

4、需、编号、版本号必需、发表日期、公布方，必要时还可以说明如何使用这些资料。2. 架构描述方式为了让读者更好地理解架构文档，在本节应当说明文档涉及的架构视图，并指明为了描述设计决策用到了哪些图表和模型。2.1 架构视图阅读指南以多视图的方式来组织架构文档是大势所趋。推举的是经过优化的5 视图方法，如以以下图所示。2.2 图表与模型阅读指南对后续文档内容中所用到的建模语言例如UML、表格例如目标-场景-决策表等进展 说明。3. 架构设计目标功能、质量、约束，一个都不能少。3.1 关键功能对架构设计至关重要的功能，包括如下4 类：核心功能、必做功能、高风险功能、独特功能。所谓独特功能，指这个功能掩盖

5、了上述3 类功能没有涉及到的职责。3.2 关键质量属性人之所以苦痛，很多时候是由于追求错误的东西。以以下图是确定关键质量的5 大原则的整体思路图。3.3 业务需求和约束因素制造性地提出约束需求的 4 大类型，这是一种极为有用的分类方式。特别是业务需求对架构设计而言是一种约束的观点，解决了很多架构师的现实困惑。以以下图标明白4 类约束在“需求层次-需求方面矩阵”中的位置，可以帮助我们理解产生约束需求的根源。4. 架构设计原则投标时常常讲“架构设计原则”，但到了架构文档，这些着眼大局的考虑却“丢了”。推举的本文档模板，认为应当把它们“找回来”。4.1 架构设计原则着重描述重大的权衡取舍考虑。4.2

6、 备选架构设计方案及被否缘由在概念架构一级，对备选架构设计方案进展描述，并阐述它们未被承受的缘由。这有利于团队了解当前架构设计方案的来龙去脉，提高团队对当前架构设计方案的认可度。4.3 架构设计对后续工作的限制详设，部署等架构设计不仅应当包含“指导”，也应当包含重要的“限制”。例如，一份只是说明“性能和可扩展性都重要”的架构文档，实际上无视了“可扩展性和性能之间存在的冲突关系”。此时，最有效的方法就是在架构文档中明确说明“任何提升可扩展性的架构设计和具体设计，都应通过架构团队的评审才能引入，以确保性能目标不受重大影响”。5. 规律架构视图关注点：此架构设计视图的关注点是职责划分。留意：规律架构

7、视图无疑是最重要的，但同时也应避开“架构= 模块 + 接口”等以偏概全的生疏。参考：任何简洁系统的架构设计都不是一蹴而就的，所以架构师需要理性思维过程的指导。 针对规律架构设计这个关键环节，一线架构师实践指南一书给出了2 条建议：一是“以质疑驱动的螺旋思维”，二是相对分别地考虑“构造方面的切分”和“行为方面的定义”。以以下图所示即为推举的规律架构设计理性思维过程。5.1 职责划分与职责确定内容：将系统切分成更小的单元，并明确这些单元的职责。具体而言，职责单元可以是层、子系统、模块、关键类等。意义：一句话，职责划分不合理，功能和质量都会受到影响。也就是说，功能需求和质量需 求无一不和职责划分相关

8、：一方面，每个功能都是由一条职责协作链完成的；另一方面，职责划分方式也影响着质量，于是需要职责模型针对特定质量属性要求做出相应调整和优化。很多人认为架构设计就是职责划分的艺术，虽略显片面，但足以说明职责划分的重要性。参考：基于对业界大量案例的争论，梳理出了“模块划分的3 种必用手段”，如以以下图所示， 更多内容可参考一线架构师实践指南一书。5.2 接口设计与协作机制内容：本节描述接口的定义，以及协作的方式和标准。参考：推举使用序列图，建议少用、甚至杜绝使用协作图。以以下图为一个序列图的例如。5.3重要设计包内容：对重要子系统的设计进展“灰盒”级描述。意义：恰恰是由于有了各模块之间“将来合作的契

9、约”，分头开发各模块才有了根本保证。 参考：推举利用“包-接口”图，来识别接口。以以下图为一个“包-接口”图的例如。意义：“每个子系统在架构设计中都应保持黑盒子”的观点，过于抱负化了。对于业务层、通用协作机制而言，常常需要在架构设计期间就引入“灰盒”级描述。参考：类图和灰盒包图，在本节中较多消灭。以以下图为一灰盒包图例如。6. 开发架构视图关注点：此架构设计视图的关注点是程序单元组织。留意：此架构设计视图是必需的、不应“剪裁”掉的。但实际状况却是，很多架构师不关注 开发架构视图，导致很多程序开发人员埋怨“架构师就知道高来高去，架构对编程工作没什么指导性”。6.1 Project 划分内容：本节

10、说明整个系统将划分成哪几个Project 来开发，其中，Project 指开发环境所感知到的“工程”。意义：根本好处是，有利于开发的组织；而对一些大型的集成系统而言，由于同时涉及了 Web 应用、桌面应用、嵌入式应用等软件形态，所以此时Project 划分其实是不得不做的；最终，我们推举核心代码应主动地切分到单独的Project 以进展独立的软件配置治理SCM， 以降低核心代码外泄的风险。参考：Project 划分必定是属于“架构设计”的工作，严格来讲仅靠“需求分析”划分的业务域Business Area直接映射到Project 常常意味着工作内容的遗漏。其实，业界不少有见地的专家已经生疏到W

11、BS工作分解构造做得太早太草率危害很大，就与“Project 划分不到位”不无关系。6.2 Project 1内容：对Project 划分后的每个Project 进展名目构造、程序单元组织、框架与应用关系的说明。6.2.1 Project 名目构造指导内容：关于该Project 一级名目、二级名目等根本名目构造的商定。意义：为团队并行开发供给必要根底，让不同程序小组看到自己应当负责的程序名目。参考：不要把全部程序名目的商定都定义得太细，否则这份架构文档就要每天更了。6.2.2 程序单元组织内容：源码、程序库、框架、目标码等类型程序单元之间的编译依靠关系。意义：或许有人认为这没什么技术含量，但架

12、构设计原来就不是只关心技术含量最高问题的。君不见，很多软件工程师跳槽到的企业之后，竟然连一个能正常编译源码的开发环境都建不起来其实，他们“不知道Project 所依靠的Library 有哪些”是其中重要缘由这本应在架构文档中给出明确描述的。6.2.3 框架与应用之间的关系可选内容：框架Framework。意义：既然不适用Framework 的开发越来越少了，既然程序员犯的很多错误都和对Framework 理解不到位有关，架构师就有责任明确说明Framework 和待开发系统之间的关系。参考：以以下图描述了Struts 框架和待开发应用的关系。参考：以以下图描述了JGraph 框架和待开发应用的

13、关系。6.3 Project 2内容：对Project 划分后的每个Project 进展名目构造、程序单元组织、框架与应用关系的说明。6.4 Project n内容：对Project 划分后的每个Project 进展名目构造、程序单元组织、框架与应用关系的说明。7. 运行架构视图关注点：此架构设计视图的关注点是把握流组织。留意：进程和线程是广为人知的把握流实现技术，但在架构设计思维当中，对于系统软件和 嵌入式软件极为重要的中断效劳程序也是把握流，这样利于架构师统一利用不同把握流手段设计并行和并发。7.1 把握流组织内容：把握流有哪些，每条把握流各是何种形式例如进程、线程、中断效劳程序，哪些软件

14、单元是把握流的起点，整条把握流中分别调用了哪些软件单元。意义：这是对系统运行时构造的刻画，主要反映系统的动态构造。7.2 把握流的创立、销毁、通信内容：描述进程、线程和中断效劳程序的创立和销毁，以及多条把握流之间的通信关系的定义。意义：一旦引入了多条把握流，附加工作就产生了此时把握流的创立和销毁、以及把握流之间的通信关系往往是必需考虑的。7.3 加锁设计内容：系统中有多条把握流在同时运行的状况下，一个经典问题是多于一条把握流可能会同 时修改某些数据构造，而造成数据的不全都。为此，架构师需要关注加锁设计，合理引入临界区或同步机制。意义：加锁设计事关系统的正确性。值得留意的是，无视加锁设计造成的问

15、题往往以“不易重现的Bug”的形式消灭，困惑的程序员会对测试人员说，“你看你报的Bug 在我机器上根本就不存在呀”。参考：对通用组件、通用模块的设计而言，加锁设计应予以特地关注，思维要点是争论将来通用模块的各种可能使用场景。8. 物理架构视图关注点：此架构设计视图的关注点是物理节点Node分布，以及软件到硬件的具体映射关系。留意：物理节点即可以是PC 机或效劳器，也可以是单片机、单板机或专用机，从而物理架构视图既适用于描述企业信息系统，也适合于描述嵌入式软件系统。8.1 物理拓扑内容：一为硬件选型，二为硬件之间的拓扑连接关系。参考：以以下图是某嵌入式系统的物理拓扑图。意义：对于分布式系统的设计

16、，此节极为重要、而且是必需的。 参考：以以下图是某企业级系统的物理拓扑图。8.2 软件到硬件的映射内容：明确每个物理节点上有哪些一到多个软件的目标单元，并说明具体的“映射方式”是安装、是部署、还是烧写、抑或是下载。意义：假设把此节漏了，就无法说明本文档的主题软件系统和上述硬件、硬件拓扑的关系。参考：以以下图所示为设备调试系统中，软件到硬件的映射关系。8.3 优化部署内容：为达降低本钱、提高性能和牢靠性等等目标，应特别关注的部署考虑。意义：物理架构设计的优劣，造成的本钱差异和质量差异，可能是天壤之别。所以必需重视。参考：以以下图呈现的，是ADMEMS 方法重点推举的“物理架构设计思维要点”，更多

17、内容可参考一线架构师实践指南一书。9. 数据架构视图关注点：此架构设计视图的关注点是长期化。具体而言，场景化可以借助扁平文件、关系数据库、实时数据库、Flash 等方式中的一种或多种完成。留意：本视图单独归档时，请在此节注明其文档名称等信息。9.1 长期化机制的选择内容：如下长期化机制的一种或多种：扁平文件、关系数据库、实时数据库、Flash。意义：不要假设在你的系统中，长期化只需一种机制；随着如今的系统变得越来越简洁，我们常常需要综合利用不同长期化机制。9.2 长期化存储方案内容：长期化数据的格式定义。意义：统确定义表、文件格式、Flash 数据构造等内容。9.3 数据同步与复制策略内容：由

18、于数据分布所引起的，包含数据分布、同步、复制等内容的重要设计决策。 意义：在数据分布的状况下，此节为必需。参考：在实际中，数据分布的策略绝大多数状况下不会超越以以下图所示的6 种手段，更多内容可参考一线架构师实践指南一书。10. 关键质量属性的设计原理内容：因软件系统的不同，性能、安全性、可伸缩性、互操作性、可扩展性、可测试性、可 重用性、可维护性等质量属性，都可以是本系统的关键质量属性。本文档的前面局部已经涉及了关键质量属性的设计决策，而本节更集中、更全面地描述这些架构设计决策，并且阐述“为什么”这么设计。意义：只描述架构设计决策本身，不利于读者理解“为什么”这么设计。而且，描述设计原理有利于在整个软件企业层面促进团队的架构设计力气。参考：关于描述“为什么”这么设计，目标-场景-决策表是此方面的卓越工具。以以下图为例如， 更多内容可参考一线架构师实践指南一书。