逻辑分解在系统架构中的角色

定义“复杂性”

一个好的开头是讨论“复杂性”的意思是什么。这里有一个启发性的定义：

“... 系统或组件的设计或实现难于理解及验证的程度” ³

更学术的定义来自 McCabe ⁴ 和其他人开发出的度量秩数复杂度的方法。通过检查秩数复杂度方法，我已经发现了通过以下问题推出复杂性是有用的：确定系统进入某种状态有多难？

对于 system state（系统状态），我指的是系统元素的配置。这可以包括那种物理实现的内存和寄存器中的位的软件变量、物理位置，例如机器人组件或汽车转向子系统的零件的相对位置，电子零件中的电压，等等。状态空间可能被认为是一个大向量空间，其每个基本元素跨越一个系统元素的可能状态（比方说内存寄存器或偏心角）。人们必须理解，在该状态空间中，系统从一点演进到另一点。如果没有许多路径进入已知点，那么系统可以说是 简单的，而如果有许多路径进入已知点，那么系统可以说是 复杂的。在后一种情况下，如果系统常常处于不希望的状态下，那么很难了解如何修补或与系统交互。

软件缺陷

这一观点是实际的，因为当系统处于某种意外的状态下（会导致某种非期望的结果）时系统缺陷会出现。如果系统是简单的，那么不难了解系统如何进入已知状态，以及如何防止该状态循环（这是“调试”。）如果系统是乱七八糟的，那么系统可能通过许多路径进入不希望的状态，并且因此很难调试。而且，这种系统很难扩展，因为很难预测添加的状态如何与现有的状态交互。

从传统上讲，用很少部件实现目的的纯物理系统被认为优于那些用更多部件的系统 —— 大部分由于它们有较小的状态空间，并且因此不太可能有缺陷。

状态转移的数量（在状态空间中从一点移动到另一点）以状态空间大小的平方增长，当然状态空间中的可能路径的数量按指数规律增长。因此，除非有什么可以分治状态空间，否则系统将变得难以控制地复杂。秩数复杂度是度量状态空间中路径有多紊乱的方式。

对象方法的出现

这种难以控制的复杂度在计算的时代很早就出现了。随着软件程序的增长，它们变得复杂了，这是我一直讨论的。不久变得明显的是，良好的程序设计实践可以帮助组织避免复杂性。举例来说，程序设计人员不久了解到，出于此原因，要避免令人畏惧的“goto”语句。为了解决复杂性，而产生了结构化的语言，例如 Pascal 和 C，生成了提供状态空间的有用分割的状态变量的层次结构。下一个演进是对象语言，它将状态变量结构和影响它们的操作捆绑为实体，成为类对象。生成良好的软件状态空间的分割是对象设计的关键目标。目的在于减少复杂性，并且具有可维护性和可扩展性，同时仍旧提供功能性。

对象方法为有状态系统的设计带来其他优势。如果运行系统有许多同样种类的实例（比方说，IT 系统或传感器消息中的界面图形元素），每个都将有相同的状态模型。而且，如果系统中有类似的东西，像对磁带录音机的不同用户控件，对象方法可以确保它们拥有同样类似的状态模型。所有这些都对可维护性和可扩展性提供了帮助。

对象方法对于整个系统架构越来越有用，因为两个原因：

1. 所有种类的现代系统都变得更有状态，这出于许多原因，包括嵌入式软件的数量，更有能力的硬件，及现代网络技术允许的集成。
2. 状态不再很容易由物理子系统分割了。考虑汽车。五十年前，交通工具的状态很容易分割为子系统的状态（转向、传动、电力，...），而这些系统有最小的，即使有的话，交互。如今，这些系统都通过内部网络、传感器，和电子控制设备（“黑匣子”）来进行交互。这些交互使协作功能起作用，像刹车恢复，或自动并列停车。每个子系统的状态直接影响彼此的状态，并且因此现代交通工具的状态转移相互依赖得多。

系统工程的积极含义

因此，软件团体首次面临的问题 —— 解决状态空间的复杂性 —— 现在面对系统工程和设计团队了。类似的解决方案是适合的，这不令人惊奇。特别是，对象系统设计的目标是分割系统状态，从而达到软件设计中面临的同样的可维护性和可扩展性的目标。

当然，系统工程师必须比软件工程师考虑的更多，例如许多“能力”（可靠性、可行性、可用性、可服务性，...）以及所有权的总成本、能量消耗，等等。因此一种分解是不够的。虽然逻辑分解常常是必要的，但是对系统建模来说是不够的。这是我推荐从各种观点，以及连接的实现方法进行分解的理由。

查看本文来源