目录

第1章 全面思考概述（空间）

1.1 什么是全面思考（整体思考）

1.2 全面思考的含义

1.3 程序的局部性原理

第2章 如何做到全面思考

2.1 本位思考 =》 全局思考

2.2 大局观，既是一种格局，也是一种能力

2.3 软件架构师、系统架构师

第3章 全面思考的辅助工具

3.1 实体关系图

3.2 输入输出图

3.3 思考的罗盘

第4章 UML图在全面思考中的应用

后记：

---

第1章 全面思考概述（空间）

1.1 什么是全面思考（整体思考）

系统思考的本质是整体思考，虽然“我们是一个整体”的道理很好理解，“盲人摸象”的寓言也是妇孺皆知，但在组织中，最常见的问题仍然是“本位主义”，局限思考和行动，每个人每个部门都只是从自己的本位出发，“归罪于外”，结果造成组织中充满了相互指责，以及平庸甚至是愚蠢的决策。

产生这个问题的原因一方面在于组织系统的动态复杂性，另一方面也与人们缺乏有效进行整体思考的技能不无关系。因此，要做到系统思考，必须能够全面思考，从局限于本位到关照全局、看见整体。

系统思考是一个既见树木，又见森林的思考模式。

1.2 全面思考的含义

（1）本位主义 VS 大局观

（2）局部 VS 全局

（3）片面 VS 全面

（4）单维度 VS 多维度

（5）非黑即白 VS 多彩多姿

（6）井底之蛙 VS 海阔天空

（7）固执 VS 灵活

（8）刻板单一 VS 因人而异（见人说人话，见鬼说鬼话）

（9）只见树木 VS 又见森林

备注：

鬼谷子最厉害之处，就是他能够把人与人的交往定义了无数个典型的场景，并针对不同的场景，指明了不同的行之有效、助人成功的策略。这也是全面思考的体现。

1.3 程序的局部性原理

程序的局部性原理是指程序在执行时呈现出局部性规律，即在一段时间内，整个程序的执行仅限于程序中的某一部分。它们倾向于引用的数据项邻近于其他最近引用过的数据项，或者邻近于最近自我引用过的数据项。

在现代计算机系统的各个层次，从硬件到操作系统、应用程序等，设计上都利用了局部性原理。比如缓存机制，CPU指令顺序处理等。

局部性通常有两种形式：时间局部性和空间局部性

（1）时间局部性（temporal locality）

时间局部性是指如果程序中的某条指令一旦执行，则不久之后该指令可能再次被执行；如果某数据被访问，则不久之后该数据可能再次被访问。强调数据的重复访问。

利用时间局部性，缓存在现代程序系统中扮演着重要角色，数据缓存，磁盘缓存，文件缓存等，极大提高数据的重复访问性能。而在程序设计中，循环体则是时间局部性常见的一个场景

（2）空间局部性（spatial locality）

空间局部性是指一旦程序访问了某个存储单元，则不久之后。其附近的存储单元也将被访问。强调连续空间数据的访问，一般顺序访问每个元素（步长为1）时具有最好的空间局部性，步长越大，空间局部性越差。

备注：

人天然的思维模式，与计算机程序一样，具备时间和空间的局部性。

第2章 如何做到全面思考

2.1 本位思考 =》 全局思考

 

 无论是由人组成的企业组织，还是有代码组成的软件目标系统。

在分析问题时：

我们不仅仅站在自身的立场和角度思考问题的根源，还需要从系统的角度，思考问题的根源。

在解决问题时：

我们不仅仅站在自身的立场和角度思考解决方案，还需要从系统的角度，思考问题的解决方案。

局部最优，不代表全局最优。有时候，为了达成全局最优，需要牺牲某个局部的利益。

一味地站在自身的立场、维护小团体的利益，带来如下的几个可能的后果：

• 局部最优，导致全局不是最优，即牺牲全局利益，维护局部利益。
• 限制个人的成长、井底之蛙，目标短浅。

2.2 大局观，既是一种格局，也是一种能力

 因此，克服本位思考不仅仅是格局，也是一个人的能力，需要经过长期的训练。

2.3 软件架构师、系统架构师

从某个模块和或某组件程序员的角度跳出来，从软件架构师、系统架构师角度思考目标系统

（1）软件组件以及功能划分

（2）软件组件的层次结构

（3）软件组件的消息交互

（4）软件组件的状态机

（5）软件系统的性能需求

第3章 全面思考的辅助工具

3.1 实体关系图

 

实体：

在系统思考中：代表的是利用相关方。

在项目管理中：代表的是干系人

在UML中：代表的是用户或软件实体

 

 元素：软件实体

 

 

 

3.2 输入输出图

 

 

 

3.3 思考的罗盘

 

第4章 UML图在全面思考中的应用

UML是在开发阶段，说明、可视化、构建和书写一个面向对象软件密集系统的制品的开放方法。最佳的应用是工程实践，对大规模，复杂系统进行建模方面，特别是在软件架构层次，已经被验证有效。统一建模语言（UML）是一种模型化语言。模型大多以图表的方式表现出来。一份典型的建模图表通常包含几个块或框，连接线和作为模型附加信息之用的文本。这些虽简单却非常重要，在UML规则中相互联系和扩展。

截止UML2.0一共有13种图形（UML1.5定义了9种，2.0增加了4种）。

用例图、类图、对象图、状态图、活动图、顺序图、协作图、构件图、部署图、包图、组合结构图、交互概览图 

• 用例图：从用户角度描述系统功能。

• 类图：描述系统中类的静态结构。

• 对象图：系统中的多个对象在某一时刻的状态。

• 状态图：是描述状态到状态控制流，常用于动态特性建模

• 活动图：描述了业务实现用例的工作流程

• 顺序图：对象之间的动态合作关系，强调对象发送消息的顺序，同时显示对象之间的交互

• 协作图：描述对象之间的协助关系

• 构件图：一种特殊的UML图来描述系统的静态实现视图

• 部署图：定义系统中软硬件的物理体系结构

• 包图：对构成系统的模型元素进行分组整理的图

• 组合结构图：表示类或者构建内部结构的图

• 交互概览图：用活动图来表示多个交互之间的控制关系的图

用上述图形，就可以从不同角度、不同层次、全面地、描绘一个软件系统。

UML不仅仅可以描述软件系统的静态特征，也可以描述软件系统的动态特征。

后记：

从上面可以看出，UML图远比系统思考提供的图全面。

UML不仅仅可以描述软件系统，也可以用来描述任何组织。

UML不仅仅可以描述软件系统的工作方式，也可以用来描述任何组织的工作方式。