指南：从业务模型到系统

主题

• 简介
• 业务模型和系统构架
• 业务模型和系统主角
• 自动业务角色
• 业务模型和分析模型中的实体类
• 业务角色之间的交互转化为系统需求
• 使用业务对象模型进行资源计划
• 摘要表

简介

Rational Unified Process 介绍的业务建模方法中包括为支持业务工具或系统生成需求的方法。这种方法简明而直接。很好地理解业务流程对于构建正确的系统至关重要。如果您使用人员的角色和职责，以及业务所处理对象的定义作为构建系统的基础，这个模型将更有价值。正是通过这种对业务更加深入的内部分析（在业务对象模型中表示），才能了解它与系统模型最紧密的关系。

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

业务模型和系统构架

从构架的角度来看，如果您要构建的系统属于以下类型，那么具有适当的业务模型会十分有用：

• 为某个特殊行业的一个或多个公司专门定制的系统，例如银行和保险公司。
• 用于开放市场的一系列应用程序，例如订单处理系统、结帐系统和航空管制系统。

业务模型为分析模型中给出的用例视图和逻辑视图提供输入。您还可以在分析级别上找到核心机制（称为分析机制）。

应该考虑以下几点：

• 对于每个将被系统支持的业务用例，在分析模型中确定一个子系统。子系统处于应用程序层中，我们把它看作基本的原型迭代。例如，如果业务用例模型中有一个订单流程和一个结帐流程，您就应该在分析模型的应用程序层确定一个订单子系统和一个结帐子系统。您可能会认为订单和结帐都是独立的系统。没错，但这只是规模的问题。如果您把所有业务工具看做一个具有多个应用程序（这些应用程序共享构架）的系统，那么订单和结帐就是应用程序子系统。但如果您只是要构建一个“订单管理”应用程序，那么“订单管理”就是整个系统，前边的建议就没有意义了。只有当您将组织内的所有业务工具看做一个系统时，这种做法才有意义。
• 为系统所支持的每个业务角色确定用例来表示需要自动化的对象。
• 为系统所支持的每个业务实体在分析模型中确定实体类。其中一部分作为系统中的候选核心机制（即构件实体）。
• 在业务专用层中为业务实体簇创建一个子系统，业务实体簇是指一组只用于一个业务用例的业务实体，或者一组紧密联系的业务实体。

在一个四层的系统构架中，业务模型为顶部两层提供输入

业务模型和系统主角

为每个业务角色确定一个候选的系统主角。为该业务主角参与的每个业务用例创建一个候选系统用例。

为了确定信息系统用例，从业务对象模型中的业务角色着手。对每个业务角色执行以下步骤：

• 确定业务角色是否需要使用信息系统。
• 如果需要，在信息系统的用例模型中为信息系统确定一个主角。赋予该主角与业务角色相同的名称。
• 为业务角色参与的每个业务用例创建一个系统用例。
• 对所有业务角色重复这些步骤。

示例：

基于银行业务模型，您可以导出候选的系统主角和系统用例。

自动业务角色

如果您要构建一个系统来完全自动地完成一套业务流程，例如当您要构建一个电子商务应用程序时，业务角色将不再成为系统主角。此时，业务主角将直接和系统进行通信并成为系统主角。

当构建这样一个应用程序时，您实际上改变了业务执行的方式。业务角色的职责将转移到业务主角。

示例：

当为某个银行构建电子商务站点时，您将改变流程实现的方式。

• 职员 (Clerk) 的职责将转移到客户 (Customer)。

• 创建一个相当于业务主角“客户”的系统主角“客户”。

• 移去系统主角“职员”。

• 相应修改系统用例货币交易 1 (Money Transaction 1) 来配合系统主角“客户”，而不再是以前的“职员”。

对业务角色的完全自动化改变了业务流程实现的方式，也改变了您查找系统主角和用例的方法。

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

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

信息系统管理的每个业务实体都将与信息系统分析模型中的一个实体相对应。但有时候，让业务实体的属性与信息系统模型中的实体对应会更合适。可以有多个业务角色访问一个业务实体。因此，系统中对应的实体可以参与到多个信息系统用例中。

示例：

业务实体客户简档 (Customer Profile)、帐户 (Account) 和贷款 (Loan) 都将进行自动化。

业务角色之间的交互转化为系统需求

您如何理解业务模型中角色间的关系？您必须了解信息系统是如何支持角色进行通信的。由于在整个信息系统中都可以得到信息，这样就避免了角色之间的信息传输。

使用业务对象模型进行资源计划

如果要使用业务对象模型进行资源计划，或用作模拟的基础，您应该对模型进行更新以反映所使用资源的类型。您需要对其进行修改，让每个业务角色和业务实体只由一种类型的资源实施。如果要在业务对象模型的第一次迭代中重建业务流程，则不需要考虑资源。这样做使您更多地关注现有的解决方案，而不是去确定那些可以使用新解决方案解决的问题。以下是一个考虑过程的示例：

• 在业务对象模型的第一次迭代中，不考虑将用于业务实施的资源或系统。
• 讨论哪些部分可以实现自动化。
• 讨论自动化将如何改变业务流程，开始草拟系统用例模型和系统需求。
• 在业务对象模型的第二次迭代中对其进行更新，使之可以反映所使用的资源和要实现自动化的部分。
  • 某些业务角色将被标注为自动角色。
  • 某些业务角色将被一分为二 - 一个是自动的，另一个不是自动的。
  • 两个业务角色的某些部分可以分离出来形成一个新的自动角色。
  • 业务角色的部分职责可以移出组织，成为某个业务主角的职责。

  示例：

在银行这个示例中，我们决定更新业务对象模型，将其用在资源计划中。

• “职员”业务角色完全自动化，成为一个自动职员 (Automated Clerk)。银行将只进行在线业务。

• 贷款专家 (Loan Specialist) 实现了部分自动化，分成自动贷款专家 (Automated Loan Specialist) 和贷款专家 (Loan Specialist)。

修改业务角色以反映自动化

摘要表

下表对业务模型和系统模型之间的关系进行了概括。

系统模型	如何利用业务模型中的信息查找备选对象	业务模型
主角	在业务角色中找到备选主角。	业务角色
主角	在直接使用系统的不同业务主角（客户、厂商）中找到其他备选主角。	业务主角
用例	在业务角色的操作中找到备选用例。查找操作和职责区域，这些操作和职责区域应该涉及与信息系统进行的交互。理想情况下，一个信息系统用例可以支持一个业务模型用例实现中的所有角色操作。	业务角色的操作
实体类	在业务实体中找到备选实体类。查找应该在信息系统中维护或表示的业务实体。	业务实体
实体类	可以在业务对象模型的属性中找到备选实体类。查找应该在信息系统中维护或表示的属性。	属性
实体类之间的关系	业务实体之间的关系常常表示信息系统模型中的类之间存在相应的关系。	业务实体之间的关系