《软件架构设计文档》模板
软件架构设计文档模板-参考模板
软件架构设计文档模板-参考模板项目名称软件架构设计文档版本修订历史记录目录1. 简介51.1 目的51.2 范围51.3 定义、首字母缩写词和缩略语51.4 参考资料51.5 概述52. 整体说明52.1 简介52.2 构架表示方式52.3 构架目标和约束53. 用例视图63.1 核心用例63.2 用例实现64. 逻辑视图64.1 逻辑视图64.2 分层64.2.1 应用层64.2.2 业务层64.2.3 中间层64.2.4 系统层74.3 架构模式74.4 设计机制74.5 公用元素及服务75. 进程视图76. 部署视图77. 实施视图77.1 概述77.2 层87.3 部署88. 数据视图89. 大小和性能810. 质量811. 其它说明812. 附录A 指南813. 附录B 规范814. 附录C 模版815. 附录D 示例9软件架构设计文档1.简介软件构架文档的简介应提供整个软件构架文档的概述。
它应包括此软件构架文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述1.1目的本文档将从构架方面对系统进行综合概述，其中会使用多种不同的构架视图来描述系统的各个方面。
它用于记录并表述已对系统的构架方面作出的重要决策本节确定此软件构架文档在整个项目文档中的作用或目的，并对此文档的结构进行简要说明。
应确定此文档的特定读者，并指出他们应该如何使用此文档1.2范围简要说明此软件构架文档适用的范围和影响的范围1.3定义、首字母缩写词和缩略语本小节应提供正确理解此软件构架文档所需的全部术语的定义、首字母缩写词和缩略语。
这些信息可以通过引用项目词汇表来提供1.4参考资料本小节应完整地列出此软件构架文档中其他部分所引用的所有文档。
每个文档应标有标题、报告号（如果适用）、日期和出版单位。
列出可从中获取这些参考资料的来源。
这些信息可以通过引用附录或其他文档来提供1.5概述本小节应说明此软件构架文档中其他部分所包含的内容，并解释此软件构架文档的组织方式2.整体说明2.1简介在此简单介绍软件架构的整体情况，包括用例视图、逻辑视图、进程视图、实施视图和部署视图的简单介绍。
《软件架构设计文档》模板
《软件架构设计文档》模板软件架构设计文档模板1. 引言1.1 背景在当今数字化时代，软件的需求日益增加，对高质量、可维护和可扩展的软件架构需求也越来越高。
软件架构设计文档是为了规划和指导软件开发团队在开发过程中的工作，保证软件系统的稳定性和可靠性。
1.2 目的本文档旨在定义软件架构设计的要素和所需的技术、工具以及规范，以确保软件开发项目的成功实施。
2. 系统架构2.1 设计原则2.1.1 模块化2.1.2 可重用性2.1.3 可扩展性2.1.4 松耦合2.1.5 高内聚2.2 架构风格2.2.1 分层架构2.2.2 客户端-服务器架构2.2.3 事件驱动架构2.3 架构图示在此处插入架构图示，包括主要组件和它们之间的关系。
3. 体系结构设计3.1 模块描述3.1.1 模块一描述模块一的功能和职责，包括输入、输出和内部数据流程等。
3.1.2 模块二描述模块二的功能和职责，包括输入、输出和内部数据流程等。
...3.2 接口设计3.2.1 内部接口描述模块之间的内部接口，包括输入输出参数、数据格式等。
3.2.2 外部接口描述软件系统与外部系统或第三方服务的接口，包括输入输出参数、协议规范等。
3.3 数据库设计描述软件系统的数据库设计，包括表结构、关系、数据类型等。
3.4 数据流程设计描述软件系统的数据流程设计，包括数据的输入、处理和输出流程。
3.5 安全性设计描述软件系统的安全性设计，包括用户验证、数据保护、权限控制等。
4. 技术选型4.1 编程语言选择根据项目需求和开发团队的技术实力，选择适合的编程语言或技术框架进行开发。
4.2 开发工具描述使用的开发工具，包括IDE、版本控制系统等。
4.3 第三方库和组件描述使用的第三方库和组件，包括功能描述、版本信息等。
5. 质量保障计划5.1 单元测试计划描述针对各个模块的单元测试计划和策略，确保软件的稳定性和可靠性。
5.2 集成测试计划描述软件集成测试的计划和策略，确保软件各个模块之间的协同工作。
软件架构设计文档模板
广州润衡软件连锁有限公司软件架构设计文档项目名称软件架构设计文档版本 <V1.0>修订历史记录目录1.简介51.1目的51.2范围51.3定义、首字母缩写词和缩略语51.4参考资料51.5概述52.整体说明52.1简介52.2构架表示方式52.3构架目标和约束53.用例视图63.1核心用例63.2用例实现64.逻辑视图64.1逻辑视图64.2分层64.2.1应用层64.2.2业务层74.2.3中间层74.2.4系统层74.3架构模式74.4设计机制74.5公用元素及服务75.进程视图76.部署视图77.实施视图87.1概述87.2层87.3部署88.数据视图89.大小和性能8软件架构设计文档10.质量811.其它说明812.附录A 指南813.附录B 规范914.附录C 模版915.附录D 示例9软件架构设计文档1.简介软件构架文档的简介应提供整个软件构架文档的概述。
它应包括此软件构架文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述1.1目的本文档将从构架方面对系统进行综合概述，其中会使用多种不同的构架视图来描述系统的各个方面。
它用于记录并表述已对系统的构架方面作出的重要决策本节确定此软件构架文档在整个项目文档中的作用或目的，并对此文档的结构进行简要说明。
应确定此文档的特定读者，并指出他们应该如何使用此文档1.2范围简要说明此软件构架文档适用的范围和影响的范围1.3定义、首字母缩写词和缩略语本小节应提供正确理解此软件构架文档所需的全部术语的定义、首字母缩写词和缩略语。
这些信息可以通过引用项目词汇表来提供1.4参考资料本小节应完整地列出此软件构架文档中其他部分所引用的所有文档。
每个文档应标有标题、报告号（如果适用）、日期和出版单位。
列出可从中获取这些参考资料的来源。
这些信息可以通过引用附录或其他文档来提供1.5概述本小节应说明此软件构架文档中其他部分所包含的内容，并解释此软件构架文档的组织方式2.整体说明2.1简介在此简单介绍软件架构的整体情况，包括用例视图、逻辑视图、进程视图、实施视图和部署视图的简单介绍。
软件设计文档模板(带实例)
软件设计文档模板(带实例)1. 引言此软件设计文档旨在提供软件开发过程中所需要的详细设计信息。
该文档包含了软件的总体架构，模块划分，接口设计等内容。
2. 背景在本项目中，我们将开发一个名为 "软件名称" 的软件。
该软件旨在解决某类问题，提供某类服务。
3. 功能需求以下是软件的主要功能需求：- 功能需求 1：描述功能需求 1 的具体内容- 功能需求 2：描述功能需求 2 的具体内容- ...4. 总体设计4.1 架构设计按照所需功能的划分，我们将采用层次化的架构设计。
主要包含如下几个层次：层次化的架构设计。
主要包含如下几个层次：层次化的架构设计。
主要包含如下几个层次：- 用户界面层：处理用户输入和输出- 业务逻辑层：实现软件的核心功能- 数据层：管理和处理数据4.2 模块划分根据软件的功能需求和架构设计，我们将软件划分为以下几个模块：- 模块 1：描述模块 1 的功能和作用- 模块 2：描述模块 2 的功能和作用- ...4.3 接口设计在此部分，我们将详细描述各个模块之间的接口设计。
包括输入参数、输出结果以及接口调用规范等。
5. 详细设计在本章节中，我们将详细描述每一个模块的实现细节。
包括算法设计、数据结构、关键代码等。
5.1 模块 1- 描述和目的：此部分描述模块 1 的详细设计，并阐述其设计目的。
- 算法设计：描述模块 1 中关键算法的实现细节。
- 数据结构：描述模块 1 中使用的数据结构，包括数据类型和存储方式等。
- ...5.2 模块 2- 描述和目的：此部分描述模块 2 的详细设计，并阐述其设计目的。
- 算法设计：描述模块 2 中关键算法的实现细节。
- 数据结构：描述模块 2 中使用的数据结构，包括数据类型和存储方式等。
- ...6. 测试计划在本章节中，我们将制定软件的测试计划。
包括功能测试、性能测试、兼容性测试等。
6.1 功能测试- 描述：本部分描述功能测试的具体内容和测试方法。
(完整word版)《软件架构设计文档》模板
目录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.1Project划分106.2Project 1 106.2.1Project目录结构指导116.2.2程序单元组织116.2.3框架与应用之间的关系（可选）116.3Project 2 (12)6.4Project n (12)7.运行架构视图127.1控制流组织127.2控制流的创建、销毁、通信137.3加锁设计138.物理架构视图138.1物理拓扑138.2软件到硬件的映射148.3优化部署159.数据架构视图159.1持久化机制的选择169.2持久化存储方案169.3数据同步与复制策略1610.关键质量属性的设计原理161. 文档简介[帮助读者对本文档建立基本印象，并为阅读后续内容扫清障碍。
]1.1 文档目的[文档目的，非项目目的。
否则造成同一项目多个文档之间的内容重复，不利于文档维护。
本小节应指明文档针对的读者对象，最好列出各种读者角色，并说明每种读者角色应该重点阅读的章节。
]1.2 文档范围[文档的Scope，非项目的Scope。
否则造成同一项目多个文档之间的内容重复，不利于文档维护。
]1.3 定义、缩写词和缩略语[集中列举文档中的定义、缩写词和缩略语。
]1.4 参考资料[本项目经审核的计划书、合同、上级批文；本项目的其他已发表文件；本文档引用的文件资料，如软件开发标准。
具体而言，应包括参考资料的题目（必须）、编号、版本号（必须）、发表日期、发布方，必要时还可以说明如何使用这些资料。
软件架构设计文档模板
项目名称软件架构设计文档版本 <V1.0>修订历史记录目录1.简介51.1目的51.2范围51.3定义、首字母缩写词和缩略语51.4参考资料51.5概述52.整体说明52.1简介52.2构架表示方式52.3构架目标和约束53.用例视图63.1核心用例63.2用例实现64.逻辑视图64.1逻辑视图64.2分层64.2.1应用层64.2.2业务层74.2.3中间层74.2.4系统层74.3架构模式74.4设计机制74.5公用元素及服务75.进程视图76.部署视图77.实施视图87.1概述87.2层87.3部署88.数据视图89.大小和性能810.质量811.其它说明812.附录A 指南813.附录B 规范914.附录C 模版915.附录D 示例9软件架构设计文档1.简介软件构架文档的简介应提供整个软件构架文档的概述。
它应包括此软件构架文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述1.1目的本文档将从构架方面对系统进行综合概述，其中会使用多种不同的构架视图来描述系统的各个方面。
它用于记录并表述已对系统的构架方面作出的重要决策本节确定此软件构架文档在整个项目文档中的作用或目的，并对此文档的结构进行简要说明。
应确定此文档的特定读者，并指出他们应该如何使用此文档1.2范围简要说明此软件构架文档适用的范围和影响的范围1.3定义、首字母缩写词和缩略语本小节应提供正确理解此软件构架文档所需的全部术语的定义、首字母缩写词和缩略语。
这些信息可以通过引用项目词汇表来提供1.4参考资料本小节应完整地列出此软件构架文档中其他部分所引用的所有文档。
每个文档应标有标题、报告号（如果适用）、日期和出版单位。
列出可从中获取这些参考资料的来源。
这些信息可以通过引用附录或其他文档来提供1.5概述本小节应说明此软件构架文档中其他部分所包含的内容，并解释此软件构架文档的组织方式2.整体说明2.1简介在此简单介绍软件架构的整体情况，包括用例视图、逻辑视图、进程视图、实施视图和部署视图的简单介绍。
ADMEMS方法推荐《软件架构设计文档》模板
ADMEMS方法推荐《软件架构设计文档》模板ADMEMS方法是一种常用的推荐系统算法，它能够根据用户的历史偏好和行为，为用户推荐合适的内容。
在软件架构设计中，使用ADMEMS方法可以帮助开发人员更好地设计和构建推荐系统。
本文将介绍《软件架构设计文档》的模板，并详细讨论如何使用ADMEMS方法进行推荐系统的设计。
一、引言在当前信息爆炸的时代，用户往往面临海量的信息和内容，因此推荐系统的作用变得尤为重要。
推荐系统能够根据用户的个性化需求和行为模式，为用户提供个性化的推荐内容，使用户更快地找到自己感兴趣的内容。
本文将基于ADMEMS方法，通过《软件架构设计文档》模板，介绍如何设计和构建一个高效的推荐系统。
二、概述《软件架构设计文档》是一个用于记录软件架构设计的模板，它包含了系统的整体结构、主要模块和组件、以及各个模块/组件之间的关系。
使用该模板可以使软件开发团队在设计时更加有条理和规范。
三、ADMEMS方法介绍ADMEMS方法是一种常用的推荐系统算法，它基于用户的历史偏好和行为，通过分析用户的行为模式，为用户推荐个性化的内容。
ADMEMS方法主要包括以下几个步骤：1. 数据收集：收集用户的历史行为数据，包括点击、购买、评分等。
2. 数据预处理：对收集到的数据进行清洗和处理，去除噪声，提取有效特征。
3. 特征工程：通过特征选择和特征转换等方法，提取用户的关键特征。
4. 模型选择：选择适合的推荐模型，如协同过滤、内容过滤等。
5. 模型训练：使用历史数据对选定的模型进行训练和优化。
6. 推荐生成：根据用户的个性化需求，使用训练好的模型生成推荐结果。
7. 推荐展示：将生成的推荐结果以合适的方式展示给用户。
四、《软件架构设计文档》模板《软件架构设计文档》模板通常包含以下几个部分：1. 引言：介绍本文档的目的、范围和背景。
2. 系统概述：概括地描述整个系统的功能和特点，以及与其他系统的关系。
3. 系统结构：详细描述系统的整体结构、主要模块和组件。
软件架构设计文档
软件架构设计文档软件架构设计文档一、引言本设计文档旨在详细阐述一款软件系统的架构设计，包括系统的整体结构、主要功能模块、接口定义、数据流向、安全性和可扩展性等方面的内容。
本设计文档将帮助开发人员更好地理解系统的结构与实现方式，为后续的开发工作提供指导和支持。
二、系统概述本系统是一款面向广大用户的在线购物平台，旨在为用户提供便捷、安全的购物体验。
系统主要包括用户注册、商品展示、购物车管理、订单处理、支付结算、物流配送等功能模块。
通过本系统，用户可以轻松地浏览各种商品，将商品添加到购物车并进行结算，同时可以选择不同的支付方式进行支付。
三、系统架构设计1.系统整体结构本系统的整体结构如下图所示：系统整体结构图（请在此处插入系统整体结构图）由上图可知，本系统主要包括以下几个层次：（1）表示层：负责与用户进行交互，展示数据和接收用户输入。
（2）业务逻辑层：处理系统的核心业务逻辑，包括用户注册、商品展示、购物车管理、订单处理、支付结算等功能。
（3）数据访问层：负责与数据库进行交互，包括数据的读取和写入。
（4）数据库层：存储系统的数据。
2.主要功能模块（1）用户注册模块：该模块负责用户的注册功能，用户可以通过填写个人信息并设置密码进行注册。
注册成功后，用户可以登录系统并使用各种功能。
（2）商品展示模块：该模块负责展示各种商品的信息，包括商品的名称、价格、描述、图片等。
用户可以通过搜索或浏览方式查找自己需要的商品。
（3）购物车管理模块：该模块允许用户将选中的商品添加到购物车中，并进行结算操作。
用户可以查看购物车中的商品列表，并选择删除或修改商品数量。
在结算时，用户需要填写收货地址和支付方式等信息。
（4）订单处理模块：该模块负责生成订单并处理订单状态。
当用户提交结算请求时，系统会生成一个订单号并记录订单信息，包括商品信息、收货地址、支付方式等。
同时，系统会根据订单状态进行相应的处理，如等待支付、已发货等。
（5）支付结算模块：该模块允许用户选择不同的支付方式进行支付。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
目录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.1Project划分106.2Project 1 106.2.1Project目录结构指导116.2.2程序单元组织116.2.3框架与应用之间的关系（可选）116.3Project 2 (12)6.4Project n (12)7.运行架构视图127.1控制流组织127.2控制流的创建、销毁、通信137.3加锁设计138.物理架构视图138.1物理拓扑138.2软件到硬件的映射148.3优化部署159.数据架构视图159.1持久化机制的选择169.2持久化存储方案169.3数据同步与复制策略1610.关键质量属性的设计原理161. 文档简介[帮助读者对本文档建立基本印象，并为阅读后续内容扫清障碍。
]1.1 文档目的[文档目的，非项目目的。
否则造成同一项目多个文档之间的内容重复，不利于文档维护。
本小节应指明文档针对的读者对象，最好列出各种读者角色，并说明每种读者角色应该重点阅读的章节。
]1.2 文档范围[文档的Scope，非项目的Scope。
否则造成同一项目多个文档之间的内容重复，不利于文档维护。
]1.3 定义、缩写词和缩略语[集中列举文档中的定义、缩写词和缩略语。
]1.4 参考资料[本项目经审核的计划书、合同、上级批文；本项目的其他已发表文件；本文档引用的文件资料，如软件开发标准。
具体而言，应包括参考资料的题目（必须）、编号、版本号（必须）、发表日期、发布方，必要时还可以说明如何使用这些资料。
]2. 架构描述方式[为了让读者更好地理解《架构文档》，在本节应当说明文档涉及的架构视图，并指明为了描述设计决策用到了哪些图表和模型。
]2.1 架构视图阅读指南[以多视图的方式来组织《架构文档》是大势所趋。
ADMEMS推荐的是经过优化的5视图方法，如下图所示。
]2.2 图表与模型阅读指南[对后续文档内容中所用到的建模语言（例如UML）、表格（例如目标-场景-决策表）等进行说明。
]3. 架构设计目标[功能、质量、约束，一个都不能少。
]3.1 关键功能[对架构设计至关重要的功能，包括如下4类：核心功能、必做功能、高风险功能、独特功能。
所谓独特功能，指这个功能覆盖了上述3类功能没有涉及到的职责。
]3.2 关键质量属性[人之所以痛苦，很多时候是因为追求错误的东西。
下图是ADMEMS方法确定关键质量的5大原则的整体思路图。
]3.3 业务需求和约束因素[ADMEMS方法创造性地提出约束需求的4大类型，这是一种极为实用的分类方式。
特别是业务需求对架构设计而言是一种约束的观点，解决了很多架构师的现实困惑。
下图标明了4类约束在“需求层次-需求方面矩阵（又称ADMEMS矩阵）”中的位置，可以帮助我们理解产生约束需求的根源。
]4. 架构设计原则[投标时经常讲“架构设计原则”，但到了《架构文档》，这些着眼大局的考虑却“丢了”。
ADMEMS方法推荐的本文档模板，认为应当把它们“找回来”。
]4.1 架构设计原则[着重描述重大的权衡取舍考虑。
]4.2 备选架构设计方案及被否原因[在概念架构一级，对备选架构设计方案进行描述，并阐述它们未被采用的原因。
这有利于团队了解当前架构设计方案的来龙去脉，提高团队对当前架构设计方案的认可度。
]4.3 架构设计对后续工作的限制（详设，部署等）[架构设计不仅应该包含“指导”，也应该包含重要的“限制”。
例如，一份只是说明“性能和可扩展性都重要”的《架构文档》，实际上忽视了“可扩展性和性能之间存在的矛盾关系”。
此时，最有效的办法就是在《架构文档》中明确说明“任何提升可扩展性的架构设计和详细设计，都应通过架构团队的评审才能引入，以确保性能目标不受重大影响”。
]5. 逻辑架构视图[关注点：此架构设计视图的关注点是职责划分。
][注意：逻辑架构视图无疑是最重要的，但同时也应避免“架构 = 模块 + 接口”等以偏概全的认识。
][参考：任何复杂系统的架构设计都不是一蹴而就的，所以架构师需要理性思维过程的指导。
针对逻辑架构设计这个关键环节，《一线架构师实践指南》一书给出了2条建议：一是“以质疑驱动的螺旋思维”，二是相对分离地考虑“结构方面的切分”和“行为方面的定义”。
下图所示即为ADMEMS方法推荐的逻辑架构设计理性思维过程。
]5.1 职责划分与职责确定[内容：将系统切分成更小的单元，并明确这些单元的职责。
具体而言，职责单元可以是层、子系统、模块、关键类等。
][意义：一句话，职责划分不合理，功能和质量都会受到影响。
也就是说，功能需求和质量需求无一不和职责划分相关：一方面，每个功能都是由一条职责协作链完成的；另一方面，职责划分方式也影响着质量，于是需要职责模型针对特定质量属性要求做出相应调整和优化。
很多人认为架构设计就是职责划分的艺术，虽略显片面，但足以表明职责划分的重要性。
][参考：基于对业界大量案例的研究，ADMEMS方法梳理出了“模块划分的3种必用手段”，如下图所示，更多内容可参考《一线架构师实践指南》一书。
]5.2 接口设计与协作机制[内容：本节描述接口的定义，以及协作的方式和规范。
][意义：恰恰是因为有了各模块之间“未来合作的契约”，分头开发各模块才有了基本保证。
] [参考：ADMEMS方法推荐利用“包-接口”图，来识别接口。
下图为一个“包-接口”图的示例。
][参考：ADMEMS方法推荐使用序列图，建议少用、甚至杜绝使用协作图。
下图为一个序列图的示例。
]5.3 重要设计包[内容：对重要子系统的设计进行“灰盒”级描述。
][意义：“每个子系统在架构设计中都应保持黑盒子”的观点，过于理想化了。
对于业务层、通用协作机制而言，经常需要在架构设计期间就引入“灰盒”级描述。
][参考：类图和灰盒包图，在本节中较多出现。
下图为一灰盒包图示例。
]6. 开发架构视图[关注点：此架构设计视图的关注点是程序单元组织。
][注意：此架构设计视图是必须的、不应“剪裁”掉的。
但实际情况却是，很多架构师不关注开发架构视图，导致很多程序开发人员抱怨“架构师就知道高来高去，架构对编程工作没什么指导性”。
]6.1 Project划分[内容：本节说明整个系统将划分成哪几个Project来开发，其中，Project指开发环境所感知到的“工程”。
][意义：基本好处是，有利于开发的组织；而对一些大型的集成系统而言，由于同时涉及了Web应用、桌面应用、嵌入式应用等软件形态，所以此时Project划分其实是不得不做的；最后，我们推荐核心代码应主动地切分到单独的Project以进行独立的软件配置管理（SCM），以降低核心代码外泄的风险。
][参考：Project划分必然是属于“架构设计”的工作，严格来讲仅靠“需求分析”划分的业务域（Business Area）直接映射到Project经常意味着工作内容的遗漏。
其实，业界不少有见地的专家已经认识到WBS（工作分解结构）做得太早太草率危害很大，就与“Project划分不到位”不无关系。
]6.2 Project 1[内容：对Project划分后的每个Project进行目录结构、程序单元组织、框架与应用关系的说明。
]6.2.1 Project目录结构指导[内容：关于该Project一级目录、二级目录等基本目录结构的约定。
][意义：为团队并行开发提供必要基础，让不同程序小组看到自己应该负责的程序目录。
][参考：不要把所有程序目录的约定都定义得太细，否则这份《架构文档》就要天天更新了。
]6.2.2 程序单元组织[内容：源码、程序库、框架、目标码等类型程序单元之间的编译依赖关系。
][意义：或许有人认为这没什么技术含量，但架构设计本来就不是只关心技术含量最高问题的。
君不见，很多软件工程师跳槽到新的企业之后，竟然连一个能正常编译源码的开发环境都建不起来——其实，他们“不知道Project所依赖的Library有哪些”是其中重要原因——这本应在《架构文档》中给出明确描述的。
]6.2.3 框架与应用之间的关系（可选）[内容：框架（Framework）。
][意义：既然不适用Framework的开发越来越少了，既然程序员犯的很多错误都和对Framework理解不到位有关，架构师就有责任明确说明Framework和待开发系统之间的关系。
][参考：下图描述了JGraph框架和待开发应用的关系。
][参考：下图描述了Struts框架和待开发应用的关系。
]6.3 Project 2……[内容：对Project划分后的每个Project进行目录结构、程序单元组织、框架与应用关系的说明。
]6.4 Project n……[内容：对Project划分后的每个Project进行目录结构、程序单元组织、框架与应用关系的说明。
]7. 运行架构视图[关注点：此架构设计视图的关注点是控制流组织。
][注意：进程和线程是广为人知的控制流实现技术，但在架构设计思维当中，对于系统软件和嵌入式软件极为重要的中断服务程序也是控制流，这样利于架构师统一利用不同控制流手段设计并行和并发。
]7.1 控制流组织[内容：控制流有哪些，每条控制流各是何种形式（例如进程、线程、中断服务程序），哪些软件单元是控制流的起点，整条控制流中分别调用了哪些软件单元。
][意义：这是对系统运行时结构的刻画，主要反映系统的动态结构。
]7.2 控制流的创建、销毁、通信[内容：描述进程、线程和中断服务程序的创建和销毁，以及多条控制流之间的通信关系的定义。
][意义：一旦引入了多条控制流，附加工作就产生了——此时控制流的创建和销毁、以及控制流之间的通信关系往往是必须考虑的。
]7.3 加锁设计[内容：系统中有多条控制流在同时运行的情况下，一个经典问题是多于一条控制流可能会同时修改某些数据结构，而造成数据的不一致。
为此，架构师需要关注加锁设计，合理引入临界区或同步机制。
][意义：加锁设计事关系统的正确性。
值得注意的是，忽略加锁设计造成的问题往往以“不易重现的Bug”的形式出现，困惑的程序员会对测试人员说，“你看你报的Bug在我机器上根本就不存在呀”。
][参考：对通用组件、通用模块的设计而言，加锁设计应予以专门关注，思维要点是研究未来通用模块的各种可能使用场景。
]8. 物理架构视图[关注点：此架构设计视图的关注点是物理节点（Node）分布，以及软件到硬件的具体映射关系。