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