本文内容包括:
您曾经怀疑过如何向系统架构师、设计人员和开发人员提供干脆明确的需求吗？所撰写的场景向您和您的团队完全地阐述了系统运行所处在的环境的情境吗？您如何能够快速地适应连续的业务需求变更？您如何能够为系统创建最佳的接口？统一的基于场景的设计是回答以上问题的端到端的方法，它同时也瞄准了创建更容易满足业务需求的系统。
引言
最近几年，许多公司开始越来越依赖支持它们的动态业务过程的软件，作为一种方式来获得可持续的竞争优势，或只是处于不断的竞争中。这推动了创建不仅支持所描述的业务目标，而且还可以在那些目标变更时可以很容易地适应的软件的需求。随着人们对软件使用的一普遍化，等式的第三个元素是这种软件的最终用户。如果预期接受者察觉很难使用，那么甚至是设计和开发得最好的技术也不能变出魔术来。
试图解决该等式的两个主要的学科最近出现了，各有所长，基于场景的设计（Scenario-Based
Design） [1] 和 Outside-In Design [2]。
基于场景的设计（Scenario-Based Design，SBD）作为可以满足有效地管理客户需求，并且更容易地在客户环境中集成产品的关键学科出现。它的主要目标是推动技术集成。虽然此方法是好的开端，但其还不完全。为了避免创建与现有的客户角色和过程不一致的解决方案，SBD
必须对用户、它们所做的事情，以及他们所处的环境更加重视。
IBM 中的 Outside-In Design（OID）方法和过程代表了以用户为中心的设计（User-Centered
Design）[3] 和 用户工程（User Engineering） [4]最后的演进步骤。主要的焦点在于产品线所处于，或计划处于的业务环境。更确切地说，OID
的目标是定义此类产品的用户，以更好地设计他们的交互体验。这使得 OID 在用户接口设计领域中非常有效。如果在 OID
方法中寻找弱点，那么其弱点是缺少业务环境、系统环境，和用户接口之间的正式连接。
这两个学科都建立在这样的概念之上，就是了解客户的业务环境是成功的关键。两种方法都承认了解是不够的：向所有有关的涉众（包括客户）以明确的形式传达您的理解至少也是同样重要的。
UML 方法是公认的描述软件系统的语言，因此似乎很自然的是，也采用同一种语言来描述业务环境的知识（用户及用户接口）。这使得该方法非常严谨，并且允许一种以无疑的方式将结果与系统架构链接起来。因此解决方案非常依赖于业务过程的正式建模，就如同现今软件系统的通用实践。
本系列文章的目标是介绍一个有效的统一设计方法，基于两个互补的方法，基于场景的设计和
Outside-In Design。方法将产生一组严谨且完整的设计规范 — 从业务环境到系统的实现 — 关键的焦点是用户体验。这个系列文章将此方法论命名为统一的基于场景的设计（USDB）。
统一的基于场景的设计的好处
本系列文章中所描述的 USBD 方法在 IBM? Tivoli? Workload
Scheduler (TWS) 用户接口上应用，并且证明给出了，其中，以下的优点：
- 允许您将业务环境及其目标看作是管理软件设计所遵从的约束条件的关键决定因素
- 为以下方面提供可能性：
- 确定业务目标是否得到正确的支持
- 确定哪个领域需要更多投资
- 发现冲突的目标
- 验证用户执行的任务如何支持业务需求
- 设计符合用户需求和目标的用户接口
就令软件产品快速地响应业务中的变更的能力而言，从业务过程元素到系统元素的正式追踪为您提供更大的灵活性。您可以使用为系统建模的同样形式来为业务过程和目标建模，通过利用这样的事实，您现在可以获得整个端到端的视图的单一的描述，从业务需求到软件产品。
- 通过正式的、基于 UML 的用户和用户接口建模，在参与软件开发生命周期的不同团队之间创建明确的文档及通信
- 为您提供将用户接口和系统模型链接起来的能力，使您更容易地找到错误。这使您可以将所有设计软件系统的最佳实践应用到用户接口的设计中来。
本系列文章将讨论着重于产品所处的端到端的业务环境的 USBD 方法的愿望，而不仅仅是围绕单个产品介绍业务场景。通过介绍将业务需求和软件实现链接起来的方式,这些文章概述了通过过程映射、目标，和类图获取业务过程，以及如何用实际的实现追溯它们的方法。本系列还会向您介绍怎样可以正式化地表示与系统分析相连接的用户接口。围绕此方法的工作的自然演进是描述了支持该方法过程的
IBM? Rational Unified Process?（RUP?）定制。
注意：OID 所覆盖的两个领域，IBM Business Domain 和 Milestone
Process，超出了该集成的范围。它们是有价值的，由于它们的含义不作为此工作的一部分而变更，所以在此处就不提了，但它们是包含于
OID 材料中的。
通用实践的问题
由于缺少形式，生成实质上缺少客观阐述的产品规范是通常的做法，当您认为不可能正式地追溯两个基本规范工件，如根据应用程序层的业务过程和业务目标时，这是很明显的。这种客观阐述的缺乏在业务系统必须快速地对新的或更新的需求做出反应的情况下严重地削弱了通用实践的能力。
以下列表总结了问题的陈述，并概括了对当前方法的主要关注点：
- 仅仅使用用例驱动的 UML 规范对系统进行建模不会提供良好的业务反应性级别。即使该实践通过能够将分析和设计工作集中于系统的使用维度上以带来许多益处，但仍旧不够。
- 从市场投入时间和质量的角度来看，实现应对新的或修改的业务需求的变更仍旧是主要难题
- 应用程序开发不能有效地响应业务层上出现的变更。这是因为在业务定义层业务规范没有充分地构建，并且因为它们没有有效地追溯到应用程序层
- 业务和应用程序层之间存在着鸿沟
- 业务分析人员和应用程序分析人员不使用同一种语言（例如，UML）来将它们的系统形式化
- 在目前的 UML 图中没有明确的提出规范
- 抽象层之间缺乏可追溯性
- 当面对变更时，说明需求的演进对分析人员来说是不容易的，或者对于设计人员来说实现对支持那些需求的系统所需要的调整是不容易的
- 作为这种可追溯性缺乏的直接影响，不鼓励分析人员在分别的模型中形式化业务反应：业务规则及其使用约束条件在应用程序用例中无意地混用了
- 用户体验的质量通常很低
- 对产品的用户、它们的目标和任务，以及最重要的，产品如何符合客户业务过程有很少的理解
- 用户接口设计人员和系统设计人员不使用同一的语言（UML）来将它们的系统形式化
- 用户接口规范可能是不明确的，并且对实际的系统 UML 图是不可追溯的
作为这些陈述的证据，设想一个来自于真实生活的实例：图 1描述了三个不同的场景，以非书面的形式描述，作为当前推荐的最佳实践。该图还显示出一系列从场景中识别出的需求，但与后者没有联系。
假设由于过程中的变更更新软件栈（Update software stack）场景将不再包含步骤
8。去掉一个步骤导致当前过程中的两个主要问题。首先，确定与变更相关的需求集的过程是具有不确定性的，并且因此是易出错的。这是由于这样的一个事实，场景和需求之间的联系既没有用形式化进行表示，也没有任何工具支持。第二，相关需求及有关的用例的移去部分可能对不同的场景有副作用，并且不存在确定这种影响的方法。
图 1. 问题陈述：来自真实生活的实例
为了描述此问题，USBD 方法论为以形式化的方式描述场景和需求，以及将这些需求关联到系统和所设计的用户接口上提供了方法。
此方法在 TWS 用户接口的重新设计时被使用，并且通过此新方法获得的好处是切实的：
- 产品开发周期中所涉及的所有参与者，包括执行官（制定关于战略方向的决策），产品经理（必须与客户团体保持经常的通信的人），并且当然有开发团队，清楚地了解产品线所处的业务环境。因此，当讨论需求、特性和产品定位的时候，每个人都处于同一页面。而且最终，开发团队能够有办法来实现由客户要求的客户定位（customer
orientation）。定义业务过程中的哪些部分对所有客户是通用的 — 哪些实现是可选的 — 也能够帮助指导产品特性的优先级的确定。
- 用户场景不再是纯粹的推测，而是源自于业务过程，并由用户团体验证。另外，借助于模型中的可追溯性，开发团队可以确信，所描述的用例实际地支持场景的目标子集。只要涉及用户体验，由于已经用形式化的方式描述了用户及其目标，那么团队就可以确信所描述的用例能够支持用户目标，并且其可视化的实现以一种匹配用户技能的可用方式来提供所希望的功能。
- 用户接口和系统模型之间的关联考虑到更有效的检查，因此导致在开发周期中，更早地找到更多错误。同样，开发团队现在可以将设计软件系统的最佳实践应用于用户接口的设计。
- 开发组织可以更快速地对业务环境中的变更作出反应。业务和系统模型之间形式化的可追溯性的引入使开发能够了解由业务需求中的变更所导致的对系统的影响。这增强了业务灵活性之后始终的探索，并且朝着成为随需应变的开发组织又前进了一步。
假设及重要的事实
本系列文章大量的使用了建模规程中可以找到的概念和工件。因此，本系列文章假设您对这些概念有一定程度的了解。下面的内容是您可以轻松地阅读本文所需要的基础知识。业务建模（按照标准的
RUP 定义）将用作表示客户业务过程的框架。您可以参考Learn business process modeling
basics for the analyst [5]、Effective Business Modeling with
UML: Describing Business Use Cases and Realizations [6]，和Introducing
the IBM Rational Unified Process essentials by analogy [7]
来获得对此规程的介绍。
UML 形式是令此方法更加严谨的关键，并且是以无可置疑的方式关联结果及系统架构。要了解
UML 的概述，您可以参考 统一建模语言（Unified Modeling Language）版本 2.0 [8]、
UML Distilled 书 [9] 和 UML 资源中心（UML Resource Center）[10]。
利用IT Infrastructure Library (ITIL) [11]，依据
USBD 方法论中包含的同样方法，作为系统管理参考业务过程。
统一的基于场景的设计
USBD 是被提议的覆盖软件开发端到端范围的统一的设计方法。目标是能够设计出覆盖所有或部分被建模的业务过程的产品，以及帮助预期的用户利用最可能的经验实现所确定的目标。USBD
所描述的开发的另一方面是如何通过简洁，而完全的形式化文档集支持生产者和消费者之间的沟通渠道。这些文档，或工件，允许各种接口和角色之间明确的通信，在不丢失信息的情况下启用简洁的通信。USBD
确定出可以归为以下类别的过程步骤和相关联的工件：
- 理解客户
- 理解用户
- 概念设计
这些类别中的每一个都会在本系列文章中的一篇文章中得到详细地描述。额外的一篇文章将讨论用于简化该方法的实现的
IBM? Rational? Software Architect（RSA）或 IBM? Rational? Software
Modeler（RSM）概要文件和模型模板。前两类中的步骤自然地进入交互设计师（Interaction Designer）角色，这个包含了
RUP 中定义的需求分析人员 角色和部分的设计人员角色。第三类则包含了产品架构师和设计师。第一篇文章对 USBD 进行概述，并提出了将在本系列文章中使用的，用来例举所讨论概念的案例研究。其余的文章详述了该方法的活动和相关的工件。
过程和案例研究概述
通过利用真实生活中的场景，换句话说是案例研究来介绍 USBD。场景已经完整开发出来了，但是在这些文章中，只详细地介绍了一个单个的途径，来阐述所使用的方法。本部分介绍案例研究，基于了解
TWS Operational Interface（今后称为 TWS Web UI）如何能够被再设计以更好地满足市场的工作。
案例研究识别出在客户那里适当的实现工作量进度安排自动化的运作业务过程。IT Infrastructure
Library（ITIL）被用于确定在该业务环境中可以利用的最佳实践。ICT Infrastructure Management
和 Service Support 规程是手边匹配此问题的规程。之后，ITIL 所提出的模型由一些与计划产品（换句话说，TWS）进度有密切联系的人进行检查和验证，最后，这些模型有客户自己进行检查和验证。
如前面所概括的，这对了解围绕任何用来安排软件进度的操作环境的业务环境是很重要的，并且属于理解客户（Understanding
the Customer）类别。将对这样的环境理解转化为需求以进行形式化的定义：
- 实现工作量进度安排所需的业务过程，包括：
- 不同的活动是什么
- 它们如何相关联
- 谁负责每个活动
- 在过程中交换了哪些工件
- 组织所设置的过程支持的业务目标。这包含理解：
- 业务目标是什么
- 如何对每一个进行度量
- 谁设置了每个目标
将上面的第一点进行形式化地建模的方法是使用业务过程图（Business Process
Map）和一组详细的业务过程（Business Processes）。如图 2所示。前者以简洁的方式表示所有已确定的业务过程，以及它们之间的关系。焦点位于组织单元级别。由业务过程图开始，所关心的业务过程可以进一步详尽，来更好地理解自动化的机会。
图 2：业务过程图
经验认为在各种客户那里，同样的逻辑业务过程是以不同的形式实现的。总之，实际上，您会发现，所确定的业务环境由两个主要部分组成，核心的和定制的。本系列文章介绍了如何利用这种可变性。
业务过程中所描述的活动的级别非常高。事实上，每个活动都可能在所确定的业务角色的责任下，由许多其他角色执行。更详细地介绍活动如何执行，由哪些角色执行的形式化方法是使用业务用例及其实现。
对于该案例研究，业务过程、相应的业务角色，和一组业务目标是由 ITIL 文档描述的。同样的，一组业务用例也是出自于，且与每个用例所支持的业务目标相关的。
这两个活动概括了用来为业务过程和相应的用例建模的方法。USBD 方法至关重要的方面是所确定的业务过程如何支持业务目标的描述和形式化。此概念在业务用例实现中获得。每个实现通过形式化的可追溯性，将业务过程中的一个活动与一个或多个业务目标相关联，如图
3所示。
图 3：业务目标和业务用例
这完成了业务级别上用来确定技术所应用的环境所需的分析，以及要帮助实现的业务目标。下一个逻辑步骤是确定过程的那个部分可以自动化。
所执行的业务建模到目前为止已经确定了一组参与业务用例实现的业务参与者。原则上，这些参与者中的任何一个都可能被选择成为自动化的对象。一旦确定了这样一个业务参与者，那么将隐含系统（自动化的参与者）及其用户（与其交换消息的非自动的参与者）的定义。这也将确定出自然地定义系统的用例的两个参与者之间所交换的消息。在这种情况下，业务用例实现也可以视为场景的定义。
业务用例实现描述用户可能与软件系统交互所处的场景的方法如图 4所示。
图 4：作为场景的业务用例实现
根据定义，用例（Use Cases）表示要建模的系统与其预期的用户之间的交互。理解并形式化地描述系统所确定的用户的需求出自于经验。一个非常成功的用于对实际或潜在的产品，或一套产品的用户建模的方法是交互设计（Interaction
Design，IaD）— 参见参考资料，[4]。USBD 扩展了 IaD，使其拥有了 UML 的严谨，同时也考虑到了追踪对业务和系统模型进行的用户建模的结果。
在设计阶段，通常将软件系统分解为类和子系统，并且根据这些元素来实现用例。在系统拥有用户前端的情况下，严谨地设计
UI 也是非常关键的。USBD 也通过描述如何根据 UI 元素实现用例来解决此问题。
图 5显示了用例情节串连板如何描述组成用户交互的屏幕显示，以及如何对具体的用例进行导航。
图 5：根据情节串连板的系统用例及其实现
虽然利用 UML 描述 UI 在开发团队中有极大的意义，但是其结果对于客户验证会是困难的事情。在这种情况下，可视化的场景情节串连板仍旧可以证明是非常有效的，如果将它们用于演示所确定的场景，这对客户来说听起来是熟悉的。
难题的另一个部分是用户目标和业务目标之间不明显的关系。此关系需要明确地获得，以确保用户目标支持业务目标。该关系可以源自于模型，通过从业务目标开始，到业务用例实现，到用例，并且最终到用户目标的形式化的追溯。总之，一旦确定了此关系，就可以在类图中明确地表达出来，说明两个目标的类之间的联系。
可视化的场景情节串连板 — 以及业务和用户目标之间的关系 — 如图 5 中所示。
图 6显示了一个将前面所有概念放在一起的实例，它引用了真实的案例，描述了被 TWS
产品部分覆盖的业务模型片段。
图 6：将所有部分放在一起
本系列中其他两篇文章为所描述的主题提供更加详细的信息，并且将提供一个如何将 USBD 投入到实践的端到端的实例。最后的一篇文章将介绍如何使用
RSA 附加功能创建所介绍的工件。
- 第 2 部分：理解客户和用户
- 第 3 部分：开发概念设计
- 第 4 部分：将概念投入工作中
参考资料
学习
- 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
- 统一的基于场景的设计，第 2 部分：理解客户和用户 本文是关于统一的基于场景的设计的方法的四篇文章中的第二部分。
- 统一的基于场景的设计，第 3 部分：概念设计 第三篇文章介绍了 USBD 所使用的用来详述自动化系统及其用户接口设计的最后的工件集。
- Usability Engineering Scenario-based Development
of Human Computer Interaction，Mary Beth Rosson，John M。Carroll
- An "outside in" approach to
development，Executive corner，出自 CCR2，2005 年第 9 期
- User-Centered Design: An Integrated Approach，Karel
Vredenburg，Scott Isensee，Carol Righi —— Prentice Hall，2001
- User Engineering，http://www.ibm.com/ibm/easy/eou_ext.nsf/publish/1996
- Learn business process modeling basics
for the analyst，http://www.ibm.com/developerworks/webservices/library/ws-bpm4analyst/
- Effective Business Modeling with UML：Describing
Business Use Cases and Realizations，http://www.ibm.com/developerworks/rational/library/content/03July/2000/2256/2256_PWN.pdf
- Introducing the IBM Rational Unified Process
essentials by analogy，http://www.ibm.com/developerworks/rational/library/05/wessberg/
- 统一建模语言（Unified Modeling Language）2.0 版，
http://www.ibm.com/developerworks/rational/library/05/321_uml/
- UML Distilled: A Brief Guide to the Standard
Object Modeling Language, Third Edition，M. Fowler —— Addison-Wesley，2004
年
- UML 资源中心（UML Resource Center），http://www.ibm.com/software/rational/uml/
- 关于 ITIL，http://www.ogc.gov.uk/index.asp?id=1000367
- IBM Rational Software Architect 资源页面：寻找关于
Rational Software Architect 的技术文档、指导文章、培训、下载及产品信息。
获得产品和技术
- IBM Rational Software Architect：从 developerWorks
下载产品试用版本。
讨论
- Rational Software 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）。 |