如何绘制逻辑图——要素的属性：系统与模块（5）

在上一篇文中已经介绍了描述要素状态的属性（黑盒与白盒），这一篇要说明描述要素的归属名称。

我们知道，“系统、“模块”等都是“功能”集合体的名称，那么将一些功能集合成为一个整体时需要遵循什么原则？这个集合体有什么特点？用图形表达有什么标准要求呢？

在绘制逻辑图时，任何一个“框”都代表着一个系统或是模块；因此，搞清楚系统、模块的概念、特点、原则等对于正确绘制逻辑图、传递逻辑意图是非常重要的。

属性3：系统与模块，是要素归集的单位。

一、系统与模块的概念

1. 系统的概念

系统：是由一群有相互作用关系的功能要素组成的集合体。

图1 系统的概念

前面讲过的要素属性有：粒度/分层（表达要素的大小）、黑/白盒的（表达要素的内部是否可视）概念；除此之外，还需要对要素的集合体给予说明，把一群有相互作用关系的要素的集合在一起称之为系统或模块。

系统的概念有三层含义：

• 系统是由若干要素组成的，这些要素必须是功能，可以用来处理业务，如：合同签订、计划编制、材料采购、物流派送等，而不能是“物”（比如：桌子、电器、材料等）；
• 系统内部要素之间存在相互作用的关系，能够形成一定结构体；
• 同一系统中的要素通过相互作用可以具有处理某类业务的能力，如：销售管理、财务管理、物流管理、订单管理等。

仅考虑要素的粒度和包含关系、不考虑相互作用时，可以将一群要素的集合体之为“对象”；但是在考虑要素之间的相互作用时，要素的集合体一般就要改称为“xx系统”了。

再进一步，考虑的处理业务的属性时，在系统二字的前面加上业务用途做前缀就形成了不同的业务系统，如：财务系统、生产系统、人资系统、物流系统等。

系统也有粒度的概念，小型的集合体可以称之为：子系统，大型的集合体称之为父系统，或简称为系统；父、子系统是个相对的概念，不同的系统之间不好直接进行大小的比较。

2. 模块的概念

模块：是由一群可处理某个业务场景的功能要素组成的集合体。

作为要素集合体名称的概念，模块可以看成是比系统小一级的要素集合体。

由于系统、模块和功能这三个词在不同的场合、面对不同的描述对象时定义都不同，为了避免出现表达的混乱，三者同时出现的场合，可以做如下的约定：

• 系统：是具有独立处理某个业务领域工作的完整功能集合体，系统是由模块组成的；
• 模块：是分担系统中的局部处理工作的，模块是由功能组成的；
• 功能：是系统中可以完成某个业务处理操作的最小独立单位，不可再拆分；

这三者都是由功能构成的，在粒度上的关系为：系统＞子系统＞模块＞功能。

在构成上的关系为：

• 系统 =Σ（n个子系统）
• 子系统=Σ（n个模块）
• 模块=Σ（n个功能）

注：“模块”还具有另外一层含义，被称之为模块的要素群必须具有“可以组合、拆分”的功能；比如：软件系统中的xx模块，就意味着这个xx模块可以替换；如果被称为xx系统时，则不强调这个要素集合体是否具有可组合、拆分的功能。

二、系统与模块概念的作用

在绘制逻辑图时，特别是图中有大量的要素时，要特别注意对这些要素的归集，要素归集的集合体根据大小的划分就可以分别称之为系统、模块等。

下面举例绘制企业业务功能的框架图来说明概念的作用：

1. 画法一

将企业的业务划功能分为三个业务领域，分别命名为：主营区、辅营区和支持区，如图2所示，这三个区就代表了三个系统。

图2 业务功能的组合

主营区：主营区内的有4个子系统，构成了企业业务的主体，它们分别代表了4个主营业务板块，包括：①销售管理、②财务管理、③设计管理、④生产管理，因为它们是企业产生价值和收入的主要功能，所以称之为主营业务，这里表达的4个子系统是处于“黑盒状态”；如果对子系统再进行拆分（如②财务管理），就可以看到其内部的模块、功能等细粒度的要素。

辅营区：辅营区的子系统是用来对主营区和辅营区的业务进行辅助管理的，包括：财务管理、人资管理、信息中心等，它们不是直接生产价值的，而是为了保证价值顺利产生的功能。

支持区：这些子系统是为主营区业务提供服务的，包括：后勤管理、物流管理等。

2. 画法二

也可以把三个区的内容都看成是一个“系统”，每个区看成是一个子系统，进行降级的名称标注；可以看出，要素群名称的标注是相对的，重点是一定要对要素群的划分有层级的概念。

扩展说明：

模块化设计的概念，就是将具有不同作用的功能进行多种组合，以实现用有限的功能支持多样的业务处理场景。

功能要素按照要求，被归集到不同的系统中，每个系统可以独立地处理某个业务领域的工作，且每个系统都具有标准的对外接口。

按照需要，可连接更多的具有不同功能的系统组合在一起，以完成更加复杂的任务；通常我们做所的系统规划都具有这样的特点，以企业管理的功能框架图为例来说明模块和模块化的关系。

举例，按照企业管理信息系统的设计方法*1，客户的业务处理模块与管理控制模块需要分开来进行设计，业务模块与管理模块各自遵循各自的技术、标准完成各自的架构设计，然后再按照模块化的要求组合到一起，参见图3：

图3 业务功能与管理功能的模块化组合

这里将处理业务用模块设计为图（a）的形式，对业务模块进行管理控制的模块设计为图（b）的形式，这两个模块通过组合可以给出不同的解决方案，这里试举2例。

• 方案1：将业务模块（a）和管理模块（b）进行组合，形成了方案1（对流程加工节点进行“c”管理）。
• 方案2：将业务模块（a）和管理模块（b）进行组合，形成了方案2（将管理“c”从加工节点移到采购节点）。

方案1与2的变化在管理模型的“c”上，从图中可以看出，变化的管理模块与不变的业务模块可以给出不同的组合。

当外部市场发生变化时，企业需要调整管理模式，由于业务模块（流程图）与管理模块（PDCA模型）是各自独立的；因此可以不断地更换管理的模型（因为管理易变），而不必改变业务架构（如果业务不需要改变的话），这就是模块化的设计带来的效果。

本系列下一篇博文：如何绘制逻辑图 — 6.要素的属性：内聚与解耦

相关阅读：

如何绘制逻辑图——逻辑图构成的三元素（1）

如何绘制逻辑图——要素的属性（2）

如何绘制逻辑图——要素的属性：粒度与分层（3）

如何绘制逻辑图——要素的属性：黑盒与白盒（4）

作者：李鸿君；《大话软件工程—需求分析与软件设计》一书作者。

本文作者 @李鸿君

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！