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

使用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的方法是将这些用例看作是一个光谱，从一个组织的最高层次业务目标，到为实现这些业务目标而执行的软件解决方案的需求详细资料。这种方法将系统用例看作是一个业务用例的分解。这个用例分解方法可以用来帮助您从这个业务模型驱动系统用例模型，我稍后会对这个问题进行讨论。那么业务用例模型与系统用例模型图有什么其他相似之处呢？两者都有参与者。在业务用例图中，您将一个参与者原型化为BusinessActor。两者都有用例。在业务用例模型中，您将一个用例原型化为BusinessUseCase。在参与者与用例之间两者都有一个通信关联。业务用例和系统用例都能够包含、扩展，以及一般化关联。用例图中的通信关联对于学习用例建模的人们来说，通常是一个容易混淆的地方。我应该使用箭头吗？这个箭头应该指向什么方向呢？通信关联已经被描绘出来，因为1.4UML规范是一条实线。这条线可以配上一个箭头。这条线和箭头代表角色与系统之间的双方对话。如果呈现出一个箭头，那么说明只有这个关联末尾的“这个事物”能够发起通信。没有箭头的表明任何一方都可以发起通信（而不是两端都发起通信）。UML2.0规范使它更简单。UML2.0不允许角色与用例之间或者业务角色与业务用例之间存在这种可灵活操作的关联。我个人比较喜欢箭头，但是如果您把IBMRationalSoftwareArchitect(RSA)当作您的UML建模工具，您就不能在角色和用例之间描绘出一个箭头。此时的RSA是完全没有错的。UML2.0是通信关联不可灵活操作的原因。既然我们已经讨论了业务用例模型和系统用例模型之间的相似之处，下面我们就看看它们的不同点。业务用例模型与系统用例模型之间究竟有怎样的差别呢？业务用例模型与系统用例模型之间主要有三点重大不同之处：设计范围、白盒测试与黑盒测试，以及业务操作者。范围在前面的部分中，我借助AlistairCockburn的处于“水平线”上面、下面，或正好处于“水平线”的规定对设计范围进行了讨论。业务用例着重于业务操作。它们表示实现业务目标的业务中的具体工作流。业务过程可能涉及手工和自动过程，并且在一段长期的时间内进行。系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互？我们在系统用例说明中书写的事件流应该足够详细，从而用作编写系统测试脚本的出发点。白盒与黑盒业务用例常常是以白盒形式编写的。它们描述了被建模的组织中的人和部门之间的交互。我们使用业务用例来说明在“现有”业务模型中组织如何工作。然后我们重构“现有”的业务用例模型，让其面向将要建模的组织的未来设计。我们需要创建什么新角色和部门来提供更多价值，或者消除业务问题？什么角色和部门需要消失？系统用例几乎总是以黑盒形式编写的。它们描述了软件系统之外的参与者如何与将被设计的系统进行交互。系统用例详细阐明了系统需求。系统用例模型的目的是从涉众的角度说明需求，而不是设计如何满足需求。业务角色那么业务角色是什么？在系统用例图中，您只让参与者与用例进行交互。但在业务用例图中，您可以让业务参与者和业务角色与业务用例进行交互。业务参与者是业务之外的人。它可以是一个角色或其他组织实体。例如，在刑事审判系统中，业务参与者可以是证人、嫌疑犯、外部的政府机构，例如健康服务，或业务实体，例如，业务资信咨询机构。业务角色是业务内部的某个人或某个部门。在刑事审判系统中，业务角色可以是治安人员、法官、检察官，或假释官。当您实现了一个业务用例，并且创建了时序图和/或通信图来显示业务参与者、业务角色，和业务实体如何协作执行业务用例时，您将会把业务角色从业务用例模型转入业务分析模型，并且加入所需的额外业务角色来提供业务用例功能。图1显示了基于ISM项目的示例业务用例图。图1：ISM业务用例图图1显示了一个业务参与者：嫌疑犯（Suspect）。有三个业务角色：执法人（LawEnforcement）、检察官（Prosecutor）和法院（Court）。有四个业务用例：逮捕被告（ArrestS