指南:从业务模型到系统
本指南显示如何从业务模型派生出系统的用例和分析模型。
关系
主要描述

简介

Rational Unified Process 中提供的业务建模的方法包括一种简明直接的方式,用于为支持业务工具或系统生成需求。对业务流程的较好理解对于构建正确的系统非常重要。如果您使用人员的角色和职责以及对业务所处理对象的定义来作为构建系统的基础,则这个模型将更有价值。正是从这种在业务分析模型中捕获的更内部的业务视图中,您可以看到与系统模型需要是什么样的最紧密联系。

附带文本中描述的图。

业务模型和支持信息系统模型之间的关系

业务模型和系统体系结构

从体系结构角度看,如果您的目的是构建以下种类的系统之一,则具有适当的业务模型尤其有用:

  • 为特定行业类型中的一家或多家公司(如银行和保险公司)定制的系统。
  • 用于开放市场的系列应用程序,例如订单处理系统、开票系统和空中交通控制系统。

这些业务模型向分析模型中显示的用例视图和逻辑视图提供输入。您也可以发现分析层的关键机制,称为分析机制。

应考虑以下事项:

  • 对于将由该系统支持的每个业务用例,在分析模型中确定一个子系统。该子系统处于应用层,并被视为一个第一原型迭代。例如,如果在您的业务用例模型中有一个“订单”流程和“开票”流程,则在您的分析模型的应用层中确定一个“订单”子系统和一个“开票”子系统。您可能要争辩说“订单”和“开票”是两个独立的系统。那是一个范围的问题。如果 您正在将所有业务工具视为具有共享体系结构的若干应用程序的一个系统,则“订单”和“开票”将是应用程序子系统。如果您的范围是仅构建一个“订单管理”应用程序,则“订单管理”将是您的系统,上述建议就没有意义了。它只有在您的范围是将贵组织中的所有业务工具都视为一个系统时才有意义。
  • 对于该系统支持的每个业务工作者,确定代表要自动化的内容的用例。
  • 对于该系统支持的每个业务实体,在分析模型中确定实体类。它们中的一些是视为系统中关键机制即组件实体的候选类。
  • 对于业务实体的群集(一组仅在一个业务用例内使用的业务实体或一组以其他方式紧密相关的业务实体),在特定于业务的层中创建一个子系统。

附带文本中描述的图。

在一个四层系统体系结构中,业务模型向前两层提供输入

业务模型和系统的参与者

附带文本中描述的图。

对于每个业务工作者,确定一个候选系统参与者。对于业务工作者参与的每个业务用例,创建一个候选系统用例。

要确定信息系统用例,请从业务分析模型中的业务工作者开始。

对于每个业务工作者,执行以下步骤:

  • 确定该业务工作者是否将是使用信息系统的人。
  • 如果是,则在该信息系统的用例模型中为该业务工作者确定一个参与者。先创建一个与业务工作者名称相同的参与者。
  • 对所有业务工作者重复这些步骤。

对于每个业务用例实现,请执行以下步骤:

  • 确定由系统参与者(在前面的步骤中确定的)启动的步骤序列。
  • 为每个步骤序列创建一个系统用例。先使用启动步骤名称(操作名称)作为用例名称。
  • 确保该系统用例符合系统用例的所有标准(向参与者提供有意义的值等)。按需要合并或进一步分割系统用例。

请注意这仅是系统用例模型的起点。当更好地理解从系统角度而言的需求时,这些初始系统参与者和用例将按需要重构。

示例:

下图给出了一个关于如何得出“申请贷款”业务用例实现的系统用例的示例。图中的虚线标记将考虑的系统的边界。

附带文本中描述的图。

基于一家银行的业务模型,您可以得出候选的系统参与者和系统用例。

自动化业务工作者

如果您的目的是构建完全自动执行一组业务流程的系统(例如,如果您在构建一个电子商务应用程序,就是这种情况),则不再是将成为系统参与者的业务工作者。相反,是将直接与系统通信并充当系统参与者的业务工作者。

实际上,当您在构建此类应用程序时,您是在更改执行业务的方式。该业务工作者的职责将转移给业务参与者。

示例:

当为一家银行构建一个电子商务站点时,您将修改实现流程的方式。

  • “职员”的职责将转移给“客户”。

  • 创建一个对应于业务参与者“客户”的系统参与者“客户”。

  • “职员”和“贷款系统”业务工作者将合并成为“增强的贷款系统”业务工作者(这在下图中以虚线表示)。

  • 按照这个新的业务工作者修改业务用例实现。

  • 基于修改后的业务用例实现,确定新的系统用例,或改编现有的系统用例。通常合并的业务工作者之间的操作会成为新的或更新过的系统用例中的步骤。

附带文本中描述的图。

将业务工作者完全自动化将更改实现业务流程的方式以及您查找系统参与者和用例的方式

分析模型中的业务模型和实体类

附带文本中描述的图。

对于每个业务实体,在系统的分析模型中创建一个类

要由信息系统管理的业务实体将对应于信息系统的分析模型中的实体。但是,在一些情况下,让该业务实体的属性对应于信息系统模型中的实体,可能比较合适。几个业务工作者可以访问一个业务实体。因此,系统中对应的实体可以参与几个信息系统用例。

示例:

附带文本中描述的图。

业务实体“客户概要信息”、“帐户”和“贷款”都是自动化的候选者。

业务事件

业务事件确定业务中重要的状态发生或更改。它们用于分离业务用例并发送关于状态发生或更改的通知或触发器。这样,它们是业务流程自动化(以减少业务工作者之间的交互和加速业务用例)的极好来源。自动执行业务事件允许在整个业务中迅速传播重要信息,而不会增加具有此职责的业务工作者的负担。

示例:

例如,在军事行动中涉及的所有单位可能需要在友军(或敌军)声称战略优势点时立即得到通知。如果没有自动化,该业务可能要通过以特定的无线电频率广播密码(例如礼帽)来实施。可能会使接收到密码的所有人采取必要的措施(例如进入战役的下一个阶段)。自动执行此业务事件可以允许更有效地通知该事件,并且也可能自动执行对该事件的不同响应。

业务工作者之间的交互转换为系统需求

应当如何解释业务模型中角色之间的联系?您必须找出信息系统如何支持通信的角色。信息系统可以通过在信息系统中提供信息而使您无需在角色之间传输信息。

使用业务分析模型进行资源规划

如果您要使用业务分析模型进行资源规划或作为仿真的基础,您将需要更新它以反映使用的是哪些类型的资源。您需要修改它使每个业务工作者和业务实体仅由一个类型的资源实施。如果您的目的是重新设计业务流程,则在业务分析模型的第一个迭代中,您不应考虑资源。这样做会倾向于使您专注于已经存在的解决方案,而不是确定可以使用新类型的解决方案解决的问题。下面是一个要考虑的过程的示例:

  • 在业务分析模型的第一个迭代中,不考虑将用于实施该业务的资源或系统。
  • 讨论可以自动化的内容。
  • 讨论自动化可以如何更改业务流程并开始勾勒系统用例模型和系统需求。
  • 在业务分析模型的第二个迭代中,更新它以反映使用的资源以及要自动化的内容。
    • 一些业务工作者将被标记为自动化角色。
    • 一些业务工作者将被分为两个 - 一个自动化,另一个不自动化。
    • 两个业务工作者的若干部分可以分出一个新的自动化角色。
    • 业务 角色的职责的若干部分可以移出组织以成为一个业务参与者的职责。

    示例:

在银行示例中,我们决定更新业务分析模型以使用它进行资源规划。

  • “职员”业务工作者被完全自动化,并成为“自动化职员”。银行将只进行在线银行业务。

  • “贷款专员”被部分自动化,并分为“自动化贷款专员”和“贷款专员”。

附带文本中描述的图。

业务工作者被修改以反映自动化

总结表

下表总结了业务模型和系统模型之间的关系。

系统模型 如何使用业务模型中的信息查找候选者 业务模型
参与者 在业务工作者中发现候选参与者。 业务工作者
参与者 在将直接使用系统的不同业务工作者(客户、供应商)中发现其他候选参与者。 业务参与者
用例 在业务工作者的操作中发现候选用例。查找与信息系统交互的操作和职责领域。理想情况下,一个信息系统用例支持一个业务模型用例实现内所有业务工作者的操作。 业务工作者的操作
实体类 在业务实体中发现候选实体类。查找应在信息系统中维护或表示的业务实体。 业务实体
实体类 在业务分析模型中的属性中发现候选实体类。查找应在信息系统中维护或表示的属性。 属性
实体类之间的关系 业务实体之间的关系通常表示信息系统模型中的类之间的相应关系。 业务实体之间的关系