和小贺的聊天记录,关于业务用例和系统用例的一些迷惑

原创 2004年09月12日 16:50:00

 AOL(嘿咻,嘿咻) says:
在不在吖?
小贺 [NAT..UML..WebService..] says:

 AOL(嘿咻,嘿咻) says:
碰到个问题. 是不是用例析上, 有业务用例和系统用例的区别?
小贺 [NAT..UML..WebService..] says:

 AOL(嘿咻,嘿咻) says:
哦, 我们用的分析方法, 是系统用例分析?
小贺 [NAT..UML..WebService..] says:
是啊,业务的用例是用来做业务需求的
 AOL(嘿咻,嘿咻) says:
比如说?
 AOL(嘿咻,嘿咻) says:
除了这两种还有没有其它的呢?
 AOL(嘿咻,嘿咻) says:
呵呵,今天问题比较多, 主要是自己在想一些用例的东东
小贺 [NAT..UML..WebService..] says:
比如整个业务流程,我们和各个合作者之间的关系

拿Ezhi来说,就涉及到协约用户和我们的一些关系,这些是做在整个系统设计之前的工作
 AOL(嘿咻,嘿咻) says:
原来.那我们再拿一个单机的马里奥游戏来说吧.根据系统用例分析, 我可以把游戏玩家做为一个Actor;但业务用例中, 我感觉游戏世界中是马里奥却是一个Actor
小贺 [NAT..UML..WebService..] says:
业务用例分析,在我们对整个商业系统的商业运作不清楚的时候是很有用的,也是用来确定我们要开发的系统在商业系统中的位置和作用
 AOL(嘿咻,嘿咻) says:
那就拿马里奥游戏来说,有几个问题:一,你觉得我那种观点正确吗? 二,一般情况下,是系统用例,还是业务用例? 三,假如是系统用例,有哪几个Actor;假如是业务用例,应该有哪几个Actor?
 AOL(嘿咻,嘿咻) says:
我感觉你的看法是,在做软件的时候用系统分析,而业务分析是个辅助
小贺 [NAT..UML..WebService..] says:
是的,就我的理解,在业务建模时候,我们要设计的系统有时候都会成为一个Actor,一般的用例分析,全部都是系统用例分析,业务用例分析和系统用例分析的图形表示都是有所区别的,UML中,所有的业务符号,都是带一个“/”的
 AOL(嘿咻,嘿咻) says:
这个我知道
小贺 [NAT..UML..WebService..] says:
Bussiness Use Case Diagram,不是分析的一个必要步骤,是需要的时候才进行的,而其中的Actor,不能直接移用到Use Case Diagram中来,这中间有很多要注意的细节
 AOL(嘿咻,嘿咻) says:
还是用马里奥游戏来说吧,我只想到几个Actor,一个玩家,一个时间(时间到了马里奥就会挂掉),一个是游戏(可以生成NPC,记血,记分)
 AOL(嘿咻,嘿咻) says:
你觉得应该怎么分呢? 我觉得实例来说,我理解会更好点儿
 AOL(嘿咻,嘿咻) says:
现在都在找有没有这样的书, 很多实例的.
小贺 [NAT..UML..WebService..] says:
首先,我觉得这个游戏不是一个典型的分析例子,作为一个游戏系统,他始终没有跟我们的投资商挂钩,没有跟业务挂钩,只能停留在系统分析上
 AOL(嘿咻,嘿咻) says:
我就是说从系统分析上,怎么分呢?

 AOL(嘿咻,嘿咻) says:
这种外界参与的人不是很多的情况下,事实上玩游戏的时候,系统假如可以自己维护的话.人只剩下玩家一个了.
小贺 [NAT..UML..WebService..] says:
如果就是一个单机游戏的话,那就只有 Player 一个了
 AOL(嘿咻,嘿咻) says:
对呀,那就没达到目的了.
 AOL(嘿咻,嘿咻) says:
那怎么分析下去?
小贺 [NAT..UML..WebService..] says:
你所说的目的是什么呢?
 AOL(嘿咻,嘿咻) says:
就是能分析出它的模型啊
小贺 [NAT..UML..WebService..] says:
执行着是只有一个啊,但是对象有很多啊,游戏中的角色马里奥不是一个执行者,但是他是一个最典型的对象啊
 AOL(嘿咻,嘿咻) says:
游戏世界里的动作,可不可以看作是业务?
 AOL(嘿咻,嘿咻) says:
这时候马里奥是可以作为一个执行者的.
小贺 [NAT..UML..WebService..] says:
如果理解了 Bussiness ,你就应该会明白 “业务” 的意思
 AOL(嘿咻,嘿咻) says:
我觉得不是这样理解的.
 AOL(嘿咻,嘿咻) says:
Bussioness,这个英文单词不是很好.
 AOL(嘿咻,嘿咻) says:
它偏向商业
小贺 [NAT..UML..WebService..] says:
那说说你的理解
 AOL(嘿咻,嘿咻) says:
我拿一个例子来说吧.
 AOL(嘿咻,嘿咻) says:
就那个订单的吧.
 AOL(嘿咻,嘿咻) says:
假如做系统用例的话, 软件的用户是一个Actor,它可以派生出客户,客户代表,还有其它的用这个软件的人
 AOL(嘿咻,嘿咻) says:
或系统
 AOL(嘿咻,嘿咻) says:
做业务用例分析的话,他们之上就没有软件用户这个Actor。
 AOL(嘿咻,嘿咻) says:
我觉得系统用例分析的系统范围比业务用例分析的系统范围要大一层.
 AOL(嘿咻,嘿咻) says:
订单的那个例子,业务用例更实际点儿,而且软件做是的模拟/辅助这个业务.
小贺 [NAT..UML..WebService..] says:
业务当然不只有关商务,但是业务所描叙的,是作为一个庞大的系统,所有的相关者都要纳入分析范畴的,它是要描叙,我们所要做的事情,是怎样的一个逻辑,而系统用例分析,只针对我们要开发的系统,作为一个配合者,怎样来提高这个事情的效率
 AOL(嘿咻,嘿咻) says:
这个道理我知道.
 AOL(嘿咻,嘿咻) says:
马里奥游戏,我也只能划出玩家这个Actor,最多也就多了一个时间的Actor.
小贺 [NAT..UML..WebService..] says:
那这一句如何理解:“我觉得系统用例分析的系统范围比业务用例分析的系统范围要大一层.”
 AOL(嘿咻,嘿咻) says:
但光有这两个Actor,再做用例,Actor可以有很多用例的.应该有所细分. 
小贺 [NAT..UML..WebService..] says:
我理解,你是觉得Actor少了,想把 马里奥作为一个 Actor,来进行分析
 AOL(嘿咻,嘿咻) says:
这是我说的我觉得系统用例分析的系统范围比业务用例分析的系统范围要大一层的原因.
 AOL(嘿咻,嘿咻) says:
游戏世界里完成的东西,更像一个业务
小贺 [NAT..UML..WebService..] says:
如果你这个游戏只是开发给自己玩,那么系统也就等同于业务了,没有建立业务的意义
 AOL(嘿咻,嘿咻) says:
假如把它看成一个业务的话,那就可以把马里奥做为一个Actor了
小贺 [NAT..UML..WebService..] says:
不论如何,马里奥都不是一个Actor
 AOL(嘿咻,嘿咻) says:
倒, 你始终认为业务的执行者是现实世界的人
小贺 [NAT..UML..WebService..] says:
不是,这样理解是错误的
 AOL(嘿咻,嘿咻) says:
照你这么说的话,那就是一个player了. 我觉得这很不科学
 AOL(嘿咻,嘿咻) says:
这么说吧.
 AOL(嘿咻,嘿咻) says:
我拿这两个做类比
小贺 [NAT..UML..WebService..] says:
可以是一个人,可以是一个子系统,在业务建模中,马里奥游戏系统,是一个执行着
 AOL(嘿咻,嘿咻) says:
那你说说假如要业务建模,你认为这个马里奥游戏有什么Actor呢?
小贺 [NAT..UML..WebService..] says:
游戏代理商、游戏玩家、游戏商家(也就是开发者)、游戏系统、等等
 AOL(嘿咻,嘿咻) says:
马里奥游戏系统是否可以再细分?怎么细分呢?
 AOL(嘿咻,嘿咻) says:
 我明白你的意思,或许是我理解错误,因为我没看过这种书. 但我的感觉,不应该是这样.假如这样的话,意义不是很大
小贺 [NAT..UML..WebService..] says:
可以细分啊,作为一个对象,象 马里奥 这个游戏角色(不是执行着Actor),就是一个对象啊,我们的Actor:Player,如果能够操作 马里奥 跳,那么这个对象就应该具有跳的功能,如此等等
 AOL(嘿咻,嘿咻) says:
那这个对象所具有的方法,是什么时候分析呢?
 AOL(嘿咻,嘿咻) says:
而且这里的对象有可能是很多的,他们之间也有一些继承,关联什么的关系.那又怎么去分析呢?
小贺 [NAT..UML..WebService..] says:
在顺序图中就会有描叙的,我们的Player以 Actor小人的形式出现在顶端、我们的 马里奥 以 Object 的形式出现在 顶端
 AOL(嘿咻,嘿咻) says:
我来说一下, 这里有可能用到的对象吧.马里奥,敌人(可以派生为恶蘑菇,乌龟,飞行物),静态的东西(地图,青藤等),还有记分子系统,记血子系统,还有一些其它的,我没有看到的.那怎么来表现它们的关系呢?
小贺 [NAT..UML..WebService..] says:
我明白你冲突的地方了,就假如一个《金山游侠》的网络游戏,他的游戏世界本身就模拟了真实的世界,这个时候,仅仅有游戏这个玩家,肯定是不好分析的,当然,这个时候,如果只针对于这个游戏系统,不涉及到人的主动性,你就可以变通的来把其中的对象转换成执行者,因为人在这个系统中,本来就扮演了一个游戏角色,呵呵,我这样说不知道是否正确,但是我觉得这也是一种解决方案
 AOL(嘿咻,嘿咻) says:
这么大一个东西以顺序图的方法的话,那就面向过程了.
 AOL(嘿咻,嘿咻) says:
我就的就是这个
小贺 [NAT..UML..WebService..] says:
呵呵,如果有一个UML的考题,就可以出“RPG游戏”的用例分析了
 AOL(嘿咻,嘿咻) says:
至始至终,系统用例的方法,看的资料中,都与电脑,与电脑的用户有关.也许这些东西对我有些误导吧
 AOL(嘿咻,嘿咻) says:
或许我们对这个游戏系统的分析,就是一个系统用例分析
小贺 [NAT..UML..WebService..] says:
当然是一个系统用例分析,但是一定要明白 业务建模 的概念 和 系统建模 概念是有所区别的
 AOL(嘿咻,嘿咻) says:
这个知道  有些东西误导我了, 我应该去看一下业务用例.这样就可以分出两者的区别了. 
小贺 [NAT..UML..WebService..] says:
呵呵,+U!
 AOL(嘿咻,嘿咻) says:
呵呵, 谢谢. 我先试一下, 用马里奥做为一个Actor的用例分析吧. 88 
小贺 [NAT..UML..WebService..] says:
好的,88

需求分析阶段的工作(一):业务用例和系统用例

在这里要申明的是逻辑模型并不能完全算需求分析阶段的工作,因为它包含了设计模型的概念,但是我又把它归纳了一块到需求分析阶段,原因在于逻辑模型中存在了业务对象模型和分析模型的概念。 言归正传,先来看...
  • vampirem
  • vampirem
  • 2014-04-09 16:07:28
  • 1386

业务用例向系统用例转换方法的一个讨论

最近收到一封网友来信,询问关于业务用例向系统用例转换的问题。觉得这个问题比较有意义,涉及到了业务用例向系统用例转换的策略以及评判方法,特发表上来,并感谢rainyhuang网友:  rainyhuan...
  • coffeewoo
  • coffeewoo
  • 2009-12-22 14:28:00
  • 7298

业务用例和系统用例

"业务用例:业务过程是描述这个业务的具体工作流的;一次涉众与实现业务目标的业务之间的交互。它可能包含手工和自动化的过程,也可能发生在一个长期的时间段中。"  系统用例的设计范围就是这个计算机系统设计的...
  • thunder09
  • thunder09
  • 2010-08-17 14:56:00
  • 9746

【转】使用 UML 进行业务建模:理解业务用例与系统用例的相似和不同之处

使用 UML 进行业务建模:理解业务用例与系统用例的相似和不同之处   作者:Arthur V. English 出处:IBM   ...
  • itsgoodtobebad
  • itsgoodtobebad
  • 2012-07-29 09:01:34
  • 2377

业务用例, 业务用例场景与业务用例实现之间的关系

简单说, 所谓的业务用例场景即为了实现业务用例所采取的不同的实现方式或做法, 因此一个业务用例才有多个业务用例场景的出现。而业务用例场景和业务用例实现的关系通常为一个业务用例场景对应一个业务用例实现。...
  • gaoxueyi551
  • gaoxueyi551
  • 2015-02-07 15:12:39
  • 1997

物流配送<em>系统用例</em>文档

整个结构设计的很好,但是<em>用例</em>编写的不够详细,缺少异常、<em>业务</em>规则等等。基于物流配送...取  消 提  交 物流配送<em>系统用例</em>文档 3积分 立即下载 ...
  • 2018年04月15日 00:00

点名<em>系统用例</em>图及<em>用例</em>规约

<em>业务</em>规则 本<em>用例</em>所有用户都可以进入待解决问题由于第一次设计点名系统,很多细节还...取  消 提  交 点名<em>系统用例</em>图及<em>用例</em>规约 5积分 立即下载 ...
  • 2018年04月14日 00:00

业务流程&系统用例

前言 老大说要做一个什么系统或者功能,找到相关业务流程在确定需求开发一个和什么企业或者场景相关的软件系统之后,首先要了解,和系统相关的业务流程。怎样判断哪些流程是和我们将要做的系统相关?首先要到我们所...
  • ZiLongO
  • ZiLongO
  • 2016-11-22 23:28:40
  • 787

《Thinking in UML》学习1——参与者与用例

一、参与者(actor) 1、参与者的定义         参与者的定义:actor是在系统之外与系统交互的某人或某事物。它在建模过程中处于核心地位。        注意:在参与者存在的场景中,系...
  • xiaoxiaoyusheng2012
  • xiaoxiaoyusheng2012
  • 2015-05-23 20:23:55
  • 1346

用例图——如何描述用例

1 用例模板 1 用例名 2 迭代 3 综述 4前置条件 5 触发器 6 基本事件流 7 备选路径 8 后置条件 9 业务规则 10 注释 11 作者与日期...
  • ZZh1301051836
  • ZZh1301051836
  • 2017-05-11 19:57:15
  • 7603
收藏助手
不良信息举报
您举报文章:和小贺的聊天记录,关于业务用例和系统用例的一些迷惑
举报原因:
原因补充:

(最多只允许输入30个字)