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