UML-业务建模

UML全程实作 写道

用UML画图很容易，但要知道画什么是很难的。

以前画图，拿来就画。很少去考虑现在是业务建模 or 系统建模，画的是业务用例 or 系统用例，业务时序图 or 系统时序图，一句话，没有真正搞清楚。

先谈谈业务组织（研究对象），业务建模首先必须明确研究对象，否则无法做后续的事情，所以在业务建模时候，第一句话是问自己：我们的研究对象是谁？

业务执行者（Actor）：在业务组织（研究对象）之外和业务组织（研究对象）交互的人或组织。

业务工人（Business Worker）：业务工人在业务里（我觉得是业务组织更加合适）。

业务实体（Business Entity）：可以和业务工人相互取代职责。把系统看成业务中的一个业务实体。

现在正在做一个某M系统和支付宝对账的系统。

研究对象是谁？应该是财务部门。

业务工人，财务人员

业务实体，自动对账系统。

业务执行者，好像没有么，业务组织之外，那应该是公司高层或者ISV（对财务数据关心的童鞋们）咯。

 

先看一下现有系统的业务序列图是如何的（改造前，只是描述大致业务）

改造后的业务序列图

 

写道

消息的名字：代表责任和目的，A请求B做某事
消息的方向：责任的委托，不是数据的流动；

从改进后的业务序列图来看，应该有两个用例图：1）ISV查看对账单2）财务人员自动对账

 

怎么样才能看出改进点：

1）涉及到信息的流动么？（物流变成信息流）

2）包含的业务逻辑能封装到系统里吗？

3）涉及到怎么样的业务对象？

 

改进点需要我们不断的采用阿布思考法：探索普通人没有考虑到的问题。

 

最后再来看一下业务用例和系统用例之间的区别是什么

 

RUP的指南 写道

1，业务用例中划分了业务主角和业务角色。
对于业务用例我是这样理解的：业务主角（business actor）驱动某个业务用例，在这个业务用例中，其他业务主角（甚至包括驱动者自己）都被认为是业务角色（Business worker），而业务角色与业务主角进行了“交互”（如信息的传递、报表的处理等），最后返回给业务主角一个有价值的确定值。

2，系统用例和主角
而系统用例是在需求阶段被提出来的，我在指南中注意到，在系统用例中，只有“主角”的概念。我这样理解这两个概念。系统用例就像楼上朋友所说：是系统分析员用来阐释主角与系统本身如何交互（或者说是一系列动作）来完成业务用例的。具体的一个系统用例中，只能有用例的驱动者（主角），而不该再出现任何以人为基础的角色（换句话说就是“人”不该参与到系统用例中去）。我举个例子：保存输入的信息 用例 是个很典型的系统用例（好像就叫用例），驱动者：主角、响应者： 系统本身。

通过我上面的分析：系统用例的某种组合，就构成了一个业务用例！或者按照实际的流程来说：业务用例最终会被分解为系统用例的集合。

  

 对于这块的深刻理解，我会在后面的学习过程中继续提到。