基于统一场景的设计: 从概念到实践
这篇文章是本系列文章的完结篇，它描述了用于方法学的 UML 扩展和支持工具。本文将关注点放在支持 USBD （基于统一场景的设计）的工具上面，也就是将用于 IBM® Rational® Software Architect 版本 7 以及后续版本的 IBM® WebSphere® Business Modeler 集成特性，以及一组 UML 2.0 的扩展放置到一组 UML 规范之中。这其中包括一个 UML 2.0 规范以及一个帮助创建 Business Model、Business Analysis Model、Use Case Model 和 User eXperience Model 的模型模板。
入门简介
在本系列前面的几篇文章中，我们已经描述了一个基于基于场景的设计（Scenario Based Design，SBD） 和 Outside-In Design （OID） 的一个有效的统一设计方法论。该方法论被称作 基于统一场景的设计 （USBD）。它的关注点在于产品所处的点对点的业务环境，而不是仅仅描述围绕在单一产品周围的业务场景。通过描述业务需要和软件执行之间的链接方式，这 些文章大致描绘出了通过处理过程路线图、目标和类图表捕获业务处理过程的方式，以及如何根据实际执行来跟踪他们。本系列文章还描述了一种用户接口同系统分 析相链接的正式的表示法。
本文将关注点放在支持 USBD （基于统一场景的设计）的工具上面，也就是：
- 用于 IBM® Rational® Software Architect 版本 7 及其后续版本的 IBM® WebSphere® Business Modeler 综合特性。
- 被捕获到一组 UML 规范中的一组 UML 2.0 扩展。
WebSphere Business Modeler 综合特性是同 Rational Software Architect 相伴而来的，并且被用作讲一个在 WebSphere Business Modeler 中被开发的的业务模型导入到 Rational Software Architect 之中。这一特性还包括一个被称作 IBM® WebSphere® Business Integration Modeler Nav Tree Profile 的 UML 规范，它提供了能够自动被应用于在导入期间被转换的 UML 类、接口和其他元素的 UML 模板。
Rational Software Architect 包括另一个被称作 Business Modeling Profile 的 UML 规范，它提供了进一步加强业务模型的其余一组 UML 模板。
为了通过特定于 USBD （基于统一场景的设计）方法论的概念来补足这两个规范，IBM 开发了另外一个规范，即用于 USBD 的 UML 2.0 规范。它定义了另外一组模板，当它们被应用到类时，接口以及其他的模型元素都根据 USBD 概念来表现它们。该规范将和 IBM® Rational® Software Delivery Platform （例如：IBM® Rational Software Modeler 或者 Rational Software Architect）一起被使用。
下一小节将讨论 USBD （基于统一场景的设计）的概念，在后面的小节中，我们将描述如何通过前面所提到的三种规范来刻画这些概念。
USBD （基于统一场景的设计）元模型
本小节将通过一个元模型帮助您更好地理解 USBD 方法论。这个模型描述了您使用 USBD 方法论在软件设计（包含业务、用户和系统）及其相互关系中将会捕获到的概念。该模型包括 USBD 的分类法和存在论。
用户、目标、处理过程、用户接口面板等概念都被放到一起，它们之间的关系通过一个模型来确定和描述。该元模型描述了实际的模型将如何使用 USBD 方法论。下一小节描述了被用来支持这些概念建模以及 USBD 模型结构的实际的 UML 扩展。
图 1 和图 2 分别显示了完整的元模型图表的左右两个部分。
图 1：对业务处理过程进行建模。 
图 2: 根据业务上下文环境获得系统的需求和行为。 
关于这些图表，正如在本系列的前几篇文章中我们所看到的：
- 一个 Business Process Map （业务处理过程路线图）包括一组 Business Processes （业务处理过程）。
- Business Processes （业务处理过程）同 Business Actors （业务活动者）所开启的 Business Use Cases （业务用例）是一一对应的。
- Business Event （业务事件）是一种特殊的 Business Actor （业务活动者），它也能够开启 Business Use Cases （业务用例）。
- 一个特定的 Business Process Realization （业务处理过程实现）就是 Business Roles （业务角色）执行一组 Business Process Activities （业务处理过程活动）。
在一个更低的层次上，重复着同样的逻辑结构（或者结构模式）：
- 业务处理过程活动同业务角色所开启的业务处理用例是一一对应的。
- 业务处理用例的存在支持业务目标。
- 业务目标是由您的客户来制定的，并且可以通过测量来被评价。
- 一个特定的业务处理活动实现就是业务工作者执行一组业务处理任务（生产、消费、交换业务实体等）。
- 业务实体同样在一个更高层次上作为实体在业务处理实现之间被交换。
- 由业务工作者所完成的任何一个这样的实现都是一种真实描述一个业务场景的交互作用。
在业务层和系统层之间，有两条链接。
- 业 务工作者在一个场景中所执行的某些活动，甚至是所有的活动，都能够被自动地执行。USBD 最佳实践建议：每一项在业务处理过程活动实现中被自动执行的操作都确定了一个系统活动者（即调用该操作的一方）以及一个系统（即操作提供者），并且能够被 映射到一个相应的用例实现上。
因此，每一个被选中为自动执行的业务工作者操作，都映射到系统层上面一个相应的用例实现。当然，这个用例实现链接到它所实现的用例上面。 - 与此同时，一个用户（一个特定类型的系统活动者）扮演一个业务角色（或者该场景中的业务工作者），并且使用一个系统来执行相应的操作。
您能够在图 1 和图 2 中看到业务工作者（及其操作）和业务角色，并且他们表现了业务层和系统层之间的链接。
但是当系统活动者是一个真实的用户的时候，还有系统设计的另一个方面开始活动。
- 进入用户经验的领域，您希望以有目标的角色的形式捕获到用户原型。
- 除此之外，您还需要设计用户接口，图 2 显示了如何做。
- 用例情节串联模板提供了另外一种描述用例实现的方式。情节串联模板描述了实现用例的用户接口元素的导航，从而支持相应的用户目标。
UML 2.0 扩展
表 1 描述了被引入到 UML 2.0 中的支持 USBD （基于统一场景的设计）概念建模的扩展。Business Modeling UML 2.0 规范是由 Rational Software Architect 的版本 7 引入的，与此同时，WebSphere Business Integration Modeler Nav Tree Profile 同 WebSphere Business Modeler 集成在了一起。
下面各小节将向您展示如何向模型中添加所有需要的规范。
表 1：UML 2.0 扩展以及它们到元模型中概念上的映射。
| 参与者 | 参与者 | - | ||
| 业务参与者 | 参与者 | <BusinessActor> | 业务建模 | |
| 业务实体 | 类 | <BusinessEntity> | 业务建模 | |
| 业务事件 | 信号 | <BusinessEvent> | 业务建模 | |
| 业务目标 | 类 | <BusinessGoal> | 业务建模 | |
| 业务过程 | 协作 | <Process> | <KernelProcess> | <OptionalProcess> | <AlternativeProcess> | WBI Modeler Nav Tree Profile | USBD | 活动图 |
| 业务过程活动 | 调用行为活动 | <BusinessProcessActivity> | USBD | |
| 业务过程活动实现 | 协作 | <BusinessProcessActivityRealization> | USBD | 时序图 |
| 业务过程路线图 | 协作 | <BusinessProcessMap> | USBD | 活动图 |
| 业务过程实现 | 协作 | <BusinessProcessRealization> | USBD | 活动图 |
| 业务过程任务 | 消息, 操作 | N.A. (针对消息), <BusinessProcessTask> | <BusinessService> (针对操作) | USBD | 业务建模 | |
| 业务过程用例 | 用例 | <BusinessProcessUseCase> | USBD | |
| 业务角色 | 类, 活动划分 | <BusinessRole> (针对类), N.A. (针对活动划分, 使用 "Represents") | USBD | |
| 业务用例 | 用例 | <BusinessUseCase> | 业务建模 | |
| 业务执行者 | 接口 | <BusinessWorker> | 业务建模 | |
| 客户涉众 | 参与者 | <CustomerStakeholder> | USBD | |
| 度量 | 属性 | <Measure> | USBD | |
| 操作 | 操作 | - | ||
| 人物 | 类型 | <PrimaryPersona> | <SecondaryPersona> | USBD | |
| 用例 | 用例 | - | ||
| 用例实现 | 协作 | <realization> | 标准 | 活动图 |
| 用例情节板 | 协作 | <Storyboard> | USBD | 状态机图|时序图 |
| 用户 | 参与者 | <User> | USBD | |
| 用户目标 | 类 | <UserGoal> | USBD | |
| 用户接口元素 | 类, 状态 | <UIElement> | USBD |
用于基于统一场景设计的 UML 2.0 规范
图 3 显示了用于 USBD （基于统一场景的设计）的 UML 2.0 规范的新模板。表 1中并没有列出所有的模板。这些仅仅是当您将模型中的元素组织到不同包之中时除了由 WebSphere Business Integration Modeler Nav Tree Profile 所提供的模板之外的其他可选的模板。正如示例模型将要说明的那样，用更加具有描述性的包组织一个模型将大大增强它的可用性。
为了能够在规范中使用模板，您需要将其安装到 Rational Software Architect 之中。
安装用于 USBD （基于统一场景的设计）的 UML 2.0 规范
您应当首先在 下载 一节中下载档案文件，并且将其解压缩到本地。然后，您就能够使用通常的操作步骤来安装规范，从而将插件程序安装到 Eclipse 开发平台之上了。
具体的操作步骤如下所示：
- 打开 Help 菜单，并且选择 Software Updates > Find and Install 。
- 下一步，选择 Search for New Features to Install ，然后点击 New Local Site 。
- 定位到档案文件被解压缩的目录（即 site.xml 文件所在的目录）。
- 在下一个对话框中，将其命名为
USBD Profile Site。 - 点击 Finish 。
- 在下一个对话框中，展开 USBD Profile Site 节点，并且选择 Unified Scenario Based Design feature 1.2.0 特性。
- 继续完成向导所示的剩余步骤，安装 UML 规范。
在下一小节中，您将看到如何将一个业务处理过程（它在 WebSphere Business Modeler Advanced Edition 中被建模的）导入到 Rational Software Architect 之中，从而得到处理过程的自动部分的需求。
从“业务”到“代码”
基于统一场景的设计提供了一种从业务处理过程中得到软件需求的方法论，并且确保该软件同时满足业务和用户的目标。假设您的公司拥有一支业务分析和设计团队，他们负责建造通过 WebSphere Business Modeler 建模的业务处理过程的一个资产。
这些也许是您所在的公司所采用的的业务处理过程，或者是您的客户所采用的业务处理过程。在前一种情况中，您可能会希望自动完成处理过程的部分操作，从而提 高公司的效率。在后一种情况中，您可能会成为一个面对这样一项业务的软件公司：提出一种自动完成客户的处理过程的部分操作的软件解决方案。
图 4 显示了 WebSphere Business Modeler 中的示例业务处理过程模型的内容。
图 4：WebSphere Business Modeler 中的业务处理过程模型的内容。 
特别地，图 5 显示了一个示例 Batch 和 Schedule Development 的业务处理过程。为了更好的描述在 WebSphere Business Modeler 中建模的可能性，并且理解每一项是如何被转化到 UML 的，这个例子显示了如下内容：
- 用于收集 Scheduling 需求和收集 Batch 需求的简单任务。
- 一个用于 Batch Development 的目标任务。
- 用于 Schedule Developmen 和 Program Development 的全局处理过程。
我们还将描述全局知识库 Schedule Definitions、Batch Definitions 和 Program Library 将如何在转换中被处理。
图 5：WebSphere Business Modeler 中的 Batch 和 Schedule Development 业务处理过程。 
图 6 展开了 Schedule Development 全局处理过程的细节，这些细节将在下一小节中被选为自动处理。处于简单性的考虑，其中只包括一个活动。
图 6：WebSphere Business Modeler 中的 Schedule Development 业务处理过程的细节。 
您可以通过将 WebSphere Business Modeler 模型导入到 Rational Software Architect 之中，将知识传递到您的开发团队，从而提高业务处理过程资产的价值。在 Rational Software Architect 中，您能够通过 USBD 方法论的额外的语义学来补足知识。除此之外，在模型元素之间的路线关系将为您提供一幅关于问题的业务、系统和用户经验方面的全景图。
将一个 WebSphere Business Modeler 处理过程模型导入到 Rational Software Architect 之中
在开始之前，请确保您已将将 WebSphere Business Modeler 综合添加到您的 Rational Software Architect 安装之中。通常，您是在安装 Rational Software Architect 时指定这个选项的。如果您并没有这么做的话，那么您能够在稍后使用 IBM Installation Manager 从 Rational Software Architect 安装媒体中将其添加。
在本小节中，您将看到如何导入一个用于“富裕公司”的示例业务处理过程模型，接着前文中所给出的“工作量安排处理过程”的例子。我们在一个新的工作区中启动一个 Rational Software Architect，并且将其切换到建模视图。我们现在将 WebSphere Business Modeler 模型导入作为一个现已存在的项目：
- 从 File 菜单中选中 Import 。弹出导入对话框，如图 7 中所示。
图 7：导入 WebSphere Business Modeler 项目。
- 在 General 文件夹中，选择 Existing Projects into Workspace ，并且点击 Next 。
- 接下来，指定业务处理过程项目所在的 WebSphere Business Modeler 工作区目录。
- 在图 8 中所示的对话框中，选择您希望导入的项目，以及其内容是应当被复制到 Rational Software Architect 工作区中，还是被引用到 WebSphere Business Modeler 中。
图 8：选择要导入的 WebSphere Business Modeler 项目。
- 点击 Finish 。业务处理过程模型被转换到 UML，并且被导入到 Rational Software Architect 工作区中。图 9 显示了操作结果。
图 9：在 UML 中被转换的被导入的项目。
请注意，在 WebSphere Business Modeler 中所定义的业务模型元素已经被转换到 UML 元素中，并且没有创建任何图表。为了创建图表，需要我们创建一组图表，并且将被转换的元素放至其中。首先，创建一个自由格式的图表，然后将 Business Items 和 Processes 包中的所有条目拖动到该图表之中。图 10 显示了布局改造后的结果。
请注意，每一个处理过程都被转换为两个条目：一个 <BusinessUseCase> 和一个 <Process>，第一个条目是一个 UML 用例，而第二个条目是一个 UML 协作。每一个业务条目都被转换为一个 <BusinessEntity>，而每一个角色都被转换为一个 <BusinessActor>。
至此，您已经将相关的业务处理过程的知识导入到 Rational Software Architect 之中，并且您希望通过那些 WebSphere Business Modeler 不打算捕获的概念来增强这些知识。为了能够在我们的模型中使用 USBD （基于统一场景的设计）模板，您首先需要做的就是将用于 USBD 的 UML 2.0 规范添加到这个模型之中。
- 在左侧的资源树中，选择 UML 模型，然后在透视图中选择 Profiles 标签。
- 点击 Add Profile 按钮。弹出如图 11 中所示的对话框，从中您能够选择 USBD 规范。
图 11：将用于 USBD 的 UML 2.0 规范添加到模型之中。 
您将首先对业务目标进行建模，尤其是那些对您已经描述过的业务处理过程产生影响的目标。
- 首先在您的 UML 模型的顶部创建一个包，并且将其命名为
Business Goals（业务目标）。 - 接下来，通过 USBD 规范中的 <Business Goals Catalog> 模板对其进行刻画。
- 然后，在该包中打开图表，并且创建两个类以反映两个业务目标，并且将它们模板化为 <BusinessGoal>。
- 然后，您就能够为这些目标添加方法，作为相应的类属性，并且将它们模板化为 <Measure>。
- 至此，您需要对建立这些目标的人进行建模，这是因为这是这些人希望收到关于公司如何实现这些目标的报告 。您可以通过向处理过程包中添加一个新的 <BusinessActor> 来完成这一操作。同时，也要将 <CustomerStakeholder> 模板添加进去。
其结果如图 12 中所示。
您现在就可以在导入的业务处理过程上进行业务分析，进一步指定处理过程活动。这将允许您决定希望哪些活动被自动执行，从而得出用于相应的软件系统的需求。
- 您首先希望检查 Batch 和 Schedule 开发业务处理过程。因此，展开 <ProcessCatalog> 包，然后是 Batch 和 Schedule Development <Process> —— 即模板化的 UML 协作，然后是其中的 UML 活动。
- 您需要创建一个图表来查看该活动，右键双击活动结点，然后选择 Add Diagram > Activity Diagram 。
- 这个新图表中自动加载了 UML 活动。打开该图表，如图 13 所示，您将注意到原始的业务处理过程已经被转换为如下内容：
- 在原始处理过程中被调用的每一个简单任务、全局任务和全局处理过程，都成为新的处理形式中的一个调用操作活动。
- 每一个这样的调用操作活动都被放置到一个泳道中，用来表现执行原始任务或者全局处理过程的原始活动者。每一个泳道都对应一个相应的业务活动者。
- 原始任务或者全局处理过程的输入和输出都被正确无误地转移到相应的调用操作活动中。
这个例子将关注 Schedule Development 全局处理过程，而图 14 显示了在您以同样的方法添加相应的活动图表之后的情况。出于简单性的考虑，这个子处理过程只包含一个任务，此处被转化到一个被称为“为 Batch 创建一个 Schedule 定义”的 Call Operation Action （调用操作活动）。
图 14：Schedule Development 业务处理过程。 
您希望进一步分析这个活动及其子任务。您将通过开发一个 <BusinessProcessActivityRealization> （一个在 表 1 中被显示的 UML 协作）来完成这一操作。
- 在进行这一操作之前，您需要分配一个适当的包来包含这些实现，所以我们创建另一个顶层包，并且通过 <BusinessProcessActivityRealizations> 模板来对其进行刻画。
- 此时，您将在一个 Sequence Diagram （序列图表）中描述“为 Batch 创建一个 Schedule 定义 ”活动所需要的任务流程，如图 15 中所示。
处理过程中一个活动的实现是由相应的业务活动者发起的，并且由一组业务工作者执行。将各种协作工作者从模型树中拖动到图表中，从而描述实现该处理过程活动的任务序列。
图 15：为 Batch 活动实现创建一个 Schedule Definition。 
您将注意到一个被称为 Workload Scheduler 的新工作者的出现。您已经在 <ResourceCatalog> 包中显示的创建了这个工作者，这是由于您发现了一个参与到这个活动的实现中的新的活动者。正是在此处，您将业务的上下文环境传递到系统的上下文环境：假定您已经决定自动执行这个 Workload Scheduler 工作者。请您执行下列步骤：
- 首先，将 <System> 模板添加到这个类中。
- 现在，您应当理解同这个工作者的每一次交互作用都定义了相应系统的一个用例，例如：一个交互作用成为了在序列图表中所描述的一个消息，而该序列图表对应于业务工作者类中的一个操作。随后，您还能够创建系统活动者来对应那些同新系统向连接的工作者（活动者），并且将 <System> 或者 <User> 模板添加到它们之中。
- 图 16 中显示的用例模型来自于 Workload Scheduler 工作者的引入消息，您可以在模型中所开发的所有活动实现中找到这些工作者。
- 您还能够看到一个系统活动者，它是一个符合 Schedule Developer Business Actor 的 <User>。您可以通过创建一个结点，将这个用例模型直接链接到序列图表上面，并且将该用例图表从模型树中拖动到这个结点之下。
- 除此之外，您能够将这些用例打包到一个顶层包中，并且使用 <UseCases> 模板对其进行刻画。
现 在，我们希望这些用户对这个系统拥有一个成功和愉快的体验。USBD （基于统一场景的设计）方法论允许您设计这样一个系统，该系统将用户整合到业务处理过程之中，这应当肯定地说是一个成功的体验。然而，您可能还想将人为的 因素考虑进来，从而提供一个有效的、简单的并且舒适的交互作用。
一种方法就是执行 Interaction Design （IaD），它最终定义了 Personas （角色）并且捕获了 User Goals （用户目标）。图 17 中显示了您如何描述模型中的用户目标，并且将系统的用例绑定到这些目标上。尽管这个例子并没有对其加以讨论，但是角色还可以通过使用 USBD 模板被描述和刻画，正如 表 1 中所描述的那样。
最后，由于用户和系统之间的交互作用将会通过一个用户接口被建立，所以您能够为每一个相关的用例开发一个用例情节串联图板，根据参与的用户接口元素来描述这个交互作用将会如何发生，以及它们将如何被导航。
用例情节串联图板是用例的另一个 <Realization>，就像您在 Analysis 模型中所描述的通常实现一样。但是，它并没有定义用例如何通过系统被内在的 实现，而是定义了用例如何通过其用户接口被外在的 实现。图 18 中显示了您如何通过使用由一个状态机所描述的 UML 协作来建模一个用例情节串联图板。
您 可以将协作和状态机都模板化为 <Storyboard>，状态集中的每一个状态都是一个 <UIElement>。表现用户接口面板以及它们之间转换的各个状态，反映了和用户在面板上的活动相对应的定位路径。情节串联图板也被证明 在设计用于用户接口的测试实例时是有效的。再一次说明，您能够将情节串联图板打包到一个顶层包之中，您可以使用 <Storyboards> 模板来刻画它。
图 18：创建 Schedule 用例的情节串联图板。 
图 19：业务处理过程路线图。 
总结
这篇文章是本系列的完结篇，它总结了在 IBM Rome 开发实验室中被成功实践的需求聚集和设计的方法论。
本文描述了关注于点对点的业务环境（即产品所存在的地方）的基于统一场景的设计（USBD）方法背后的原因，并且提供了将其链接到自动执行业务的系统的上 下文环境中的强有力手段。通过解释如何将业务需要链接到软件执行，本文描述了通过处理过程路线图、目标和类图表来捕获业务处理过程的方式，以及如何通过系 统执行来跟踪它们。本文还讨论了一种用户接口同系统分析相链接的正式的表示法。
本文所关注的重点在于帮助您将 USBD 方法论投入实践的那些工具。本文提供了一个新颖的规范，当您在 IBM Rational Software Architect 版本 7 及其后续版本中将它同 IBM WebSphere Business Modeler 综合特性一起使用时，这个规范允许您以一种正式的方式捕获和描述所有和业务、系统、用户经验层相关的概念。
下载
| UML 2.0 Profile for USBD | usbdprofile_1.2.zip | 101KB |