业务用例与系统用例的关系.docx
《业务用例与系统用例的关系.docx》由会员分享，可在线阅读，更多相关《业务用例与系统用例的关系.docx（27页珍藏版）》请在冰豆网上搜索。
业务用例与系统用例的关系
使用UML进行业务建模：
理解业务用例与系统用例的相似和不同之处
∙背景
∙业务用例模型与系统用例模型有什么相似之处？
∙业务用例模型与系统用例模型之间究竟有怎样的差异呢？
∙我应该为业务建模使用哪些UML图？
∙业务用例模型和系统用例模型之间的关系是什么？
∙总结
∙注释
∙现在对本文进行讨论！
参考资料
本文来自于RationalEdge：
学习有关业务用例与系统用例相似和不同之处的知识，包括应该使用什么样的UML图，通过IBMRationalSoftwareArchitect或者其它建模工具来建模这些用例。
绝大多数构架师都认为业务建模是开发软件解决方案中到一个非常重要的活动。
成功的解决方案会支持这个业务，它们能够解决业务问题并确保业务目标的实现。
当开发一个合理的业务模型以后，业务流程分析员能够探究不同业务改良的选项，比方取消多余的任务，使重复且平凡的任务或者容易出现的错误实现自动化操作。
IBM®RationalUnifiedProcess®，或者RUP®，以及Unisys3DVisualEnterprise，或者3D-VE，或者3D-VE,提供了一个系统化的方法，利用统一建模语言〔UML〕可以直观地表现业务模型，同时还可以派生出一个一致的且能够追溯到这个业务模型的起点系统用例模型。
这篇文章提供了RUP业务建模的概述，并解决了以下的问题：
∙业务用例模型与系统用例模型有怎样的相似之处？
∙业务用例模型与系统用例模型有什么不同之处？
∙构建业务模型应该使用哪个UML图？
∙业务用例模型与系统用例模型之间有什么关系？
背景
在谈论这个问题之前，我想解释一下为什么要挑选这个特殊的话题来写。
自从1990年我就作为一名软件构架师从事系统用例的工作。
当我是一名由UnisysGlobalPublicSector开发的IntegratedJusticeInformationSharing（IJIS）框架解决方案的总构架师时，还没有接触到业务用例，直到2002年。
IJIS现在已经开展成为UnisysInformationSharingManagementFramework（ISM）。
ISM是一套支持信息共享的总体业务过程的可重用的组件。
ISMFramework利用ServiceOrientedArchitecture（SOA）技术整合了不同类型的司法与公共平安系统，从而在关键决定点时分配关键的数据，文档以及图片。
ISM解决方案将为司法与公共平安团体提供了一个业务框架、技术框架、根底应用软件以及方法，使政府机构能够继续使用他们的遗留系统。
ISM是使用RUP进行设计的，ISM业务模型是为ISM工程开发的首批工件之一。
开发ISM业务模型对我来说是一个有意义的学习经历：
我认识到的一个问题是，对于如何开发一个业务模型有很多含混不清的地方，为开发UML业务模型提供指导的文献相比照拟少，而且有些不一致。
自从我离开UnisysGlobalPublicSector参加到UnisysUniversity作为一名培训和开发参谋后，就一直负责开发和交付软件构架和IBMRational工具培训。
我的职责之一就是IBMRational课程"MasteringRequirementsManagementwithUseCases"（MRMUC）的教学。
这门课程主要阐述的是开发系统用例，但是这门课程仅仅提供了什么是业务模型以及它如何与这个系统用例模型相联系的一个很有限的讨论。
因此这篇文章的目的之一就是为MRMUC课程补充材料。
这篇文章假定您已经有了系统用例建模和RUP需求规程的根本知识。
如果您对系统用例建模并不熟悉，我建议您学习RUP需求规程的知识。
正如前面提到的，这篇文献关于业务建模的内容比拟少，但是我们发现了一些非常有用的参考资料，远远多于您在RUP中找到的信息：
∙WritingEffectiveUseCases，由AlistairCockburn编著。
这是我最喜欢的关于业务和系统用例说明的著作。
Alistair强调一个业务或者系统用例模型最重要的局部是用例说明。
这本书强调的就是用例说明，而不是UML。
∙UMLfortheITBusinessAnalyst，由HowardPodeswa编写。
本书主要强调的是利用UML来开发一个业务模型，以及对Alistair的书进行补充。
UMLfortheITBusinessAnalyst帮助我完成了关于如何开发一个有效的业务用例模型的课程培训。
∙RationalEdge中的文章“EffectiveBusinessModelingwithUML:
DescribingBusinessUseCasesandRealizations〞，由Pan-WeiNg编写。
那篇文章与这篇文章有些类似。
那篇文章是从UML1.x的角度来编写的。
而这篇文章是从一个UML2.0的角度来编写的，并且阐述了业务用例模型，业务分析模型，以及系统用例模型之间更深刻的关系。
既然我已经完成了预备工作，就让我们开始提一些问题。
业务用例模型与系统用例模型有什么相似之处？
业务用例模型与系统用例模型有很多相似之处。
两个模型都有用例说明。
如果您对业务用例模型以及系统用例模型的RUP模版进行检查，您会发现它们的格式十分相似。
两者都包含先决条件、后置条件、扩展点以及特殊需求。
业务用例说明有根本的工作流和可选择的工作流，从而取代了根本的事件流和可选流。
业务用例说明与系统用例说明的格式十分相似，但是在设计范围上有些分歧。
业务用例的设计范围是业务操作。
它是这个组织外部的业务参与者，实现与业务组织相关的业务目标。
让我们查看这个业务用例的RUP定义：
"业务用例从一个外部的，增加值的角度来描述一个业务过程。
为了给这个业务的涉众创造价值，业务用例是超越组织边界的业务过程，很可能包括合作伙伴和供给商。
"
简单地说，这个定义标识了一些重要点，比方：
∙一个业务用例描述的是业务过程——而不是软件系统过程。
∙一个业务用例为涉众创造价值。
这些涉众要么是业务参与者要么是业务工作者。
∙一个业务用例可以超越组织的边界。
有些构架师对于这一点有非常严密的态度。
许多业务用例确实超越来组织的边界，但是有些业务用例仅仅关注于一个组织。
我稍后将在这篇中给出一些例子。
让我们也看看Podeswa的书UMLfortheITBusinessAnalyst中对业务用例的定义：
"业务用例：
业务过程是描述这个业务的具体工作流的；一次涉众与实现业务目标的业务之间的交互。
它可能包含手工和自动化的过程，也可能发生在一个长期的时间段中。
"
这个定义说明了通过实现业务目标创造价值的观点。
它通过把一个业务过程描述成一个可能包含手工和自动化过程的具体工作流来详述RUP的定义。
这个定义还指出，工作流可能发生在一个长期时间段中。
所有的这些都十分的重要。
那么系统用例又是怎样的呢？
系统用例的设计范围就是这个计算机系统设计的范围。
它是一个系统参与者，与计算机系统一起实现一个目标。
系统用例就是参与者如何与计算机技术相联系，而不是业务过程。
Cockburn的WritingEffectiveUseCases给业务和系统用例使用了相同的用例说明模版。
业务用例与系统用例说明使用这个模版的区别是设计范围，而不是模版。
Cockburn想通过目标层次对用例进行分类，如表格1所示。
图1：
AlistairCockburn对业务和系统用例的分类
高层概要
概要
用户目标
子功能
最低层
Cockburn编写WritingEffectiveUseCases的最初目标是系统用例，但他在业务用例上也花了很多精力。
他利用目标层次来区分业务与系统用例，而不是使用不同的模版类型。
那么这些图标和目标层次又意味着什么呢？
这些图标本身代表着一个简单的系统，它是根据用例与“海平面〞〔用户的实际层次〕的相对上下来确定的。
系统用例的最正确点是用户目标，通过海平面图标来说明。
有时候需要将复杂的系统用例分解成其它有子功能目标、通过鱼图标说明的用例。
但是您应该尽量防止将海平面系统用例分解成蛤或者最低层系统用例。
也许您会猜想到，概要或者蛤用例应该是业务用例。
云或者高层概要也可能是业务用例。
Cockburn的方法是将这些用例看作是一个光谱，从一个组织的最高层次业务目标，到为实现这些业务目标而执行的软件解决方案的需求详细资料。
这种方法将系统用例看作是一个业务用例的分解。
这个用例分解方法可以用来帮助您从这个业务模型驱动系统用例模型，我稍后会对这个问题进行讨论。
那么业务用例模型与系统用例模型图有什么其他相似之处呢？
∙两者都有参与者。
在业务用例图中，您将一个参与者原型化为<>。
∙两者都有用例。
在业务用例模型中，您将一个用例原型化为<>。
∙在参与者与用例之间两者都有一个通信关联。
∙业务用例和系统用例都能够包含、扩展，以及一般化关联。
用例图中的通信关联对于学习用例建模的人们来说，通常是一个容易混淆的地方。
我应该使用箭头吗？
这个箭头应该指向什么方向呢？
通信关联已经被描绘出来，因为1.4UML标准是一条实线。
这条线可以配上一个箭头。
这条线和箭头代表角色与系统之间的双方对话。
如果呈现出一个箭头，那么说明只有这个关联末尾的“这个事物〞能够发起通信。
没有箭头的说明任何一方都可以发起通信〔而不是两端都发起通信〕。
UML2.0标准使它更简单。
UML2.0不允许角色与用例之间或者业务角色与业务用例之间存在这种可灵活操作的关联。
我个人比拟喜欢箭头，但是如果您把IBMRationalSoftwareArchitect（RSA）当作您的UML建模工具，您就不能在角色和用例之间描绘出一个箭头。
此时的RSA是完全没有错的。
UML2.0是通信关联不可灵活操作的原因。
既然我们已经讨论了业务用例模型和系统用例模型之间的相似之处，下面我们就看看它们的不同点。
业务用例模型与系统用例模型之间究竟有怎样的差异呢？
业务用例模型与系统用例模型之间主要有三点重大不同之处：
设计范围、白盒测试与黑盒测试，以及业务操作者。
范围
在前面的局部中，我借助AlistairCockburn的处于“水平线〞上面、下面，或正好处于“水平线〞的规定对设计范围进行了讨论。
业务用例着重于业务操作。
它们表示实现业务目标的业务中的具体工作流。
业务过程可能涉及手工和自动过程，并且在一段长期的时间内进行。
系统用例着重于要设计的软件系统。
参与者如何与软件系统进行交互？
我们在系统用例说明中书写的事件流应该足够详细，从而用作编写系统测试脚本的出发点。
白盒与黑盒
业务用例常常是以白盒形式编写的。
它们描述了被建模的组织中的人和部门之间的交互。
我们使用业务用例来说明在“现有〞业务模型中组织如何工作。
然后我们重构“现有〞的业务用例模型，让其面向将要建模的组织的未来设计。
我们需要创立什么新角色和部门来提供更多价值，或者消除业务问题？
什么角色和部门需要消失？
系统用例几乎总是以黑盒形式编写的。
它们描述了软件系统之外的参与者如何与将被设计的系统进行交互。
系统用例详细说明了系统需求。
系统用例模型的目的是从涉众的角度说明需求，而不是设计如何满足需求。
业务角色
那么业务角色是什么？
在系统用例图中，您只让参与者与用例进行交互。
但在业务用例图中，您可以让业务参与者和业务角色与业务用例进行交互。
业务参与者是业务之外的人。
它可以是一个角色或其他组织实体。
例如，在刑事审判系统中，业务参与者可以是证人、嫌疑犯、外部的政府机构，例如健康效劳，或业务实体，例如，业务资信咨询机构。
业务角色是业务内部的某个人或某个部门。
在刑事审判系统中，业务角色可以是治安人员、法官、检察官，或假释官。
当您实现了一个业务用例，并且创立了时序图和/或通信图来显示业务参与者、业务角色，和业务实体如何协作执行业务用例时，您将会把业务角色从业务用例模型转入业务分析模型，并且参加所需的额外业务角色来提供业务用例功能。
图1显示了基于ISM工程的例如业务用例图。
图1：
ISM业务用例图
图1显示了一个业务参与者：
嫌疑犯〔Suspect〕。
有三个业务角色：
执法人〔LawEnforcement〕、检察官〔Prosecutor〕和法院〔Court〕。
有四个业务用例：
逮捕被告〔ArrestSubject〕、请求担保〔RequestWarrant〕、获得指纹和嫌疑犯照片〔CaptureFingerprintsandMugshot〕，以及保释〔ReleaseonBail〕。
获取指纹和嫌疑犯照片总是作为来自逮捕被告根底业务用例的强制行为。
保释是继承逮捕被告业务用例的可选行为。
早先，我讨论了业务用例如何跨越组织边界，许多情况都是这样的。
请求担保就是一个好例子。
它涉及执法人和法院。
业务用例还可以只集中在一个组织上。
获得指纹和嫌疑犯照片就是这样一个好例子。
我应该为业务建模使用哪些UML图？
在我讨论您在业务建模中使用的UML图之前，我想说一些关于使用RSA和UML2.0创立业务用例图的提示：
∙在UML1.x中，您可以将参与者原型化为业务角色。
在UML2.0中，您必须创立一个类，然后将其原型化为业务角色。
在UML2.0中，您可以将参与者原型化为业务参与者，但您不能将参与者原型化为业务角色。
∙在UML2.0中，业务用例和业务角色之间的关联是可导航的。
业务参与者和业务用例之间的关联是不可导航的。
∙作为最正确实践，我推荐断开业务用例和业务角色之间的导航，从而保持业务角色与业务参与者的一致。
业务角色及其用例关联应该按照业务参与者与业务用例通信的同样方式来绘制。
∙您必须在您的工程的Properties标签页中选择Profiles选项卡，然后单击AddProfile按钮，来向您的工程中添加业务建模和健壮性分析原型。
在IBMRationalRose中，这是自动包含的。
在UML2.0中，概要文件用于包装原型和标记值UML扩展。
UML2.0标准要求您向UML建模工程中添加概要文件来使用业务建模原型。
UML业务模型包括两个模型：
用例视图〔Use-CaseView〕中的业务用例模型和逻辑视图〔LogicalView〕中的业务分析模型。
1业务用例模型中的主图是业务用例图。
您还可以随意参加表示单个业务用例的UML活动图，来图形化地显示工作流过程，如图2所示，逮捕被告业务用例的活动图。
图2：
ISM逮捕被告业务用例活动图
业务分析模型描述了通过业务角色和业务实体的交互来实现业务用例。
它用作业务角色和业务实体需要如何相关联，以及它们需要如何协作，来执行业务用例的抽象。
业务分析模型中有三种类型的UML图，如图3所示：
类〔Class〕、时序〔Sequence〕和通信〔Communication〕图。
图3：
业务分析模型图
业务分析模型中的主要的图是时序图。
您手工地创立显示出业务参与者、业务角色，和业务实体如何交互执行业务用例的时序图。
时序图显示出以时间时序安排的对象交互。
特别是，它显示出参与交互的对象，以及消息交换的顺序。
通信图是以前在UML1.x中所称的协作图〔Collaborationdiagram〕，它描述了对象之间交互的模式，通过对象间的链接和发送给对方的消息来展示参与交互的对象。
通信图和时序图都显示出交互，但它们强调了不同的方面。
时序图清楚地显示出时间顺序，但没有明确地显示出对象关系。
通信图清楚地显示出对象关系，但必须从顺序号那儿获得时间顺序。
两个图都显示出同样的行为，但方式不同。
我个人喜欢时序图，因为它通常比拟容易读懂。
您还可以使用参与类的视图〔ViewofParticipatingClasses，VOPC〕来显示协作执行业务用例的业务参与者、业务角色和业务实体的静态视图。
图4显示出ISM逮捕被告业务用例实现的时序图。
图5显示出ISM逮捕被告业务用例实现的VOPC。
图6显示出ISM逮捕被告业务用例实现的通信图。
图4：
ISM逮捕被告业务用例实现的时序图
在ISM逮捕被告业务时序图这局部中，如图4所示，有三个从业务用例模型转入的业务角色：
执法人、签署者〔Subscriber〕和刑事审判系统。
刑事审判系统是执法人、法院、检察官，等等的一般化。
为了让时序图简单化，我们使用该泛化来表示ISM可以使用的任意刑事审判系统。
图4还显示出引入到业务分析模型中的两个新的业务角色：
档案管理系统〔RecordsManagementSystem，RMS〕和ISMBroker。
RMS通常是商业化成品〔commercialoff-the-shelf，COTS〕解决方案，它将地方的执法用作刑事案件管理系统。
ISMBroker是Unisys方案开发的软件解决方案的自动化候选者或代理。
UnisysISM解决方案利用中心辐射型SOA技术整合了多个各种各样的司法系统，从而在重要决策点处，分享关键任务的数据、文档、图像和事务。
ISM可以在MicrosoftBizTalkServer或IBMWebSphereBusinessIntegration上实现。
ISMBroker作为在审判团之中数据共享的导管，并且利用当前的技术来推、拉、发布和订阅信息，从而支持日常的审判操作。
图5：
ISM逮捕被告业务用例实现的VOPC图
图5中的VOPC图显示了参与逮捕被告业务用例的业务参与者、业务角色和业务实体的静态视图。
注意为每个业务角色显示的操作。
这些操作被称为业务职责。
VOPC图的更精确的名称是参与的业务参与者、业务角色和业务实体的视图〔ViewofParticipatingBusinessActors,、BusinessWorkers和BusinessEntities〕。
在本实例中，只有业务角色协作执行业务用例。
图6：
ISM逮捕被告业务用例实现的通信图
如前面所提到的，通信图〔如图6所示〕是观察时序图中所示行为的另一种方法。
RSA提供了从时序图创立通信图的自动能力，反之亦然。
还有一个要答复的问题。
业务用例模型和系统用例模型之间的关系是什么？
图7，业务用例到系统用例的向下流动〔BusinesstoSystemUse-CaseFlowDown〕，出自我所教授的IBMRational课程“MasteringRequirementsManagementwithUseCases〞。
图7，业务用例到系统用例的向下流动
图7例举了课程中最难教授的主题之一，因为您要理解该图所需的大局部根底不在标准课程材料之内。
本文的其中一个目的是提供额外的根底。
图7显示了业务模型中所找到的东西和系统用例模型中的东西之间的清晰映射。
在此特殊的实例中，可以看出，系统能够将业务角色的职责自动化。
它还显示出关键的业务角色是自动化的候选者。
记住，业务模型包含业务用例模型和业务分析模型。
业务分析模型是业务用例模型的实现，并且拥有紧密的集成化和可追溯性。
系统用例模型可以追溯到业务分析模型。
业务分析模型可以追溯到业务用例模型。
使用该方法，您可以构建从业务分析模型演化来的系统用例模型。
这向您的整个UML模型提供了一致性和可追溯性。
那么系统参与者和系统用例从那里来的呢？
系统参与者是根据业务分析模型中的业务参与者和业务角色而生成的。
与业务角色自动化候选者交互的业务参与者总是成为系统参与者。
不是自动化候选者的，与业务角色自动化候选者交互的业务角色成为系统参与者。
例如，ISM业务分析模型中的执法人和法院成为了系统参与者。
ISMBroker是“纯〞自动化候选者。
它不会成为系统参与者。
我所谓的纯是什么意思呢？
简单的说，自动化候选者的唯一目的就是成为我们正在开发的软件解决方案的代理。
注意到图7中的LoanSpecialist。
LoanSpecialist业务角色转换为系统参与者和系统用例。
让我来解释一下。
LoanSpecialist是图7中所示的业务模型中的角色。
在我们的系统用例模型中，需要有作为LoanSpecialist角色的参与者。
但是，在我们正在开发的新的软件解决方案中将LoanSpecialist的一些业务职责自动化了。
业务分析模型中的那些业务职责成为了系统用例模型中的系统用例。
其他的纯业务角色自动化候选者将不会转换为系统用例模型中的系统角色。
这答复了问题，“系统用例是从哪里来的？
〞系统用例是根据业务分析模型中的业务角色自动化候选者的业务职责而创立的。
如果您回到图5，显示了ISMBroker的VOPC图，每个业务职责，例如QueryforInformation，都可以转换为系统用例模型中的系统用例。
分析模型显示了业务实体如何映射到系统分析模型中的类上。
这些类表示系统将使用的“数据〞。
总结
我的目标是概括出RUP业务建模和系统用例建模的比拟情况。
我讨论了相似点和差异，以及业务用例模型和系统用例模型之间的关系。
如果您对这些比拟和关系有任何疑问，可以通过arthur.english@unisys联系我。
注释
1用例视图〔Use-CaseView〕、逻辑视图〔LogicalView〕是UML4+1视图模型架构〔UML4+1ViewModelArchitecture〕的一局部。
要了解更多关于4+1视图模型架构的信息，您应该学习分析与设计规程中的URUP软件架构概念。
[全程建模]业务用例与用例的对应关系解析收藏此文于2010-12-16被推荐到CSDN首页
如何被推荐？
下文中是关于业务用例和用例之间的对应关系的对话，一般来说在一些较大的业务系统或者业务逻辑较为复杂的系统开发中才需要进行单独的业务建模过程，而对于大多数业务系统是不需要单独进行这样的开发阶段的。
在每次的全程建模的培训中，青润都会提出这个过程将业务建模过程进行详细的分解，但是在?
软件工程之全程建模实现?
一书中对业务建模并没有进行深入的阐述。
下文中的系统用例在青润的定义中一般就称之为用例，而系统用例这个名词用于非业务性相关用例的命名，比方用户管理，码表分类定义/管理之类的非用户原有业务需求产生的用例上，或者称之为支撑业务用例而不得不构建的用例被称之为系统用例。
所以在这里单独进行明确，以便于大家的区分。
业务用例和用例的对应关系一般是1对1和1对多最为普遍，但是也可能出现多对1的形式，甚至一些用户业务间交叉过多的业务实现中还可能出现多对1的形式。
比方下面这个例子就是2003年底在北航给软工硕士讲课期间产生的一张图，此图的模型也在?
软件工程之全程建模实现?
一书的光盘中可以找到：
下面是相关的对话内容，有助于对以上内容的进一步理解。
缘，妙不可言21:
32:
59
UML中，我本来认为业务用例和系统用例的关系是一对多，因为系统用例是从业务用例场景中推导出来
升级会员 