软件架构设计（二） 导言

流程

　　描述关键流程的概览图：

　　架构设计活动位于开发和需求的中间。虽然需求这个阶段主要是业务分析人员的责任，但是架构师也会参与这个活动的一些详细任务。随后，架构师在创建逻辑架构中首先创建一个大概的逻辑架构，这个时候不考虑技术因素。这步是从需求到物理架构的一个跳板。物理架构是需要考虑技术因素的。逻辑架构会做为逻辑详细设计执行的任何详细设计的输入。

　　在需求、逻辑架构、逻辑详细设计的基础上，架构师对这种架构凝练并最终产生物理架构。物理架构作为物理详细设计执行的任何详细设计的输入。物理详细设计会成为实现的基础。详细设计和实现并不是架构师的职责。但需要架构师在需要的时候为这些团队提供指导。

　　架构设计可以看作是战略上的设计，而详细设计可以看作是战术上的设计。

　　下面详细的看一下其中的部分活动

　　定义需求活动中的任务：

　　这个任务从收集利益相关者的需求开始，它关注于了解各种各样利益相关者的需求。这些需求为架构师提供了需要设计系统的范围的一个初始的指示，在整理常用词汇完成后，架构师非常关注定义系统上下文。因为他定义了与系统交互的外部元素，如最终用户和外部系统。在这个上下文基础上，概要说明功能需求和非功能需求。架构师不仅对关键的功能性需求感兴趣，还应对系统质量（性能）、解决方案约束（非功能性需求）感兴趣，处理非功能性需求通常比处理功能性需求有挑战性。

　　在某种程度上，架构师参与整个定义需求以确保需求能够按照可能的技术、在制定的时间和预算内可以实现的方式来制定。就我们关心的需求任务而言，指定需求优先级与架构师关系特别大，架构师要保证优先级受那些能使架构尽可能快速稳定的需求和风险的影响。高优先级的需求会在细化功能性需求和细化非功能性需求中进行细化。接下来，架构师在更新软件架构文档中正式的编写架构上重要需求的概要文档。最终以和利益相关者复审需求结束。

　　创建逻辑架构活动中的任务：

　　基于最高优先级的需求，架构师在个定义架构概图中概要的说明候选的解决方案，架构概览定义了架构的整体轮廓。概要说明功能性元素和概要说明部署元素同时进行，接着根据组件，他们的关系和交互精炼这个轮廓。检验架构确保功能性元素和部署元素一致，尤其是确保跨这些元素的任何要点都被适当的处理。在构建架构证明中架构师关注证明架构的某些方面，概念证明提供了一个工具来减少某些与架构相关的风险。接下来，架构在系统功能性元素和细化部署元素中得到细化。确认架构确保架构像声明那样满足需求，还确保项目上的一些考虑，如资源，进度和预算约束。然后，架构师在更新软件架构文档这个任务中编写一个不依赖于平台的架构的概要。由此形成的架构描述用来和利息相关人员沟通架构，这些相关人员包括设计人员，程序员，分析人员，项目经理，维护人员和支持人员。最后，在和利益相关者复审架构中使大家对架构达成一致意见。

　　创建物理架构于创建逻辑架构任务完全一样，只不过创建物理架构需要考虑技术因素。

　　当然，这些顺序并不是一个必须遵守的顺序（仅仅是一个比较合适的顺序），在需要的时候可以重新回到这些任务。