使用UML停止业务分析（二）——“消费订单管理”实例介绍

前一篇对根本的UML概念和关系做了介绍，本节以作者目前从事的制造企业信息化行业中的“消费订单管理”业务需求为例，介绍业务分析是如何停止的。

关于计算类控制类系统不适用UML的看法

也有说法说计算类的系统软件是用不着UML业务分析的。我觉得也对，也不对。觉得不对是因为计算类系统其实也是可以套用主角、用例和活动这一思路的，详细参见《大象-Thinking in UML（第2版）》p223第三个讨论。另外，第一次接触UML，理论UML的时候就是在做核电力学分析法设计系统时。虽然当时感觉这一套太费事了，但至少能最后分析清楚，搭建出非常好的程序构造。说对，是因为计算类系统更加注重的是系统内部的算法逻辑，很少考虑人机交互，考虑人的因素。拿我的CAE开发为例，所有的CAE开发和二次开发都是前处置、求解器、后处置三大模块顺序执行，不会考虑业务目的，主角和用例。在开发的时候，只需要注意能让客户把参数设置完成，求解的时候能正确处置理论方程保证求解正确，能正确展示出来就行了。至于用例、活动、场景描绘等都不是重要的内容。

名词解释

UML最根本的目的就是“统一建模语言”，是为了让不同业务人员、软件工程人员等参与系统建立的参与者可以用统一的语言停止交流沟通，防止产生歧义和错误理解。这点对于企业信息化来说是非常重要。在这几年的产品研发过程中，确实发现工业软件研发的一大障碍就是跨学科的综合性人才匮乏，各学科人才协作工作不容易，无法很好的互相理解。
在领域驱动开篇也是提到，一定要统一语言，并且要向业务侧的专业名词靠拢，明晰统一名词非常重要。但假设要做到名词统一，必需深化理解每个词组甚至每个字的意思，才干精准的代表一类事物。这就要求较高的语文素养，有深究的意愿。但需要注意的是，最后不要陷入文字游戏的境地。我语文水平一般，只能模糊的给出以下两个名词的解释：
消费订单是指废品或半废品的消费指令；
消费任务是指现场人员可以详细执行的消费指令；

明确业务目的

对于制造业来说，消费订单是一切消费活动的起点，一般是通过接受销售订单人工转换成消费订单或者使用MRP功能将销售订单拆解为各个零部件的消费订单和产品的装配消费订单。根据普通的中小型离散制造业对消费订单管理的需求，可以梳理出如下一些业务目的：
1.消费订单管理（理解销售订单业务和消费整体业务的人）（工厂方案员）：
1.1.根据销售订单，创建废品和半废品的消费订单；
1.2.可以通过手动录入、导入和系统集成的方式创建消费订单；假设创建的消费订单仅仅是废品或独立需求件的消费订单，则可以根据BOM分解生成半废品的消费订单；消费订单可以修改，以更改日期、消费优先级、数量等；消费订单可以停止数量的合并拆分，以优化消费执行；消费订单可以撤销、可以发布；
1.3.消费订单可以直接下发到车间，也可以依照工艺段（需支持子工艺道路）下发到车间，由车间根据产能和优先级布置消费分派；也可以根据工艺道路通过排程直接布置到详细的工位/设备/班组，生成消费任务；
1.4.可以查询消费订单状态和进度信息；
一开端考虑这个业务场景的时候，仍然是依照传统老路，依照模块去梳理用例和活动，迷惑到底销售订单拆分为零部件的消费订单到底算不算在消费订单管理业务边境内。回头看看书，再理解下，发现当时忽略了业务目的。再以业务目的为动身点，一下子就非常明晰了，而且也能得到比较好的业务边境。

定义业务边境

目的清楚后，就可以根据一个个的目的来定义业务边境在哪里。
1.1根据销售订单，创建废品和半废品的消费订单。我们就可以晓得，方案员、销售订单管理员（假设负责拆分非独立需求件订单）可能都是这个目的相关的主角，而业务内部就是创建消费订单的整个用例。

发现业务用例

原则上，每一个业务目的都会对应一套参与者、用例、实现等整个过程。但在真实应用中，业务目的不一定非常严谨，不一定逻辑正确。所以，折中的，可以聚集好几个业务目的来生成一套用例过程。
以整个消费订单管理所有业务目的动身，发现主角就是方案员，方案员要达成目的需要做以下事情：

创建消费订单根据销售订单和消费实际调整消费订单发布消费订单，布置消费；查询消费订单进度；
以用例图形式展示：




在开端使用用例图时，发现用例图用例非常多，颗粒度不好掌握。渐渐的，才发现，依照业务目的去梳理用例图时非常适宜的。每个用例只需要能完好描绘一个业务目的即可，但是不需要将如何实现的。 如何实现是在用例场景中去描绘的。这就可以较好的控制用例的颗粒度了。

业务用例场景

理论上，需要为每一个用例停止用例场景、实现场景建模；但假设业务复杂，时间和资源有限，只能将一些可以使用流程串到一起的用例集中停止描绘；实际应用中，鉴于用例场景是描绘如何实现用例的，要求每个用例至少用2个及两个以上的活动来描绘；对于无法放到流程中的用例，假设非常重要，则需要单独描绘，否则可以不描绘，如调整消费订单。
tips:
(最好不要以下图方式，虽然节省时间，但可能比较乱，将多个用例放到了一张图上，变成了“流程图”)
在绘制用例场景活动图或泳道图时，最好依照规范的活动图来绘制，这对开端学习非常重要。当用例场景存在多个主角和参与者时，以参与者维度使用泳道图来描绘会比较明晰。

用例实现场景

对于每个业务用例，对应有多个业务用例实现；如创建消费订单，用户可以通过手动添加，导入或第三方集成接口同步的方式实现创建消费订单。即创建消费订单用例对应了三种用例实现。对于创建消费订单用例，在用例场景中已经分解为1,2.1,2.2,2.3三个活动；理论上，可以对每个活动停止用例实现场景建模，即每个活动可能对应着三种实现场景。如1.查看销售订单等信息，可以通过Excel查看，通过纸质单据查看或在其他系统中查看。
实际应用中，只需要对涉及到系统交互的某些关键性活动或复杂活动停止详细的用例场景实现建模。为节省时间和本钱，可以将整个用例场景一起停止实现场景描绘，仅对其中涉及到多个实现场景的活动做拆解描绘，同时，可以过滤掉非本版本内容的实现场景。采用泳道图或页面流程图采用实现分支描绘清楚。

业务对象

通过这个流程，不难看出实现此业务目的的多个用例过程中，主要包括消费订单这个业务对象。详细对象属性就不再描绘了。

总结

通过上面，我们非常清楚的实现了从业务目的不时转化胜利能交互的过程。认真回忆这个过程，是不是很自然而然的，逻辑性非常好。面对一个新的行业或新业务，是不是不再需要通过大脑网络的黑盒计算，以自己都不晓得功能是怎么蹦出来的方式来设计功能了呢？最后，还有一点比较重要，就是初学时，一定要依照规范的UML规范来绘制各种图，深化浅出，打好根底，为以后的灵敏应变打好根底。