#业务系统和软件系统的边界,一般系统与环境的边界有所不同.txt

一些关于UML的经典讨论

作者 内容 
 outputdebugstring   业务用例一定要是business actor直接驱动得嘛
　
--------------------------------------------------------------------------------
 
按RUP上所说无business actor使用得用例就应该踢飞，那有些系统得业务用例模型就会变得很少，那是不是主要放在业务对象模型里呢？？ 
比如医院来说，actor是病人，那他无非是挂号，交钱，看病，拿药，体现不出来什么啊？
 
 04/04/07 09:29 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 outputdebugstring   还有管理活动也是，rup中业务用例的3类活动中包括管理活动，但是管理活动通常是由worker做的，要不要画用例呢？
　
--------------------------------------------------------------------------------
 
rup中业务用例的3类活动中包括管理活动，但是管理活动通常是由worker做的，要不要画用例呢？
 
 04/04/07 13:30 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  要灵活处理"内/外"的边界
　
--------------------------------------------------------------------------------
 
不管是业务用例和用例,建立内外边界的概念是关键. 
主角Actor在外,worker在内. 
没有主角在用例外的需要,worker在用例内就白忙活. 
这是最基本的道理. 

对于一个系统(业务系统或软件系统)的整体,这时候边界在整体对外的接口上,如果我们仅仅在整体上描述接口上的行为,可能显得过于抽象或简单,不能表现整个系统的价值传递关系.于是我们需要深入到整体内部的部分. 

深入到部分是不是就一定要用对象模型来表达呢? 
当整体在粒度上已经足够清晰地表达系统内部的价值关系时,再往内深入就将表明价值关系是如伪皇迪值氖焙?是应该用对象模型来表达了. 
如果整体在粒度上还不足够清晰地表达系统内部的价值关系,此时仍然可以使用用例模型来表达.不过,此时要灵活处理系统的"内/外"边界. 

顺着原来系统整体外部主角所需要的价值向系统内部探索,看这个价值是如何被系统内部不同的部分分阶段逐步实现的,那么在系统内部的这些不同部分之间也会存在价值关系,这就是所谓内部客户和内部服务的关系. 
于是我们可以把提供内部服务的单位定义为子系统,享受内部服务的单位定义为子系统的主角.这样一来,原来整体上的内部Worker就有可能成为内部子系统用例的外部主角. 
如此叠代递归地深入下去,直到建立对象模型. 

这样分层建立的用例视图,正是系统构架的核心视图,它表现的是系统价值体系的构架.当我说到"用例驱动"有"价值驱动"之意的时候,单从技术的角度是难以理解到的. 

　
 
 04/04/08 08:38 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 javawebstart  一般来说，业务用例的第一个业务角色也可以作为此业务用例的主角
　
--------------------------------------------------------------------------------
 
 04/04/08 08:50 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 outputdebugstring   从理论上将是应该像您说的，但是怎么实际操作呢
　
--------------------------------------------------------------------------------
 
比如第一层画了直接由actor驱动的usercase，我的想法是其他的内部子系统另画他们内部的用例，这些用例就是由worker驱动的了。但是这些子系统怎么和第一层的用例连上呢，直接关联到某些用例上？有些好像没有语义关系，因为他们对actor来说是透明的。是自动化内部的事。 

另外一个问题就是如果这样演化下去，会不会成立系统用例图，二者的区别是什么呢。原来我任务主要是边界的划分，如果worker也画了用例，二者边界就基本一致了 

您曾经留过msn在这里，能再留一次马，在您有空的时候讨教^_^
 
 04/04/08 09:39 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 sealw  如果一个医院能让病人很满意地完成挂号，交钱，看病，拿药，这个医院就很成功了。
　
--------------------------------------------------------------------------------
 
 04/04/08 09:46 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 panrglory  回复: 要灵活处理"内/外"的边界
　
--------------------------------------------------------------------------------
 
这样理解内/外对么？ 

 
 04/04/08 12:30 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 lee_sure  回复: 业务用例一定要是business actor直接驱动得嘛
　
--------------------------------------------------------------------------------
 
业务与系统的用例的区别体现在此。业务用例可以理解为操作者的行为，是客户能提出的需求。系统用例可理解为系统的行为，来支持/协助操作者完成其行为，是对需求的另一方面的阐述。
 
 04/04/08 12:51 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  非常好的一幅图!
　
--------------------------------------------------------------------------------
 
panrglory的图清晰地表明了软件的信息逐层明晰的过程. 
如果把市场研究/软件定位层再细化为业务分析的几个阶段,就更加完美了. 
如果把这张图理解为横向的过程坐标,那么在这个坐标轴上的每个阶段做一个纵切,就是软件模型演化过程的不同层次的版本.如业务用例模型,业务对象模型,系统用例模型,系统对象模型,系统实现模型,部署模型等. 

我回答楼主的话题不在整个宏观过程上,而在具体的用例模型的构架上.但"内外"的概念和上述宏观过程是一致的.具体内外概念要结合事例才能表术清楚. 
如 
一个企业对于顾客而言,只能表现整个企业的外部视图.企业内部各部门的协作对于顾客而言就是内部视图. 
而对于企业内部的市场部而言,开发部则表现的是开发部的外部视图.开发部经理如何管理部门内部开发过程,对于市场部就是内部视图. 
我指的灵活性,就是要灵活而清晰地变换分析的参照系,参考点.而方法上,始终就只需要用"用例模型/对象模型"交替运用就可以了.在不同的抽象级别建立的"用例模型/对象模型"对具有不同的意义和作用.必须针对项目的情况进行有选择性建模.
 
 04/04/12 09:31 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  业务系统和软件系统的边界,一般系统与环境的边界有所不同
　
--------------------------------------------------------------------------------
 
实际操作不清楚,还是因为概念没有理顺. 
在谈用例方法的一般原理的时候,内外的边界指的是:一般系统与其周边环境的边界. 
而业务系统和软件系统的边界只是上述边界的一个特例,做业务用例模型的目的之一,恰好就是要明确这个边界. 
如果你要做企业的业务模型,你站在企业外面顾客的角度看过了企业,然后你从一个企业的大门进入一个企业,站在总经理的位置看看各部门外部的运作,你完全还可以再进入市场部或研发部的大门,看看各工作组外部的运作...,没有人要求此时一定要进入电脑软件系统内部去看每个软件子系统外部的运作。你只需要站在部门里面看看电脑系统从外面看看需要给部门解决什么业务上的问题就是了。甚至不需要描述软件系统外部的运作，因为这是系统用例模型的任务。 

你可以看到，我们的观察点在不停地变换，而每次变换都意味着深入或变换了一个内嵌子系统，当我们从一个内嵌子系统内部看它如何满足外部环境大系统的需求的时候，我们用对象模型，当我们从外部环境大系统看内嵌子系统对外应该提供什么服务的时候，我们用用例模型。 

计算机系统正好就是企业业务系统的一个特殊的内嵌子系统。说它特殊，是因为它不是按照组织层次结构表现的从业务功能嵌套的角度来划分的，而是从信息处理的计算机手段层面来划分的。相类似的子系统还有如：企业大厦给排水系统，通信系统，供电系统等。业务建模，实际上就是从组织结构层次分析业务嵌套功能来解析，信息处理的计算机手段层面的功能需求，最终拼凑出信息处理的计算机手段层面的完整画卷。
 
 04/04/13 09:35 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 sinohong   既然已经提到business actor和business worker
　
--------------------------------------------------------------------------------
 
那么就继续吧。当然，business actor和business worker本身就可以用来设定系统边界。 

实际上RUP里面很直接的描述了几乎和这个一模一样的问题，你可以看看这篇“Guidelines: Going from Business Models to Systems”。 

你当然不是打算开发一套无人看守完全自助医院，是吧。你正在开发的是实际一套给医生啊、挂号处、交费处使用的信息系统而已。那么很明显的，这里business actor是病人，而医生、挂号处等等就是business worker。 

你看了那篇文章就会知道，在进行系统分析演进的时候，business actor从最后的use case模型中消失了，而每一个business worker会成为最后的use case模型中的一个actor并且有相对应的use case。而这些use case，就是你的系统最终要满足的需求。甚至，每一个business use case对应的功能都可以对应到一个子系统去。比如，挂号子系统，交费子系统等。 

当然，如果某些business worker的工作要自动化，比如实现自助挂号，那么当然对系统的分析就会变化，这时候business actor会保留在最后的use case模型中，business worker则消失了。 
这些都在那篇文章里做出了详细地说明。
 
 04/04/14 17:30 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 panrglory  软件过程中的用例驱动原则使“用例”变得重要
　
--------------------------------------------------------------------------------
 
我谈谈自己的理解吧：用例UseCase有三种理解 
1.操作 
2.功能 
3.需求 
可想而知，把用例理解为操作肯定是不恰当的，其实这就是大家都一致批判的“用例划分过细”的做法 
把用例理解为功能和需求是流行的观点，我个人倾向于理解为需求。我认为理解为功能的做法，实际上混淆了两个原则“用例驱动”和“模块封装”，“用例驱动”和“模块封装”是系统分析中相互独立的两个不同原则 

----- 
“用例驱动”实际上只有需求驱动的含义，这是可以想当然地得到的 

对于小的功能软件我们可以直接写函数；对稍大一点的软件，需要划分模块降低复杂度，每个模块直接写代码；对于更大的软件，我们只能把整体划分成一些模块，然后把子模块再划分成若干模块，这就叫做“模块化封装” 
----- 

把用例理解为功能，则同时蕴涵了“模块封装”和“用例驱动”两个原则 
把用例理解为需求，则只是强调“用例驱动”的原则
 
 04/04/18 12:03 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 outputdebugstring  回复: 业务系统和软件系统的边界,一般系统与环境的边界有所不同
　
--------------------------------------------------------------------------------
 
那您的意思是不是在顶层是actor直接驱动的，再下一层进入子系统后，worker就转换成Actor使用，进入子系统后通常是看不到actor了(通常是企业的客户)，这一层用来描述子系统的边界，如此下去，直到需要描述自动化的系统功能之前停止。
 
 04/04/27 11:21 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 outputdebugstring   回复: 业务系统和软件系统的边界,一般系统与环境的边界有所不同
　
--------------------------------------------------------------------------------
 
那您的意思是不是在顶层是actor直接驱动的，再下一层进入子系统后，worker就转换成Actor使用，进入子系统后通常是看不到actor了(通常是企业的客户)，这一层用来描述子系统的边界，如此下去，直到需要描述自动化的系统功能之前停止。
 
 04/04/27 11:21 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  我基本上是这样理解的
　
--------------------------------------------------------------------------------
 
准确一点说:在划分子系统之后,一个子系统内的worker可能成为另一个子系统的Actor.原来大系统的Actor可能仍然是各子系统的Actor,就看它是否仍然与各子系统有直接的交互. 
可以看到,子系统的边界如何确定,会得到不同的用例模型的方案.这种不同的方案,正好体现建模者对不同架构价值的理解.真正需要讨论的是:这种对价值的定位是否清晰,是否与客户的理解一致.