商务参考体系结构：企业对消费者 (B2C电子商务实践) 第 3 章：逻辑设计阶段

商务参考体系结构：企业对消费者

第 3 章：逻辑设计阶段
Microsoft Corporation
2001年5月

摘要：本章描述 Microsoft 解决方案框架 (MSF) 设计流程的逻辑阶段。在此阶段，设计小组要根据概念设计在组件应用和集成方面作出高级的决定。设计小组将使用应用方案（在概念阶段开发）来构建应用程序的逻辑模型。

在此阶段结束时，设计小组应已开发出逻辑设计，此设计是工程实际设计阶段的基础。

简介

逻辑阶段的目标是将概念阶段定义的功能转化为一个抽象模型，以确定将用于支持解决方案的协作逻辑组件。

所生成的逻辑设计并不涉及具体的技术。相反，此阶段的目标是在开展任何技术工作之前对功能性进行分析和了解。例如，当一个小组在逻辑阶段设计电子商务解决方案时，可能认为名为 Users 的组件是必需的服务，用以对访问应用程序的用户组进行跟踪。但在实际设计阶段，设计小组可能会选择使用 Microsoft® Commerce Server 2000。这种情况下，Commerce Server 中的 MSCSProfileService 组件提供了 Users 组件的实际实施方案。

如果最终应用程序设计包括定制组件（即未在现成的解决方案或产品中提供的组件），就可以将逻辑阶段确定的相应组件直接转换到实际阶段中。例如，在逻辑阶段定义了 Users 对象，而设计小组决定使其成为定制对象，那么 Users 对象就将在实际阶段中重复。

本章的其余部分将概述在设计 ConsolidatedRetail.com 时使用的逻辑设计流程，然后详细说明满足应用方案要求所需的逻辑组件。

创建逻辑设计

创建逻辑应用设计的第一步是确定将提供所需功能的业务对象（组件）。除了确定所需对象之外，设计小组还必须确定各个对象具有的行为、属性和关系。设计小组将使用在概念阶段创建的应用方案来确定这些对象及其关系、行为和属性。

例如，以下是应用方案 3：

用户选择要浏览的目录。显示所选目录的根中的各类别和各产品。然后，用户可以选择要查看其细节的产品，或选择一个类别，查看所选类别中的各产品和各子类别。

这样，设计小组将通过分析此方案来确定支持解决方案的各个方面，并执行以下任务：

1. 确定此方案中的业务对象。
   
   
2. 确定这些对象的行为。
   
   
3. 确定这些对象的属性或特性。
   
   
4. 确定这些对象之间的逻辑关系。

这些任务将在本章的后面小节中进行更为详细的描述。

当完成每个应用方案的这些任务并将其归档后，设计小组就可以结束逻辑设计阶段。有关 ConsolidatedRetail.com 应用的完整设计示例，请参考“完成的逻辑设计”一节。

统一建模语言

统一建模语言 (Unified Modeling Language, UML) 是一种用于描述系统运行方式的工具。在直观地描述系统以对其进行更为全面的分析时，UML 是非常有用的工具。通过使用 UML，可以很方便地用图表说明组件、交互操作、关系等等。

UML 通常用于在逻辑阶段简化对设计的分析。

为了说明创建逻辑设计所涉及的任务，以下各节将提供简单 UML 图表示例。

确定对象

当分析应用方案时，首要任务是确定其中的对象。对象通常是在应用方案中出现的业务实体或过程。例如，在以下段落中，对象将以粗体标识：

user（用户）选择要浏览的 catalog（目录）。显示所选 catalog（目录）的根位置中的 categories（各类别）和 products（各产品）。然后，user（用户）可以选择要查看其细节的 product（产品），或选择一个 category（类别），查看所选 category（类别）中的 products（各产品）和子类别。

上例使用了以下对象：

• User
  
  
• Catalog
  
  
• Categories
  
  
• Product
  
  
• Products

图 3-1 是描述此示例中所确定的对象的 UML 图：

图 3-1：对象

这五个对象成为此方案的基本对象；不过，在有些情况下，要使方案起作用，还需要添加其他对象，即使这些对象未在方案中明确列出。通过检查没有明显的对象与其相关联的行为，即可确定这些附加对象。要确定这些对象，必须首先确定其行为。

确定行为

当确定明显的对象组后，下一步是确定其各自的行为，这些行为也称作“方法”或“服务”。

要确定对象行为，必须首先确定在方案中执行的操作。例如，在以下段落中，动作将以粗体标识：

用户选择要浏览的目录。显示所选目录的根中的各类别和各产品。然后，用户可以选择要查看其细节的产品，或选择一个类别，查看所选类别中的各产品和子类别。

第一项动作是用户选择目录。图 3-2 是一个 UML 图，它将 User（用户）对象描述为具有 Select Catalog（选择目录）行为：

图 3-2 User 对象的行为

如先前所述，必须从方案中派生没有明显的对象与其相关联的行为。我们从而可以想到，由于用户选择了目录，所以必然有某种允许从目录列表中选择目录的机制。这样，您可以从逻辑上假定 Catalogs 对象存在，它管理所有的 Catalog 对象。然后，应该将这一新对象添加到已定义对象的列表中。

当定义“Catalogs”对象后，可以将第一项动作定义为 Select Catalog（选择目录），此行为属于“Catalogs”对象。

您可以继续分析方案中的每个句子，直至确定所有的征询对象及其关联行为。

确定属性

当确定行为后，下一步是确定所定义对象的属性（也称作“特性”）。属性是解决方案需要跟踪的元素。它们是用于保留（或“存留”）数据的占位符。

属性派生的方法是，分析方案中的行为并提取需要存留（或跟踪）的元素。例如，在上一节中，应用方案指定用户将能够查看产品。当查看产品时，显示给用户的元素将成为产品的属性。例如，如果业务要求显示产品规格和价格，这些元素就会成为对象的属性。

图 3-3 是一个 UML 图，显示具有 Name 属性的 User 对象：

图 3-3：User 对象的属性

确定关系

确定对象及其属性后，下一步是确定“关系”。关系是对象之间的逻辑关联。

要确定关系，必须分析对象之间的交互方式。例如，“Categories”对象与“Category”对象具有关系，因为“Categories”对象管理“Category”对象的集合并包含“Category”对象。

务必要注意，另外有一种名为 inheritance（继承）的关系，它专门处理一个对象由另一个对象定义的情况。例如，如果所设计的解决方案要销售食品和书籍，但又需要在逻辑上将这两者区别开，则可以定义这样一种关系：“Book”和“Food”对象都属于一种“Product”对象。这样，它们都可以继承“Product”对象。

在商务参考体系结构解决方案中，未在逻辑阶段定义任何继承关系。但在有些电子商务解决方案中，这些关系可能非常重要。

完成的逻辑设计

在参考体系结构应用 ConsolidatedRetail.com 的逻辑设计阶段，设计小组确定了以下对象，它们组成了支持解决方案所需组件的抽象集合。（这些对象按字母顺序排列，而不是按使用顺序排列。）

Authentication

Authentication 对象处理用户的注册和身份验证。

Catalog

Catalog 对象存留特定目录的信息并管理该目录内产品的集合。

Catalog Manager

Catalog Manager 对象管理目录的集合。

Category

Category 对象存留有关特定类别的信息。

Category Manager

Category Manager 对象管理类别的集合。

Configuration

Configuration 对象存留应用配置信息并处理与配置相关的任务。

Data Functions

Data Functions 对象执行特定于数据的功能，如打开与数据库的连接。

E-mail

E-mail 对象用于向用户发送电子邮件消息，如订单确认消息。

Error Handler

出错时将调用“Error Handler”对象。它处理用户友好的错误转换和日志错误。

Order

Order 对象存留有关特定订单的信息。

Product

Product 对象存留有关特定产品的信息。

Search

Search 对象用于搜索目录并返回产品搜索的结果。

User

User 对象用于存留特定用户的有关信息。此外，它还管理所有的用户订单。

User Manager

User Manager 对象管理用户的集合。

图 3-4 演示了主要对象之间以及主要对象与第二章所述的用例之间的关系

图 3-4：对象关系

总结

本章说明了确定组成电子商务应用的对象（即业务组件）及其属性、行为和相互关系的四步骤流程。此流程的最终结果是创建出将用作技术设计和规范基础的逻辑设计。

要注意，所生成的逻辑设计并不涉及具体的技术。这些技术将在实际设计阶段确定，这是下一章讨论的主题。