精华内容
下载资源
问答
  • 这个做法是不对的,数据逻辑来源于业务逻辑,需求分析师能够向程序员说明数据逻辑关系,那么后者的工作效率会提升很多(否则、不熟悉业务的后者还要花费很多时间去研究业务逻辑)。同时是否能够清楚地表达数据逻辑...

    前一篇介绍逻辑中的“业务逻辑”表达方式,这一篇介绍“数据逻辑”的表达方式。

    多数没有开发背景的需求工程师对数据面层的分析、设计是比较生疏的,面对比较复杂的数据关系时或多或少都有一些畏惧,不太愿意深究,尽量交给后续的程序员去处理。这个做法是不对的,数据逻辑来源于业务逻辑,需求分析师能够向程序员说明数据逻辑关系,那么后者的工作效率会提升很多(否则、不熟悉业务的后者还要花费很多时间去研究业务逻辑)。同时是否能够清楚地表达数据逻辑关系也说明了需求分析师具有的能力和水平。

    1. 数据逻辑的概念

    ■数据逻辑:表达的是数据层数据之间的逻辑关系,这个层的要素是数据。

    为了理解数据逻辑,要先理解为什么存在着业务逻辑和数据逻辑二种不同的表达形式呢?这首先是因为两者存在于不同的层面上、且要素不同。

    1)业务逻辑
    表达的是以客户“活动、规则”等内容为要素的逻辑关系。
    业务逻辑表达的是业务活动之间的关系,是以客户的业务知识、业务事理为基础的。
    举例说明,图1是一个生产过程的业务架构图(流程图),我们对客户业务的理解首先是从业务架构图获得的,从图的表面上只看到业务活动之间的关系,如:活动“4.采购”完成后下一个活动是“5.物流”。

    在这里插入图片描述

    图1 生产流程图

    在表面上虽然直接看不到数据的存在,但是在两个活动之间的关联线中流动着如下的数据:采购物品名称、数量、单价、交付日期等。

    2)数据逻辑
    表达的是以“数据”为要素的逻辑关系。
    数据逻辑是数据间的关系。数据架构层在业务架构层的下面,图2是一个业务逻辑与数据逻辑关系的示意图。从业务架构图上是不能直接看到数据逻辑的,数据是业务活动产生的结果(沉淀),数据逻辑的获取是依赖于业务逻辑的,但在数据获取后,数据间的引用关系要远多于业务活动间的关联关系,如图2所示。
    数据逻辑虽然来源于业务逻辑,反过来数据逻辑又是业务逻辑合理存在的内在支撑。

    在这里插入图片描述

    图2 业务逻辑与数据逻辑关系的示意图

    确认了存在着数据之间的逻辑关系,那么这个逻辑表达形式是什么样的呢?数据逻辑的表现形式有很多,本篇的目的是支持业务需求的分析工作,因此从“业务的视角”给出数据逻辑的表达方法(而不是从技术视角)。

    3)数据逻辑的表达形式
    这里介绍业务分析用的三种数据逻辑表达形式:线、表、图,参见图3,其中
    图(a)线:是用数据表的业务编号,作为连接数据表、数据之间的关系(主/外键);
    图(b)表:指的是数据表,用表格结构表达出数据之间的上下、父子、从属等的关系;
    图(c)图:用图的形式,给出数据之间的关联关系,如:算式图、数据线、勾稽图;

    在这里插入图片描述

    图3 数据逻辑的表达方式

    2. 数据逻辑表达的简介

    1) 用线表达数据逻辑(主/外键)
    以下面的合同书的数据表为例,说明主键和外键的定义和关系,参见图4。
    (1)主键,是本数据表的代表名称,一个数据表里只能有一个主键,它只能是唯一地标识表中的每一行,通过它可强制数据表的完整性。它用于与其他表的关联,以及本记录的修改与删除等。
    (2)外键,当一个表中除了本表的主键外,还保存了其它数据表的主键时,那么在本表中其它数据表的主键就被称之为“外键”。根据参照外部数据表的数量多少,一个数据表中可以有复数的外键。

    在这里插入图片描述

    图4 数据表之间的主外键关系示意图

    2)用表表达数据逻辑
    数据表,是按照一定的结构形式排列的数据格式,任何数据的载体都是数据表。用“格式”描述数据表的形式,格式包括了数据结构、数字分类、数据状态等三类内容,参见图5。
    □数据结构:列表结构、树表结构等;
    □数字分类:数值、货币、文本、日期、分数等;
    □数据状态:表达在导入上游功能的数据时,该功能所处的状态,比如:编辑期限已过、功能被锁定、审批已完成、数据已被引用等。

    在这里插入图片描述

    图5 数据表格式示意图

    3)用图表达数据逻辑
    当遇到了非常复杂的计算,比如:数据来源多、计算公式复杂且需要进行多重计算等,需求分析师如何才能做到准确、快速地向程序员说明计算公式和数据呢?此时仅靠用文字说明就非常困难了,即麻烦、又不准确,使用逻辑图是一个非常好的方法,这里简单地介绍一下算式关联图的用法。

    算式关联图的应用场景是:在某个“节点”上有多个数据来源的汇总、计算。这个计算式可以是存在于活动功能、看板功能或报表功能中的某个处理步骤,这个计算式涉及到了复杂的数据来源、引用、关联及多重的计算。
    算式关联图的模型包括了两大部分:数据的来源和数据的处理。见图6。

    假定在图a.的“L-021采购流程”的B节点①上有一个计算处理,这个计算需要用到A、B、Q节点、以及其他数据库的数据,表达B节点计算过程的方式如下。

    在这里插入图片描述

    图6 算式关联图

    下面分别对算式关联图的各个部分进行详细说明。

    (1)数据来源
    数据来源图部分,是用来说明包含有计算功能的位置、以及其它参与计算的数据来源:

    □绘制采购流程L-021,该流程上节点A和节点B中的数据参与了计算,另外,不在流程上的独立活动Q中的数据也参与了计算;
    □标注出发生了“成本核算”处理的活动B在该流程上的位置(可以采用不同的颜色);
    □标注出每个活动上参与计算的数据表名称,比如:活动A/表a(在流程上的功能)、活动Q/表q(非流程上的功能);
    至此,标示出了计算公式的位置和3个数据的来源,完成了数据来源的说明。

    (2)数据处理
    数据处理图,是建立数据表b的计算处理模型,其中:

    ②表b:因为计算公式在发生在功能B上,因此将功能B的数据表b放到处理图的左上角;
    ③其它的数据来源分列在处理图的两侧(布局的要求仅作为参考),比如
    □数据源1:将来源于活动类的数据,如:表a、表q,置于处理图的左侧,表b的下方;
    □数据源2:将来源于数据库的数据,如:基础数据、过程数据库,置于处理图的右侧;
    ④计算数据:在表内写入参与计算的变量名称、数值,并用箭头线将数据表指向处理器;
    ⑤计算名称:计算处理器⑤的上面要标明算式的名称,如:成本核算;
    ⑥计算过程:将各数据来源的具体数值带入到计算过程⑥的公式中,格式必须要给出分步计算的过程,必须要让程序员可以读出来每一步的计算公式与对应的计算结果;
    ⑦计算结果:将最终的计算结果填入计算结果栏⑦,到此完成全部的计算过程;
    ⑧如果某个步骤的内容比较复杂,可以在实体、或是数据旁边,加入一些说明文;

    可以看出来,算式关联图实际上就是一个为解决某个特定问题而建立的用例图。

    ■扩展说明
    由谁来规划数据和建立数据标准?在软件企业中有不少人认为:只要是数据相关的设计就是程序员的工作,其实不然,业务层面与技术层面对数据的设计方法是不同的,技术层面的数据设计不能替代业务层面的数据设计,相反,没有很好的业务层面的数据设计做支持,技术层面的数据设计缺乏依据、容易发生重复调研、分析和设计的现象,工作效率低。

    与技术层面的数据设计不同,业务层面重点做的不是数据“库”的设计,而是业务数据的逻辑设计,由于业务和技术的视角不同,数据关系图的表达内容和方式也不同,参见图7中的两张图就可以看出它们之间的区别,区别的关键点还是在于业务逻辑的有无,
    □业务视角的数据关系图(a):有业务流程,带有清晰的业务逻辑关系;
    □技术视角的数据关系图(b):用“键”的形式替代了业务逻辑的表达形式,但是要注意,这个“键”的设计依据或直接、或间接地参考了业务逻辑。

    在这里插入图片描述
    图7 数据关系图

    只有从业务设计的视角,充分地理解业务数据的内容、用途、业务数据之间的逻辑关系、以及未来可能的变动规律等,才能保证不论业务如何变化数据的结构都是稳定的。

    消除企业信息孤岛现象,首先是业务设计师要解决的问题,因为这个问题的本质不是数据库问题,也不是技术开发工程师单独能够解决的问题。

    下一篇介绍逻辑图三元素之三的“模型”的表达。

    详细的内容说明请参见《大话软件工程—需求分析与软件设计》一书。

    在这里插入图片描述

    展开全文
  • 前一篇介绍逻辑中的...这个做法是不对的,数据逻辑来源于业务逻辑,需求分析师能够向程序员说明数据逻辑关系,那么后者的工作效率会提升很多(否则、不熟悉业务的后者还要花费很多时间去研究业务逻辑)。同时是...

    前一篇介绍逻辑中的“业务逻辑”表达方式,这一篇介绍“数据逻辑”的表达方式。

    多数没有开发背景的需求工程师对数据面层的分析、设计是比较生疏的,面对比较复杂的数据关系时或多或少都有一些畏惧,不太愿意深究,尽量交给后续的程序员去处理。这个做法是不对的,数据逻辑来源于业务逻辑,需求分析师能够向程序员说明数据逻辑关系,那么后者的工作效率会提升很多(否则、不熟悉业务的后者还要花费很多时间去研究业务逻辑)。同时是否能够清楚地表达数据逻辑关系也说明了需求分析师具有的能力和水平。

    1. 数据逻辑的概念

    ■数据逻辑:表达的是数据层数据之间的逻辑关系,这个层的要素是数据。

    为了理解数据逻辑,要先理解为什么存在着业务逻辑和数据逻辑二种不同的表达形式呢?这首先是因为两者存在于不同的层面上、且要素不同。

    1)业务逻辑

    表达的是以客户“活动、规则”等内容为要素的逻辑关系。

    业务逻辑表达的是业务活动之间的关系,是以客户的业务知识、业务事理为基础的。

    举例说明,图1是一个生产过程的业务架构图(流程图),我们对客户业务的理解首先是从业务架构图获得的,从图的表面上只看到业务活动之间的关系,如:活动“4.采购”完成后下一个活动是“5.物流”。

    98f77b3e596814b6f2425cc6d9f7d9c7.png

    图1 生产流程图

    在表面上虽然直接看不到数据的存在,但是在两个活动之间的关联线中流动着如下的数据:采购物品名称、数量、单价、交付日期等。

    2)数据逻辑

    表达的是以“数据”为要素的逻辑关系。

    数据逻辑是数据间的关系。数据架构层在业务架构层的下面,图2是一个业务逻辑与数据逻辑关系的示意图。从业务架构图上是不能直接看到数据逻辑的,数据是业务活动产生的结果(沉淀),数据逻辑的获取是依赖于业务逻辑的,但在数据获取后,数据间的引用关系要远多于业务活动间的关联关系,如图2所示。

    数据逻辑虽然来源于业务逻辑,反过来数据逻辑又是业务逻辑合理存在的内在支撑。

    096dbdc2077f60a93f9de40490b6fe2b.png

    图2 业务逻辑与数据逻辑关系的示意图

    确认了存在着数据之间的逻辑关系,那么这个逻辑表达形式是什么样的呢?数据逻辑的表现形式有很多,本篇的目的是支持业务需求的分析工作,因此从“业务的视角”给出数据逻辑的表达方法(而不是从技术视角)。

    3)数据逻辑的表达形式

    这里介绍业务分析用的三种数据逻辑表达形式:线、表、图,参见图3,其中

    图(a)线:是用数据表的业务编号,作为连接数据表、数据之间的关系(主/外键);

    图(b)表:指的是数据表,用表格结构表达出数据之间的上下、父子、从属等的关系;

    图(c)图:用图的形式,给出数据之间的关联关系,如:算式图、数据线、勾稽图;

    cf4dbd26c5e5b8876c3ccf19bceb753f.png

    图3 数据逻辑的表达方式

    2. 数据逻辑表达的简介

    1) 用线表达数据逻辑(主/外键)

    以下面的合同书的数据表为例,说明主键和外键的定义和关系,参见图4。

    (1)主键,是本数据表的代表名称,一个数据表里只能有一个主键,它只能是唯一地标识表中的每一行,通过它可强制数据表的完整性。它用于与其他表的关联,以及本记录的修改与删除等。

    (2)外键,当一个表中除了本表的主键外,还保存了其它数据表的主键时,那么在本表中其它数据表的主键就被称之为“外键”。根据参照外部数据表的数量多少,一个数据表中可以有复数的外键。

    cbf6ec7d4a9b714856f5eb0f82101124.png

    图4 数据表之间的主外键关系示意图

    2)用表表达数据逻辑

    数据表,是按照一定的结构形式排列的数据格式,任何数据的载体都是数据表。用“格式”描述数据表的形式,格式包括了数据结构、数字分类、数据状态等三类内容,参见图5。

    □数据结构:列表结构、树表结构等;

    □数字分类:数值、货币、文本、日期、分数等;

    □数据状态:表达在导入上游功能的数据时,该功能所处的状态,比如:编辑期限已过、功能被锁定、审批已完成、数据已被引用等。

    513374c532abd0df9233eb8a035edcc9.png

    图5 数据表格式示意图

    3)用图表达数据逻辑

    当遇到了非常复杂的计算,比如:数据来源多、计算公式复杂且需要进行多重计算等,需求分析师如何才能做到准确、快速地向程序员说明计算公式和数据呢?此时仅靠用文字说明就非常困难了,即麻烦、又不准确,使用逻辑图是一个非常好的方法,这里简单地介绍一下算式关联图的用法。

    算式关联图的应用场景是:在某个“节点”上有多个数据来源的汇总、计算。这个计算式可以是存在于活动功能、看板功能或报表功能中的某个处理步骤,这个计算式涉及到了复杂的数据来源、引用、关联及多重的计算。

    算式关联图的模型包括了两大部分:数据的来源和数据的处理,见图6。假定在图a.的“L-021采购流程”的B节点①上有一个计算处理,这个计算需要用到A、B、Q节点、以及其他数据库的数据,表达B节点计算过程的方式如下。

    fcc910b24100c0cdb71beee55fba1a1f.png

    图6 算式关联图

    下面分别对算式关联图的各个部分进行详细说明。

    (1)数据来源

    数据来源图部分,是用来说明包含有计算功能的位置、以及其它参与计算的数据来源:

    □绘制采购流程L-021,该流程上节点A和节点B中的数据参与了计算,另外,不在流程上的独立活动Q中的数据也参与了计算;

    □标注出发生了“成本核算”处理的活动B在该流程上的位置(可以采用不同的颜色);

    □标注出每个活动上参与计算的数据表名称,比如:活动A/表a(在流程上的功能)、活动Q/表q(非流程上的功能);

    至此,标示出了计算公式的位置和3个数据的来源,完成了数据来源的说明。

    (2)数据处理

    数据处理图,是建立数据表b的计算处理模型,其中:

    ②表b:因为计算公式在发生在功能B上,因此将功能B的数据表b放到处理图的左上角;

    ③其它的数据来源分列在处理图的两侧(布局的要求仅作为参考),比如

    □数据源1:将来源于活动类的数据,如:表a、表q,置于处理图的左侧,表b的下方;

    □数据源2:将来源于数据库的数据,如:基础数据、过程数据库,置于处理图的右侧;

    ④计算数据:在表内写入参与计算的变量名称、数值,并用箭头线将数据表指向处理器;

    ⑤计算名称:计算处理器⑤的上面要标明算式的名称,如:成本核算;

    ⑥计算过程:将各数据来源的具体数值带入到计算过程⑥的公式中,格式必须要给出分步计算的过程,必须要让程序员可以读出来每一步的计算公式与对应的计算结果;

    ⑦计算结果:将最终的计算结果填入计算结果栏⑦,到此完成全部的计算过程;

    ⑧如果某个步骤的内容比较复杂,可以在实体、或是数据旁边,加入一些说明文;

    可以看出来,算式关联图实际上就是一个为解决某个特定问题而建立的用例图。

    ■扩展说明

    由谁来规划数据和建立数据标准?在软件企业中有不少人认为:只要是数据相关的设计就是程序员的工作,其实不然,业务层面与技术层面对数据的设计方法是不同的,技术层面的数据设计不能替代业务层面的数据设计,相反,没有很好的业务层面的数据设计做支持,技术层面的数据设计缺乏依据、容易发生重复调研、分析和设计的现象,工作效率低。

    与技术层面的数据设计不同,业务层面重点做的不是数据“库”的设计,而是业务数据的逻辑设计,由于业务和技术的视角不同,数据关系图的表达内容和方式也不同,参见图7中的两张图就可以看出它们之间的区别,区别的关键点还是在于业务逻辑的有无,

    □业务视角的数据关系图(a):有业务流程,带有清晰的业务逻辑关系;

    □技术视角的数据关系图(b):用“键”的形式替代了业务逻辑的表达形式,但是要注意,这个“键”的设计依据或直接、或间接地参考了业务逻辑。

    5c4d65eab43b8ed1f311096471cdecd4.png

    图7 数据关系图

    只有从业务设计的视角,充分地理解业务数据的内容、用途、业务数据之间的逻辑关系、以及未来可能的变动规律等,才能保证不论业务如何变化数据的结构都是稳定的。

    消除企业信息孤岛现象,首先是业务设计师要解决的问题,因为这个问题的本质不是数据库问题,也不是技术开发工程师单独能够解决的问题。

    ■ 本系列下一篇博文:

    李鸿君:如何绘制逻辑图 — 9.模型的分类zhuanlan.zhihu.com

    详细的内容说明请参见《大话软件工程—需求分析与软件设计》一书。

    d697c0c585d9534bbb5772b7935841c4.png
    展开全文
  • 前面已经介绍了逻辑图三元素中的“要素”和“逻辑”表达方式,最后一篇三元素的之三“模型”的表达方式...又如:如果观者看到的是“鱼骨”,就知道作者要做一个归集的分析,给出因果关系的结论。 (2)模型选取的有误

    前面已经介绍了逻辑图三元素中的“要素”和“逻辑”表达方式,最后一篇三元素的之三“模型”的表达方式。最后就是如何将要素、逻辑整合为一张具有说服力的“逻辑图”。通常在选择用什么形式的图形来表达研究对象时,往往会首选大家比较熟悉的图形,这个图的形式和表达的意图存在着约定俗成的关联,已经获得了大家的认同,这个图形就是模型。

    有了要素、逻辑之后,为什么还有特别地说明模型呢?因为模型选择的正确与否会产生不同的结果

    (1)模型选取的合适
    则观者首先通过模型的外观就知道作者要表达什么意图、观者会按照模型的定义去确认作者的内容,比如:但观者看到的是“流程模型”,就知道作者展示达成某个目标的工作过程,他会沿着流程的起点研究工作的每个步骤。又如:如果观者看到的是“鱼骨图”,就知道作者要做一个归集的分析,给出因果关系的结论。

    (2)模型选取的有误
    当要素和逻辑表达都很准确时,如果把要素和逻辑整合在一起的载体选的不合适,则最终传递的意图还是会打折扣、或是将作者的意图表达错了。比如:当你要表达一个确定的工作目标、以及达成该目标工作步骤的前后顺序时,就应该首选“流程图”,如果你选择的不是“流程图”而是“思维导图”的话就可能图不达意了,因为用思维导图是表达可能哪些相关工作,而不是给出确定的工作前后顺序。

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

    1.分析模型

    ■分析模型,是建立分析要素与推测结果之间的关联关系。
    这里推荐的5种分析模型可以分为两类,第一类是在业内具有较高的认知度和使用频率、第二类是基于作者的实践经验设计而成,参见图1。分析模型有如下的特点:

    在这里插入图片描述

    图1 分析模型一览

    *1.鱼骨图:由日本的石川馨先生所发明,故又名石川图,也可称之为因果图。
    *2.思维导图:由英国的东尼博赞先生(Tony Buzan)所提倡。
    *3.排比图:④和⑤由作者整理、设计。

    1)①关联图
    分析对象所包含的要素未必都具有可以结构化的特征,现实中有很多业务场景是非常复杂、耦合度高、难以拆分的,因此,模型①的引入主要是为了解决这类问题。关联图看似简单,实际是为理解和表现最复杂对象场景而引入的。

    2)鱼骨图②与思维导图③
    它们不但具较强的方向性,而且还可以自由、发散地收集相关的要素,并在使用中可以边拓展、边收集,在收集要素的过程中就完成了对要素的梳理。

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

    2. 架构模型

    ■架构模型,是表达符合业务逻辑关系的要素结构图。

    1) 对模型的描述
    这里推荐的5种架构模型可以分为两类,第一类是在业内具有较高的认知度和使用频率、第二类是基于作者的实践经验设计而成,参见图2。架构模型有如下的特点:

    在这里插入图片描述

    图2 架构模型一览

    1) 拓扑图①
    为了开拓读者的思路,这里导入一款具有可以响应扩展、灵活部署的架构模型,主要用来做最粗的规划设计,它不但可以用在一般的业务架构,也可以为未来参与软件设计做一些实用知识的铺垫。

    2) 分层图②和框架图③
    用于复杂对象的第1级、第2级划分,起到了从粗粒度的规划→细粒度的设计的过渡作用,属于架构图中做概要层次描述的表达方法。

    3) 分解图④和流程图⑤
    这两个模型是采用结构化架构方法的核心,它们的作用是承接中粒度架构结果并向下做进一步的细分,属于架构图中做详细层次描述的表达方法。

    3. 两种模型的区别

    分析模型与架构类模型有什么区别呢?构成分析模型中的要素不一定有明确的、精准的逻辑关系,由于这个阶段要素之间的因果关系不清晰,此时无法使用精准的逻辑表达。

    分析类模型可以解决梳理、归集要素并给出分析结果的工作,但是分析模型不能直接用来做分析结果的解决方案,因为无法精准地表达逻辑关系,所以必须将分析得到的要素(业务、管理)融入到“业务架构(如:业务流程)”中,才能够发挥出作用。

    分析模型与架构模型的目的不同,它们之间的区别,从图3的(a)、(b)两张图的对比可以看出,将实际的业务内容(要素)加入到模型中,观察图形的变化,

    在这里插入图片描述

    图3 分析模型与架构模型的区别

    1)图(a)鱼骨图-成本超标问题 (分析模型)
    分析(a)给出的分析课题是研究成本超标问题,可以看出鱼骨图上呈现的分析要素都是 “意见、想法、现象、建议等”内容,它们是在调研中客户使用的语言,而不是通常设计中使用的业务设计用语,所以,“鱼骨图”+“非业务设计用语(客户用语)”,是不能用来表达解决方案中的“业务处理、管理控制等”内容的。

    2)图b.流程图-业务流程图(架构模型)
    再看架构图(b)的内容,采用的都是业务设计用语(业务属性),图形是严谨的、结构化,清晰地给出了目标、方向、流程、步骤等信息,也就是说,图(b)模仿的是真实的业务形态,所以也必须使用真实的业务设计用语(要素),流程上所有的节点之间必须用合理的逻辑相关联,这样的架构图才能够用来做业务的解决方案。

    分析模型可以表现分析成果、需要的功能等,但不一定能够表现出严谨的逻辑关系、可以执行的解决方案,所以分析与架构各自关注的是不同阶段的工作和结果,因此分析模型是不能够替代架构模型做架构图的。
    虽然分析工作与架构工作的目的都是用要素来构成一张图,但作图的方法也是有别的:
    □分析:是用“归集要素”的方法做图,归集后要素的承载结构是分析模型;
    □架构:是用“组合要素”的方法做图,组合后要素的承载结构是架构模型;

    ■扩展说明
    “模型”与“图”的区别
    “模型”也是图,称之为“模型”的图揭示了某种事物对象的规律,这个规律具有一定的普遍性,所以模型可作为具有类似规律研究对象的参考。

    一般称之为“xx图”的图形,只是表明对“xx”用图形来表达其含义,不强调它是否是一个具有代表性的“模型”。以生产流程图为例看两者的区分:

    在这里插入图片描述

    图4 生产流程图

    □流程模型:给出了有规律性连续活动之间的关系表达图形(与业务领域无关);
    □生产流程图:给出了用图形表达的“生产”过程、节点关系(与业务领域有关)
    当然,如果这个生产行为在生产领域具有一定的代表性,则这个“生产流程图”也可以称为“生产流程模型”。

    逻辑图绘制方法的总结

    到此,就完成了对逻辑图三元素的说明。不论描绘什么内容的逻辑图,都包含有这三种元素:要素、逻辑和模型,熟练度掌握了这三种元素的定义、用法,几乎没有不能表达的对象、事物。

    在这里插入图片描述

    但你需要理解一张内容较多、业务比较复杂的、同时也不太熟悉的逻辑图时,一定要从这三个元素入手,就可以快速的理解:

    1)判断模型的分类:知道了模型,就大概知道了作者要表达对象的哪个层面、维度的逻辑,如:
    □ 框架图 → 表达研究对象的范围、区分、模块的边界等关系;
    □ 流程图 → 表达研究对象的行为过程的起点、节点数、顺序、终点等;

    2)判断要素的合理性:要素表达的粒度/层级、内容划分的耦合性等是否符合要求;

    3)判断逻辑的正确性:根据业务知识、软件设计要求等,检查逻辑表达的方式是否正确;

    作为一种能力,不论你从事软件工程上的哪个岗位(咨询、需求、架构、开发、测试、实施等),逻辑思维、逻辑推理、逻辑表达等有关逻辑的能力都是必须的。这种能力是做好任何业务领域软件(ERP、电商平台、物联网等)的基础。

    能够用逻辑图完美、精准地表达、传递意图,是你展示自己才能的一个重要方式,同时也是其他人评估你能力的一个重要参考。

    各类模型的详细用法说明,请参见《大话软件工程—需求分析与软件设计》一书。

    在这里插入图片描述

    展开全文
  • 不论从事软件工程上的那个岗位,“粒度、分层”都是挂在嘴头上的常用语,它是说明对象“尺寸、位置”的重要属性。与别人交流时(不论采用语言、文字或是图形的方式),...拿捏好粒度和分层关系,是表达逻辑的重要方法。

    在上一篇文中已经介绍过了,要想绘制出正确的逻辑图,就要掌握绘制逻辑图的三元素,三元素中的第一位是“要素”。从本篇开始用4个篇幅介绍表达要素的属性。

    不论从事软件工程上的那个岗位,“粒度、分层”都是挂在嘴头上的常用语,它是说明对象“尺寸、位置”的重要属性。与别人交流时(不论采用语言、文字或是图形的方式),首先要确保双方对交流题目的认知是处在同一粒度、同一层面上进行的,否则就会发生“关公战秦琼”的笑话。拿捏好粒度和分层关系,是表达逻辑的重要方法。

    属性1:粒度与分层,它是对要素大小的属性描述。

    1. 粒度与分层的概念

    在上一篇中讲到了研究对象是由若干的要素构成的,如将研究对象图1“企业业务(a)”拆分后出现了要素(b),如果以其中的“财务要素”为对象再度进行拆分后,就会出现更下一层的要素(c),如此反复可以进行若干次,如何表达这个“对象-要素-对象”循环出现的现象呢?这就需要引入表达要素粗细的概念,将表达要素粗细的尺度称之为“粒度”。

    在这里插入图片描述
    图1 企业业务对象

    ■粒度:是表达对象中不同要素的“粗细”程度的尺度。
    粒度原指球状体的直径大小,比较细小的要素就包含在同类较粗的要素之内,如下图2(a)所示。也可以将不同粒度的要素,按照从粗到细、从上到下地放置在不同的“层”上,如图2(b)所示。

    ■分层:将不同粒度的内容归集到不同的层面上,是按照粒度大小的分类。
    可以层理解为是用不同网眼的筛子过滤要素一样,最大的留在上面,最小的到了最下层。

    在这里插入图片描述

    图2 粒度与分层的概念

    图中标出了对象“财务”中的3个要素的粒度关系,即:财务、财务-成本、成本-合同,显然它们由粗到细的包含关系是:财务>成本>合同,这就是所谓的“粒度”不同。

    【例1】
    再举一个广义的例子来扩展一下思维,将下面的12个单词(要素)绘制到一张图中:军事领域、经济领域、装甲车、大使馆、广交会、外交领域、陆军、教育领域、商务部、学校、考试、一等秘书。

    这些单词看上去杂乱无章,它们具有不同的类型、粒度,无法直接绘制成图形。采用粒度、分层的方法,对它们的梳理可以分为三步

    1)步骤1:首先从分类的角度将这些要素进行归类,归集出4个大分类,这4个分类名称同时也是各分类中粒度最大的要素,即:军事领域、外交领域、教育领域、经济领域。

    2)步骤2:根据与各领域名称的关系,将其余要素归集各个分类的下面
    A.1军事领域:陆军、装甲车
    B.1外交领域:大使馆、一等秘书
    C.1教育领域:学校、考试
    D.1经济领域:商务部、交易会

    3)步骤3:对同一分类的要素按照粒度放置在不同的层上
    比如:在同一分类“军事”中,按照粒度可以分出三层,它们之间的大小顺序为军事>陆军>装甲车,用层的方式来表达时就形成了:第1层=A.1军事、第2层=A.2陆军、第3层=A.3装甲车,
    绘制的图形如下所示。

    在这里插入图片描述

    图3 要素粒度的应用

    在表达第一层领域之间的关系时,就不要将小粒度的内容参与进来,如:交易会、一等秘书,它们之间没有直接的关联关系。另外,分层的表达方式不但可以表达大小(粒度)还可以表达顺序(上下)。

    2. 粒度的作用

    知道了粒度和分层的概念,那么这些概念在绘制逻辑图时的作用是什么呢?
    粒度和分层的概念在理解新事物、研究分析、绘制逻辑图时起着非常重要的“划分大小”的作用,特别是在研究和表达不熟悉的事物时尤为重要,它指导我们先从“顶层、大方向、总目标、核心价值等”等高处出发,从大粒度要素入手描述对象的构成。

    在进行比较复杂的业务分析或设计时,一定要注意相关要素之间的粒度对比,也就是通常说的“不要胡子眉毛一把抓”。如果将不同粒度的要素放在一起进行绘制逻辑图,这样做出表达出来的结论可能是混乱的,因为不同粒度的要素之间的逻辑关系、表达方式可能是不一样的。不分粒度、不分层次画出的图形,无论表现的多么漂亮都可能是无价值的。

    【例2】
    下面再用业务流程设计说明粒度的概念,如图4所示。
    使用粗粒度的要素形成的最上层的流程图,称之为“一级流程”,以此类推,可以有二级流程、三级流程等。

    在这里插入图片描述

    图4 要素粒度与业务流程的分级关系

    □一级流程:由大粒度的要素(如:系统级)构成;
    □二级流程:一级流程中的要素“采购(系统)”,是由若干中粒度要素(如:模块级)构成的,中粒度要素构成了二级流程;
    □三级流程:二级流程中的要素“签约(模块)”,是由若干小粒度要素(如:功能级)构成的,小粒度要素构成了三级流程;

    在绘制的一级流程(系统级)中如果同时掺杂着三级流程(功能级)的内容,这个逻辑图就不通了,比如:在一级流程的“采购”与“生产”之间,加入了三级流程的“审核”,观者就会感觉非常的突兀。
    粒度和分层的概念,不但是绘制逻辑图的重要手法,同时也是需求分析、设计的重要指导方针。

    ■ 扩展说明
    粒度和分层,不仅仅用在绘制逻辑图上,在用文字、语言表达时同样需要有粒度和分层的概念,比如:
    □ 你选取研究对象的粒度要合适,粒度过大,看不清对象的内容;粒度过小,细枝末节被放大影响了你对主线的关注。
    □ 你在讲话时要有层次感,要用语言将问题一层一层的剥开,由上到下、由粗到细、由外到里,逐渐地展开。

    详细的内容说明请参见《大话软件工程—需求分析与软件设计》一书。

    在这里插入图片描述

    展开全文
  • 如何绘制泳道

    万次阅读 2017-10-27 11:00:08
    如何绘制泳道(跨职能流程) “泳道” 如何定义? 泳道也叫跨职能流程,旨在展示工作流中每个步骤涉及的流程和职能部门。泳道流程是一种特殊的图表可以展示出一个商业过程之间的关系,并...
  • 如何绘制产品流程

    2019-05-08 15:25:10
    很多人拿到需求就火急火燎的开始画原型,然后画着画着觉得有些地方没有考虑到,又回头去改,如果在画原型之前,你能将自己的业务流程想...流程是一系列的逻辑关系(包含因果关系、时间先后、必要条件、输入输出)产...
  • 后续所有的设计和开发等工作都是基于对业务架构的展开,从业务架构的设计成果中可以获得业务逻辑、功能需求、数据关系等重要信息,表达业务架构的主要方法就是使用业务架构。表达准确的业务架构,应该不用说明...
  • 后续所有的设计和开发等工作都是基于对业务架构的展开,从业务架构的设计成果中可以获得业务逻辑、功能需求、数据关系等重要信息,表达业务架构的主要方法就是使用业务架构。 表达准确的业务架构,应该不用说明...
  • 泳道流程专注于价值活动之间的逻辑关系,更好地展示每个价值活动的责任。流程描述一个过程的步骤,当这个过程涉及许多不同的人,部门或功能区域时,很难跟踪每个步骤的负责人。解决此问题的一个有用方法是把流程...
  • 本周又是一种新的绘图技能,这周分享泳道绘制方法。有没有人连泳道是什么都不知道的?请举手~不过就算不知道也没关系,3...泳道流程专注于价值活动之间的逻辑关系,更好地展示每个价值活动的责任。泳道绘...
  • 有时候我们需要在PPT中插入组织结构,来表现不同部门之间的关系。...01 思维导图绘制这种结构从逻辑上看,内核是多重总分关系的嵌套,我们也可以称这种结构为树状结构,它满足MECE原则。MECE原则(...
  • 流程是一系列的逻辑关系(包含因果关系、时间先后、必要条件、输入输出)产品经理做需求前一定要先把这些逻辑关系理清楚,如果非要用一句话概括的话“流程就是在特定的情境下满足用户特定需要的总结”。产品流程...
  • 通常来说,我们绘制架构的目的就是为了解决团队之间的沟通障碍,通过架构很便捷的其他成员进行沟通,减少歧义,最终让整个团队成员能够达成共识。二、系统架构有哪些分类?系统架构最经典的是4+1视图,分别...
  • 泳道拥有可以清晰的表述关系和直观的逻辑关系等特点,都可以有效的帮助业务员进行人事管理和程序软件开发。 1、计算机维护功能流程。计算机的每个程序之间都是有固定联系的,所以泳道可以有效的帮助整理不同功能...
  • 通常来说,我们绘制架构的目的就是为了解决团队之间的沟通障碍,通过架构很便捷的其他成员进行沟通,减少歧义,最终让整个团队成员能够达成共识。二、系统架构有哪些分类?系统架构最经典的是4+1视图,分别...
  • 论文研究-一种新的微机辅助绘制网络方法.pdf, 本文讨论在网络活动的逻辑关系已知的情况下,如何利用微机直接绘制网络的问题,同时也研究大型网络在微机上的显示与绘图问题。
  • 今天我们来谈谈业务流程如何绘制的?可能有些测试工程师就会说:——这个我们必须要会吗?开发工程师不是可以帮忙绘制吗?这就好像问测试工程师需不需要会数据库一样。那么为什么要绘制业务流程?我们都知道,...
  • 通常来说,我们绘制架构的目的就是为了解决团队之间的沟通障碍,通过架构很便捷的其他成员进行沟通,减少歧义,最终让整个团队成员能够达成共识。二、系统架构有哪些分类?系统架构最经典的是4+1视图,分别...
  • ---如何编写与应用递归函数),从中我们知道,利用递归解决问题的分析方法主要分为两个步骤:第一步是分析出递归算法的核心递归逻辑,即分析出第n步与第n-1步间的递归逻辑关系。第二步则是要找出递归的最终结束条件,...
  • graphviz dot uml类图绘制笔记

    千次阅读 2014-01-04 10:30:43
    不过总的来说如果要关要逻辑思维去理解在有些情况下,可能会很有难度。这也就可以解释为什么近几年来可视化领域的发展是如何的速度,人们对于图形的理解要比数字快多了。 至于为什么用的是dot,而不是其他,很重要的...
  • 逻辑结构设计的任务,就是把在概要结构设计阶段建立的基本 E-R ,按选定的关系数据模型的原则转换成相应的数据库模型。 本节将介绍如何将 E-R转化为关系模型和数据库模型关系数据库模式 用二维表的形式...
  • 泳道流程:跨职能流程

    千次阅读 2019-06-18 22:40:18
    什么是泳道?...泳道流程本现了价值活动之间的逻辑关系,还明确地表明每个价值活动的责任。 先看一看泳道流程: 那么,应该如何绘制泳道呢? 在跨职能流程中,通常一栏代...
  • 什么是泳道?泳道也叫跨职能流程,能够展示工作流中每个步骤涉及的...先看一看泳道流程:那么,应该如何绘制泳道呢?在跨职能流程中,通常一栏代表一个职能单位。流程中的步骤要分别放在负责这些步骤...
  • 什么是泳道?泳道也叫跨职能流程,能够展示工作流中每个...先看一看泳道流程:那么,应该如何绘制泳道呢?在跨职能流程中,通常一栏代表一个职能单位。流程中的步骤要分别放在负责这些步骤的职能单位...
  • 拓扑常见的用途拓扑通过图形可以更直观表明网络中各节点和端口之间的连接,反应出各实体间的结构关系,方便配置和排除错误。拓扑包括物理拓扑和逻辑拓扑。物理拓扑:指的是设备如何用线缆物理连接;逻辑拓扑:...
  • 拓扑常见的用途拓扑通过图形可以更直观表明网络中各节点和端口之间的连接,反应出各实体间的结构关系,方便配置和排除错误。拓扑包括物理拓扑和逻辑拓扑。物理拓扑:指的是设备如何用线缆物理连接;逻辑拓扑:...
  • 八度4.2.1用于绘制猪的数量与时间的关系图。 然后,我们分析了在提议的某个时期内猪在围栏中的生长方式。 通过此分析,我们提出了一些策略,可以保持笔中的猪只数量而不必过度估计笔的承载能力。
  • 说到文氏图对于专业领域的人来说都不陌生,其英文名是Venn Diagram,也有译:韦恩、文恩图或韦氏等,这是一种用封闭曲线(内部区域)表示集合及其关系的图形,在表现一些逻辑关系(如三段论)时尤为直观简单。...

空空如也

空空如也

1 2 3 4 5
收藏数 99
精华内容 39
关键字:

如何绘制逻辑关系图