封底
从电网的架构到移动支付系统的架构，很多领域都出现了系统架构的思维。架构是系统的DNA，也是形成竞争优势的基础所在。那么，系统的架构到底是什么？它又有什么功能？
本书阐述了架构思维的强大之处，目标是帮助系统架构师规划并引领系统开发过程中的早期概念性阶段，为整个开发、部署、运营及演变的过程提供支持。为了达成上述目标，本书会帮助架构师：
在产品所处的情境与系统所处的情境中使用系统思维。
分析并评判已有系统的架构。
指出架构决策点，并区分架构决策与非架构决策。
为新系统或正在进行改进的系统创建架构，并得出可以付诸生产的架构成果。
从提升产品价值及增强公司竞争优势的角度来审视架构。
通过定义系统所处的环境及系统的边界、理解需求、设定目标，以及定义对外体现的功能等手段，来厘清上游工序中的模糊之处。
为系统创建出一个由其内部功能及形式所组成的概念，从全局的角度对这一概念进行思考，并在必要时运用创造性思维。
驾驭系统复杂度的演化趋势，并为将来的不确定因素做好准备，使得系统不仅能够达成目标并展现出功能，而且还可以在设计、实现、运作及演化过程中一直保持易于理解的状态。
质疑并批判地评估现有的架构模式。
指出架构的价值所在，分析公司现有的产品开发过程，并确定架构在产品开发过程中的角色。
形成一套有助于成功完成架构工作的指导原则。

前
本书由系统架构领域3位领军人物亲笔撰写，该领域资深专家Norman R. Augustine作序推荐，Amazon全五星评价。
全书共分四部分。第一部分（第1~3章）的重点是引出系统架构。第1章通过一些范例来展示架构理念，指出良好的架构，并给出本书的概要；第2章列出进行系统分析必备的思路；第3章给出分析系统架构所用的思维模式。第二部分（第4~8章）着重对架构进行分析。第4章讨论系统的形式；第5章讨论系统的功能；第6章讲解形式与功能之间的映射，并以此给出系统架构的定义；第7章研究如何从独立于解决方案的功能陈述中衍生出系统；第8章演示怎样把这些概念汇聚成一套架构。第三部分（第9~13章）讲解如何为复杂的系统定义架构。第9章从任务和可交付成果这两方面来概述架构师的职责；第10章探讨如何把组织机构方面的接口当成在架构中减少歧义的契机；第11章讲述如何用系统化的方式来捕获利益相关者的需求，并把它们转换成系统目标；第12章提出一些能够帮助架构师更有创意地构思并选择概念的手段；第13章讲述在开发系统时管理复杂度的一些办法。第四部分（第14~16章）探寻帮助架构师做决策的各种计算方法及工具所具备的潜力。第14章把系统架构的过程当成一种决策制定的过程来进行讲解；第15章讲解如何对架构权衡空间中的信息进行综合；第16章演示怎样把架构决策编码成一套模型，使计算机可以根据该模型自动生成权衡空间并对其进行探索。

后
Edward Crawley　是俄罗斯莫斯科斯科尔科沃科学与技术学院的校长，也是麻省理工学院航空航天学及工程系统学教授。他从麻省理工学院获得航空与航天专业的学士学位及硕士学位，并获得航空航天结构专业的博士学位。Crawley教授是美国航天航空学会及英国皇家航空学会的会员，也是瑞典皇家工程科学院、英国皇家工程学院、中国工程院及美国国家工程院的成员。

Bruce Cameron 是咨询公司Technology Strategy Partners的创始人，也是MIT System Architecture Lab的董事。Cameron博士从多伦多大学获得学士学位，从麻省理工学院获得硕士学位。Cameron博士在麻省理工学院的斯隆管理学院及工程学院讲授系统架构与技术策略课程，是多伦多大学董事会的前成员。

Daniel Selva　是康奈尔大学机械与航天工程系的副教授。他从加泰罗尼亚大学、法国国立高等航空航天学院及麻省理工学院获得电气工程与航空工程学位。Selva教授的研究重点是在设计活动的初期运用系统架构、知识工程与机器学习工具。他的研究成果运用于NASA的地球科学十年调查、Iridium GeoScan Program及NASA的跟踪与数据中继卫星系统等项目。在这些项目中，他利用架构分析技术来为系统架构师和管理者提供支持。

我们写这本书，是为了阐述一种强大的思想。越来越多的人已经开始有了这种思想，这就是“系统的架构”（architecture of a system）。从电网的架构到移动支付系统的架构，很多领域都出现了系统架构的思维。架构就是系统的DNA，也是形成竞争优势的基础所在。拥有系统架构师这一头衔的专业人士，现在已经超过10万人，此外还有更多的人以其他身份参与架构工作。
对于强大的思想，其边界一般都比较模糊。我们发现许多同事、客户和同学都能够意识到系统架构问题，但他们对这个词的用法有所区别。这个词一般用来区分两个已有的系统，例如“这两种山地自行车的架构不同”。
系统的架构到底是由什么组成的？这个话题通常会引发巨大的争论。在某些领域中，架构用来指代一项能够在抽象层面上区分两类系统的决策，例如“封包交换的架构”（packet-switched architecture）与“电路交换的架构”（circuit-switched architecture）。而在另外一些领域中，这个词则用来在忽略某些小细节的情况下描述整体的实现，例如“我们的软件是用来充当服务架构的”。
我们的目标是阐述架构思维的强大之处，并且使其边界变得更加明晰。架构思维的强大，源自它能够使我们在项目的早期阶段权衡各种架构、展望后续的发展情况，并发现各种约束以及对提升项目价值较为重要的机遇。如果架构把全部细节都包括进去，那么我们就无法在各种粗略的想法之间轻易跳跃，但如果架构中缺少了重要的价值驱动力，那它又显得没有意义。
我们写本书时所持有的理念与Eberhardt Rechtin相同，都认为架构师应该是专才，而非通才。我们想在书中描述系统架构的分析与构建过程，也想展示系统架构的“科学性”。与产品设计规范相比，本书的措辞在某种程度上较为宽松一些，因为我们要处理的系统更加复杂。产品研发人员所重视的是设计问题，而我们要强调的则是系统中的各个部件如何才能凝聚成一个连贯的整体，我们重视的是这个奇妙的涌现过程。
我们把过去的经验融入了本书中。我们有幸参与了许多复杂系统的早期研发工作，这些系统遍布通信、运输、移动广告、财经、机器人、医疗设备等各个领域，其复杂程度也各有不同，从农具到国际空间站，我们都接触过。
此外，书中的案例研究还涉及混合动力车（hybrid car）及商用飞机（commercial aircraft）等其他领域的系统架构师所总结出的一些经验。我们认为，本书必须要能够应对当前系统架构师所面临的各项挑战，因为只有这样，才能推进系统架构的发展。
本书的核心受众有两类人，一类是专业的架构师，另一类是工程学的学生。系统架构这一理念，是相关行业的从业者从实践和尝试中得来的，这些从业者运用自身的智慧，试着总结出一些经验，以应对研发新系统时所面临的挑战。本书的一部分目标读者是进行架构决策的资深专业人士。这些专业人士包括高级技术人员，也包括软件、电子、工业用品、航空、汽车及消费用品等科技产业中的管理人员。
本书的另一部分目标读者是工程学的学生。本书是根据过去15年间我们在麻省理工学院讲授研究生课程时的教学经验而写成的，其中有很多学生后来成了私人企业和政府部门中的佼佼者，对此我们深感荣幸。架构思维不仅可以帮助我们理解系统当前的运作方式，而且对于科技组织的管理来说，这也应该是一项必备的能力。

计算机\软件工程

从电网的架构到移动支付系统的架构，很多领域都出现了系统架构的思维。架构就是系统的DNA，也是形成竞争优势的基础所在。那么，系统的架构到底是什么？它又有什么功能？
本书阐述了架构思维的强大之处，目标是帮助系统架构师规划并引领系统开发过程中的早期概念性阶段，为整个开发、部署、运营及演变的过程提供支持。为了达成上述目标，本书会帮助架构师：
 在产品所处的情境与系统所处的情境中使用系统思维。
 分析并评判已有系统的架构。
 指出架构决策点，并区分架构决策与非架构决策。
 为新系统或正在进行改进的系统创建架构，并得出可以付诸生产的架构成果。
 从提升产品价值及增强公司竞争优势的角度来审视架构。
 通过定义系统所处的环境及系统的边界、理解需求、设定目标，以及定义对外体现的功能等手段，来厘清上游工序中的模糊之处。
 为系统创建出一个由其内部功能及形式所组成的概念，从全局的角度对这一概念进行思考，并在必要时运用创造性思维。
 驾驭系统复杂度的演化趋势，并为将来的不确定因素做好准备，使得系统不仅能够达成目标并展现出功能，而且还可以在设计、实现、运作及演化过程中一直保持易于理解的状态。
 质疑并批判地评估现有的架构模式。
 指出架构的价值所在，分析公司现有的产品开发过程，并确定架构在产品开发过程中的角色。
 形成一套有助于成功完成架构工作的指导原则。

[美] 爱德华·克劳利（Edward Crawley) ,布鲁斯·卡梅隆（Bruce Cameron），丹尼尔·塞尔瓦（Daniel Selva) 著：暂无简介

爱飞翔　译：暂无简介

系统和系统架构，是两个让人觉得既熟悉又模糊的词语。说熟悉，是因为很多领域都频繁地提到它们；说模糊，则是因为不同的领域和不同的人，对这两个词的定义及范围，都有着不同的理解。而本书正是要从各领域对系统架构的理解和构建中，总结出一套共识，使大家能够更为清晰地看到复杂的产品在研发策略方面所体现出的共性。
本书第一部分讲解了什么是系统，其中主要强调整体思维的作用，并强调系统的整体功能必须大于各部件的功能之和。多出来的这些功能，就称为涌现物。
为了使系统涌现出良好的功能，我们需要对它进行分析。于是，第二部分就从形式和功能这两个方面讲解了如何分析系统，并且把系统架构这个概念描述为对形式和功能之间的映射关系所做的分配，同时，还强调了各部件之间的交互以及本系统与周边环境之间的互动。这些问题对于系统的价值来说至关重要。
在明确了系统和系统架构的含义之后，第三部分开始讲解如何创建良好的系统架构。产品上游和下游的影响因素，以及利益相关者所提出的各种需求，都是架构师必须要考虑的问题，因此，第11章开头给出了一套思维框架，使我们可以把庞杂的需求转化为凝练的目标，并确定这些目标之间的先后次序。接下来，讨论了怎样把这些目标汇聚成与特定解决方案无关的概念。之所以要先把特定的解决方案抛开，是为了使架构师能够把抽象的概念细化为多个片段，并运用创造力来探索它们的各种实现及组合方式，然后把那些能够满足客户需求的方式逐渐演化为具体的架构。由于很多系统本质上是非常复杂的，因此，在把概念演化为架构的过程中，架构师需要对系统进行分解，以看清这些组件的结构以及它们之间的交互情况。
同一个组件可能有多种实现方式，而组件之间的布局及交互情况，也是多种多样的，这就需要我们对其中较为关键的几个决策点做出选择。于是，第四部分从决策角度探讨系统架构。对每一个这样的架构决策来说，各选项之间的搭配方式可能极为繁多，因此，为了进行定量分析，我们需要根据一些衡量指标来构建权衡空间，并把各种候选架构都展示在该空间中的对应坐标上，以便使用优化算法找出优势较大的架构。
以上四个部分就是全书的主线。作者把系统架构的分析和综合过程中所提到的相关理念，总结成了20多条架构原则，使我们可以在系统架构的各环节中把握住重点，这也是本书的一个特色。它的另外一个特色在于：作者对照建筑学中的模式语言，以及软件开发中的设计模式，把各种架构决策问题也归纳成6种模式，使架构师能够在不同的工作场景中选用合适的模式及算法来对这些问题进行程序化的处理。
本书提供了丰富的架构展示方法和架构分析公式，也给出了适用面较为广泛的原则和模式，在面对具体的项目时，我们应该根据自己的经验和判断力，灵活地运用这些工具。
翻译过程中，我得到了机械工业出版社诸位编辑和工作人员的帮助，在此深表感谢。
由于译者水平有限，错误与疏漏之处，请大家发邮件至eastarstormlee@gmail.com，或访问github.com/jeffreybaoshenlee/zh-translation-errata-sysarch/issues留言，给我以批评和指正。

在医疗健康领域中，有一种趋势特别有前途，这就是生物医学研究与工程实践的结合。我有一位朋友是工程师，他最近告诉我，美国一家知名大学曾经开了这样一个会，工程系与心脏病学科系的教研人员，在会上探讨了这两种学科的结合方式。会议的重点是构建一颗可供人类使用的机械心脏，心脏病学科系的主管刚开始描述人类心脏的各项特征，就有工程师打断他，并问道：“机械心脏必须放在胸腔中吗？有没有可能放在其他更容易够到的地方？例如大腿中？”开会的人以前从来没考虑过这种可能。主管接着描述心脏的特征，但是过了一会儿，又有另一个工程师打断他，并提问：“能不能不要只放一个心脏，而是把三颗或四颗心脏组合成分布式系统？”这个问题，也是大家从未考虑过的。
本书由系统架构领域内三位备受崇敬的领军人物撰写，他们的观点很有见地。书中讨论的就是如何提出并回答上面那样的问题。我在工作中曾经碰到工程、商务、政府等方面的各种系统架构问题，当运用系统架构领域中的一些经验来解决这些问题时，我发现结果会好很多。
然而，单单运用这些经验是不够的。刚开始工作时，我记得自己总是问同事各种问题。当时我们正在“合作”完成一个导弹项目，我问他们为什么要采用某种特定的方式来设计产品的某个部件。有人给出的原因是“这种设计方式重量最轻”，有人说他设计的那一部分雷达横截面（radar cross-section）最小，还有人说自己设计的那个部件成本低、体积小，等等。
这些理由都不错，可是其中缺了一样东西。那就是系统架构师（system architect）。
系统架构师的缺位很常见，但表现方式一般比较微妙。几年前，我曾经参与了近音速运输机（Near-Sonic Transport aircraft）的早期研发工作。一份市场调查表明，乘客想要更快地到达目的地。近音速运输的理念，就是想使速度尽量接近音速（也就是接近1马赫，1马赫≈1225km/h），但又不超过它，以避免超过音速之后所引发的各种问题。然而空气动力学者（我早前的研究领域就是空气动力学）发现：这样做使得飞机在阻力曲线上会进入一个耗油量陡增的区域。
从系统架构的观点来看，我们要解决的问题并不是怎样飞得更快，而是如何缩短乘客从家中到机场、办理登机手续、过安检、上飞机、飞行、落地后取行李并驶往最终目标所需的总时间。把这个问题放在刚才那个情境中考虑，我们就会发现，更基本的问题其实应该是：节省这5分钟或10分钟的飞行时间，究竟能给乘客带来多大的好处？答案是：带不来多大好处。因此，这项近音速运输机计划就提前终止了。如果我们想使乘客更快地到达目的地，那么显然还有其他更好的方案可供探索。这个项目之所以失败，是因为大家没有意识到自己正在处理的是系统架构问题，而不单单是空气动力学或飞机设计方面的问题。
这些年来，我一直在不断地完善自己对“系统”这个词所下的定义。系统是“可以交互的两个或多个元素”，而本书作者又明智地补充了一点，那就是系统的功效必须大于各自元素的功效之和。尽管在概念层面很简单，但是现实世界中的系统相当复杂。实际上，对于由若干元素所构成的（而且这些元素之间都以最简单的方式来交互）系统来说，描述其可能具备的状态数量所用的那个公式非常吓人，有“怪兽公式”之称。此外，很多系统里面还有人的因素在内，如果系统里面还包括人，那么系统架构所面临的困难就会更大，因为人的因素会带来不确定性。我们在现实中遇到的就是这种系统，本书作者要分析和解决的架构问题，也针对的是这种系统。
我曾经分析过这样一个给美国南极站进行补给的系统。与其他系统一样，我需要非常谨慎地设定具体的评估目标。是要缩减在可以预期的状况下所产生的消耗，还是要减少在无法预期的最差状况（例如糟糕的天气）下所产生的消耗？又或者是要尽量避免在补给品根本无法送达时所发生的那些“令人遗憾的”状况？可以考虑的目标还有很多。
在这个系统中，有很多个必须互相配合的元素，例如运输船、破冰船、各种飞机、用于卸货的冰码头、存储设施、交通工具、通信等。而且在做各种决策时，还要考虑架构中一直可能会发生的一种危险，那就是单点故障。
我还在商务领域中遇到了一个比刚才更复杂的问题，那就是能不能把7家公司的所有部门或主要部门，合并为洛克希德·马丁公司，如果能，应该如何去做。这个系统中的每个“元素”都有其优缺点，每个都涉及很多人，都有自己的目标、能力和局限性。这项决策的关键在于，合并之后的新公司，其效能是否远远高于原有那些部分各自的效能总和。如果做不到这一点，那就没有理由耗费资金去进行合并与收购了。
对于这一类复杂问题来说，并没有简单的数学公式能够给出“正确”答案。然而，系统思维（systems thinking）的训练是一项极为有用的工具，可以帮助我们去评估系统的观感、系统中潜藏的机遇以及系统对参数的敏感程度等。在刚才那个企业合并的案例中，大多数人都认为合并是“对的”，顺便说一下，在相似的案例中，有80%的情况也是如此。
我与本书的一位作者及其他同事，曾经向美国总统提出一项载人航天计划，这项计划是为将来的几十年而制定的。在这个案例中，最困难的地方是怎样合理地定义任务（mission），虽说确定适当的硬件配置也是个不小的工作，但与前者比起来，难度还是要低一些。所幸这种问题都可以通过系统思维来解决。
正如作者在书中所说的那样，系统架构的建立过程，既是科学，又是艺术。尽管这听起来很美好，但现实相当残酷。与达尔文式的物种进化现象一样，用过去的错误架构所搭建出来的系统是无法生存的；反之，用良好的架构所搭建的系统不仅可以生存，而且会越来越好。
所谓复杂系统的架构，也就是这么一回事。

系统架构原则
译者序
推荐序
前言
致谢
作者介绍
第一部分系统思维
第1章　系统架构简介 …… 2
1.1　复杂系统的架构 …… 2
1.2　良好架构的优势 …… 2
1.3　学习目标 …… 5
1.4　本书结构 …… 6
1.5　参考资料 …… 7
第2章　系统思维 …… 8
2.1　简介 …… 8
2.2　系统与涌现 …… 8
2.2.1　系统 …… 8
2.2.2　涌现 …… 10
2.3　任务一：确定系统及其形式与功能 …… 13
2.3.1　形式与功能 …… 13
2.3.2　工具-过程-操作数：这是人类的标准思维模式吗 …… 16
2.4　任务二：确定系统中的实体及其形式与功能 …… 16
2.4.1　具备形式与功能的实体 …… 17
2.4.2　确定如何将系统初步分解为恰当的实体 …… 18
2.4.3　用整体思维找出系统中的潜在实体 …… 19
2.4.4　集中注意力，找出系统中的重要实体 …… 21
2.4.5　为实体创建抽象或从实体中发现抽象 …… 22
2.4.6　定义系统的边界，并将其与外围环境隔开 …… 24
2.5　任务三：确定实体之间的关系 …… 25
2.5.1　关系的形式与功能 …… 25
2.5.2　外部接口 …… 28
2.6　任务四：涌现 …… 28
2.6.1　涌现的重要性 …… 28
2.6.2　系统故障 …… 29
2.6.3　预测涌现物 …… 30
2.6.4　涌现物依赖于实体及其关系 …… 31
2.7　小结 …… 32
2.8　参考资料 …… 33
第3章　思考复杂的系统 …… 34
3.1　简介 …… 34
3.2　系统中的复杂度 …… 34
3.2.1　复杂度 …… 34
3.2.2　引入Team XT这一范例系统 …… 35
3.3　系统的分解 …… 38
3.3.1　分解 …… 38
3.3.2　体系 …… 39
3.3.3　层级分解 …… 39
3.3.4　简单的系统、复杂度适中的系统以及复杂的系统 …… 41
3.3.5　原子部件 …… 42
3.4　特殊的逻辑关系 …… 43
3.4.1　类/实例关系 …… 43
3.4.2　特化关系 …… 43
3.4.3　递归 …… 44
3.5　对复杂系统进行思索 …… 44
3.5.1　自顶向下及自底向上式的思考 …… 44
3.5.2　交替思考 …… 45
3.6　架构展示工具：SysML与OPM …… 45
3.6.1　视图与投射 …… 45
3.6.2　SysML …… 46
3.6.3　OPM …… 46
3.7　小结 …… 49
3.8　参考资料 …… 50
第二部分　系统架构的分析
第4章　形式 …… 53
4.1　简介 …… 53
4.2　架构中的形式 …… 53
4.2.1　形式 …… 53
4.2.2　用解析表示法来表现形式：对象 …… 56
4.2.3　形式的分解 …… 57
4.3　对架构中的形式进行分析 …… 58
4.3.1　定义系统 …… 58
4.3.2　确定形式实体 …… 59
4.3.3　把泵作为复杂度适中的系统来分析 …… 61
4.4　对架构中的形式关系进行分析 …… 63
4.4.1　形式关系 …… 63
4.4.2　空间/拓扑形式关系 …… 65
4.4.3　用图和图表来展现形式关系：OPM …… 67
4.4.4　用表格及类似矩阵的视图来展现形式关系：DSM …… 70
4.4.5　连接性的形式关系 …… 71
4.4.6　其他的形式关系 …… 74
4.5　形式环境 …… 75
4.5.1　伴生系统、整个产品系统及系统边界 …… 75
4.5.2　使用情境 …… 77
4.6　软件系统中的形式 …… 77
4.6.1　软件系统：信息形式及其二元性 …… 77
4.6.2　软件中的形式实体与形式关系 …… 79
4.6.3　软件系统所在的整个产品系统、软件系统的边界及使用情境 …… 81
4.7　小结 …… 82
4.8　参考资料 …… 82
第5章　功能 …… 83
5.1　简介 …… 83
5.2　架构中的功能 …… 84
5.2.1　功能 …… 84
5.2.2　把功能视为过程加操作数 …… 84
5.2.3　用解析表示法来展现功能 …… 85
5.3　分析对外展现的功能和价值 …… 89
5.3.1　对外界展现的主要功能 …… 89
5.3.2　与价值有关的操作数 …… 90
5.4　对内部功能进行分析 …… 93
5.4.1　内部功能 …… 93
5.4.2　确定内部功能 …… 94
5.5　分析功能交互及功能架构 …… 97
5.5.1　功能交互与功能架构 …… 97
5.5.2　确定功能交互 …… 98
5.5.3　价值通路 …… 100
5.5.4　涌现与细分 …… 101
5.5.5　软件系统中的功能架构 …… 102
5.6　与价值相关的次要外部功能及内部功能 …… 105
5.7　小结 …… 106
5.8　参考资料 …… 107
第6章　系统架构 …… 108
6.1　简介 …… 108
6.2　系统架构：形式与功能 …… 109
6.2.1　形式与功能之间的映射 …… 109
6.2.2　确定形式与过程之间的映射 …… 114
6.2.3　形式结构承载并展现功能交互 …… 116
6.2.4　确定形式结构是如何承载功能和性能的 …… 118
6.3　系统架构中的非理想因素、支持层及接口 …… 119
6.3.1　系统架构中的非理想因素 …… 119
6.3.2　系统架构中的支持功能及支持层 …… 120
6.3.3　形式与功能中的系统接口 …… 121
6.4　操作行为 …… 123
6.4.1　操作者 …… 124
6.4.2　行为 …… 124
6.4.3　操作成本 …… 126
6.5　用各种表示法来推究系统架构 …… 127
6.5.1　能够对系统架构进行简化的几种方式 …… 127
6.5.2　用投射法来表示系统的架构 …… 128
6.5.3　把过程投射到对象 …… 129
6.5.4　把过程和操作数投射到形式 …… 130
6.6　小结 …… 133
6.7　参考资料 …… 134
第7章　与特定解决方案无关的功能和概念 …… 135
7.1　简介 …… 135
7.1.1　正向工程与更加复杂的系统 …… 135
7.1.2　对与特定解决方案无关的功能和概念所做的介绍 …… 136
7.2　确定与特定解决方案无关的功能 …… 138
7.3　概念 …… 140
7.3.1　作为一种观念的概念 …… 140
7.3.2　对概念构想有所帮助的框架 …… 142
7.3.3　构想概念时所应依循的步骤 …… 144
7.3.4　为概念命名 …… 145
7.3.5　对候选的概念进行整理 …… 146
7.3.6　由更为广阔的概念所形成的体系 …… 150
7.4　整体概念 …… 152
7.5　操作概念与服务概念 …… 156
7.6　小结 …… 158
7.7　参考资料 …… 159
第8章　从概念到架构 …… 160
8.1　简介 …… 160
8.2　研发系统之下第1级的架构 …… 161
8.2.1　把概念扩展为功能架构 …… 161
8.2.2　定义形式 …… 162
8.2.3　把功能映射为形式 …… 164
8.3　研发系统之下第2级的架构 …… 166
8.3.1　第2级的功能意图以及对第2级所做的递归思考 …… 166
8.3.2　研发第2级中的架构 …… 166
8.4　家庭数据网络系统的第2级架构 …… 170
8.5　为系统之下的第1级架构做模块化处理 …… 173
8.6　小结 …… 176
8.7　参考资料 …… 177
第三部分　创建系统架构
第9章　架构师的角色 …… 180
9.1　简介 …… 180
9.2　歧义与架构师的角色 …… 180
9.2.1　架构师的角色 …… 180
9.2.2　减少歧义 …… 182
9.2.3　架构师可以交付的成果 …… 185
9.3　产品开发过程 …… 186
9.3.1　各企业所使用的PDP之间的异同 …… 187
9.3.2　通用的产品开发过程 …… 191
9.4　小结 …… 195
9.5　参考资料 …… 199
第10章　上游和下游对系统架构的影响 …… 200
10.1　简介 …… 200
10.2　上游的影响因素：公司策略 …… 201
10.3　上游的影响因素：营销 …… 204
10.3.1　内向营销 …… 205
10.4　上游的影响因素：法规及类似法规的因素 …… 207
10.4.1　法规的来源 …… 208
10.4.2　与法规类似的因素：可能出台的法规、标准和法律责任 …… 209
10.5　上游的影响因素：技术融合 …… 210
10.6　下游的影响因素：实现—编码、制造及供应链管理 …… 212
10.7　下游的影响因素：操作 …… 214
10.7.1　系统的登场与退场 …… 215
10.7.2　偶发操作、应急操作与独立操作 …… 216
10.8　下游的影响因素：Design for X …… 216
10.9　下游的影响因素：产品与系统的演化、产品系列 …… 218
10.9.1　复用与遗留元素 …… 219
10.9.2　产品系列 …… 220
10.9.3　平台与架构 …… 221
10.10　产品论证：架构商业论证决策框架（ABCD） …… 224
10.11　小结 …… 226
10.12　参考资料 …… 229
第11章　将需求转换为目标 …… 231
11.1　简介 …… 231
11.2　确定受益者和利益相关者 …… 232
11.2.1　受益者和利益相关者 …… 232
11.2.2　确定受益者和利益相关者的需求 …… 235
11.2.3　从交换中确定利益相关者及其需求 …… 238
11.2.4　对利益相关者进行分组 …… 240
11.3　描述需求的特征 …… 242
11.3.1　从各种维度来描述利益相关者的需求 …… 242
11.3.2　将利益相关者作为系统：间接的价值交付及利益相关者关系图 …… 244
11.3.3　在各个利益相关者的需求之间排定优先次序 …… 247
11.3.4　对排列各需求的优先次序所做的小结 …… 251
11.4　把需求转换为目标 …… 252
11.4.1　设定目标时所依据的标准 …… 253
11.4.2　人类可以解决的目标：系统问题陈述 …… 255
11.5　排列目标之间的优先次序 …… 259
11.5.1　具备一致性与可达成性的目标 …… 262
11.6　小结 …… 263
11.7　参考资料 …… 270
附：对利益相关者提出的系统需求所进行的特征分析 …… 271
第12章　用创造力生成概念 …… 272
12.1　简介 …… 272
12.2　对概念进行创新 …… 273
12.2.1　创新 …… 273
12.2.2　无结构的创新 …… 274
12.2.3　结构化的创新 …… 274
12.2.4　确定概念 …… 277
12.3　提出概念 …… 278
12.4　扩充概念并提出概念片段 …… 279
12.4.1　对推进功能进行扩充 …… 279
12.4.2　混合动力车的另外7个内部功能所对应的概念片段 …… 282
12.5　演化并完善整体概念 …… 285
12.6　选出几个整体概念，做进一步的发展 …… 288
12.7　小结 …… 291
12.8　参考资料 …… 295
第13章　把分解作为复杂度管理工具来使用 …… 296
13.1　简介 …… 296
13.2　理解复杂度 …… 296
13.2.1　复杂度 …… 296
13.2.2　复杂与难懂 …… 299
13.2.3　必要的复杂度 …… 301
13.3　管理复杂度 …… 305
13.3.1　选定分解方式 …… 305
13.3.2　模块化程度与分解 …… 308
13.4　小结 …… 312
13.5　参考资料 …… 317
第四部分　作为决策的架构
第14章　作为决策制定过程的系统架构 …… 321
14.1　简介 …… 321
14.2　对阿波罗计划的架构决策问题进行公式化处理 …… 322
14.2.1　做决策时可以考虑的经验法则 …… 322
14.2.2　阿波罗计划的决策 …… 323
14.2.3　约束及衡量指标 …… 325
14.2.4　计算各种阿波罗架构的得分 …… 327
14.3　决策与决策支持 …… 328
14.4　决策支持系统的四项主要任务 …… 330
14.5　基本的决策支持工具 …… 331
14.5.1　形态矩阵 …… 332
14.5.2　设计结构矩阵 …… 332
14.5.3　决策树 …… 334
14.6　为系统架构提供决策支持 …… 338
14.7　小结 …… 339
14.8　参考资料 …… 340
第15章　探求架构的权衡空间 …… 343
15.1　简介 …… 343
15.2　权衡空间的基本知识 …… 344
15.3　帕累托前沿 …… 347
15.3.1　帕累托前沿与占优 …… 347
15.3.2　GNC范例系统的帕累托前沿 …… 348
15.3.3　模糊的帕累托前沿及其好处 …… 351
15.3.4　在模糊的帕累托前沿上挖掘数据 …… 352
15.3.5　帕累托前沿的运用机理 …… 354
15.4　权衡空间的结构 …… 355
15.5　敏感度分析 …… 359
15.6　整理架构决策 …… 364
15.6.1　对其他决策的影响 …… 364
15.6.2　对衡量指标的影响 …… 366
15.6.3　决策空间视图 …… 367
15.6.4　对决策进行排序 …… 368
15.6.5　对决策及其顺序的总结 …… 370
15.7　小结 …… 371
15.8　参考资料 …… 372
第16章　系统架构优化问题的表述与求解 …… 374
16.1　简介 …… 374
16.2　对系统架构优化问题进行表述 …… 375
16.3　NEOSS范例：NASA的地球观测卫星系统 …… 379
16.4　系统架构决策中的模式 …… 381
16.4.1　从程序化的决策到模式 …… 382
16.4.2　DECISION-OPTION模式 …… 383
16.4.3　DOWN-SELECTING模式 …… 386
16.4.4　ASSIGNING模式 …… 389
16.4.5　PARTITIONING模式 …… 395
16.4.6　PERMUTING模式 …… 399
16.4.7　CONNECTING模式 …… 402
16.5　对大规模的系统架构问题进行表述 …… 406
16.5.1　模式之间的重合 …… 407
16.5.2　把问题分解为子问题 …… 409
16.6　解决系统架构优化问题 …… 410
16.6.1　介绍 …… 410
16.6.2　全因子排列 …… 411
16.6.3　启发式的架构优化算法 …… 412
16.6.4　基于种群的通用启发式优化 …… 413
16.6.5　生成初始种群 …… 414
16.6.6　把某些固定的架构包含在初始种群中 …… 415
16.6.7　通用的启发式和元启发式高效搜索 …… 416
16.6.8　遗传算法中的启发式策略 …… 416
16.6.9　用更多的启发式技术来强化遗传算法 …… 418
16.7　小结 …… 419
16.8　参考资料 …… 420
附录A根据所选的架构集来计算衡量指标对决策的敏感度 …… 423
附录B聚类算法及其在系统架构中的运用 …… 425
附录C基于规则的系统及其在系统架构中的应用 …… 430
附录D经典的组合优化问题 …… 436
各章问题 …… 441