狐狸糊涂 10:06:10
请教大家一个问题：
业务建模应该包括哪些东西？
青润
10:07:14
RUP
中关于业务建模目的地描述是：
①
了解目标组织（将要在其中部署系统的组织）的结构及机制。
②
了解目标组织中当前存在的问题并确定改进的可能性。
③
确保客户、最终用户和开发人员就目标组织达成共识。
④
导出支持目标组织所需的系统需求。
为实现这些目标，业务建模工作流程说明了如何拟定新目标组织的前景，并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。
狐狸糊涂
10:08:11
寒，我说错了。。应该是业务模型包括哪些东西。。而不是建模～
狐狸糊涂
10:08:46
这些东西应该是看得见的。
青润
10:09:09
业务模型，就是一个模型文件，你的这个包括那些东西，应该是说：业务模型需要说明哪些问题，才对吧？
狐狸糊涂
10:09:53
我想问的是，应该用哪些东西来描述一个业务模型。
青润
10:10:18
噢．呵呵
这样就明白了，那就是应该用那些符号或者语言来描述业务模型．
狐狸糊涂
10:10:41
对的，我就是想问这个。呵呵。
青润
10:10:44
这在我的书上没有直接提出来，但是，应该可以看到用到了哪些．
狐狸糊涂
10:11:20
能不能就我自己的意思先描述一下，如果您有时间的话希望能指正一些错误，或者遗漏～
青润
10:11:20
业务用例图，状态／活动图／泳道图
青润
10:12:11
没关系，你说，大家的观点都可以表达出来．
我的做法，只是我的一些体验，并不一定完全正确．而且，我用到的也不是全部的Ｕｍｌ，只是我需要用到的部分而已．
狐狸糊涂
10:13:42
我想的（也是这么做的）是
:
业务模型应该是由
2
个部分构成的，
1
是数据模型；
2
是业务逻辑（业务流程）
。我做的过程中是由
use case
－－》
根据
use case
设计出整个数据模型，然后对应每个
usecase
会由对应设计到的数据模型以及对应的流程（业务逻辑）。
这样下来就可以把所有的
usecase
通过数据模型＋业务逻辑来描述出来。
同事对每个
usecase
都会由角色的约束。
不知道这样来做，是否合理？
青润
10:16:39
你的做法和我的方法是相似的，应该没有什么问题．
不过，我在对状态／活动图的用法上是有一个定义的：
状态图绘制大的阶段或者需要细化的操作；
活动图模型绘制小的活动或者被细化的操作细节．
具体的可以在我的书中找到对应的内容．
狐狸糊涂
10:18:44
哦，终于明白了。我就是觉得在我那种方法中，对业务逻辑的描述就容易出现一个问题。描述的颗粒度的控制。
太大则无法完全描述业务，太细则又显得臃肿。
原来你是分别用状态图和活动图来描述不通颗粒度的业务逻辑。
不找到我这样说是否正确？
青润
10:20:54
基本上差不多．
尤其在Ｕｍｌ图中，Ｓｔａｔｅ表示的就是阶段或者需要被细化的活动，ａｃｔｉｖｉｔｙ我用来表示不需要被细化的活动和行为．
青润
10:21:58
(此处图像显示不出来，只好暂时放弃)
就是这两个图例
狐狸糊涂
10:22:12
是不是可以这样理解，
state
描述的是更加泛化的，而
activity
则描述的就是细化的？
青润
10:22:17
可以．
青润
10:22:34
一个ｓｔａｔｅ下面会有多个ｓｔａｔｅ和ａｃｔｉｖｉｔｙ
狐狸糊涂
10:22:41
好的，谢谢青润～
