《系统架构:复杂系统的产品设计与开发》——第3章,第3.2节系统中的复杂度-阿里云开发者社区

开发者社区> 华章出版社> 正文

《系统架构:复杂系统的产品设计与开发》——第3章,第3.2节系统中的复杂度

简介:

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

3.2系统中的复杂度
3.2.1复杂度
如果系统中有很多互相关联、互相连接或互相混杂的实体与关系,那么该系统就是复杂的(complex)(参见文字框3.1)。笔者在当前所下的这个定义中,故意使用了一个含义较为模糊的词,那就是“很多”(many)。
文字框3.1 定义:复杂的系统


1f602152fd29417783ea8aa327112c39ef2e6a02

复杂的系统,是由很多高度相关、高度互联或高度混杂的元素或实体所组成的系统。
系统之所以变复杂,是因为我们对系统总是有“更多的要求”:要求系统有更多的功能、更好的性能,要求系统更加健壮、更加灵活。系统变复杂的另一个原因,在于我们要求本系统要能够与其他系统相互协作、相互连接,例如我们要把汽车与交通控制系统相连,要给屋子接入互联网,等等。
复杂的系统需要用大量的信息来指定并描述。因此,某些复杂度指标是根据系统的描述信息中所含的内容来制定的。此外,还有一些复杂度指标,想通过对系统所做的事情进行归类,来衡量系统的复杂性,这是基于功能的复杂度衡量法。
一个与复杂一词紧密相关的概念叫做难懂(complicated)。要认定某物是否难懂,应该考虑该物的复杂度是否超越了人类有限的观察和理解能力。第2章所说的那些系统都不难懂。我们只要研究几分钟,就可以较好地理解它们。难懂的事物具备较高的表面复杂度(apparent complexity)。它们之所以难懂,是因为其超出了人类的理解能力。
应对复杂度并不是新鲜的事情。实际上,在古罗马时代,人类就经常构建复杂的系统(例如大型的供水网络)。然而,在20世纪中,系统及其运作环境的复杂度出现了激增(对比一下1900年和2000年的电话)。这种极度攀升的复杂度几乎超越了我们对系统的理解能力。
架构师的工作是训练自己的思维,用它去理解复杂的系统,令那些系统不再那么难懂。我们应该努力构建易懂的架构,使得在该系统上工作的其他人员(例如设计者、构建者、操作者等)可以较为容易地理解这个系统。
设计一套良好的系统架构,实际上可以归结为:构建一套具备必要的复杂度同时又不难懂的系统。

3.2.2引入Team XT这一范例系统
本章以Team XT作为我们要分析的范例系统,该系统是针对第2章的Team X系统所做的扩展(extended,XT)版本。新团队的角色仍然是制作设计方案。对Team XT来说,Team X团队中的实体以及实体之间的关系同样有效,但是我们还要考虑更多的细节。笔者之所以选择一个较为复杂的组织作为研究案例,是因为许多读者可以把这种组织与自己工作时所在的组织联系起来,而且还可以把本章所述的系统思维经验,直接运用到这些组织中。
假设我们走进某公司的一间办公室,并结识了Team XT团队。那么,现在可以就运用第2章所说的方法,开始问第一个问题:“系统是什么?”这个问题的答案与第2章相同,Team XT系统也是由一组人员和一套过程所构成的,这套过程就是研发设计方案。接下来,我们要问该系统的形式是什么。对Team XT来说,其形式就是每位团队成员的总和。第三个问题是系统要完成什么功能。功能是指系统所要做的事情、活动或转换行为。Team XT系统的功能是研发设计方案。思考完这三个问题之后,我们就完成了系统思维的第一项任务(参见文字框2.3)


6eacc474d66048709a967de5e733fff24a988b99

从Team XT的形式上来看,如果我们认定其中的实体是各位团队成员,那就要通过仔细的观察、广泛的经验或是与每位成员进行谈话等手段,来确定这些实体各自的功能。我们把分析好的成员功能列在表3.1的第3列中。每一个功能都具备操作数与过程。根据第2章中所说的步骤,我们用整体思维(参见文字框2.5)把对系统可能有重要意义的实
表3.1 Team XT系统全图。该系统是Team X的扩展版,它的角色是研发一套工程设计方案


66bb7119b1fa94185f04a36f960572e41dce25f0


731343caa71c626539b5a8d7d6730a26f8ae7213

体全都找出来,然后划定系统边界(参见文字框2.6)


6a0695d61fdded03728b7775f497cf8a07c42a97

,以便将注意力集中在设计人员与设计过程上。这种划分方式把市场人员和操作人员所具备的功能放在了Team XT系统之外,使其成为大环境的一部分。在表3.1中,虚线以下的部分表示系统的外部环境。至此,我们完成了系统思维的第二项任务(参见文字框2.4)

348afd58702abfc4cccfa63aa32095f865cb238f


系统思维的第三项任务,是确定系统中的各实体之间的关系,以及系统内的实体与位于系统边界处的实体之间的关系。我们把与Team XT有关的人员之间的主要功能交互情况确定出来,并将其整理到表3.1中,这其中既包括团队成员的内部交互,也包括团队成员与团队外的市场人员和操作人员所做的跨边界交互。第4列描述了功能交互,第5列指出了位于交互关系另一端的人员。这些均显示在图3.1中。

图3.1 Team XT的功能及功能交互


b402bcd3550d6518674ecbbaab5d805168c6b712

表3.1最右方的那3列是形式结构。从地理位置上来看,某些团队成员在剑桥,其余的成员在莫斯科,这体现在右起第3列中。为了促进团队成员之间的交流,他们会使用一些软件工具及相关的数据库来进行沟通。这是一种连接关系,体现在右起第2列中。最右边的那一列呈现了一种报表式的结构。那些关系是人事关系,它们本身并不反映交互情况。形式关系可以分为很多种类,我们将在第4章中详细讲解。
系统思维的第四项任务是确定系统的涌现属性,下面几节将会讲解思考复杂系统所使用的工具,当我们选出适当的工具并将其运用到所要应对的系统之后,就可以更加清楚地判断它的涌现属性了。

版权声明:如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developerteam@list.alibaba-inc.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

华章出版社

官方博客
官网链接