业务用例与系统用例的关系Word文档下载推荐.docx

业务用例与系统用例的关系Word文档下载推荐.docx

《业务用例与系统用例的关系Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《业务用例与系统用例的关系Word文档下载推荐.docx（21页珍藏版）》请在冰豆网上搜索。

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的方法是将这些用例看作是一个光谱，从一个组织的最高层次业务目标，到为实现这些业务目标而执行的软件解决方案的需求详细资料。

这种方法将系统用例看作是一个业务用例的分解。

那个用例分解方法能够用来关心您从那个业务模型驱动系统用例模型，我稍后会对那个问题进行讨论。

那么业务用例模型与系统用例模型图有什么其他相似之处呢？

∙两者都有参与者。

在业务用例图中，您将一个参与者原型化为<

<

BusinessActor>

>

。

∙两者都有用例。

在业务用例模型中，您将一个用例原型化为<

BusinessUseCase>

∙在参与者与用例之间两者都有一个通信关联。

∙业务用例和系统用例都能够包含、扩展，以及一样化关联。

用例图中的通信关联关于学习用例建模的人们来说，通常是一个容易混淆的地点。

我应该使用箭头吗？

那个箭头应该指向什么方向呢？

通信关联差不多被描画出来，因为1.4UML规范是一条实线。

这条线能够配上一个箭头。

这条线和箭头代表角色与系统之间的双方对话。

假如出现出一个箭头，那么说明只有那个关联末尾的“那个事物”能够发起通信。

没有箭头的说明任何一方都能够发起通信（而不是两端都发起通信）。

UML2.0规范使它更简单。

UML2.0不承诺角色与用例之间或者业务角色与业务用例之间存在这种可灵活操作的关联。

我个人比较喜爱箭头，然而假如您把IBMRationalSoftwareArchitect（RSA）当作您的UML建模工具，您就不能在角色和用例之间描画出一个箭头。

现在的RSA是完全没有错的。

UML2.0是通信关联不可灵活操作的缘故。

既然我们差不多讨论了业务用例模型和系统用例模型之间的相似之处，下面我们就看看它们的不同点。

业务用例模型与系统用例模型之间怎么说有如何样的差别呢？

业务用例模型与系统用例模型之间要紧有三点重大不同之处：

设计范畴、白盒测试与黑盒测试，以及业务操作者。

范畴

在前面的部分中，我借助AlistairCockburn的处于“水平线”上面、下面，或正好处于“水平线”的规定对设计范畴进行了讨论。

业务用例着重于业务操作。

它们表示实现业务目标的业务中的具体工作流。

业务过程可能涉及手工和自动过程，同时在一段长期的时刻内进行。

系统用例着重于要设计的软件系统。

参与者如何与软件系统进行交互？

我们在系统用例说明中书写的事件流应该足够详细，从而用作编写系统测试脚本的动身点。

白盒与黑盒

业务用例常常是以白盒形式编写的。

它们描述了被建模的组织中的人和部门之间的交互。

我们使用业务用例来说明在“现有”业务模型中组织如何工作。

然后我们重构“现有”的业务用例模型，让其面向将要建模的组织的以后设计。

我们需要创建什么新角色和部门来提供更多价值，或者排除业务问题？

什么角色和部门需要消逝？

系统用例几乎总是以黑盒形式编写的。

它们描述了软件系统之外的参与者如何与将被设计的系统进行交互。

系统用例详细阐明了系统需求。

系统用例模型的目的是从涉众的角度说明需求，而不是设计如何满足需求。

业务角色

那么业务角色是什么？

在系统用例图中，您只让参与者与