【组合原理】如何通过图去表达业务

119 阅读9分钟

前言

对于程序员来说与别人交流是很困难的,更何况是与客户产品交流模块、系统上的设计,那就难上加难了。为了方便别人沟通交流,更好的方式就是通过图形的方式更加直观的展现业务的流程或者架构。组合原理就是通过图形的方式去表达、分析设计的成果。接下来将会详细介绍如何去选择图形,以及画出对应的图形。

定义与概念

组合原理通过要素、模型、逻辑三个元素来表达任意逻辑图。如果是基于100 种场景抽取出来的逻辑图,在101场景下可能不适用,组合原理要满足的就是不论是什么业务应用场景,仅通过有限“元素”组合就可以表达。

三个元素

1. 要素

在画图之前,我们需要先确认要表达的是哪些要素,一开始的时候我们列举了100个的要素,然后就准备对这些要素进行处理,就会感觉特别头大。别慌,咱们可以根据要素的属性进行分类。

粒度和层级

有一些属性的粒度和层级是不一样的,如下图所示:

image.png

询价和签约与销售要素不一样,但是可以归纳为采购要素,编制和审核要素和询价要素又不一样,但是属于签约要素中两个流程,如果按照层级和粒度的不同,将要素进行区分,就会更加直观的画出流程。

黑盒与白盒

可能根据粒度区分要素会有些困难,那我们可以通过黑盒白盒的方式,想象这些要素都是一个个盒子,如果这个要素a属于要素b,那就把要素a放到要素b盒子中,如果不属于,那就再与下一个盒子进行比较,如果都不属于,那就自称为一级要素。如下图所示:

image.png 有财务、销售、生产盒子,财务盒子中有预算、收入、支出等要素,还可以再往下,比如成本盒子中有材料、工资等等要素

系统与模块

在开发的过程中,我们都会遇到XX系统、XX模块、XX功能等术语,但是他们之间的关系是什么呢?由于系统、模块和功能这三个词在不同的场合、面对不同的描述对象时定义都不同,这样就容易给读者带来困惑,我们可以约定:

  • 系统:具有独立处理某个业务领域工作的完整功能体,系统是由模块组成的。
  • 模块:是分担系统中局部处理工作的,模块是由功能组成的。
  • 功能:是系统中完成某个业务处理的最小独立单位

这三者的粒度关系是:系统 > 子系统 > 模块 > 功能,如下图所示:

image.png 可以分为主营区系统、辅营区系统和支持区系统,其中主营区系统又可以分为销售管理子系统、采购管理子系统等,采购管理子系统中又可以分出比如签约、询价模块等,最后再将签约模块细分成编制、审核等更小的功能。

解耦与内聚

分层与粒度的概念,说明了要素的粗细;系统与模块的概念,说明了要素的归集单位。将不该放到一起的要素放到了同一个黑盒内,就会造成在讨论黑盒之间的关系时,由于不同黑盒内部的细节相互牵扯,可能无法将盖子盖上形成黑盒状态。那么什么样的要素可以放在一起,什么样的要素不能放在一起呢?解决这个问题需要引入解耦和内聚的概念。我们可以先看看耦合的要素是什么样子的,如下图所示:

image.png

系统1内部的要素与系统3和系统2内部的要素相互依赖,这个状态就是紧耦合,系统4的内部要素没有与其他系统的内部要素相互依赖,这个状态就是松耦合。最好的系统与系统内部要素之间的状态是松耦合状态,如下图所示: image.png 真正的依赖关系是系统与系统之间,而不是系统中的要素与要素之间的关联。

好了,咱们说完了要素元素,再说说第二个元素,那就是模型。

2. 模型

模型主要分为两大类型,即:分析模型、架构模型。

分析模型

分析模型,是建立分析要素与推测结果之间的关联关系,多用于表达“非优化类对象[1]”的分析结果,主要是为了更好的分析出对应的要素。推荐的有4种分析模型,从粗到细的粒度分别为关联图、鱼骨图、思维导图、排比图。

关联图 分析对象所包含的要素未必都具有可以结构化的特征,现实中有很多业务场景是非常复杂、耦合度高、难以拆分的,因此,关联图的引入主要是为了解决这类问题。如下图所示: image.png 每个要素之间都有关系,可能两两相关,也可能没有关系。

鱼骨图和思维导图

它们不但具有较强的方向性,而且还可以自由、发散地收集相关的要素,并在使用中可以边拓展边收集,在收集要素的过程中就完成了对要素的梳理。鱼骨图如所示:

image.png 可以更好的列出一些导致这个结果的原因。

思维导图如下所示:

image.png

排比图 具有一定的结构化形式的模型,这样的模型易于给出分析成果的规律性、收敛方向等,在调研、分析的现场就有很好的实用性,可以比较容易地建立起分析结果与业务架构(流程图)之间的对应关系,加快分析与设计的速度。它是“分析模型”与“架构模型”之间的桥梁。

image.png

架构模型

架构模型,是表达符合业务逻辑关系的要素结构图,多用于表达“优化类对象[2]”的设计结果。推荐的有5种分析模型,从粗到细的粒度分别为拓扑图、分层图、框架图、分解图和流程图。

拓扑图

主要用来做最粗的规划设计,它不但可以用于一般的业务架构,也可以为未来参与软件设计做一些实用知识的铺垫。适用于表达项目包含有多个不同目的的业务板块,板块分别部署的业务场景,参考图形如下所示:

image.png

分层图

适用于表达对分离结果进行粗略估计的场景,如下图所示:

image.png

框架图

适用于表达设计对象的整体规划,顶层设计的场景,如下图所示:

image.png

分解图

适用于表达对要素进行细分(分层、分组)的场景,如下图所示:

image.png

流程图

适用于表达具有明确操作顺序的业务处理过程的场景,如下图所示:

image.png

模型的关系

那么该如何去选择模型呢?为什么有分析模型又有架构模型呢?如下图所示:

image.png

我们可以先通过分析模型中的鱼骨图头脑风暴罗列出一堆导致成本超标问题的原因,再通过架构模型中的流程图,将每一个原因变成对应的解决方案也就是对应的流程,因此在业务架构图中已经不能直接看到原来的问题要素了。

虽然分析工作与架构工作的目的都是用要素来构成一张图,但作图的方法也是有区别的。

  • 分析:是用“归集要素”的方法作图,归集后要素的承载结构是分析模型。
  • 架构:是用“组合要素”的方法作图,组合后要素的承载结构是架构模型。

3. 逻辑

在字典中,逻辑(logic)是一个音译词,指的是思维,是一个外来词语音译。狭义上,逻辑即指思维的规律、理清事物的本身。广义上,逻辑泛指规律,包括思维规律和客观规律。我们可以定义为三个核心内涵:

  1. 规律:要素之间内在的、稳定和反复出现的关系。
  2. 顺序:要素的位置关系,包括前后、上下、左右。
  3. 规则:保证按照规律、顺序运行的约束。

为什么需要逻辑呢?它的作用是什么?如下图所示:

image.png 架构方案1和架构方案2都是五个要素,分别是成本管理、人工管理、材料管理、设备管理、合同管理等,使用的模型也都是分解图模型,对于架构方案1来说,签订合同之后不需要经过成本管理系统,而架构方案2则需要经过成本管理系统,这其中的差异就是逻辑。不同的逻辑导致的流程、方案、设计结果就会有所不同。

不同的业务对应的逻辑表达方式也会有所不同,如下图所示:

image.png

有用文字表达的逻辑,它需要通过“阅读”的方式获取逻辑(直接看不出来),还有就是使用图形“符号”表达逻辑,也有使用“线条”表达逻辑。

总结

组合原理是对研究对象利用三元素,按照信息化环境下的要求进行重新的组合,解决的是如何合理地利用逻辑、模型来整合要素。

通过对要素属性(粒度/分层、黑/白盒、系统/模块以及解耦/内聚)的理解和掌握,确认模型,用眼(观察)和脑(思考)进行分析和梳理逻辑,就有了如何切入研究对象的方法,运用好这些观察和思考的方法画出对应的设计图,可以大幅度地提升工作效率,减少不必要的思考和沟通成本。

  • [1] 非优化类对象: 指尚未实现的业务(如:一个问题、一个现象或是一个全新领域的业务等)。这类对象的研究要先从理解对象开始,再寻找构成对象的要素、逻辑,再进行对象优化。非优化类对象没有参照物,信息化是从零开始,是全面创新的过程。
  • [2] 优化类对象:指已存在并运行着的业务体系。优化指采用信息化方法改进、完善既存的业务,实现效率、效益的提升。优化类对象有实际参照物,调研、分析阶段可以与实际现状进行对比验证,是创建加完善的过程。