前一篇对基本的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规范来绘制各种图，深入浅出，打好基础，为以后的灵活应变打好基础。