本文内容包括:

• 介绍
• 理解解客户
• 理解用户
• 参考资料
• 作者简介

一个关于统一的基于场景设计的方法的四篇文章组成的系列中的第二篇着重于建模活动的业务方面，并提供了取自于真实案例的具体实例。特别地，本文说明了如何获取并形式化与所有的业务实体，以及将正在被建模的流程的一部分自动化所需的相应系统实体相关的详细内容。

　介绍

本系列的第一篇文章提出了对统一的基于场景的设计（Unified Scenario-Based Design，USBD）方法的端到端的观点，说明了要正确地为业务建模并让其与支持它的系统相连接所需的步骤。本文更着重于说明如何通过获取所有细节 — 客户（Customer）做什么，以及如何做 — 来创建的建模"客户（Customer）" 所需的工件，而这些信息是正确建模支持业务运行的系统所需要的。图 1显示出在您使用 USBD 方法时将生成的所有工件。

图 1：统一的基于场景的设计方法的摘要

　本文将更加着重于此图的上面和左下部分的内容，并提供那个位置所显示工件的更加详细的信息。

理解解客户

此阶段的主要参与者是作为业务分析人员（Business Analyst）角色的交互设计人员，以下是在此阶段中执行的步骤。值得注意的是，下面介绍的步骤实际上不应该被严格认为是连续的。事实上，建模时并行执行许多活动是很平常的，每一个步骤都帮助细化整体模型。

步骤 1

在第一个步骤中，在业务模型中确定并获取了五个主要的元素：

1. 业务流程图（Business Process Maps）
2. 业务流程（Business Processes）
3. 业务参与者（Business Actors）
4. 客涉众（Customer Stakeholders）
5. 业务目标（Business Goals）

如本系列第一篇文章中所预料的一样，经验表明同样的逻辑业务流程在不同的客户那里以不同的形式实现。例如，一些实现整个流程，而其他的可能只实现一个子集。而且，不同的客户可能会把流程的一些部分作为备选的实现工作。在描述这些可变性要点时，您可能会问，除了业务建模是否存在其他领域，在这些领域中建模可变性的同样问题已经被解决了。一个答案来自于系统建模领域，特别是软件产品线（Software Product Lines）方法。在该领域中采用的解决方案是在整个系统中识别出在所有开发者之间都是公共的子集。这将成为系统的核心（kernel）。只由一些开发者使用的部分将成为可选的（optional）部分，而两个开发者关注的不同部分是选择性的（alternative）。因此在业务建模中可以使用相同的模式。特别是，您可以识别业务流程的一般部分：更确切地说，任何客户经常执行的活动。这些将成为核心的业务流程。以类似的风格，可以对可选的和选择性的活动也能够被适当地识别和建模。

业务流程图以 UML 活动图来表示。它们用紧凑的形式显示所有的已确定的业务流程，以及之间的关系。与每个组织（业务）单位有关的流程在图中被分配一个相应的泳道线。应该注意的是，业务流程生成并使用业务实体。从此图开始，将对所关心的业务流程进一步细化。图 2 显示出关于进度工作量管理的所有流程的图，从最初的业务单元批量及进度开发（Batch and Schedule Development），下到将实际的进度放入生产中的操作中心（Operations Center）。

　图 2：业务流程图

　业务流程也是以 UML 活动图表示的。图 3详细描述了批量及进度开发（Batch and Schedule Development）业务流程（图 2红色箭头标出的）。这样详细的业务流程图说明了业务参与者（Business Actors）如何彼此协作。这由一个 UML 活动图进行表示，图中显示出了所有具体业务流程中确定的活动。

图 3： 批量及进度开发（Batch and Schedule Development）业务流程片段

　活动被组织成不同的分组。这样的分组方法是一种用于组织对具体环境中活动的责任进行打包的机制。它们符合组织中的角色，并且在业务流程中以泳道线表示（借鉴了在系统分析中相应的图中所使用的形式化方法）。在流程中交换的工件由业务实体（Business Entities）表示，并且与生成并使用它们的活动相关联。如前面所提到的，提倡用软件产品线方法来描述业务层中的核心的、可选的，或选择性的活动。这是通过向活动本身中添加相应的原型，来表示客户如何实际地采用流程的不同部分来实现的。

每个分组表示由进度工作量管理领域中相同的角色所执行的活动，这些角色中的每一个都对应一个业务用例模型中定义的业务参与者（参考下面的步骤 2），而每个活动通过业务用例实现来对应一个业务用例。利用此技术，很可能将业务流程转化为业务模型，并在它们之间创建形式化的可追溯性。

图 4通过覆盖两个相对应的实体，显示了业务流程的泳道线和业务模型参与者之间的对应关系，以及活动和相关的业务用例之间的对应关系。请注意，在这里进行的可视化成只是为了说明的目的，这在此方法的正常实现中是不可能的。

图 4：批量及进度开发 业务流程转化
　

　如果涉及业务领域，其他最佳实践建议使用 IBM? WebSphere? for Business Integration (WBI) 来为业务流程建模。例如，图 2中显示的 运行生产进度（Run Production Schedule） 流程可能用 WBI 工具来描述。图 5 中的截图显示了使用 WBI 进行建模所产生的流程的具体样子。一种选择是仍旧使用 WBI 继续对流程建模，然后利用可用的转换工具将它们转换为 UML 活动图。

图 5： 运行生产进度（Run Production Schedule） 利用 WebSphere for Business Integration 建模的业务流程
　

客户涉众 是一类特殊业务参与者。他们表示具有设置业务目标责任的人的角色。对这些参与者及其目的进行理解并建模的重要性依赖于这样一个事实，那就是他们是否参与到了购买软件产品的流程中。T图 6 中的图为运作管理人员提供了一个示例，这些管理人员需要设定确保在一致同意的情况下完成所有事务的目标。像涉众设定的任何其他目标一样，此目标必须是可度量的。对涉众来说量度是非常重要的，并且可能成为给予涉众的系统报告中的重要信息。涉众也许不能直接参与业务流程，但他们仍然对业务流程如何工作感兴趣。

　图 6：运作管理人员（Operations Manager） 客户涉众和相关的业务目标

　业务参与者（Business Actors）以及与他们之间的静态关系，通常是利用传统的业务参与者建模元素在具体的图中表示出来的。业务角色之间的静态关系的显式建模能够获得一些重要的特性，这些特性是：通过形式化的追溯方式确定层次关系，及他们如何整体地协作来支持业务目标。

业务目标 可以用由 UML 类原型 <<business goal>>来表示，并且可以追溯到支持它们的业务用例。新的原型及其图标表示在本系列的第四篇文章中介绍的 USBD 概要文件中是可用的，并且这个概要文件可以安装在 IBM? Rational? Software Architect 工具中。

步骤 2

如之前所预期的，业务流程中描述的活动是层次非常高的。实际上，每个活动都在已确定的业务参与者的责任被其他的参与者，称为业务操作者，来执行。为了提供更详细的内容，这里的最佳实践建议将流程中的每个活动与不同的业务用例联系起来，反之亦然。这样业务用例的实现将详述每个活动是如何执行的，以及由哪些参与者执行。

特别是，在第二个步骤中，通过以下方法来完成业务模型：

• 用例图显示所有已确定的业务用例
• 追溯客户涉众、他们设定的业务目标，及支持那些目标的业务用例之间关系的自由形式的图

流程中活动之间形式化的追溯，以及相应的业务用例实现是通过将这种活动建模为连接到相应实现的调用行为（Call behavior）元素的方式来完成的。

图 7 显示由了图 4 中显示的业务流程的步骤 1 所阐述的转换产生的业务模型片段。

图 7：业务模型片段
　
　如对业务流程中活动所做的处理一样，在业务模型中，也可以将业务用例确定为的核心的、可选的，或选择性的。同样在此阶段，业务用例和业务目标之间的联系被定义并用 UML 形式化地表现出来，这一追溯活动帮助确保每个业务目标都由一个或多个业务用例覆盖。图 8显示出此关系的一个实例。红色箭头表明出自于图 7 的开发进度定义（Developing Schedule Definition）业务用例支持由运作管理人员设定的业务目标。

图 8：客户涉众、业务目标，和支持业务用例

　第二个步骤中的一部分是具体的业务流程活动及其相应的已确定的业务用例之间可追溯的形式化定义。这通过业务用例实现来完成，之后将成为创建流程、业务用例，间接地，还有业务目标之间关联的方法。此方法允许根据业务用例及业务目标验证业务流程覆盖率，反之亦然。图 9 显示出具体的 开发进度定义（Developing Schedule Definition）业务用例如何关联到开发进度定义（Develop Schedule Definition） 业务活动上。

图 9：通过实现将业务活动关联到业务用例

　一旦定义了模型的此部分，很重要的是执行一轮验证，这需要包含尽可能多的来自不同环境的涉众。从实际或潜在的客户那里来的输入在细化业务模型的此阶段是非常重要的。

步骤 3

在第三个步骤中，将开发业务分析模型，在其中，每个业务用例实现根据两个主要的 UML 工件进行形式化：

UML 类图表示业务用例参与者 — 包括业务操作者和业务参与者 — 以及他们的关系的静态视图
一个或多个 UML 序列图（每一个表示不同的业务用例场景或子流程）表示存在于业务操作者之间，用以实现业务用例的交互
图 10 显示了用三个业务操作者是如何实现开发进度定义（Developing Schedule Definition）业务用例的。业务操作者是实际执行流程图中显示的活动的实体，而业务参与者是计划活动的人（并且可能对完成的工作负责）。

图 10： 开发进度定义（Developing Schedule Definition）业务用例实现参与者
　
　业务操作者可能是一个人，或者它可能是一个自动化的系统。值得注意的是在一个实现中，不论什么时候存在业务参与者和自动化的业务操作者之间的交互，这实际上都引入了用户和系统之间的交互，并且因此产生了一个或多个系统用例。同样地，不论什么时候存在两个自动化的业务操作者之间的交互，需要发生系统到系统的交互。图 11 显示了开发进度定义（Developing Schedule Definition）业务用例实现的业务操作者如何合作来实现活动。

图 11： 开发进度定义（Developing Schedule Definition）业务用例实现流
　
　步骤 4

此步骤在前面步骤中确定的人中选择业务操作者来自动化。决定将哪个业务操作者自动化超出了本文的范围，但却是至关重要的。为了进行识别可能使用许多不同的方法。例如，可以了解通过自动化的方式来代替一个业务操作者所带来的预期节约。值得注意的是，如果至少有一个业务操作者能够被自动化，并且至少一个不能被自动化，那么实际上定义的内容是系统和系统的用户。例如，如果决定必须自动化Scheduler操作者，那么图 11中所示的序列图提供有用的信息来创建Scheduler系统用例模型。实际上，每个进入操作者的消息可以被认为是实现操作者功能的系统用例的实现。图 12显示如何概念化地完成此转换，这与在业务领域中完成从业务流程创建业务用例模型十分类似。

图 12：Scheduler业务操作者转换
　
　此处的实例表明了如何自动化Scheduler业务操作者。结果产生的系统用例模型如图 13所示，并且包括已确定的所有用例。

图 13：Scheduler用例模型
　
　步骤 5

此步骤创建业务建模及系统建模工件之间的追溯。此处的最佳实践，通过序列图中的引用方法把将要自动化的业务操作者所提供的每个方法关联到系统分析模型中相应的系统用例实现。这大大地增强了模型可导航性。此外，发起那些方法的业务操作者将追溯到相应的位于系统用例模型中的系统参与者（用户角色）。图 14 显示出创建作业模板（Create Job Template）用例如何连接到相应的消息上。

　另外，由于自动化的系统必须提供图形用户界面（Graphical User Interface，GUI）来允许进度开发人员（Schedule Developer）操作者（用户）与其交互，所以创建类似的连接来追溯同样的方法，使用用例情节串连板，这是相同的创建作业模板（Create Job Template）系统用例不同类型的实现。确切地说，USBD 建议用例模型中的每个用例 — 与参与者有关系 — 由设计模型中的用例实现，以及由用户经验模型中的用例情节串连板来实现。通常，没有必要用方法的同一个名字定义系统用例实现，以创建连接，名字在两个模型（业务和系统）中可以是不同的，因为连接被 UML 追溯依赖关联形式化地定义了。下一个部分介绍了用户建模，一旦确定了将一个或多个业务操作者自动化的决定之后，这就是重要的步骤。

理解用户

这个类别包含了目前被认为是交互设计（Interaction Design，IaD）团队的主要内容的活动，也就是创建用户角色（User Personas）并理解用户目标。用于用户建模的交互设计方法将原型用户捕获到用户角色中，也包括其目标和技能。如果涉及到目标，每个目标可以与已知环境中的角色相关联。在此方法中，角色以文本形式描述，这是在最大范围内进行涉众沟通的非常有效的方式。不幸的是，这使得从“用户模型”追溯到系统模型中的系统参与者是困难的。要做到这点，角色的形式化的 UML 表示是值得使用的，并且在下面进行了描述。

这些角色，以及其目标和技能映射到类图中，其中每个角色与其覆盖的系统参与者（换句话说，用户角色）相关联。此外，同样的类图也描述了在 IaD 活动中确定的每个用户目标和相应的系统参与者之间的关系。

步骤 6

此步骤创建角色，这是用户原型，封装了通过与许多具体的当前或潜在的产品用户进行面谈而收集的所有知识。针对每个被确定为需要一个产品的具体接口的用户，来创建不同的角色来详述典型的用户目标、任务和技能。角色通常在文本文档中描述。图 15 显示出这种文档的摘录。

图 15：角色文档

　使用描述性的语言收集在面谈中获得的信息对系统和产品的需求和接口的形式化定义有一些消极的影响。因此，我们应该使用以下的 UML 工件来介绍角色目标、技能和责任的新的形式化表示。

UML 类图表示用户角色发起的系统需求，建模为User原型的以角色命名的系统参与者。此图已经在图 13中显示过了，并且表示系统用例模型。
　UML 类图将用户目标表示为UserGoal 原型化类，每个都拥有一组Measure 原型的度量属性。量度描述了度量如何满足每个目标的方法。每个 UserGoal 如何与每个 User 相关联也可以在图中获得。关系是User 和每个 UserGoal 之间的依赖关联。图 16显示一个这样的 UML 类图。

图 16：用户、用户目标，及角色
　
　还是在此图中，每个角色显示为拥有一组 skill 原型技能属性的类。每个角色都与它覆盖的所有用户（用户角色）相关联，并且由主要角色（primary persona）、次要角色（secondary persona）, 补充角色（supplemental persona）、负面角色（negative persona），等等的原型进行标记。建立连接并验证角色和分析阶段中确定的（或者可能是反向工程）实际系统参与者之间的关系是有用的。角色类也拥有通过面谈收集来的信息的属性。除了技能，这可能包括年龄和工作环境的类型。此外，如同其他图一样，核心的、可选的，和选择性的的概念也应用于用户角色，来表示 eachUser 角色对于正在设计的系统的功能来的重要性。这在划分系统特性（用例）优先级过程中是有用的。

UML 图还能获取哪个系统用例支持哪个用户目标。此图还可以包含用户目标和业务目标之间的关系，特别是哪个用户目标支持每个业务目标。很重要的是要理解这种关系是不能被发明创造的，相反，它必须源自业务模型和系统模型之间的追溯。特别是，具体业务目标和用户目标之间的关系出自于支持业务目标的业务用例实现和支持用户目标的相应的系统用例之间的追溯。图 17显示了一个这样的 UML 类图。

图 17：用例、用户目标和业务目标之间的关系的


　所有在本文中显示的图都来自于真实世界的实例，用以研究对其操作性的 GUI 的改进。在下一篇文章中，将开发系统的概念设计。这样的设计将利用本文中建模的成果，并且将继续追溯到业务需求，以及向下到 UI 和系统设计。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
• 统一的基于场景的设计，第 1 部分：方法论原理本文是关于统一的基于场景的设计的方法的四篇文章中的第一部分。
• 统一的基于场景的设计，第 3 部分：概念设计第三篇文章介绍了 USBD 所使用的用来详述自动化系统及其用户接口设计的最后的工件集
• Designing Software Product Lines with UML，Hassaan Gomaa — Addison-Wesley，2004 年
• 用于 WBI Modeler 的 RUP 插件：在 RUP 中更新业务建模规程。
• 业务服务建模：业务服务建模帮助在业务需求和要满足这些需求的 IT 解决方案的架构之间的语义上的间隔上架起桥梁。
• 业务驱动开发：表示一种开发业务应用的方法，着重于建立对要达到的业务目的及目标，和分析流程、服务及达到目标所必需的已部署的应用程序所涉及的角色、活动和 工作产品的清楚了解。BDD 通过监控应用程序来收集关于重要的性能指标的数据来验证是否 IT 解决方案满足预期的业务目的和目标，并且为演进业务以减少成本，以及提供增加的价值提供具体的基础。
• WebSphere Business Modeler：可以使业务分析人员很容易地创建、模拟，并变更业务流程模型来确保满足业务目的和目标。
• IBM Rational Software Architect 产品页面：寻找关于 Rational Software Architect 的技术文档、指导文章、培训、下载和产品信息。

获得产品和技术

IBM Rational Software Architect：从 developerWorks 下载试用版本。提供了观察 Business Contract Model 所需的工具，以及开发可以用于为不同的架构风格生成实现代码的服务实现模型所需的工具。

讨论

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）。