1 架构描述框架
1.1 本框架的基础
Ø Philippe kruchten的“软件架构的4+1模型”——多重视图和场景视图的使用；
Ø Zachman Framework——实现层级；
Ø Rozanski和woods框架——交叉关注。
1.2 架构描述框架概要信息
|
|
基础视点 |
||||
| 需求视点 |
功能性视点 |
部署视点 |
验证视点
扫描二维码关注公众号，回复：
745134 查看本文章
|
||
| 交叉视点 |
应用视点 |
|
|
|
|
| 基础设施视点 |
|
|
|
|
|
| 系统管理视点 |
|
|
|
|
|
| 可用性视点 |
|
|
|
|
|
| 性能视点 |
|
|
|
|
|
| 安全性视点 |
|
|
|
|
1.3 软件架构文档大纲
前页（扉页、变更历史、目录、图形列表、参考书目）
软件架构文档的目标
架构概览
架构决策
需求视图
功能性视图
部署视图
验证视图
应用视图
基础结构视图
系统管理视图
可用性视图
性能视图
安全性视图
附录
2 定义需求
定义需求活动的概览：
2.1 收集利益相关者要求
主要参与角色：业务分析师、利益相关者。
次要参与角色：应用架构师、基础设施架构师。
必须的输入项：变更要求、愿景。
可选的输入项：业务流程模型、术语表。
输出：利益相关者的要求
架构师职责：
Ø 将包括技术角色在内的人员纳入利益相关者的范围，比如系统管理员。
Ø 确保获得尽可能多的技术需求，比如质量与约束。
Ø 从成本、市场时机等角度清晰阐述一个要求对于解决方案的潜在影响。
Ø 排定要求的优先级。
步骤：
步骤一，确定利益相关者。
检查列表：维护一个利益相关者的check list，以防止需求收集时遗漏利益相关者。
步骤二，收集利益相关者的要求。
可用方法包括：使用调查表、开讨论会、头脑风暴会议、访谈等。
要注意的是在迭代式需求定义阶段的“变更要求”。
推荐技术：维护一个要求即潜在需求的check list，可以作为调查问卷的基础。
架构需求检查列表模板：（FURPS分类）
<!--[if !supportLists]-->Ø <!--[endif]-->功能性需求例子
| 需求 |
描述 |
| 审计 |
提供审计系统的能力 |
| 本地化 |
提供本地化机制以允许系统配置为使用某一特定人类语言 |
| 在线帮助 |
提供在线帮助的能力 |
| 打印 |
提供打印的能力 |
| 报表 |
提供报表的能力 |
| 安全 |
提供阻止资源不遭受未授权访问的安全能力 |
| 系统管理 |
提供系统管理能力来控制系统的运转特性 |
<!--[if !supportLists]-->Ø <!--[endif]-->可用性需求的例子
| 需求 |
描述 |
| 可达性 |
系统通过特定的用户交互机制进行使用的难易程度 |
| 美观性 |
系统对用户的吸引程度 |
| 可学性 |
用户学习系统的难易程度 |
| 可操作性 |
用户操作系统的难易程度 |
<!--[if !supportLists]-->Ø <!--[endif]-->可靠性需求的例子
| 需求 |
描述 |
| 准确性 |
系统提供结果的精确程度 |
| 有效性 |
系统保持特定运行状态的难易程度 |
| 可恢复性 |
系统重新建立某一特定运行状态的难易程度 |
<!--[if !supportLists]-->Ø <!--[endif]-->性能需求的例子
| 需求 |
描述 |
| 资源消耗 |
系统对规定资源的消耗程度 |
| 速度 |
系统展现的特定处理时间（如启动、关闭和响应时间）的长短程度 |
| 生产能力 |
系统对指定生产能力的支持程度 |
<!--[if !supportLists]-->Ø <!--[endif]-->支持性需求的例子
| 需求 |
描述 |
| 适应性 |
系统对新环境的适应程度 |
| 兼容性 |
系统对先前的或将来的版本的兼容程度 |
| 可配置性 |
系统配置的难易程度 |
| 可扩展性 |
系统扩展的难易程度 |
| 可安装性 |
系统安装的难易程度 |
| 协同性 |
系统与其他系统交互的难易程度 |
| 可维护性 |
系统修改的难易程度 |
| 可替换性 |
系统用来替换相同环境中担任相同任务的其他系统的能力，包括替换系统先前的或将来的版本 |
| 可测量性 |
系统在数据容量和并行用户方面的可测量性 |
| 可测试性 |
系统验证的难易程度 |
<!--[if !supportLists]-->Ø <!--[endif]-->业务约束例子
| 需求 |
描述 |
| 顺从 |
坚持要求的标准和规则的能力 |
| 成本 |
解决方案和其部署的成本的约束 |
| 进度 |
对开发和部署解决方案的进度的约束 |
<!--[if !supportLists]-->Ø <!--[endif]-->架构约束
| 需求 |
描述 |
| 协作 |
对处理用户之间协作的机制的约束 |
| 通信 |
对处理进程间通信的机制的约束 |
| 错误管理 |
对管理系统内错误的机制的约束 |
| 事件管理 |
对处理系统内异步事件的机制的约束 |
| 集成 |
对允许系统和其他系统集成的机制的约束 |
| 持久 |
对允许系统数据写到磁盘上的机制的约束 |
| 调度 |
对提供调度能力的机制的约束 |
| 安全 |
对提供安全能力的机制的约束 |
| 系统管理 |
对提供系统管理能力的机制的约束 |
| 事务管理 |
对处理事务的机制的约束 |
| 工作流 |
对处理工作项移动（通常由一个组织）的机制的约束 |
<!--[if !supportLists]-->Ø <!--[endif]-->开发约束
| 需求 |
描述 |
| 实现语言 |
使用的编程语言的约束 |
| 接口格式 |
在当前系统和外部系统之间传输的数据格式的约束 |
| 遗留集成 |
使用现有组件的约束 |
| 网络基础设施 |
系统使用的网络基础设施的约束 |
| 平台支持 |
系统将支持的平台的约束 |
| 资源限制 |
受资源使用的任何限制所影响的约束，如内存和硬盘空间等。 |
| 标准顺应性 |
受系统必须遵守的任何标准所影响的约束 |
| 第三方组件 |
第三方组件的使用和成本的约束 |
<!--[if !supportLists]-->Ø <!--[endif]-->物理约束
| 需求 |
描述 |
| 功耗 |
对系统功耗的约束 |
| 形状 |
对最终承载系统的硬件的形状的约束 |
| 大小 |
对承载系统的硬件的大小的约束 |
| 重量 |
对承载系统的硬件的质量的约束 |
收集需求时应避免的缺陷：
<!--[if !supportLists]-->Ø <!--[endif]-->把要求当成需求，在相关方未确认和现有需求之间冲突未解决之前，要求不能成为需求。
<!--[if !supportLists]-->Ø <!--[endif]-->购物车式的思维方式，比如指出选择特定需求的后果，如成本、进度和质量，而不能让需求成为一张购物清单。
<!--[if !supportLists]-->Ø <!--[endif]-->调查问卷过于技术性，被调查者关心的是业务问题，而不是技术问题，技术性的调查问卷超出了利益相关者的关心范围。
<!--[if !supportLists]-->Ø <!--[endif]-->要求过于笼统，使要求尽量明确，否则系统可能设计过度。
<!--[if !supportLists]-->Ø <!--[endif]-->要求不可测量，所有要求尽量做到无歧义和可测量的，而不是含糊的依赖主观判断的。
<!--[if !supportLists]-->Ø <!--[endif]-->和不适当的人讨论，不同的利益相关者有自己不同的要求，需要向适当的人问适当的问题。
步骤三，排定利益相关者要求的优先级
每个利益相关者排定的优先级都有可能不同，架构师需要协调他们，最终排定优先级，并且在“和利益相关者复审需求”的步骤中复审优先级。
2.2 获取常用词汇
目的：确保利益相关者常用的业务和技术术语能被理解并编写成文档。
主要参与角色：业务分析师、利益相关者。
次要参与角色：应用架构师、基础设施架构师。
必须的输入项：利益相关者的要求、愿景。
可选的输入项：业务实体模型、业务流程模型、企业架构规范。
输出项：术语表
架构师职责：协助定义使用的任何技术术语。
步骤：
确认常用术语表
最佳实践：协调同义词和同音异义词
2.3 定义系统上下文
目标：确保理解所开发系统的边界以及确认与该系统交互的最终用户和外部系统。
主要参与角色：业务分析师
次要参与角色：首席架构师、利益相关者。
必须输入项：利益相关者要求、项目目标。
可选输入项：业务实体模型、业务流程模型、企业架构规范、现有IT环境。
输出项：系统上下文
架构师职责：
<!--[if !supportLists]-->Ø <!--[endif]-->确保考虑到和系统集成的所有外部系统
<!--[if !supportLists]-->Ø <!--[endif]-->确保恰当地定义所有参与者的地点
<!--[if !supportLists]-->Ø <!--[endif]-->确保考虑到系统和外部参与者之间的所有数据流
步骤：
步骤一，确认参与者
参与者可以是一个人，也可以是一个外部系统或一个外部设备。
检查列表：维护一个参与者列表
可以采用用例建模的方法，参与者即角色。
可以画出系统上下文关系图，有助于理解系统必须面对的外部环境。
步骤二，参与者的地点
参与者地点会影响系统架构。
步骤三，确认数据流
数据流说明表示例：
| 数据源 |
目的地 |
描述 |
相关数据项 |
| 顾客 |
系统 |
顾客要求查看所有可预订线路的信息 |
旅游线路 |
| 顾客 |
系统 |
顾客提供游客的信息和预订线路的信息 |
游客、游客的选项、预订详细信息 |
| 系统 |
顾客 |
系统提供可预订线路的详细信息 |
旅游线路 |
2.4 概述功能性需求
主要参与角色：业务分析师
次要参与角色：应用架构师、利益相关者。
必须的输入项：术语表、利益相关者要求、系统上下文、愿景。
可选的输入项：业务流程模型、企业架构规范。
输出项：功能性需求
架构师职责：
确保考虑到更具技术性的参与者（如系统管理员）的需求。
步骤：
步骤一，确认功能性需求
可以使用用例来描述需求
应避免的缺陷：
<!--[if !supportLists]-->Ø <!--[endif]-->需求是无法协商的，任何需求都有成本，而利益相关者并不一定理解这一点，这就是沟通的必要性。
概念：变更用例
在设计中实现变更用例，以便在变化发生很久之前就做好准备。
一个变更用例代表系统需求的一个潜在改变，它能让架构师洞察架构的容易改变或扩展的部分。
架构师是否应该处理一个变更用例是他需要做出的权衡之一。
步骤二，概述功能性需求
2.5 概述非功能性需求
主要的参与角色：业务分析师
次要的参与角色：应用架构师、基础设施架构师、利益相关者。
必须的输入项：术语表、利益相关者要求、系统上下文、愿景。
输出项：非功能性需求
架构师职责：
<!--[if !supportLists]-->Ø <!--[endif]-->确保考虑到适当的非功能性需求
<!--[if !supportLists]-->Ø <!--[endif]-->确保用适当的方式表达非功能性需求
步骤：
步骤一，确认非功能性需求
最佳实践：维护一个系统级的非功能性需求列表
概念：业务规则
业务规则是定义或约束业务某一方面的声明。起目的是维护业务结构或控制及影响业务行为。
步骤二，概述非功能性需求
最佳实践：如果有助于理解，声明什么不是必需的。
2.6 定义需求优先级
目的：指定需求的优先级以便可以根据最优的优先级需求安排迭代。
主要的参与角色：业务分析师、首席架构师。
次要的参与角色：项目经理、利益相关者。
必须的输入项：术语表、功能性需求、非功能性需求、RAID（风险、假设、问题、依赖条件）日志、利益相关者要求。
可选的输入项：愿景。
输出项：排定优先级的需求列表
架构师职责：协助定义需求的优先级
步骤：
定义需求优先级
理解需求并不是独立的这一事实，有助于帮助我们排定优先级，下面一个示例的表格是帮助我们排定优先级的一个方法。
| 需求 |
易用性 |
可靠性 |
通信 |
遗留系统 |
平台支持 |
可扩展性 |
安全 |
速度 |
遵循标准 |
| 管理注册用户 |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
|
Y |
| 登录 |
Y |
Y |
Y |
|
Y |
Y |
Y |
|
Y |
| 注册 |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
|
Y |
应避免的缺陷：所有需求的优先级都相同，如果优先级都相同，那么排定优先级的工作就是浪费时间。
2.7 细化功能性需求
目的：把功能性需求完善到可以驱动定义系统功能的程度。
主要的参与角色：业务分析师。
次要的参与角色：应用架构师、利益相关者。
必须的输入项：功能性需求、需求优先级列表、利益相关者要求、系统上线文。
可选的输入项：术语表
输出项：功能性需求
架构师职责：
<!--[if !supportLists]-->Ø <!--[endif]-->确保考虑到所有的流（数据流、事件流）。
<!--[if !supportLists]-->Ø <!--[endif]-->协助定义用例数据项。
<!--[if !supportLists]-->Ø <!--[endif]-->协助细化系统范围的功能性需求。
<!--[if !supportLists]-->Ø <!--[endif]-->协助细化特定场景。
步骤：
步骤一，细化用例（在当前迭代考虑的每一个用例）。
细化用例时需要说明的信息：
<!--[if !supportLists]-->Ø <!--[endif]-->名称：用例名称
<!--[if !supportLists]-->Ø <!--[endif]-->简要描述：用例的目标和动机
<!--[if !supportLists]-->Ø <!--[endif]-->主要参与者：用例发起者的名称
<!--[if !supportLists]-->Ø <!--[endif]-->次要参与者：用例其他相关的参与者名称
<!--[if !supportLists]-->Ø <!--[endif]-->主要事件流：执行用例时参与者和系统之间交互的主要途径的描述
<!--[if !supportLists]-->Ø <!--[endif]-->可选事件流：当执行用例时可选路径的描述
<!--[if !supportLists]-->Ø <!--[endif]-->特殊需求：不在用例事件流中进行考虑但需要在详细设计和构建时关注的需求的描述，一般来说这类需求代表和用例相关的非功能性需求。
<!--[if !supportLists]-->Ø <!--[endif]-->先决条件：执行这个用例系统所需要的系统状态
<!--[if !supportLists]-->Ø <!--[endif]-->后置条件：用例执行后，系统必须立即所处的可能状态的列表
步骤二，细化用例数据项。
细化“定义系统上下文”中确认的数据项
步骤三，细化系统范围的功能性需求。
步骤四，细化功能性需求场景。
定义几个具体的场景来示例和阐明某个特定的功能性需求也是有益的。这种方法也能够确保系统必须提供的某一特定价值得以清晰的展示，还能够为开发人员和测试人员提供有价值的信息。
2.8 细化非功能性需求
目的：把非功能性需求完善到可以驱动系统在展现质量和适应约束方面的定义的程度。
主要的参与角色：业务分析师。
次要的参与角色：应用架构师、基础设施架构师、利益相关者。
必须的输入项：非功能性需求、需求优先级列表、利益相关者要求。
可选的输入项：术语表
输出项：非功能性需求
架构师职责：
<!--[if !supportLists]-->Ø <!--[endif]-->确保以恰当的方式描述所有的非功能性需求。
<!--[if !supportLists]-->Ø <!--[endif]-->协助处理特定的场景。
步骤：
步骤一，细化非功能性需求（当前迭代考虑的各项非功能性需求）。
每个非功能性需求的定义必须都具备缩写SMART中的每个元素特点，即specific（明确的）、measurable（可测量的）、achievable（可完成的）、realistic（现实的）和time-based（基于时间）。
步骤二，细化非功能性需求场景
细化与非功能性需求相关的场景主要关注质量。每个场景由6个部分组成：
<!--[if !supportLists]-->Ø <!--[endif]-->触发：定义了必须由系统处理的情况。
<!--[if !supportLists]-->Ø <!--[endif]-->触发源：定义了导致出现这个场景的角色、系统或系统元素。
<!--[if !supportLists]-->Ø <!--[endif]-->触发对象：代表触发的目标，可能是整个系统或系统的一部分。
<!--[if !supportLists]-->Ø <!--[endif]-->环境：定义了触发发生时的情况。
<!--[if !supportLists]-->Ø <!--[endif]-->响应：代表系统在环境所描述的情况下系统对于触发所作出的响应。
<!--[if !supportLists]-->Ø <!--[endif]-->响应度量：定义如何处理结果。
2.9 更新软件架构文档
目的：把对于架构有重要意义的需求编写在软件架构文档中。
参与角色：首席架构师
输入项：业务流程模型、功能性需求、术语表、非功能性需求、RAID日志、利益相关者要求、系统上下文。
输出项：软件架构文档
步骤：
更新软件架构文档
需要明确的一点是：软件架构文档是用来沟通架构用的。
2.10 更新软件架构文档
目的：使利益相关者同意需求达到当前的详细程度已经能够满足他们的要求。
主要的参与角色：业务分析师、首席架构师、利益相关者。
次要的参与角色：应用架构师、数据架构师、基础设施架构师。
输入项：业务实体模型、业务流程模型、业务规则、企业架构规范、现有IT环境、功能需求、术语表、非功能性需求、排定优先级的需求列表、RAID日志、软件架构文档、利益相关者要求、系统上下文、项目愿景。
输出项：变更要求、RAID日志、复审记录。
架构师职责：
<!--[if !supportLists]-->Ø <!--[endif]-->参与复审
<!--[if !supportLists]-->Ø <!--[endif]-->回答任何技术问题
步骤：
步骤一，定义工作产品的基线。
定义基线是配置管理的一个方面，配置管理的方式是应该在项目的最初阶段就进行考虑并解决的关注点。
步骤二，汇集工作产品。
步骤三，复审工作产品。
3 创建逻辑架构
创建逻辑架构活动的概览：
3.1 架构方法参考
<!--[if !supportLists]-->Ø <!--[endif]-->卡内基梅隆软件工程研究所的属性驱动设计方法（ADD，Attribute-Driven Design），参考书目《Software Architecture in Practice，2nd ed》（Bass 2003）。
<!--[if !supportLists]-->Ø <!--[endif]-->西门子的四重视图（S 4V），参考书目《Applied Software Architecture》（Hofmeister 2000）。
<!--[if !supportLists]-->Ø <!--[endif]-->Rational的统一过程（RUP）,参考书目《The Rational Unified Process:An Introduction,2nd ed》（Kruchten 2000）。
3.2 调查架构资源
目的:确认可用于所开发系统的可重用资源。
主要参与角色：首席架构师
次要的参与角色：应用架构师、数据架构师、基础设施架构师。
输入项：架构概览、部署模型、现存IT环境、企业架构规范、功能模型。
输出项：架构决策
步骤：
调查架构资源
3.3 定义架构概览
目的：确认并描述所开发系统的主要元素。
主要参与者：首席机构师。
次要参与者：应用架构师、数据架构师、基础设施架构师。
输入项：功能性需求、企业架构概览、术语表、非功能性需求、系统上下文。
输出项：架构概览。
步骤：
定义架构概览
主要关注功能视图和开发视图，但是也可能需要关注其他视图。
企业架构规范应该在架构概览中得以体现。
通过复审系统上下文以理解系统的边界，复审功能性需求以理解系统的功能领域，复审非功能性需求以理解需要满足的质量和符合的约束，在这个过程中的术语应收录进术语表。
3.4 编写架构决策文档
目的：记录在架构形成的过程中所作出的关键决策和背后的原因。
主要参与角色：首席架构师。
次要的参与角色；应用架构师、数据架构师、基础设施架构师。
输入项：所有和架构相关的工作产品、RAID日志。
输出项：架构决策文档
步骤：
步骤一：记录难题和问题
难点和问题多数出自于RAID日志。
步骤二：评估选项
判断有哪些选项可以用来解决问题，可用的方法有参考同类问题解决方案、搜索供应商的产品和库、头脑风暴等。
步骤三：选择首选的选项
选择选项需要注意的问题有：
<!--[if !supportLists]-->Ø <!--[endif]-->是否有功能性需求、质量属性或约束是决定性的因素，直接决定一个选项比另一个好？
<!--[if !supportLists]-->Ø <!--[endif]-->是否有必须遵循的规范、政策和指导？
<!--[if !supportLists]-->Ø <!--[endif]-->风险是否是评估的属性之一？项目是否能承担这种风险？
<!--[if !supportLists]-->Ø <!--[endif]-->选项是策略性的还是战略性的？
<!--[if !supportLists]-->Ø <!--[endif]-->实际上是否要进行单选？也许需要一个短期选项和长期选项。
<!--[if !supportLists]-->Ø <!--[endif]-->是否存在决策依赖性，依赖其他决策或者依赖POC的运行结果？
步骤四：编写决策文档
3.5 概述功能性元素
目的：确认所开发系统的主要功能性元素（子系统和组件）。
主要参与角色：应用架构师。
次要参与角色：数据架构师、基础设施架构师。
输入项：架构决策、架构概览、架构的概念可行性、业务实体模型、业务规则、企业架构规范、现存IT环境、功能性需求、术语表、非功能性需求、需求优先级列表。
输出项：功能模型。
步骤：
步骤一：确认子系统
将架构概览中的非正式符号转化为UML就可以确认子系统。
如果架构概览不够详细，可以采用如下技术：
<!--[if !supportLists]-->Ø <!--[endif]-->复审功能性需求，寻找已经组合在一起或者可以组合在一起的需求。
<!--[if !supportLists]-->Ø <!--[endif]-->复审企业架构规范、非功能性需求和现有IT环境，看是否存在某些约束暗示着一些特定的技术，这些技术可以确认为子系统。
<!--[if !supportLists]-->Ø <!--[endif]-->复审业务实体模型，查找由一组相关组件进行管理的相关业务实体组。
步骤二：确认组件
推荐方法：Rebecca Wirfs-Brock设计的CRC（Classes-Responsibilities-Collaborations）技术。
考虑每个组件如下三个方面：
<!--[if !supportLists]-->Ø <!--[endif]-->组件知道什么（它拥有或管理的数据）
<!--[if !supportLists]-->Ø <!--[endif]-->组件做什么（它展示的行为）
<!--[if !supportLists]-->Ø <!--[endif]-->组件要求其他组件为它做什么（需要一起协作来执行某种功能的组件）
组件的确认需要分析业务实体模型、功能性需求、非功能性需求、业务规则、现有IT环境和架构决策。
分析功能性需求确认逻辑组件时，参考步骤：
<!--[if !supportLists]-->Ø <!--[endif]-->定义一个接口（边界）组件里接收来自用例主要参与者的请求并发送响应。
<!--[if !supportLists]-->Ø <!--[endif]-->在需要调用外部系统来获得或发送数据的地方，创建一个边界组件来处理系统和这个外部系统的接口。
<!--[if !supportLists]-->Ø <!--[endif]-->定义一个和用例同名的用于控制整个用例的控制组件。
<!--[if !supportLists]-->Ø <!--[endif]-->对于需求中需要参与者和系统交互的每一个步骤，把一个对应职责分配给控制组件来管理那个交互。
<!--[if !supportLists]-->Ø <!--[endif]-->一些步骤暗示了数据的应用，通常由用例中的名词表示。对于这些数据元素，创建一个负责管理相关数据的实体组件。
<!--[if !supportLists]-->Ø <!--[endif]-->在当前迭代中，对每个用例重复前面的步骤。
最佳实践：追溯方案元素直至需求（用例实现）
3.6 概述部署元素
目的：确认所开发的系统未来部署的地点和在这些地点内的节点。
主要参与角色：基础设施架构师。
次要的参与角色：应用架构师、数据架构师。
输入项：架构决策、架构概览、架构概念证明、企业架构规范、现有IT环境、功能模型、功能性需求、术语表、非功能性需求、系统上下文。
输出项：部署模型。
步骤：
步骤一：确认地点
步骤二：确认节点
3.7 检验架构
目的：检验所有架构产品是否一致，并确保跨越架构产品的所有问题都得到一致性的解决。
主要参与角色：首席架构师。
次要参与角色：应用架构师、数据架构师、基础设施架构师。
输入项：架构决策、架构概览、架构概念证明、部署模型、功能模型、功能性需求、非功能性需求、系统上下文。
输出项：复审记录。
架构师职责：
<!--[if !supportLists]-->Ø <!--[endif]-->领导对架构的检验以确保全部架构产品一致。
<!--[if !supportLists]-->Ø <!--[endif]-->确保跨越架构工作产品的问题（质量，如性能）得到一致的解决。
<!--[if !supportLists]-->Ø <!--[endif]-->确保解决检验中发现的缺陷且不破坏整体的架构。
<!--[if !supportLists]-->Ø <!--[endif]-->确保记录任何检验活动中得到的架构决策。
步骤：
这项任务可以是简单的非正式复审，也可以采用严格的技术。
步骤一：计划检验
步骤二：召开动员会议
步骤三：进行个别检验
步骤四：召开检验会议
步骤五：进行返工
步骤六：进行后续工作
3.8 构建架构的概念证明
目的：至少合成一个能满足严重影响架构的需求的解决方案来确定架构师设想的解决方案是否存在。
主要的参与角色：首席架构师。
次要的参与角色：应用架构师、数据架构师、基础设施架构师。
输入项：架构决策、架构概览、部署模型、功能模型、功能性需求、RAID日志、非功能性需求、排定优先级的需求列表。
输出项：架构概念证明。
架构师职责：
<!--[if !supportLists]-->Ø <!--[endif]-->发起概念证明并确立基本规则和概念证明的范围。
<!--[if !supportLists]-->Ø <!--[endif]-->和所有产品供应商紧密合作以对于概念证明需要他们提供什么产品给出明确的指导。
<!--[if !supportLists]-->Ø <!--[endif]-->比较和解释概念证明的结果并向利益相关者汇报。
<!--[if !supportLists]-->Ø <!--[endif]-->根据概念证明的结果，作出任何需要的架构决策。
步骤：
步骤一：创建架构的概念证明
创建架构的概念证明的可能原因：
<!--[if !supportLists]-->Ø <!--[endif]-->功能性需求新颖或具有挑战性。
<!--[if !supportLists]-->Ø <!--[endif]-->所开发系统具有特殊的质量要求。
<!--[if !supportLists]-->Ø <!--[endif]-->需要使用新的和没有经过验证的技术。
<!--[if !supportLists]-->Ø <!--[endif]-->将采用新的标准。
<!--[if !supportLists]-->Ø <!--[endif]-->和现有系统的接口很复杂或没有文档。
<!--[if !supportLists]-->Ø <!--[endif]-->将使用新的开发工具，需要证明项目能够随新工具继续进行。
步骤二：把发现的内容编写成文档
3.9 细化功能元素
目的：把功能性元素精炼到可以交付给详细设计的程度。
主要的参与角色：应用架构师。
次要的参与角色：数据架构师、基础设施架构师。
输入项：架构决策、业务实体模型、功能模型、术语表。
输出项：数据模型、功能模型。
步骤：
步骤一：定义组件接口
可以通过组件说明图来说明组件的接口
步骤二：定义操作和操作签名
可以通过逻辑数据模型和接口职责图来描述
步骤三：定义组件之间的契约
对于组件，契约以组件提供的接口中的每一个操作的先决条件和后置条件的形式出现。
3.10 细化部署元素
目的：精炼部署元素以达到可以交付给详细设计的程度。
主要参与角色：基础设施架构师。
次要参与角色：应用架构师、数据架构师。
输入项：架构决策、部署模型、功能模型、术语表、非功能性需求。
输出项：部署模型。
步骤：
步骤一：把组件分配给节点。
确定了逻辑部署元素后，需要通过把功能模型中的组件分配给部署模型中的节点来在功能模型和部署模型之间建立连接。
步骤二：定义节点之间的连接。
节点之间的通信只要表示为一个连接线就可以了，不需要考虑物理实现。
步骤三：定义地点之间的连接。
3.11 确认架构
目的：确认架构是否支持当前声明的需求。
主要的参与角色：首席架构师。
次要的参与角色：应用架构师、数据架构师、基础设施架构师、项目经理。
输入项：架构评估、变更要求、RAID日志。
输出项：架构评估
架构师职责：
<!--[if !supportLists]-->Ø <!--[endif]-->计划并领导架构确认。
<!--[if !supportLists]-->Ø <!--[endif]-->把发现的内容编写成文档。
<!--[if !supportLists]-->Ø <!--[endif]-->提示风险或问题和确认适当的缓解方案。
步骤：
步骤一：制定确认计划
步骤二：复审架构
步骤三：把发现的内容编写成文档
步骤四：评估风险并提出建议。
3.12 更新软件架构文档
目的：把对架构影响重大的元素记录在软件架构文档中。
参与角色：首席架构师。
输入项：架构评估、架构决策、架构概览、架构概念证明、数据模型、功能模型。
输出项：软件架构文档。
步骤：
更新软件架构文档
软件架构文档各个部分和工作产品的对应关系：
| 文档部分 |
工作产品 |
| 架构概览 |
架构概览 |
| 架构决策 |
架构决策 |
| 需求视图 |
定义需求阶段的产出 |
| 功能视图 |
架构决策、架构概览、数据模型、功能模型。 |
| 部署视图 |
架构决策、架构概览、部署模型。 |
| 验证视图 |
架构评估、架构概念证明、复审记录、RAID日志。 |
| 应用视图 |
可能包括所有工作产品。 |
| 基础结构视图 |
可能包括所有工作产品。 |
| 系统管理视图 |
可能包括所有工作产品。 |
| 可用性视图 |
可能包括所有工作产品。 |
| 性能视图 |
可能包括所有工作产品。 |
| 安全性视图 |
可能包括所有工作产品。 |
3.13 和利益相关者复审架构
目的：为逻辑架构工作产品定义基线并使利益相关者认同当前详细程度的架构能够解决定义的需求。
主要的参与角色：首席架构师、利益相关者。
次要的参与角色：应用架构师、数据架构师、基础设施架构师。
输入项：软件架构文档、其他需要的工作产品。
输出项：变更要求、RAID日志、复审记录。
架构师职责：
<!--[if !supportLists]-->Ø <!--[endif]-->确保为正确的工作产品定义基线。
<!--[if !supportLists]-->Ø <!--[endif]-->领导复审
<!--[if !supportLists]-->Ø <!--[endif]-->在复审过程中回答问题并提供澄清的注释。
步骤：
步骤一：定义工作产品的基线
选取代表当前架构的工作产品集，确保把他们加入配置管理系统并赋予正确的版本号。
步骤二：聚集工作产品。
除软件架构文档以外，其他工作产品都可以作为复审期间的参考。
步骤三：复审工作产品。
主要是对软件架构文档的走查
4 创建物理架构
要避免的错误：逻辑元素和物理元素混合在一个模型或视图中。
物理架构活动概览于逻辑架构活动完全一样，只是这些活动任务关注的开发系统的物理方面而不是逻辑方面。
检查列表：把逻辑组件映射到物理组件
当出现下列情况时，考虑在逻辑组件和物理组件之间一对一的映射：
<!--[if !supportLists]-->Ø <!--[endif]-->单个物理组件可以支持对应逻辑组件的全部职责，利用适当的实现技术而不破坏为组件分配职责时使用的耦合、内聚和粒度。
<!--[if !supportLists]-->Ø <!--[endif]-->单个组件可以支持任何非功能性需求而不需要其他一对多或多对一的映射。
当出现下列情况时，考虑在逻辑组件和物理组件之间一对多的映射：
<!--[if !supportLists]-->Ø <!--[endif]-->需要多个物理组件来实现这个逻辑组件。这些物理组件可能由好几个产品和定制构建的组件组成。
<!--[if !supportLists]-->Ø <!--[endif]-->需要多个物理组件来支持已经分配给这个逻辑组件的不同服务级别的特性。
<!--[if !supportLists]-->Ø <!--[endif]-->需要使用多个物理组件来实现一个已选择的、要求把分配给一个逻辑组件的职责在多个物理组件中实现的架构模式。
当出现下列情况时，考虑在逻辑组件和物理组件之间多对一的映射：
<!--[if !supportLists]-->Ø <!--[endif]-->单个物理组件封装了分配给多个逻辑组件的职责。
<!--[if !supportLists]-->Ø <!--[endif]-->单个物理组件支持多个逻辑组件需要的一个服务级别的特性。散布于多个逻辑组件的业务规则需要放置在同一个地方。
<!--[if !supportLists]-->Ø <!--[endif]-->实现多个逻辑组件的单个物理组件需要适应已选择的特定架构模式。
5 进阶
5.1 架构师和需求
<!--[if !supportLists]-->Ø <!--[endif]-->确保考虑技术型用户。
<!--[if !supportLists]-->Ø <!--[endif]-->确保考虑外部系统。
<!--[if !supportLists]-->Ø <!--[endif]-->确保突出非功能性需求。
<!--[if !supportLists]-->Ø <!--[endif]-->清楚表达一个需求对解决方案的影响。
<!--[if !supportLists]-->Ø <!--[endif]-->排定需求的优先级。
5.2 架构师和开发
<!--[if !supportLists]-->Ø <!--[endif]-->确定元素被设计和实现。
<!--[if !supportLists]-->Ø <!--[endif]-->确定重要的实现结构（如代码组织）。
<!--[if !supportLists]-->Ø <!--[endif]-->影响元素实现和集成的顺序。
<!--[if !supportLists]-->Ø <!--[endif]-->确保遵从架构决策和标准。
应避免的缺陷：避免技术细节
尽管架构师更关注架构的重要元素，但是有时候必须参与到详细设计和编码，在需要的时候，架构师必须深入到技术细节中。
5.3 架构师和测试
<!--[if !supportLists]-->Ø <!--[endif]-->确保架构是可测试的。
<!--[if !supportLists]-->Ø <!--[endif]-->确保架构经过测试（尤其是重要的元素，包括相关的质量和约束）。
5.4 架构师和项目管理
<!--[if !supportLists]-->Ø <!--[endif]-->为计划提供输入信息
<!--[if !supportLists]-->Ø <!--[endif]-->为工作分配提供输入信息
<!--[if !supportLists]-->Ø <!--[endif]-->为成本计算提供输入信息
<!--[if !supportLists]-->Ø <!--[endif]-->确定风险和降低风险的方案
<!--[if !supportLists]-->Ø <!--[endif]-->确定需要的技术及获取技术的时间
应避免的缺陷：架构师和项目经理是同一个人
5.5 架构师和配置管理
<!--[if !supportLists]-->Ø <!--[endif]-->影响任何配置管理仓库的结构
<!--[if !supportLists]-->Ø <!--[endif]-->构建元素来支持并行的工作
应避免的缺陷：配置管理忽略了架构
5.6 架构师和变更管理
确定进行变更在影响元素、成本、风险方面的影响。
5.7 架构师和开发环境
<!--[if !supportLists]-->Ø <!--[endif]-->定义架构标准和规范性指导
<!--[if !supportLists]-->Ø <!--[endif]-->确定工具来支持所有的架构标准
<!--[if !supportLists]-->Ø <!--[endif]-->考虑工具之间必须的集成
<!--[if !supportLists]-->Ø <!--[endif]-->确保拥有基础设施来实现和测试系统
5.8 架构师和业务分析
5.9 架构师和外界影响
这些影响是：
<!--[if !supportLists]-->Ø <!--[endif]-->企业架构
<!--[if !supportLists]-->Ø <!--[endif]-->设计权威
<!--[if !supportLists]-->Ø <!--[endif]-->基础设施提供者
<!--[if !supportLists]-->Ø <!--[endif]-->系统维护者
>5.10 复杂系统的架构设计
最佳实践：确保架构适当地模块化
<!--[if !supportLists]-->Ø <!--[endif]-->同时从逻辑层面和物理层面考虑架构。
<!--[if !supportLists]-->Ø <!--[endif]-->考虑分层的架构。
<!--[if !supportLists]-->Ø <!--[endif]-->考虑子系统。
<!--[if !supportLists]-->Ø <!--[endif]-->确认组件时，考虑耦合与内聚带来的启发。
最佳实践：设立并管理架构标准
最佳实践：确保质量驱动架构定义
最佳实践：正式地把架构描述为系统之系统