业务用例和系统用例

"业务用例：业务过程是描述这个业务的具体工作流的；一次涉众与实现业务目标的业务之间的交互。它可能包含手工和自动化的过程，也可能发生在一个长期的时间段中。"

 

系统用例的设计范围就是这个计算机系统设计的范围。它是一个系统参与者，与计算机系统一起实现一个目标。系统用例就是参与者如何与计算机技术相联系，而不是业务过程。着重系统的控制流、数据流和功能。

 

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

• 两者都有参与者。在业务用例图中，您将一个参与者原型化为 <<BusinessActor>>。
• 两者都有用例。在业务用例模型中，您将一个用例原型化为 <<BusinessUseCase>>。
• 在参与者与用例之间两者都有一个通信关联。
• 业务用例和系统用例都能够包含、扩展，以及一般化关联。

业务用例着重于业务操作。它们表示实现业务目标的业务中的具体工作流。业务过程可能涉及手工和自动过程，并且在一段长期的时间内进行。

系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互？我们在系统用例说明中书写的事件流应该足够详细，从而用作编写系统测试脚本的出发点。

 

业务用例常常是以白盒形式编写的。它们描述了被建模的组织中的人和部门之间的交互。我们使用业务用例来说明在“现有”业务模型中组织如何工作。然后我们重构“现有”的业务用例模型，让其面向将要建模的组织的未来设计。我们需要创建什么新角色和部门来提供更多价值，或者消除业务问题？什么角色和部门需要消失？

系统用例几乎总是以黑盒形式编写的。它们描述了软件系统之外的参与者如何与将被设计的系统进行交互。系统用例详细阐明了系统需求。系统用例模型的目的是从涉众的角度说明需求，而不是设计如何满足需求。

 

在系统用例图中，您只让参与者与用例进行交互。但在业务用例图中，您可以让业务参与者和业务角色与业务用例进行交互。

业务参与者是业务之外的人。它可以是一个角色或其他组织实体。例如，在刑事审判系统中，业务参与者可以是证人、嫌疑犯、外部的政府机构，例如健康服务，或业务实体，例如，业务资信咨询机构。

业务角色是业务内部的某个人或某个部门。在刑事审判系统中，业务角色可以是治安人员、法官、检察官，或假释官。当您实现了一个业务用例，并且创建了时序图和/或 通信图来显示业务参与者、业务角色，和业务实体如何协作执行业务用例时，您将会把业务角色从业务用例模型转入业务分析模型，并且加入所需的额外业务角色来提供业务用例功能。

 

UML 业务模型包括两个模型：用例视图（Use-Case View）中的业务用例模型和逻辑视图（Logical View）中的业务分析模型。 ¹ 业务用例模型中的主图是业务用例图。您还可以随意加入表示单个业务用例的 UML 活动图，来图形化地显示工作流过程。--即静态建模和动态建模。

 

业务分析模型描述了通过业务角色和业务实体的交互来实现业务用例。它用作业务角色和业务实体需要如何相关联，以及它们需要如何协作，来执行业务用例的抽象。业务分析模型中有三种类型的 UML 图，类（Class）、时序（Sequence）和通信（Communication）图（即协作图）。

 

业务分析模型中的主要的图是时序图。您手工地创建显示出业务参与者、业务角色，和业务实体如何交互执行业务用例的时序图。时序图显示出以时间时序安排的对象交互。特别是，它显示出参与交互的对象，以及消息交换的顺序。

通信图是以前在 UML 1.x 中所称的协作图（Collaboration diagram），它描述了对象之间交互的模式，通过对象间的链接和发送给对方的消息来展示参与交互的对象。通信图和时序图都显示出交互，但它们强调了不同的方面。时序图清楚地显示出时间顺序，但没有明确地显示出对象关系。通信图清楚地显示出对象关系，但必须从顺序号那儿获得时间顺序。

两个图都显示出同样的行为，但方式不同。我个人喜欢时序图，因为它通常比较容易读懂。您还可以使用参与类的视图（View of Participating Classes，VOPC）来显示协作执行业务用例的业务参与者、业务角色和业务实体的静态视图。

 

 

VOPC 图显示了参与逮捕被告业务用例的业务参与者、业务角色和业务实体的静态视图。注意为每个业务角色显示的操作。这些操作被称为业务职责。VOPC 图的更精确的名称是参与的业务参与者、业务角色和业务实体的视图（View of Participating Business Actors,、Business Workers 和 Business Entities）。

 

 

业务模型包含业务用例模型和业务分析模型。业务分析模型是业务用例模型的实现，并且拥有紧密的集成化和可追溯性。系统用例模型可以追溯到业务分析模型。业务分析模型可以追溯到业务用例模型。