软件架构--《系统架构：复杂系统的产品设计与开发》笔记

1 简介

1.1 内容简介

本书由系统架构领域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章演示怎样把架构决策编码成一套模型，使计算机可以根据该模型自动生成权衡空间并对其进行探索。

1.2 作者介绍

• Edward Crawley是俄罗斯莫斯科斯科尔科沃科学与技术学院的校长，也是麻省理工学院航空航天学及工程系统学教授。他从麻省理工学院获得航空与航天专业的学士学位及硕士学位，并获得航空航天结构专业的博士学位。Crawley教授是美国航天航空学会及英国皇家航空学会的会员，也是瑞典皇家工程科学院、英国皇家工程学院、中国工程院及美国国家工程院的成员。
• Bruce Cameron是咨询公司Technology Strategy Partners的创始人，也是MIT System Architecture Lab的董事。Cameron博士从多伦多大学获得学士学位，从麻省理工学院获得硕士学位。Cameron博士在麻省理工学院的斯隆管理学院及工程学院讲授系统架构与技术策略课程，是多伦多大学董事会的前成员。
• Daniel Selva是康奈尔大学机械与航天工程系的副教授。他从加泰罗尼亚大学、法国国立高等航空航天学院及麻省理工学院获得电气工程与航空工程学位。Selva教授的研究重点是在设计活动的初期运用系统架构、知识工程与机器学习工具。他的研究成果运用于NASA的地球科学十年调查、Iridium GeoScan Program及NASA的跟踪与数据中继卫星系统等项目。在这些项目中，他利用架构分析技术来为系统架构师和管理者提供支持。

2 摘要

系统架构原则

• 涌现原则
  当各实体拼合成一个系统时，实体之间的交互会把功能、行为、性能和其他内在属性涌现出来。
• 整体原则
  每个系统都作为某一个或某些个大系统的一小部分而运作，同时，每个系统中也都包含着更小的一些系统。
• 聚焦原则
  在任何一个点上都能发现很多影响系统的问题，而数量已经超出了人们的理解能力。因此，我们必须找出其中最关键、最重要的那些问题，并集中精力思考它们。
• 二元原则
  所有由人类构建而成的系统，其本身都同时存在于物理领域和信息领域中。
• 受益原则
  好的架构必须使人受益，要想把架构做好，就要专注于功能的涌现，使得系统能够把它的主要功能通过跨越系统边界的接口对外展示出来。
• 价值与架构原则
  价值是有着一定成本的利益。架构是由形式所承载的功能。由于利益要通过功能而体现，同时形式又与成本相关，因此，这两个论述之间形成一种特别紧密的联系。
• 与特定解决方案无关的功能原则
  糟糕的系统规范书总是把人引向预先定好的某一具体解决方案、功能或形式中，这可能会令系统架构师的视野变窄，从而不去探索更多的潜在选项。
• 架构师角色原则
  架构师的角色是解决歧义、专注创新，并简化复杂度。
• 歧义原则
  系统架构的早期阶段充满了歧义。架构师必须解决这种歧义，以便给架构团队定出目标，并持续更新该目标。
• 现代实践压力原则
  现代产品开发过程是由同时工作着的多个分布式团队来进行的，而且还有供应商的参与，因此，它更加需要有优秀的架构。
• 架构决策原则
  我们要把架构决策与其他决策分开，并且要提前花一些时间来谨慎地决定这些问题，因为以后如果想变更会付出很高的代价。
• 遗留元素复用原则
  要透彻地理解遗留系统及其涌现属性，并在新的架构中把必要的遗留元素包括进来。
• 产品进化原则
  系统必须进化，否则就会失去竞争力。在进行架构时，应该把系统中较为稳固的部分定义为接口，以便给元素的进化提供便利。
• 开端原则
  在产品定义的早期阶段列出的（企业内部和企业外部）利益相关者会对架构产生极其重大的影响。
• 平衡原则
  有很多因素会影响并作用于系统的架构、设计、实现及操作。架构师必须在这些因素中寻求一个平衡点，使大多数重要的利益相关者得到满足。
• 系统问题陈述原则
  对问题所做的陈述会确定系统的高层目标，并划定系统的边界。就问题陈述的正确性进行反复的辩论和完善，直到你认为满意为止。
• 歧义与目标原则
  架构师必须解决这些歧义，以便提出几条代表性的目标并持续地更新它们。这些目标要完备且一致，要兼具挑战性和可达成性，同时又要能够为人类所解决。
• 创新原则
  在架构中进行创新，就是要要求一种能够解决矛盾的好架构。
• 表面复杂度原则
  我们要对系统进行分解、抽象及分层，将其表面复杂度控制在人类所能理解的
  范围之内。
• 必备复杂度原则
  系统的必备复杂度取决于它的功能。把系统必须实现的功能仔细描述出来，然后选择一个复杂度最低的概念。
• 第二定律原则
  系统的实际复杂度总是会超过必备复杂度。架构师要令实际复杂度尽量接近
  必备复杂度。
• 分解原则
  分解是由架构师主动做出的选择。分解会影响性能的衡量标准，会影响组织的运作方式及供应商的价值捕获潜力。
• “2下1上”原则
  要想判断出对Level 1所做的分解是够合适，必须再向下分解一层，以确定Level 2中的各种关系。
• 优雅原则
  对于身处其中的架构师来说，如果系统的必备复杂度较低，而且其分解方式能够同时与多个分解平面相匹配，那么该系统就是优雅的。
• 架构健壮程度原则
  好的架构能够应对各种各样的变化。能够应对变化的那种架构，要么是比较健壮的架构，要么是适应能力比较强的架构。前者能够处理环境中的变化，而后者则能够适应环境中的变化。
• 架构决策的耦合与整理原则
  可以按照指标对决策的敏感度以及决策之间的连接度来排定架构决策之间的先后顺序。

系统思维任务步骤

• 第一项任务：确定系统及其形式与功能。
• 第二项任务：确定系统中的实体、实体的形式与功能，以及系统边界和系统所处的环境。
• 第三项任务：确定实体之间的关系。
• 第四项任务：基于实体的功能以及实体之间的功能互动，来确定系统的涌现属性。

系统思维

1 系统架构简介

1.1 复杂系统的架构

• 阿波罗计划前的登月计划
• 汽车控制系统
• 石油平台系统

1.2 良好架构的优势

架构就是对系统中的实体以及实体之间的关系所进行的抽象描述。

2 系统思维

2.1 简介

系统思维，简单来说，就是把某个疑问、某种状况或某个难题明确地视为一个系统，也就是视为一组相互关联的实体。

2.2 系统与涌现

• 系统
  系统思维，简单来说，就是把某个疑问、某种状况或某个难题明确地视为一个系统，也就是视为一组相互关联的实体。
  实体（也称为部件、模块、例程、配件等）就是用来构成全体的各个小块。
• 涌现
  功能（function）是系统所做的事情，也就是它的动作、产出或输出。
  系统的基本性质在于它会涌现出新的功能，此外还会涌现出性能（performance）、可靠性（reliability）、可维护性（maintainability）、可操作性（operability）、安全性（safety）和健壮性（robustness，鲁棒性）。

2.3 任务一：确定系统及其形式与功能

• 形式与功能
  形式和功能是系统的两个特征。
  形式：系统是什么？
  功能：系统做什么？由过程（process）和操作数（operand）组成。
  在机构中，功能有时用来指代角色（role）或职责（responsibility）。
  
• 工具-过程-操作数：这是人类的标准思维模式吗？
  诺姆·乔姆斯基（Noam Chomsky）在提出转换文法（transformational grammer）时，曾经给出一个观点，认为人类所有的自然语言都具备一种深层结构，名词-动词-名词。也就是“名词-动词-名词”格式模型，或者说“工具-过程-操作数”格式模型，要么是所有系统均具备的基本模型，要么就是人脑在理解任何一种系统时都要采用的思维方式。
  总之，所有系统都具备形式和功能。功能又可进一步拆分为过程及操作数。

2.4 任务二：确定系统中的实体及其形式与功能

• 具备形式与功能的实体
  系统是由一组实体（entity, 同单元unit，同事物thing）所构成的。
  有时会用“元素”（element，同部分part，同部件piece）一词来强调
  系统形式中的某个方面。
  
  实际工作中，定义系统的实体及系统的边界，是一件极重要且困难的事情。
  系统思考者需要面对5个问题：
  1）确定如何将系统初步分解为恰当的实体。
  2）用整体思维找出潜在的实体。
  3）通过对重点的分析，把注意力集中到重要的实体上。
  4）为实体创建抽象。
  5）定义系统的边界，并将其与外界环境隔开。

• 确定如何将系统初步分解为恰当的实体
  确定系统中的实体进而确定系统的内部边界时，可能会遇到一定的困难，其难度取决于系统属于由互不相同的（distinct）元素组成的，还是模块化（modular）或集成（integral）系统。由界限清晰的实体所组成，分解自然明确。以模块化为基调的系统，模块内部关系密切，模块间较弱。整体较为清晰。集成系统分解较为困难。如汽车的转向装置系统，各个组件（轮胎、方向盘、悬吊、转向齿轮、驾驶杆）是紧密相连的，且其中的某些部件同时是其他系统（行驶质量系统、传动系统）的组成部分。

• 用整体思维找出潜在的实体
  从整体上把握事物之间的紧密联系，尽可能发现一些对系统很关键的东西。已经的不确定物（known-unknown）与未知的不确定物（unknown-unknown）是不同的。整体思维能够尽可能多地找出未知的不确定物，从而使我们有机会去思考它们潜藏的重要作用。
  激发整体思维的办法有很多，其中包括：结构化与非结构化的头脑风暴，通过研发框架来保证相关问题可以得到考虑，从多个视角进行思考，以及把系统明确地放在大环境下进行思考。

• 集中注意力，找出系统中的重要实体

• 为实体创建抽象或从实体中发现抽象
  抽象指导原则如下：
  1）针对形式和功能创建抽象时，要把重要的信息凸显出来，隐藏不重要的细节
  2）适当的关系能在抽象后得以表现
  3）在适当的层面进行分解和聚合，并于该层面创建抽象。
  4）在能覆盖系统重要方面基础上，抽象尽力精简

• 定义系统的边界，并将其与外界环境隔开
  外围环境（context，情境、上下文）就是环绕在系统外围的东西。
  划定系统边界，可能会考虑的问题：
  1）把需要分析的实体包含进来（针对理解某个机制）
  2）把创建设计方案所必备的要素包括进来（针对创建设计方案）
  3）把我们负责实现和操作的东西包括进来（针对体现某种价值）
  4）由规章、契约或其他法律制度所建立的规范边界。
  5）能够把系统与大环境区分开的传统做法或习惯做法。
  6）我们必须遵从的一些接口定义或标准，包含于供应商之间的关系。

2.5 任务三：确定实体之间的关系

• 关系的形式与功能
  功能关系，是指用来完成某件事情的实体之间所具备的关系，此关系可能涉及实体之间对某物的操作、传输或交换。为了强调其动态性，我们有时也把功能关系称为交互（interaction，互动）关系。
  形式关系。是某段时间内稳定存在或有可能稳定存在的实体之间所具备的关系。为了强调静态性，我们有时也把形式关系称为结构（structure）关系。如心肺相连是形式，血液交换是功能。 形式关系是功能关系的载体。
• 外部接口
  形式关系与功能关系可以跨越系统边界，它们可以发生在系统内部的实体与系统外围环境中的实体之间。这叫做系统的外部接口。

2.6 任务四：涌现

• 涌现的重要性
  系统的奇妙之处，在于涌现。把系统的各个实体组合起来之后，一种新的功能，就会随着由这些实体的功能与实体之间的功能交互所形成的组合而涌现出来。
• 系统故障
  预期的涌现未能出现，可分两种情况。一是预期的良好涌现物未能出现；二是意外的不良涌现物出现了。
• 预测涌现物
  预测涌现物三种方式。一是根据经验来预测；二是做实验来预测；三是建模。
  三种方式都不行时，要对将要涌现出的功能进行推理。
• 涌现物依赖于实体及其关系

2.7 小结

3 思考复杂的系统

3.1 简介

系统架构本身就是具备复杂性的，下面介绍系统中的复杂度问题。

3.2 系统中的复杂度

• 复杂度
  如果系统中有很多互相关联、互相连接或互相混杂的实体与关系，那么该系统就是复杂的（conplex）。
  系统之所以复杂，是因我们对系统总是有“更多的要求”:
  更多的功能、更好的性能，更健壮、灵活，可协作、可连接。复杂度指标可基于信息，可基于功能。难懂的事物是具备较高的表面复杂度，超出人类的理解能力。如今社会的告诉发展，很多系统复杂度在快速增加。
  好的系统架构，具备必要的复杂度同时又不难懂。

3.3 系统的分解

• 分解
  分解就是把实体分成小的部件或组成部分。在应对复杂度的诸多
  工具中，它是较为强大的一种。
  系统先分解后整合，难在整合。
  整合在形式领域就是把各部件所具备的形式聚合起来，这过程存在物理上或逻辑上能否拼接在一起的风险。
  整合在功能领域就是每个实体的功能重新组合，这过程会遇到涌现物，是挑战之一。
• 体系
  体系也是一种用来理解并思考系统复杂度的强大方法。
  社会系统中经常看到各种体系，如军队（将军、上校、少校、上慰）、公司组织体系（董事、总经理、部长、组长）。
• 层级分解
  将分解与体系这两种手段结合起来，通常可实现多层次或层级化的分解，
• 简单的系统、复杂度适中的系统以及复杂的系统
  1）简单的系统
  只需分解一次即可将其完整地描述出来。如太阳系只需要分解成由行星和更小的星体所组成的一层即可。简单系统分解的元素一般不超过7个（上限浮动2个）。
  2）复杂度适中的系统
  需要分解两层，初次分解出的部件还统领一层部件。
  3）复杂的系统
  需要分解3层及以上，如果3层对应的元素可以有9的3次方729个，超过人类所能理解的范围。

层级定义：
第0层（Level 0） – 系统本身
第1层（Level 1） – 系统初次分层
第2层（Level 2） – 系统再次分层
…
第0层系统之下的那些层，可叫做模块（module）、配件（assembly）、子配件（sub-assembly）、函数或功能（function）、架（rack）、在线更换单元（Online Replacement Unit，ORU）、例程（routine）、委员会（committee）、工作组或任务组（task force）、单元（unit）、组件（component）、子组件（sub-component）、部件或部分（part）、区段（segment）、节（section）、章（chapter）等

• 原子部件（atomic part）

系统架构的分析

4 形式

创建系统架构

9

作为决策的架构

14

3 知识点

4 资料补充

5 个人感悟

5.1 大道至简

复杂系统设计简单化，追求大道至简。

5.2 修身齐家治国平天下

修身齐家治国平天下，每一层都是一个复杂的系统，而对应的方法论便是架构。《论语》、《素书》、《商君书》、《盐铁论》、《毛 | 选》都可认为是架构。

参考

1、《系统架构：复杂系统的产品设计与开发》
2、豆瓣–系统架构