编辑导语：逻辑图是多个元素之间用图标、说明文字和连接线相互作用的可视化表达。在之前的文章中，作者介绍了逻辑图三要素中的“要素”和“逻辑”。在这篇文章中，作者继续介绍“模型”，让我们来看看。
逻辑图三要素中“要素”和“逻辑”的表述前面已经介绍过，上一篇文章三要素中第三个要素中“模型”的表述。最后，如何将元素和逻辑整合成令人信服的“逻辑图”。通常，在选择用什么形式的图来表达研究对象时，我们通常更喜欢我们熟悉的图。这个图的形式和表达的意图之间有一种约定俗成的关系，这一点大家都认可。这个图就是模型。
有了元素和逻辑，为什么会有特殊的解释模型？因为模型选择正确与否会产生不同的结果。
(1)如果模型选择得当，观看者首先会通过模型的外观知道作者想要表达什么意图，观看者会根据模型的定义确认作者的内容。比如观众看到“流程模型”，就知道作者展示的是实现某个目标的工作流程，他会沿着流程的起点去研究工作的每一步。再比如：观者看到“鱼骨图”，就知道作者要做总结分析，给出因果关系的结论。
(2)选型错误。当元素和逻辑的表达非常准确时，如果没有恰当地选择整合元素和逻辑的载体，最终传递的意图就会打折扣或者作者的意图表达不正确。例如，当你想表达一个明确的工作目标和实现目标的工作步骤顺序时，你应该优先考虑“流程图”。如果选择“思维导图”而不是“流程图”，可能会不尽如人意，因为思维导图是用来表达可能的相关工作，而不是给出明确的工作顺序。
主要有两种型号，即分析模型、架构模型。.
# 01分析模型
分析模型，是建立分析要素与推测结果之间的关联关系。
这里推荐的五种分析模型可以分为两类。第一类在业内认知度高，使用频率高，第二类是根据作者的实践经验设计的，如图1所示。
分析模型具有以下特征：
图1分析模型列表
1.鱼骨图：是日本老师石川薰发明的，所以也叫石川图或者因果图。
2.思维导图：英国托尼布赞倡导。
3.线形图：、由作者整理设计。
1)关联图的分析对象中包含的所有元素可能不是结构化的。现实中，有很多业务场景非常复杂，高度耦合，难以拆分。因此，模型的引入主要是为了解决这类问题。关联图看似简单，其实是为了理解和表示最复杂的对象场景而引入的。
2)鱼骨图和思维导图不仅方向性强，而且可以自由发散地采集相关元素，在使用中可以同时展开采集，在采集元素的过程中可以将元素整理出来。
3)并行图 :具有一定结构化形式的模型，这样的模型容易给出分析结果的规律性和收敛方向，在调查分析领域非常实用，可以很容易地建立分析结果与业务架构(流程图)的对应关系，从而加快分析设计。它是“分析模型”和“架构模型”之间的桥梁。
# 02架构模型
架构模型，是表达符合业务逻辑关系的要素结构图。
1)
模型描述这里推荐的五种架构模型可以分为两类。第一类在业内认知度高，使用频率高，第二类是根据作者的实践经验设计的，如图2所示。该架构具有以下特征：
图2架构模型概述
1)
(1)拓扑图为了打开读者的思路，这里我们导入一个可以响应扩展和灵活部署的架构模型，主要用于最粗糙的规划设计。它不仅可以用于一般的业务架构，还可以为将来参与软件设计铺平道路。
2)层次图和框架图用于复杂对象的一、二级划分，起到从粗粒度规划到细粒度设计的过渡作用，属于架构图中大纲层次描述的表达方法。
3)分解图和流程图这两个模型是采用结构化体系结构方法的核心。它们的作用是承接中粒度架构的结果，进一步向下细分，属于架构图中详细层次描述的表达方式。
# 03两种型号之间的差异
分析模型与架构类模型有什么区别呢？
分析模型中的元素不一定具有清晰和精确的逻辑关系。由于现阶段要素之间的因果关系尚不明确，此时无法使用精确的逻辑表达。
分析类模型可以解决整理收集要素并给出分析结果的任务，但分析模型不能直接用于解决分析结果。
因为无法精准地表达逻辑关系，所以必须将分析得到的要素（业务、管理）融入到“业务架构（如：业务流程）”中，才能够发挥出作用。分析模型与架构模型的目的不同，它们之间的区别，从图3的（a）、（b）两张图的对比可以看出，将实际的业务内容（要素）加入到模型中，观察图形的变化，
图3 分析模型与架构模型的区别
1）图（a）鱼骨图-成本超标问题 （分析模型）分析（a）给出的分析课题是研究成本超标问题，可以看出鱼骨图上呈现的分析要素都是
“意见、想法、现象、建议等”内容，它们是在调研中客户使用的语言，而不是通常设计中使用的业务设计用语，所以，“鱼骨图”+“非业务设计用语（客户用语）”，是不能用来表达解决方案中的“业务处理、管理控制等”内容的。
2）图b.流程图-
业务流程图（架构模型）再看架构图（b）的内容，采用的都是业务设计用语（业务属性），图形是严谨的、结构化，清晰地给出了目标、方向、流程、步骤等信息，也就是说，图（b）模仿的是真实的业务形态，所以也必须使用真实的业务设计用语（要素），流程上所有的节点之间必须用合理的逻辑相关联，这样的架构图才能够用来做业务的解决方案。
分析模型可以表现分析成果、需要的功能等，但不一定能够表现出严谨的逻辑关系、可以执行的解决方案，所以分析与架构各自关注的是不同阶段的工作和结果，因此分析模型是不能够替代架构模型做架构图的。
虽然分析工作与架构工作的目的都是用要素来构成一张图，但作图的方法也是有别的：□分析：是用“归集要素”的方法做图，归集后要素的承载结构是分析模型；□架构：是用“组合要素”的方法做图，组合后要素的承载结构是架构模型；
## 扩展说明：
“模型”与“图”的区别“模型”也是图，称之为“模型”的图揭示了某种事物对象的规律，这个规律具有一定的普遍性，所以模型可作为具有类似规律研究对象的参考。
一般称之为“xx图”的图形，只是表明对“xx”用图形来表达其含义，不强调它是否是一个具有代表性的“模型”。以生产流程图为例看两者的区分：
图4 生产流程图
* 流程模型：给出了有规律性连续活动之间的关系表达图形（与业务领域无关）；
* 生产流程图：给出了用图形表达的“生产”过程、节点关系（与业务领域有关）
当然，如果这个生产行为在生产领域具有一定的代表性，则这个“生产流程图”也可以称为“生产流程模型”。
# 04 逻辑图绘制方法的总结
到此，就完成了对逻辑图三元素的说明。不论描绘什么内容的逻辑图，都包含有这三种元素： 要素、逻辑和模型
，熟练度掌握了这三种元素的定义、用法，几乎没有不能表达的对象、事物。
你需要理解一张内容较多、业务比较复杂的、同时也不太熟悉的逻辑图时，一定要从这三个元素入手，就可以快速的理解：
1）判断模型的分类： 知道了模型，就大概知道了作者要表达对象的哪个层面、维度的逻辑，如：
* 框架图 → 表达研究对象的范围、区分、模块的边界等关系；
* 流程图 → 表达研究对象的行为过程的起点、节点数、顺序、终点等；
2）判断要素的合理性： 要素表达的粒度/层级、内容划分的耦合性等是否符合要求；
3）判断逻辑的正确性： 根据业务知识、软件设计要求等，检查逻辑表达的方式是否正确；
作为一种能力，不论你从事软件工程上的哪个岗位（咨询、需求、架构、开发、测试、实施等），逻辑思维、逻辑推理、逻辑表达等有关逻辑的能力都是必须的。这种能力是做好任何业务领域软件（ERP、电商平台、物联网等）的基础。
能够用逻辑图完美、精准地表达、传递意图，是你展示自己才能的一个重要方式，同时也是其他人评估你能力的一个重要参考。
本系列博文到此结束，谢谢收看！
作者：李鸿君；《大话软件工程―需求分析与软件设计》一书作者。
本文由 @李鸿君 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
