6.可操作性

6 可操作性

With Liming Zhu

早起的鸟（A）到达并抓到虫子（B），拉动绳子（C）并发射手枪（D）。子弹（E）使气球（F）爆裂，砖块（G）落在雾化器（I）的灯泡（H）上，香水（J）落在海绵（K）上。随着海绵重量的增加，它会降低自身并拉动绳子（L），从而抬高木板的末端（M）。炮弹落在熟睡绅士的鼻子上。绑在炮弹上的绳子会释放真空瓶（P）的软木塞（O），冰水会落到睡眠者的脸上，以帮助炮弹正常工作。

—Rube Goldberg, instructions for “a simple alarm clock”

互操作性大约是指两个或多个系统可以在特定上下文中通过接口有效交换有意义的信息的程度。 该定义不仅包括具有交换数据的能力（语法互操作性），而且还具有正确解释正在交换的数据的能力（语义互操作性）。 系统不能孤立地互操作。 对系统互操作性的任何讨论都需要确定与谁，什么以及在什么情况下（因此需要包含上下文）。

互操作性受预期可互操作的系统的影响。 如果我们已经知道与系统进行互操作的外部系统的接口，则可以将这些知识设计到系统中。 或者我们可以将系统设计为以更通用的方式进行互操作，以便可以在生命周期的后期，构建时或运行时绑定其他系统提供的标识和服务。

像所有质量属性一样，互操作性不是“是或不是”的命题，而是具有深浅的含义。 有几个互操作性的特征描述框架，它们似乎都定义了五个级别的互操作性“成熟度”（有关指针，请参见本章末尾的“更多阅读”部分）。 最低级别表示完全不共享数据或不成功共享数据的系统。 最高级别表示系统可以无缝协作，在解释彼此的通信时不会犯任何错误，并且共享与工作环境相同的基本语义模型。

“通过接口交换信息”

正如我们所说，互操作性大约是两个或多个通过接口交换信息的系统。

在这一点上，我们需要澄清两个关键概念，这是讨论的核心，并强调我们对每个概念都具有广泛的看法。

第一个是“交换信息”的含义。这可能意味着像程序A这样简单的事情，它调用带有某些参数的程序B。 但是，即使两个系统（或系统的一部分）从不相互直接通信，也可以交换信息。 在初中时，您是否曾经有过如下对话？ “夏琳说金告诉她，特雷弗听说希瑟想参加你的聚会。”当然，初中的协议将排除直接回应希瑟的可能性。 相反，您的回答（如果您喜欢Heather）可能是“酷”，它将通过Charlene，Kim和Trevor返回。 您和希瑟（Heather）交换了信息，但从未互相交谈。 （我们希望您在聚会上能互相交谈。）

实体可以以更少直接的方式交换信息。 如果我对某个程序的行为有一个了解，并且我将程序设计为在假定该行为的情况下运行，那么这两个程序也已经交换了信息，而不仅仅是在运行时。

历史上最臭名昭著的软件灾难之一是，1991年反导系统未能拦截“沙漠风暴”行动中的一枚弹道导弹，造成28人死亡。 导弹的软件组件之一“有望”被关闭并定期重启，因此它可以从已知的起点重新校准其定向框架。 导弹发射时，该软件已经运行了大约100个小时，并且计算错误已累积到一定程度，以至于该软件组件的定向概念已无可救药地偏离了事实。

系统（或系统中的组件）通常对其“信息交换”合作伙伴的行为抱有或体现期望。 在前面的示例中，所有与错误组件交互的假设都是其准确性不会随时间而降低。 结果是零件系统无法正确协作以解决它们应解决的问题。

我们需要强调的第二个概念是“接口”的含义。我们再一次指的是简单情况之外的东西-组件程序的语法描述及其参数的类型和数量，通常以API的形式实现。这对于实现互操作性是必要的-哎呀，如果您希望软件成功编译是必要的-但还不够。为了说明这个概念，我们将使用另一个“对话”类比。您的伴侣或配偶是否曾经回家，砸过门，当您问出什么问题时，回答“没事！”？如果是这样，那么您应该能够理解语法和语义之间的敏锐差异以及期望在理解实体行为方面的作用。因为我们需要可互操作的系统和组件，而不是简单地很好地编译在一起的系统和组件，所以我们要求接口的标准更高，而不仅仅是语法声明。所谓“接口”，是指您可以安全地对实体进行的一系列假设。例如，可以安全地假设您的配偶/伴侣有什么毛病，不是“什么都没有”，您知道那是因为“接口”不仅限于他们所说的话。而且这也是一个安全的假设，即我们的导弹组件的API随时间的推移不会降低精度，但这是其界面的关键部分。

—PCC

您可能希望系统进行互操作的一些原因如下：

• 您的系统提供了供未知系统集合使用的服务。 这些系统需要与您的系统进行互操作，即使您可能对它们一无所知。 一个示例是诸如Google Maps之类的服务。
• 您正在从现有系统中构建功能。 例如，一个现有系统负责感测其环境，另一个系统负责处理原始数据，第三个系统负责解释数据，最后一个系统负责生成和分发所感测的内容的表示形式。 。 一个示例是交通传感系统，其中输入来自各个车辆，原始数据被处理为通用的度量单位，被解释和融合，并广播交通拥堵信息。

这些示例突出了互操作性的两个重要方面：

1. 发现。 服务的使用者必须发现（可能在运行时，可能在运行时之前）服务的位置，身份和接口。
2. 处理响应。 有三种不同的可能性：
   • 服务将响应报告给请求者。
   • 服务将其响应发送到另一个系统。
   • 该服务将其响应广播给任何感兴趣的各方。

这些要素（响应的发现和处置以及接口的管理）控制着我们对场景和互操作性策略的讨论。

系统的系统

如果您有一组相互协作以实现共同目的的系统，那么您将拥有所谓的系统的系统（SoS）。 SoS是系统的布置，当将独立且有用的系统集成到提供独特功能的较大系统中时，就会产生结果。 表6.1显示了SoS的分类。

表6.1系统的系统分类*

.	.
直接的	制定了SoS的目标，集中管理，资金和整个SoS的权限。 系统从属于SoS。
应答式	SoS目标，集中管理，资金和权限到位。 但是，系统与SoS并行保留自己的管理，资金和权限。
协作式	SoS级别没有总体目标，集中管理，权限，责任或资金。 系统自愿合作以解决共同或共同的利益。
虚拟的	像协作式的一样，但是系统之间彼此不了解。

* 显示的分类法是Mark Maier在1998年所做工作的延伸。

在定向和公认的SoS中，有意创建SoS。 关键的区别在于，在前者中，存在SoS级管理来对组成系统进行控制，而在后者中，组成系统在其自身的演化中保留了高度的自治性。 系统的协作和虚拟系统更特别，缺少总体权限或资金来源，对于虚拟SoS，甚至缺少关于SoS范围和成员资格的知识。

合作案例非常普遍。 考虑一下引言中的Google Maps示例。 Google是地图服务的管理者和资助机构。 应用程序（SoS）中对地图的每次使用都有其自己的管理和资金授权，并且对使用Google Maps的所有应用程序没有全面的管理。 应用程序中涉及的各种组织（显式或隐式）进行协作以使应用程序正常工作。

虚拟SoS涉及大型系统，并且是临时性的。 例如，美国电网中有3,000多家电力公司，每个州都有一个公用事业委员会，负责监督在该州运营的公用事业公司，而联邦能源部则提供一定程度的政策指导。 电网中的许多系统必须可以互操作，但是整个系统没有管理权限。