第3章 组合原理 分离原理，提供了如何分离研究对象的原理。本章的组合原理要解决的是如何用模型表达 研究成果的原理。用图形表达分析与设计的成果，可以多维度、精准、完整地传递信息。 本章介绍逻辑图形的构成原理、规律，详细说明了图形中各元素的属性等，组合原理是建 立用图形表达分析与设计成果的基础，见图3-1。 业务 物品 组织 管理 要素 逻辑 模型 分离原理 （4分类） 组合原理 （3元素）企业管理信息系统 1.业务 2.管理 3.组织 4.物品 企业构成的分类 业务架构的元素 图3-1 分离原理与组合原理关系 3.1 基本概念 3.1.1 定义与作用 1. 定义 组合原理，给出了用要素、逻辑和模型三元素形成图形的原理和设计方法，利用组合三元 素可以表达出任意的逻辑图。 在分析与设计过程中，不论使用什么样的逻辑图形（分析用、架构用、管理用等），图形 的构成都包括这三个元素，三元素既可以用来绘图，也可以用来检查图形是否正确。 2. 作用 在企业管理咨询行业和软件行业中，针对企业管理对象的描述，不同的业务领域、不同的 描述人、不同的关注点等使得表达方式有无数种，这就带来了传递意图、解读意图都很困难的 现象。这些图形是否存在着相似的规律呢？是否可以找到一套与业务领域、描述人和关注点无 关的、具有普遍性的图形表达方法呢？ 通常寻找具有普遍性的表达方法时，最常用的做法就是“穷尽”所有应用场景，然后通过 抽提共性整合成为一套方法。由于“应用场景”与具体业务相关联，所以这种方式的最大短处 就是随着遇到的场景越多，相应的约束规则、附加条件也会增多。例如，基于100次不同应用场 景抽提出的方法，在用到第101次时如果存在着新的不同点，就要将新场景中的不同之处再加入 大话软件工程——需求分析与软件设计 到既有约束规则中，这种积累方式难以收敛为一个具有共性的模型。 理想的方式是，不论什么业务应用场景仅通过有限的“元素”组合就可以表达，“组合原 理”的提出就是为了满足这一要求。 3.1.2 组合原理模型 1.图形的基本构成 由于研究对象的形态有万千种，所以表达分析、设计意图的图形也就有非常多的形式，如 果要想找到一套通用的方法来替代，需要先研究一下各种图形的构成内容是什么、规律性有哪 些等，从而找到一个通用的建模方法。 下面通过对比几个完全没有任何业务背景，也无任何关联的图形，研究一下它们之间有哪 些共同之处。如图3-2（a）所示，其中有4个图形a1～a4，它们从外形上看似乎没有什么共同 点，如果对a1～a4的图形进行拆分，将拆分后获得的图形元素进行分类，可以获得三组不同的 元素，分别详见图3-2（b）～图3-2（d），这三组不同元素的含义如下。 （1）图3-2（b）：表达的是图的“要素”。 将a1～a4各图中都具有的共同内容3个方块A、B、C提出来，这3个方块是用来表达构成图 形主体内容的“构件”，它们被称为图形的“要素”。 （2）图3-2（c）：表达的是要素间的“逻辑”。 在去掉a1～a4各个图形中的构件要素后，剩下了“线条、位置、背景框”等内容，它们是 用来表达各个构件要素之间的关系，它们被称为“逻辑”。 （3）图3-2（d）：表达的是图的“模型”。 在去除了a1～a4 各个图形中表达要素和逻辑的内容之后，只剩下了要素方块和逻辑的“投 影”，这些投影表达的是要素与逻辑构成的不同“形状”，它们被称为“模型”。 原图三元素 A B C BA C A B C A B C A B C BA C BA C BA C 箭头 位置 背景框 线条①关联 　关系 ②位置 　关系 ③包含 　关系 a1 a2 a3 a4 A B C A B C (d) 图的形状(b)图的要素(c)要素的关联(a) 常用图形 A B C A B C 图3-2 组合原理三元素的抽提 大话软件工程 四校　正文1-4.indd 42 2020-3-22 15:19:46 2. 组合原理的三元素 从前面利用4种与业务无关的图形中抽提出来的三种共同元素，可以得出这样的结论：只要 是逻辑类图形都是由这三种元素构成的，这个结论就是图形的构成原理，称为“组合原理”， 而这三个元素就称为“组合原理三元素”，它们是组合原理的核心。组合原理三元素与逻辑图 的关系如图3-3所示。组合原理三元素的定义与说明详见图3-4。 ABCABC 元素3：模型元素1：要素元素2：逻辑组合=逻辑图 图3-3 组合原理模型 工作分解内容说明三元素的举例 组合原理 任何具有结构形式的逻辑图都是由三元素构成的： □要素、□逻辑、□模型 组 合 三 元 素 1.要素是图形中表达主体内容的“构件” □系统要素：系统、模块、功能、控件…… □业务要素：财务、销售、采购、物流…… 2.逻辑是图形中表达要素关联的“关系” □业务逻辑：线条、位置、背景框（架构用） □数据逻辑：键、表、图 3.模型是由要素和逻辑构成的、具有规律性结构的“形态” □架构模型：框架图、分解图、流程图 □数据模型：算式关联图、数据勾稽图、业务数据线 图3-4 组合原理三元素的内容与说明 表达企业管理信息化研究成果的图形基本上都是可以通过用组合三元素来描绘的，反过 来，利用组合原理的三元素也可以检查绘制完成的逻辑图是否正确、合乎逻辑（读者可以尝试 使用其他领域的图形去验证组合三元素的适用性）。 3.1.3 思路与理解 通过少量元素的组合，就可以表达出多种形式业务构成和业务逻辑是理想的建模方法，如 何才能够找到这样的方法呢？基于某些业务场景建立起来的模型一般来说都有一定的局限性， 因为选择的业务场景不具有普遍性。在对组合原理进行详细说明之前，首先借用具象事物来说 明一下组合原理形成的思路，观察一下提线木偶道具的构成和运行机理，如图3-5所示。 (b)提线→逻辑(c)服装→模型(d)木偶→图形(a)构件→要素 图3-5 木偶原理示意图 大话软件工程——需求分析与软件设计 提线木偶道具由以下三个部分构成。 （1）构件：是构成木偶骨骼的部分，不论是什么形态的木偶，它的形体都是由有限的构件 组成的，每个构件都代表唯一的功能，如头、身躯、腿骨、手等。 （2）提线：提线关联了所有的构件，通过提拉操作，可以调动各个部分的构件发生位置移 动，这些移动就会产生木偶的表情、运动等行为。 （3）服装：服装、面具、鞋帽等装饰物让木偶具有了不同的造型，这些不同的造型表现了 不同的角色，可以让人辨识出木偶表达的是人、动物、物件等。 将这三者安装在一起，就可以形成木偶，通过操作提线，就可以表达出表演者的意图（表 情、动作、故事情节等），但是去掉了服饰之后，木偶内部的构成、运动原理都是一样的。 构件、提线和服装分别对应组合原理中的要素、逻辑和模型。下面分别对组合原理的三元 素进行详细说明。 3.2 组合三元素1——要素 本节重点介绍组合三元素之一“要素”的来源、属性、表达方式等，“要素”是构成图形 内容的主要部分。本节中对要素的属性描述对后续的分析和设计起着非常重要的作用，理解这 些属性可以在分析和设计中很容易进行沟通、表达，有了这些属性作为支撑，可以大大地提升 工作效率，以及分析与设计成果的质量。 这些描述方法不仅是说明要素的属性，更重要的是它还是一种思考方式，特别是在用语言 交流时，如果使用了要素属性进行描述，会明显地提升沟通效率和质量。 3.2.1 对象的概念 对象，是指分析与设计的目标事物。 对象是要素的来源，要素是从对象分解而来的。对象会以多种形态呈现，例如： ●需要优化的事物：企业管理体系、生产流程、操作程序等。 ●需要分析的问题：产品质量问题、销售业绩下滑问题、成本超标原因等。 ●需要研究的课题：软件的需求规格书、事故调研报告等。 所有需要进行分析并通过设计可以进行优化的目标事物，都可以称为对象。为了保持讲述 内容前后的关联性，本书所举案例主要以企业运行中的各种“业务”为主，所以也称之为“业 务对象”或“研究对象”。 1.对象的分类 根据研究课题的目的、研究对象包含的内容，以及其所处的环境背景，可以将需要研究的 对象分为两种类型：优化类对象，非优化类对象。两者的内容和关系如图3-6所示。 1）优化类对象 优化类对象：已存在并正在运行着的业务体系。 优化类对象的共同特点是：要研究的对象是一个客观上已经存在的真实业务体系，且该体 大话软件工程 四校　正文1-4.indd 44 2020-3-22 15:19:46 2.新建型(有业务、无系统） 　对既有业务现状进行调研 一、优化类 如企业,成本,物流…… 二、非优化类 如问题,因果,现象…… 用分析模型进行分析 再与架构模型进行关联 1.既存型(有业务、有系统） 　对既有业务和系统进行调研 无参考依据 　收集所有的信息、资料 对象 分类、判断 用架构模型进行分析 图3-6 研究对象的分类：优化类与非优化类 系已经运行了一段时间，已经形成了一定的形式、规律、标准和规则等。所谓的优化就是采用 新技术、标准对它们进行升级、改造、完善的工作，这类对象可以是如下的内容。 ● 企业级的业务体系、管理体系，例如，某个企业的运营管理体系。 ● 企业内某个领域的业务体系，例如，成本管理、物流管理、销售管理等。 ● 某个正在运行的流程，例如，生产加工流程、财务申报流程等。 为企业进行的管理咨询、系统设计等的研究对象都属于优化类对象，因为研究的对象业已 存在（不论其是否实现了信息化管理）。所谓的“优化”就是采用信息化方法改进、完善既存 的业务，实现效率、效益的提升。 2）非优化类对象 非优化类对象：尚未实现的业务（对尚未实现的事物是不存在优化的）。 非优化类研究对象可以是：一个问题、一个现象、一对因果关系、一个尚没有实践过的课 题、一个全新领域的业务等。简而言之，就是“没有做过的事，没有参照的对象”。这类对象 不同于对优化类事物的研究，由于没有客观存在的对象，既无法绘制业务现状构成图，也无法 直接绘制新的业务架构图。 注：只有对优化类对象才能进行优化 针对非优化类对象的研究成果不能说“优化”，因为“优化”行为必须是针对某个已存在 的且已经过时的对象。 非优化类对象的研究需要从理解对象开始，首先要去寻找构成对象的要素、逻辑，然后才 能进入与优化类对象相同的阶段，下面试举几例来说明非优化类对象的特点。 【案例1】针对某个问题：如何提升生产效率？ 提升生产效率的问题，可能都不是某个单一原因所造成的，不能通过简单地优化某个流程 获得解决，而是需要通过大量的、多视角的分析研究，找出造成问题的原因后，再根据原因给 出解决方案。 【案例2】针对某种现象：为何年末的客流突然涌向了××地区？ 首先要收集客观的现象、建立各种现象之间的关联关系模型，分析造成该现象的原因，然 后归集出答案。 大话软件工程——需求分析与软件设计 【案例3】针对因果关系：共享单车使用效率低是因为投入量太大吗？ 题目给出了因果关系的猜测，这就需要收集要素，建立模型，分析使用效率与投入量是否 存在着因果关系，最后证明因果关系是否成立等。 可以看出，非优化类对象都是没有可以参考的实际对象的，对这样的对象进行研究就需要 从零开始做功课。 2.对象分类概念的作用 首先对比一下优化类对象与非优化类对象的异同，在进行以企业业务为目标的分析与设计 研究中，这两类对象都是常见的，两者的差异如图3-6所示。 （1）相同之处：都需要经过分析，给出最佳的设计方案。 （2）不同之处：前者可以直接参考既存对象（业务、系统）；后者无可直接参考的对象。 了解了对象分类的异同后，那么，在进行需求调研前首先就要判断该项目是属于哪一类对 象，确定了对象的分类后，容易找到最佳的分析和设计理论、方法和路线，假定研究对象的规 模是相同的，则， （1）优化类对象：因为已有实际的参照物（实际业务流程、既存系统、资料等），在调 研、分析与设计的各个阶段中都可以与实际的现状进行对比验证，这是一个“创新+完善”的过 程，因此，优化类对象信息系统的实现相对比较容易。 （2）非优化类对象：由于没有参照物的存在，所以全部的工作需要从零开始，非优化类对 象的信息化实现过程是一个“全面创新”的过程。因此，找对目标、方向，以及要素、逻辑、 分析模型等非常重要。进行非优化类对象的研究始终要关注“整体”与“细节”之间的关系， 避免出现方向性的错误。 3.2.2 要素的概念 要素，是构成事物必不可少的因素，要素的集合体构成了对象。 1.要素的内容 要素，在表达不同对象的逻辑图中以不同的形式出现，例如： ●业务架构图：要素表现为系统、子系统、模块、功能。 ●数据架构图：要素表现为数据表、数据。 ●管理架构图：要素表现为标准、规则、判断。 2.要素的描述 要素是构成研究对象的核心内容，要素覆盖的内容包罗万象，在对要素进行表达时需要一 套规范的描述方法，用以说明要素的数量、大小以及所处的状态等。本书中给出的描述要素的 属性分为4组：①粒度与分层；②黑盒与白盒；③系统与模块；④解耦与内聚。 对上述①～④的详细介绍，参见本章的3.2节的说明。 3.要素的相对性 要素与对象是相对的概念，如图3-7所示。例如，在研究“企业业务”这个对象时，其内部 构成中的“财务”要素仅仅是作为对象“企业业务”中诸多要素之一而存在的，企业的业务构 成如图3-7（b）所示；但是在聚焦于“财务”的研究时，“财务”就从原来的一个要素，转变 大话软件工程 四校　正文1-4.indd 46 2020-3-22 15:19:47 为一个对象，财务的构成如图3-7（c）所示；再对财务中的“成本”进行进一步的研究时，则 “成本”又成为对象，成本打开后的构成如图3-7（d）所示，以此类推。 销售 物流 生产 财务 设计 计划 … 企业 业务 支出 报表 经费 收入 报销 成本 … 定额 核算 目标 预算 计划 合同 … (b)对象要素的构成(a)对象(c)财务要素的构成(d)成本要素的构成 图3-7 对象、要素的相对概念 对象不同，拆分出来的要素也就不同，例如： ● 图3-7（a）企业业务：其构成为图3-7（b）—财务、计划、生产、设计、销售、物 流等。 ● 图3-7（b）财务要素：其构成为图3-7（c）—财务、收入、成本、经费、支出、收 入、报销等。 ● 图3-7（c）成本要素：其构成为图3-7（d）—预算、合同、定额、计划、目标、核 算等。 为了说明这些现象，就需要一套描述这些要素特征的方法。 3.2.3 要素属性1——粒度与分层 粒度与分层，是对要素大小的属性描述。 1. 粒度的概念 将研究对象“企业业务”拆分后出现了要素，如果以其中的“财务要素”为对象再度进 行拆分后，就会出现更下一层的要素，如此反复可以进行若干次，如何表达这个“对象-要素- 对象”循环出现的现象呢？这就需要引入表达要素粗细的概念，将表达要素粗细的尺度称为 “粒度”。 粒度，是表达对象中不同要素的“粗细”程度的尺度。 粒度原指球状体的直径大小，比较细小的要素就包含在同类较粗的要素之内，如图3-8（a）所示。也可以将不同粒度的要素，按照从粗到细、从上到下地放置在不同的“层”上，如 图3-8（b）所示。 财务 财务-成本 成本-合同 (b)用分层表达粒度 财务 成本 (a)粒度的概念 合同 大粒度 中粒度 小粒度 图3-8 粒度与分层的概念 大话软件工程——需求分析与软件设计 图中标出了对象“财务”中的3个要素的粒度关系，即：财务、财务中的成本、成本中的合 同，显然它们由粗到细的包含关系是：财务＞成本＞合同，这就是所谓的“粒度”不同。 再举一个广义的例子来扩展一下思维，采用分层的方法，对下述12个要素进行梳理：军事 领域、经济领域、装甲车、大使馆、广交会、外交领域、陆军、教育领域、商务部、学校、考 试、一等秘书。 可以看出这些要素具有不同的类型、粒度，对它们的梳理可以分为以下三步。 步骤1：首先从分类的角度将这些要素进行归类，归集出4个大分类，这4个分类同时也是各 类中粒度最大的要素，即：军事领域、外交领域、教育领域、经济领域。 步骤2：根据与各领域的关系，将其余要素归集到各个分类的下面。 A. 1军事领域：陆军、装甲车。 B. 1外交领域：大使馆、一等秘书。 C. 1教育领域：学校、考试。 D. 1经济领域：商务部、交易会。 步骤3：对同一分类的要素按照粒度放置在不同的层上。 例如，在同一分类“军事”中，按照粒度可以分出三层，它们之间的大小顺序为军事领 域＞陆军＞装甲车，用层的方式来表达时就形成了：第１层＝A.1军事，第２层＝A.2陆军，第 ３层＝A.3装甲车，如图3-9所示。 A.3 装甲车 A.2 陆军 C.3 考试B.3 一等秘书 A.1 军事领域 D.3 交易会 B.2 大使馆 B.1 外交领域 C.2 学校D.2 商务部 C.1 教育领域D.1 经济领域第1层：粗粒度 第2层：中粒度 第3层：细粒度 图3-9 要素粒度的应用 从图3-9可以看出，分层的表达方式不但能显示大小（粒度）还能显示顺序（上、下）。 2.粒度的作用 知道了粒度的概念，那么粒度概念在分析和设计时的作用是什么呢？ 粒度的概念在进行理解新事物、研究分析时起着非常重要的“划分大小”的作用，特别是 在研究不熟悉的事物时尤为重要，它可以指导我们先从顶层、大方向、总目标、核心价值等描 述基本构成中的大粒度要素入手。 作为分析师、设计师，在观察繁杂的事物时，是先看整体、大的构成（粗粒度），还是先 关注细节（细粒度），往往是关乎分析与设计成败的要因。 在进行比较复杂的业务分析或设计时，一定要注意相关要素之间的粒度对比，也就是通常 说的“不要胡子眉毛一把抓”，将不同粒度的要素放在一起进行研究，这样得出的结论可能是 混乱的，因为不同粒度的要素之间的逻辑关系、表达方式可能是不一样的。不分粒度、不分层 次画出的图形，无论表现得多么漂亮都可能是无价值的。 粒度的概念，是软件分析、设计的常用概念。下面再用业务流程设计说明粒度的概念。 【案例】业务流程图，如图3-10所示。 使用粗粒度的要素形成的最上层的流程图，称为“一级流程”，以此类推，可以有二级流 程、三级流程等，由最小粒度（活动）构成的流程图就是可以执行的流程了。 大话软件工程 四校　正文1-4.indd 48 2020-3-22 15:19:47 大话软件工程——需求分析与软件设计 素的内部细节，此时就可以将这些“看不到下一层细节”的要素称为处在“黑盒状态”（因为 盒子是盖着的，所以看不见盒子里面的内容）。 例如，从企业管理这个对象中拆分出来了财务、销售、计划等同粒度的要素，在讨论企业 级的问题时不必去关注财务中的“收入”和“支出”这样的小粒度业务细节，所以这个时候可 以将“财务”看成一个整体（黑盒），专注于财务与销售、设计、生产等具有相同粒度要素之 间的关系。 2）白盒的概念 白盒指打开盒子，让盒子里面的内容（要素）暴露出来时的状态，参见图3-11（b）。 白盒与黑盒的定义相反，例如，打开财务这个“黑盒”后，里面小粒度的要素就显示出 来了，这时财务就不是处于“黑盒”的状态，而是处于“白盒”的状态了，同时财务也就从要 素变为了对象，而白盒中的“收入”“支出”“预算”等内容又成为构成财务对象的要素，此 时，财务中的诸要素（预算、支出、收入等）之间又可以彼此看成是黑盒状态了。 图3-11中只有财务盒子被打开处于白盒状态，其余的销售、生产等要素仍处于黑盒状态。 2.黑/白盒概念的作用 黑盒与白盒概念的应用，在分析对象、要素时起着什么作用呢？ 试想一下，为什么当遇到复杂的问题时新手会感到束手无策，而经验丰富的老手则可以从 容地找到解决问题的路径呢？下面尝试用黑/白盒的概念来解释一下。 1）没有经验的新手 在观察问题时缺乏经验，他们看到问题（对象、要素）的状态，既有呈黑盒状态的，又有 呈白盒状态的，结果就是感到问题非常多，盘根错节，一团混乱，问题的原因就是因为新手的 眼睛不会“一层一层地去看观察”，而是同时看到了所有不同粒度的问题。 2）有丰富经验的老手 先将拆分出来的要素归集到不同的分类中（黑盒），首先对大分类（粗粒度）的要素进行 观察和讨论，摸清情况后，再根据需要将其中一个黑盒打开成为白盒状态，对白盒内的细节问 题进行深入的研究，这就避免了同时出现不同分类且大小粒度不同的信息，极大地降低了研究 的难度（当然，有经验但缺方法的老手也会犯与新手一样的初级错误）。 要素的粒度越粗理解时需要的业务知识就越少，反之，要素的粒度越细需要的业务知识就 越多。不同分类的黑盒同时打开，不但造成了大量的细节同时出现，且如果不同黑盒中的要素 之间还存在着复杂关联，这就使得判断的工作量和难度达到了难以控制的程度。 3.黑白盒概念的应用案例 下面举例来说明如何利用黑盒/白盒的方法减少研究难度，同时提升研究的效率。 【案例1】需求调研时的应用。 假定需要调研的客户部门共有10个，调研可以采用两种方式，分别说明如下。 方式一：全部门同时展开调研 以企业为对象，以各个岗位的工作为要素，由10个部门的负责人和其下属各个岗位的担当 人轮番讲解各自的工作，这就相当于各个部门没有处于黑盒状态的，全是白盒状态，需求分析 师一开始就要面对数十个甚至上百个混在一起的不同层次不同粒度的问题，问题有来自于部门 的管理层，也有来自于执行层，例如，交通费报销、质检流程、在库资产的摊销、生产流程的 大话软件工程 四校　正文1-4.indd 50 2020-3-22 15:19:50 优化、安全管理、收支平衡等。 结论：如果采用方式一进行调研，不单是新手会晕头转向，就是经验丰富的老手也会被搞 晕，问题出在没有设置中间的黑盒，一开始就将对象全部都置于“白盒”状态，没有粒度、没 有层次。在以新手为主的调研过程中是常见的现象。 方式二：分部门逐层进行调研 第一步：以企业为对象，以部门为要素（部门=中间的黑盒层）讲解企业部门级的工作， 即：经营管理部、销售部、采购部、生产部等10个部门，讲解的是这10个部门的主要功能、部 门之间的协同关系等内容。 第二步：以部门为对象（部门=处于白盒状态），以部门内部的工作为要素，逐个讲解各 个部门内具有的各项工作的作用、工作之间的协同关系等。 第三步：以某个具体工作/功能为对象，讲解该工作/功能的作用、定义、规则等。 按照上述步骤逐层推进，直至完成全部的定义工作。 结论：如果采用方式二调研，就相当于交替式地将要素在“黑盒”与“白盒”间进行转 换，这就可以循序渐进地观察对象，比较有层次地了解和收集企业的信息了。所以，什么时候 让要素呈现白盒状态，是要根据研究的进展而定的，提前去观察白盒状态的内容，反而会找不 到观察的层次、重点和主线，也容易被引入歧途。 【案例2】生产流程分析时的应用。 假定一条生产流程上有6个节点，每个节点为一个要素，即：销售、设计、采购、生产、物 流、结算，这6个要素是同一粒度的，见图3-12。案例重点研究节点“4.生产”分别处于黑盒/白 盒状态时的不同。 1.销售2.设计3.采购4.生产5.物流6.结算se 图3-12 生产流程 研究一：将“4.生产”看成是黑盒的场景 研究节点“4.生产”与其他节点的关系，将流程上全部生产节点都看成是处于“黑盒”状 态，同粒度各要素之间的“关系”就是“4.生产”节点的“输入”和“输出”与其他上下游节 点的相互影响，此时不需要关注“4.生产”节点内部的细节，见图3-13。 （1）“4.生产”节点的输入：上游三个节点提供了①订单、②图纸、③计划。 （2）“4.生产”节点的输出：向下游两个节点输出了④合格单、⑤结算单。 1.销售 2.设计 3.采购 ①订单 ③计划 ②图纸 5.物流 (b)输入(d)输出(c)黑盒状态(a)上游节点(e)下游节点 6.结算⑤结算单 ④合格单· 4.生产 图3-13 “4.生产”节点的输入输出关系 大话软件工程——需求分析与软件设计 注：流程图中要素可以分为如下的内容 （1）1～6的各个节点都是“活动”。 （2）输入的“订单、图纸、计划”和输出的“合格单、结算单”都是“实体”（表单）。 研究二：将“4.生产”看成是白盒的场景 如果要研究生产流程的上游节点（1、2、3）对“4.生产”节点内部的影响，就要将“4.生 产”节点看成是“白盒”，将它的内部细节显示出来，同时要表现从上游的输入（订单、图 纸、计划）对节点4的影响，打开了“4.生产”就会发生如下的讨论。 ①订单：可能会影响到生产环节的流程、设备、资源等。 ②图纸：可能会影响到生产环节的工艺、工法、质量等。 ③计划：可能会影响到生产环节的交付时间、产品价格等。 一旦涉及“4.生产”的内部，就会出现很多的要素，不同的要素遵循着不同的技术、不同 的标准等，就会使得研究变得非常复杂，因此，分析工作的第一步一定要从大处入手，看清目 标、层次、关系等，避免在分析一开始就去关注细节。在讨论问题时，要注意： ●讨论的所有要素是否是同一粒度，是否都处在黑盒状态上； ●黑盒之间要研究的内容，与某个黑盒内部要研究的内容是不相同的。 掌握黑/白盒的概念在分析和设计过程中是很重要的，它不但可以帮助工程师清晰地剖析对 象，而且还加快了研究和分析的进度。 3.2.5 要素属性3——系统与模块 系统与模块，是要素归集的单位。 1.系统的概念 系统是由一群有相互作用关系的功能要素组成的集合体，如图3-14所示。 系统1系统2 要素 要素 要素 要素要素 要素 要素 图3-14 系统的概念 前面讲的要素粒度、黑/白盒的概念，本质上讲的都是对要素大小的属性描述，而系统不仅 表述要素的大小，而且还可以表述它们之间的关联。 系统的概念有以下三层含义。 （1）系统是由若干要素组成的，这些要素必须是功能，如处理业务的功能：合同签订、材 料采购等，而不能是“物”（如设备、材料等）。 （2）系统内部的要素要有相互作用关系，并能够形成一定结构体。 （3）同一个系统中的要素合在一起可以具有处理某类业务的能力。 在仅考虑粒度和包含关系时，可以将研究的内容称为对象、要素，在考虑要素之间的相互 作用时，要素的集合体一般就要改称为“××系统”了。 大话软件工程 四校　正文1-4.indd 52 2020-3-22 15:19:51 系统，作为功能要素集合体的代名称，在不考虑业务属性时，可将要素的集合体称为系 统，如果加上了业务属性做前缀就形成了不同的业务系统，例如，财务系统、生产系统、人资 系统、物流系统等。 系统也有粒度的概念，小型的集合体称为子系统，大型的集合体称为父系统，或简称为系 统。父、子系统是个相对的概念，不同的系统之间不好直接进行大小的比较。 2. 模块与模块化设计 1）模块的概念 模块，是由一群可处理某个业务场景的功能要素组成的集合体。 由于系统、模块和功能这三个词在不同的场合、面对不同的描述对象时定义都不同，这样 就容易给读者带来困惑，因此在本书中做如下约定。 （1）系统：是具有独立处理某个业务领域工作的完整功能集合体，系统是由模块组成的。 （2）模块：是分担系统中的局部处理工作的，模块是由功能组成的。 （3）功能：是系统中可以完成某个业务处理操作的最小独立单位。 这三者都是由功能构成的，在粒度上的关系为：系统＞子系统＞模块＞功能。 2）模块化设计的概念 模块化设计，就是将具有不同作用的功能进行多种组合，以实现用有限的功能支持多样的 业务处理场景。 功能要素按照要求被归集到不同的系统中，每个系统可以独立地处理某个业务领域的工 作，且每个系统都具有标准的对外接口。按照需要，可将更多的具有不同功能的系统组合在一 起，以完成更加复杂的任务。通常我们做的系统规划都具有这样的特点，下面以企业管理的功 能框架图为例来说明模块和模块化的关系。 【案例1】将企业业务划分为三个业务领域，分别命名为：主营区、辅营区和支持区，如 图3-15所示。 主营区 ①销售管理 ③设计管理④生产管理 后勤管理…管理 辅营区 财务管理 人资管理 知识库… 信息中心 物流管理 1.系统2.子系统3.模块4.功能 支持区 ②采购管理 图3-15 业务功能的组合 （1）主营区：区内的子系统构成了企业业务的主体，它们分别代表了4个主营业务板块， 包括：①销售管理、②采购管理、③设计管理、④生产管理，因为它们是企业产生价值和收入 的主要来源，所以称为主营业务。 （2）辅营区：区的子系统是用来对主营区的业务进行辅助管理的，包括：财务管理、人资 管理、信息中心等， 它们不是直接生产价值的，而是为了保证价值顺利产生的功能。 （3）支持区：区内的子系统是为主营区业务提供服务的，包括：后勤管理、物流管理等。 从图中可以看出，如果哪个部分的内容需要调整时，可以遵循规则在该部分内增加或是减 关联，三个系统之间两两成对地形成了非常复杂的依赖关系，三个系统因“盖不上盖子”都不 能形成黑盒，这种状态就是“紧耦合”状态。 对象 系统1系统2 系统4系统3 要素 松耦合关联 状态的系统 紧耦合关联 状态的系统 图3-17 紧耦合与松耦合的示意 2）松耦合 系统4与其他系统之间的关系是非常清晰、简单的，分别只有一个接口，可以看出系统4 内 部的要素并不直接与其他系统中的要素关联，而是由统一的接口进行关联，也就是说，系统4和 其他系统之间虽然有关联，但不是复杂的依赖关系，这种由唯一或是少量关联形成的关系就是 松耦合状态。 解耦，简单地说，就是将上述的“紧耦合”状态解开，形成“松耦合”的状态。 解耦的概念说明，当分析对象内部的系统之间都是紧耦合关系时，那么各个系统就不能在 “黑盒状态”下进行讨论了，因为各个系统都存在着系统内要素之间的依赖关系，也不可能在 不考虑这些依赖关系的前提下，将各个系统看成是黑盒了。 解耦概念对后续分析与设计有着非常实际的指导意义，例如，某个产品的生产过程在企业 内部大都是由多部门协同完成的，业务流程大多要跨部门才能完成，最佳的流程设计是部门之 间的交互最少，最大限度地减少不同部门内部工种之间发生的直接依赖。避免由于某个部门内 部某个工种的作业内容发生了变化而引起其他部门的连锁反应。 2. 内聚的概念 内聚，是说明同一个系统中各个要素之间的关联性。 理想的内聚状态如图3-18所示，对象中的每个系统都可以独立地完成一个业务领域的工 作，且各个系统内部要素之间的关系紧密。也就是说，每个系统内所有的要素都是为了完成同 一个目标而存在的，例如，对于财务系统来说，既不要把财务系统的功能划分到其他系统中， 也不将其他系统中的非财务功能拉入到财务系统中来。 对象 系统1系统2 系统4系统3 图3-18 内聚概念的示意 大话软件工程——需求分析与软件设计 内聚的概念说明，各个系统内部的要素要按照“内聚”的标准放在一起，各个系统之间通 过一定的接口进行相互调用，而各系统内的要素之间没有直接关联。这样在进行讨论时一个系 统就可以用一个黑盒来表示。 内聚的实际意义在于，在设计时让每个系统具有的功能都相对独立、单一，这样就容易进 行拆分，并通过不同的组合灵活地满足各种需求。 3.高内聚与松耦合 系统内要素间的内聚程度高就称之为“高内聚”，系统间的关联程度低就称之为“松耦合 （或低耦合）”，参见图3-19的对比可以看出来内聚和耦合之间的关系。 (b) 高内聚、松耦合的状态(a)低内聚、紧耦合的状态 对象2 系统1系统2 系统4系统3 对象1 系统1系统2 系统4 系统3 图3-19 高内聚与松耦合的示意 1）高内聚 高内聚的系统内的功能要素要做到高度的相似聚合，共同为一个目标服务。图3-19对象1中 3个系统没有做到高内聚，而是紧耦合，系统内部之间的交互非常繁杂。而对象2的情况就完全 不同了，各个系统的内部都做到了高内聚。 2）松耦合 在同一对象内的各个系统之间要尽量做到松耦合，系统之间具有最小的相关度，图3-19的 对象1系统之间没有做到，对象2系统之间实现了松耦合，因此对象2的系统构造看上去就非常 舒服。 判断信息系统架构优劣的一个重要的原则就是：系统之间是否进行了松耦合的设计。它关 系到系统运行后的维护成本，而且还极大地影响到系统的扩展性、对需求变化的响应能力，甚 至是系统的生命周期。 为什么要对从事需求分析、业务设计的读者谈模块化设计、松耦合设计呢？ “功能做到模块化、快速响应客户的需求变化”是软件行业一直追求的目标，但是很多从 事软件开发的人并不清楚达成这个目标与业务人员的相关性，不清楚业务人员对系统的模块化 设计和结果起着非常重要的作用。因为这些目标的达成都需要一个非常重要的前提，那就是对 “业务的拆分”，首先要将研究对象拆分成为若干个小的可以独立的要素，才可能实现“将一 个大的系统分解成多个小的、独立的功能/组件，然后通过它们的不同组合来处理复杂的、大型 的、多变的问题”。也就是说，业务人员能否将研究对象进行有效的拆分并给出变化的规律是 关键，如果业务人员做不到，那么在后续的技术设计和开发时就很难做系统的模块化，更别谈 让系统具有强应变能力了。 对于要素属性的描述使用了很多的概念（粒度/分层、黑/白盒、系统/模块、解耦/内聚）， 大话软件工程 四校　正文1-4.indd 56 2020-3-22 15:19:52 这些概念不但可以在架构中得到应用，而且在分析过程中也有着广泛的应用价值，这些概念运 用可以让工程师的眼、脑、耳、嘴、手等器官在理解、分析和设计时有了层次感。 3.3 组合三元素2——逻辑 本节重点介绍组合三元素之二的“逻辑”，包括在业务架构图、功能原型以及数据架构图 中的逻辑表达形式。“逻辑”是业务事理用图形的表达形式，是图形中的灵魂。 3.3.1 逻辑的概念 逻辑，指的是思维的规律和规则，是对思维过程的抽象。 在对业务分析与设计中逻辑表达方式的说明之前，先借鉴参考一下不同领域对逻辑的解 释，它们可以帮助理解逻辑的概念，例如逻辑定义有： ● 逻辑是思维的规律和规则，是对思维过程的抽象； ● 在广义上逻辑泛指规律，包括思维规律和客观规律； ● 在狭义上逻辑即指思维的规律； ● 逻辑就是事情的因果规律； ● 逻辑表明了规律，事物完成的序列； ● 逻辑表现了事物流动的顺序规则； ● 逻辑是事物传递信息并得到解释的过程。 1. 不同行业的逻辑表达 图3-20分别给出了语言文字、数字电路以及软件数据关系三种不同的逻辑表达形式， 图3-20（a）是用文字表达的逻辑，它需要通过“阅读”的方式获取逻辑（直接看不出来）， 图3-20（b）使用图形“符号”表达逻辑，图3-20（c）使用“线条”表达逻辑。 (b) 数字电路：逻辑表达用图标(c) 数据库：逻辑表达用线(a) 逻辑学：逻辑表达用文字 　狭义上逻辑既指思维的规律，也指研究思维规律的 学科即逻辑学。广义上逻辑泛指规律，包括思维规律 和客观规律。逻辑包括形式逻辑与辩证逻辑，形式逻 辑包括归纳逻辑与演绎逻辑，辩证逻辑包括矛盾逻辑 与对称逻辑。对称逻辑是人的整体思维(包括抽象思维 与具象思维)的逻辑。[1] 　逻辑指的是思维的规律和规则，是对思维过程的抽 象。从狭义来讲，逻辑就是指形式逻辑或抽象逻辑， 是指人的抽象思维的逻辑；广义来讲，逻辑还包括具 象逻辑，即人的整体思维的逻辑。 图3-20 不同领域的逻辑表达方式 2. 业务设计中的逻辑存在 在软件设计时采用的各类图形中是否存在着逻辑的表达呢？如果有，那么逻辑的表达形式 是什么呢？见图3-21。 1）首先将表达对象的图3-21（a）通过拆分得到三个要素A、B、C，如图3-21（b）所示。 2）将A、B、C三个要素，分别画成分层图、分解图、流程图的三种形式。 大话软件工程——需求分析与软件设计 CABABCABC 分层图流程图分解图 BCA(a)对象(b)要素(c)要素的位置关系表达了逻辑 图3-21 业务设计用图的逻辑表达示意 通过分层、顺序、连线的方法进行关联，虽然三种图形的构成要素是一样的，但是可以看 出三个图给出了三种不同含义，说明如下。 （1）分层图：说明A、B、C在不同的层面上，理由可能是粒度不同，也可能是层次不同。 （2）分解图：说明B和C的集成是A，也可以说A的分解是B和C，三者为从属关系。 （3）流程图：说明A、B、C的处理过程，A必须通过B才能够到达C，说明了顺序关系。 如果能解读出上面的含义，那就说明“逻辑”不但是存在的，而且还能“画”出来。 结合逻辑的一般定义以及信息系统的设计方法，对逻辑的概念进行抽提、定义为三个核心 内涵，即：规律、顺序、规则。 （1）规律：要素之间内在的、稳定和反复出现的关系。 （2）顺序：要素的位置关系，包括前后、上下、左右。 （3）规则：保证按照规律、顺序运行的约束。 3.3.2 逻辑的作用 有了逻辑的概念，那么逻辑在实际的业务架构中是如何起作用的呢？ 从事过管理咨询、业务梳理工作的人都知道业务架构是一门既非常重要又很难掌握的技 能，长期以来究竟什么是业务架构、业务架构包含哪些内容和步骤，没有一个规范化的说法 （在软件行业中还常常将业务架构与软件的技术架构混同在一起，甚至用技术架构方法来做业 务的架构），久而久之，“业务架构”就成为一个似乎大家都知道但又说不太清楚的技术了。 究竟是什么原因造成业务架构难以掌握与运用呢？这就是逻辑的影响，特别是业务逻辑的影 响，下面试举三例来说明逻辑在图形中所起的作用。 【案例1】逻辑在业务表达中的作用。 题目：做一个有关成本过程控制的方案，已知构成成本的业务模块有5个，成本过程是由 “合同管理”模块发起的，见图3-22。 成本管理 人工管理 材料管理 设备管理 合同管理 或 成本管理 人 工 管 理 材 料 管 理 设 备 管 理 合 同 管 理 合 同 管 理 人工管理 材料管理 设备管理 成 本 管 理 成本合计 成 本 合 计 (a)业务模块一览(b)架构方案1(c)架构方案2 图3-22 成本过程的控制方案 大话软件工程 四校　正文1-4.indd 58 2020-3-22 15:19:53 图3-22（a）给出的是业务模块一览，调整这些模块的相对位置进行成本控制过程的架构设 计工作，通过调整模块可以得出两个架构方案： 图3-22（b）是架构方案1，图3-22（c）是架构方案2。 由于调整了业务模块的位置关系，相同的业务模块形成了两个不同形式的架构图，而这两 种不同的业务架构方案表达了不同的业务含义。下面对这两个架构图进行分析。 1. 两个架构方案的相同条件 1）要素 两个方案中各有5个要素：合同管理，人工管理，材料管理，设备管理，成本管理。 2）逻辑 （1）合同管理：主管签订合同，确定合同金额。合同管理是过程的起点。 （2）成本管理：主管核算成本金额，确认最终是否超标。成本管理是过程的终点。 （3）成本合计：是人工管理、材料管理和设备管理三个要素产生数值的合计。 3）模型 两个方案的架构形式，采用的是架构模型中“分解图”的变体图形。 2. 两个架构方案的不同结论 从方案1、方案2可以清晰地看出，在方案1中，“合同管理”不与“成本管理”直接接触， 但在方案2中两者发生了接触，由此带来了成本的发生路径、要素间的从属关系、收敛方向等的 变化；这些变化的本质是什么呢？变化的本质就是逻辑的变化。可以看出，即使要素的内容完 全一样，由于存在着不同的逻辑，所以造成了最后架构意图的不同（只谈差异点）。 1）架构方案1的意图 （1）签订合同一事，不需要事前通知成本管理部门或在成本管理部门进行登记。 （2）成本管理对象（人工管理、材料管理和设备管理）的数据汇总到成本管理部门。 2）架构方案2的意图 （1）签订合同一事，必须要在事前知会成本管理部门或在成本管理部门进行登记。 （2）在进行成本管理的计算时，要对合同金额与实际成本（人工、材料和设备）进行 比对。 业务架构形态的不同，就是业务逻辑变化造成的，调整要素之间的相对关系，就是改变了 业务架构，也就是进行了业务逻辑的再设计。 【案例2】逻辑在学习业务中的作用。 1. 场景1——利用逻辑梳理既存业务 企业在进行信息系统开发时，需要聘请软件工程师来做业务梳理，一般来说，软件工程师 是不懂业务的（至少不是很懂），但是他们却能在短时间内准确地将现实的业务搬到计算机系 统中，并让系统正确地运行，他们是怎么做到的呢？一个重要的理由就是“逻辑”起的作用。 （1）软件工程师虽非业务专家，但他们有“逻辑”的概念，他们是从业务“逻辑”的视角 来理解业务的。 （2）掌握了业务逻辑，也就掌握了业务对象的事理、关系、规律等内容，有了这些核心内 容就可以建立支持管理信息化的软件设计模型。 可以说，软件工程师虽然掌握的不是体系化的专业业务知识，但由于他们抓住了逻辑这个 大话软件工程——需求分析与软件设计 “主线”，所以可以在短时间内完成分析与架构的工作。 2.场景2——利用逻辑理解新业务 在两名经历不同的架构师面对同一个谁也不熟悉的全新研究对象时，通常旁观的人会预判 说：经历丰富的架构师一定会因为他的“经验多”而做得更好，另一名年轻的架构师则会因为 “经验不足”而做得差一些。 但是在实践过程中，有5个项目经验的架构师与有20个项目经验的架构师相比，在面对双方 都不熟悉的新研究对象时，如果前者掌握了利用逻辑分析问题的能力，其做出来的结果不一定 就会比后者差。如果要求的时间短、精度高时，前者的成功概率可能高于后者。因此，从逻辑 入手了解业务知识的人上手快，更可能在短时间内掌握业务的关键脉络。 3.场景3——用逻辑实现业务处理信息化 再仔细地观察和思考一下，利用软件是如何实现业务处理的呢？ 软件系统就是将业务处理的功能封装成一个个模块，然后利用业务逻辑将这些模块串联起 来进行运行，就实现了业务的信息化处理。由于软件工程师抓住了业务功能模块之间的主线、 步骤、顺序、流转规则等关键要素，所以才能做到短期内完成任务，这些关键就是业务逻辑。 【案例3】逻辑对结果的强化作用。 可以采用不同的形式来表达同一个结论，例如用语言、表格或是图形，这三者中图形的逻 辑表达最为显著，例如，表达“工程质量下降”分析原因的方法，见图3-23。 问题分类问题内容 设备问题完成率低、使用年代久 资料问题缺乏测试、质量不稳定 员工问题培训不足、经验缺乏 技术问题图纸不准确、设计不交圈 环境问题气温比较低、下雨太多 检查问题检查不到位、检查凭感觉 3.员工问题2.材料问题1.设备问题 6.检查问题5.环境问题4.技术问题 培训不足 经验缺乏 缺乏测试 质量不稳定 完好率低 使用年代久 检查不到位 检查凭感觉 气温比较低 下雨太多 图纸不准确 设计不交圈 (a)用表格的形式表达(b)用图形的形式表达 工程质量下降 图3-23 表格与图形在表达逻辑时的差异 图3-23（a）是用“表格”的方式，图3-23（b）是用“图形（鱼骨图）”的方式，两者的 内容完全一样，但是哪种方式在表达工程质量下降的因-果效应上更强烈、更具说服力呢？ 结论当然是图形的表达最为强烈。图形表达方式之所以比较清晰、强烈，是因为图形直接 将“逻辑”显示出来了，读者不需要去通过思考“读”取文字和表格中的逻辑，而只要顺着逻 辑线的示意，就可以“看”出图形表达的含义了。 3.3.3 逻辑的分类 在3.3.1节中，对逻辑的含义用三个内涵来定义，即：规律、顺序、规则。由于架构可以分 为不同层（架构层、功能层、数据层、管理层等），且不同层的模型表达方式不同，所以它们的 逻辑表达方式有相同也有不同。作者根据对大量图形的分析和研究，总结了业务分析和设计用图 大话软件工程 四校　正文1-4.indd 60 2020-3-22 15:19:53 中常用的逻辑表达方式，见图3-24，对它们的逻辑表达方法详见后续的说明。 逻辑分类表达方式逻辑说明 业务架构图 的逻辑表达 1关联用线、箭头等方法将要素连接在一起，明确、清晰地指明逻辑关系 2位置用要素之间的位置关系表明逻辑，包括：上下、左右、前后等 3包含用背景框将同类要素归集到一起，形成系统、模块，显示逻辑关系 功能界面图 的逻辑表达 1位置功能载体（界面、表）上布置字段、控件的位置 2包含用背景框将具有相关关系的字段、按钮等放置在同一区域内 数据架构图 的逻辑表达 1文字在规格书（4件套）中用文字说明实体内部的数据关系 2键赋予实体编号，用线关联数据间、数据表之间的关系 3表数据的表结构表达了数据的分类、从属关系 4图用图表达数据之间具有计算关系 管理 逻辑 管理架构图 的逻辑表达 1规则用规则约定的控制标准、方法 2模型管控模型包括：标准、规则、判断、决策之间的互动机制 数 据 逻 辑 业 务 逻 辑 图3-24 逻辑的分类与表达方式 下面重点讲述设计工程中不同设计阶段用到的逻辑表达方式，关于设计分层“架构、功 能、数据、管理”的内容参考设计工程中的相关章节。 3.3.4 逻辑的表达1——架构 在架构模型中，逻辑表达的是要素之间的业务关联关系，也称为“业务逻辑”。业务逻辑 的主要表达形式有三种：关联、位置和包含。常用的业务架构模型如图3-25所示。 项目①拓扑图②分层图③框架图④分解图⑤流程图 图例 业务板块 业务1业务2 业务1 子业务2子业务1 实体 3 实体 1 实体 2 实体 4 实体 x系统4… 系统1系统2系统3 数据板块 管理板块 业务板块 系统1 节点4 节点1…节点2 节点3 图3-25 业务架构模型 1. 逻辑形式之一——关联 在几种逻辑的表达方法中，毫无疑问，用线、箭头表达逻辑是最为普遍和直观的方式了。 从例图中可以看出，典型的代表就是流程图。在关联这些要素时，不论是用线还是用箭头，心 中一定非常地清楚连接两端之间的关系，例如，节点1→节点2、节点1→节点4等，见图3-26。 如果采用箭头进行关联，表明两者不仅有关联关系而且有特定的指向，这是最强的逻辑表达 方式。 2. 逻辑形式之二——位置 在图形表达时，为什么要用“位置”一词来替代逻辑原定义中的“顺序”呢？因为在用语 言表达时，“顺序”一词通常含有“线形”的含义，这在一维图形中表达逻辑关系是没有问题 大话软件工程——需求分析与软件设计 的，但在二维、三维的架构图中，实际上要素之间会同时存在着“上下、左右、前后”的空间 位置关系，因此，从广义的视角看，“顺序”也是“位置”的一种表达方式，而“位置”的表 达具有更为广泛的意义，因此，将逻辑原定义的第二个指标“顺序”改为“位置”，以适合于 一维～三维架构图的表达。 分层图就是一个典型的用位置表达逻辑的图形，图中要素之间具有明显的上下、前后关系 等，见图3-27。另外，框架图也具有很强的用位置表达逻辑的能力。用位置关系来表达业务逻 辑的方法，在任何一种图形表达方法中都存在，因为每一个要素在图形中占据什么位置都是有 其背后的逻辑依据的。 节点4 节点1…节点2 节点3 数据板块 管理板块 业务板块 图3-26 流程图图3-27 分层图 3.逻辑形式之三——包含 包含，也是图形逻辑的一个重要的表达方式，包含在一起的要素具有一定的共性。包含逻 辑同时也具有从属的意思，表达包含的方式可以用线、背景框等。框架图是一个典型的用背景 框表达包含逻辑的方式，见图3-28。背景框内的要素具有共性，不同的背景框中的要素目的不 同，从而形成了不同的系统或是模块。 业务板块 业务1业务2 业务3业务x 图3-28 框架图 同样，分解图也可以用来表达具有包含关系的图形。 注：架构图与逻辑图 逻辑图采用逻辑要素可以准确地描绘出对象的“事理”。架构图因为是设计用图，所以必 须采用逻辑图表达，而不能使用示意类图形表达（示意图说明参见7.4.2节的注）。 在本书中，分析模型与架构模型都属于逻辑图，但后者是强逻辑表达。 3.3.5 逻辑的表达2——功能 这里功能层面的逻辑表达，指的是进行界面/表单的设计时所考虑的逻辑依据，界面上的 逻辑主要表现在“位置、包含”上，见图3-29。界面上不同的区域（虚线框）表达了不同的逻 大话软件工程 四校　正文1-4.indd 62 2020-3-22 15:19:54 大话软件工程——需求分析与软件设计 管理 规则 业务流程图 管控 模型 A=总额度 如果合计Σ()>=A， 则发出：提示/警告/终止 签约物流设计加工 外购 s Y N e核算 ②数量控制③单价控制①利润控制④成本评估 Σ（①+②） Σ（①~③） Σ（①~④） 提示警告终止 <=A? Y 控1控2 控3 控4 管理 架构 管理要素 图3-31 管理逻辑的表达 3.4 组合三元素3——模型 本节重点介绍组合三元素之三的“模型”，模型主要分为两大类型，即：分析模型、架构 模型。“模型”是管理信息系统相关人之间传递信息的标准“语言”。 3.4.1 分析模型 分析模型，是建立分析要素与推测结果之间的关联关系，多用于表达“非优化类对象”的 分析结果。 本书推荐的分析模型有两类，第一类是在业内具有较高的认知度和使用频率，第二类是基 于作者的实践经验设计而成，本书推荐5种分析模型，见图3-32。 1.对模型的描述 对分析模型的描述采用了4个指标：图例、目的、适用、特征，各自的含义如下。 （1）图例：是该模型的标准表现形式。 （2）目的：该模型被选择的目的。 （3）适用：该模型适用的场景。 （4）特征：该模型具有的普遍特征，特别关注的3个特征如下。 ●是否有起点-终点； ●模型是否具有结构化特征； ●结果是否呈现收敛性。 2.模型选择的思路 本书推荐这5种分析模型是基于以下几点考量。 1）关联图① 分析对象所包含的要素未必都具有可以结构化的特征，现实中有很多业务场景是非常复 大话软件工程 四校　正文1-4.indd 64 2020-3-22 15:19:55 图形粒度粗中细 图名①关联图②鱼骨图*1③思维导图*2④排比图(1D)*3⑤排比图(2D)*31图例 2目的 利用要素之间的关联，找 出因果的对应关系 利用“鱼骨”型图，收集& 梳理要因，以证明因果关系是 成立的 利用发散式的方法，收集要素一维的表达方式。 以流程为主线，挂接相关的措 施(功能需求) 二维的表达方式。 以流程为主线，挂接相关的措 施(功能需求) 3适用 多要素之间交叉关联、耦合度 高，无法按照线性的方式进行 收集与梳理的场景 存在大量且散乱的要素，通过 梳理&归集要因、可以让结果 都指向某个结果的场景 不需考虑约束条件，按照某个 主题进行发散式联想的场景 通过分析获得的对策、功 能需求等都不多的场景 通过分析获得的对策多、功 能需求多、要求多的场景 4特征 □由1～n个点出发 □多中心的关联 □无起点、无终点 □不收敛，有多个结论 □从n个点出发 □有方向、松散的关系 □没起点、有终点 □结果收敛 □从某点出发收集要素 □没有严格的结构关系 □有起点、无终点 □不要求结果 □针对过程收集 □结构化、流程化 □流程有起点、有终点 □结果收敛于多个结果 □针对多维度收集 □结构化、流程化 □流程有起点、终点 □多个结果 原因 目的 问题效果 手段 对策1 对策2 步骤x步骤1 条件1 条件2 中心 主题1 主题2 主题3 子题1 结果 要因1要因2 要因3要因x 要素要素 主线节点1节点2节点x 要素 措施2 措施3 措施4 措施1 图3-32 分析模型 *1.鱼骨图：由日本的石川馨先生所发明，故又名石川图，也可称之为因果图。 *2.思维导图：由英国的东尼博赞先生（Tony Buzan）所提倡。 *3.排比图：④和⑤由作者整理、设计。 大话软件工程——需求分析与软件设计 杂、耦合度高、难以拆分的，因此，模型①的引入主要是为了解决这类问题。关联图看似简 单，实际是为理解和表现最复杂对象场景而引入的。 2）鱼骨图②与思维导图③ 它们不但具有较强的方向性，而且还可以自由、发散地收集相关的要素，并在使用中可以 边拓展边收集，在收集要素的过程中就完成了对要素的梳理。 3）排比图④⑤ 具有一定的结构化形式的模型，这样的模型易于给出分析成果的规律性、收敛方向等，在 调研、分析的现场就有很好的实用性，可以比较容易地建立起分析结果与业务架构（流程图） 之间的对应关系，加快分析与设计的速度。它是“分析模型”与“架构模型”之间的桥梁。分 析类模型的使用方法说明参见第4章。 3.4.2 架构模型 架构模型，是表达符合业务逻辑关系的要素结构图，多用于表达“优化类对象”的设计 结果。 1.对模型的描述 根据作者的实践经验以及使用频率，本书推荐下述5种架构模型，见图3-33。对模型的描述 采用了5个指标：图例、目的、适用、维度、状态。 （1）图例：是该模型的标准表现方式。 （2）目的：该模型被选择的目的。 （3）适用：该模型适用于什么场景。 （4）维度：模型表达的维度数，有三种：一维、二维、三维。 （5）状态：模型表达的是业务的什么状态，有两种：静态、动态。其中， ●静态：流程图以外的都是静态表达方式（图中①～④）。 ●动态：流程图（图中⑤）。 2.模型选择的思路 本书推荐的架构模型主要来源于在业内具有较高认知度和使用频率的模型，基于作者的实 践经验设计而成的模型（分层图）为辅。本书向读者共推荐5种业务架构模型，见图3-33。推荐 这5种架构模型是基于这样的考量。 ●这套模型必须能支持业务架构的全过程，可以满足从粗的规划到细的流程设计。 ●这套模型间具有某种程度的关联性，可以让设计完成的架构图可以相互衔接。 ●这套模型具有较高的辨识度，让没受过培训的读者也能理解（但不一定会画）。 1）拓扑图 为了开拓读者的思路，这里引入一款具有可以响应扩展、灵活部署的架构模型，主要用来 做最粗的规划设计，它不但可以用于一般的业务架构，也可以为未来参与软件设计做一些实用 知识的铺垫。 2）分层图和框架图 用于复杂对象的第1级、第2级划分，起到了从粗粒度的规划到细粒度的设计的过渡作用， 大话软件工程 四校　正文1-4.indd 66 2020-3-22 15:19:55 图形粒度粗（整体）中（概要）细（详细） No图名①拓扑图②分层图③框架图④分解图⑤流程图 1图例 2目的 利用网络的形式，将不同目的 的要素进行分离或是集成 利用分层的方式，将不同目的 的要素进行分离 利用背景框，给出对象的范围、 对象中各领域的边界、关系 利用父-子的关系，建立要素间 的从属关系（分解/汇总） 建立处理要素之间的方向、顺 序、位置 3适用 表达项目包含有多个不同目的 的业务板块，板块分别部署的 场景 表达对分离结果粗略归集的 场景 表达设计对象的整体规划，顶层 设计的场景 表达对要素进行细分（分层、 分组）的场景 表达具有明确操作顺序的业务 处理过程场景 4维度 □网络图 □一～三维表现（1～3D） □立体图 □二～三维表现（2～3D） □平面图 □二维表现（2D） □剖面图 □二维表现（2D） □线型图 □一维表现（1D） 5状态静态静态静态静态动态 业务板块 业务1业务2 业务3业务x 业务1 子业务2子业务1 活动 3 活动 1 活动 2 活动 4 活动 x 系统4… 系统1系统2系统3 数据板块 管理板块 业务板块 系统1 节点4 节点1…节点2 节点3 图3-33 架构模型 注：业务架构图的节点只表达功能 此时，分析模型中归集的问题已经被转换为解决对策融入到实际的业务架构中去了，因此 在业务架构图中已经不能直接看到原来的问题要素了。 分析模型可以表现分析成果、需要的功能等，但不一定能够表现出严谨的逻辑关系、可以 执行的解决方案，所以分析与架构各自关注的是不同阶段的工作和结果，因此分析模型是不能 够代替架构模型作架构图的。 虽然分析工作与架构工作的目的都是用要素来构成一张图，但作图的方法也是有区别的。 ● 分析：是用“归集要素”的方法作图，归集后要素的承载结构是分析模型。 ● 架构：是用“组合要素”的方法作图，组合后要素的承载结构是架构模型。 小结与习题 小结 分离原理与组合原理，共同构成了业务分析和设计的理论支撑，两者的作用不同。 分离原理是对研究对象进行分离、梳理和分析的基础，解决的是如何对原始对象进行合 理的拆分以获得要素、逻辑。 组合原理是对研究对象利用三元素，按照信息化环境下的要求进行重新的组合，解决的 是如何合理地利用逻辑、模型来整合要素。 组合原理给出了观察、思考和表达的方法。 1. 在分析和设计时的观察和思考方式 通过对要素属性（粒度/分层、黑/白盒、系统/模块以及解耦/内聚）的理解和掌握，在用 眼（观察）和脑（思考）进行分析和梳理时，就有了如何切入研究对象的方法，运用好这些 观察和思考的方法，可以大幅度地提升工作效率，减少不必要的思考和沟通成本，对于分析 师和设计师来说，要素属性带来的价值绝对不低于绘制（手）架构图带来的价值。只有眼、 脑、手三者有机地协同才能够做出好的分析与设计成果。 2. 对分析和设计结果的图形表达方法 组合三元素给出了详细、严谨的表达和检验业务分析和设计成果的方法，利用组合原理 中三元素的概念，可以高效地进行沟通、分析、架构和设计，并使得每个阶段的成果可以舒 畅地进行传递、继承。 从事需求分析、业务设计的工程师掌握了组合原理，并在分析和设计中融入组合原理的 概念后，可以为系统最终实现模块化、具有快速响应客户需求变化的能力等方面做出重要的 贡献，它也为后续进行信息系统模块化设计、产品和功能的设计等奠定了基础。 组合原理提出的观察、思考和表达的方法，对不论从事软件工程上的哪个部分工作的工 程师来说都是必须要掌握的基础知识。 大话软件工程——需求分析与软件设计 3.理解逻辑对表达含义的作用 图形对表达和传递意图的作用是不言而喻的，图形之所以具有强大的表达能力，是因为 图形将“逻辑”信息显示出来了，不需要读者努力去寻找就可以“看到逻辑”，对比表格、 文字的形式，加深理解图形在逻辑表达上的作用。 （1）图形：用“关系、位置、包含”将逻辑全面地、直接地标识出来，并且可以用多 达三维的形式表达，所以，图形是最强的逻辑表达形式。 （2）表格：表格用“位置”确定了要素的位置结构关系，这个关系是隐性的包含关 系，同时可以用二维的形式表达，因此，表格是仅次于图形的逻辑表达形式。 （3）文字：当采用条目式的表达形式时，即在段落前使用“①、②”或“.”做开头， 这些“①、.”就是一维的逻辑提示符号，其中，“①、②”是表示强逻辑（必须按顺序理 解），“.”是表示弱逻辑（不强调顺序），条目式文字表达是较弱的逻辑表达形式。 顺便提示一下，采用文章体（段落前没有提示符号）的表达形式时，需要读者自己从文 章中去寻找逻辑的存在，文章中是否存在逻辑？逻辑是否被准确地表达出来了？最终取决于 作者的编写能力和读者的阅读能力，缺一不可。 使用专业用语，提升交流的专业水平和效率 第3章为读者提供了很多描述对象的概念和专业用语，例如： （1）要素：对要素的描述属性（粒度、黑白盒、解耦内聚等）。 （2）逻辑：对逻辑的表达形式（关联、位置、包含）。 （3）模型：分析模型（鱼骨图、排比图等）、架构模型（框架图、流程图等）。 老师要求学员们平常进行交流时一定要用教材中的用语进行，学员问为什么呢？ 老师解释说，平常在听大家讨论时有个感觉，当讨论的对象是业务时，大家都会使用客 户的业务用语，例如财务、成本、资金、物流等，听上去很专业。但是当讨论到分析与设计 的问题时就感觉大家说话很“外行”，因为在表达中没有多少专业的设计用语，这样的沟通 不但不精准、效率低，而且给人以不专业的感觉，这也是业务人员经常受到技术人员诟病的 地方。 通过这样的强化训练，让大家记住这些概念、形成习惯，三个月后再与这些学员们交流 时，发现他们已经可以自然地使用这些概念进行交流，在表达的精确度、沟通的效率上取得 了明显的进步。与某个企业的员工交流，可以通过他们表达的标准和规范上判断这个企业的 工作水准。 习题 1. 简述组合原理的定义、目的及作用。 2. 简述组合原理给出的组合规律是什么？ 3. 简述组合原理与分离原理各自的作用、协同关系。 4. 依据组合原理对逻辑图的表达，能否覆盖所有的逻辑图形？ 分享 大话软件工程 四校　正文1-4.indd 70 2020-3-22 15:19:56 5. 简述要素有哪些属性、属性用来表达什么意思。 6. 讨论问题时，如果不注意讨论对象的属性会出现什么问题？ 7. 简述逻辑的概念，以及逻辑的表达形式有哪些。 8. 逻辑在分析与设计中起什么作用？试举例说明。 9. 模型与图形的区别是什么？模型有哪些分类？各适用于什么场景？ 10. 分析模型与架构模型之间是如何转换的？ 11. 在研究非企业管理类型的图形表达时，组合原理是否具有指导意义？ 第9章 架构的概要设计 架构的概要设计，是利用架构的手法对系统整体的顶层规划和设计。 架构的概要设计是在需求工程分析成果的基础之上对整个系统进行的顶层规划，重点是确 定设计规范（理念、主线等），从大的范围和高度对业务进行规划和设计，架构概要设计的成 果“业务架构图”是后续各阶段设计的依据、载体。同时，在业务架构的设计过程中明确了业 务逻辑，业务逻辑是串联起所有要素的主线，是设计的灵魂。 本章内容在软件工程中的位置见图9-1，本章的内容提要见图9-2。 工程分解 …4.详细设计3.概要设计5.应用设计 架构规划 功能规划 需求工程 架构详细架构机制 数据规划数据详细数据机制 概要规格书详细规格书应用规格书 ①架构层 ②功能层 ③数据层 需求规格书 2.需求分析1.需求调研 需求汇总规格书 需求访谈业务需求 功能需求既存表单 目标需求现状构成 设计工程 业务设计部分应用设计部分技术设计部分 … 功能详细功能机制 业务用例验证用例应用用例 工作分解 图9-1 架构的概要设计在软件工程结构中的位置 现状构成 现状框架 现状构成 现状流程流程详细 架构规划 应用架构 业务架构 转换 系统架构 审批流程 线形流程 泳道流程 业务逻辑 整体规划 结构细化 架构基础 理念& 主线 标准& 规范 局部规划 向技术设计 输出逻辑&机制 2.架构的概要设计 1.需求调研4.架构的应用设计3.架构的详细设计 □架构层设计全过程 □各阶段设计重点 流程规则架构机制 拓扑图 分层图 分解图 流程图 架构图 图9-2 本章的主要设计内容 9.1 基本概念 9.1.1 定义与作用 1. 定义 架构的概要设计，是以信息化价值为目标，确定设计规范，对客户需求进行梳理、优化， 并用架构模型表达出清晰的业务逻辑，最终确定全部业务的范围、系统/模块的划分、业务的构 成、业务的流程。 架构的概要设计是架构层的三个设计步骤（概要、详细和应用）中的第一步。也是设计工 程整体的第一步，它承担通常所说的“业务优化设计”中“流程优化”等主要工作。 注：“架构”与“设计”的区别 “架构”有名词和动词两种含义，本书只取“架构”一词的名词含义，其动词含义用“设 计”替代。“设计”是一个大的概念和过程，“架构”只是“设计”含义中的第一个层次，也 就是粗粒度的设计。 “架构”顾名思义就是搭建产品的“框架”（如同建筑物的“结构”一词的含义），“架 构”的行为不能包含全部的设计内容，完成一个产品的设计除去架构层部分外，还有：功能层 的设计（如界面、布局、规则等）、数据层的设计（数据结构、表关系、算式等）、应用层的 设计（UI、美工等），这也是本书没有采用“架构师”一词的原因。 2. 作用 架构的概要设计主要作用有两个：确定设计规范、完成业务架构的规划设计。 1）设计规范 设计规范，包含设计的目标、理念、原则、主线、标准等内容，是确定基于客户的目标需 求与业务设计师对目标需求的理解，特别是设计理念的不同，使得形成的设计主线就不同，最 终围绕着这条主线做出的业务架构也会不同，设计理念和设计主线是系统的灵魂。 2）业务架构 业务架构是承载理念和主线的主要载体，从软件工程的全过程看，这是对需求工程收集 到的现状构成图按照架构设计标准进行的第一次设计，也是从需求工程进入到设计工程的转换 点，它的作用就是将需求阶段的内容用设计的标准进行梳理、分类、规划，让相关人第一次 “看到”有规律性的业务形象，为后面的详细设计奠定基础，见图9-3。 在需求阶段获得的需求是发散的且不成体系的，在业务架构设计时，是将需求阶段收集到 的现状构成图、功能需求等用“业务架构”的方法进行“①业务梳理、②业务优化、③业务还 原”，通过这个过程让业务设计师从整体上理解和掌握业务的构成、逻辑，它是后续所有的设 计（包括业务和技术两个方面）、开发、测试以及上线培训等环节的指导依据。 大话软件工程——需求分析与软件设计 流 程 中 心 流程 模型 规则模 型 控制模 型 … 模型 业务组件库 B L1 ：招标流程 L2 ：合同管理 L3 ：物资采购 L4 ：成本管理 业务组件 C. 业务流程 D. 管控中心 A. 组件1 组件2B. 审批流程 组件31. 需求调研 -现状构成 3 .架构详细设计 -流程详细 4 .架构应用设计 -系统机制 编码开发 □现状构成图□业务流程规格书 (流程5件套) □流程系统机制□系统流程 2. 架构概要设计 -业务优化 □业务架构图 采购 生产设计销售 A 判B C ΣA>=100 →B ΣA< 100 →C 规则库 ΣA=115 采购 销售生产设计 图9-3 业务架构的变化过程 在本书中，如果没有在“架构”一词的前面加上特定的前缀，如“应用”“系统”“技 术”时，则此时“架构”一词指的就是“业务架构”，在说明业务架构以外的架构时，会在 “架构”一词的前面加上特定的前缀，形成如“应用架构”“系统架构”等。 9.1.2 内容与能力 架构的概要设计的主要内容如图9-4所示。 主要内容内容简介主要交付物名称 基础概念、需求资料 □基础概念：组合原理、架构模型 □需求分析：现状构成图（框架、分解、流程等） 1. 设计规范 □理念：设计师对系统的顶层设计的构想、方向 □主线：以价值为目标，串联起达成目标的功能 设计规范 □手法：架构设计的基本方法：分层、分区、分线、分点 □标准：架构模型在架构设计中需要遵循的要求 2. 业务架构 □总体规划：拓扑图 □局部规划：分层图、框架图 □结构规划：分解图（静态）、流程图（动态） 业务架构图 本章主要工作内容输入 图9-4 架构的概要设计内容 1.作业内容 1）设计规范的确定 设计规范中对系统构成影响比较大的就是理念和主线，它们的作用分别如下。 （1）设计理念。 针对未来要设计的系统，业务设计师要根据客户的目标需求（目的、价值、期望…）确定 对系统的设计理念，这个理念可以指导和判断信息系统应该选用的业务处理的方式、管控的手 法，以及系统最终可以为客户带来什么样的使用效果和价值等。 （2）设计主线。 有了设计理念作为追求的目的，寻找支持这个理念的核心价值点，将它们连接成线，并将 实现这些价值点的功能沿着主线展开，形成了系统设计的主线。 大话软件工程 四校　正文8-11.indd 200 2020-3-22 15:22:36 2）模型与标准的确定 （1）架构模型。 理念和主线决定了系统内在的“魂”，架构模型就是系统外在的“形”。理念和主线确 定后就是进行业务架构的设计，架构层的概要设计相当于架构的规划设计，这个设计是粗线条 的，本书挑选了五个架构模型作为业务架构设计的主要表达方式，即：拓扑图、分层图、框架 图、分解图、流程图。 （2）架构标准。 业务架构图，是业务设计中最为基础和重要的设计资料之一，它是后续所有设计的指导依 据，因此架构设计采用的基本图标、表达方式等都必须是统一的标准，只有统一了设计标准的 业务架构图才能作为工程化设计的基础资料。 2. 能力要求 架构的概要设计，可以说是软件工程中最为重要的部分，它主要是做信息系统规划的顶层 设计（决定理念、主线、标准），以及确定业务的范围、系统的划分等，完成这些内容需要业 务设计师具有相对最为全面的能力，他要掌握的知识至少要包括（不限于此）： （1）具有从整体上理解、抽提、建模的知识和能力。 （2）具有站在客户领导视角观察和理解问题的能力。 （3）对客户所从事行业的专业知识具有一定的了解（包括业务和管理两个层面）。 （4）对软件的业务分析、架构设计具有较为丰富的知识和经验（本章内容）。 （5）对软件的技术实现具有一定的背景知识。 9.1.3 思路与理解 架构、功能和数据，并称为设计工程的三大对象，架构是三大对象之首，而架构的概要设 计又是架构三个设计阶段——概要设计、详细设计、应用设计中的第一步，且由于架构在设计 工程的每个阶段都处在第一层，所以，架构层还具有对其他两层（功能层、数据层）的设计指 导作用。架构设计的指导理念就是基础概念中的“组合原理”。 同时架构的概要设计结果对后续的技术设计也起着指导和约束的作用。 1. 架构 1）架构的概念 “架构”一词有两种词性：名词、动词，在设计工程中各有不同的含义。 （1）名词：表达的是业务要素之间按照某个规律呈现出一种“结构化的形态”。 （2）动词：表达的是将业务要素“组织成某种结构的行为”。 “设计”是一个大的概念和过程，包括从粗粒度到细粒度的全部设计过程。“架构”一 词作为动词时，它描述的是一个粒度比较粗的规划行为。动词的架构含义只是设计过程的一部 分。软件行业内常用“架构”一词称呼所有设计行为（大到一个系统框架的规划，小到一个界 面控件的细节描绘），这样的划分方法就使得软件行业无法像制造业那样进行细致的规范。因 此，为了对设计的过程进行清晰的定义，不论描述对象的内容和粒度的大小，本书统一使用 “设计”一词，对“架构”一词仅使用其“名词”的含义，作为三大设计对象之一的“架构” 大话软件工程——需求分析与软件设计 定义如下。 （1）名词含义：“架构”指的是工作分解三分层（架构、功能、数据）中第一层的内容。 （2）动词含义：用“架构设计”替代，指的是对“架构层”内容的设计工作。 2）业务架构 当用于架构的要素是客户的业务活动、实体、行为、物体，且要素之间的关联关系符合业 务逻辑时，那么这个架构就是业务架构。 2.架构图 架构图，就是用来描述工程分解三分层中第一层“架构”的图形表达方式。“架构图”描 绘的是架构层的设计结果，软件的设计还包括功能层的设计、数据层的设计，它们使用的图形 与架构层是不一样的。 在非软件行业中，如制造业、建筑业务等，对产品进行规划设计的资料都称为“设计 图”，下面通过对比其他行业的设计图来看业务架构图的作用和定位。 1）其他行业的设计图 下面对建筑行业和机械行业各举一例说明设计图。 【案例1】建筑设计图纸（建筑三视图），见图9-5。 立面 剖面 平面 (d)剖面图(a)对象=建筑物(b)平面图(c)立面图 图9-5 建筑三视图 在建筑行业，设计师使用最多的就是三种基本图形，以图9-5（a）的建筑物（三维图）为 例，三个基本图形分别为平面图、立面图、剖视图，这三个图形被称为“建筑三视图”。 （1）平面图：平面图表达的是将建筑物从某个层“横向切一刀”，露出横断面，然后从鸟 瞰的视角从上向下看，表达的是建筑平面形状、内部布局、与周边的关系等，可以画多层的平 面图，如每层画一张。 （2）立面图：这个图是站在建筑物的对面看，表达的是建筑的n个立面的外观形状。 （3）剖面图：剖面图表达的是将建筑物的某个位置上“纵向切一刀”，去掉一半后，观看 剩下的另一半的内部情况。它表达的是建筑物内部各层之间的关系。 通常看到了这三种图形后，读者大体上就可以理解建筑设计对象和设计意图了。 【案例2】机械设计图（机械三视图），见图9-6。 在机械制造行业，设计师使用最多的是三种基本图形，以图9-6（a）的机械零件（三维 图）为例，三个基本图形分别为前视图、侧视图、俯视图，这三个图被称为“机械三视图”。 （1）前视图：从前视的角度看零件。 （2）侧视图：从侧视的角度看零件。 （3）俯视图：从俯视的角度（俯）看零件。 通常看到了这三种图形后，读者大体上就可以理解机械设计对象和设计意图了。 大话软件工程 四校　正文8-11.indd 202 2020-3-22 15:22:37 前视 俯视 侧视 (a)对象=零件(b)前视图(d)俯视图(c)侧视图 图9-6 机械三视图 2）软件行业的设计图——业务架构图 下面再回过来看软件的业务设计中使用的设计图——业务架构图，见图9-7。业务架构也 有类似的“业务架构三视图”，即框架图、分解图和流程图，它们可以称为“业务架构三视 图”，以图9-7（a）的企业管理为对象。 （1）框架图：表达了图9-7（b）的内容规划、范围、分区、区域之间的关系。 （2）分解图：表达了图9-7（c）中的某个区域内容的静态分解关系。 （3）流程图：表达了图9-7（d）中的某些活动之间的流程关系。 业务2 分解2分解1 活动 1 活动 3 活动 2 业务层 业务1业务2 业务3业务x 销售 采购 物流 财务 产生 仓库 … 活动x 活动2 活动3活动1(b)框架图(c)分解图(d)流程图(a)对象=企业管理 图9-7 业务架构三视图 通常看到了这三种图形后，观者大体上就可以理解业务设计对象和设计意图了。在工程分 解的不同层绘制的图形有不同的名称，例如： （1）架构的概要/详细设计阶段图形：业务框架图、业务分解图、业务流程图。 （2）功能的概要/详细设计阶段图形：功能规划视图、实体I/O图。 （3）数据的概要/详细设计阶段图形：数据视图、数据勾稽图。 （4）管理设计阶段的图形：管理架构图、管控模型。 3）软件设计图与其他图的差异 （1）建筑图、机械图，因为描绘的都是具象的、物理的物体，比较容易理解和表达，而且 它们有物理原理、空间尺寸等的约束，容易判断是否正确。 （2）业务架构，描绘的是一个抽象的对象，不易理解也不易表达，且判断图形正确与否的 依据不是物理原理和尺寸大小，而是业务逻辑、规则。 从对比可以理解，由于企业管理的业务在表达上比较抽象，所以表达的图形也是抽象的， 这里看出软件业务设计与建筑/机械设计的“相同”与“不同”。 （1）建筑/机械设计：用仿真的方式画出与未来完成后效果完全一样的对象。 （2）业务架构设计：用架构模型给企业的业务“画像”，让看不见的“成本管理”“物资 大话软件工程——需求分析与软件设计 采购”“销售管理”等业务对象可以变得能够“看得见”。 3.设计思路的变化 关于业务架构图的表述方式，由于在软件行业中传统上都是以功能实现为主导进行设计 的，所以常用的架构表达方式大都是技术视角的，造成这样的原因是可以理解的，因为在企业 管理信息化的初期，大部分获取的客户需求都是实体级的，例如： ●完成一个单体的数据记录，如设计一张收据单、开发一张分析报表等。 ●完成一个窗口型的交易系统，如图书馆出纳、财务报销、超市收款等。 在现在构建企业级信息系统时，通常为客户做的第一件事不是收集实体级的需求，而是要 先梳理企业各个层级的工作构成、业务流程、存在的问题、难点痛点，以及客户经营管理者提 出的目标、希望、价值等的需求，这就大大超出了原有技术视角的设计方法和工具所能应对的 范围，此时就需要有一套能够站在客户视角，以业务优化和实现客户价值为核心的分析与设计 方法，它先考虑的不是软件如何实现（技术问题），而是如何理解和分析客户的问题。打个比 方说，医生为患者看病的顺序是号脉→诊断→开方子，然后才是如何抓药、做手术。前者就 是业务设计要做的工作，后者是技术实现要做的工作。 4.业务设计：软件相关人的共同语言 业务架构图虽然是一种绘图的方法，但是在软件工程的过程中它是所有相关人的“共同语 言”，如图9-8所示。建立软件业务设计的标准图后，就可以获得如同建筑业和制造业一样的 效果（图9-8（a）），即所有的软件相关人看到了业务设计图就可以进行沟通、交流（图9-8 （b）），它是相关人认知的共同标准之一。 (b)软件行业（业务部分）(a)建筑行业 建筑 设计图 甲方 建筑 设计师 设备 工程师 其他… 监理 工程师 政府审 批部门 结构 工程师 业务 设计图 客户 用户 需求 设计 开发 测试 其他… 信息 中心 监理 图9-8 将设计图作为沟通和交流的依据 作者在做培训的过程中经常会听到业务人员和技术人员之间相互抱怨，都说对方听不懂自 己的意思，造成沟通不畅、传递的信息缺失或是失真，同样的问题也发生在软件工程师和客户 之间。造成这个问题的原因有很多，但最为重要的还是大家没有一个“共同用语”，每一方都 在用只有自己熟悉的方式说明问题，例如，客户用客户的行业用语、技术人员用技术特有的用 语，因为客户用语和技术用语都不能作为“共同用语”，而业务人员本身又没有特定的表达方 式，所以他无法作为桥梁去精准地实现客户与技术之间的信息传递。 业务设计方法（特别是业务架构图）就解决了这个问题，它的表达载体是符合“技术要 求”的逻辑图，但表达的内容是客户的行业“业务”，因此，就实现了让软件的相关人都可以 理解，并可以作为沟通、交流、设计和验收的依据。 大话软件工程 四校　正文8-11.indd 204 2020-3-22 15:22:37 架构图的绘制方法（画法、图标、标准）已在前面的第4章中进行了详细说明，本章中就不 再赘述，本章重点是利用架构模型和“架构的思想”进行具体的业务架构设计。 逻辑表达的最佳方式——画图 在培训绘制架构图前，老师向学员们提了一个问题：表达同一个复杂问题时，采用画图 表达和用语言（或文字）表达，哪个方法比较难和花费的时间长？大家基本上都倾向于画图 比较难，用的时间也要长。老师说：那好，培训后再向大家确认一次。 培训完，又经过了三个月实践后，老师再次向学员们提了同样的问题，此时学员当中大 约有半数的人回答说画图比语言（文字）的表达方式要容易，花费的时间也要少，且越是复 杂的问题这个效果就越明显，而且大多数人表示再不愿意用文字或是电话去说明复杂的问题 了。出现这个现象的原因是什么呢？老师做了如下的说明。 实际上，用文字和语言表达复杂内容的技能要求更高，在表达同样的复杂问题时用语言 表达是最难的，例如用语言与人沟通时，你对自己的语言表达能力即使再有信心，你也只能 一句一句地说话，也就是“说”只能按照一维的方式逐条地进行说明。但是听者却可能无法 将一句一句听来的话在大脑中组织成为立体的架构，并能够理解到多要素之间的交叉关联， 且大多数的情况下听者都是听到了第三句的内容时可能已经忘了第一句的内容。因此，不论 用多少语言或是文字，都不如一张图表达得清晰。图形不但可以让绘制者从容地将自己的思 路有条理地表达出来，而且因为它不需要听者去记忆要素，也不需要听者去寻找逻辑，更不 需要听者在头脑中建立模型，因为所有的内容一次表达出来了，特别是能够直接“看到”逻 辑这一点起的作用尤为重要。 当然，当说者和听者双方都受过架构设计的训练，在经过一段时间熟悉后，对于比较简 单的问题就可以达到“边听边在头脑中形成图形”的水平（前提是双方都受过训练）。 9.2 设计基础——设计规范 设计规范中的理念承载了“目的”，主线串联了“功能”，功能实现了“价值”。 虽然最终的软件设计是针对功能的，但是获取功能是要通过对目的、理念、价值的研究之 后才能够最终设计出理想的功能，否则就可能走偏而达不到目的。 9.2.1 设计理念 在着手对系统进行设计之前，首先要参考客户提出的目标需求（目的和希望）及期望收获 的价值来确定应该做出什么样的系统才可以满足客户的需求。 1. 设计理念的概念 企业管理信息系统，大系统和小系统相比单从功能和流程的数量看，大型的企业级系统必 定功能繁多、流程复杂；小型系统则功能少、流程也简单。那么如果同是大型系统进行对比的 话还会有区别吗？有，这个区别就在于设计理念。不同企业有不同的经营理念、战略、路线， 分享 大话软件工程——需求分析与软件设计 因此也就会产生对信息系统的不同目标要求，例如客户希望未来的系统可以支持实现产业的互 联、企业治理的透明化、绿色设计和绿色生产等。 设计理念就是业务设计师要根据客户的希望和目标，融入业务设计师自己的想法然后给出 设计指导思路。例如客户的希望信息系统可以支持“绿色设计”，那么业务设计师给出的设计 理念可以是：系统要做到全程支持“绿色设计”的各个环节，要将生产过程中可以节约（→浪 费）、复用（→重复）等环节做到极致，形成一条全过程的自动监控机制。 2.设计理念的作用 设计产品，不论是汽车、建筑，还是服装等，设计师都需要有一个设计的理念，产品设 计、项目研发等，都需要有一条贯穿全局的“设计理念”作为灵魂，这个设计理念指导和保证 了设计不走偏。理念设计的精准、到位，则后续设计的脉络、功能、客户价值都会非常清晰， 而且也容易设计。 如果有设计理念作指导，则很容易为客户设计出一套可以带来更多信息化的附加价值的系 统；如果没有设计理念作为指导，则系统可能就像一个没有灵魂的处理功能集合体。 9.2.2 设计主线 确定设计理念后，以实现这个理念为目标，将用于实现目标的功能串联成线，在功能上标 注出该功能可以带来的价值，这就是所谓的“主线”，如图9-9所示。主线包含“功能和对应 的价值”，这是作为高级业务设计师所必须具备的设计能力之一。 目标功能1功能2功能3功能…功能4主线 价值1价值2价值3价值4价值… 图9-9 设计主线的概念 已经知道了功能需求（来自于需求分析）、目标（来自于理念），为什么还要主线的概念 呢？有了功能、目标还不够，因为业务设计师还要思考用什么样的“线”引导这些“功能”到 达“目标”，这个引导就是价值。 价值可以用来确认功能的作用、该功能是否是达成目标所必需的，功能是否完善等。主线 不同，功能模块的组合方式就不同，最后完成的系统就不同。只有将功能模块与价值有机地结 合在一起，同心协力指向目标才能完美地完成任务。 一个系统内可以有若干条主线，例如，企业治理、成本管理、资金管理等。主线可以是一 条完整的业务流程，也可以是若干功能形成的一条“虚拟线”（后者更为常用）。 确定理念和主线的概念后，再次理解客户的目标：产业的互联、企业治理的透明化、制造 的绿色设计等，是否感觉就没有那么抽象、变得比较容易理解了呢？ 主线的概念除了用来支持设计理念的落地外，还有一个重要的作用就是可以帮助业务设计 师完善需求。需求调研的结果如果缺失内容、质量不高都会极大地影响到后续的设计，原因有 很多，例如，需求调研工程师的能力不足、调研时间不充分、客户的配合程度不够等。如果遇 到了要设计的信息系统属于非优化类型时，就算是没有出现前面的问题，也会由于双方都不清 大话软件工程 四校　正文8-11.indd 206 2020-3-22 15:22:37 楚系统的构成而不能收集到全部的需求细节，此时，业务设计师就需要按照理念提供的目标设 计出一条主线，这条主线不但可以将已收集到的功能需求串联起来，而且可以根据理念和主线 的指引补全缺失的功能需求。 9.2.3 规范的其他内容 ● 目标：关于目标已在需求分析中详细说明过了，在此不再赘述。 ● 原则：针对各个阶段设计的原则，详细参见各章节。 ● 标准：针对各个阶段设计内容的标准，均以模板的形式给出来，详细参见各章节。 ● 定义：各种与设计相关的用语、图形、图标、方法等的定义，详细参见各章节。 9.3 设计基础——基础手法 架构的设计知识有两个基本的内容：架构模型和架构手法。其中，架构模型已在第4章中对 模型的分类、构成、画法等进行了详细说明，本节的重点是如何通过对一个业务对象进行逐步 的拆分、组合，选用合适的架构模型最终表达出业务设计师的想法。 9.3.1 架构设计的基础 1. 架构模型的使用——粗粒度的设计 对业务进行粗粒度的架构设计采用架构模型来表达，通过不同粒度的模型对业务对象进行 拆分、组合，基本的架构模型如图9-10所示。 粗要素粒度细 弱强业务逻辑 分类整体规划局部规划构成规划(静态)运行规划(动态) ①拓扑图②分层图③框架图④分解图⑤流程图 图例 业务板块 业务1业务2 业务3业务x 业务1 子业务2子业务1 实体 3 实体 1 实体 2 实体 4 实体 x系统4… 系统1系统2系统3 数据板块 管理板块 业务板块 系统1 节点4 节点1…节点2 节点3 图9-10 不同粒度的架构模型 1）整体规划 拓扑图：对项目的全部内容进行整体规划。 先将不同业务领域的内容分化成为不同的板块，将没有直接关联的业务分开后，这样易于 理解业务的内涵、边界、板块之间的数据交互关系等，这是最上层的规划。 大话软件工程——需求分析与软件设计 2）局部规划 （1）分层图：对拓扑图中的某个业务板块进行规划、设计。 因为每个业务板块都是由业务层（还可再细分为业务、管理等）、数据层、技术层等构 成，它们的设计内容、方法等都是不同的，因此第二步用分层图将它们区分开来。 （2）框架图：对分层图中的某个层进行区域划分的规划。 通过这个规划可以再进一步对同一层的内容进行划分，分出主营功能、辅营功能以及支持 功能等，这个划分的结果决定了信息系统构成的子系统、模块等的基础。 3）构成规划（静态） 分解图：对框架图中某个区域的构成进行规划、设计。 通过这个规划可以对每个区域内的业务构成进行详细的规划，通过这个静态的构成给出了 该区域内业务要素之间的层级关系，这个分解成果为后续的功能和数据层面的详细设计奠定了 基础。 4）运行规划（动态） 流程图：表达对分解图中要素在运行时前后关系的规划、设计。 将分解图中识别出来的要素，按照完成不同目的过程串联在一起就形成了流程图，流程图 给出了业务的动态架构关系，这是指导业务运行的最重要的架构。 拓扑图和分层图，在架构设计中更多的是起着“划分、归集”的作用，而框架图、分解 图和流程图则不仅有划分和归集，而且还有“构建”的作用，它们的成果也是后续架构的详 细设计、应用设计以及数据设计的依据，后3者的设计内容要在系统中有非常具体的落实。 例如： ●框架图：是系统、模块的划分依据，是系统菜单的设计依据。 ●分解图：是基础数据（字典库）的设计依据，如组织结构、材料结构等都用分解图。 ●流程图：从流程图获得的“业务逻辑”是系统运行设计的主要依据。 如同建筑三视图、机械三视图一样，不论信息系统的规模大小，这三种图都是业务设计中 的必备图形（拓扑图和分层图在小型、简单的系统设计时可以省略）。 2.架构手法的使用——细粒度的设计 每个架构模型都是用不同的要素（图标）、逻辑（线、框等）组合出的图形，用以表达不 同的含义，这里介绍4种架构设计的手法，即：分层、分区、分线、分点，如图9-11所示。 关系1 关系2 关系3 关系x(a)分层(b)分区(c)分线(d)分点 图9-11 架构设计的手法 1）分层 分层，就是将设计对象按照不同的粒度或是不同的分类进行拆分，获得的要素分别置于不 同的层上，这是架构设计最为基本的方法，也是最为重要的方法，见图9-11（a）。 分层的表达手法在所有的架构模型中都有使用。 大话软件工程 四校　正文8-11.indd 208 2020-3-22 15:22:38 2）分区 分区，就是在一个平面上将不同分类的要素归集到不同的区域，同一区域内的要素具有高 内聚的关系，不同区域的要素具有低耦合的关系。要注意在同一个平面内的要素，不论是否同 在一区，都必须粒度相同，因为这个平面是3D分层其中的一个面，这个面上要素的粒度必须一 致，否则就不能在同一个面上了，见图9-11（b）。 分区的表达手法可以使用于分层图、框架图、分解图等。 3）分线 以某个目标为终点，将实现这个目标所需要的要素按照发生的前后顺序串联起来，就形成 了一条线，这条线上的要素粒度要一致，还要注意要素的分类、属性，例如，不要将动词要素 和名词要素连接在一起，见图9-11（c）。 流程图是此类架构手法的代表，另外，业务数据线也属于此类型（参见第14章）。 4）分点 以某个点为核心（点可以是一个：功能、模块、系统），关联与其有关的其他要素，注意 相关联要素的粒度要一致，这个点就是业务功能设计、复杂算式设计等的主要手法。 如果点是一个“系统”时，那么还可以按照分层、分区等方法重复上述过程。如果点是一 个“功能”时，就不能再划分了（再划分就进入到了功能的内部，进入到功能内部就属于详细 设计，不再是业务架构的范畴了），见图9-11（d）。 3. 架构模型与架构手法的区别 架构的“手法”与架构的“模型”是两个不同的概念。 （1）架构模型：利用架构手法形成的具有普遍意义的业务架构图形（是架构的结果）。 （2）架构手法：分层、分区就是具体的架构设计的方法（是架构的过程）。 利用架构的手法，可以创造出更多的、本书中没有推荐的架构模型。 9.3.2 设计标准 1. 绘图标准 1）模型 本书推荐的架构模型已在第4章中进行了解说，包括定义、用途、画法以及标准，在这个范 围内这些标准一定要遵守，否则由于标准不统一，每个设计师各自采用自己习惯的表达方式， 那么每次的沟通都要从图形符号的识别开始，这就无法高效率地进行设计资料的传递了，也就 难以实现工程化设计的效果了。 如果在读者设计的软件中，本书推荐的模型或是图标不够或不匹配，可以增加建立一个适 用的体系，这个体系要包括定义、用途、画法以及相应的标准。 2）图标 画图的图标已在第4章介绍过了，此处不再赘述。同样，如果不够用或不匹配，则可以参照 模型的方法进行设计。 3）粒度 图形中要素的粒度是否合适，是正确设计一张图的重要基础，关于粒度的说明参见9.3.1节 大话软件工程——需求分析与软件设计 各个设计手法中提到的“粒度”问题。 2.绘图用语 1）节点 所有在线上的块或是线的交叉点等，都可以称之为节点。“节点”一词可以用来表达一个 活动、一个步骤，当然也可以表达某个实际业务（如销售）等，见图9-12（a），用诸如节点、 活动、步骤等用语而不用具体的业务名称描述时，表明此时关心的是这个“位置”，而不是该 位置上的具体业务内容。 3.活动2.步骤4.销售1.节点 节点 (a)流程图(c)交叉点(b)分解图 图9-12 节点的概念 例如，在描述主线时，可以说“主线上的所有节点都是为了实现目标而存在的”，此时可 以不必纠结于这些节点“包含什么内容？具体的作用是什么？”这样的问题。 2）结构图 为了使基本模型具有普遍性，在不针对某个特定专业业务进行讨论时，需要使用不带模 型分类名称来描述模型或是图形符号，例如，在泛指一个图形时，只要这个图形包含要素块、 关联线，具有一定规律性、结构性，则不论它表达的是分析图、架构图，这个图形都可以称为 “结构图”，如图9-12所示。 3）系统规划 有很多的“单位”用语，不同的场合有不同的定义，在进行系统的整体规划时就要统一， 否则设计的“单位”不统一，很多定义也就会出现歧义了。例如，功能要素的集合体可以按照 需求体系和设计体系分开进行不同粒度的划分，见图9-13。 ①业务领域 （独立的业务） ②业务过程 （近似业务的集合体） ③功能需求 （活动/表单） ①业务系统/子系统 （某个领域的功能集合体） ③业务功能 （活动,字典,看板,表单） 需求体系 设计体系 ②业务模块 （近似的功能集合体） 大小系统划分粒度 图9-13 系统划分的单位名称 （1）需求体系。 需求调研、分析阶段收集到的功能需求按照业务知识的划分方法进行分类。 业务领域＞业务过程＞功能需求 其中： ①业务领域为独立的业务，如财务管理、采购管理、物流管理等。 ②业务过程为业务领域的下一级，如报销过程、核算过程、支付过程等。 大话软件工程 四校　正文8-11.indd 210 2020-3-22 15:22:38 ③功能需求为业务过程的下一级，如经费记录、成本核算、支付确认等。 （2）设计体系。 设计体系是设计知识体系的划分方法，是未来的系统体系。其中： ①业务系统/子系统可以完成独立的业务，如财务系统、采购系统、物流系统。 ②业务模块为系统的下一级，如报销模块、核算模块、支付模块等。 ③业务功能为模块的下一级，如经费记录、成本核算、支付确认等。（业务功能还可以分 为4个种类：活动、字典、看板和表单。） 原则是一样的，但是在实际划分时还需要根据客户的使用习惯、系统菜单的设置方法等共 同决定。 3. 设计用图与宣传用图的区分 业务架构使用的5种架构模型是正式的设计用图，采用了工业化的制图方式，图中不需要任 何的装饰物，包括每个点、线和背景框，都有明确的含义，这个“业务设计图”与一般的“宣 传类用图”是不同的。 （1）设计用图：用的是逻辑图，要能够经受严格的推敲、分析，系统相关人在看图时必须 要能够得出同一个结论，不能有歧义，并且必须要有数据上的关系。 （2）宣传用图：用的是概念图或示意图，用来说明主题的含义，并不要求表达精准的逻 辑，不要使用没有严谨逻辑的概念类图等来替代逻辑图作为正式的设计用图。 以上完成了架构设计前的基础准备工作，有了架构模型、架构手法后，下面就分别对架构 设计的5种模型的具体应用做逐一的介绍说明。 9.4 架构的整体规划——拓扑图 9.4.1 使用场景 拓扑图的作用是基于需求工程获得的成果，包括：业务现状构成图、功能需求一览等，对 未来系统的业务进行最大粒度的整体规划，基本形式如图9-14所示。 图9-14 拓扑模型 在进行大型的复杂系统设计时，通常一个项目可能包含若干不同目的的系统（或是需要将 新建系统与既存系统进行整合）此时就要对这个项目进行拆分，按照不同目的、不同的业务内 容，划分为几个独立的系统。这些系统相互独立，又在数据、协同上有合作。使用的场景有很 大话软件工程——需求分析与软件设计 多，例如： ●使用部门不同：同一家企业内构建的系统，需要分为不同子公司的子系统。 ●业务领域不同：同一个系统内，由于业务差异大，需要分为不同的子系统（业务 板块）。 ●部署地方不同：同一个系统，由于地域分布较广，需要拆分为不同的子系统等。 拓扑图适合于做最粗粒度的表达。首先用拓扑图进行第一次粗粒度的拆分，然后再使用其 他的架构方法，按照不同的视角，进行较小粒度的二次拆分-架构、三次拆分-架构等。另外， 拓扑图表达是“逻辑上的划分”，不管系统在物理上是否进行了同样的划分。 拓扑图的详细定义参见第4章。 9.4.2 使用案例 拓扑图用到了架构的基础手法：分区。 下面以“蓝岛工程建设集团”的企业管理信息系统为例，说明粗粒度的架构规划设计 方法。 1.第一步：结构规划 将企业的全部业务划分为不同的业务板块，每个板块的业务对应一个系统（逻辑上的或是 物理上的），并以“企业互联平台”板块为核心，将其他的业务板块联合起来，形成以企业互 联平台为中心的在业务层面和数据层面可以实现互联互通的系统。本案例采用了星状拓扑图， 如图9-15所示。 ②制造板块③建筑板块④电商板块 ⑥服务板块⑦××板块⑤培训板块 ①企业互联平台 图9-15 企业信息系统规划的拓扑图 2.第二步：要素收集 有了规划的方法，对收到的业务要素进行拆分、梳理，把不同的业务要素归集到不同的业 务板块中，如制造、建筑、电商、培训、服务等，按照拓扑图的绘制方式连接在一起形成一个 企业信息系统的拓扑图。 3.第三步：结果检查 拓扑设计的结果要满足以下基本要求。 （1）不同的业务板块内的业务是否是内聚的。 （2）每个业务板块的内容是否具有独立的价值。 （3）各个业务板块的内容（数据、业务、管控等）要保证可与企业互联平台进行交互等。 大话软件工程 四校　正文8-11.indd 212 2020-3-22 15:22:38 9.5 架构的分层规划——分层图 9.5.1 使用场景 分层图的作用是对某个子系统内部的要素，按照不同的分类和目的进行拆分，以利于集中 精力研究其中某个分类的内容，基本形式如图9-16所示。 图9-16 分层模型 拓扑图已经将处理不同业务的板块划分开来，下面就开始对其中的“建筑板块”进行分层 规划。第一步就先要将同一系统内不同作用的内容进行划分，也就是分层，这个“层”是逻辑 层面上的层，通过这个分层可以更好地理解和处理不同层内的内容。 通过层的划分可以将不同的设计要素分开，使得业务设计师可以集中精力有序地设计每一 层内的处理、层与层之间的交互，避免了将要素混杂在一起造成不同要素之间的耦合。 用分层图对企业进行粗粒度的划分时，不论该企业从事的业务内容是什么，从构成上看企 业管理信息系统都是相似的，都可以分为如下若干层（同层要素的目的相同）。 ● 业务层：将客户的业务处理内容置于此。 ● 管理层：将客户的管理控制内容置于此。 ● 数据层：将系统产生的全部数据置于此。 ● 技术层：将系统的技术相关内容置于此。 ● 维护层：将系统的运行维护功能置于此。 进行逻辑分层的意义在于，在研究业务层面的内容时可以暂不考虑数据层面的内容或是维 护层面的内容，但是业务设计师也不会忘掉其他层的存在，对研究对象的分层带来了设计上的 便利，举例如下（不限于此）。 ● 从粗粒度、大的层面上对研究对象进行定义、理解。 ● 设计时可以只关注整个结构中的其中某一层，进行深入研究。 ● 可以降低层与层之间的依赖（理解解耦设计的重要方法）。 ● 有利于设计和开发的标准化（不同层有不同的目的和方法）。 ● 利于各层逻辑的复用（不同软件项目间的复用）。 ● 结构更加明确（要素、维度减少，结构更加收敛）。 分层图的详细定义参见第4章。 大话软件工程——需求分析与软件设计 9.5.2 使用案例 分层图用到的架构的基础手法：分层、分区。 前面已经利用拓扑图将项目的全部内容进行了板块划分，下面以拓扑图中的“建筑板块” 的数据内容为例说明分层图的使用。按照不同数据处理目的进行的分层图，如图9-17所示。 1.数据采集 2.数据管控 3.数据规划 4.数据加工 1.详细设计 （活动,字典） 3.概要设计 （数据模型） 2.管理计 （规则,判断） 数据处理设计阶段 4.应用设计 （数据仓库） 5.数据查看 5.应用设计 （报表,看板） 流程监控收支监控成本监控... 经营管 理功能 生产管 理功能 财务管 理功能 … 报表查询分析… 加工数据（数据仓库） 预算主数据 看板 业务数据应用业务数据获取 数据加工 图9-17 数据规划设计分层图 1.第一步：结构规划 分层图的主要内容是分层，分层是为了更好地理解和设计，所以第一步首先确定分层的根 据是什么，例如，按照数据的发生和应用过程进行分区，从下到上，依次为数据采集、数据管 控、…、数据查看。 2.第二步：要素收集 收集每一层的要素，这里要根据分层表达的目的来确定要素的粒度，为了表达的方便，可 以在每一层内用粗粒度划分出区，但是要注意这里的工作重点不是分区，而是利用区的名称来 显示该层的内容。 3.第三步：结果检查 分层设计的结果要满足以下基本要求。 （1）同层内的关系要内聚，不同类的内容不要放在同一层。 （2）同层内要素的粒度要一致，不可大小不一。 （3）上下层的顺序要满足以下原则：上层内容依赖于下层，下层内容不能依赖于上层。 即：下层的内容发生了变化→会影响到它直接上层的内容； 上层的内容发生了变化→不能影响到它直接下层的内容。 与图9-17相关的详细说明参见第14章。 大话软件工程 四校　正文8-11.indd 214 2020-3-22 15:22:39 上述案例采用了三维形式的分层图，分层图的核心在于“分层”，实际上不论是三维还是 二维的图形中都存在着分层，在二维和三维图形中分层的表达区别如下，见图9-18。 (b) 二维表达(并列)(c) 二维表达(叠加) 层1 层2层3 层1 层2 层3层3 层2 层1(a) 三维表达 图9-18 分层图的多维表达方式 1）三维分层图的表达 可以从六个面来布置各个层之间的位置，更加形象、直观地表达出各层内容之间的关联 关系，缺点是绘图比较复杂。如果表达的内容具有普遍意义，并且有复用价值，可以使用， 如图9-17所示的内容就比较复杂，且具有普遍意义。 2）二维分层图的表达 也可以采用二维的表达方式，表达简洁、直观，同时绘图也比较容易。缺点是二维图形 只能表达四个面的位置关系，对应内容复杂的对象表现力比较弱，直观效果比三维要差一 些，如果是图9-17的内容就需要用多张图形来表达。 分层图，粗粒度的分类手法 在培训过程中，很多学员对分层图表示不解，分层图看似简单，又好像没有什么实际作 用，其内容好像用拓扑图、框架图等也能够表达。 课堂上老师出了一道较为复杂的分析课题，需要用画图的方式进行表达，拿到题目后学 员们都急于用分解图、流程图去画最终的结果。待大家将图画完之后，老师用投影仪把大家 的作业展示出来并要求学员之间进行相互的解读点评，此时出现了很多有趣的现象。 A学员：B学员的图不该将完全不同分类的要素放在一起，内容看起来像一个“大 杂烩”。 B学员：C学员的图内容太多，看不出图的意图和逻辑是什么，且图的内容和标题不符。 C学员：A学员在一张图内放入了不同阶段、不同层次的内容。 出现了什么问题呢？经过大家一起继续分析，发现问题都出在了对画图的要素没有进行 梳理、分类，能画的内容恨不得都画在一张图上，表面上看是：内容杂乱无章，看得人透不 过气来，但本质上是制图者心中没有清晰的对象构成、分类，以及对象之间的作用关系等。 理解了问题所在之后，大家重做了一遍，这次要先画分层图用以梳理对象和关系。果 然，先用分层图进行梳理后，框架图、流程图等就没有了不同要素混在一起的现象，完成的 图形给人清晰、耳目一新的感觉。 分层图，起到了一个粗粒度的梳理、划分、确定关系的作用，它将不同的内容分别置于 不同的层上，但同时又给出了不同层之间的关系。 分享 大话软件工程——需求分析与软件设计 9.6 架构的区域规划——框架图 9.6.1 使用场景 框架图，是“业务三视图”之一，是所有系统设计时都必须要绘制的基本图形，当项目 是一个小型的或是不复杂的系统时，可以省略拓扑图和分层图，但是不论项目的内容、规模和 复杂度，框架图都是不能省略的，因为框架图的内容是对系统的整体描述，基本形式如图9-19 所示。 图9-19 框架模型 当对某个特定层的内容进行设计时重点就是对同层内的要素根据它们的目的进行划分，划 分的方法是“分区”，从分区的结果上可以让读者获得如下信息。 ●这个层覆盖了哪些业务内容、层的边界在哪里。 ●层内有哪些业务领域、各领域的边界在哪里。 ●各个领域的内容，领域之间的相互作用关系等。 框架图的结果不但是对业务的分区，还是后续划分子系统、功能模块的依据，甚至是系统 菜单的设计依据，参见图9-20对信息系统的内容规划。 （1）系统的划分：核心功能系统、辅助功能系统、应用功能系统。 （2）模块的划分：在“核心功能系统”中划分出不同的模块，如营销、招投标、合同等。 （3）功能的划分：这个企业信息系统的规模比较大，因此在这个框架图中无法直接显示 出功能粒度的内容，例如，在图9-20（a）的一级框架图中“核心功能-合同”模块的下一层中 会有图9-20（b）的二级框架图“合同签订、合同变更”等功能，此时就需要在另外的图中表示 了，也就是说根据架构对象的规模，需要绘制的框架图可能不止一张。 当然，子系统、模块等都是相对的概念，具体称为子系统还是模块要看系统的规模、业务 设计师的设计意图等因素。 框架图的详细定义参见第4章。 9.6.2 使用案例 框架图用到的架构基础手法：分区、分层。 前面已经利用分层图对建筑板块的内容划分了层，下面以分层图中的“业务层”的内容为 大话软件工程 四校　正文8-11.indd 216 2020-3-22 15:22:40 例说明框架图的应用。 企业知识 企业规章制度 财务法律法规 生产工艺功法 常用填报模板 安全质量 知识培训 员工守则 基础数据 客商信息 材料信息 设备信息 合同信息 招标信息 市场价格信息 供应商信息 … … 进度计划技术采购设计 售后招投标营销合同服务 环境质量安全物流加工 …法律成本会计财务 经 营 管 理 战 略 规 划 综 合 查 询 指 标 分 析 绩 效 评 价 业 务 监 控 企 业 架 构 决 策 支 持 … 312 合同模块 合同 签订 合同 变更 合同 编制… 一级框架图 二级框架图 应用功能区辅助功能区 核心功能区 图9-20 业务板块功能的框架图 1. 第一步：结构规划 同层要素很多，首先要确定分区的依据，例如分为3个大的区块，如图9-20所示。 ①核心功能区：主要用来处理业务（输入、输出、计算、监控等）。 ②辅助功能区：为业务功能区的输入/输出、应用功能区的查询/展示提供支持。 ③应用功能区：对业务功能收集和加工的信息进行查询、分析。 2. 第二步：要素归集 依据框架的规划，为各个区填入相关的功能需求，主要的来源有以下三个部分。 （1）通过需求调研和分析获得的功能需求，参考功能需求一览、现状构成图等。 （2）通过理念和主线设计而增补的功能需求。 （3）为支持业务处理的顺利进行而新增的辅助性功能需求。 3. 第三步：结果检查 （1）确认业务整体的边界、各个区块的边界是否合理，是否覆盖了需要的内容。 （2）各个分区的粒度是否相同（这一点非常重要，也很难）。 （3）排列的位置关系业务是否符合业务逻辑的表达方式（位置、包含等）。 （4）业务框架图特别要注意不要出现“技术用语、技术图形符号”，例如，在图中加入 “××数据库”“××技术框架”等内容，这些都不是业务的内容，也不是业务设计用语，这 些内容只有在应用设计和技术设计时才会出现，在业务设计阶段使用这些用语会使得业务与技 术设计的界限不清楚，造成理解的偏差。 框架图的画法看似最简单，但却是架构图中相对难度最大的图形。框架图多用来进行架构 的顶层设计、初始规划，因为越是靠近顶层的设计，图形中的要素就越少，图形的构成就越是 要求精简，因此要求业务设计师的抽提能力也就越强，所以判断一张框架图设计的水平高低， 并不是图中的要素越“满”越好，而是要层次清晰、粒度合适、逻辑舒畅。 大话软件工程——需求分析与软件设计 分享 越简单的内容越难表达 关于框架图在架构中的设计和作用，老师问学员一个问题：业务的三视图（框架、分 解、流程）中哪一种最难画？从事业务分析和设计的学员普遍都说：框架图最难画，看似内 容最少，又没有箭头，但是一画起来就觉得无从下手。另一面，有的程序员就说流程图有 用，但是框架图没有什么作用，拿到手里也基本上都不看。为什么会出现这样的现象呢？老 师分别请从事业务工作和技术工作的学员来回答框架图的难度和用途。 （1）从事业务工作的A学员回答：为什么框架图难画。 因为框架图表达的是系统的整体规划，如果设计者的能力不够，只会看单个的功能点， 没有能力理解全局、把握不了整体的范围、整体和局部的关系、局部和局部的关系等内容， 那就很难做出合理、舒服的系统规划图（框架图）。 （2）从事技术工作的B学员回答：框架图是否有用。 通常开发功能的数量从几个到十几个时，有没有框架图的影响并不大，但是当要开发的 功能数量达到上百个甚至几百个时，只有功能一览而没有框架图那就晕了，感觉到开发没完 没了，既不知道开发到了什么地方，也不清楚开发的内容之间到底有什么关系、用途等。 老师最后又做了补充说明：框架图多用于顶层的规划，越是顶层的内容，越是粗粒度的 内容，越不易画，理由是顶层的架构需要思考的内容多，要给出大的布局，要有意识地忽略 细节，所以落在图面上的内容少，但是可以从大的布局中感受到细节的存在。 框架图与流程图相比，就相当于“小区的规划图”与“某栋楼的建筑图”的关系，没有 “小区的规划图”就找不到“某栋楼”在小区中的位置。 9.7 架构的结构规划——分解图 9.7.1 使用场景 分解图，是“业务三视图”之一。 分解图用于标示要素的业务结构关系，可以用分解图将要素的关系逐一进行分解展示，反 之，也可以用来将具有关联关系的要素进行汇总，展示出它们之间的结构关系。分解图是架构 图中使用最为广泛的模型之一，同框架图一样也是所有设计中不可省略的图形。常用于表达物 体、工作等之间的结构关系，基本形式见图9-21。 图9-21 分解模型 大话软件工程 四校　正文8-11.indd 218 2020-3-22 15:22:40 1. 分解的业务要素 用分解图可以表达所有具有上下级、从属等关系的业务要素，例如： ● 对关系的表达：组织构成、成本的构成、客商的构成、产品的构成等（用名词表达）。 ● 对工作的表达：工作分解、活动分解等（用动词或动名词表达）。 ● 对物体的表达：材料构成、产品构成、设备构成等（用名词表达）。 2. 分解的系统要素 用分解图可以表达构成系统的要素（节点）的关系，主要是功能和数据，例如： ● 功能：以业务功能为要素，表达子系统构成→模块构成→功能构成。 ● 数据：以数据为要素，其粒度可以是：数据表、数据分类。 分解图的详细定义参见第4章。 9.7.2 使用案例 分解图用到的架构基础手法：分层、分区。 下面以图9-20框架图中“核心功能区——成本”模块的内容为例说明分解图的应用。 1. 第一步：结构规划 从成本模块内抽提出要素一致的内容，根据需要，规划出要素的分解层级，在每个层级中 再划分几个区域。本案例的分解图由4个分层构成，其中，分层 4中是由5个分区（分组）构成 的，如图9-22所示。 实际成本 直接成本 人工费材料费其他直接费机械使用费 间接成本 分层1 分层2 分层3 分层4 分区3 内部劳务费 外部劳务费 消耗材费用 周转材租赁费 周转材摊销费 机械使用费 租赁机械费 安装拆除费 工具摊销费 安全文明施工费 临设摊销费用 检测实验费 干部工资奖金 办公费 差旅费 固定资产折旧费 图9-22 成本构成的分解图 2. 第二步：要素归集 按照每个层级中的项目，收集其属下的要素。 分层2中的“直接成本”由于内容较多，所以比同级的“间接成本”多分了一层，在分层3 中又进行了数个分区（分组）的分解。 收集时要注意要素的一致性，本分解图的顶层要素的单位是“成本”，所以以下的内容不 但要使用名词，而且还必须是可以用“钱”来计量的单位（“成本”和“费”都是可以用钱来 衡量的），只有如此这些要素之间才能存在着分解/汇总的关系。 大话软件工程——需求分析与软件设计 分享 3.第三步：结果检查 （1）内容的统一，如果是对“物”或“事”分解，则名称应该是名词；如果是对“工作” 或“活动”分解，则名称应该是动词或是动名词。 （2）同层要素的粒度要一致，同区的要素要同类。 （3）要素如果是数字，则上下级之间要可以进行分解和归集的计算；如果要素是文字，则 上下级之间要有逻辑关系。 注：关于工作的分解图 图9-22是对“事/物”的分解图，分解图还可以用在对 “工作（做事）”的分解，在用于对“工作”进行分解时要注 意节点必须都是“活动”。“工作”是指客户的业务行为，它 的范围可大可小，大到可以是一个“财务管理”工作，小到可 以是一个“报销填表”工作，而“活动”是工作中的最小单 位，在系统中这个“报销填表”就是一个活动（只有活动级的 业务才有对应的业务界面）。 在工作的分解图中不能出现某个节点是一个名词的要素。 如图9-23中的“合同书”和“分析表”，这两个表单是工作的结果，它们不是工作本身，所以 在绘制分解图时应该去掉。 分解图，是最为典型的结构表达方式之一 培训中，学员们说，“业务三视图”中框架图和流程图使用得比较广泛，但是分解图除 去用在组织结构、材料分类上好像用得不是太广泛，实际情况又如何呢？ 在实际中，分解图可能是使用最为广泛的，甚至比流程图还要广泛，老师启发大家找找 看在实际工作中有哪些地方使用到了分解图概念的场景，例如： （1）组织结构、材料分类； （2）图书的目录、方案的提纲； （3）软件系统的功能菜单、树形界面； （4）二维表格等。 9.8 架构的流程规划——流程图 9.8.1 使用场景 流程图，是“业务三视图”的最后一张图，只要研究对象中有连贯性的活动，就会存在流 程图。流程图的设计主要分为两个类型：业务流程和审批流程。由于流程图是架构图中最小粒 工作1 工作2.2工作2.1 活动1 活动2 合同书 活动x 活动4 分析表 图9-23 工作分解图 大话软件工程 四校　正文8-11.indd 220 2020-3-22 15:22:40 度的设计，且涉及具体的数据和规则（流程分歧），基本形式 见图9-24。 业务流程图，是架构图中与用户实际工作关系最为密切的 图形，用这个图形可以模拟、优化用户在信息化环境下的工作 过程，其他类型的模型是系统设计、开发的重要依据，但是用 户在实际工作中不一定能够直观地感受到它们的存在。利用业 务流程的设计主要有以下目的（不限于此）。 1. 目的一：建立业务流程的标准 每一条业务流程都是为完成某一个特定目标而建立的，设计一条业务流程就是为企业建立 实现这个业务目标的标准。确定了流程的目标，然后根据这个目标将相关的业务活动按照一定 的业务逻辑进行关联，流程上全部的业务活动都要围绕着这个目标进行设计。 一条标准、完整的业务流程架构模型要包含以下5个基本环节（小型的业务流程不限于 此），如图9-25所示。 ①目标⑤结尾②计划③执行④监督 图9-25 完整业务流程的标准环节 ①目标：确定这条业务流程运行完毕要达成的目标。 ②计划：对目标值进行分解，分解后得到的分目标值是流程管理的监控对象。 ③执行：依据目标，寻找构成业务流程所需要的业务活动（节点）。 ④监督：在业务流程需要管理的节点上设置管理规则。 ⑤结尾：对每个分解目标的执行结果进行清算，其总值的合计不得超过目标。 2. 目的二：既存业务流程的优化 根据新的管理理念和方法、新的工艺工法等对既存的业务流程进行完善和升级的过程称为 “流程优化”，优化后的流程会提升工作的质量、效率、效益。 业务流程的优化设计有两个参考对象：一是需求调研阶段获得的企业流程现状构成图；二 是企业所属行业内的最佳样板流程。优化的流程与两个参考对象的关系如图9-26所示。 步骤2… ①客户的原始流程： 　客户描述业务过程 ③经过优化的流程： 　优化后的业务流程 步骤1步骤3步骤X 活动1活动X活动2活动3活动4… 现状构成 (优化下限) ②行业的最佳流程： 　最优的样板流程 活动1活动y活动2活动3…活动x 流程优化 （最佳） 行业典范 (优化上限) 图9-26 流程优化标准参考 ①客户的原始流程：给出了流程优化的下限（即优化后的水平不能低于此下限）。 ②行业的最佳流程：给出了流程优化的目标，它可能是行业标杆，是最佳实践结果。 图9-24 流程图 大话软件工程——需求分析与软件设计 ③经过优化的流程：因为加入了新的理论、方法、工具，优化的结果一定要高于流程现状 的水平。但是最终优化的流程也不一定选择业内的最佳流程，这是因为优化的结果要与导入信 息系统企业的环境、资源、能力、成本、时间等条件相匹配，否则可能发生事与愿违的结果， 消耗了大量的资源最终也未能达到最高的管理水平。 3.目的三：业务功能的完善 在需求阶段获得的功能需求一览其内容是处于松散状态的，表中的功能之间的关系尚不明 确，这些功能需求是否是真实的需求呢？如何来精确地回答这个问题呢？答案是用业务流程来 判断，因为业务流程可以表达出清晰的功能之间的业务逻辑、数据逻辑关系，通过这些逻辑关 系的推演就可以解决前述的不确定功能，通过业务流程可以帮助确定功能的概要设计的业务功 能一览。 这也是为什么要在业务功能设计前要先完成业务架构设计的原因之一，没有业务架构，特 别是业务流程，难以从业务逻辑的维度来正确地判断功能需求的真伪。 注：目的与目标的区别 “目的”是指行程的最终点，可以将行程分为几个阶段，每个阶段就是一个“目标”，用 几个目标的接力就可以完成最终的目的。例如，从北京到广州，广州是最终目的，在全过程中 设置了郑州、武汉、长沙三个目标，三个目标依次达成后，就可以达到最终目的了。 流程图的详细定义参见第4章。 9.8.2 使用案例 流程图用到的架构基础手法：分线。 下面以图9-20框架图中核心功能区的“采购”模块内容为例说明流程图的应用。 1.第一步：结构规划 按照前述的架构标准框架的5个环节搭建流程的基本结构，包括： （1）确定流程目标：对成本的过程进行管理，最终完成成本的合计不得超过预算值。 （2）确定起止点：从物资预算编制开始，到核算支付结束。 （3）确定关键节点：例如分歧的设置位置、条件等。 2.第二步：要素收集 采购流程图的绘制参考了两个资料，如图9-27所示。 （1）资料1：采购流程的现状图，它是来源于需求调研阶段的成果。 （2）资料2：新增的功能需求，它是来源于对业务流程的优化成果。 (b)资料2：新增功能需求(a)资料1：材料流程现状图 入库登记采购合同发货通知物资验收 物资需求预算统一采购计划 现场采购计划物资索赔 结算支付 图9-27 需求分析的成果 大话软件工程 四校　正文8-11.indd 222 2020-3-22 15:22:41 经过对采购流程现状图的分析（资料1），以及对采购流程的优化要求（资料2），业务设 计师给出了最终的采购流程优化结果，如图9-28所示。分析与设计的主要步骤如下。 1.物资 预算编制 7.入库 登记 3.自采 计划编制 2.统采 计划编制 5.发货 通知 6.物资 验收 8.合同 索赔 物资需求 预算书 统一材料 采购计划材料采购 合同书 发货 通知单 到货 验收单 材料 入库单 se 合同 索赔单 结算单 自行材料 采购计划 4.采购 合同签订 9.结算 支付 业务活动 业务实体 图9-28 业务流程图与对应的实体 （1）按照客户提出的目标需求之一“成本的过程管理”，将“物资预算编制”模块作为采 购流程的起点，后续所有的活动都要以这个预算值为目标，合计值不得超过目标值。 （2）根据设计理念以及其他的需求，通过业务流程的优化补足原业务流程中不足的功能， 例如，计划编制、物资索赔，并在关键节点上增加管理用的审批点（审批流程），见图9-29。 ①目标⑤结尾②计划③执行 1.物资 预算编制 7.入库 登记 3.自采 计划编制 2.统采 计划编制 5.发货 通知 6.物资 验收 8.合同 索赔 se4.采购 合同签订 9.结算 支付 ④监督 审审审 预算总额支付总额 过程金额 图9-29 业务流程与流程标准的对应关系 （3）确定和补全所有节点上的业务实体（每个活动至少要对应有1个实体）。 3. 第三步：结果检查 流程设计得是否合理，可以用标准流程架构模型为检查依据，见图9-29中①～⑤，说明 如下。 ①目标：建立流程的目标 通过对物资需求的规划，建立其流程最终不能超过的目标（总额，数量等）。 ②计划：对目标进行分解 通过分解目标达到可执行的程度（如月度需求计划），因为大型的采购可能不是一次完 成，而是根据实际生产的进度分批购入的。 ③执行：执行流程的中间活动 按照采购计划签订采购合同、购入材料、验收、入库等，执行流程的中间活动。 ④监督：监督流程的运行过程 监督行为是在每个活动中发生的，例如，目标是否过低、计划是否合理、执行中有无超 大话软件工程——需求分析与软件设计 标、收尾依据是否有错误，监督一直伴随着流程以保证可以达成目标。需要设置多少个管控点 合适是根据客户需求和系统的设计理念确定的。 ⑤结尾：流程的结束 对照着目标，对每一个分解目标的执行结果进行核算，其总值的合计不得超过目标值。 注：关于审批流程的说明 由于审批流程是一个管理的概念，在本章中审批流程只是作为节点上的审批控制点，这个 部分的详细设计放在12.4节中说明。 这里做个简单的小结，对比一下对采购流程优化的前后（图9-27（a）与图9-29），可以看 出如下变化。 ●业务层面：对完成采购的业务进行了充实、完善，采购的过程实现了标准化、规范化。 ●管理层面：加入了管理规则，确保业务流程可以达成最终的目标。 经过业务流程的优化设计，读者可以理解了需求并不完全是来自于对客户的原始调研。 9.8.3 流程划分 在掌握了流程的使用场景和使用方法后，对于流程的规划和设计还需要补充两点，即：流 程的分解和长度的确定。这两点主要是由于在系统中流程是非常容易发生变化的架构部分，因 此在流程设计时就要特别注意流程在系统中的应变能力。 1.流程的分级 流程的设计会根据节点的粒度不同，而出现多级流程的表达。例如，在顶层的设计中，可 以用“系统”级粒度的要素作为流程的节点，这样绘制的流程可以帮助业务设计师从高层次上 理解业务的运行，但是按照流程的定义，流程的节点只有是“活动”级粒度的要素才能执行， 不是活动级的节点是不能执行的，因此就需要对流程进行分级设计，如图9-30所示。 活动1活动2活动3…活动x 模块1模块2…模块x 系统1系统2系统x一级流程 二级流程 三级流程 图9-30 业务流程的分级概念 （1）一级流程：节点是系统，是从整体上理解系统之间的作用关系，其中含有二级流程的 节点执行完成后，一级流程才能向前推进。 （2）二级流程：节点的粒度小于一级流程的节点，是对一个系统内模块之间关系的表达， 其中含有三级流程的节点执行完成后，二级流程才能向前推进。 大话软件工程 四校　正文8-11.indd 224 2020-3-22 15:22:41 （3）三级流程：节点是活动，是流程构成的最小粒度，也是流程可执行的最大粒度，“活 动”级的节点是由业务功能构成的，因为业务功能中含有数据和规则，所以以活动为节点的业 务流程才能够被执行。 2. 流程的长度 对在信息系统中运行的业务流程设计，不同于一般管理咨询师所绘制的企业流程。一般 管理咨询师在绘制业务流程时，经常会将企业的某个领域内的活动全部画在一条流程上（当 然也不区分节点是否是动词），这样的流程非常长、节点非常多，同时流程分歧节点也多， 有时会多达5级甚至更多，流程非常复杂。管理咨询师这样绘制业务流程是可以的，因为他只 是将企业现状总结梳理出来或是表达未来的企业活动过程，他绘制的流程图不是信息系统的设 计图（或只是作为参考图）。但是作为信息系统的业务设计师就应该避免做这样长且复杂的流 程，这种流程的设计方式带来的弊端很大，因为这样的流程在系统中运行后，如果在某个节点 上发生了需求的变化就很难维护，常常会因为改动一点而影响其他多处，造成“牵一发而动全 身”的现象。 设计适合于在信息系统中运行的业务流程时，一定要将业务对象拆分得比较小，每个处理 模块或是每条流程都比较简单、短小，然后由小的模块和流程通过“组合”的方式来处理较大 的复杂业务对象。在设计流程时，除去前述讲的要分级以外，还要注意流程的长度，碰到需要 比较多的活动联合处理才能完成的业务对象时，可以利用一些中间的处理环节将流程变短。如 图9-31所示，图9-31（a）中的两条流程比较长，可以利用中间功能（如数据库）将流程拆分成 若干段，形成如图9-31（b）中的形状。 仓库 数据库 流程A 流程B 流程A1 流程A2 流程B1(a)现状业务流程图 (b)拆分后信息系统业务流程图 流程A 流程B 图9-31 流程的拆分 （1）流程A分为：流程A、流程A1和流程A2。 （2）流程B分为：流程B、流程B1。 如此拆分后，当流程A和流程B发生需求变化时，由于每一段的流程长度都变短了，因此而 带来的影响范围也就会相应地变小了。 大话软件工程——需求分析与软件设计 9.9 综合应用案例 9.9.1 各类图形的变化 至此，已经讲解了图形符号和基本模型（第4章）、绘图手法和模型在规划中的应用（本 章），前面都是按照个体去说明模型及其应用的，下面通过基本模型的变化案例，加深读者理 解这些模型的含义以及如何灵活地应用基础模型。 1.分析模型与架构模型的转换 同样的内容，分别用鱼骨图和分解图来表达时有什么不同呢？如图9-32所示。 结果 原因1原因2 原因3原因x 结果 原因2原因1原因3原因x 图9-32 鱼骨图（归集）→分解图（定性定量） （1）鱼骨图：作为分析模型，它表达的是一种“原因-结果”之间的归集关系，说明可能 是这些“原因”造成了这个“结果”，它们之间的关系只是定性，但不定量。 （2）分解图：作为架构模型，它表达的是“结果-原因”之间的结构关系，说明这个“结 果”就是由从属的这些“原因”造成的，它们之间的关系不但定性，而且定量。 2.5种架构模型之间关系 5种架构的基本模型之间，从表达的业务粒度上、逻辑关系上有以下的关联关系，可以利用 这些关系对业务进行分层架构设计，如图9-33所示，从左到右，由粗到细。 (c)框架图(d)分解图(e)流程图(b)分层图(a)拓扑图 系统3业务板块 业务1业务2 系统4… 系统1系统2系统3 数据板块 管理板块 业务板块 活动4 活动1…活动2 活动3 业务2业务1 子业务2子业务1 活动 3 活动 1 活动 2 活动 4 活动 x 图9-33 架构模型之间的关系 拓扑图：相对独立的业务板块的集合体。 分层图：将拓扑图中的“A”板块展开，形成一个A板块的分层图。 框架图：将分层图中的“业务层”展开，形成一个框架图。 分解图：将框架图中的“业务2”展开，形成一个分解图。 流程图：将分解图中的“活动1～活动x”组成一条流程图。 大话软件工程 四校　正文8-11.indd 226 2020-3-22 15:22:41 注：流程图的形成 只有当分解图表达的内容是工作分解，且分解图的最下端节点是“活动”时，才能建立分 解图与流程图的关系，否则分解图与流程图是无关的。另外，如果框架图中要素的粒度是活动 级时，也可以从框架图过渡到流程图。 上述架构模型之间的关系并非是绝对的，会根据不同业务内容有所差异。 3. 分层图与框架图的转换 1）将分层图转换为框架图 分层图9-34（a）中的“1.业务层”的内容分为4个区：业务A1～业务D1。 图9-34（b）：将业务层的内容用二维的框架图展示，可以看到有4个业务分区（A1～D1）。 图9-34（c）：将业务层的内容用三维的框架图展示，不但可以看到4个业务大分区，还可 以看到各大分区下面的小分区（粒度A1＞A2＞A3），当要表达的业务是由多层要素构成时， 可以使用三维图表达。 1.业务层 业务D1业务C1 业务A1业务B1 业务D1C3C2 业务C1A3A2 业务A1B3B2 业务B13.辅助层 2.管理层 1.业务层 (c)框架图（三维，侧视）(b)框架图（二维，俯视）(a)分层图 图9-34 分层与分区的关系 2）将分层图转换为不同布局的框架图（降维转换） 从图9-35（a）的分层图可以清楚地看出来各个层之间的相互作用关系。但是把它改用二维 和一维的平面图形来表达时，就会发现很难表达出三维图中4个层之间的相互关系。 (b)框架图（二维）(a)分层图（三维） (d)框架图（一维）(c)框架图（二维） 业务层 管理层 技术层 支持层 数据层 支持层 业务层 管理层 技术层 数据层 业务层 管理层 技术层 支持层 业务层 管理层 技术层 数据层 支持层 支持层 图9-35 图形维度数不同，效果不同 大话软件工程——需求分析与软件设计 图9-35（b）：支持层的位置不对，它应同时与其他4个层相接，现在它只与技术和数据层 相接。 图9-35（c）：将支持层分置于左右是可以的，但是数据层没有做到同时与其他4个层相 接面。 图9-35（d）：用一维表示时，就失去了原分层图的含义了，看不出相互的作用关系。 4.分层与分区的应用 在架构的设计手法中谈到了分层和分区的方法，从图9-36中可以看出，不同的模型中这两 个手法基本上都存在，因此，不论是利用分析模型，还是利用架构模型进行绘图时，都要非常 注重对图中不同的内容采用分层和分区的方法表达关系。 层 区 层区 层 一级 流程 二级 流程 (b)分解图(a)框架图(c)流程图 图9-36 分层与分区的相互融合 5.用不同模型表达相同内容 如图9-37所示，对相同的内容（①～④共4个要素）采用不同的模型表达，有什么不同呢？ 合同管理 ①采购计划②合同编制 ③合同审批④合同变更 合同管理 ② 合同 编制 ① 采购 计划 ③ 合同 审批 ④ 合同 变更 ② 合同 编制 ① 采购 计划 ③ 合同 审批 ④ 合同 变更 se 合同管理流程 (c)流程图(b)分解图(a)框架图 图9-37 相同内容不同表达——逻辑的变化 框架图：4个要素之间没有紧密的关系，是4个各自独立的模块，是弱逻辑关系。 分解图：4个要素之间没有直接关系，都是从属于合同管理的内容，较强的逻辑关系。 流程图：4个要素之间有紧密关联（逻辑、数据），是强逻辑关系。 从上述几个案例中可以看出，尽管推荐给读者的图形符号、基本模型以及设计手法不是很 多，也没有很难记忆的规则，但是在绘制图形时还是要非常严谨，注意每一个符号、模型及手 法的不同所带来的不同含义。 9.9.2 模型的组合使用 本书虽然只是推荐了5种架构模型，但实际上通过这5种模型的组合（混搭）可以获得丰富 的表达形式。下面通过3个案例来说明方法，这3个例子是典型的组织机构（分解图）和业务流 程（流程图）的关联，可以用来表达不同的含义。 【案例1】不同组织层级的目标分解表达，见图9-38。 大话软件工程 四校　正文8-11.indd 228 2020-3-22 15:22:42 大话软件工程——需求分析与软件设计 以这个基础图形为基础，还可以根据需要再增加其他的信息，例如，角色、规则等。 【案例3】不同部门的业务与流程之间的关系，如图9-40所示。 签约运输设计加工 采购 sYNe核算 合约部 编 制 … 签 约 …部 ……… 采购部 询 价 采 购 … 物流部 计 划 调 度 运 输 财务部 计 划 核 算 … 合约部调研…部调研采购部调研物流部调研财务部调研 业务内容 组织机构 业务流程 图9-40 不同部门的业务与流程间的关系 通过将组织部门、各个部门的业务与跨越多个组织部门之间的业务流程建立对应关系，这 样就可以展示出组织的静态结构和生产过程的动态流程之间的关系，对于分析业务、优化业务 等带来帮助。 从上述案例可以看出，不论要表达什么样的内容，图形如何变化，只要符合绘图的标准 （包括图形符号、基本模型）和逻辑表达方式，图形不但容易绘制而且易懂，做到让读者可以 “无师自通”。读者可以尝试其他的不同组合。 小结与习题 小结 1. 架构对业务梳理的价值 通过对原始需求的一系列梳理，最终将“无形”的企业业务整理成“形”。对企业业务 的梳理，用图形还是用表格会带来不同的效果，如图9-41所示。 （1）需求调研（图9-41（a））：收集客户原始需求，其目的、作用、逻辑关系等不清 晰、不准确。 （2）需求分析（图9-41（b））：按照业务领域归集成表，但是要素间的逻辑关系没有 形象化的表达。 （3）业务架构（图9-41（c））：按照业务逻辑，将需求要素进行架构设计，使得原来 不清晰、不准确的关系用架构图全部清晰、准确地表达出来，相当于给企业的业务进行扫 描、成像，让企业的业务可以直观地“看到”，从这3个表达方式可以看出架构图给出的信 息是无法用语言和表格来表达的，图形表达最重要的特点就是让逻辑“外露”。 2. 架构对设计与开发的价值 业务架构图对技术设计和开发有着直接的作用和价值，例如业务流程为设计和开发提供 了两大价值（不限于此）。 大话软件工程 四校　正文8-11.indd 230 2020-3-22 15:22:42 业务板块 业务1业务241X23业务1 子业务2子业务13124x 数据板块 管理板块 业务板块业务领域 业务过程 12341市场开发信息获取信息跟踪客户关系… 2投标管理投标启动标书策划 3合同管理合同洽商合同交底合同履约… 4成本管理成本测算成本计划成本控制… 5物资管理计划管理采购管理… 6设备管理计划管理调拨管理日常运转… … 企业战略 集团财务 进度管理 质量管理 物资管理机械管理 风险管理 档案资料 电子商务 财务管理 信息门户 通信视频 需用计划 安全管理知识管理 运营方 … 采购合同 材料入库 合同管理 成本管理 招投标管理 竣工管理办公管理 人力资源 经营核算 财务管理 施工方 建设方 设计方 (a)收集原始需求(b)表格-按领域归集(c)图形-按逻辑架构 图9-41 架构对业务梳理的价值 1）价值1：业务流程提供了业务逻辑 业务功能的详细设计（4件套的内容）是基于业务逻辑才获得了业务功能的上下游的数 据来源、数据关系的，可以说没有业务流程就没有业务逻辑，没有业务逻辑就无法进行数据 关系、流向的设计。业务流程是通过业务功能的设计（业务4件套）间接地提供了价值。 2）价值2：业务流程提供了进行“事找人”机制设计的基础 让系统中的业务流程可以实现自动地进行“事找人”，这个设计依据就是业务流程，但 是“价值2”并没有被广泛使用，这对业务架构设计成果来说是一个重大的损失。 关于“事找人”的理念和内容参见第16章。 3. 模型内容与使用顺序 架构的概要设计，给出了业务架构的5种基本模型的使用方法，以及它们在实际应用中 的使用顺序，见图9-42。 （1）拓扑图：对研究对象的内容进行系统的划分、关联。 （2）分层图：对拓扑图中某个系统的内容进行分层规划，如业务层、数据层。 （3）框架图：对分层图中的某个层进行详细的分区规划，如功能区、应用区。 （4）分解图：对分层图中的某个区进行详细分解，如成本分解、采购工作分解。 （5）流程图：对框架图/分解图的活动部分进行流程关联，如采购流程。 4. 模型与逻辑的强弱关系 本章的成果实现了原始需求中的业务知识表达向逻辑表达转换的第一步，通过这一系列 的架构设计工作，将原来的“零散业务”，通过架构模型的逻辑表达方式，形成了一套完整 的、清晰的、符合开发要求的“逻辑表达方式”。业务不再是用表格、语言、零散的功能需 求来表达的，模型从拓扑图到流程图，用不同强弱的逻辑表达形式将研究对象一步一步地从 粗粒度的弱逻辑关联走到了细粒度的强关联，见图9-10。 习题 1. 什么是架构设计？架构与设计的概念有什么区别？ 2. 理念、主线的概念对一个信息系统的规划、设计有何重要的指导意义? 3. 简述架构设计有几种基本的设计手法？各自表达的意图是什么？ 4. 架构模型与分析模型的使用目的、使用场景，以及表达的含义有什么区别？ 5. 在业务分析过程中，架构模型起了什么作用？没有架构模型哪些分析结果无法表达？ 6. 简述拓扑图的使用场景、使用条件。 7. 简述分层图的使用场景、分层的条件。 8. 简述框架图的使用场景、作用。为什么说框架图是架构设计中必须使用的模型？ 9. 简述分解图的使用场景，分解图的节点使用名词或动词是分别代表什么含义？ 10. 简述流程图的使用场景、条件，业务流程与审批流程的区别，两者的关系。