本文内容包括:

• 前言
• 概念设计
• 参考资料
• 作者简介

本文是关于统一的基于场景的设计方法论的四篇系列文章中的第三篇，主要关注于建模活动的系统方面。本文尤其关注如何设计与支持在前面的文章中被建模的业务流程的自动化系统的用户交互。

　前言

第一篇文章 我们介绍了统一的基于场景的设计（USBD）方法论的端对端观点，第二篇文章 解释了为一个支持业务的自动化系统的客户和用户建模所需要的工件。本文描述了USBD使用的最后一部分工件，USBD用其来详细描述自动化系统及其用户界面的设计。 图 1 显示了USBD方法论所使用的全部工件。

图1：USBD 方法论的概述
　
　本文将会更加详细的讨论图1中的右下部分。

概念设计

给规类为概念设计分类活动是系统分析与系统设计的常见活动。本文主要关注于通过形式化的方式设计用户交互行为的重要性，这利用了在"Building J2EE applications with RUP"一书中所描述的内容作为基础，然后根据Rome Development Laboratory所采纳的IBM? Rational Unified Process? (RUP?)用户定制中的指南修改它。

第二篇文章描述了理解你所构建系统的客户（Customers） 与 用户（Users），以及获取这些知识所需的六个步骤。本文通过另外两个步骤实现建模过程的描述，这两个步骤有助于详细描述所建系统的功能与表示的方面。

步骤 7

在步骤 7 中，系统用例以两种不同方式得以实现，如图 2所示。

图 2: 用例实现

　实现系统用例的第一种方式是传统的用例实现（use case realization）, 它显示出用例如何通过一系列协作类进行实现。值得注意的是这是系统内部行为的模型。两个UML 工件模拟了这个方面：参与者（Participants）类图和 交互（Interaction）图。

参与者（Participants） 类图表提供了用例参与者的静态视图。尤其是主要参与者与系统的交互，其包含了边界类。这个类将通过用例情节串连板（看下一点）中的主屏幕被典型地反映出来。这种关系还可能通过直接的依赖性被反映出来。图 3 显示了Create Job Template用例实现中的参与者（Participants）类图。

图 3: 参与者（Participants）类图

　交互图是描述参与者的一个或多个UML的协作图。 图 4 表示了Create Job Template 用例实现中参与者之间的基本交互流程。

图 4: 基本流程的交互图
　
　由于系统需要与人交流，因此需要一个图形界面， 还需要实现 用例情节串连板（除了传统的用例实现）。这部分理论上仅应用于那些需要与人交互的系统。与传统用例实现不同，用例情节串连板展示了如何通过用户界面交互实现用例需求，并描述了系统的 外部 行为。

用例情节串连板还由两个主要的UML工件组成，它们是用户接口屏幕（User Interface Screens）类图与交互图。用户接口屏幕（User Interface Screens）类图表示了有关构建用户交互窗口的用例参与者的静态视图。这些类都被进行了原型化，对于主界面窗口使用原型 screen , 对于包含信息的面板或更多面板使用原型compartment （典型情况是大部分的类），对于接收用户输入信息面板使用原型 input form。

面板显示的每条信息由响应类的属性描述，面板为用户提供的每个操作都被表示为一个操作。这种 图表示了窗口中的静态与动态关系。每种关系如下：

• 静态关系是一个screen由一些compartments组成
• 动态联系是由用户行为决定的两个screen间的导航。

除此以外，此图还获取了同一界面两个不同方面之间的关系，正如他们各自在分析模型与用户体验模型所展示的那样。之前，一个用例实现一般由系统参与者与边界 类交互开始。后来，相应的用例情节串连板一般由系统参与者与screen 类交互开始。图中表示了这两种类间的关系。图 5 表示了Create Job Template 用例实现的 Screens 类图。

图5：用户界面的 Screens 类图

　交互图包括一个或多个UML 时序图（每个表示一个不同的用例流），它表示包含了信息交换的用户与窗口间的实际交互作用。图 6 显示了Create Job Template 用例情节串连板屏幕中的基本交互流。

图 6: 基本流的交互图
　
　最后，额外介绍了一个工件，它提供了通过所有用例识别的所有GUI元素的整体视图。这个工件是导航图（Navigation Map）, 它是一个UML 类图，它表示所有用户界面的窗口和他们之间的静态和动态关系。图 7 是导航图（Navigation Map）的一个例子。

图 7: 导航图（Navigation Map）类图

　步骤 8

一旦使用UML 情节串连板完成了GUI设计的理论部分，则需要可视化设计实际的图形界面。值得注意的是，这时的概念设计完全是技术无关的。就是说，例如，同一设计可通过Java? GUI，简单的Web 应用程序，或者portlet 应用程序进行实现。我们可以推迟决定实际用户界面所使用的技术，这不会影响设计的有效性。

在可视化设计阶段，包含可选的和潜在的用户让他们确定建议的有效性和可用性是极为重要的。但是，当UML是技术社区中传递信息的正确选择时，非技术的涉众则渴望着另一种不同的交流方式。

因此，在步骤 8 中，你创建了一个可视化情节串连板； 例如，格式可以是解说图,一组用户可导航的静态HTML 页，或者一个简单的原型。应该围绕用户场景创建可视化的情节串连板，用户场景能够在业务建模被识别，并且他们是 USBD方法的核心。 使用用户目标（User Goals）实现作为具体的例子、使用角色（Personas）作为参与者，每个可视化情节串连板都显示了GUI如何提供易用性与解决问题的能力。

可视化情节串连板应该被验证, 主要关注于验证GUI背后的主要设计思想的正确性。 图 8显示了一个可视化情节串连板的实例。

图 8: 可视化情节串连板

　总结

本系列文描述了组成所提出的方法论的八个步骤，它参照了统一的基于场景的设计。让我们简短的回顾一下这些步骤与他们的主要目的。

• 理解客户
1. 为用户涉众和他们的业务目标定义建模。为业务流程图和个人业务过程建模，确定加入其中的业务参与者。
2. 定义业务用例，并且为每个业务用例如何 支持 一个或多个业务目标进行建模。为每个业务用例突出其业务用例实现，并且定义如何连接返回到业务流程图的活动。
3. 定义关于业务操作者和他们所交换的信息的业务用例实现。
4. 选择将被自动化的业务操作者。它还定义了一系列用户。
5. 利用系统用例实现和业务用例实现间的依赖性将业务模型与系统模型连接起来。这种活动确定了系统用例和系统参与者，它们最终是用户角色。
• 理解用户
1. 创建用户角色，识别并对用户角色和用户目标进行建模, 利用依赖性理解用户目标如何实现最初的业务目标。
• 概念设计
  1. 开发用例实现和用例情节串连板。确定每个用例都支持用户目标。
  2. 设计用户界面。使用可视化情节串连板来描述场景, 并通过客户代表对他们进行验证。
  3. 作为额外的资源， 表1：方法工件 总结了支持这种方法论的UML工件。它提供了一种指示，即哪些工件被认为是必需的，哪些是可选的，以及它们被创建的步骤。

表1：活动工件

　结论与收益

到目前为止所发表的三篇文章讨论了USBD方法的需求，这个方法是关注于产品生存的端对端业务环境的，而不仅仅描述单一产品所围绕的业务场景。通过解释如何把业务需求与软件实现连接起来，文章描述了通过流程图获取业务过程，通过类图达到目的，以及如何通过系实现行进而跟踪它们的方法。还介绍了把系统分析与形式化的用户界面表示联系在一起的方法。

相反, 当描述产品规格说明时，今天被广泛采纳的方法被认为是缺乏表达形式的。当你在应用层中不能形式化的跟踪两种基本的规格工件（业务过程与业务目标）时，这种表达形式的缺乏变得非常明显。当业务系统必须迅速对新的或更新的需求进行响应时，这种形式的缺失是致命的 。

以下列表总结了问题陈述并且概括了当前过程中的主要关注方面：

• 仅仅使用用例驱动的UML说明为系统进行建模不能满足高水平的业务反应。即使这种实践通过将精力集中在一个系统使用维度方面的分析与设计上，来提供很多好处，但它仍然是不够的。
  
  • 对新的或修改后的业务需求的响应仍然是一项主要挑战，既包括投入市场的时间，也包括质量的方面。
  • 在业务层中，应用开发不能有效的对变更加以响应。制约因素是在业务定义层中，业务规格说明不能被充分结构化，且不能有效的追溯到应用层
• 存在于业务与应用层之间的鸿沟
  • 业务分析师与应用分析师没有使用同一种语言（UML）形式化的表示他们的系统
  • UML图中不能精确的确认规格说明
• 抽象层中缺乏可跟踪性
  • 当面对变更时，分析师很难指出需求的演进，设计师很难实现系统需求所需要的正确性
  • 缺乏可跟踪性所造成的后果就是，分析师不被鼓励在单个模型中形式化的表示业务反应：在应用用例中，业务规则和他们的使用约束被任意的交织在一起
• 用户体验的质量通常很低
  • 对于产品用户、他们的目标和任务，以及产品如何适应客户的业务流程的理解很贫乏
  • 用户界面设计师与系统设计师没有使用同一种语言(UML) 形式化的表示他们的系统s
  • 用户界面规格是模糊不清的，且对于实际系统的UML图是不可跟踪的

假设Update Software Stack 不再包括过程中的步骤8 。在当前方法论中，删除这步意味着引发两种主要问题。首先，确定与变化相关的需求集的过程是具有不确定性，并且具有导致错误的倾向，因为场景与需求间的连接既没有形式化的表达也没有被任何工具支持，因此可能出错。其次，删除相关需求与相关用例可能会影响其他场景，但是没有任何方法来确定这种影响。

图9：Schedule Update Software Stack 实例
　
　为阐明这些问题, 这种方法论在本系列文章中提供了一种描述场景与需求的形式化方式，并且在用户界面设计、系统、场景和需求之间创造了可追踪能力。 这种方法最初使用于重新设计的Tivoli Workload Scheduler 用户界面，现今已被多个项目采纳。通过新方法得到的好处是确确实实的：

• 产品开发周期中所包含的所有部分 － 包括必须决定策略方向的执行，必须与客户社区保持联系的产品经理，当然，还有开发团队 －
• 产品线存在的业务环境拥有清晰的理解。当讨论需求、特征和产品定位时每个人都能够互相理解。
• 开发团队最终拥有了被要求的实现客户定位的方法。
• 定义所有用户中哪部分业务过程是通用的，哪部分是可选择执行的，这些可以帮助指导产品特征的优先级划分。
  • 用户场合景不再是纯粹猜想的，而是源于业务流程，且在用户社区中进行了验证。
  • 除此之外，依靠模型中的可追踪性，开发团队可以依此确定用例实际支持场景的目标子集。
• 就用户体验而言，由于团队已经以形式化的方式描述了用户和他们的目标，他们可以确定实现的用例支持用户目标，并且可视化实现以
• 种便于使用的方式提供了被期望的功能，它匹配了用户的技能。
• 用户界面与系统模型的连接允许更高效率的评审，因此可以在开发周期中更早的发现错误。
• 开发团队现在可以使用设计软件系统的所有知识和最佳实践来设计用户界面。
• 开发组织可以在业务环境中更迅速的响应变更。业务与系统模型间形式化跟踪的引入可以让我们理解业务所需的改变对系统的影响。这增强了广受欢迎的业务敏捷性，并且向随需应变的开发组织又迈出了一步。

文中所示的所有图片均来自于 Tivoli Workload Scheduling 改进它的操作性 GUI 过程中所做的工作。下一篇文章将描述 IBM? Rational? Software Architect 工具的实际使用，它将为你展示如何使用作为 USBD方法论一部分被开发的插件。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
• 统一的基于场景的设计，第 1 部分：方法论原理本文是关于统一的基于场景的设计的方法的四篇文章中的第一部分。
• 统一的基于场景的设计，第2部分：理解客户和用户四篇关于统一的基于场景设计的方法论文章中的第二篇。
• Building J2EE applications with the Rational Unified Process ，Object Technology S.，Peter Eeles，Kelli Houston，Wojtek Kozaczynski － Addison-Wesley，2002
• IBM Rational Software Architect 产品页面：寻找关于 Rational Software Architect 的技术文档、指导文章、培训、下载和产品信息。

获得产品和技术

• IBM Rational Software Architect：从developerWorks 下载产品的试用版本。它提供了所需要的工具来显示 Business Contract Model ，并且能够开发出用于产生对于不同架构风格的实现代码的服务模型。

讨论

• Rational Software Architect，Data Architect，Software Modeler，Application Developer 和 Web Developer 论坛（英文）：询问关于 Rational Software Architect 的问题。

作者简介

Alex Donatelli 是 IBM 的高级技术职员。他是罗马和意大利的 Tivoli 实验室（Tivoli Laboratory）的首席架构师，并且是罗马中央架构团队（Rome Central Architectural Team）的经理。他和他的职员，以及罗马和 Tivoli 的整个技术团体一起提高产品质量。统一的基于场景的设计工作是此类工作的一个实例。

Roberto Longobardi 是 IBM 的交互解决方案设计师。他在性能及可用性和工作量管理方面致力于许多 Tivoli 开发项目。最近他提出了 IBM Tivoli Workload Scheduler 用户接口的再设计假说，他试图通过让解决方案更接近其商业和运作环境来提高解决方案的实用性。统一的基于场景的设计是与罗马中央架构团队共同经验的结果。

Rosario 是罗马和意大利 Tivoli 实验室的高级软件工程师。他是 IBM Tivoli Configuration Manager 的主要架构师，作为软件工程师、市场经理和人员经理，他在软件开发方面有 15 年的经验。在他各种各样的职位中，他对复杂的企业应用程序实现进行过架构、设计、发起和推进。他与合作伙伴及客户一起合作，并且在将商业需要转换为产品和解决方案需求方面有很长时间的经验。他在墨西拿大学获得物理学硕士学位。

Claudio 目前是一名高级软件工程师，以及 IBM Tivoli Configuration Manager 的首席设计师，他拥有 14 年的在系统管理领域进行开发和设计企业应用程序的经验。他被认为是 RUP 和 J2EE 方面的重要专家，他目前着重于软件工程最佳实践和模型驱动体系架构（Model-Driven Architecture）。