《系统架构：复杂系统的产品设计与开发》——第3章，第3.3节系统的分解

本节书摘来自华章出版社《系统架构：复杂系统的产品设计与开发》一书中的第3章，第3.3节系统的分解，作者[美]布鲁斯·卡梅隆，更多章节内容可以访问云栖社区“华章计算机”公众号查看

3.3系统的分解
3.3.1分解
分解（decomposition）就是把实体分成小的部件或组成部分。在应对复杂度的诸多工具中，它是较为强大的一种。“分而治之”（divide and conquer）是一项基本策略，它把大问题持续分解成小问题，直到每一个小问题都能够解决为止。尤利乌斯•凯撒（Julius Caesar）在《高卢战记》的开头宣称“所有的高卢人都可以分成三个部分”，这并不是巧合，而是说明在古罗马时代，这种方略就已经得到深入研究和广泛运用了。
正如2.4节所述，有些系统是很容易分解的，例如那种由彼此不同的元素所构成的系统，分解起来就比较简单。如果系统是模块式的，那么分解起来就需要经过一番思考了。而对于整合式的系统来说，其分解方式则会显得有些武断。
把系统分解成部件的难点并不在于分解，而是体现在用分解出来的实体构建整个系统的这一过程上。这个过程通常称为整合（integration）。对于形式领域来说，整合就是把各部件所具备的形式聚合起来，在这一过程中，我们会担心这些元素在物理上或逻辑上是否能够合适地拼接在一起。对于功能领域来说，我们会把大功能分解成一些小的功能，然后把每个实体所具备的功能重新组合起来，在这一过程中，我们会遇到涌现物，这是真正的挑战所在。
我们现在开始分析Team XT。刚才说过，分解系统所用的方式，取决于系统元素的构成情况。如果系统在形式上由彼此不同的元素所构成，那我们就可以认为把Team XT团队按照成员进行分解是一种恰当的分解方式。但如果系统在形式上不是由彼此截然不同的元素所构成的，或是元素的形式尚未确定，那我们就更有可能会考虑按照功能来进行分解。这可能会得到与功能相关的一些实体（例如，转向机制、压缩机，以及排序算法，都可以按照功能分解为这样的一些实体）。具体到表3.1来说，其中有很多地方都表明，如果我们把注意力放在功能上，那就可能会得出一种与已有方式不同的分解方式。比如，我们发现Jose和Vladimir都具备“撰写需求文档”这一功能，于是我们就可以提出一种把Jose和Vladimir放在同一个实体内的分解方式。对我们理解系统涌现物来说，这种基于功能的分解方式，可能会更有帮助。

3.3.2体系
体系也是一种用来理解并思考系统复杂度的强大方法。体系（hierarchy）是一种其实体均处在某个层次或某个位阶的系统，这些层次是按照上下顺序排列起来的。社会系统中经常看到各种体系。比如，军队就是一种体系，其中有将军、上校、少校、上尉等不同的军阶。大公司也是个体系，可以分为总裁、执行副总裁及资深副总裁等不同的层次。
为什么有一些元素在体系中的位阶会比另外一些元素高呢？一般来说，有下面这几个原因：
这些元素所涉及的范围更广：例如州长比市长高，因为州长的行政范围比市长大（州比市大）。
这些元素的重要性较高或性能较强：例如黑带（black belt）选手比褐带（brown belt，茶带、棕带）选手高，因为他们的晋级标准更加严格，武艺也更加高强。
这些元素在功能上要承担更多的责任：例如总统比副总统高，因为总统的职责更大。
体系并非总是能够明确地展示我们想要的信息。即便仔细观察图3.1和表3.1，我们也依然不清楚Team XT的实际层级。各小组的组长和整个团队的经理，实际上都是为了交付有价值的设计方案而设立的，并不是单单为了评审其他人递交上来的工作，因此，我们不能仅仅通过图3.1和表3.1所展示的递交和评审关系来推断团队的实际层级。于是，我们还需要观察图3.2，这张图明确地展示了整个团队的体系。我们可以看到：Sue在Amy、John和Phil之上，而这三位小组长又处在团队的其他成员之上。这些内容是从表3.1最右侧那一列中的结构信息中提取出来的。图3.1给人的感觉是那些团队成员似乎都处在同一级别。而图3.2则呈现了一种分层的视图，使我们可以明确地看出：有一些团队成员在某种程度上要比其他成员更加重要。请注意，图3.2中的体系并不意味着某一层中的团队成员一定会向上一层汇报工作。工作汇报情况只有在做层级分解时，才能体现出来。

3.3.3层级分解
将分解与体系这两种手段结合起来，通常可以实现多层次的分解或层级化的分解，也就是可以实现像图3.3这样，大于两层的分解方式。图3.2中的中间那一层并没有体现出这三位小组长之间的区别，而图3.3则比较好，因为它使我们能够更加清晰地意识到这三位组长有着不同的分工。而且它还把每个节点所统领的下层节点数量限制在7个以内，使其不超越我们的认知能力（该上限可以左右浮动两个，位于5～9个）[1]。从图3.3中可以看出，三位小组长都向Sue汇报工作，而每位小组长所统领的四位组员都向该小组的组长汇报工作。
图3.3　对Team XT所做的层级分解

从表3.1和图3.2来看，“组”（group）是一种有用的抽象单元，但它并不是分解该团队的唯一方式。对于Sue以下的那些团队成员来说，我们可以用其他方式对其进行分解，包括按地理位置分解、按连接性分解或按功能关系分解等。实际上，图3.2既没有体现出这些团队成员彼此之间是否离得很近或是否有连接渠道（也就是说，没有展示出形式关系），也没有体现出某位成员是否会和另一位成员交换信息（也就是说，没有展示出功能关系）。

3.3.4简单的系统、复杂度适中的系统以及复杂的系统
按照一套特定的分类标准，本书将系统分成简单的系统、复杂度适中的系统，以及复杂度较大的系统（也就是复杂的系统）这三种类型。如果某系统像图3.4这样，只需分解一次即可将其完整地描述出来，那么它就是简单的系统。第2章所讲的那4个范例系统都是简单的系统，即便是太阳系，也只需要分解成由行星和更小的星体所组成的一层即可。对简单的系统进行分解之后，在分解出来的这一层中（也就是系统之下的第1层），其元素一般都不超过7个（该上限可以左右浮动两个）。而对这些元素进行研究时，我们则会发现：它们或多或少都是那种不便于继续分解的原子部件（参见3.3.5节）。

图3.4　对Team XT进行第一次分解

如果某个系统不是简单系统，但是经过两次分解之后，可以表示成图3.3这样的形式，使得每个上级部件所统领的下级部件都不超过7个（该上限可以左右浮动两个，这要求最底层的实体数量不能超过81个），那么这种系统就是复杂度适中的系统。
复杂的系统与复杂度适中的系统一样，也可以像图3.3这样进行分解，但是在系统下方的第2层中，仍然会有一些抽象的元素，这些元素还可以继续分解。这种系统分析起来更为困难，而它也比前两种系统更为常见。比如，假如Natasha本身还领导着一个专门负责拟定备选概念的小组，那么Team XT就由复杂度适中的系统变成复杂的系统了。
我们很少会看到分解深度超过两层的示意图。不使用这种示意图的原因有两个。首先，如果绘制三层分解的示意图，那么最底层的元素数量上限大约是73。由于7可以左右浮动2，因此这个上限可以位于53～93，按照93来算，最多可以有729个元素，这个数量远远超过了人类所能理解的范围。其次，我们在观察某个组织或系统时，对系统之下的第1层元素（也就是向该组织“直接汇报”的那些元素），一般都会了解得非常清楚，而对系统之下的第2层元素（该层中的元素会直接向第1层中的元素进行汇报），也会有着一定程度的了解，但是再往下看，就多少显得有些模糊了。
在分解系统时，笔者会把系统本身称为第0层（Level 0），把分解出来的那些层分别称为系统之下的第1层（Level 1（down））、系统之下的第2层（Level 2（down））等。第2章说过，每件事物几乎都可以当成系统来看待，因此，第0层究竟指代的是哪个系统还要由架构师的视点来确定。第0层系统之下的那些层，有很多种称呼方式，它们可以叫做模块（module）、配件（assembly）、子配件（sub-assembly）、函数或功能（function）、架（rack）、在线更换单元（Online Replacement Unit，ORU）、例程（routine）、委员会（committee）、工作组或任务组（task force）、单元（unit）、组件（component）、子组件（sub-component）、部件或部分（part）、区段（segment）、节（section）、章（chapter）等。称呼方式虽然有很多，但每一种称谓应该怎样使用并没有形成一致的意见。在另一个人看来，某个人所说的配件可能应该叫做部件才对。至于系统之上的那些层，其称呼方式则相对较少，有人将其称为系统的系统（system of system）、复合体（complex）或集合（collection）。本书在提到系统之上的那些层时，会采用系统之上的第1层（Level 1（up））、系统之上的第2层（Level 2（up））等说法。

3.3.5原子部件
我们刚才说的那种归类方式，某种程度上要依赖于“原子部件”（atomic part）这一概念，而该词并没有精确的定义。它的含义源自希腊语的（转写成拉丁字母是atomos）一词，原意是不可分之物（indivisible）。在机械系统中，我们把那种不能轻易“拆解”的部件假定为原子部件。按照这种定义方式，人、螺丝及处理器芯片都是原子部件。处理器芯片当然也包含很多对架构起着重要作用的内部细节。比如，其中有哪些类型的晶体管和逻辑门，这些类型的电子元器件分别有多少个，以及它们是如何连接起来的，等等。即便是一枚简单的螺丝，也含有一些架构方面的重要细节。比如，它是一字头（straight head）还是十字头（也称为菲利普头，Phillips head）等。由此看来，刚才所设想的那种定义方式似乎有些不够清晰，但我们可以把握一条简单的规则，那就是：不能拆解的东西都可以叫做原子部件。
在信息系统中，“原子部件”这个定义就显得更模糊了。有一种办法可以判断出某物应不应该称为原子部件，那就是看该物是不是像单词或指令那样具备语义含义（semantic meaning），或者不是一种数据或信息单元。这些单词、指令或数据单元本身当然也包含各种细节。由于所有的信息都是一种抽象（第4章将讲述这一点），因此想在本身就比较抽象的信息上再抽象出一个针对原子部件的有效定义，就必然会显得非常模糊。不过与机械系统一样，分析信息系统时，也可以把握这样一条简单的规则：凡是一经拆解就失去意义的东西，都可以称为原子部件。