第4章 分析模型与架构模型
（1）制图标准：工程化制图的基本要求，包括图标、符号、名称等。
（2）分析模型：用于分析工作的常用模型定义、绘制方法和使用场景。
（3）架构模型：用于架构设计的常用模型定义、绘制方法和使用场景。
4.1 基本用语约定
1．结构图
所有具有一定的形状并符合组合原理三元素的图形都属于“结构图”。在使用“结构图”一词替代具体的模型名称时，表明此时的关注点不在于是分析类还是架构类的模型。
2．图形
用线、要素块等图形符号构成的表达某类含义的形状都称为“图形”。“图形”比“结构图”更为广义和宽泛，该图形是否符合组合三元素不重要，它可以是逻辑图（符合三元素），也可以是示意图、物理图形（软件的界面）。
3．模型
表达具有某种“规律”并具有“示范性”的图形称为模型。模型与图形的区别在于：虽然都是图形，但模型是对某类具有规律性内容的抽提和归纳，而一般用到“图形”一词时并不关注它是否是某种规律的总结，只强调用的是“图形”而不是用“表格”“文字”或其他什么形式进行的表达。
4．节点
图形中具有两条以上线的交叉位置点都称为节点，例如在流程图上，节点可以表达的是一个“步骤”、一个“业务活动”或是一个“业务组件”等。使用节点一词时同样是此时不关注该节点对应的是具体的什么业务内容（如步骤、活动、组件等）。
4.2 图形符号说明
工程化的图形设计必须要统一制图标准，制图标准的统一可以快速、精确地表达和传递图中的含义，提升沟通与设计的效率及质量。图形符号是构成图形的基本要素，主要用于表达架构模型。
4.2.1 图形符号的构成
推荐的图形符号分为三大类：要素块、关联线、背景框。
1．要素块
要素块，表示了图形中的要素，它是构成图形的核心内容，要素块可以再细分为两类：业务要素、系统要素。
1）业务要素
在业务设计的范围内，用来表达具有业务含义的要素，如财务系统、材料采购模块、合同签订功能、角色、交付物等。这类图标都与业务有关联。
2）系统要素
在业务设计的过程中，有一些与业务设计紧密相关的系统要素，如数据库、数据处理器等。这类图标与技术设计有关，在业务设计中仅标出与这些系统要素有相关性。
2．关联线
用来表现节点之间的关联关系，如连接、方向、顺序、从属等。分为两大类：实线类、虚线类。关联线是表达三元素中“逻辑（关联）”的主要手法之一。
3．背景框
背景框主要有两个用途，一是整合图形中的要素群，在同一背景框内的要素具有相同的目的，具有内聚性，通常是来表达“系统、模块”的含义的。二是用来为图形增加辅助信息（如组织）。背景框是表达三元素中“逻辑”的主要手法之一。
4.2.2 图形符号的用法
分析与架构所采用的图形虽然形态不同，但都是使用了简单的点、线、面，以及通过它们之间的关联形成的，相同的图形符号可以构成不同的图形以表达不同的意思。
4.2.3 背景框的用法
要素块、关联线的用途容易理解和使用，但是整合框的作用就不是很清晰了。背景框并非只是简单的“白色背景”，它不仅可以用简单白色框来对要素进行整合，表达要素之间简单的逻辑关联关系，而且还有提供多维度信息（如组织结构、时间维度等）的作用。结构图与具有维度信息的背景框相结合后，能够使得结构图表达更多的信息。
4.3 分析模型1——关联图
关联图：把原因、结果要素按照相互作用关系关联起来的图形。通过关联线可以找到产生结果的原因。
4.3.1 概念与解读
1．模型概念
在现实中很多的研究对象包含复杂的要素，这些要素互为因果，用复杂的形态耦合在一起，很难用结构化形式清晰地进行分离、表现出来。从对象上拆分出来的要素包含：原因、结果、手段、意见、目的、方法等不同的类型，这些要素之间不是一对一的关系，这样的对象显然无法使用结构化的模型表达。但是采用“关联图”就比较容易表达，用关联图可以将要素关联起来，在复杂的关联关系中找寻规律、因果关系。
关联图的主要目的与作用是关联分析要素之间的关系。
2．适用场景
主要由于要素之间没有明确的逻辑关系，也不确定是否具有严格意义上的关联关系等情况下适用。通过进行要素之间的关联，逐渐地找到要素之间的因果关联、规律、逻辑等，为后续可以用架构图进行架构表达做好准备。
4.3.2 画法与场景
1．模型画法
关联图的绘制方法非常简单，只需要圆圈（或方框）和箭头，画法如下。
（1）确定主题，收集所有与主题相关的要素；
（2）将要素列成一圈，顺序不重要；
（3）在圆圈中标注要素的名称；
（4）按照从“原因”到“结果”、从“手段”到“目的”的原则，标注箭头；
（5）用颜色标出主要原因的要素1（箭头全部向外）；
（6）用颜色标出主要问题的要素4（箭头全部向内）。
2．适用场景
主要由于要素之间没有明确的逻辑关系，也不确定是否具有严格意义上的关联关系等情况下适用。通过进行要素之间的关联，逐渐地找到要素之间的因果关联、规律、逻辑等，为后续可以用架构图进行架构表达做好准备。
4.4 分析模型2——鱼骨图
鱼骨图：给出一个结果（主题），通过归集要因向主题收敛的因果关系表达方法。
4.4.1 概念与解读
其图形看上去有些像鱼骨，所以称之为鱼骨图。在“鱼头”处标出问题的归集结果，通过头脑风暴法找出造成问题的要因。
4.4.2 画法与场景
将收集到的问题与可能造成发生这些问题的要因，不但用鱼骨图表达出它们之间的因果关联，并通过线条和位置表达出了问题的轻重关系。
4.5 分析模型3——思维导图
思维导图：是不设约束条件、边界，从主题出发进行发散式地收集要素的方法。
4.5.1 概念与解读
思维导图又称树状图、思维地图，它用一个主题（关键词）以辐射线形连接所有的相关代表字词、想法、任务或其他关联项目，形象地、自然地表达出主题与要素间的关系。
4.5.2 画法与场景
在需求调研时，可以既快捷又有条理地记录需求，同时根据某个题目可以发散式地收集与该题目相关的需求或是信息，这些信息中包含着未来可能成为功能的需求。
注：思维导图与鱼骨图的区别
两者都可作为头脑风暴的分析和记录工具，但两者又有差异之处，注意不要搞错用法。
（1）思维导图：先给出一个主题，然后以这个主题为出发点，向外发散式地收集与主题相关的信息，只要相关就可以挂接，因为目的不是聚焦，所以没有收敛点。
（2）鱼骨图：先给出一个结果，然后以这个结果为目标，去收集与这个结果相关的信息，这些信息一定要支持得出这个结果。也就是说，鱼骨图是要聚焦的，因此是收敛的。
4.6 分析模型4——排比图（一维）
排比图：以业务线为主线，将找出的问题及对策与业务线的节点建立对应关系。
4.6.1 概念与解读
一维的排比图（以下将一维排比图简称为排比图）是利用线形关联的方式收集和分析研究对象，可以将收集、分析、梳理的工作有序地一次完成。
4.6.2 画法与场景
这个模型在需求调研的现场，当调研人员与客户处于对问题都不清晰的场合，或是大家讨论了很长时间得不到结论时，以及应对突发问题时都可以利用排比图快速地沟通、理解，并得出结论，这是一个非常行之有效的方法。
4.7 分析模型5——排比图（二维）
排比图：以业务线为主线，将分析结果、对策与主线进行二维方式的关联。
4.7.1 概念与解读
通过一维的排比图可以将由分析获得的要素与实际的业务线（流程、数据线）进行关联，给出哪些业务的环节需要进行改进或是增加功能。但是实现中的问题会比较复杂，不是都可以用一维的线形图解决，这里介绍利用二维的排比图表达更加复杂的问题和对策（以下将二维排比图简称为排比图）。
注：二维与一维的排比图的区别
二维比一维的排比图表达的信息更多。当同时要解决的问题和对策有很多时，使用二维排比图可以将诸多的要素（如问题、对策、部门、流程、活动等）清晰地、结构化地整合在一起，更加有利于相关人讨论、调整、找出对应的功能需求。
4.7.2 画法与场景
利用排比图，给出了不清晰的需求是如何通过梳理、转换，最终与清晰的功能需求关联起来的，这个过程也是一个逻辑梳理、逻辑表达的过程。
（1）分析结果：用分析模型对研究对象进行分析，得出问题、需求、难点等要素。
（2）关联转换：用排比图将分析结果与业务主线进行关联，找出对策。
（3）业务架构：将对策融入到实际的业务设计图中（架构图）。
4.8 架构模型1——拓扑图
拓扑图：将多个软件系统用网络图连接起来的表达方式。
4.8.1 概念与解读
随着企业推进信息化建设，信息系统的数量会越来越多，未来的发展趋势不会再去用一个系统包括全部的功能，而是会采用将不同功能分为数个独立系统的方式，这样更易于维护、扩展。选择拓扑图的目的不是为了做硬件的系统架构，而是借鉴它的概念、思路。
1）总线型结构
比较普遍采用的方式，它将所有的系统接到一条总线上。
2）星状结构
各个系统通过点到点的方式连接到一个中央系统上。
3）环状结构
将各个系统连接成一个闭合的环。
4.8.2 画法与场景
（1）企业内部有数个独立运行的系统，或是数个企业的系统进行互联（集团企业系统常见）。
（2）用来对系统进行初步的规划（粗粒度）。
4.9 架构模型2——分层图
分层图：将研究对象按照不同内容分成不同逻辑层的方法。
4.9.1 概念与解读
分层工作看似非常简单，但它却是分析与设计诸多手法中最为重要的基础技术，掌握分层的方法对于分析和设计师来说既是基础技术，也是最难的能力之一。
（1）范围：从全部层的划分可以看出构成对象的内容（对象分为①～⑤共5层）。
（2）层面：每个层里都是“同类”的内容（即内聚，①=业务，②=管理等）。
（3）主次：①～③层为主体，其中①最重要；以④为①～③支持，以⑤为①～④支持。
（4）方向：分层可以有纵向，也可以有横向，怎么表示效果最好主要看传达什么信息理念、场景。
4.9.2 画法与场景
对数据进行概要规划、分层后，通过分层可以针对不同层面的数据进行逐一的研究和设计，彼此不会发生相互影响。
4.10 架构模型3——框架图
框架图：用以对研究结果进行规划，确定范围、分区以及分区间的边界。
4.10.1 概念与解读
框架图主要是用来对研究对象进行全面、局部的规划，它可以给出对象的范围、对象内部的分区、分区的边界以及分区之间的关系。框架图的表达不拘泥于细节，是粗粒度的表达方式。框架图通常被用来作架构图中的顶层规划、架构总图。
（1）范围：框架图由3个区域构成，给出了全部的业务范围（由区域①、②、③组成）。
（2）区域：每个区域有主要的任务目标（①=主营业务，②=辅营业务，③=支持业务）。
（3）模块：每个区域内有若干个模块，每个模块的任务不同，以“主营业务”区域为例，其内部又划分为四个领域：①-1=销售，①-2=生产，①-3=采购，①-4=物流。
（4）边界：每个区域、模块的背景框给出了领域的边界。
（5）位置：由上下、中间与边缘的位置关系，可以看出主营、辅营与支持区域之间的关系。
● 主营区：是三个区域的中心位置（左上角为上）。
● 辅营区：是主营区的基础（②在①的下面）。
● 支持区：是对①、②的支持工作（③在①和②的侧面）。
（6）粒度：主营业务、辅营业务和支持业务，这三个区的粒度是相同的。
4.10.2 画法与场景
首先要确认分析成果用“框架图”表现是最适用的。
1）图的核心位置的概念
绘制一幅架构图与设计软件的界面是一样的，除去图的正中心以外，通常以图的左上角为“上”，因此在构图时，除去特意要放图的中心位置外，一般会将最为重要的内容放到左上角的位置。框架图是二维的，所以平面的布局非常重要。
框架图，是将分析的要素进行规划、进一步分类的主要手段，由于是平面布局，所以框架图具有最为容易观察、推敲、调整的特点。
“分区”是框架图设计中最为重要的步骤，用绘画的术语表达就是“布局”，要确定：
（1）不同功能的区域、边界；
（2）不同功能区的位置、相互作用关系；
（3）每个区域具有的独立功能。
2）分区的原则
（1）区的划分要遵循“一个区，一个目标”的原则。
（2）同一区域内的功能要“高内聚”，区内各个功能都为完成同一个目标而存在。同时该区域内包括的成分紧密相连、缺一不可。
（3）不同区域间要做得“低耦合”，当框架图的各个部分在外部的需求发生变化时，可以容易地进行调整、删除或是增加。
（4）同一区域内各个要素的粒度要一致，如都是子系统或都是模块。
适用于对研究对象进行全面、局部的规划。虽然软件系统不是按照框架图的形式进行开发的，但是设计图中没有框架图作为总体规划，感觉就像在看一本没有目录的书一样，找不到路线。所以，设计图中除去用拓扑图、分层图进行粗粒度的规划外，进行正式设计的第一幅图一定要使用框架图（可能不止一幅图）。
这是一个企业的信息系统规划图。可以看出图中使用了若干个背景框，每个背景框都是一个分区设计。
4.11 架构模型4——分解图
分解图：是对研究对象的有序分离或是对细粒度要素有序归集的表达。
4.11.1 概念与解读
分解图的目的有两个：一是自上而下的“分解”，二是自下而上的“汇集”。不论是分解还是汇总，都是从上向下绘制的，因此将此类图统称为“分解图”。
1）分解的目的
主要用来表现将一个对象由上而下、由粗到细地进行“分解”，如此可以找出这个对象是分为几层、由哪些要素构成的，分解图的要素通常分为两类：数字型和文字型。
（1）数字型：将一个大的合计数值进行逐级的分解，直至找到最下层的原始数据。
（2）文字型：对目标、工作、任务、组织、问题等进行分解。
2）汇集的目的主要用来表现由很多的细小要素经过多层汇总，最终集成为一个大的数值／目标，是一个归属的概念。
（1）数字型：将原始数据（表单）依次汇总、集成为一个大的结果（如报表集成）。
（2）文字型：对成果、报告、信息等进行逐层的汇总。
4.11.2 画法与场景
任何可以向下一级进行拆分的对象，都可以绘制它的分解图。
例如：
● 功能：系统→子系统→模块→功能。
● 组织：行业→企业→部门→岗位→角色。
● 工作：企业经营→财务→预算→报销→支付。
● 物品：材料分类→设备分类→固定资产等。
4.12 架构模型5——流程图
流程图：一组为完成特定目标而进行有序活动的过程表达。
4.12.1 概念与解读
（1）目标：流程，必须要有一个明确的任务目标，这个目标多用流程的名称来表示，如报销申请流程、物资采购流程、合同支付流程等。
（2）方向：用标准的图形符号表示出流程将要完成目标的方向，即起点（s）、方向（→）、终点（e）。
（3）节点：完成目标需要多少个节点，节点数=6个。
（4）顺序：完成流程的顺序、前后关系（节点1→节点2→…）。
（5）分歧：在哪个地方会发生流程的分歧，即流程从节点“1．签约”出发，根据分歧条件的约定，流程可以走向节点“2．设计”或是走向节点“4．采购”。
（6）主次：可以看出有主流程和次流程两条线，主流程=签约～核算，次流程=采购。
4.12.2 画法与场景
企业有规律的生产活动都是采用业务流程的方式表达的，因此对企业进行的标准化工作之一就是业务流程的标准化。使用流程图可以描述所有具有有序作业的过程。流程图可以用来描述两类场景：业务处理过程，审批处理过程。
（1）业务处理过程（业务流程）：材料采购流程、预算编制流程、项目管理流程等。
（2）管理控制构成（审批流程）：报销审批流程、投标审批流程、合同审批流程等。
4.13 其他模型——交互图
交互图：以干系人的交互工作为主线的有序活动过程表达。
这个模型比较特殊，它是一种有角色表达的模型，既可以用来进行分析，也可以用来进行架构设计。
4.13.1 概念与解读
模型中为什么要出现干系人呢？干系人对模型的表达又会产生什么影响呢？首先了解一下什么样的研究对象需要有干系人参与。
1）适合于引入干系人的场景在具有“窗口”特点的业务场景描述时，显示干系人会起到很好的理解作用。例如，银行窗口内／外的银行员与顾客、超市收银台前／后的顾客与收银员、图书馆借阅柜台两端的读者与图书管理员、医院取药窗口内外的药剂师与患者、讲台前／后的学生与老师、快递员与下订单的顾客等。因为“窗口”内外的干系人的角色是固定的，定义是清楚的，而且是不能互换的，所以在分析这些场景时引入干系人的概念可以帮助理解事物的关系，而且有利于发掘出更多的需求和确认需求。
不表现干系人，就无法说清楚活动的场景；或者加入了干系人可以让事物的逻辑表达得更加清晰的场景等，就需要采用这个交互模型来表达，让干系人充分地展现出他们之间的逻辑关系，这个关系包括“事”与“物”的内容。
2）不适合引入干系人的场景
在分析没有“窗口”做界线的业务场景时，例如，企业的采购流程、成本分析、销售战略、合同管理、财务管理等，引入干系人可能反而会影响分析结果的正确性。
当然，在分析和设计完成后，采用加入具体的组织、干系人要素对结果进行验证是可以的，在设计完成后设计师与客户进行推演验证时，需要做业务设计的回归，此时利用泳道式流程图的方法加入部门、角色等要素可以帮助客户理解流程的设计，但要注意，此时的干系人是出现在“人-机-人”环境中的角色，他们可能与“人-人”环境中的干系人不一样，他们是按照实现了信息化管理后的情况重新设定的干系人。
4.13.2 画法与场景
1）适用的场景交互图不但适用于分析，而且也适用于架构设计，例如：● 适合于用来建立低层级的业务活动关系。● 适合于用来进行细粒度的复杂关系分析，例如窗口类型的对象。● 适合于做细粒度的业务架构设计，如窗口类型的对象。
2）不适用的场景不适合做顶层设计／规划、大粒度的架构设计。
小结
绘制逻辑图的方式有很多，可以说每个人可能都会有自己习惯的画法，但是，如果这个逻辑图是用于多方（客户、业务、技术等）沟通的资料，那么图形和绘制方法至少就要满足三个基本要求：共同认知、绘图标准和使用约束。
1．共同认知
因为企业信息化这个课题所描述的对象都是抽象的事、行为，而不是具体的物，所以绘制的图形一定要具有普遍的代表性和辨识性，通过简单解释或是完全不用解释就可以让读者看明白图形的含义，因此分析和架构用模型都是比较成熟、有一定代表性的，如鱼骨图、分解图、流程图。
2．绘图标准
不同的人绘制同一个业务处理过程的“流程图”，如果不采用同样的标准，就会产生歧义（哪怕是小的不一致），那么这个流程图就只能用作“示意图”来传递大概的意思，而不能够作为正式的“设计图”来使用了。
3．使用约束
不同的模型用于描述什么场景、表达什么含义、传递什么信息都要符合模型的使用条件，否则就会发生“图不达意”的现象。
用图表达想法、传递信息是最为直观、高效的方法，再者，我们通常会说高手是能够做到用简单方法解决复杂的问题，绘图其实也是一样的道理：先将复杂的问题拆分为简单的问题，然后再用简单的方法解决和表达简单的问题。
