软件架构---架构设计过程

架构设计中各个步骤的位置

 

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

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

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

 

· 【一纵】需求沟通。持续伴随需求分析过程的，是需求沟通、需求启发、需求验证等活动，这些活动都要求需方和开发方紧密协同、精诚合作。“闭门造需”危险大了。
· 【二纵】非功能需求的确定。真实的实践中，确定非功能需求是一个持续的过程，是持久战。究其原因，这是非功能需求的范围广造成的，无论是技术还是业务、无论是甲方还是乙方，都可能有这样那样的非功能需求。想“一蹴而就”地定义非功能需求是不现实的。
· 【三横】需求分析主线。从确定系统目标开始，后续凭借“范围+Feature+上下文图”三剑客研究高层需求，再后续建立开发人员较熟悉的用例模型。
做不到“追根溯源”的需求分析，往往会失败。因此，我们补充图4-6来强调需求分析工作的主线是“确定系统目标→研究高层需求→建立用例模型”，需求从“高飘”到“落地”，成果项从“目标列表”到“范围框图 + Feature树 + 上下文图”到“用例图 + 用例规约”，需求跟踪脉络清晰可辨。

 

 需求分析的主线体现“追根溯源”

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

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

3.确定关键需求

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

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

 

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

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

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

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

下图列出了细化架构设计的5个设计视图、15个设计任务。

 

· 细化架构要为“需求”而设计。关键对比：概念架构设计的输入是“关键需求”、而不是泛泛的所有“需求”。
· 细化架构要在“概念架构”的设计思想下进行。
· “领域模型”，一方面影响着“逻辑架构视图”的“领域模型设计”，另一方面影响着“数据架构视图”的“存储格式设计”。

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

 

参考：温昱《软件架构设计》