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,系统用例和主角
而系统用例是在需求阶段被提出来的,我在指南中注意到,在系统用例中,只有“主角”的概念。我这样理解这两个概念。系统用例就像楼上朋友所说:是系统分析员用来阐释主角与系统本身如何交互(或者说是一系列动作)来完成业务用例的。具体的一个系统用例中,只能有用例的驱动者(主角),而不该再出现任何以人为基础的角色(换句话说就是“人”不该参与到系统用例中去)。我举个例子:保存输入的信息 用例 是个很典型的系统用例(好像就叫用例),驱动者:主角、响应者: 系统本身。
通过我上面的分析:系统用例的某种组合,就构成了一个业务用例!或者按照实际的流程来说:业务用例最终会被分解为系统用例的集合。
对于业务用例我是这样理解的:业务主角(business actor)驱动某个业务用例,在这个业务用例中,其他业务主角(甚至包括驱动者自己)都被认为是业务角色(Business worker),而业务角色与业务主角进行了“交互”(如信息的传递、报表的处理等),最后返回给业务主角一个有价值的确定值。
2,系统用例和主角
而系统用例是在需求阶段被提出来的,我在指南中注意到,在系统用例中,只有“主角”的概念。我这样理解这两个概念。系统用例就像楼上朋友所说:是系统分析员用来阐释主角与系统本身如何交互(或者说是一系列动作)来完成业务用例的。具体的一个系统用例中,只能有用例的驱动者(主角),而不该再出现任何以人为基础的角色(换句话说就是“人”不该参与到系统用例中去)。我举个例子:保存输入的信息 用例 是个很典型的系统用例(好像就叫用例),驱动者:主角、响应者: 系统本身。
通过我上面的分析:系统用例的某种组合,就构成了一个业务用例!或者按照实际的流程来说:业务用例最终会被分解为系统用例的集合。
对于这块的深刻理解,我会在后面的学习过程中继续提到。