业务用例与系统用例的关系Word文件下载.docx

1、IJIS 现在已经开展成为 Unisys Information Sharing Management Framework （ISM）。ISM 是一套支持信息共享的总体业务过程的可重用的组件。ISM Framework 利用 Service Oriented Architecture （SOA） 技术整合了不同类型的司法与公共平安系统，从而在关键决定点时分配关键的数据，文档以及图片。ISM 解决方案将为司法与公共平安 团体提供了一个业务框架、技术框架、根底应用软件以及方法，使政府机构能够继续使用他们的遗留系统。ISM 是使用 RUP 进行设计的，ISM 业务模型是为 ISM 工程开发的首批工件

2、之一。开发 ISM 业务模型对我来说是一个有意义的学习经历：我认识到的一个问题是，对于如何开发一个业务模型有很多含混不清的地方，为开发 UML 业务模型提供指导的文献相比照拟少，而且有些不一致。自从我离开 Unisys Global Public Sector 参加到 Unisys University 作为一名培训和开发参谋后，就一直负责开发和交付软件构架和 IBM Rational 工具培训。我的职责之一就是 IBM Rational 课程 Mastering Requirements Management with Use Cases （MRMUC） 的教学。这门课程主要阐述的是开发系统

3、用例，但是这门课程仅仅提供了什么是业务模型以及它如何与这个系统用例模型相联系的一个很有限的讨论。因此这篇文章的目的之一就是为 MRMUC 课程补充材料。这篇文章假定您已经有了系统用例建模和 RUP 需求规程的根本知识。如果您对系统用例建模并不熟悉，我建议您学习 RUP 需求规程的知识。正如前面提到的，这篇文献关于业务建模的内容比拟少，但是我们发现了一些非常有用的参考资料，远远多于您在 RUP 中找到的信息：Writing Effective Use Cases， 由 Alistair Cockburn 编著。这是我最喜欢的关于业务和系统用例说明的著作。Alistair 强调一个业务或者系统用例

4、模型最重要的局部是用例说明。这本书强调的就是用例说明，而不是 UML。UML for the IT Business Analyst， 由 Howard Podeswa 编写。本书主要强调的是利用 UML 来开发一个业务模型，以及对 Alistair 的书进行补充。 UML for the IT Business Analyst 帮助我完成了关于如何开发一个有效的业务用例模型的课程培训。Rational Edge 中的文章“Effective Business Modeling with UML: Describing Business Use Cases and Realizations，由

5、 Pan-Wei Ng 编写。那篇文章与这篇文章有些类似。那篇文章是从 UML 1.x 的角度来编写的。而这篇文章是从一个 UML 2.0 的角度来编写的，并且阐述了业务用例模型，业务分析模型，以及系统用例模型之间更深刻的关系。既然我已经完成了预备工作，就让我们开始提一些问题。业务用例模型与系统用例模型有什么相似之处？业务用例模型与系统用例模型有很多相似之处。两个模型都有用例说明。如果您对业务用例模型以及系统用例模型的 RUP 模版进行检查，您会发现它们的格式十分相似。两者都包含先决条件、后置条件、扩展点 以及特殊需求。业务用例说明有根本的工作流和可选择的工作流，从而取代了根本的事件流和可选流

6、。业务用例说明与系统用例说明的格式十分相似，但是在设计范围上有些分歧。业务用例的设计范围是业务操作。它是这个组织外部的业务参与者，实现与业务组织相关的业务目标。让我们查看这个业务用例的 RUP 定义： 业务用例从一个外部的，增加值的角度来描述一个业务过程。为了给这个业务的涉众创造价值，业务用例是超越组织边界的业务过程，很可能包括合作伙伴和供给商。简单地说，这个定义标识了一些重要点，比方：一个业务用例描述的是业务过程而不是软件系统过程。一个业务用例为涉众创造价值。这些涉众要么是业务参与者要么是业务工作者。一个业务用例可以超越组织的边界。有些构架师对于这一点有非常严密的态度。许多业务用例确实超越来

7、组织的边界，但是有些业务用例仅仅关注于一个组织。我稍后将在这篇中给出一些例子。让我们也看看 Podeswa 的书 UML for the IT Business Analyst 中对业务用例的定义：业务用例：业务过程是描述这个业务的具体工作流的；一次涉众与实现业务目标的业务之间的交互。它可能包含手工和自动化的过程，也可能发生在一个长期的时间段中。这个定义说明了通过实现业务目标创造价值的观点。它通过把一个业务过程描述成一个可能包含手工和自动化过程的具体工作流来详述 RUP 的定义。这个定义还指出，工作流可能发生在一个长期时间段中。所有的这些都十分的重要。那么系统用例又是怎样的呢？系统用例的设计范

8、围就是这个计算机系统设计的范围。它是一个系统参与者，与计算机系统一起实现一个目标。系统用例就是参与者如何与计算机技术相联系，而不是业务过程。Cockburn 的 Writing Effective Use Cases 给业务和系统用例使用了相同的用例说明模版。业务用例与系统用例说明使用这个模版的区别是设计范围，而不是模版。Cockburn 想通过目标层次对用例进行分类，如表格1所示。图1： Alistair Cockburn 对业务和系统用例的分类 高层概要概要用户目标子功能最低层Cockburn 编写 Writing Effective Use Cases 的最初目标是系统用例，但他在业务用

9、例上也花了很多精力。他利用目标层次来区分业务与系统用例，而不是使用不同的模版类型。那么这些图标和目标层次又意味着什么呢？这些图标本身代表着一个简单的系统，它是根据用例与“海平面用户的实际层次的相对上下来确定的。系统用例的最正确点是用户目标，通过海平面图标来说明。有时候需要将复杂的系统用例分解成其它有子功能目标、通过鱼图标说明的用例。但是您应该尽量防止将海平面系统用例分解成蛤或者最低层系统用例。也许您会猜想到，概要或者蛤用例应该是业务用例。云或者高层概要也可能是业务用例。Cockburn 的方法是将这些用例看作是一个光谱，从一个组织的最高层次业务目标，到为实现这些业务目标而执行的软件解决方案的需

10、求详细资料。这种方法将系统用例看作是一个业务用例的分解。这个用例分解方法可以用来帮助您从这个业务模型驱动系统用例模型，我稍后会对这个问题进行讨论。那么业务用例模型与系统用例模型图有什么其他相似之处呢？两者都有参与者。在业务用例图中，您将一个参与者原型化为 。两者都有用例。在业务用例模型中，您将一个用例原型化为 在参与者与用例之间两者都有一个通信关联。业务用例和系统用例都能够包含、扩展，以及一般化关联。用例图中的通信关联对于学习用例建模的人们来说，通常是一个容易混淆的地方。我应该使用箭头吗？这个箭头应该指向什么方向呢？通信关联已经被描绘出来，因为 1.4 UML 标准是一条实线。这条线可以配上一

11、个箭头。这条线和箭头代表角色与系统之间的双方对话。如果呈现出一个箭头，那么说明只有这个关联末尾的“这个事物能够发起通信。没有箭头的说明任何一方都可以发起通信而不是两端都发起通信。UML 2.0 标准使它更简单。UML 2.0 不允许角色与用例之间或者业务角色与业务用例之间存在这种可灵活操作的关联。我个人比拟喜欢箭头，但是如果您把 IBM Rational Software Architect （RSA） 当作您的 UML 建模工具，您就不能在角色和用例之间描绘出一个箭头。此时的 RSA 是完全没有错的。 UML 2.0 是通信关联不可灵活操作的原因。既然我们已经讨论了业务用例模型和系统用例模型

12、之间的相似之处，下面我们就看看它们的不同点。业务用例模型与系统用例模型之间究竟有怎样的差异呢？业务用例模型与系统用例模型之间主要有三点重大不同之处：设计范围、白盒测试与黑盒测试，以及业务操作者。范围在前面的局部中，我借助 Alistair Cockburn 的处于“水平线上面、下面，或正好处于“水平线的规定对设计范围进行了讨论。业务用例着重于业务操作。它们表示实现业务目标的业务中的具体工作流。业务过程可能涉及手工和自动过程，并且在一段长期的时间内进行。系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互？我们在系统用例说明中书写的事件流应该足够详细，从而用作编写系统测试脚本的出发点。白

13、盒与黑盒业务用例常常是以白盒形式编写的。它们描述了被建模的组织中的人和部门之间的交互。我们使用业务用例来说明在“现有业务模型中组织如何工作。然后我们重构“现有的业务用例模型，让其面向将要建模的组织的未来设计。我们需要创立什么新角色和部门来提供更多价值，或者消除业务问题？什么角色和部门需要消失？系统用例几乎总是以黑盒形式编写的。它们描述了软件系统之外的参与者如何与将被设计的系统进行交互。系统用例详细说明了系统需求。系统用例模型的目的是从涉众的角度说明需求，而不是设计如何满足需求。业务角色那么业务角色是什么？在系统用例图中，您只让参与者与用例进行交互。但在业务用例图中，您可以让业务参与者和业务角色

14、与业务用例进行交互。业务参与者是业务之外的人。它可以是一个角色或其他组织实体。例如，在刑事审判系统中，业务参与者可以是证人、嫌疑犯、外部的政府机构，例如健康效劳，或业务实体，例如，业务资信咨询机构。业务角色是业务内部的某个人或某个部门。在刑事审判系统中，业务角色可以是治安人员、法官、检察官，或假释官。当您实现了一个业务用例，并且创立了时序图和/或 通信图来显示业务参与者、业务角色，和业务实体如何协作执行业务用例时，您将会把业务角色从业务用例模型转入业务分析模型，并且参加所需的额外业务角色来提供业务用例功能。图 1 显示了基于 ISM 工程的例如业务用例图。图 1：ISM 业务用例图 图 1 显

15、示了一个业务参与者：嫌疑犯Suspect。有三个业务角色：执法人Law Enforcement、检察官Prosecutor和法院Court。有四个业务用例：逮捕被告Arrest Subject、请求担保Request Warrant、获得指纹和嫌疑犯照片Capture Fingerprints and Mugshot，以及保释Release on Bail。获取指纹和嫌疑犯照片总是作为来自逮捕被告根底业务用例的强制行为。保释是继承逮捕被告业务用例的可选行为。早先，我讨论了业务用例如何跨越组织边界，许多情况都是这样的。请求担保就是一个好例子。它涉及执法人和法院 。业务用例还可以只集中在一个组织上

16、。获得指纹和嫌疑犯照片就是这样一个好例子。我应该为业务建模使用哪些 UML 图？在我讨论您在业务建模中使用的 UML 图之前，我想说一些关于使用 RSA 和 UML 2.0 创立业务用例图的提示：在 UML 1.x 中，您可以将参与者原型化为业务角色。在 UML 2.0 中，您必须创立一个类，然后将其原型化为业务角色。在 UML 2.0 中，您可以将参与者原型化为业务参与者，但您不能将参与者原型化为业务角色。在 UML 2.0 中，业务用例和业务角色之间的关联是可导航的。业务参与者和业务用例之间的关联是不可导航的。作为最正确实践，我推荐断开业务用例和业务角色之间的导航，从而保持业务角色与业务参

17、与者的一致。业务角色及其用例关联应该按照业务参与者与业务用例通信的同样方式来绘制。您必须在您的工程的 Properties 标签页中选择 Profiles 选项卡，然后单击 Add Profile 按钮，来向您的工程中添加业务建模和健壮性分析原型。在 IBM Rational Rose 中，这是自动包含的。在 UML 2.0 中，概要文件用于包装原型和标记值 UML 扩展。UML 2.0 标准要求您向 UML 建模工程中添加概要文件来使用业务建模原型。UML 业务模型包括两个模型：用例视图Use-Case View中的业务用例模型和逻辑视图Logical View中的业务分析模型。 1 业务用

18、例模型中的主图是业务用例图。您还可以随意参加表示单个业务用例的 UML 活动图，来图形化地显示工作流过程，如图 2 所示，逮捕被告业务用例的活动图。图 2：ISM 逮捕被告业务用例活动图 业务分析模型描述了通过业务角色和业务实体的交互来实现业务用例。它用作业务角色和业务实体需要如何相关联，以及它们需要如何协作，来执行业务用例的抽象。业务分析模型中有三种类型的 UML 图，如图 3 所示：类Class、时序Sequence和通信Communication图。图 3：业务分析模型图 业务分析模型中的主要的图是时序图。您手工地创立显示出业务参与者、业务角色，和业务实体如何交互执行业务用例的时序图。时

19、序图显示出以时间时序安排的对象交互。特别是，它显示出参与交互的对象，以及消息交换的顺序。通信图是以前在 UML 1.x 中所称的协作图Collaboration diagram，它描述了对象之间交互的模式，通过对象间的链接和发送给对方的消息来展示参与交互的对象。通信图和时序图都显示出交互，但它们强调了不同的方面。时序图清楚地显示出时间顺序，但没有明确地显示出对象关系。通信图清楚地显示出对象关系，但必须从顺序号那儿获得时间顺序。两个图都显示出同样的行为，但方式不同。我个人喜欢时序图，因为它通常比拟容易读懂。您还可以使用参与类的视图View of Participating Classes，VOP

20、C来显示协作执行业务用例的业务参与者、业务角色和业务实体的静态视图。图 4 显示出 ISM 逮捕被告业务用例实现的时序图。图 5 显示出 ISM 逮捕被告业务用例实现的 VOPC。图 6 显示出 ISM 逮捕被告业务用例实现的通信图。图 4：ISM 逮捕被告业务用例实现的时序图 在 ISM 逮捕被告业务时序图这局部中，如图 4 所示，有三个从业务用例模型转入的业务角色：执法人、签署者Subscriber和刑事审判系统。刑事审判系统是执法人、法院、检察官，等等的一般化。为了让时序图简单化，我们使用该泛化来表示 ISM 可以使用的任意刑事审判系统。图 4 还显示出引入到业务分析模型中的两个新的业务

21、角色：档案管理系统Records Management System，RMS和 ISM Broker。RMS 通常是商业化成品commercial off-the-shelf，COTS解决方案，它将地方的执法用作刑事案件管理系统。ISM Broker 是 Unisys 方案开发的软件解决方案的自动化候选者或代理。Unisys ISM 解决方案利用中心辐射型 SOA 技术整合了多个各种各样的司法系统，从而在重要决策点处，分享关键任务的数据、文档、图像和事务。ISM 可以在 Microsoft BizTalk Server 或 IBM WebSphere Business Integration

22、上实现。ISM Broker 作为在审判团之中数据共享的导管，并且利用当前的技术来推、拉、发布和订阅信息，从而支持日常的审判操作。图 5：ISM 逮捕被告业务用例实现的 VOPC 图 图 5 中的 VOPC 图显示了参与逮捕被告业务用例的业务参与者、业务角色和业务实体的静态视图。注意为每个业务角色显示的操作。这些操作被称为业务职责。VOPC 图的更精确的名称是参与的业务参与者、业务角色和业务实体的视图View of Participating Business Actors,、Business Workers 和 Business Entities。在本实例中，只有业务角色协作执行业务用例。图

23、 6：ISM 逮捕被告业务用例实现的通信图 如前面所提到的，通信图如图 6 所示是观察时序图中所示行为的另一种方法。RSA 提供了从时序图创立通信图的自动能力，反之亦然。还有一个要答复的问题。业务用例模型和系统用例模型之间的关系是什么？图 7，业务用例到系统用例的向下流动Business to System Use-Case Flow Down，出自我所教授的 IBM Rational 课程“Mastering Requirements Management with Use Cases。图 7，业务用例到系统用例的向下流动 图 7 例举了课程中最难教授的主题之一，因为您要理解该图所需的大局部

24、根底不在标准课程材料之内。本文的其中一个目的是提供额外的根底。图 7 显示了业务模型中所找到的东西和系统用例模型中的东西之间的清晰映射。在此特殊的实例中，可以看出，系统能够将业务角色的职责自动化。它还显示出关键的业务角色是自动化的候选者。记住，业务模型包含业务用例模型和业务分析模型。业务分析模型是业务用例模型的实现，并且拥有紧密的集成化和可追溯性。系统用例模型可以追溯到业务分析模型。业务分析模型可以追溯到业务用例模型。使用该方法，您可以构建从业务分析模型演化来的系统用例模型。这向您的整个 UML 模型提供了一致性和可追溯性。那么系统参与者和系统用例从那里来的呢？系统参与者是根据业务分析模型中的

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

26、例模型中，需要有作为 Loan Specialist 角色的参与者。但是，在我们正在开发的新的软件解决方案中将 Loan Specialist 的一些业务职责自动化了。业务分析模型中的那些业务职责成为了系统用例模型中的系统用例。其他的纯业务角色自动化候选者将不会转换为系统用例模型中的系统角色。这答复了问题，“系统用例是从哪里来的？系统用例是根据业务分析模型中的业务角色自动化候选者的业务职责而创立的。如果您回到图 5，显示了 ISM Broker 的 VOPC 图，每个业务职责，例如 Query for Information，都可以转换为系统用例模型中的系统用例。分析模型显示了业务实体如何映射

27、到系统分析模型中的类上。这些类表示系统将使用的“数据。总结我的目标是概括出 RUP 业务建模和系统用例建模的比拟情况。我讨论了相似点和差异，以及业务用例模型和系统用例模型之间的关系。如果您对这些比拟和关系有任何疑问，可以通过 arthur.englishunisys 联系我。注释1用例视图Use-Case View、逻辑视图Logical View是 UML 4+1 视图模型架构UML 4+1 View Model Architecture的一局部。要了解更多关于 4+1 视图模型架构的信息，您应该学习分析与设计规程中的 URUP 软件架构概念。全程建模业务用例与用例的对应关系解析 收藏 此文

28、于2010-12-16被推荐到CSDN首页如何被推荐？下文中是关于业务用例和用例之间的对应关系的对话，一般来说在一些较大的业务系统或者业务逻辑较为复杂的系统开发中才需要进行单独的业务建模过程，而对于大多数业务系统是不需要单独进行这样的开发阶段的。在每次的全程建模的培训中，青润都会提出这个过程将业务建模过程进行详细的分解，但是在?软件工程之全程建模实现?一书中对业务建模并没有进行深入的阐述。下文中的系统用例在青润的定义中一般就称之为用例，而系统用例这个名词用于非业务性相关用例的命名，比方用户管理，码表分类定义 / 管理之类的非用户原有业务需求产生的用例上，或者称之为支撑业务用例而不得不构建的用例被称之为系统用例。所以在这里单独进行明确，以便于大家的区分。业务用例和用例的对应关系一般是 1 对 1 和 1 对多最为普遍，但是也可能出现多对 1 的形式，甚至一些用户业务间交叉过多的业务实现中还可能出现多对 1 的形式。比方下面这个例子就是 2003 年底在北航给软工硕士讲课期间产生的一张图，此图的模型也在?一书的光盘中可以找到：下面是相关的对话内容，有助于对以上内容的进一步理解。缘，妙不可言 21:32:59 UML 中，我本来认为业务用例和系统用例的关系是一对多，因为系统用例是从业务用例场景中推导出来