3.2架构设计过程概述

正如在第 2 章中已经解释的那样，架构师在设计过程中至少在两个维度上活动（见图 3 - 1）：一方面是自上而下和自下而上地改变抽象级别，另一方面是在各个架构设计活动之间持续的迭代和增量的相互作用。 我们区分了以下四个抽象级别(参见第2章): • 需求和约束 • 软件架构的抽象级别: o 架构风格和技术基础设施 o 功能和技术架构级别 • 程序设计与实现

图3-1软件架构设计过程概览——迭代和增量，自顶向下和自底向上

图3-2四个抽象层次

这里需要注意的是，抽象级别的数量和结构可能不同。特别是其他方法，如模型驱动架构（MDA）包含更广泛区分的抽象级别（也见第 2 章和第 4.3 节）。然而，这里提出的抽象级别提供了一个一般的顶级结构，通常允许投射到这些类型的方法上。

如图 3 - 2 所示，在这些抽象级别之间的变化是基于自上而下和自下而上的方式进行的。在设计过程中，架构师从需求和约束抽象级别通过软件架构的抽象级别向下移动到最低抽象级别，即软件程序本身、程序设计和实现。

最高抽象级别（需求和约束）是架构设计的输入。在这个抽象级别可以找到功能和非功能需求或要遵循的架构标准。软件架构本身可以在下面的两个抽象级别上找到。

在架构风格和技术基础设施级别，定义了具有富互联网部署的三层架构。在应用架构和技术架构级别，进行特定功能和技术组件的设计及其交互。

最后的抽象级别（程序设计和实现）位于实现级别。因此，它代表了上面设计的软件架构的最终目标——换句话说，一个开发的软件系统。软件架构还定义了相应的架构要求和程序员要遵循的规则。

架构设计具有创造性和发明性，这意味着设计过程本身必须是迭代和增量的：迭代是为了纳入反馈和新信息，增量是为了持续推动开发前进。这就是为什么所涉及的各个活动不能有意义地按线性顺序排列。它们都是同等重要的领域，软件架构必须根据具体的项目情况投入足够的精力。图 3 - 3 中所示的设计过程的四个活动没有确定的顺序： • 需求和约束的分析 • 架构视图和技术概念的开发 • 架构和设计决策的评估 • 实施的支持和审查

图3-3设计过程中涉及的四项主要活动

在架构设计过程中，软件架构师几乎同时进行这四个活动，但按照适合项目背景和需求的顺序进行。然而，该顺序应遵循以下基本原则： 在第一个活动（需求和约束的分析）中，通常从更高的抽象级别分析可用的输入，目的是为要开发的设计创建核心决策标准，例如将系统分解为各个构建块的标准。 在接下来的活动（架构视图和技术概念的开发）中，进行实际的设计工作。设计过程本质上涉及决策。必须为解决方案确定构建块，然后为所涉及的抽象级别开发整体解决方案，并根据在初始分析期间建立的决策标准选择最佳可能的解决方案。 接下来，评估架构和设计决策。在这里，可以演练先前定义的需求场景以测试架构。 最后一个活动涵盖在下一个较低抽象级别对架构实现的支持和审查。当然，如果需要，架构师可以积极支持实现，并且也被允许进行编程。 因此，架构设计过程是抽象级别内连续的自上而下和自下而上的流动，与互动和增量执行的活动的持续变化相关。在设计过程中，架构师在两个维度（抽象级别和活动区域）中稳定且持续地移动。这些维度内的移动不是混乱、不稳定的步骤，而是架构师的深思熟虑的行动。

在这个过程中，软件架构、系统和整体组织不断相互影响和促进。迭代/增量和自上而下/自下而上的程序有助于应对与设计相关的不确定性，更容易在早期阶段检测到设计问题。因此，尽早考虑核心视图、抽象级别、功能和非功能需求是很重要的。

由于抽象级别的变化，架构师也会与不同的利益相关者接触。如果他在需求和约束区域，他将更多地与客户和需求工程师交流。在程序设计和实现级别，相应的对话伙伴是程序员和测试员。因此，架构师的任务之一是在设计过程中充分利用中央通信接口。

一位当前处于“架构风格和技术基础设施”抽象级别“开发架构视图和技术概念”活动区域的架构师可能会注意到，基于先前得出的决策标准，两种不同的部署架构在质量上是等效的。富互联网应用和胖客户端解决方案都能同样好地满足所有先前确定的决策标准。

然后架构师会切换级别。在“需求和约束”级别，他会与需求分析师交谈，向他解释这两个替代方案，并强调可能缺少需求，从而确定哪种解决方案更有利。需求分析师可以在架构师在场的情况下与利益相关者讨论。因此，可能会在此级别向需求目录添加额外的需求。

然后架构师会回到“架构风格和技术基础设施”抽象级别“需求和约束的分析”活动区域，并将由于额外需求而产生的方面补充到已经创建的标准目录中。然后，他会将扩展的标准目录带回“架构风格和技术基础设施”抽象级别“开发架构视图和技术概念”活动区域，现在他可以根据额外的决策标准选择更好的替代方案。

当然，这个过程并不像这里描述的那样机械地进行。但它仍然反映了架构设计过程中一个典型、现实的顺序。这个顺序伴随着电话、讨论和研讨会。即使对相关方来说并不总是透明的，架构师也必须始终清楚自己目前在两个维度上所处的级别。这是确保实现正确目标、适当的沟通级别和有效解决方案的唯一方法。

在设计过程的开始,首要任务是尽可能多的收集信息: • 开发项目所需的领域知识和技术背景知识 • 确定组织中现有的系统，并调查它们可被重用的程度 • 确定第三方提供的执行与要开发的系统（或系统的部分）类似任务的系统 • 阅读适当的技术文献，寻找所需的解决方案和程序模式 这些只是适当信息来源的几个例子。

基于这个初始分析，然后可以定义核心系统概念。核心任务是什么呢？为此，应当参照功能领域的最重要术语和方面，用几句话描述系统的主要任务和责任。在大多数情况下，这已经为架构提供了一个初始框架，因为此信息使我们能够将系统归类为三个主要系统类别之一：信息系统、移动系统或嵌入式系统（见图 2 - 3）。

根据系统类别，接下来的设计步骤和问题马上就清晰了。如果要设计的系统是一个信息系统，可能会使用分层架构。需要明确是想要一个交互式系统还是批处理系统。需要支持哪些业务流程？是否需要使用当前组织数据进行事务处理？需要什么样的可用性和性能？

然而，如果我们谈论的是一个嵌入式系统，要问的问题是：它应该在专用硬件上运行或控制专用硬件吗？对于时间关键操作，是否有定义的时间保证要求？是否需要基于结果的控制？是否需要并行控制？

这些和其他问题帮助架构师准备后续步骤。然而，他决不能忽视影响因素和约束，例如组织和政治方面、技术和操作条件/约束以及功能和非功能需求。

组织因素例如客户公司的结构、团队内部或决策机构的结构。它们也可能与可用资源有关，例如人员、预算或进度要求。组织标准如流程模型和工具也必须考虑在内。法律方面也需要在适当的地方进行检查和考虑。技术和操作因素，如现有的软件和硬件基础设施、编程语言和风格、参考架构、现有的数据结构、现有的库和现有的框架决不能被忽视。

架构师必须持续处理这些及其他影响因素和约束。在这方面，最高抽象级别（需求和约束）从以下四个领域提供了相应的参考点： • 项目环境和项目管理 • 产品管理和需求工程 • 实现环境和运营 • 工具环境和开发

这些接口领域是需求和约束的来源，同时也与架构相互作用。如果架构师能够令人信服地论证，来自这些接口领域的需求或约束的变更可以简化架构，决策者将认真考虑采取适当的行动。然后，自然必须考虑对其他架构、系统和组织的后果。这就是为架构设计创建功能和非功能需求的方式，由负责需求的组织的需求工程部提炼。架构设计反映了需求的可行性及其对需求工程的后果。如果我们发现对少量需求的更改会显著简化架构，架构师的任务就是与相关接口角色和决策者讨论这些选项。