精华内容
下载资源
问答
  • 1、在A业务用例下,有5个业务流程;在B业务用例下,有7个业务流程。其中,有4个业务流程是完全相同的。 请问,这四个相同的业务流程,是否可以归纳为"包含"(include)的业务用例?需要在业务用例图中表达出来吗? 2、...

    第五元素(50***16) 9:08:47
    经过仔细思考,原来的老问题还是没有想通。请潘老师指教:
    1、在A业务用例下,有5个业务流程;在B业务用例下,有7个业务流程。其中,有4个业务流程是完全相同的。
    请问,这四个相同的业务流程,是否可以归纳为"包含"(include)的业务用例?需要在业务用例图中表达出来吗?
    2、一个业务用例对应多个业务流程,最后用交互概览图来总括表达。那么同一个业务用例划分为多个业务流程的原则是什么?
    比如,A业务用例划分为A1、A2....等业务流程,用交互概览图"串"起来。那么在业务建模之初,使用一张业务序列图也可以表达,但是图非常大。现在将这个业务用例划分为由多个业务序列的原则是什么?
    谢谢。
    cheppinl(271***332) 20:21:40
    我试着理解你的问题:
    cheppinl(271***332) 20:29:00
    1. 什么是业务用例?
    业务用例是站在业务执行者的角度,系统能够提供给业务执行者,并且业务执行者可感知的价值。
    2. 什么是业务流程?
    业务流程是业务用例的实现,也就是说,组织是由系统(包括业务执行者和业务实体)组成的,业务流程是描述组织中的系统如何相互协作,完成业务用例需要提供给业务执行者的价值。
    3. 既然业务流程是业务用例的实现,怎么理解一个业务用例有多个业务流程来描述?这多个业务流程描述同一个业务用例的关系又如何?我理解是一个业务用例对应一个业务流程,只是这个业务流程中有过个路径而已。
    4. 分析业务用例的时候,最好不要纠结使用include/extend之类的东西,如实画出即可。我认为这两个东西不是分析的思路,而是设计的思路。
    5. 交互概述图一般是在描述系统用例的时候使用。
    cheppinl(271***332) 20:29:56
    更正一下:组织是由系统(包括业务工人和业务实体)组成的。
    cheppinl(271***332) 20:35:54
    @第五元素 你的A用例和B用例需要这么多流程来描述,能说出你业务用例的名称吗?是不是业务用例切分有问题?
    第五元素(50***16) 21:17:05
    @cheppinl 谢谢您的耐心解答。思想的传播真是一个神奇的过程,阅读是一回事,理解是一回事,应用是一回事。
    第五元素(50***16) 21:18:05
    希望多讨论,也许理解就会深入了。我把我的问题具体说说。
    第五元素(50***16) 21:25:21
    你的A用例和B用例需要这么多流程来描述,能说出你业务用例的名称吗?是不是业务用例切分有问题?
    ---------------------
    病人到医院看病,以医院为研究对象,组织对外提供的价值只有"看病"这个业务用例。那么,看病这个业务用例是由于多少业务流程构成的呢?比如,1、咨询台去咨询问诊。2、挂号去挂号。3、到专家门诊科室去看病。4、到窗口去划价。吧啦吧啦。。。
    这些都是由于"看病"这个业务用例触发组织内的业务序列图(业务流程)的。
    而把这些"串"起来的,是使用交互概略图。交互概览图,并不是用于描述系统用例,这在书上说明过的。
    第五元素(50***16) 21:27:51
    那么,这个时候,就不可避免的出现在A用例对应的5个流程和B用例对应的4个流程中出现交叉的情况。
    第五元素(50***16) 21:28:14
    应该说是相同的流程的情况。
    第五元素(50***16) 21:29:22
    我的问题现在再来理解,应该就比较容易了。
    -----------
    在A业务用例下,有5个业务流程;在B业务用例下,有7个业务流程。其中,有4个业务流程是完全相同的。
    请问,这四个相同的业务流程,是否可以归纳为"包含"(include)的业务用例?需要在业务用例图中表达出来吗?
    第五元素(50***16) 21:29:43
    2、一个业务用例对应多个业务流程,最后用交互概览图来总括表达。那么同一个业务用例划分为多个业务流程的原则是什么?比如,A业务用例划分为A1、A2....等业务流程,用交互概览图"串"起来。那么在业务建模之初,使用一张业务序列图也可以表达,但是图非常大。现在将这个业务用例划分为由多个业务序列的原则是什么?
    第五元素(50***16) 21:30:42
    这就是我所描述的问题,如果理解不对的地方,欢迎请批评指正。谢谢。
    cheppinl(271***332) 22:11:55
    你所说的"1、咨询台去咨询问诊。2、挂号去挂号。3、到专家门诊科室去看病。4、到窗口去划价"我理解为看病这个业务流程中的步骤,而不是业务流程。如果把这些理解成业务流程,那么怎么定义业务流程这个概念?
    cheppinl(271***332) 22:38:01
    我试着画了一下看病的业务流程,最简单的一种场景,的确流程挺长。对于这种情况,可以将例如"检查"作为子流程从这个途中抽取出去,作为一个应用导入进来。

    第五元素(50***16) 22:42:51
    对于"看病"这样的业务用例,是不是应该对应多个"步骤"?
    第五元素(50***16) 22:44:26
    所谓的"子流程",在业务用例和业务序列图中应如何表达?
    cheppinl(271***332) 22:47:59
    在这里要区分两个概念,一个是模型,一个是视图。模型是对依据问题对现实世界的简化和抽象,而视图是模型在某个视角上的投影。视图是给人看的,由于人脑处理能力有限,一张视图不能太复杂,可以分层、分区表达。所以看病这个流程是否要分多个"步骤"是视图层面的事,关键是放在一张图上是否太复杂。
    cheppinl(271***332) 22:49:46
    在EA里为子流程建立一个新的业务序列图,在总图里将它拖拽过来就可以。
    第五元素(50***16) 23:01:52
    嗯,如果这样,连交互概览图都不用了。
    第五元素(50***16) 23:04:33
    是这样的,在书上,有个"参加公开课"的业务用例,分为多个"步骤",最后通过交互概述图进行表达。这似乎与我们讨论的问题不太一样啊?
    UMLChina9(1493943028) 12:54:41
    @第五元素 不是用例。单独画成交互片段,拖到各个用例的序列图中
    UMLChina9(1493943028) 12:57:25
    2、发生频率不同
    UMLChina9(1493943028) 13:00:03

    UMLChina9(1493943028) 13:00:17
    这个顺下来的都属于一个业务流程
    UMLChina9(1493943028) 13:01:47
    其他业务流程是为了预防或应对这个主流程中的意外而存在的。
    UMLChina9(1493943028) 13:05:29

    http://mp.weixin.qq.com/s?__biz=MjM5NDI4MDE4MQ==&mid=2651031517&idx=1&sn=544918087602791cfcd7d3a39aac2f86&mpshare=1&scene=23&srcid=1023gI1CtqULInRqxUgCAGEB#rd
    UMLChina9(1493943028) 13:06:26
    有时觉得一个流程步骤多,拆成几张图来画,也可以,但不是必要的

    第五元素(50***16) 15:47:37
    嗯嗯,之前的有些概念没搞清楚,理了一下。再次把问题重述一下:
    我的一个用例对应的流程一拆分,成了十多个序列图(交互片段)。在绘制交互概览图时,就显得很复杂,可能会涉及判断、合并、分支等内容。如果分割粒度小,交互概览图就会很大。如果分割粒度大,就需要将判断、合并、分支等内容放入到业务序列图中。
    那么,将一个业务流程划分为多个业务序列(交互片段)的原则是什么?
    潘加宇(3504847) 18:55:35
    我上面应该回答了。你先做,贴具体的图问问题

    展开全文
  • 火龙果软件工程技术中心 本文内容包括:背景业务用例模型与系统用例模型有什么相似之处?业务用例模型与系统用例模型之间究竟有怎样的差别呢?我应该为业务建模使用哪些UML图?业务用例模型和系统用例模型之间的...
  • 业务用例建模举例

    2021-03-04 18:54:19
    一次和一个朋友聊起业务用例建模的目的,这个朋友讲了一个发工资的案例,希望看看业务用例建模在该案例中能够起到什么作用。朋友的案例是这样的:在某家几十人的小软件公司里,每当每月发完工资的时候,经常出现个别...
  • 用例模型包括业务用例模型和系统用例模型。这里从实际应用的角度简单阐释一下两者的概念。 简单而概括的讲,业务用例就是要完成的业务,系统用例是系统要做的事情,两者的域不同。 业务用例模型就是将客户的原来的...

    用例模型包括业务用例模型和系统用例模型。这里从实际应用的角度简单阐释一下两者的概念。

    简单而概括的讲,业务用例就是要完成的业务,系统用例是系统要做的事情,两者的域不同。

    业务用例模型就是将客户的原来的工作模式建模,而系统用例就是根据客户现在工作模式用计算机系统应该怎样完成而建立的系统模型。

    两者的域不同 
    业务建模,是对业务系统建模,不是简单地讲述信息系统所覆盖的业务、说明业务、告诉开发人员业务是怎么回事。而是暴露整个业务系统的问题和机会,以暴露的问题和机会来驱动信息系统的开发。 
    系统建模,是队信息系统建模,是接着业务建模发现的问题和机会,给出利用信息化手段的解决方案。

    转载于:https://www.cnblogs.com/ITEagle/archive/2011/07/28/2119238.html

    展开全文
  • 业务用例和系统用例

    千次阅读 2012-07-11 16:16:59
    业务用例和系统用例 业务用例与系统用例具有同样的特征,因此编写和评审用例的方法对两者都适用。在业务用例中说明的东西,也会在系统用例中说明。这形成了系统用例和用户用例之间的合作。但这样带来了两个坏消息。...

    业务用例和系统用例

    业务用例与系统用例具有同样的特征,因此编写和评审用例的方法对两者都适用。在业务用例中说明的东西,也会在系统用例中说明。这形成了系统用例和用户用例之间的合作。但这样带来了两个坏消息。

        第一个坏消息:编写者和读者经常把二者弄混,可能把系统行为放入业务用例中,也可能把业务操作归于系统用例。如果能够商量着去做将会有所帮助,但通常编写者和读者不会认识到这样做的重要性。使用系统用例的读者批评业务用例所处层次太高,但却没有认识到提供系统详细行为细节不是业务用例应该做的。业务用例编写者偶尔把系统行为细节写入其中,结果导致业务主管对这类有详细细节行为的文档失去了兴趣。

    为了减少这种混乱,应该经常在用例模板中写明用例范围及层次,让用例编写者依此规则编写,同时让读者了解这些规则。如果可以的话,尽量对用例使用图标。对两者使用稍微不同的模型和用完全不同的数字进行编号(如一组从1000开始对用例编号,另一组从1开始编号)。同时,编写一些可以直接使用和可视化的构件。这样就可以既能充分利用这种合作关系,又不会让人混淆。

    第二个坏消息:完全且正确地连接系统和用户用例不太值得。通常,业务用例编写者应对业务过程到系统使用(通常没有描述)进行描述。而在描述日常生活中客户如何使用新系统之前,用例编写者已经花光时间、财力、精力及热情。而系统用例编写者有时为了保持一致,会在业务过程中加一两句,但是他们通常不愿意重写一个包含新系统功能的业务用例。

    这样就在系统用例和业务用例之间形成了空隙,即系统用例和业务用例之间不一致。FirePondRusty Walters对此评论如下。

    在完整的业务用例展开为系统用例方面,我有一些成功的经验。根据我的经验,通常把业务用例分为3个层次:开始是少数几个黑盒、云朵级业务用例;然后很快转换为白盒、云朵级业务用例;最后展开为白盒、风筝级业务用例。

    然而,在此过程中,看不到业务用例和系统用例之间清晰的连接。

    在下面的论述中,FirePondRusty Walters阐述了他在业务过程用例方面的经验。

    ◆  Rusty  Walters:业务建模和系统需求

    受益于早先曾经阅读过你的书,我通过以前的试能够对问题合理规划,并且能利用新的知识。

    阅读前的经历:

    在阅读这本书之前,我从事过产品组中几个应用程序功能需求文档的编写工作。

    在一个应用程序开发中,我们编写各个层次的系统用例,包括概要级、用户级和子功能级。我们主要集中在系统功能方面。对建模后的结果也非常满意,它非常易于理解。同时,我们也觉得没有开发业务用例来展示整个环境的必要,系统概要用例就包括了我们全部的需求。

    在另一个应用程序开发中,虽然还是同样的开发组负责用例

    建模,情况却完全不同。回顾起来,我明白问题的症结在于,不同组的成员从不同角度接近系统。我从业务过程到技术进行建模,有的人却从技术到业务过程进行建模。毫无疑问,在两组设计人员中,每个用例的设计范围不清晰。

    在从业务过程到技术进行建模的组中,他们从不编写系统用例;而在从技术到业务过程进行建模的组中,他们也从不编写业务用例。相反,由于两组都希望直接利用对方编写的用例,因此难免正面冲突和相互指责。由于当时对界定用例范围层次没有远见并且缺少必要的理解,用例模型变得相当混乱。直到最后,整个小组对用例模型仍不满意。

    事实上,整个小组都知道这样有问题,但却不知道症结何在。

    阅读后的经验:

    正如我在一个试图理解和文档化开发过程的小组中发现的,从核心业务到技术进行建模似乎不会导致什么混乱。

         
          

    160

            我们一起讨论业务过程及其内部工作方式(不包括软、硬件系统)时,每一个人都很清楚。而混乱出现的区域确实与业务和部门的范围有关系。

    我们从业务中很概要级(云朵级)的黑盒用例开始,大家对这些用例都很清楚,甚至包括那些从事底层建模的人。然后,如书本中所说的一样,很快写出很概要级(云朵级)的白盒用例。

    我们决定讨论下一低层次用例时,设计域(即我们是讨论整个业务,还是某个部门)引发的混乱出现了。这个问题也与如何创建后续用例有关。在一个特殊的例子中,当我们认识到那些应该在调用用例中实现,而不应该作为当前用例的一部分后,删除了上面两个步骤。同时开发组也不打算把业务用例展开为系统用例需求。

    虽然在会议期间很难注意和修正整个过程,但会后,对问题域的理解相对容易一些。在文档化会议结果的过程中,我使用设计域语境图,用图标明每个用例的范围和层次。如果图足够简单,就会给读者留下深刻印象,并直接浮现在读者脑海中。


     

     

    本文节选自《编写有效用例》一书

    []AlistairCockburn(阿利斯泰尔.科伯恩

    王雷,张莉译

    图书详细信息:http://blog.csdn.net/broadview2006/article/details/7736848

     

    展开全文
  • 业务用例和系统用例的区别

    万次阅读 2019-03-04 17:26:47
    分清业务用例和系统用例,是做需求分析的第一步 用例 use case,或译使用案例、用况,是软件工程或系统工程中对系统如何反应外界请求的描述,是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个...

    分清业务用例和系统用例,是做需求分析的第一步

    用例 use case,或译使用案例用况,是软件工程系统工程中对系统如何反应外界请求的描述,是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景,该场景说明了系统是如何和最终用户或其它系统互动,也就是谁可以用系统做什么,从而获得一个明确的业务目标。

    业务用例:属于业务范围的概念。顾名思义,在具体用户所接触的真实业务中总结出来的例子,体现了需求,属于功能性需求,需要actor来实现的

    系统用例:属于系统范围的概念。也可理解为要实现某个业务用例的系统级实现

    系统用例并不是业务需求的细分

    最常见的例子就是档案管理,从业务用例来说,添加档案,修改档案,删除档案,对于系统用例。可能修改档案比较麻烦,就只是添加档案,删除档案就可以实现业务层面的功能性需求。

    比如点菜:在业务层面,点菜人员只需要点菜,或者是取消点菜,但是在需求用例中需要体现增加菜品,减少菜品,取消点单

     

     

    以下是百度结果:

    业务用例是用来捕获功能性需求的,功能性需求是由actor的业务目标来体现的。也就是对于actor来说,他所负责的业务需要由一系列的业务目标组成。比如一个档案管理员,他的业务目标就是维护档案。比如论坛管理员,他的业务目标有维护用户,维护帖子等..这些业务目标构成actor职责的全部。业务用例体现了需求。
    而需求的实现有多种方式。如何实现它,是由系统用例来体现的,它们并不是一个简单的细分关系,虽然看上去象。就说维护档案吧,这样一个业务目标,会有多种不同的用例场景去完成它,这些场景包括如何增加档案,如何修改档案,如何删除档案....对于系统用例来说,就是通过分析这些场景,来决定哪些场景中的哪些部分是要纳入系统建设范围的。比如维护档案业务用例中,假设由于某个原因,修改档案很困难,只能通过先删除,再全部重建的方式来实现,那么系统用例就增加档案,删除档案,而没有修改档案。
    业务用例和系统用例是分别站在客户的业务视角和系统建设视角来规划的。业务用例不是接近,而是完全的直接需求,系统用例也不是业务逻辑的详细划分,而是系统对需求的实现方式,但不是与程序设计无关,它只是说,要建设的系统功能性需求由这些系统用例构成。
    所以业务用例和系统用例都是需求范畴,它们分别代表了业务范围和系统范围。

     

     

    展开全文
  • 本文内容包括:进行一个业务用例模型调查进行业务用例说明业务用例的实现事件/动作与职责/活动之间的区别将注意力放在过程自动化上关注信息流程结论附录:业务建模简介就像大多数的软件开发从业者所知道的那样,统一...
  • 业务用例分析

    2018-04-11 21:38:00
    业务用例“科技创新平台用户注册”规约描述 ... 主要事件流: ...业务用例“科技创新平台填写信息”规约描述 参与者:填表的用户 主要事件流: 用户按要求输入平台的相关信息 系统将信息存进数据库...
  • 用例和业务用例

    2010-03-30 08:49:28
    RUP里有两个重要的概念,用例和业务用例。初识RUP人常常会问,到底什么是用例,用例和业务用例的区别是什么。以下简要说明一下用例,以及业务用例与用例之间的区别。 用例又叫系统用例,是一种软件需求定义的方法或...
  • 相关于业务用例的术语在RUP中有:业务用例业务用例实例,业务用例实现,业务角色,业务实体,具体业务用例,抽象业务用例,业务流程,业务参与者和业务执行者等等。除了搞需求方法论研究的人(比如笔者),谁还能...
  • 业务用例 专门用于需求阶段的业务模型 业务用例是针对客户业务的模型 也就是业务模型与计算机模型无关 它是业务领域的一个模型 业务范围不等于需求 软件需求真正的来源是系统范围 也就是系统模型 但是业务需求是...
  • 业务用例:财务--》修改--》收支明细 系统用例:(除管理员没有编辑权限)系统中如下操作 财务--》删除--》旧收支明细--》增加--》新收支明细 以上个人理解。 转载于:...
  • 业务用例模型

    2009-09-19 01:28:00
    业务用例模型 业务用例模型 描述一个业务的流程以及它们与外部各方(如客户和合作伙伴)之间的交互。 主题 解释 业务用例的不同类型 一个业务有多个业务用例 ...
  • 业务用例- 我们思考业务流程的出发点是从我们真实世界的业务运作着手。业务用例是一种从外部的视角来描述业务。更通常的情况是,一个业务用例就是一系列的行为和活动,而这些行为和活动将对特定的业务执行者带来价值...
  • 作者:张克强 作者微博:张克强-敏捷307 ...在《编写有效用例》中,业务用例被放在很次要的位置,前面提到云朵和风筝时,科伯恩并没有清晰的指出这是业务用例,相反的还是在系统范围内讨论用例。而且科
  • 业务用例与系统用例具有相同的特征,因此编写和评审用例的方法对两者都适用。在业务用例中说明的东西,也会在系统用例中说明。这形成了系统用例和用户用例之间的合作。但这样带来了两个坏消息。 第一:编写者和读者...
  • 转载于:https://www.cnblogs.com/huahua985/p/8598166.html
  • 设计验证的第一层是检验业务设计的质量。...业务用例整合了架构、功能、数据、管理等多层面的内容,业务用例是用数据、规则的细粒度写成的。业务用例也是后续应用用例、测试用例的输入,同时也是用户上线培训的教材。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 5,982
精华内容 2,392
关键字:

业务用例