架构师之道：你的需求是什么，你要实现什么

超、凢脫俗 2024-05-24 05:28 62阅读 0赞

在开展系统架构设计之前，关键是要确保业务需求明确无异议，各部门针对需求达成一致。这就意味着，在系统需求分析阶段，必须明确界定系统的功能和业务范畴，同时充分理解系统运营的各项需求。如果这些基本需求还没有确定下来，便着手进行架构设计是不合时宜的。在这种情况下，我们需要退回到需求分析阶段，彻底完善这些需求，然后才能适时开展架构设计工作。

系统架构设计的核心在于模型图的构建。这些模型图不仅有助于我们理解整个系统，也是与各方沟通的重要工具。为了确保不同的干系人都能理解这些架构，必须提供适合他们背景和理解能力的模型图。干系人群体包括项目经理、产品经理、开发人员、系统运维人员、客户以及投资者等，他们各自拥有独特的知识背景和对架构模型的理解能力。比如，产品经理或客户可能难以理解专为开发人员设计的开发架构模型图；反之，如果仅向开发人员展示逻辑架构图，则可能无法为他们正确构建开发环境提供足够的信息。

### 1、逻辑架构：系统的逻辑组成 ###

逻辑架构在软件系统设计中扮演着至关重要的角色，它主要关注于满足软件系统的功能需求和揭示系统内部的逻辑联系。通过逻辑分解，逻辑架构将复杂的系统细化为多个逻辑单元，并且明确这些单元之间如何相互作用和通信。逻辑架构的核心目的是确保软件系统能够有效地实现其功能需求，并为开发人员提供一个宏观的视角来理解和设计整个软件系统。

在设计逻辑架构时，常采用模块化的方法，将系统拆分为具有特定功能和接口的多个模块。这种分解方式有助于降低系统整体的复杂性，从而提升系统的开发效率和易维护性。此外，逻辑架构设计中还会详细定义模块之间的通信机制，包括数据交换的格式和所使用的通信协议，这对于保障系统各部分能够高效、准确地协同工作至关重要。

从上面可以看出，“逻辑架构”这个概念，实质上是对“系统架构的逻辑视图”的简洁表述，它为我们提供了一个明晰的框架，以便更好地理解和规划软件系统的逻辑层面。这种方法论不仅有助于把握系统设计的整体脉络，也促进了软件开发过程中的效率和准确性。

#### 1.1、逻辑架构视图 ####

从宏观的视角来看，逻辑架构模型的开发可以视为“开发候选架构模型和视图”活动中的一个关键任务，或者被看作是系统架构定义过程的一个子流程。这个过程的主要目的是为了深入描述和规划未来系统在实际运行中应有的功能表现和行为模式。逻辑架构模型融合了一系列技术概念和原则，这些都是系统逻辑操作的支撑。它不仅可能包括功能架构视图、行为架构视图和时序架构视图，还可能根据具体的应用领域，结合架构框架的建议，引入更多的视图来丰富架构的维度。

##### 1.1.1、功能架构视图 #####

功能架构模型构建了一套精细的框架，旨在定义系统为完成其既定使命而执行的一系列功能及其子功能。这个模型深入阐释了系统如何处理和转换输入数据、物质和能量以产生预期的输出。

**功能及输入输出流** \- 在系统架构的范畴中，功能及其输入输出流构成了架构的基础实体。功能是一个核心的转换过程，负责将输入数据、物质和能量转化为输出。这些输入和输出在功能间形成了交换流，是系统内部各个部分相互作用和沟通的桥梁。功能通常用数学表达式 ***y***=ƒ(=ƒ(***x*** *, t)* 来定义，其中 **y** 和 **x** 是可以在图形上展示的向量，�t代表时间变量。

要全面界定系统的功能集合，就必须细致识别系统及其衍生需求所必须的所有功能，并明确这些功能的输入与输出。从广义上讲，这些功能主要分为两大类：

1.  直接从系统的功能性和接口需求中推导出的功能，这些功能反映了系统为满足其整体需求而必须提供的基本服务。
2.  源自物理架构模型备选方案的功能，这类功能依赖于设计的最终结果，并受到实现逻辑架构模型元素时技术选择的影响。

**功能层次与功能分解** \- 在功能层次结构的静态视图(如图3-1所示)，系统可以被抽象为一个集中的、唯一的功能（如图3-1 中A-0的“F0”，代表系统的总体使命），这在很多方面相当于一个“黑盒子”。为了深入理解系统的具体作用，这个“层次结构之首”（F0）被细化为多个子功能（例如F1, F2, F3, F4），这些子功能组成了层次结构的下一层（如图3-1 中A0），以此类推。功能层次结构的最底层被称为叶功能（在图3-1 中A2中为F21, F22, F23, F24）。通过这种层次分解，复杂或整体的功能被拆解为一组具有已知、可实施或可构想的物理解决方案的功能集合。

这种对功能层次的观点提供了一个功能的静态视图，根据所使用的综合方法，这个视图会在不同的迭代级别上进行展开和充实。这种层次结构通常不是由单一的自顶向下的分解过程形成的。静态的功能层次结构本身并不足以完全展示输入和输出流的有效交换方式，因此，为了全面理解系统的运作，它需要与其他模型相结合进行综合考察。

![图3-1][3-1]

##### 1.1.2、行为架构视图 #####

行为架构模型以结构化的方式定义了函数及其子函数与接口（输入与输出），描绘了执行顺序、控制或数据流的条件，以及为满足系统需求所需的性能水平（ISO/IEC 26702:2007）。该模型本质上是一系列功能场景和操作模式的集合，这些场景和模式相互关联，共同描述了系统的动态行为。

**控制（触发）** \- 控制流是一种关键元素，它根据特定条件激活或停用函数。这种条件可以是元素的状态变化，或是某个特定事件的发生，例如开关被置于“开”位置、报警器响起、温度的变化，或是键盘上按键的敲击。

**功能场景** \- 功能场景由一系列按特定顺序执行的函数构成，这些函数通过控制流的同步合作，将输入转换为输出，完成系统的整体功能变换。这种场景体现了上层功能的动态流程。在构建行为架构时，必须针对每个功能层级和系统层级制定相应的场景。展示功能场景和行为架构模型时，建议使用功能流程图（FFBD）（Oliver, Kelliher, and Keegan 1997）或SysML（OMG 2010）开发的活动图(如图3-2,3-3所示)等建模技术。

![图3-2][3-2]

![图3-3][3-3]

**操作模式** \- 通过从每个功能的输入到输出的转换中抽象出来，可以着重考察功能及其控制元素的活跃或非活跃状态。这种视角被称为“模式场景”，它是按顺序进行的一系列模式转换，描述了系统各个模式之间的过渡。模式的转变通常由控制流的触发（如事件或触发器）引起。在两种模式之间转换时，可能会因为事件或触发器的出现而产生特定的动作（功能）(如图3-4所示)。

![图3-4][3-4]

**行为模式** \- 在定义功能场景或行为架构模型时，架构师可以利用已知的模型来表示系统预期的转换和行为方式。这些模式是广泛应用的基本模型，其复杂度根据处理的需求而变化（Gamma, Helm, Johnson, and Vlissides 1995）。模式的表示可以采用多种符号形式。行为模式分为多个类别，包括：

*  基本模式或构造，用于链接功能，例如顺序、迭代、选择、并发、多重出口、带退出的循环和复制。
 *  复杂模式，例如监控处理、消息交换、人机界面、模式监控、实时过程监控、队列管理和连续监控及管理。
 *  失败检测、识别和恢复（FDIR）模式，如被动冗余、主动冗余、半主动冗余和性能降级处理。

##### 1.1.3、时序架构视图 #####

时序架构视图深入分析了系统功能的执行频率，以及这些频率如何根据时间的流逝和功能启动及执行的方式而变化。在中文语境中，我们可以将其详细描述如下：

时序架构视图通过细致地划分系统功能，根据它们的执行频率进行分类，从而揭示了系统内部同步和异步方面的具体定义。这种分类不仅关注功能本身，还关注这些功能如何响应系统内部的决策监控流程，因为决策的形成紧密相关于对功能的监控。

**时序与决策层次概念**： 在这个视图中，系统功能的执行并非一成不变，而是随时间变化以及功能被触发和执行的具体方式而变化。因此，必须认识到，系统内部存在多个性能分类，这些分类按功能的执行频率进行划分。同步功能按照固定周期执行，而异步功能则依赖于特定事件或触发条件的发生来启动。

详细来说，实时系统和指挥控制系统融合了周期性（同步）操作和基于事件的（异步）操作。周期性操作是按照预定频率共享功能执行的过程，这个频率可能由输入/输出处理的需求或控制流的分派约束所决定。而异步事件则可以分为两大类：

*  **高频干扰**(图3-5顶部)：在系统的低层或发生干扰的同一层面对这些干扰做出反应。目标是隔离这些干扰，防止它们影响系统的核心频率层次，从而保证系统能够持续完成其核心使命。例如，针对操作中断、系统故障或功能失效的情况，需要引入特殊的异常处理流程。
 *  **低频变化**(图3-5底部)：涉及在系统的高层级做出的变更决策，并将这些决策逐级下传至底层，以便实施必要的修改。这类变化通常关联于人为操作、维护调整等行为。

在充分理解时序架构视图的基础上，我们能够洞察系统功能如何根据时间敏感度和紧急性进行调整和组织，以确保系统能有效应对内外部环境的变化，实现稳定运行和高效响应。这种视图不仅强调了时间因素在系统功能执行中的重要性，也体现了对功能层次和决策流程深入理解的需求。

![图 3-5][3-5]

#### 1.2、过程方法 ####

逻辑架构模型开发的核心目的是为了明确定义、精心挑选，并综合系统的逻辑架构模型。这一过程的重点在于建立一个坚实的框架，确保未来系统在各种操作环境中都能有效地满足预定的系统需求。此外，该框架还为在系统开发过程中对不同需求进行权衡提供了依据，以寻求最优解决方案

##### 1.2.1、目标 #####

在这一过程中，基本输入要素包括系统需求、架构师识别并用以应对需求的通用架构模式、系统分析过程的输出结果，以及来自系统验证和确认流程的反馈信息。选择的生命周期模型将决定这些输入和输出元素以及它们之间关系的演进方式。这种演进是通过多次迭代实现的，确保整个过程的动态适应性和持续优化（参见“应用生命周期过程”）。

从这一过程产生的基本输出可能是单一的逻辑架构模型，或者是一组候选的逻辑架构模型。每个模型都伴随着对选定的独立逻辑架构模型的详细解释和选择理由。输出内容通常至少包括多个视角的视图和模型，例如功能视图、行为视图和时间视图，这些视图之间通过逻辑架构模型元素与系统需求的追踪矩阵来实现互联互通。通过这种方式，确保了逻辑架构的选择过程不仅系统性和全面，而且具有可追溯性和逻辑性。

##### 1.2.2、过程活动 #####

在进行系统设计时，“过程活动”环节扮演着至关重要的角色，其主要活动和任务包括以下几个关键方面：

*  **功能和行为要素的识别与分析**：
    
     *  从系统需求出发，通过对功能、接口和操作需求的深入分析，识别系统的关键功能、数据流向、操作模式及其转变，以及可能遇到的各种操作场景。
     *  明确每个功能所需的输入和控制因素（包括能量、材料和数据流），并确定产生这些输入输出流所必需的功能。这一过程不仅要求理解功能之间的相互作用，还需要对如何转换、移动和生成这些流进行详细规划。
 *  **将系统需求分配给功能和行为要素**：
    
     *  对功能表达式及其属性进行正式定义，包括它们的性能、效率和约束条件。这需要特别注意需求中的时间因素，如为各功能分配具体的持续时间、响应时间和频率。
     *  同样地，输入、输出和控制流的表达式及其属性也需要被正式定义，这包括对接口、效率、操作性、时间性和约束条件的分配。
     *  建立系统需求与这些功能和行为要素之间的追溯性，确保系统设计的每一步都能与原始需求相对应和支撑。
 *  **定义候选的逻辑架构模型**：
    
     *  针对每个候选方案，分析系统需求中提及的操作模式。如果有的话，或者使用先前定义的元素来模拟操作模式的序列及其转换过程。这包括将复杂的模式逐步分解成更细小、可管理的子模式，并为每种操作模式构建一套或多套功能场景，这些场景将识别和/或采用通用的行为模式。
     *  将这些功能场景整合起来，构建出系统的行为架构模型，即一个展现系统动态行为全貌的模型。
     *  根据实现的需求，适当地分解先前定义的逻辑元素，以细化逻辑结构并准备实施。
     *  为先前定义的逻辑元素分配和整合时间约束，包括时间周期、持续时间、频率、响应时间、超时、停止条件等，以确保时间因素得到充分考虑。
     *  为不同的功能定义多个执行频率级别，这些级别对应不同的决策层次，以监控系统操作，按时间优先处理，并在各个执行频率级别之间分配功能，形成一个时间架构模型。
     *  进行功能失效模式及效果分析，根据分析结果适时更新逻辑架构元素。
     *  尽可能地使用模拟器执行模型，并调整这些模型以达到预期的特征和性能。
 *  **综合选定的独立逻辑架构模型**：
    
     *  通过评估不同的候选逻辑架构模型，并将它们与系统需求相关的评估标准进行对比，选择合适的逻辑架构。使用系统分析和决策管理流程来评估和选择，进而得到称为\_独立逻辑架构模型\_的结果，该模型尽可能独立于具体的实施决策。
     *  识别并定义由设计需求驱动产生的派生逻辑架构模型元素，并确保它们与派生的系统需求相匹配。将这些需求分配给当前研究的系统或外部系统。
     *  验证和确认选定的逻辑架构模型，尽可能使用可执行模型，并根据需要进行调整，同时在系统需求和逻辑架构模型元素之间建立追溯性。
 *  **反馈逻辑架构模型开发和系统需求**：
    
     *  在物理架构模型开发之后进行这一活动。如果可能，对系统和系统元素建立\_分配的逻辑架构\_，并根据需要添加功能、行为和时间元素，以同步各项功能和处理流程。
     *  定义或巩固由所选的逻辑和物理架构模型诱发的派生逻辑和物理元素。明确相应的派生需求，并将它们分配给合适的逻辑和物理架构元素。然后，将这些派生需求整合入受影响系统的需求基线中，确保逻辑与物理架构的一致性和完整性。

这样的过程不仅加深了对每个构建块的理解，也确保了逻辑架构模型能够全面反映系统的动态行为和操作需求。通过这种方法，我们能够细致地分析和调整系统的各个方面，从而确保最终的架构设计既符合系统需求，又能适应实际的执行环境。

##### 1.2.3、产物、方法和建模技术 #####

在逻辑架构的领域内，建模技术、方法和工件（或产物）的综合应用是至关重要的。下面详细描述了各种模型类型，以及支持这些模型的方法，特别是一些可执行模型的应用：

*  **功能模型**：功能模型是逻辑架构中的基础，旨在明确系统的功能和操作。例如，结构化分析设计技术（SADT/IDEF0）侧重于系统的活动、数据流和控制流的综合表示。系统分析与实时性（SA-RT）模型加强了对系统响应时间和并发性的考虑。增强功能流程图（eFFBD）和功能分析系统技术（FAST）进一步细化了功能之间的流程和相互作用，为深入理解系统提供了框架。
 *  **语义模型**：语义模型专注于定义系统的数据和其逻辑结构。实体-关系图揭示了数据实体之间的关系，类图则在面向对象的环境中描述了类的结构和它们之间的交互。数据流图展示了数据在系统中的流动和处理，从而帮助分析系统的信息处理方式。
 *  **动态模型**：动态模型捕捉系统行为的时间特性和状态变化。状态转换图和状态图表现了系统或组件的不同状态及其转换条件。系统建模语言（SysML）的状态机图和活动图提供了对系统行为的更细致描述，包括并发性和事件驱动的行为。Petri网则是一种数学建模语言，用于描述分布式系统中的并行过程。

针对特定领域（如防御、企业等），架构框架提供了额外的视图或方面来描述系统架构，这有助于全面理解和表示系统的各个组成部分。《企业系统工程关键概念》中提及的“企业架构框架与方法论”一节，深入探讨了这些框架如何支持系统架构的设计和实现。

在国际标准方面，ISO/IEC/IEEE 42010（ISO 2011版）提供了关于架构描述的一般模板和指南，这些标准有助于实现架构设计的一致性和规范性。在适应中国的语境时，需要结合本地的实际条件和需求，以确保逻辑架构的设计既符合国际标准，又能满足本土化的需求。

通过对这些模型和技术的深入分析和应用，可以有效地构建和优化逻辑架构，确保它们能够精确地反映系统需求和目标。这种方法不仅促进了系统设计的专业性和精确性，还增强了架构的灵活性和可扩展性，为未来的发展和变革提供了坚实的基础。

#### 1.3、实际应用考虑因素 ####

逻辑架构模型旨在详细描述系统必须具备的功能，以满足明确提出的需求。这样的模型有助于确保解决方案能全面考虑到所有利益相关者的需求和关注点，同时能够容纳基于现有技术的解决方案以及创新思路。然而，在实际操作中，各利益相关者往往会推动符合自己利益的议程，而解决方案的架构师或设计师可能更倾向于提出他们熟悉的方案。这时，如果逻辑架构模型与选定的生命周期没有恰当结合，就容易被忽略，导致回归各自的偏好和偏见。

当逻辑架构模型成为独立目标或与主要生命周期活动断开联系时，问题将更加严重。这种断开可能是由于使用了过于抽象的语言或符号，或是因为模型的细节层次、耗费的时间，或是最终形成的架构过于复杂且与其创建初衷不符。如果架构的语言、范围和及时性与问题利益相关者或解决方案提供者不相匹配，他们可能更易忽视架构模型。

要避免这些与逻辑架构模型相关的问题，就需要识别和实施一些关键的良好实践。首先，应当确保逻辑架构模型与整个系统生命周期紧密相连，反映实际需求和操作条件。其次，通过使用清晰、直接且具体的语言和符号来减少误解和忽视的可能性。同时，确保架构设计的复杂度与实际需求相符，避免过度设计。此外，适时地更新架构模型以反映新的需求和技术变化也是重要的实践。

在后续的内容中，将进一步探讨如何避免这些误区，并实施哪些良好实践，以确保逻辑架构模型不仅在理论上完善，而且在实际应用中能够有效支持系统的需求和目标。这种方法不仅有助于优化设计流程，还能提高最终系统的性能和满足性，确保其真正符合各方利益相关者的期望和需求。

##### 1.3.1、常见误区 #####

在开发逻辑架构的过程中，需要注意一些常见的误区(如表3-1所示)，这些误区可能会对架构的质量和效能产生负面影响。以下表格是以往在逻辑架构开发过程中总结的关键误区及其描述，提供了对这些问题的洞察，希望帮助未来架构师识别和规避潜在的问题，以优化架构设计和实现过程。

表3-1

<table> 
 <thead> 
  <tr> 
   <th>误区</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>问题相关性</strong></td> 
   <td>逻辑架构模型应与任务分析产生的操作场景相关联。缺乏这种关联可能导致架构与实际需求脱节。</td> 
  </tr> 
  <tr> 
   <td><strong>架构模型输入</strong></td> 
   <td>架构定义活动的主要输入是系统需求集合，当它们未能正确解决架构的适当层次时，会导致架构师忽略需求，仅凭自己对输入的理解来构想解决方案。</td> 
  </tr> 
  <tr> 
   <td><strong>过度分解</strong></td> 
   <td>许多初学者的常见错误是对功能分解过深，或在当前系统块的场景或功能架构模型中包含过多的功能和输入/输出流。这种过度分解会导致架构过于复杂，难以管理和实现。</td> 
  </tr> 
  <tr> 
   <td><strong>未将输入和输出与功能一同考虑</strong></td> 
   <td>一个常见的错误是仅考虑由功能支持的操作并进行分解，而忽略输入和输出，或过于延迟考虑它们。输入和输出是功能不可分割的部分，不应被忽视。</td> 
  </tr> 
  <tr> 
   <td><strong>仅考虑功能的静态分解</strong></td> 
   <td>静态功能分解是最小的功能架构模型任务，回答了“如何完成？”这一基本问题。静态分解的目的是为了方便管理或浏览功能列表。仅在创建了场景且逻辑架构接近完成时，才应建立静态分解。</td> 
  </tr> 
  <tr> 
   <td><strong>混合治理、管理和操作</strong></td> 
   <td>在复杂系统中，治理（战略监控）、管理（战术监控）和基本操作经常混合在一起。逻辑架构模型应该同时处理行为架构模型和时间架构模型，避免这些领域之间的混淆。</td> 
  </tr> 
 </tbody> 
</table>

##### 1.3.2、实践建议 #####

在构建和优化逻辑架构时，采用一系列经过验证的实践方法可以达到事半功倍。这些实践(如表3-2所示)建议不仅能够指导架构师系统地思考和组织架构元素，还能帮助避免常见的设计陷阱，从而提升架构的质量和效率。

表3-2

<table> 
 <thead> 
  <tr> 
   <th>实践建议</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>构建功能场景</strong></td> 
   <td>在构建功能的分解树之前，必须先对系统的行为进行建模，建立功能场景，并将功能分解为子功能的场景。</td> 
  </tr> 
  <tr> 
   <td><strong>分析与综合循环</strong></td> 
   <td>面对包含大量功能的系统时，应尝试将功能合成为更高抽象级别的功能，借助一定的标准。不要仅进行分析，而应采取小周期的分析（分解）与综合循环。使用场景的技术包括这种设计实践。</td> 
  </tr> 
  <tr> 
   <td><strong>交替功能和行为视角</strong></td> 
   <td>功能（动作动词，如“移动”）及其执行状态/操作模式（如“移动中”）是两种相似且互补的视角。利用这一点，考虑系统的行为视图，允许从一个操作模式过渡到另一个。</td> 
  </tr> 
  <tr> 
   <td><strong>创建功能场景的顺序</strong></td> 
   <td>创建功能场景时，先建立功能的（控制）流程会更高效，然后添加输入和输出流，并最后添加触发器或信号以进行同步。</td> 
  </tr> 
 </tbody> 
</table>

[3-1]: https://img-blog.csdnimg.cn/img_convert/79f129294a146a24c7c67b02067b4bee.webp?x-oss-process=image/format,png
[3-2]: https://img-blog.csdnimg.cn/img_convert/4b90cb0b6670ee8ae61e734a4ca66144.webp?x-oss-process=image/format,png
[3-3]: https://img-blog.csdnimg.cn/img_convert/7868026278b2b024637e0de86784c8b4.webp?x-oss-process=image/format,png
[3-4]: https://img-blog.csdnimg.cn/img_convert/80e42ee31ff917e15f9d70133356e07a.webp?x-oss-process=image/format,png
[3-5]: https://img-blog.csdnimg.cn/img_convert/77e117bd22f05e172e2b3fda60e6557c.webp?x-oss-process=image/format,png