33

图像与模型之间的关系是什么？

如果程序员出身的，真正的程序员，他天天做算法的，他会对这个问题比较敏感，比如看到五边形，他会告诉你图像与模型与定义之间，是怎么映射的。

那怎么描述，首先就得先理解别人的讲的是什么东西，这些东西代表了什么意思，以及理解人与人是如何沟通的，一个问题的描述，首先描述的是一个宏观的图像，架构是首先关注整体，而不是盯着那个设计细节。

架构师刚开始并不是关注细节，而是首先瞄准宏观整体的东西的形象，然后用形象的比喻和生动的语言，把它解释清楚，让人能自然明白。比如，我们经常看到一些老师所使用的沟通失效的例子，五个人之间信息传达失效的问题，人与人传统信息，沟通之间不能违规，只能一个人向一个人的传达信息。那到最后，信息从最初的第一个人，到最后一个人，已经失真得厉害了，基本上和最初的信息要表达的意思，千差万别了。为什么？

那么，现实生活中，为什么很多情况下，人与人难以沟通呢？

这是因为，沟通是人与人之间、人与群体之间思想与感情的传递和反馈的过程，以求思想达成一致和感情的通畅。首先，沟通要有三大要素即：要有一个明确的目标；达成共同的协议；沟通信息、思想和情感。

沟通就是信息传与受的行为，发送者凭借一定的渠道，将信息传递给接收者，并寻求反馈以达到相互理解的过程。沟通既是人际的交流，也涉及组织之间的交流。沟通具有的功能包括：信息传递、情感交流、控制功能。

因此，沟通的要素包括沟通的内容、沟通的方法、沟通的动作。就其影响力来说，沟通的内容占7%，影响最小；沟通的动作占55%，影响最大；沟通的方法占38%，居于两者之间。松下幸之助有句名言：“企业管理过去是沟通，现在是沟通，未来还是沟通。”管理者的真正工作就是沟通。不管到了什么时候，企业管理都离不开沟通。

34

所以，我们要使用一种有效的沟通方式，就需要建立完整的计划，画一个矩形，将脑子中的东西映射成一个二维表，使用瞄准这种方式，快速的能抓住问题的实质。

其实沟通并不是容易，信息在传递之间很容易遗失，再加上人的描述是用语言来进行的，而语言本身有时候也并不是很明晰的，你比如你想的很清楚，或者说你头脑里有一幅很清晰的图画，但你很难把它描述出来，同时，当你描述出来的时候，你可能已经失真了，难而麻烦的是，你还要把它讲给别人，那别人能理解吸收多少呢。

从你头脑中的意象，到让自己理解，到语言表达，然后，再说给别人，让别人也去理解，这一系列过程，本身就存在着信息不断的失真的情况下，所以说，有效沟通也是很难的。因此，为了把话说清楚，把道理搞明白，你要写，要设计，要画图，要解释，方便和别人交流，这样有了这些文档，还有大家要统一语言，这样才能形成共识，甚至还要来证明人家理解了，特殊情况下每个人还要签字，比如法律文本的合同等，这样才算说是理解了。

当然了，有人还说，如果没有理解怎么办，后果自负吧，你都签字了，还说没有理解，那是你的问题了。

沟通并不是你觉得或你想的那样容易，说了半天你以为你想的挺明白的。但是，那早已不是你最初在脑袋里呈现出来的东西了，脑袋里面构思是你想的那个东西，所以，这个过程还是要尽量的记录下来，以便你下次接这个地方搞下去，否则，你还得从头思考，如果没有记录，没有形成逻辑化的表达方式，最终还是一头雾水。

其实，对于某些问题，也不是一次性就能思考得全面彻底，而要多次不同时空下去思考，才更完善一些，如果你真要对这些问题感觉有兴趣，并深入持续的思考下去，那除了不断的思索，还要记录，这样好有一个基点，在原有的基础上再思考。

35

这是因为，人脑还没有达到那个发达到的地步，不是说，你能想的东西都能住，还准，这不可能，大脑本身的功能之一就是遗忘，如果什么东西它都记，那这个大脑要崩溃了。是不是痛苦的也要记呢，当然，有时候还是记着了，只是你需要的时候它又呈现了出来，比如，你又心情不好了，又想起了那些悲伤的过往，但这也只是某一个时点，触发了你过往的记忆，从而重新激活了，而并不是说，你随时都能把它寻找到，记忆之所以能激活，也是在特定的时空点，特定的情绪下，特定的场景下，特殊的意义下，被激活的，比如一件往事，你以为你早忘了，但还是被激活了。

从这一方面来说，所以你想得再好，也是过眼云烟，尽可能的记一点，起码有个思考的基点了。

首先，要描绘一下，愿景是什么样子的？

我们是运用模型驱动MD的过程，获得一个模型驱动的架构，就是我们最终的架构风格是模型。通过模型来提供架构这体现了我们的开发方法论。模型驱动的开发方法论，它的输入点就是一个用例模型。然后我们需要获得分析模型，设计模型，然后还有部署模型，我说的这些，现在还不是我们要关注的要点，因为我们还要去验证模型，是否适应于我们要解决的问题领域。

36

我们要进行架构的构思。通过描述与记录这个实践，设计、实施和评估等这样的一些关键性的活动，当我们的描述把这个活动的实践结合起来，把架构当成一种文档，最后要形成说明文档，蓝图指南。这个描述其实就是一个软件项目生命周期的过程。

我希望大家能够熟练的使用架构描述语言，通过架构描述语言来描述我们的一个架构，那我们的构架过程是什么样子的呢？

我们方法论是，使用一个用例驱动的，以架构为中心的，迭带和增量的软件过程。从空间去学会去构建一个架构，架构一定要满足系统的质量属性，the quality property，这是我们的一个核心的目标，那我们的这本书，其实就要干这件事儿，把这个事情描述与总结出来，形成一套有理论指导意义的，可实践的思维模式，也即框架思维。

这是我的一个愿景，为了完成这项任务，需要把任务分解一下，大概有十几个目标吧，也就是说，如果你能沿着我的思路，你至少能理解和掌握这些目标的中的绝大多数。

范围、目标、风格、框架，这个是我们要重点掌握的内容，在这个里面我们也希望能够了解一下架构师。那就是你要了解软件项目中的三个活动者（Actor），项目经理、架构师和设计师，这是三个核心的概念，包括他们的一些细节，怎么把它组合在一块儿，那就是怎样用UML和透视图的这种方式，把这几个角色组合在一起。

37

透视图，就像4+1视图，使用透视图确保满足系统的性能、伸缩性和重要质量属性。然后要平衡不同涉众的需要，架构有没有满足人家的这个需求了呢，整个系统的核心是动态迭代的过程，也就意味着，不可能一次性就会有一个完美的结果。

即使做的项目比较大，就像是有些几千万的项目，你也不可能说想了一周，就把架构设计出来了。一般来说，至少要好几个月，如果三个月，你把几百万，几千万的项目中遇到的架构问题能想清楚，这就很了不起了，这里面花费时间最长的就是，模型的抽象与建立。如果是逻辑比较复杂的概念模型，可能是要反复的、不断的、来回的、循环的考虑问题，如果是超级复杂的，花的时间会更长。

UML这个工具基本上大家都用过，这个描述语言分为两个模式，黑盒和白盒。

黑盒，是使用用例和场景，描述系统行为的协作和交互。白盒，就是用户图形手册，描述系统的行为和用例。

38

那我们需要用这个场景以及新的模式，去看看你做的架构符合不符合需求，然后，根据这个需求形成你的软件架构文档，最终要交给你的客户。

几种常见的架构风格，架构形成的机制就是模式。机制是架构师要用的最重要这些概念之一，在这个机制里面的也要把它分成三个，分析机制、设计机制、实施机制。

其实，道理是相通的，一里通百里容，这些思想人也能够应用于你的日常生活的。一个企业最重要的是什么，模型，文化，战略，组织结构和架构。我们有概念，协作，还有描绘它是怎么交互的。

软件设计，我们画了一个图，就整个的软件设计就是几个用例图，几个协作图，协作图实现了用例，用例代表了一种场景，在这个场景下面，我们要有一个交互，这个交互是语言描述的对象。

UML，你有没有把它就当成一个技术员之间真正的沟通呢，还是你把他当成了一个有效的架构描述语言。一个类图，一个具体的交互处对象图，可以展示出事件的来龙去脉。