软件架构设计系列包括软件生命周期、软件开发模型、软件开发方法、基于架构的软件开发、软件架构设计（软件架构设计原则、软件架构质量属性、软件架构风格、软件架构设计、软件架构文档化、软件架构评估）等。
软件架构文档化记录软件架构的活动就是架构编档过程，也就是架构的文档化。
它包含两个方面：一是过程，编档过程能促使架构设计师进一步思考，使得架构更加完善；二是结果，描述架构的文档将作为架构开发的成果，供项目干系人使用。
1、架构文档的使用者架构文档的使用者是项目干系人。
编写技术文档（尤其是软件架构文档）最基本的原则之一是要从读者的角度来编写，易于编写但很难阅读的文档是不受欢迎的。
架构的主要用途是充当项目干系人之间进行交流的工具，文档则促进了这种交流—— 项目干系人希望从架构文档中获得自己所关心的架构信息，如：系统实现人员希望文档提供关于开发活动的不能违反的限制及可利用的自由；测试人员和集成人员希望能从文档中得到必须组合在一起的各部分，并以此得到一个正确的测试黑箱；项目经理希望根据所确定的工作任务组建开发小组，规划和分配项目资源。
2、合理的编档规则编写架构文档和编写其他文档一样，必须遵守一些基本规则，这里将任何软件编档（包括软件架构编档）的规则归纳为 7 条：（1）从读者的角度编写文档。
（2）避免出现不必要的重复。
（3）避免歧义。
（4）使用标准结构。
（5）记录基本原理。
（6）使文档保持更新，但更新频率不要过高。
（7）针对目标的适宜性对文档进行评审。
3、视图编档视图是最重要的软件架构编档概念。
视图的概念为架构设计师提供了进行软件架构编档的基本原则。
架构文档化就是将相关视图编成文档，并补充多个视图的关联关系。
视图编档的组织结构（内容及编排次序、大纲）一般包含 7 个部分。
（1）视图概述：对系统进行概括性的描述，包含视图的主要元素和元素间的关系（但并不包含所有元素和元素间的关系，如：与错误处理相关的内容可以放在支持文档中）。
主要表示可用多个形式：图形、表格、文本，通常用图形形式，使用UML 语言来描述。
（2）元素目录：对主要表示中所描述的元素及其关系进行详细描述，包括：元素及其 属性、关系及其属性、元素接口、元素行为。
这部分是文档的主要组成部分，其中要注意：—对元素及其协同工作的行为进行编档，如用UML 的顺序图和状态图描述行为；—对接口进行编档，图9-19 说明了这部分的内容。
（3）上下文图：用图形展示系统如何与其环境相关。
（4）可变性指南：描述架构的可变化点，如在软件产品线中，产品线架构通过变化，适用于多个系统，因此，文档中应包含这些变化点，如各系统要做出选择的选项、做出选择的时间。
（5）架构背景：为架构的合理性提供足够的、令人信服的论据。
包括：基本原理、分析结果及设计中所反映的假定。
（6）术语表：对文档中每个术语进行简要说明。
（7）其他信息：描述不属于架构方面的必要信息，如管理信息（创作者、配置控制数据及变更历史）。
4、跨视图文档软件架构由多个视图文档来反映，按前面所述的要求完成每个视图的文档后，需要对这些文档进行一个整体的“打包”工作，这就是跨视图文档。
它包括如下内容：（1）文档有哪些内容，它们是如何组织的：视图目录（含哪些视图）；视图模板（即前面描述的视图文档，企业可以通过规范化来定义统一的、公共的视图模板）。
（2）架构概述：它描述系统的目的、视图之间的关联、元素表及索引、项目词汇。
（3）为什么架构是这样的（基本原理）：跨视图基本原理解释了整体架构实际上是其需求的一个解决方案。
即解释了做出决策的原因、方案的限制、改变决策时的影响及意义。
5、软件视图软件视图通常分为三种类型：（1）模块视图类型：为系统的主要模块实现单元编档。
（2）构件和连接件视图类型：为系统的构件和连接件执行单元编档。
（3）分配视图类型：为软件的开发和执行环境之间的关系编档。
每一视图类型中，又有一些常用的形态，可以把这些形态归纳成架构风格（简称风格），大量的架构风格供架构设计师选用，例如客户机/服务器是一种常见的架构风格，它是构件和连接件视图类型中的一员。
架构风格是对元素和关系类型的特化，它还包括如何使用这些元素和关系类型的一组限制条件。
架构结构/视图分类如下表所示。
6、软件架构重构前面已论述了架构编档，即在架构设计时完成编档工作。
但是还有另外一种情况：系统已经存在，但不知其架构，即架构没有通过文档很好地保留下来（文档的缺失/失效）。
如何维护这样的系统并管理其演变？其关键就是要找到软件架构，软件架构重构就是研究解决这一问题的方法，它是反向工程之一。
架构重构需要工具的支持，但任何一个工具或工具集对架构重构都是不够的。
因为：工具往往是面向特定语言的；数据提取工具经常返回不完整的或错误的结果，因此，应在多个工具提供的结果间进行补充、验证和判断；重构的目的（文档的用途）不同，决定了需要提取什么数据，这反过来影响了工具的选择。
以此为原则，就是架构重构的工作台方法，如 SEI 开发的 Dali。
软件架构重构由以下活动组成，这些活动以迭代方式进行，如下所示。
（1）信息提取（View Extraction）。
可以使用各种工具进行信息提取，如解析器、语法分析器等；可以利用 build 和 makefile 文件中关于模块的依赖关系；可以从源代码、编译时制品和设计制品中提取静态信息；可以使用分析工具提取动态信息。
（2）数据库构造（Database Construction）：将提取的信息转化为标准的形式，并置于数据库中。
（3）视图融合（View Fusion）：将数据库中的信息组合在一起，生成该架构的一个内聚的视图。
（4）重构（Reconstruction）：构建数据抽象和各种表示以生成架构表示，主要由两个活动组成：可视化和交互、模式定义和识别。
最后生成需要的架构文档（Documentation）。
上述过程中，架构是由重构人员通过对系统做出一组假定来获得，为了最有效地生成这些假定并对其进行验证，必须让熟悉系统的人参与此项工作，包括过去参与系统开发的人员或现在正在对其进行维护的人员。
评论：软件架构文档化是架构设计阶段的重要过程和成果。
编档过程能促使架构设计师进一步思考，使得架构更加完善；描述架构的文档将作为架构开发的成果，供项目干系人使用。
编档应遵循：从读者的角度编写文档；避免出现不必要的重复；避免歧义；使用标准结构；记录基本原理；使文档保持更新，但更新频率不要过高；针对目标的适宜性对文档进行评审。