【刘建】软件项目架构V1版

以下是对架构设计的每个步骤，进行总括的描述

1 需求分析
需求分析，是很多活动的统称，它是“架构设计过程”中第1个大的工作步骤。

需求分析活动输出的“需求”，必须涵盖功能、质量、约束这三个方面，这些是后续设计活动所需要的。需求分析工作涉及的“技能项”较多，总体而言可总结为“两纵三横”

2 领域建模
领域建模，是以提炼领域概念，建立领域模型为目的的活动。领域建模实践的精髓是“业务决定功能，功能决定模型”，理解了这个理念，评审领域模型也变得再自然不过了。
领域建模活动的输入：一是“功能”，二是“可扩展性”具体要求。

功能指目前所需要的，可扩展性指以后需要的说到底，都是“功能”，因为领域模型必须能支持在《软件需求规格说明书》中规定的“现在的功能”，还应该支持随着业务发展而出现的“未来的功能”。这两种功能，就是驱动领域建模的因素，以及评审领域模型的依据。

3.确定关键需求

架构面前所有需求一律平等？不可能。关键需求决定了架构的大方向。

具体而言，为了确定“关键功能”，一要关注“功能需求”，二要研究“约束需求”；为了确定“关键质量”，一要关注“质量需求”，二要研究“约束需求。

4.概念架构设计
概念架构是高层架构成果的核心，框定了架构大方向，是甲方规划、乙方投标的评定关键。

概念性架构界定系统的高层组件，以及它们之间的关系。概念性架构意在对系统进行适当分解，而不陷入细节。借此，可以与管理人员、市场人员、用户等非技术人员交流架构。概念性架构规定了每个组件的非正式规约及架构图，但不涉及接口细节。

概念架构设计要“直指”的、以之为输入的，是“关键需求”。
针对不同需求（功能或者质量），需要运用不同“技能项”，鲁棒图建模、目标-场景-决策表，非常实用。
概念架构设计的“输出”是“1个决定、4个选择”：
　　1）决定如何划分顶级子系统；
　　2）架构风格选型；
　　3）开发技术选型；
　　4）二次开发技术选型；
　　5）集成技术选型。

5 细化架构设计
细化架构和概念架构的关键区别之一是：概念架构没有设计到“模块 + 接口”一级，而细化架构必须关注“模块 + 接口”。

4.2.6 架构验证
如有必要，需要进行架构验证。
架构验证的输出成果是“架构原型”。和一般的开发不同，架构原型的开发不是要完美地、无Bug地实现功能，而是在“细化架构”的总体指导下，仅把存在“风险”的那些设计尽早开发出来，然后通过执行测试等手段判断“风险”是否解决，如下图所示。