物理架构的设计和实施，相较于逻辑架构，更侧重于软件系统在计算环境中的实际运行和部署方式。这一层面的架构强调如何将软件系统有效地集成到具体的硬件环境中，同时确保系统在实际运行过程中展现出高度的稳定性和优秀的性能。物理架构的主要考虑因素包括对系统所需硬件环境的规划、网络的拓扑结构设计、数据存储方案的制定，以及系统的部署策略。
在物理架构的设计过程中，必须综合考量硬件资源的配置、网络连接的稳定性、安全性要求等关键因素，来制定出一个既合理又高效的物理布局方案。为了优化系统的可扩展性、可靠性和资源利用率，设计者常常会借助云原生技术、容器化等现代技术手段。这些技术使得系统能够在资源分配和运维管理上更为灵活，同时能够快速适应变化的业务需求和技术环境。
物理架构还需密切关注数据保护和系统恢复能力，以确保在面对硬件故障、网络攻击或其他不可预见事件时，系统能够迅速恢复正常运行。这包括实施有效的数据备份策略、建立稳健的容灾计划，以及配置适当的安全措施来防范潜在的风险和威胁。
1、物理架构模型
物理架构模型的开发不仅是系统架构定义过程中的一个关键环节，也是"开发候选架构模型和视图"活动中的重要任务。它专注于构建和细化一个既能体现逻辑架构模型又能满足系统综合需求的具体物理解决方案。详细地说，一旦确定了逻辑架构模型，接下来的挑战就是确定那些能够支持系统的功能性、行为特征和时间特征的具体物理元素，并确保这些元素能满足由非功能性系统要求衍生出的预期属性，比如更新过时的组件或保持产品的持续支持。
具体来看，物理架构模型涉及到的是各种物理元素（如系统组件和物理接口）的安排，其目标是提供满足逻辑架构要求和系统要求的产品、服务或企业解决方案。这种模型不仅要与国际标准ISO/IEC/IEEE 26702（ISO 2007）保持一致，而且应能通过技术手段实现。这意味着，系统的要求必须在逻辑架构和物理架构之间合理分配，以确保最终形成的系统架构既能通过系统分析进行有效评估，又能作为系统实施的基础。
在实践中，尤其是当需要为多个系统定义统一的物理架构模型时，界面标准可能成为物理架构模型的关键驱动因素。这些物理接口的设计和标准化对于确保系统间的一致性和互操作性至关重要。在系统的整体要求中，可能已经对这些接口标准做了规定，以保证系统层面的一致性和可维护性。同时，在物理架构模型的开发过程中，也可能派生出新的标准，这对于促进工程设计的创新和实现系统之间的有效集成至关重要。这样的标准化努力不仅有助于构建系统族和技术插入，还促进了互操作性和开放系统的发展。从今天的视频技术、高保真音响系统到计算机系统，乃至工程领域中的各种标准（如服务器、存储设备、网络交换机、路由器以及数据中心的布局等），都展示了接口标准化对于推动技术进步和实现系统兼容性的重要作用。
1、物理架构要素
物理架构的核心在于定义和识别系统要素，这些要素是实现系统设计属性的关键部分。系统要素广泛覆盖，包括硬件、软件、数据、人员、过程（例如，向用户提供服务的流程）、程序（如操作指南）、设施、物料以及自然存在的实体（如水、生物、矿物等），或者这些要素的任何组合。这种定义符合国际标准ISO/IEC/IEEE 15288的规定。物理接口在这里发挥着至关重要的作用，它像链接或连接器一样，将两个系统要素紧密相连。为了具体说明，我们列出了一些系统要素和物理接口的实例，如表3-3所示：
表3-3
| 要素类型 | 产品系统 | 服务系统 | 企业系统 |
|---|---|---|---|
| 系统要素 | 硬件部件（服务器、存储设备、网络交换机、路由器等） 操作员角色 软件组件 | 流程、数据库、程序等 操作员角色 软件应用程序 | 企业、方向、部门、项目、技术团队、领导等 IT组件 |
| 物理接口 | 硬件部件、协议、程序等 | 协议、文件等 | 协议、程序、文件等 |
在这个框架下，我们进一步探讨了复杂系统的结构特性。这样的系统通常包含成千上万的物理和/或无形部分，这些部分可以按照多个层次的系统和系统要素来组织。为了有效管理这种复杂性，一个系统结构层面上的要素数量通常被限制在几个之内，具体来说，通常是"五加减二"个要素(如图3-6所示)，这有助于清晰地管理和定义系统。
在物理架构模型的构建过程中，我们不仅需要关注系统内部的系统要素和它们之间的物理接口，还需要关注系统外部的要素。这包括邻近的或使能系统和/或系统要素，以及在全局系统范围内相关的要素(如图3-7所示)。这种全面的视角有助于我们深入理解和管理复杂系统的动态和相互作用，确保整体架构的一致性和有效性。
1.2、设计属性
设计属性是系统架构过程中的关键成果，通过对非功能需求的分配、估算、分析、计算及模拟特定方面得到，或者是通过定义与系统元素、物理接口和/或物理架构相关联的现有元素形成的。当定义的元素满足特定需求时，设计属性将与该需求直接相关或相等。如果存在偏差，就需要识别这些偏差，它们可能会导致需求或设计属性的修改，并需要检测出任何的偏离情况。
利益相关者对系统的关注点通常围绕系统在实际操作、环境和物理限制下的预期行为，以及更广泛的生命周期约束。这些关注点通过利益相关者需求和系统需求得到表达，这些需求描绘出系统应具备的预期能力，如可用性、互操作性、安全性、扩展性、适应环境能力等。架构师和设计师从这些需求中识别出必要的功能，并推导出相应的定量或定性设计属性，以便为他们的物理架构模型配备适当的特征，如可靠性、可用性、可维护性、模块化、鲁棒性、可操作性、对气候环境的抗性、尺寸限制等。
这些设计属性是构成系统架构的基石，它们确保系统能在既定的限制和要求下正常运行。通过深入分析和精心设计，这些属性帮助系统架构师创建出既符合技术要求又满足利益相关者期望的解决方案。为了进一步探讨这些属性如何被纳入架构和设计中，可以参考《系统工程与相关学科的质量属性》等文献，这些资源提供了深入的视角和方法论，指导架构师在设计过程中如何有效地应用这些设计属性。
1.3、物理元素
在系统设计过程中，构建一个候选物理架构模型是一项综合性工作，它从识别能够实施逻辑架构模型中定义的功能的系统元素开始，包括确定能够处理输入输出流和控制流的接口。系统工程师需要在逻辑架构中分配设计属性，这些属性基于系统需求而确定。功能的分区和分配是关键活动，通过对功能进行分解、聚合或分离，以便更容易地识别出能够支持这些功能的可行系统元素。这些元素或者是现成可用且能被重用或重新定位的，或者需要新开发和技术实现。
在分区和分配过程中，系统工程师根据特定标准寻找功能之间的潜在关联，这些标准包括系统需求和设计属性。他们评估和选择候选系统元素和功能分区时会考虑多种因素，如技术内部的相似变换、效率水平、信息、能量和材料的输入输出流类型、集中或分布式的控制方式、执行频率的接近度、可依赖性条件、对环境的抗性水平，以及其他企业约束。
当需要结合多种不同的技术、知识和技能来建立候选物理架构模型时，并行工程方法变得尤为重要。在将功能分配给各个系统元素的过程中，系统工程师必须解决兼容性问题，并考虑到涌现属性，确保整个系统的协调一致和高效运作。这种综合性的方法要求系统工程师不仅仅是在技术层面上进行考虑，还要在策略和操作层面上进行思考，以发现和实施最优的解决方案。
1.4、候选物理架构模型
物理架构模型开发的核心目标是提供一个最佳的物理架构模型，这个模型由适配的系统、技术系统元素和物理接口组成。这样的架构应当尽可能地满足所有系统需求，这些需求根据每个需求的约定限制或容差来确定。为了达到这个目标，最有效的方法是制定多个候选物理架构模型，对它们进行全面评估和对比，从而选出最适合的模型。
候选物理架构模型的构建基于亲和性标准，以建立一组系统元素集合，包括分离、聚集、连接以及断开系统元素及其物理接口的网络。这些亲和性标准与分区和分配功能至系统元素时采用的标准是一致的。物理架构模型的开发可以从多个角度进行专注和优化，具体包括：
- 减少物理接口的数量，以简化系统结构和降低复杂性。
- 设计可以单独测试的系统元素，以便于进行故障隔离和维护。
- 确保技术兼容性，以便不同元素间能够无缝协作。
- 考虑空间中元素的接近程度，以优化布局和提高系统效率。
- 注重操作便捷性，考虑重量、体积和运输设施，以提高系统的可搬移性和易用性。
- 在元素间优化共享资源，以实现资源的高效利用和成本节约。
- 推进模块化设计，确保系统元素间的低依赖性，便于扩展和维护。
- 强化系统的韧性，确保元素具有高度的可靠性、可维护性或可替换性，以提高系统的整体稳定性和持久性。
物理架构模型的开发不仅要考虑单个元素的性能和特性，还要综合考虑这些元素在整个系统中的相互作用和协同效应。选择最佳的物理架构模型需要综合评估各种因素，以确保最终的架构能在满足系统需求的同时，在约定的限制或容差范围内提供最优的性能和可靠性。这种综合、全面的评估和选择过程是确保物理架构的有效性和适应性，满足系统长期目标和需求的关键。
1.5、候选架构
在系统设计中，发展出可行的物理架构模型是至关重要的，这些模型应使得逻辑架构中规定的所有必需功能或能力得以实现。架构和设计的过程包括了综合评估，旨在实现设计属性、成本、风险等因素之间的平衡。在多数情况下，系统的物理架构模型受到非功能需求的影响更甚于功能需求，这些非功能需求包括性能、安全性、保安、环境条件和约束等。尽管可能有多种方法来实现功能，但满足这些非功能需求的途径则更加有限。
首选的物理架构模型展现了系统元素的选择及其物理关系和接口。这种物理架构通常还需要进一步的系统工程工作来实现完全优化，在处理剩余的权衡并确定系统的算法和参数后，将实现一个高度优化的系统结构。
为了充分理解候选架构在满足系统需求方面的全局行为和结构，必须进行各种分析，如效率、可靠性、成本和风险等方面的分析，这通常归类为系统分析。此外，其他的分析和评估需要借助不同技术和专业领域的知识与技能，如机械、电子、软件、热力学、电磁兼容性、安全性和保安等。这些分析和评估通过相应领域的专业分析来执行。
在评估和选择首选候选方案的过程中，综合这些多维度因素极为关键。这一过程不仅涉及对每个物理架构模型的技术性能和功能性的评估，还包括对其经济性、安全性、环境适应性和可持续性的全面考量。通过这种综合评估和深入分析，可以确保选定的物理架构模型在技术上可行，经济上合理，并且在环境和社会层面上可持续，从而实现系统设计的最优化和性能卓越。这种方法确保了在满足当前需求的同时，也考虑了系统的长期发展和可持续性。
1.6、遗留系统
在现实中，很少有系统是孤立存在或操作的。它们通常与其他运行系统或维护和支持系统进行互动，这些系统可能是已经在使用中的遗留系统，或是正在开发中且未来可能与关注的系统共同运作的未来遗留系统。
选择最适合的方法依赖于所关注系统（System-of-Interest, SoI）与其广泛环境之间交互的密切程度。对于交互较少的情况，可以通过定义一系列静态的外部接口需求（例如，遵循技术标准）来解决，这些需求应纳入系统需求中，并通过设计保证来确保符合性。
在交互更频繁的情况下（例如，需要与其他系统进行持续的信息交换），这种互动应视为系统群（System of Systems, SoS）环境的一部分，并应在企业系统工程方法中加以考虑。这要求对系统间的动态关系进行更为深入的分析和整合。
另一方面，SoI与其他系统之间的技术或系统元素共享也是一个重要考量，这常见于系统族中（如在汽车和航空航天行业中）。或者涉及从现有遗留系统中重用系统元素。这里需要进行自上而下或中层向外的设计工作，以确保所关注的系统不仅包含必要的系统元素，而且尽可能地符合利益相关者和系统需求，同时管理任何必要的妥协。
如果SoI预期用于一个或多个服务系统或系统群（SoS）配置，这将直接影响其物理架构模型。这些SoS的一个特点是在使用中对组件系统进行后期绑定。这些组件系统必须设计有开放或可配置的接口，其功能定义应与使用它们的SoS相关，并且包含一种方法，以便在需要时能将它们识别并纳入SoS。
服务系统和SoS将由高级物理架构模型定义，该模型用于确定相关的SoS关系、接口和约束，并应纳入概念定义阶段。这些结果将融入到利益相关者和系统需求中，并通过开发、实现和使用过程中的接口协议和跨项目沟通来管理。这种综合方法确保了系统架构在多个层面上的协调一致性和整合性，为实现高效、可持续的系统操作提供了基础。
2、过程方法
物理架构模型的开发旨在定义、挑选并构建一个能够支撑逻辑架构模型的系统物理架构。这一模型需要具备特定的特性，以应对利益相关者的关切、环境挑战并满足系统需求。
在这个过程中，要明确物理架构的界定，这意味着需要识别和规划系统的物理组成部分及其相互连接。这一步骤依赖于对逻辑架构定义的功能和性能需求的深入理解，以确保这些需求能够在物理层面得到有效实现。
2.1、目标
物理架构过程方法的目标是确保系统元素构成的物理架构能够随着系统使用环境或技术可能性的演变而演变，以持续完成其使命并保持所需的效能。物理架构的演化可能会影响逻辑架构模型元素，根据这种影响，系统元素的分配可能会发生变化。物理架构模型需要具备特定的设计特性，以不断应对这种演变。
- 输入要素：主要包括选定的逻辑架构模型、系统需求、架构师识别和利用的通用模式和属性以满足需求、系统分析的结果，以及系统验证和验证的反馈。
- **输出要素：**则包括选定的物理架构模型、功能元素到物理元素的分配矩阵、与系统需求的可追溯性矩阵、构成物理架构模型的每个系统和系统元素的利益相关者需求，以及被排除的解决方案。
物理架构的发展应与技术演进和使用环境的变化保持同步，确保系统能够持续有效地执行其任务。
物理架构的设计和调整需要基于对逻辑架构的深入理解和分析，以确保两者的一致性和互补性。最后，通过综合考虑输入和输出要素，物理架构过程方法能够确保系统设计的适应性和持久性，同时满足所有利益相关者的需求和期望。
2.2、过程活动
物理架构过程活动包括一系列构建和优化系统物理结构的任务和步骤。这些活动确保物理架构能够有效地支持系统的功能需求，并能适应环境和技术的变化。
-
功能元素的分配和分解:
- 识别能够执行特定功能和支持输入输出及控制流的系统元素或技术，并确保这些元素存在或能被设计出来。
- 基于从非功能性系统需求中推导出的设计属性标准，对每个潜在的系统元素进行评估。
- 根据既定标准，对功能元素（如功能、场景、输入输出、触发器等）进行分解，并将分解后的集合分配给相应的系统元素。
- 当无法直接识别与分解的功能集合相匹配的系统元素时，进一步分解功能，直到能够识别出可以实现的系统元素。
- 检验所选系统元素之间的技术和接口兼容性，确保整体的协调性和一致性。
-
构建候选的物理架构模型:
- 鉴于功能集合可能很多，系统元素数量可能过多，因此需要将这些元素聚合为更高级别的系统元素组或子系统。
- 探索不同的系统元素组合，每种组合代表不同的基础系统元素配置，形成多个候选的物理架构模型。
- 使用图形化模式表示每个系统元素组的物理架构，确保其系统元素通过物理接口有效连接，并处理输入输出流和触发器。
- 在系统元素组中加入必要的物理接口，特别是与外部元素的接口，以增强系统的互连性和扩展性。
- 构建并展示综合的物理架构，该架构整合了系统元素组、不可分解的系统元素和从这些组继承的物理接口。
- 加强物理架构模型，融入设计属性，如模块化、进化能力、环境适应性、稳健性、可扩展性和环境抵抗力。
- 应用可执行的架构原型（如硬件-软件联合仿真原型），以发现和修正潜在的架构缺陷。
-
评估和选择物理架构模型候选方案:
- 利用系统分析过程对候选方案进行全面评估，确保每个方案的可行性和优势。
- 通过决策管理过程进行细致的选择和权衡，确定最符合项目目标和需求的物理架构方案。
-
综合并确认选定的物理架构模型:
- 明确并形式化物理元素及其属性，验证所选方案是否满足系统需求并确保其实现的现实性。
- 确定由于架构和设计需要而产生的派生物理和功能元素，及其对应的系统需求。
- 建立系统需求与物理元素之间的追溯关系，以及功能元素与物理元素之间的分配矩阵。
-
通过这种详尽的方法，物理架构过程活动不仅能够确保技术实施的准确性，而且还能保证架构设计的长期适应性和可持续性，满足系统性能和可靠性的长期需求。
2.3、产物、方法和建模技术
物理架构的描述利用建模技术来创建和展现系统的物理结构。这些技术能够详细描绘出结构块、质量、布局等物理模型的特征。在物理架构建模中，常用的技术包括物理块图（Physical Block Diagrams, PBD）、系统建模语言的块定义图（SysML Block Definition Diagrams, BDD）、内部块图（Internal Block Diagrams, IBD）和可执行的架构原型等。
不同的建模技术适用于不同的目的和领域。例如，在防御或企业等特定领域，架构框架可能提供了一套描述工具，帮助架构师在多个候选架构之间进行权衡和选择。
为了更加深入地理解"产物、方法和建模技术"，我们可以将焦点放在以下几个关键领域：
- 产物的角色和功能：在物理架构开发过程中产生的产物，如文档、模型和图表，不仅为技术团队提供了实现物理架构的蓝图，还为项目的各个利益相关方提供了交流和决策的依据。
- 建模方法的多样性和适用性：根据项目的具体需求和目标，应选择适合的建模技术。例如，物理块图（PBD）展示了系统的物理组成和互联，而系统建模语言的块定义图（BDD）则定义了系统构件及其关系，内部块图（IBD）则更详细地展示了内部组件之间的互动。
- 建模技术的专业性和深度：种建模技术都具有其独特的表达方式和专业优势。可执行的架构原型可以在设计早期阶段发现潜在的问题，而标准化建模语言如SysML则促进了不同团队和领域之间的有效沟通。
- 架构框架对建模过程的引导：根据特定的应用领域，架构框架为物理架构的开发提供了原则和指导，确保建模活动能够遵循该领域的最佳实践和标准。
通过对这些关键领域的深入分析，可以更有效地应用各种建模技术和方法，构建出既符合需求又具有可维护性和扩展性的物理架构，从而确保整个设计过程的专业性、条理性和流畅性。
3、实际应用考虑因素
在物理架构开发的过程中，需要考虑一些常见误区和实践建议。这些考虑因素对于确保物理架构的成功实施至关重要。在接下来的两个部分中：常见误区和实践建议。
3.1、常见误区
在物理架构模型开发过程中，表3-4所展示的是专业人员常面临一些误区，若不加以识别和避免，可能导致项目的低效甚至失败。以下详细阐述了几个典型的误区及其解决方法，以确保物理架构的成功实施和高效性能。
表3-4
| 误区 | 描述 |
|---|---|
| 单一系统块中分解层次过多 | 在一个系统块内包含过多的分解层次是一个常见的问题。理想的做法是，系统块的物理架构模型应该只包含单一层次的系统和/或系统元素。过度的层次分解会增加架构的复杂性，使管理和理解变得困难。 |
| 没有逻辑架构模型 | 开发者有时会直接从系统需求过渡到物理架构模型，而不建立逻辑架构模型。这种做法尤其在处理重复的系统和产品时比较常见，因为认为功能已经确定。但这忽略了功能总是与特定域集中定义的输入输出流相关的事实。如果域集发生变化，原有的功能性能可能不再有效。 |
| 直接在技术上分配功能 | 在多学科系统的高层抽象中，直接将功能分配到最低层抽象的技术上（例如硬件或软件），并不反映对系统的全面理解。更恰当的做法是，通过考虑适当的标准来分解架构，使其在达到技术层级之前，能够在逻辑和物理层次之间适当切换。 |
识别这些常见误区并采取相应的预防措施是至关重要的，有助于确保物理架构开发过程的顺利进行，并提高最终架构的质量和效率，开发团队可以更有效地规遍和实施物理架构，从而确保项目的成功。
3.2、实践建议
如表3-5所示在物理架构的实践中，从经验中总结出的一些有效做法对于构建成功的系统架构至关重要。以下是对这些实践的扩展描述，提供更为丰富和详细的理解：
表3-5
| 关注点 | 实践建议 |
|---|---|
| 模块化 | 在设计物理架构时，模块化原则是核心，它要求限制系统元素之间的相互作用。具体而言，这意味着每个系统元素内部应保持最大的一致性，并且与外部的物理接口数量保持最小。这种方法不仅有助于减少系统复杂性，还促进了更高效的维护和升级过程，因为各模块或组件可以独立地修改和替换，而不会对整个系统产生广泛影响。 |
| 关注接口 | 在抽象层次的系统设计和架构中，聚焦于接口而不是单独的系统元素本身，是实现有效架构的关键。这种方法强调了接口的重要性，即系统元素如何相互连接和交互。专注于接口可以确保系统的不同部分能够以一致和标准化的方式进行通信，从而提高整体系统的可用性和稳定性。此外，良好定义的接口有助于系统的扩展和集成，使得添加或修改功能变得更加容易。 |
通过模块化跟接口，架构师和设计师可以更有效地创建出可维护、可扩展且高效的物理架构系统，确保它们能够适应不断变化的需求和技术进步。
4、逻辑架构与物理架构的协作
逻辑架构与物理架构在软件系统的设计和实现中扮演着互补和相互依赖的角色。这两种架构虽然从不同的角度审视系统，但它们的合作是确保软件成功实施的关键。
逻辑架构主要关注系统的功能和行为，它定义了系统的组成部分以及这些部分如何相互作用来满足业务需求。通过合理的逻辑架构设计，可以确保软件系统不仅易于理解和维护，而且具有良好的扩展性和灵活性，为未来的发展留出空间。
物理架构则从实际的实施角度出发，专注于将逻辑架构映射到具体的硬件和网络环境上。它考虑如何有效地部署系统元素，以实现性能优化、成本控制和资源最佳利用。物理架构的优化关注点包括系统的可靠性、稳定性和高效性，确保软件系统在实际操作环境中的表现符合预期。
在软件开发的实践中，逻辑架构的设计通常是首要步骤，它为整个系统提供了一个清晰的蓝图和方向。随后，物理架构的设计基于逻辑架构提出的规范，考虑具体的技术实现和部署环境。这包括选择适合的硬件平台、网络配置、存储解决方案以及考虑系统的安全性和数据保护措施。
随着业务需求和技术环境的不断变化，逻辑架构和物理架构需要进行持续的评估和调整。例如，云计算的广泛应用要求软件系统能够灵活迁移至云端，这不仅需要物理架构的调整来适应云基础设施，也可能需要对逻辑架构进行优化以更好地利用云环境的特性和服务。因此，逻辑架构和物理架构的有效协作是实现高效、可靠和可扩展软件系统的关键。它们之间的关系应是动态发展的，以适应新的技术趋势和业务需求。通过深入理解这两种架构的特点和如何相互补充，我们可以设计和实现更加强大和适应未来的软件系统。这种整体的方法论不仅提高了软件项目的成功率，还确保了系统能够持续进化，以满足不断变化的市场和技术环境的需求。