基于统一场景的设计(USBD)的 UML 扩展和工具 |
级别: 中级 Alex Donatelli, 高级技术人员, IBM Tivoli Software 2008 年 8 月 07 日 这篇文章是本系列文章的 完结篇,它描述了用于方法学的 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 (基于统一场景的设计)的工具上面,也就是:
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 模型结构的实际的 UML 扩展。 图 1 和图 2 分别显示了完整的元模型图表的左右两个部分。 图 1:对业务处理过程进行建模。 图 2: 根据业务上下文环境获得系统的需求和行为。 关于这些图表,正如在本系列的前几篇文章中我们所看到的:
在一个更低的层次上,重复着同样的逻辑结构(或者结构模式):
在业务层和系统层之间,有两条链接。
您能够在图 1 和图 2 中看到业务工作者(及其操作)和业务角色,并且他们表现了业务层和系统层之间的链接。 但是当系统活动者是一个真实的用户的时候,还有系统设计的另一个方面开始活动。
表 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 扩展以及它们到元模型中概念上的映射。
图 3 显示了用于 USBD (基于统一场景的设计)的 UML 2.0 规范的新模板。表 1中 并没有列出所有的模板。这些仅仅是当您将模型中的元素组织到不同包之中时除了由 WebSphere Business Integration Modeler Nav Tree Profile 所提供的模板之外的其他可选的模板。正如示例模型将要说明的那样,用更加具有描述性的包组织一个模型将大大增强它的可用性。 图 3:UML 规范。 为了能够在规范中使用模板,您需要将其安装到 Rational Software Architect 之中。 安装用于 USBD (基于统一场景的设计)的 UML 2.0 规范 您应当首先在 下载 一节中下载档案文件,并且将其解压缩到本地。然后,您就能够使用通常的操作步骤来安装规范,从而将插件程序安装到 Eclipse 开发平台之上了。 具体的操作步骤如下所示:
在下一小节中,您将看到如何将一个业务处理过程(它在 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 的,这个例子显示了如下内容:
我们还将描述全局知识库 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 模型导入作为一个现已存在的项目:
请注意,在 WebSphere Business Modeler 中所定义的业务模型元素已经被转换到 UML 元素中,并且没有创建任何图表。为了创建图表,需要我们创建一组图表,并且将被转换的元素放至其中。首先,创建一个自由格式的图表,然后将 Business Items 和 Processes 包中的所有条目拖动到该图表之中。图 10 显示了布局改造后的结果。 图 10:由此得到的 UML 项目元素。 请 注意,每一个处理过程都被转换为两个条目:一个 至 此,您已经将相关的业务处理过程的知识导入到 Rational Software Architect 之中,并且您希望通过那些 WebSphere Business Modeler 不打算捕获的概念来增强这些知识。为了能够在我们的模型中使用 USBD (基于统一场景的设计)模板,您首先需要做的就是将用于 USBD 的 UML 2.0 规范添加到这个模型之中。
图 11:将用于 USBD 的 UML 2.0 规范添加到模型之中。 您将首先对业务目标进行建模,尤其是那些对您已经描述过的业务处理过程产生影响的目标。
其结果如图 12 中所示。 图 12:业务目标。 您现在就可以在导入的业务处理过程上进行业务分析,进一步指定处理过程活动。这将允许您决定希望哪些活动被自动执行,从而得出用于相应的软件系统的需求。
图 13:被转换的业务处理过程的摘录。 这 个例子将关注 Schedule Development 全局处理过程,而图 14 显示了在您以同样的方法添加相应的活动图表之后的情况。出于简单性的考虑,这个子处理过程只包含一个任务,此处被转化到一个被称为“为 Batch 创建一个 Schedule 定义”的 Call Operation Action (调用操作活动)。 图 14:Schedule Development 业务处理过程。 您希望进一步分析这个活动及其子任务。您将通过开发一个
处理过程中一个活动的实现是由相应的业务活动者发起的,并且由一组业务工作者执行。将各种协作工作者从模型树中拖动到图表中,从而描述实现该处理过程活动的任务序列。 图 15:为 Batch 活动实现创建一个 Schedule Definition。 您将注意到一个被称为 Workload Scheduler 的新工作者的出现。您已经在
图 16:工作量 Scheduler 用例模型。 现 在,我们希望这些用户对这个系统拥有一个成功和愉快的体验。USBD (基于统一场景的设计)方法论允许您设计这样一个系统,该系统将用户整合到业务处理过程之中,这应当肯定地说是一个成功的体验。然而,您可能还想将人为的 因素考虑进来,从而提供一个有效的、简单的并且舒适的交互作用。 一种方法就是执行 Interaction Design (IaD),它最终定义了 Personas (角色)并且捕获了 User Goals (用户目标)。图 17 中显示了您如何描述模型中的用户目标,并且将系统的用例绑定到这些目标上。尽管这个例子并没有对其加以讨论,但是角色还可以通过使用 USBD 模板被描述和刻画,正如 表 1 中所描述的那样。 图 17:用户目标。 最后,由于用户和系统之间的交互作用将会通过一个用户接口被建立,所以您能够为每一个相关的用例开发一个用例情节串联图板,根据参与的用户接口元素来描述这个交互作用将会如何发生,以及它们将如何被导航。 用例情节串联图板是用例的另一个 您 可以将协作和状态机都模板化为 图 18:创建 Schedule 用例的情节串联图板。 图 19:业务处理过程路线图。
这篇文章是本系列的完结篇,它总结了在 IBM Rome 开发实验室中被成功实践的需求聚集和设计的方法论。 本 文描述了关注于点对点的业务环境(即产品所存在的地方)的基于统一场景的设计(USBD)方法背后的原因,并且提供了将其链接到自动执行业务的系统的上下 文环境中的强有力手段。通过解释如何将业务需要链接到软件执行,本文描述了通过处理过程路线图、目标和类图表来捕获业务处理过程的方式,以及如何通过系统 执行来跟踪它们。本文还讨论了一种用户接口同系统分析相链接的正式的表示法。 本文所关注的重点在于帮助您将 USBD 方法论投入实践的那些工具。本文提供了一个新颖的规范,当您在 IBM Rational Software Architect 版本 7 及其后续版本中将它同 IBM WebSphere Business Modeler 综合特性一起使用时,这个规范允许您以一种正式的方式捕获和描述所有和业务、系统、用户经验层相关的概念。
学习
获得产品和技术
讨论
|
没有评论:
发表评论