业务用例与系统用例的关系

《业务用例与系统用例的关系》由会员分享，可在线阅读，更多相关《业务用例与系统用例的关系（23页珍藏版）》请在装配图网上搜索。

1、使用UML进行业务建模：理解业务用例与系统用例的相似和不同之处 背景 业务用例模型与系统用例模型有什么相似之处？ 业务用例模型与系统用例模型之间究竟有怎样的差别呢？ 我应该为业务建模使用哪些UML图？ 业务用例模型和系统用例模型之间的关系是什么？ 总结 注释 现在对本文进行讨论！参考资料本文来自于Rational Edge：学习有关业务用例与系统用例相似和不同之处的知识，包括应该使用什么样 的UML图，通过IBM Rational Software Architect或者其它建模工具来建模这些用例。绝大多数构架师都认为业务建模是开发软件解决方案中到一个非常重要的活动。成功的解决方案会支持 这个

2、业务，它们能够解决业务问题并确保业务目标的实现。当开发一个合理的业务模型以后，业务流程分析员能够探究不同业务改进的选项，比如取消多余的任务， 使重复且平凡的任务或者容易出现的错误实现自动化操作。IBM Rational Unified Process，或者RUP， 以及Unisys 3D Visual Enterprise，或者3D-VE，或者3D-VE,提供了一个系统化的方法，利用统一建 模语言(UML)可以直观地表现业务模型，同时还可以派生出一个一致的且能够追溯到这个业务模型的起点 系统用例模型。这篇文章提供了 RUP业务建模的概述，并解决了以下的问题： 业务用例模型与系统用例模型有怎样的

3、相似之处？ 业务用例模型与系统用例模型有什么不同之处？ 构建业务模型应该使用哪个 UML 图？ 业务用例模型与系统用例模型之间有什么关系？背景在谈论这个问题之前，我想解释一下为什么要挑选这个特殊的话题来写。自从1990年我就作为一名软 件构架师从事系统用例的工作。当我是一名由Unisys Global Public Sector开发的Integrated Justice Information Sharing (IJIS)框架解决方案的总构架师时，还没有接触到业务用例，直到2002年。IJIS现 在巳经发展成为 Unisys Information Sharing Management Fra

4、mework (ISM)。ISM是一套支持信息共享的总体业务过程的可重用的组件。ISM Framework利用Service Oriented Architecture (SOA)技术整合了不同类型的司法与公共安全系统，从而在关键决定点时分配关键的数据， 文档以及图片ISM解决方案将为司法与公共安全团体提供了一个业务框架、技术框架、基础应用软件以 及方法，使政府机构能够继续使用他们的遗留系统。ISM是使用RUP进行设计的，ISM业务模型是为ISM项目开发的首批工件之一。开发ISM业务模型 对我来说是一个有意义的学习经历：我认识到的一个问题是，对于如何开发一个业务模型有很多含混不清 的地方，为开

5、发UML业务模型提供指导的文献相对比较少，而且有些不一致。自从我离开Unisys Global Public Sector加入到Unisys University作为一名培训和开发顾问后， 就一直负责开发和交付软件构架和IBM Rational工具培训。我的职责之一就是IBM Rational课程 Mastering Requirements Management with Use Cases (MRMUC)的教学。这门课程主要阐述的是开发系 统用例，但是这门课程仅仅提供了什么是业务模型以及它如何与这个系统用例模型相联系的一个很有限的 讨论。因此这篇文章的目的之一就是为MRMUC课程补充材料。

6、这篇文章假定您巳经有了系统用例建模和RUP需求规程的基本知识。如果您对系统用例建模并不熟悉， 我建议您学习RUP需求规程的知识。正如前面提到的，这篇文献关于业务建模的内容比较少，但是我们发现了一些非常有用的参考资料，远 远多于您在RUP中找到的信息： Writing Effective Use Cases由Alistair Cockburn编著。这是我最喜欢的关于业务和系统 用例说明的著作。Alistair强调一个业务或者系统用例模型最重要的部分是用例说明。这本书强 调的就是用例说明，而不是UML。 UML for the IT Business Analyst 由 Howard Podesw

7、a 编写。本书主要强调的是利用 UML 来 开发一个业务模型，以及对Alistair的书进行补充。UML for the IT Business Analyst助 我完成了关于如何开发一个有效的业务用例模型的课程培训。 Rational Edge 中的文章Effective Business Modeling with UML: Describing Business Use Cases and Realizations”，由Pan-Wei Ng编写。那篇文章与这篇文章有些类似。那篇文章是 从UML 1.x的角度来编写的。而这篇文章是从一个UML 2.0的角度来编写的，并且阐述了业务 用例模型

8、，业务分析模型，以及系统用例模型之间更深刻的关系。既然我巳经完成了预备工作，就让我们开始提一些问题。业务用例模型与系统用例模型有什么相似之处？业务用例模型与系统用例模型有很多相似之处。两个模型都有用例说明。如果您对业务用例模型以及系 统用例模型的RUP模版进行检查，您会发现它们的格式十分相似。两者都包含先决条件、后置条件、扩展 点以及特殊需求。业务用例说明有基本的工作流和可选择的工作流，从而取代了基本的事件流和可选流。业务用例说明与系统用例说明的格式十分相似，但是在设计范围上有些分歧。业务用例的设计范围是业 务操作。它是这个组织外部的业务参与者，实现与业务组织相关的业务目标。让我们查看这个业务

9、用例的 RUP 定义：业务用例从一个外部的，增加值的角度来描述一个业务过程。为了给这个业务的涉众创造价值，业务用 例是超越组织边界的业务过程，很可能包括合作伙伴和供应商。简单地说，这个定义标识了一些重要点，比如: 一个业务用例描述的是业务过程一一而不是软件系统过程。一个业务用例为涉众创造价值。这些涉众要么是业务参与者要么是业务工作者。一个业务用例可以超越组织的边界。有些构架师对于这一点有非常严密的态度。许多业务用例确 实超越来组织的边界，但是有些业务用例仅仅关注于一个组织。我稍后将在这篇中给出一些例子。让我们也看看Podeswa的书UML for the IT Business Analyst

10、中对业务用例的定义:”业务用例：业务过程是描述这个业务的具体工作流的；一次涉众与实现业务目标的业务之间的交互。它可 能包含手工和自动化的过程，也可能发生在一个长期的时间段中。这个定义表明了通过实现业务目标创造价值的观点。它通过把一个业务过程描述成一个可能包含手工和 自动化过程的具体工作流来详述RUP的定义。这个定义还指出，工作流可能发生在一个长期时间段中。所 有的这些都十分的重要。那么系统用例又是怎样的呢？系统用例的设计范围就是这个计算机系统设计的范围。它是一个系统参与 者，与计算机系统一起实现一个目标。系统用例就是参与者如何与计算机技术相联系，而不是业务过程。Cockburn的Writing

11、 Effective Use Case给业务和系统用例使用了相同的用例说明模版。业务用例 与系统用例说明使用这个模版的区别是设计范围，而不是模版Cockburn想通过目标层次对用例进行分类， 如表格1所示。图1： Alistair Cockburn对业务和系统用例的分类高层概要 概要 用户目标 子功能 最低层Cockburn编写Writing Effective Use Case的最初目标是系统用例，但他在业务用例上也花了很多 精力。他利用目标层次来区分业务与系统用例，而不是使用不同的模版类型。那么这些图标和目标层次又 意味着什么呢？这些图标本身代表着一个简单的系统，它是根据用例与“海平面”（

12、用户的实际层次）的相对高低来确 定的。系统用例的最佳点是用户目标，通过海平面图标来表明。有时候需要将复杂的系统用例分解成其它 有子功能目标、通过鱼图标表明的用例。但是您应该尽量避免将海平面系统用例分解成蛤或者最低层系统 用例。也许您会猜测到，概要或者蛤用例应该是业务用例。云或者高层概要也可能是业务用例。Cockburn的方法是将这些用例看作是一个光谱，从一个组织的最高层次业务目标，到为实现这些业务 目标而执行的软件解决方案的需求详细资料。这种方法将系统用例看作是一个业务用例的分解。这个用例 分解方法可以用来帮助您从这个业务模型驱动系统用例模型，我稍后会对这个问题进行讨论。那么业务用例模型与系统

13、用例模型图有什么其他相似之处呢？ 两者都有参与者。在业务用例图中，您将一个参与者原型化为。 两者都有用例。在业务用例模型中，您将一个用例原型化为。 在参与者与用例之间两者都有一个通信关联。 业务用例和系统用例都能够包含、扩展，以及一般化关联。用例图中的通信关联对于学习用例建模的人们来说，通常是一个容易混淆的地方。我应该使用箭头吗？ 这个箭头应该指向什么方向呢？通信关联巳经被描绘出来，因为1.4 UML规范是一条实线。这条线可以配 上一个箭头。这条线和箭头代表角色与系统之间的双方对话。如果呈现出一个箭头，那么说明只有这个关 联末尾的“这个事物”能够发起通信。没有箭头的表明任何一方都可以发起通信(

14、而不是两端都发起通信)。UML 2.0规范使它更简单。UML 2.0不允许角色与用例之间或者业务角色与业务用例之间存在这种可灵 活操作的关联。我个人比较喜欢箭头，但是如果您把IBM Rational Software Architect (RSA)当作您的 UML建模工具，您就不能在角色和用例之间描绘出一个箭头。此时的RSA是完全没有错的。UML 2.0是 通信关联不可灵活操作的原因。既然我们巳经讨论了业务用例模型和系统用例模型之间的相似之处，下面我们就看看它们的不同点。业务用例模型与系统用例模型之间究竟有怎样的差别呢？业务用例模型与系统用例模型之间主要有三点重大不同之处：设计范围、白盒测试与

15、黑盒测试，以及业 务操作者。范围在前面的部分中，我借助Alistair Cockburn的处于“水平线”上面、下面，或正好处于“水平线” 的规定对设计范围进行了讨论。业务用例着重于业务操作。它们表示实现业务目标的业务中的具体工作流。业务过程可能涉及手工和自 动过程，并且在一段长期的时间内进行。系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互？我们在系统用例说明中书写的事 件流应该足够详细，从而用作编写系统测试脚本的出发点。白盒与黑盒业务用例常常是以白盒形式编写的。它们描述了被建模的组织中的人和部门之间的交互。我们使用业务 用例来说明在“现有”业务模型中组织如何工作。然后我们重构“现

16、有”的业务用例模型，让其面向将要 建模的组织的未来设计。我们需要创建什么新角色和部门来提供更多价值，或者消除业务问题？什么角色 和部门需要消失？系统用例几乎总是以黑盒形式编写的。它们描述了软件系统之外的参与者如何与将被设计的系统进行交 互。系统用例详细阐明了系统需求。系统用例模型的目的是从涉众的角度说明需求，而不是设计如何满足 需求。业务角色那么业务角色是什么？在系统用例图中，您只让参与者与用例进行交互。但在业务用例图中，您可以让 业务参与者和业务角色与业务用例进行交互。业务参与者是业务之外的人。它可以是一个角色或其他组织实体。例如，在刑事审判系统中，业务参与 者可以是证人、嫌疑犯、外部的政府

17、机构，例如健康服务，或业务实体，例如，业务资信咨询机构。业务角色是业务内部的某个人或某个部门。在刑事审判系统中，业务角色可以是治安人员、法官、检察 官，或假释官。当您实现了一个业务用例，并且创建了时序图和/或通信图来显示业务参与者、业务角色， 和业务实体如何协作执行业务用例时，您将会把业务角色从业务用例模型转入业务分析模型，并且加入所 需的额外业务角色来提供业务用例功能。图1显示了基于ISM项目的示例业务用例图。55 worker* 宙 Cou-rtRequest warrantSusre55Vnrker*簿 Law Enforcament皿蛔皱wk印塑 ProsecutorArrest Su

18、bjectCaptureSuspect图1： ISM业务用例图图1显示了一个业务参与者：嫌疑犯(Suspect)。有三个业务角色：执法人(Law Enforcement)、 检察官(Prosecutor)和法院(Court)。有四个业务用例：逮捕被告(Arrest Subject)、请求担保(Request Warrant)、获得指纹和嫌疑犯照片(Capture Fingerprints and Mugshot)，以及保释(Release on Bail)。 获取指纹和嫌疑犯照片总是作为来自逮捕被告基础业务用例的强制行为。保释是继承逮捕被告业务用例的 可选行为。早先，我讨论了业务用例如何跨越组

19、织边界，许多情况都是这样的。请求担保就是一个好例子。它涉及 执法人和法院。业务用例还可以只集中在一个组织上。获得指纹和嫌疑犯照片就是这样一个好例子。我应该为业务建模使用哪些UML图?在我讨论您在业务建模中使用的UML图之前，我想说一些关于使用RSA和UML 2.0创建业务用例图 的提示： 在UML 1.x中，您可以将参与者原型化为业务角色。在UML 2.0中，您必须创建一个类，然后 将其原型化为业务角色。在UML 2.0中，您可以将参与者原型化为业务参与者，但您不能将参与 者原型化为业务角色。 在UML 2.0中，业务用例和业务角色之间的关联是可导航的。业务参与者和业务用例之间的关联 是不可导

20、航的。 作为最佳实践，我推荐断开业务用例和业务角色之间的导航，从而保持业务角色与业务参与者的 一致。业务角色及其用例关联应该按照业务参与者与业务用例通信的同样方式来绘制。 您必须在您的工程的Properties标签页中选择Profiles选项卡，然后单击Add Profile按 钮，来向您的工程中添加业务建模和健壮性分析原型。在IBM Rational Rose中，这是自动包含 的。在UML 2.0中，概要文件用于包装原型和标记值UML扩展。UML 2.0规范要求您向UML建 模工程中添加概要文件来使用业务建模原型。UML业务模型包括两个模型：用例视图(Use-Case View)中的业务用例

21、模型和逻辑视图(Logical View) 中的业务分析模型。1业务用例模型中的主图是业务用例图。您还可以随意加入表示单个业务用例的UML 活动图，来图形化地显示工作流过程，如图2所示，逮捕被告业务用例的活动图。图2： ISM逮捕被告业务用例活动图业务分析模型描述了通过业务角色和业务实体的交互来实现业务用例。它用作业务角色和业务实体需要如 何相关联，以及它们需要如何协作，来执行业务用例的抽象。业务分析模型中有三种类型的UML图，如图 3 所示：类(Class)、时序(Sequence)和通信(Communication)图。(ZZI (ZZ1 CZI (ZZIClass diagr-an sS

22、equent d aramsComiTijn ication di3-gam&RSAcpabii ly图3：业务分析模型图业务分析模型中的主要的图是时序图。您手工地创建显示出业务参与者、业务角色，和业务实体如何交 互执行业务用例的时序图。时序图显示出以时间时序安排的对象交互。特别是，它显示出参与交互的对象， 以及消息交换的顺序。通信图是以前在UML1.x中所称的协作图(Collaboration diagram)，它描述了对象之间交互的模式， 通过对象间的链接和发送给对方的消息来展示参与交互的对象。通信图和时序图都显示出交互，但它们强 调了不同的方面。时序图清楚地显示出时间顺序，但没有明确地显

23、示出对象关系。通信图清楚地显示出对 象关系，但必须从顺序号那儿获得时间顺序。两个图都显示出同样的行为，但方式不同。我个人喜欢时序图，因为它通常比较容易读懂。您还可以使 用参与类的视图(View of Participating Classes，VOPC)来显示协作执行业务用例的业务参与者、业务 角色和业务实体的静态视图。图4显示出ISM逮捕被告业务用例实现的时序图。图5显示出ISM逮捕被告业务用例实现的VOPC。 图6显示出ISM逮捕被告业务用例实现的通信图。图4： ISM逮捕被告业务用例实现的时序图在ISM逮捕被告业务时序图这部分中，如图4所示，有三个从业务用例模型转入的业务角色：执法人、

24、签署者(Subscriber)和刑事审判系统。刑事审判系统是执法人、法院、检察官，等等的一般化。为了让 时序图简单化，我们使用该泛化来表示ISM可以使用的任意刑事审判系统。图4还显示出引入到业务分析模型中的两个新的业务角色：档案管理系统(Records Management System， RMS)和 ISM Broker。RMS 通常是商业化成品(commercial off-the-shelf， COTS)解决方案， 它将地方的执法用作刑事案件管理系统。ISM Broker是Unisys计划开发的软件解决方案的自动化候选者 或代理。Unisys ISM解决方案利用中心辐射型SOA技术整合了

25、多个各种各样的司法系统，从而在重要决策点处， 分享关键任务的数据、文档、图像和事务。ISM可以在Microsoft BizTalk Server或IBM WebSphere Business Integration上实现。ISM Broker作为在审判团之中数据共享的导管，并且利用当前的技术来 推、拉、发布和订阅信息，从而支持日常的审判操作。uBusressWurl keturn ReLilts fl S Kecord Arrest Dsipostion )& ConfiriTiation ()BusinessWarl-r I JIS Brclsr Query 仍Infbiirijtion (

26、J Search Master Name Index () Transmit Incident Report ()9 Update Master Name Index ()、；Locate Subscribers )、;Find Subscribers (:Transmit Arrest Ciispostion () 心 keceive Confirmation () Business WQiier* Subscribei(i： Business Worksr * Criminal Justice System# R.ecieve Notifications () Receive Incide

27、nt Report ()图5： ISM逮捕被告业务用例实现的VOPC图图5中的VOPC图显示了参与逮捕被告业务用例的业务参与者、业务角色和业务实体的静态视图。注意为 每个业务角色显示的操作。这些操作被称为业务职责。VOPC图的更精确的名称是参与的业务参与者、业务 角色和业务实体的视图(View of Participating Business Actors,、Business Workers 和 Business Entities)。在本实例中，只有业务角色协作执行业务用例。11.1.1; Ci eate? Incident. Rjyfxxt:Rh-feiL-fl8 En-faicerTie

28、ritI1. i. 1； CyrifrmafttorLLLkMm； conhiiwtiofl1,1.1,1.1: Ti irtatiil IrKklerirt Repot t1,1.1：IJK Brd：i1： (Jjrfny fix InfrrmjtiDn1,1.1.12.1: Tierwiil AJIWt DtUXBlKinl.LL 1.2.12： FhtFSctstas1.Lt. 1.2.1.1; Ltdate wastei Nciiw Drufei1.1.1.2.1 FixJ Sdikiiwili.i.iia.L；r+aneijndra1. L：豹Jir-h MKt rtTTie JjT

29、dtiNl.L.i.1.1 1: Rerme ConfiiirnEni.i.L.1.1.1: PcieveMonfkatvnfi1lL.1.1_?.L.!2.1: Retievs hJrjtifir.atKxre1.1.Ill： Rw.iih*? IhCkFiflU;9ubicribei:Intg 乐 5虎m图6： ISM逮捕被告业务用例实现的通信图如前面所提到的，通信图(如图6所示)是观察时序图中所示行为的另一种方法。RSA提供了从时序 图创建通信图的自动能力，反之亦然。还有一个要回答的问题。业务用例模型和系统用例模型之间的关系是什么？图7，业务用例到系统用例的向下流动(Business t

30、o System Use-Case Flow Down)，出自我所教授 的 IBM Rational 课程“ Mastering Requirements Management with Use Cases”。Bus nessOtjct 帕涵IAnalysisiiods-1Use-Case nade I step 2d&lUse-Case nade I step 1图7,业务用例到系统用例的向下流动图7例举了课程中最难教授的主题之一，因为您要理解该图所需的大部分基础不在标准课程材料之内。 本文的其中一个目的是提供额外的基础。图7显示了业务模型中所找到的东西和系统用例模型中的东西之间的清晰映射。

31、在此特殊的实例中， 可以看出，系统能够将业务角色的职责自动化。它还显示出关键的业务角色是自动化的候选者。记住，业务模型包含业务用例模型和业务分析模型。业务分析模型是业务用例模型的实现，并且拥有紧 密的集成化和可追溯性。系统用例模型可以追溯到业务分析模型。业务分析模型可以追溯到业务用例模型。使用该方法，您可以构建从业务分析模型演化来的系统用例模型。这向您的整个UML模型提供了一致 性和可追溯性。那么系统参与者和系统用例从那里来的呢？系统参与者是根据业务分析模型中的业务参与者和业务角 色而生成的。与业务角色自动化候选者交互的业务参与者总是成为系统参与者。不是自动化候选者的，与 业务角色自动化候选者

32、交互的业务角色成为系统参与者。例如，ISM业务分析模型中的执法人和法院成为 了系统参与者ISM Broker是“纯”自动化候选者。它不会成为系统参与者。我所谓的纯是什么意思呢？简单的说，自动化候选者的唯一目的就是成为我们正在开发的软件解决方案 的代理。注意到图7中的Loan Specialist。Loan Specialist业务角色转换为系统参与者和系统用例。 让我来解释一下。Loan Specialist是图7中所示的业务模型中的角色。在我们的系统用例模型中，需要有作为Loan Specialist角色的参与者。但是，在我们正在开发的新的软件解决方案中将Loan Specialist的一些

33、业 务职责自动化了。业务分析模型中的那些业务职责成为了系统用例模型中的系统用例。其他的纯业务角色自动化候选者将不会转换为系统用例模型中的系统角色。这回答了问题，“系统用例 是从哪里来的？ ”系统用例是根据业务分析模型中的业务角色自动化候选者的业务职责而创建的。如果您 回到图5，显示了 ISM Broker的VOPC图，每个业务职责，例如Query for Information，都可以转换 为系统用例模型中的系统用例。分析模型显示了业务实体如何映射到系统分析模型中的类上。这些类表示系统将使用的“数据”。总结我的目标是概括出RUP业务建模和系统用例建模的比较情况。我讨论了相似点和差别，以及业务用

34、例 模型和系统用例模型之间的关系。如果您对这些比较和关系有任何疑问，可以通过 arthur.english 联系我。注释1用例视图(Use-Case View)、逻辑视图(Logical View)是 UML 4+1 视图模型架构(UML 4+1 View Model Architecture)的一部分。要了解更多关于4+1视图模型架构的信息，您应该学习分析与设计规程中的 URUP软件架构概念。全程建模业务用例与用例的对应关系解析收藏 此文于2010-12-16被推荐到CSDN首页 如何被推荐？下文中是关于业务用例和用例之间的对应关系的对话，一般来说在一些较大的业务系统或者 业务逻辑较为复杂的

35、系统开发中才需要进行单独的业务建模过程，而对于大多数业务系统是 不需要单独进行这样的开发阶段的。在每次的全程建模的培训中，青润都会提出这个过程将业务建模过程进行详细的分解，但是 在软件工程之全程建模实现一书中对业务建模并没有进行深入的阐述。下文中的系统用例在青润的定义中一般就称之为用例，而系统用例这个名词用于非业务性相 关用例的命名，比如用户管理，码表分类定义/管理之类的非用户原有业务需求产生的用 例上，或者称之为支撑业务用例而不得不构建的用例被称之为系统用例。所以在这里单独进 行明确，以便于大家的区分。业务用例和用例的对应关系一般是1对1和1对多最为普遍，但是也可能出现多对1的 形式，甚至一

36、些用户业务间交叉过多的业务实现中还可能出现多对1的形式。比如下面这 个例子就是2003年底在北航给软工硕士讲课期间产生的一张图，此图的模型也在软件工 程之全程建模实现一书的光盘中可以找到：下面是相关的对话内容，有助于对以上内容的进一步理解。缘，妙不可言21:32:59UML中，我本来认为业务用例和系统用例的关系是一对多，因为系统用例是从业务用例场景 中推导出来的。可是后来被淘宝的面试官反驳了。我反复思考后现在认为：业务用例和系 统用例只是有用例粒度上的区别，即不同抽象层次上的，并不存在所谓的1对多关系。而 且一个业务用例对象可以有不同的场景实例，所以某个业务用例场景只是该业务用例对象的 某个方

37、面而已，自然从该业务用例场景中推导出的系统用例和该业务用例不会是1对多关 系。我觉得我的理解应该还有不对的地方，请本群的UML大牛一青润，给予指导，其他群 友也一起参与讨论下吧青润 21:46:02呵呵，这两者的关系，我那本书里做了详细的阐述。基本上可以认为是粒度的问题，但是，也可能出现一些业务用例在确定了其业务范畴之后认 为可以另外一个或者多个业务用例合并成为一个系统用例，所以，两者不是简单的1vn的 关系，应该是n v m的关系更合适。缘，妙不可言21:48:30多个业务用例合并成为一个系统用例？青润 21:48:50对，你肯定是没有遇到过，实际系统中会有这种特殊情况出现的，呵呵。应该是不

38、同业务用例场景中推导出的系统用例合并为一个吧青润 21:51:05在一些特殊业务系统的开发中，有可能出现这种情况，比如，抽取出来的公用子流部分，完 全可能进行子流的合并开发，实现系统的快速搭建和原型展示，这时候和用例业务场景没有 关系，呵呵，当然也有特殊的业务系统在实际开发中会出现合并的问题，比如你前期业务用 例划分过细，或者用户方曾经进行过一些业务流程的制度性分割造成的结果，你想想吧，肯 定能想明白。缘，妙不可言 21:52:39太深了，大象那书里是说对象必须从多个场景中分析出来，每个场景只是该对象映射到该 处的一个方面，所有名词，包括用例也是对象，他的分析方法和概念类对象一样青润 21:5

39、3:47呵呵，这么说没有大的错误，只是考虑的业务环境不够完整，经历的业务系统多了，自然会 遇到各种各样稀奇古怪的业务状况，自然就会有这样的情况出现。所谓的“业务用例”和“系统用例”有什么区别呢？首先，业务用例和系统用例是相对而言的。其次，业务用例和系统用例的研究对象不同。仍以经典的银行为例。我去银行开户：我在柜台前拿张空白的开户申请单，填写好我的信息，然后把我的身份证和填写好的 申请单递给柜员（此处省去排队数十分钟等巨不爽事）。柜员接个单子，啪嗒啪嗒的把我的信息录入他 们的系统。一番折腾后，我面前的密码输入器提示我设置帐号的密码两次。接着，他递出打印了信息的单 子，让我签字确认。我签字后递给他

40、，他使劲敲上几个印章，然后把我的存折、身份证以及手续单递给我， 并且告诉我办好了。这是银行很简单很常见的服务，也可以说是银行的功能。其实银行还有很多其它“功能”，比如存钱、 取钱、挂失等等。此时，我们其实是在把银行看作一个能提供很多“功能”的“系统”。同时，在这个过程中，柜员一直在操作银行的软件系统，过程可能是这样的：柜员首选选择开户功能；软件系统要求柜员将我的信息录入，并选择开户类型（我在申请单上写的是 活期）；软件系统可能会检查我的身份证号是否合法；软件系统为我生成一个银行帐号；软件系统会问柜 员我是否要密码（我在开户申请单上注明了需要），所以软件系统提示我设定密码；软件系统将我的存折 打

41、印出来。银行的软件系统给柜员提供了很多功能，除了开户当然也会有存钱、取钱、挂失等。但这些功能是银 行的软件系统提供给银行职员的。这样我们综合上述两个过程来看，其实我们在研究两个层次的“功能”。第一层次是银行提供给银行 的客户的功能；第二层次是软件系统提供给银行职员的功能。如下图所示：当我们对银行的业务进行建模时，我们会把银行看作一个整体，去研究银行会提供给客户哪 些服务。此时我们的研究对象是银行。当我们对银行的软件系统进行建模时，我们把软件系统当作一个整体，去研究它需要提供哪些功能给 银行的职员使用。此时我们的研究对象是银行的软件系统。这样我们为了区分起见，把前者称作“业务用例模型”；相对的，

42、把后者称作“系统用例模型”。业务用例和系统用例在用例技术的使用上没什么差别，如用例的关系、用例的描述等。在业务模型中还有一个概念，即“业务工人（Business Worker）”。业务工作表示实现业务的人、 软件或硬件等角色。比如银行的“开户”业务用例中，银行柜员、软件系统、打印存折的打印机等都可看 作是“业务工人”。为什么要做业务建模？请参阅Use Case的“前因”、“后果”（待出）。Q业务用例与用例的对应关系解析（续）上一篇/下一篇 2010-12-20 09:04:43 /个人分类：软件工程查看（44 ） /评论（0 ） /评分（0 / 0 ）!endif一 style. 上次问题的后

43、续对话，应该有助于理解这个问题的全部，因此贴上来。清水 8:54:56早啊卡恩 NO.1 21:31:22UML中，我本来认为业务用例和系统用例的关系是一对多，因为系统用例是从业务用例场景 中推导出来的。可是后来被淘宝的面试官反驳了。我反复思考后现在认为：业务用例和系 统用例只是有用例粒度上的区别，即不同抽象层次上的，并不存在所谓的1对多关系。而且一个业务用例对象可以有不同的场景实例，所以某个业务用例场景只是该业务用例对象的某 个方面而已，自然从该业务用例场景中推导出的系统用例和该业务用例不会是1对多关系。我觉得我的理解应该还有不对的地方，请本群的UML大牛一青润，给予指导，其他群 友也一起参

44、与讨论下吧卡恩 NO.1 21:31:22UML中，我本来认为业务用例和系统用例的关系是一对多，因为系统用例是从业务用例场景 中推导出来的。可是后来被淘宝的面试官反驳了。我反复思考后现在认为：业务用例和系 统用例只是有用例粒度上的区别，即不同抽象层次上的，并不存在所谓的1对多关系。而且 一个业务用例对象可以有不同的场景实例，所以某个业务用例场景只是该业务用例对象的某 个方面而已，自然从该业务用例场景中推导出的系统用例和该业务用例不会是1对多关系。我觉得我的理解应该还有不对的地方，请群友也一起参与讨论下吧ancestor 9:17:06流汗图标卡恩 NO.1 9:18:08青润老师昨晚的回答有点

45、深，而且感觉不是我想要的答案青润 9:20:13我给你一张图青润 9:20:20I ttp:/青润 9:20:41这个例子就是2003年底在北航给软工硕士讲课期间产生的一张图，此图的模型也在软件 工程之全程建模实现一书的光盘中可以找到清水 9:21:00旁听学习先青润 9:21:14这个是针对昨天这个话题补充了一些修订内容后，撰写的文字，可以去看看，应该说得比较 明确了。两者站的角度不同卡恩 NO.1 9:21:55哈，青润老师今早刚写的啊，拜读下先青润 9:21:57除了对话外的内容如下：下文中是关于业务用例和用例之间的对应关系的对话，一般来说在一些较大的业务系统或者 业务逻辑较为复杂的系统

46、开发中才需要进行单独的业务建模过程，而对于大多数业务系统是 不需要单独进行这样的开发阶段的。在每次的全程建模的培训中，青润都会提出这个过程将业务建模过程进行详细的分解，但是 在软件工程之全程建模实现一书中对业务建模并没有进行深入的阐述。下文中的系统用例在青润的定义中一般就称之为用例，而系统用例这个名词用于非业务性相 关用例的命名，比如用户管理，码表分类定义/管理之类的非用户原有业务需求产生的用例 上，或者称之为支撑业务用例而不得不构建的用例被称之为系统用例。所以在这里单独进行 明确，以便于大家的区分。业务用例和用例的对应关系一般是1对1和1对多最为普遍，但是也可能出现多对1的形 式，甚至一些用

47、户业务间交叉过多的业务实现中还可能出现多对1的形式。比如下面这个例 子就是2003年底在北航给软工硕士讲课期间产生的一张图，此图的模型也在软件工程之 全程建模实现一书的光盘中可以找到青润 9:22:11刚补充完的，呵呵。然后就看到你这里的消息了。清水 9:22:33看看先青润 9:22:45这个文字描述其实不好写清楚，因为涉及到一些复杂业务逻辑，或者复杂业务关系之间的相 互嵌套的问题。青润 9:23:03一般不常见，但是，在国内这类业务形式还是比较多的存在的业务用例，可以理解为：用来描述用户真实的日常办公中的一个个场景。系统用例,是面向系统的。是指为了实现用户在业务用例中展现出来的场景，系统应

48、该怎么去做 卡恩 NO.1 9:23:28一般来说在一些较大的业务系统或者业务逻辑较为复杂的系统开发中才需要进行单独的业 务建模过程，而对于大多数业务系统是不需要单独进行这样的开发阶段的。卡恩 NO.1 9:23:37你都是直接进入系统用例阶段么？青润 9:23:55这个问题不如不问。因为明显不是如此。卡恩 NO.1 9:24:23一般来说在一些较大的业务系统或者业务逻辑较为复杂的系统开发中才需要进行单独的业务建模过程青润 9:24:37对于用户业务比较直接简单的，完全不必作业务模型开发，可以直接进入用例模型的开发阶段。ancestor 9:25:01卡恩让淘宝的面试官给弄成魔症了由卡恩 NO

49、.1 9:25:16不是，这种概念性问题还是要清楚的青润 9:25:44呵呵，没事，技术讨论么，每个人都可能有自己的观点和看法，但是，解决问题的才是最好 的办法。对于不同的业务系统有可能办法是有差异的。ancestor 9:25:43嗯，其实业务用例和系统用例都是需求范畴内的清水 9:25:45大家觉得需求的文档是否要区分对内和对外两种版本？青润 9:25:56不需要。青润 9:26:12很多年前就有人问过。我当时的回答就是，需求必须让用户看懂。清水 9:26:15这个问题昨天技术开会的时候我们公司讨论过ancestor 9:26:13只是站在不同角度，不同时期的事情，它们的域不同ancest

50、or 9:26:33一个代表【业务范围】，一个代表【系统范围】。青润 9:26:57在全程建模的开发方*中，我也认为只有设计模型阶段以后的才完全不需要用户的参与，甚 至分析模型对于用户来说都是可以看懂的。青润 9:27:11而实际上，在多个项目中我也如此做到了。卡恩 NO.1 9:28:21业务用例和用例的对应关系一般是1对1和1对多最为普遍，但是也可能出现多 对1的形式，甚至一些用户业务间交叉过多的业务实现中还可能出现多对1的形式。大象作者说不是1对多或者类似的数量关系，因为用例也是对象，对象要从不同 的场景中分析出来。淘宝的面试官说业务用例只是为了搞清楚客户需求，不存在所谓的1 对多清水

51、9:28:31有个问题我们的客户是强势的需求文档必须按他的方式他关于的业务意义（往往是这 个系统的亮点 他底做报告的亮点）来描述但这样的文档对指导开发意义不大象这类问题有没有比较好的解决经验？mrman 9:28:45实际上，很多文档都是分了两份1+19:29:06淘宝的面试官说的对。青润 9:29:39如果用户方有这样的要求，而他们的文档明显不适合开发人员理解，那么你可以准备两份， 但是一般情况下，这个需求文档是不需要两份的。有个问题 我们的客户是强势的 需求文档必须按他的方式 他关于的业务意义（往往是这个系统的亮点 他底做报告的亮点）来描述但这样的文档 对指导开发 意义不大 象这类问题 有

52、没有比较好的解决经验？ancestor 9:29:43不同的人，对于术语有不同的理解。；-）青润 9:30:01因为如果你的技术人员无法理解用户的描述，你怎么保证你的业务系统用户可以用起来没有障碍呢？清水 9:30:34对这就是我想讨论的如果分两份就有个问题了以什么为界限划分呢青润 9:30:36对象，也有对象的拆分问题，大的对象和小的对象，要知道对象本身也是对象组成的，我为什么就不能拆分呢？ancestor 9:30:52淘宝面试官说的力度，其实，也可以理解为业务用例和系统用例的scope不同青润 9:30:57如果我把业务用例这个对象拆分了，是不是就是1对多了呢？青润 9:31:23如果我

53、进行了对象组合，那是不是就出现了多对1呢？清水 9:31:28刚才说的业务用例与系统用例能否作为一个划分的界限？用户需要理解系统用例吗青润 9:31:31这是对象概念中最基础的问题了。青润 9:31:59用户可以理解系统用例！这一点完全没有问题，我在多个项目中如此操作过卡恩 NO.1 9:32:56额，我把青润说的这话发给大象作者，静候他的回复青润 9:33:24呵呵，没问题。卡恩 NO.1 9:33:58 其实可能你们都对，我功力太浅给理解错了卡恩NO.19:34:03ancestor 9:34:23举个简单的例子，比如一个商场的收款系统，它的业务用例是顾客通过某个系统与收款员交 互。而系统

54、用例范围是小于等于业务用例的，它是从业务用例中提取出与系统开发有关的部 分，再分析成为系统用例。比如在收款系统中，顾客并不参与收款机的操作，所以它与收款 机的系统用例是无关的，而收款员参与这些操作，那么他是系统用例中的一个actor 青润 9:35:11简单的例子里面business uc和uc必然是一样的。ancestor 9:35:12卡恩 NO.1 9:33:58其实可能你们都对，我功力太浅给理解错了无所谓对于错，每个人理解一句话都是不一样的，最终结果达到一样就可以了破碎虚空 9:35:52白猫黑猫，抓到老鼠就是好猫ancestor 9:36:02呵呵青润 9:38:08这个不是理解错误，是一个概念的争论问题，涉及到业务的复杂性和实现关系的基础问题。青润 9:38:36没有遇到过这种过度复杂或者因为行政关系造成业务流程被强行分割的系统的话，的确很难 理解。青润 9:39:02国内这类外行领导内行进行业务流程强行分割组合的事情，实际上是不少见的，但是大部分 在国企。ancestor 9:39:24这里有个比较关键点取决于理解，“行业”ancestor 9:40:16系统分析用例是行业信息化经验比较丰富的产物