关于逻辑和物理架构模型开发之间的迭代-电子发烧友网

正如在“系统需求”中所讨论的，在集成解决方案中所采用的精确方法通常取决于系统是一个已经被理解的产品或服务的进化演进，还是一个新的和前所未有的解决方案(参见集成可能的解决方案)。

无论采用何种方法，架构活动都需要在逻辑架构模型开发和物理架构模型开发之间花费几次迭代，直到逻辑和物理架构模型一致并提供必要的详细级别。最初的架构活动之一是基于标称场景(功能)创建逻辑架构模型。物理架构模型用于确定能够执行系统功能的主要系统要素，并对它们进行组织。

后续的逻辑架构模型迭代可以考虑到系统要素的功能分配，以及来自物理解决方案选择的派生功能。它还通过引入之前没有考虑到的其他场景、故障分析和操作需求来补充初始逻辑架构模型。导出功能分配给系统要素;反过来，这会影响物理架构模型。

额外的迭代集中于生成完整的、一致的解决方案逻辑和物理视图。

在系统设计期间，技术选择可能导致新的功能、新的输入/输出和控制流，以及新的物理接口。这些新要素可以导致创建新的系统需求，称为派生需求。

接口的概念

在定义系统的架构时，接口的概念是最重要的考虑因素之一。接口的基本方面是功能性的，它被定义为功能的输入和输出。由于功能由物理要素(系统要素)执行，功能的输入/输出也由物理要素执行;这些称为物理接口。因此，接口的概念同时考虑了功能和物理方面。对接口的详细分析显示，“发送”功能位于一个系统要素中，“接收”功能位于另一个系统要素中，而“载送”功能则由支持输入/输出流的物理接口执行(参见图2)。

在系统要素之间复杂的交换环境中，特别是在软件密集型系统中，协议被看作是携带数据交换的物理接口。但是，输入/输出流可以包括除数据之外的许多其他交换，例如能量。

紧急属性

一个系统的总体架构可能具有从系统要素之间的安排和交互中产生的设计属性或操作效果，但这些属性可能不是任何单个要素的属性，也不是为整个系统设计的。

一个工程系统的要素之间相互作用，可以产生理想或不理想的现象，如抑制、干扰、共振或增强任何性质。系统的定义包括分析系统要素之间的相互作用，以防止不良的特性和加强理想的特性。

从系统中产生的属性可以有不同的起源，从单一的系统要素到多个要素之间的相互作用。一些作者使用紧急属性这个术语来识别从一个系统中出现的任何属性，而另一些人可能将其称为协同作用和储备紧急属性，用于解释意外属性或在系统开发过程中没有充分考虑但在操作过程中出现的属性。涌现的系统概念将在系统工程知识体系第2部分(参见涌现)中讨论。

属性的大类	说明和示例
状态	属性位于一个单一的系统要素中——例如，容器的容量就是系统的容量。
累计系统属性	该属性位于几个系统要素中，并通过要素属性的简单总和得到——例如，系统的权重是由系统要素的权重总和得到的。

由架构和/或相互作用修改的涌现属性。

由相互作用产生的涌现性

属性存在于多个系统要素中，并通过它们的相互作用而修改——例如，一个系统的可靠性/安全性来自于每个系统要素的可靠性/安全性及其组织方式。

架构步骤通常对于满足系统需求至关重要。

这种特性并不存在于系统要素中，而只是来自于它们之间的相互作用——例如机电接口、电磁、静电等。

紧急控制属性

在出系统之前受到控制或抑制的特性——例如:通过增加负载而消除的不平衡;用阻尼器减弱振动。

物理架构设计将包括识别可能的协同作用和紧急特性，并在逻辑或物理架构模型中包含派生功能、组件、安排和/或环境约束，以避免、减轻或约束它们在可接受的范围内。当相应的派生需求影响到系统相关(系统利益（SoI）)时，应该将它们添加到系统需求基线中。这可以通过系统工程师的知识和经验或者通过系统模式的应用来实现。然而，通常是不可能预测，避免，或控制所有涌现的特性

架构的开发。充分处理涌现的后果只能通过系统定义、系统实现和系统部署和使用之间的迭代来完成

出现的概念应用于架构和设计中，以突出必要的派生功能;此外，内部涌现通常与复杂性的概念相联系。这就是复杂自适应系统(CAS)的情况，其中单个要素独立行动，但根据共同的约束和目标共同行动。CAS的例子包括:一个国家或国家集团内的全球宏观经济网络、股票市场、跨国控股公司的复杂网络、制造企业、地缘政治组织等。

系统要素的复用

系统工程师经常利用现有的系统要素。这种复用约束必须被识别为系统需求，并在架构和设计期间仔细考虑。我们可以区分三种涉及系统要素复用的一般情况，如表2所示。

复用的情况	行为和评论
案例1:系统要素的需求是最新的，它将被复用，不需要修改。	被定义的系统架构将必须适应被复用的系统要素的边界、接口、功能、有效性和行为。
案例2:系统要素的需求是最新的，它将被复用，并可能进行修改。	如果系统要素不适应，很可能成本、复杂性和风险会适应增加。
案例3:需求不是最新的或者不存在。	要定义的系统架构足够灵活，能够适应复用系统要素的边界、接口、功能、有效性和行为。复用的系统要素的设计，包括它的测试报告和其他文档，将被评估和潜在地重新设计。有必要对系统要素进行反向工程，以识别其边界、接口、功能、性能和行为。这是一项困难的活动，因为复用的系统要素的现有文档可能不可用或不够用。逆向工程在时间和金钱上都是昂贵的，而且随之而来风险增加。