目录
系统思考的本质是整体思考，虽然“我们是一个整体”的道理很好理解，“盲人摸象”的寓言也是妇孺皆知，但在组织中，最常见的问题仍然是“本位主义”，局限思考和行动，每个人每个部门都只是从自己的本位出发，“归罪于外”，结果造成组织中充满了相互指责，以及平庸甚至是愚蠢的决策。
产生这个问题的原因一方面在于组织系统的动态复杂性，另一方面也与人们缺乏有效进行整体思考的技能不无关系。因此，要做到系统思考，必须能够全面思考，从局限于本位到关照全局、看见整体。
系统思考是一个既见树木，又见森林的思考模式。
（1）本位主义 VS 大局观
（2）局部 VS 全局
（3）片面 VS 全面
（4）单维度 VS 多维度
（5）非黑即白 VS 多彩多姿
（6）井底之蛙 VS 海阔天空
（7）固执 VS 灵活
（8）刻板单一 VS 因人而异（见人说人话，见鬼说鬼话）
（9）只见树木 VS 又见森林
备注：
鬼谷子最厉害之处，就是他能够把人与人的交往定义了无数个典型的场景，并针对不同的场景，指明了不同的行之有效、助人成功的策略。这也是全面思考的体现。
程序的局部性原理是指程序在执行时呈现出局部性规律，即在一段时间内，整个程序的执行仅限于程序中的某一部分。它们倾向于引用的数据项邻近于其他最近引用过的数据项，或者邻近于最近自我引用过的数据项。
在现代计算机系统的各个层次，从硬件到操作系统、应用程序等，设计上都利用了局部性原理。比如缓存机制，CPU指令顺序处理等。
局部性通常有两种形式：时间局部性和空间局部性
（1）时间局部性（temporal locality）
时间局部性是指如果程序中的某条指令一旦执行，则不久之后该指令可能再次被执行；如果某数据被访问，则不久之后该数据可能再次被访问。强调数据的重复访问。
利用时间局部性，缓存在现代程序系统中扮演着重要角色，数据缓存，磁盘缓存，文件缓存等，极大提高数据的重复访问性能。而在程序设计中，循环体则是时间局部性常见的一个场景
（2）空间局部性（spatial locality）
空间局部性是指一旦程序访问了某个存储单元，则不久之后。其附近的存储单元也将被访问。强调连续空间数据的访问，一般顺序访问每个元素（步长为1）时具有最好的空间局部性，步长越大，空间局部性越差。
备注：
人天然的思维模式，与计算机程序一样，具备时间和空间的局部性。
无论是由人组成的企业组织，还是有代码组成的软件目标系统。
在分析问题时：
我们不仅仅站在自身的立场和角度思考问题的根源，还需要从系统的角度，思考问题的根源。
在解决问题时：
我们不仅仅站在自身的立场和角度思考解决方案，还需要从系统的角度，思考问题的解决方案。
局部最优，不代表全局最优。有时候，为了达成全局最优，需要牺牲某个局部的利益。
一味地站在自身的立场、维护小团体的利益，带来如下的几个可能的后果：
因此，克服本位思考不仅仅是格局，也是一个人的能力，需要经过长期的训练。
从某个模块和或某组件程序员的角度跳出来，从软件架构师、系统架构师角度思考目标系统
（1）软件组件以及功能划分
（2）软件组件的层次结构
（3）软件组件的消息交互
（4）软件组件的状态机
（5）软件系统的性能需求
实体：
在系统思考中：代表的是利用相关方。
在项目管理中：代表的是干系人
在UML中：代表的是用户或软件实体
元素：软件实体
UML是在开发阶段，说明、可视化、构建和书写一个面向对象软件密集系统的制品的开放方法。最佳的应用是工程实践，对大规模，复杂系统进行建模方面，特别是在软件架构层次，已经被验证有效。统一建模语言（UML）是一种模型化语言。模型大多以图表的方式表现出来。一份典型的建模图表通常包含几个块或框，连接线和作为模型附加信息之用的文本。这些虽简单却非常重要，在UML规则中相互联系和扩展。
截止UML2.0一共有13种图形（UML1.5定义了9种，2.0增加了4种）。
用例图、类图、对象图、状态图、活动图、顺序图、协作图、构件图、部署图、包图、组合结构图、交互概览图
用例图：从用户角度描述系统功能。
类图：描述系统中类的静态结构。
对象图：系统中的多个对象在某一时刻的状态。
状态图：是描述状态到状态控制流，常用于动态特性建模
活动图：描述了业务实现用例的工作流程
顺序图：对象之间的动态合作关系，强调对象发送消息的顺序，同时显示对象之间的交互
协作图：描述对象之间的协助关系
构件图：一种特殊的UML图来描述系统的静态实现视图
部署图：定义系统中软硬件的物理体系结构
包图：对构成系统的模型元素进行分组整理的图
组合结构图：表示类或者构建内部结构的图
交互概览图：用活动图来表示多个交互之间的控制关系的图
用上述图形，就可以从不同角度、不同层次、全面地、描绘一个软件系统。
UML不仅仅可以描述软件系统的静态特征，也可以描述软件系统的动态特征。
从上面可以看出，UML图远比系统思考提供的图全面。
UML不仅仅可以描述软件系统，也可以用来描述任何组织。
UML不仅仅可以描述软件系统的工作方式，也可以用来描述任何组织的工作方式。
