统一的基于场景的设计,第 2 部分

理解客户及用户

统一的基于场景的设计方法论用来了解客户和用户的步骤

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 统一的基于场景的设计,第 2 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:统一的基于场景的设计,第 2 部分

敬请期待该系列的后续内容。

介绍

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

图 1:统一的基于场景的设计方法的摘要
您在使用 USBD 方法的时候生成的所有工件的完整概述
您在使用 USBD 方法的时候生成的所有工件的完整概述

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

理解解客户

此阶段的主要参与者是作为业务分析人员(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)业务流程片段
详细描述了批量及进度开发业务流程的 UML 活动图
详细描述了批量及进度开发业务流程的 UML 活动图

活动被组织成不同的分组。这样的分组方法是一种用于组织对具体环境中活动的责任进行打包的机制。它们符合组织中的角色,并且在业务流程中以泳道线表示(借鉴了在系统分析中相应的图中所使用的形式化方法)。在流程中交换的工件由业务实体(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 建模的业务流程
运行生产进度业务流程的 WebSphere for Business Integration 模型
运行生产进度业务流程的 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:客户涉众、业务目标,和支持业务用例
表示业务用例及业务目标之间联系的 UML 图
表示业务用例及业务目标之间联系的 UML 图

第二个步骤中的一部分是具体的业务流程活动及其相应的已确定的业务用例之间可追溯的形式化定义。这通过业务用例实现来完成,之后将成为创建流程、业务用例,间接地,还有业务目标之间关联的方法。此方法允许根据业务用例及业务目标验证业务流程覆盖率,反之亦然。图 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业务操作者转换
进入操作者的每条信息都成为实现工人&amp;amp;amp;amp;amp;amp;的功能的系统用例的实现。
进入操作者的每条信息都成为实现工人&amp;amp;amp;amp;amp;amp;的功能的系统用例的实现。

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

图 13:Scheduler用例模型
Scheduler的系统用例模型
Scheduler的系统用例模型

步骤 5

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

图 14:连接到活动的用例
创建作业模板用例连接到序列图中相应的消息/参考。
创建作业模板用例连接到序列图中相应的消息/参考。

另外,由于自动化的系统必须提供图形用户界面(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:用户、用户目标,及角色
获取用户和每个用户目标之间依赖关系的 UML 类图
获取用户和每个用户目标之间依赖关系的 UML 类图

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

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

图 17:用例、用户目标和业务目标之间的关系
描述用例、用户目标,和业务目标之间关系的 UML 类图
描述用例、用户目标,和业务目标之间关系的 UML 类图

所有在本文中显示的图都来自于真实世界的实例,用以研究对其操作性的 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 所需的工具,以及开发可以用于为不同的架构风格生成实现代码的服务实现模型所需的工具。

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=171802
ArticleTitle=统一的基于场景的设计,第 2 部分: 理解客户及用户
publish-date=10312006