基于统一场景的设计从概念到实践.docx

上传人:b****6 文档编号:4724112 上传时间:2022-12-08 格式:DOCX 页数:25 大小:1.57MB
下载 相关 举报
基于统一场景的设计从概念到实践.docx_第1页
第1页 / 共25页
基于统一场景的设计从概念到实践.docx_第2页
第2页 / 共25页
基于统一场景的设计从概念到实践.docx_第3页
第3页 / 共25页
基于统一场景的设计从概念到实践.docx_第4页
第4页 / 共25页
基于统一场景的设计从概念到实践.docx_第5页
第5页 / 共25页
点击查看更多>>
下载资源
资源描述

基于统一场景的设计从概念到实践.docx

《基于统一场景的设计从概念到实践.docx》由会员分享,可在线阅读,更多相关《基于统一场景的设计从概念到实践.docx(25页珍藏版)》请在冰豆网上搜索。

基于统一场景的设计从概念到实践.docx

基于统一场景的设计从概念到实践

基于统一场景的设计:

从概念到实践

 

2008-09-27作者:

AlexDonatelli,RosarioGangemi,ClaudioMarinelli,RobertoLongobardi来源:

IBM

 

本文内容包括:

∙入门简介

∙USBD(基于统一场景的设计)元模型

∙UML2.0扩展

∙用于基于统一场景设计的UML2.0规范

∙从“业务”到“代码”

∙总结

∙下载

∙参考资料

这篇文章是本系列文章的完结篇,它描述了用于方法学的UML扩展和支持工具。

本文将关注点放在支持USBD(基于统一场景的设计)的工具上面,也就是将用于IBM®Rational®SoftwareArchitect版本7以及后续版本的IBM®WebSphere®BusinessModeler集成特性,以及一组UML2.0的扩展放置到一组UML规范之中。

这其中包括一个UML2.0规范以及一个帮助创建BusinessModel、BusinessAnalysisModel、UseCaseModel和UsereXperienceModel的模型模板。

入门简介

在本系列前面的几篇文章中,我们已经描述了一个基于基于场景的设计(ScenarioBasedDesign,SBD)和Outside-InDesign(OID)的一个有效的统一设计方法论。

该方法论被称作基于统一场景的设计(USBD)。

它的关注点在于产品所处的点对点的业务环境,而不是仅仅描述围绕在单一产品周围的业务场景。

通过描述业务需要和软件执行之间的链接方式,这些文章大致描绘出了通过处理过程路线图、目标和类图表捕获业务处理过程的方式,以及如何根据实际执行来跟踪他们。

本系列文章还描述了一种用户接口同系统分析相链接的正式的表示法。

本文将关注点放在支持USBD(基于统一场景的设计)的工具上面,也就是:

∙用于IBM®Rational®SoftwareArchitect版本7及其后续版本的IBM®WebSphere®BusinessModeler综合特性。

∙被捕获到一组UML规范中的一组UML2.0扩展。

WebSphereBusinessModeler综合特性是同RationalSoftwareArchitect相伴而来的,并且被用作讲一个在WebSphereBusinessModeler中被开发的的业务模型导入到RationalSoftwareArchitect之中。

这一特性还包括一个被称作IBM®WebSphere®BusinessIntegrationModelerNavTreeProfile的UML规范,它提供了能够自动被应用于在导入期间被转换的UML类、接口和其他元素的UML模板。

RationalSoftwareArchitect包括另一个被称作BusinessModelingProfile的UML规范,它提供了进一步加强业务模型的其余一组UML模板。

为了通过特定于USBD(基于统一场景的设计)方法论的概念来补足这两个规范,IBM开发了另外一个规范,即用于USBD的UML2.0规范。

它定义了另外一组模板,当它们被应用到类时,接口以及其他的模型元素都根据USBD概念来表现它们。

该规范将和IBM®Rational®SoftwareDeliveryPlatform(例如:

IBM®RationalSoftwareModeler或者RationalSoftwareArchitect)一起被使用。

下一小节将讨论USBD(基于统一场景的设计)的概念,在后面的小节中,我们将描述如何通过前面所提到的三种规范来刻画这些概念。

USBD(基于统一场景的设计)元模型

本小节将通过一个元模型帮助您更好地理解USBD方法论。

这个模型描述了您使用USBD方法论在软件设计(包含业务、用户和系统)及其相互关系中将会捕获到的概念。

该模型包括USBD的分类法和存在论。

用户、目标、处理过程、用户接口面板等概念都被放到一起,它们之间的关系通过一个模型来确定和描述。

该元模型描述了实际的模型将如何使用USBD方法论。

下一小节描述了被用来支持这些概念建模以及USBD模型结构的实际的UML扩展。

图1和图2分别显示了完整的元模型图表的左右两个部分。

图1:

对业务处理过程进行建模。

图2:

根据业务上下文环境获得系统的需求和行为。

 

关于这些图表,正如在本系列的前几篇文章中我们所看到的:

∙一个BusinessProcessMap(业务处理过程路线图)包括一组BusinessProcesses(业务处理过程)。

∙BusinessProcesses(业务处理过程)同BusinessActors(业务活动者)所开启的BusinessUseCases(业务用例)是一一对应的。

∙BusinessEvent(业务事件)是一种特殊的BusinessActor(业务活动者),它也能够开启BusinessUseCases(业务用例)。

∙一个特定的BusinessProcessRealization(业务处理过程实现)就是BusinessRoles(业务角色)执行一组BusinessProcessActivities(业务处理过程活动)。

在一个更低的层次上,重复着同样的逻辑结构(或者结构模式):

∙业务处理过程活动同业务角色所开启的业务处理用例是一一对应的。

∙业务处理用例的存在支持业务目标。

∙业务目标是由您的客户来制定的,并且可以通过测量来被评价。

∙一个特定的业务处理活动实现就是业务工作者执行一组业务处理任务(生产、消费、交换业务实体等)。

∙业务实体同样在一个更高层次上作为实体在业务处理实现之间被交换。

∙由业务工作者所完成的任何一个这样的实现都是一种真实描述一个业务场景的交互作用。

在业务层和系统层之间,有两条链接。

∙业务工作者在一个场景中所执行的某些活动,甚至是所有的活动,都能够被自动地执行。

USBD最佳实践建议:

每一项在业务处理过程活动实现中被自动执行的操作都确定了一个系统活动者(即调用该操作的一方)以及一个系统(即操作提供者),并且能够被映射到一个相应的用例实现上。

因此,每一个被选中为自动执行的业务工作者操作,都映射到系统层上面一个相应的用例实现。

当然,这个用例实现链接到它所实现的用例上面。

∙与此同时,一个用户(一个特定类型的系统活动者)扮演一个业务角色(或者该场景中的业务工作者),并且使用一个系统来执行相应的操作。

您能够在图1和图2中看到业务工作者(及其操作)和业务角色,并且他们表现了业务层和系统层之间的链接。

但是当系统活动者是一个真实的用户的时候,还有系统设计的另一个方面开始活动。

∙进入用户经验的领域,您希望以有目标的角色的形式捕获到用户原型。

∙除此之外,您还需要设计用户接口,图2显示了如何做。

∙用例情节串联模板提供了另外一种描述用例实现的方式。

情节串联模板描述了实现用例的用户接口元素的导航,从而支持相应的用户目标。

UML2.0扩展

表1描述了被引入到UML2.0中的支持USBD(基于统一场景的设计)概念建模的扩展。

BusinessModelingUML2.0规范是由RationalSoftwareArchitect的版本7引入的,与此同时,WebSphereBusinessIntegrationModelerNavTreeProfile同WebSphereBusinessModeler集成在了一起。

下面各小节将向您展示如何向模型中添加所有需要的规范。

表1:

UML2.0扩展以及它们到元模型中概念上的映射。

 

元模型类

UML元类使用

UML原型应用

UML概要文件

用于协作的图

参与者

参与者

-

 

 

业务参与者

参与者

业务建模

 

业务实体

业务建模

 

业务事件

信号

业务建模

 

业务目标

业务建模

 

业务过程

协作

|||

WBIModelerNavTreeProfile|USBD

活动图

业务过程活动

调用行为活动

USBD

 

业务过程活动实现

协作

USBD

时序图

业务过程路线图

协作

USBD

活动图

业务过程实现

协作

USBD

活动图

业务过程任务

消息,操作

N.A.(针对消息),|(针对操作)

USBD|业务建模

 

业务过程用例

用例

USBD

 

业务角色

类,活动划分

(针对类),N.A.(针对活动划分,使用"Represents")

USBD

 

业务用例

用例

业务建模

 

业务执行者

接口

业务建模

 

客户涉众

参与者

USBD

 

度量

属性

USBD

 

操作

操作

-

 

 

人物

类型

|

USBD

 

用例

用例

-

 

 

用例实现

协作

标准

活动图

用例情节板

协作

USBD

状态机图|时序图

用户

参与者

USBD

 

用户目标

USBD

 

用户接口元素

类,状态

USBD

 

用于基于统一场景设计的UML2.0规范

图3显示了用于USBD(基于统一场景的设计)的UML2.0规范的新模板。

表1中并没有列出所有的模板。

这些仅仅是当您将模型中的元素组织到不同包之中时除了由WebSphereBusinessIntegrationModelerNavTreeProfile所提供的模板之外的其他可选的模板。

正如示例模型将要说明的那样,用更加具有描述性的包组织一个模型将大大增强它的可用性。

图3:

UML规范。

 

为了能够在规范中使用模板,您需要将其安装到RationalSoftwareArchitect之中。

安装用于USBD(基于统一场景的设计)的UML2.0规范

您应当首先在下载一节中下载档案文件,并且将其解压缩到本地。

然后,您就能够使用通常的操作步骤来安装规范,从而将插件程序安装到Eclipse开发平台之上了。

具体的操作步骤如下所示:

1.打开Help菜单,并且选择SoftwareUpdates>FindandInstall。

2.下一步,选择SearchforNewFeaturestoInstall,然后点击NewLocalSite。

3.定位到档案文件被解压缩的目录(即site.xml文件所在的目录)。

4.在下一个对话框中,将其命名为USBDProfileSite。

5.点击Finish。

6.在下一个对话框中,展开USBDProfileSite节点,并且选择UnifiedScenarioBasedDesignfeature1.2.0特性。

7.继续完成向导所示的剩余步骤,安装UML规范。

在下一小节中,您将看到如何将一个业务处理过程(它在WebSphereBusinessModelerAdvancedEdition中被建模的)导入到RationalSoftwareArchitect之中,从而得到处理过程的自动部分的需求。

从“业务”到“代码”

基于统一场景的设计提供了一种从业务处理过程中得到软件需求的方法论,并且确保该软件同时满足业务和用户的目标。

假设您的公司拥有一支业务分析和设计团队,他们负责建造通过WebSphereBusinessModeler建模的业务处理过程的一个资产。

这些也许是您所在的公司所采用的的业务处理过程,或者是您的客户所采用的业务处理过程。

在前一种情况中,您可能会希望自动完成处理过程的部分操作,从而提高公司的效率。

在后一种情况中,您可能会成为一个面对这样一项业务的软件公司:

提出一种自动完成客户的处理过程的部分操作的软件解决方案。

图4显示了WebSphereBusinessModeler中的示例业务处理过程模型的内容。

图4:

WebSphereBusinessModeler中的业务处理过程模型的内容。

特别地,图5显示了一个示例Batch和ScheduleDevelopment的业务处理过程。

为了更好的描述在WebSphereBusinessModeler中建模的可能性,并且理解每一项是如何被转化到UML的,这个例子显示了如下内容:

∙用于收集Scheduling需求和收集Batch需求的简单任务。

∙一个用于BatchDevelopment的目标任务。

∙用于ScheduleDevelopmen和ProgramDevelopment的全局处理过程。

我们还将描述全局知识库ScheduleDefinitions、BatchDefinitions和ProgramLibrary将如何在转换中被处理。

图5:

WebSphereBusinessModeler中的Batch和ScheduleDevelopment业务处理过程。

图6展开了ScheduleDevelopment全局处理过程的细节,这些细节将在下一小节中被选为自动处理。

处于简单性的考虑,其中只包括一个活动。

图6:

WebSphereBusinessModeler中的ScheduleDevelopment业务处理过程的细节。

您可以通过将WebSphereBusinessModeler模型导入到RationalSoftwareArchitect之中,将知识传递到您的开发团队,从而提高业务处理过程资产的价值。

在RationalSoftwareArchitect中,您能够通过USBD方法论的额外的语义学来补足知识。

除此之外,在模型元素之间的路线关系将为您提供一幅关于问题的业务、系统和用户经验方面的全景图。

将一个WebSphereBusinessModeler处理过程模型导入到RationalSoftwareArchitect之中

在开始之前,请确保您已将将WebSphereBusinessModeler综合添加到您的RationalSoftwareArchitect安装之中。

通常,您是在安装RationalSoftwareArchitect时指定这个选项的。

如果您并没有这么做的话,那么您能够在稍后使用IBMInstallationManager从RationalSoftwareArchitect安装媒体中将其添加。

在本小节中,您将看到如何导入一个用于“富裕公司”的示例业务处理过程模型,接着前文中所给出的“工作量安排处理过程”的例子。

我们在一个新的工作区中启动一个RationalSoftwareArchitect,并且将其切换到建模视图。

我们现在将WebSphereBusinessModeler模型导入作为一个现已存在的项目:

1.从File菜单中选中Import。

弹出导入对话框,如图7中所示。

图7:

导入WebSphereBusinessModeler项目。

 

2.在General文件夹中,选择ExistingProjectsintoWorkspace,并且点击Next。

3.接下来,指定业务处理过程项目所在的WebSphereBusinessModeler工作区目录。

4.在图8中所示的对话框中,选择您希望导入的项目,以及其内容是应当被复制到RationalSoftwareArchitect工作区中,还是被引用到WebSphereBusinessModeler中。

图8:

选择要导入的WebSphereBusinessModeler项目。

 

5.点击Finish。

业务处理过程模型被转换到UML,并且被导入到RationalSoftwareArchitect工作区中。

图9显示了操作结果。

图9:

在UML中被转换的被导入的项目。

 

请注意,在WebSphereBusinessModeler中所定义的业务模型元素已经被转换到UML元素中,并且没有创建任何图表。

为了创建图表,需要我们创建一组图表,并且将被转换的元素放至其中。

首先,创建一个自由格式的图表,然后将BusinessItems和Processes包中的所有条目拖动到该图表之中。

图10显示了布局改造后的结果。

图10:

由此得到的UML项目元素。

 

请注意,每一个处理过程都被转换为两个条目:

一个和一个,第一个条目是一个UML用例,而第二个条目是一个UML协作。

每一个业务条目都被转换为一个,而每一个角色都被转换为一个

根据USBD(基于统一场景的设计)概念补足业务知识

至此,您已经将相关的业务处理过程的知识导入到RationalSoftwareArchitect之中,并且您希望通过那些WebSphereBusinessModeler不打算捕获的概念来增强这些知识。

为了能够在我们的模型中使用USBD(基于统一场景的设计)模板,您首先需要做的就是将用于USBD的UML2.0规范添加到这个模型之中。

1.在左侧的资源树中,选择UML模型,然后在透视图中选择Profiles标签。

2.点击AddProfile按钮。

弹出如图11中所示的对话框,从中您能够选择USBD规范。

图11:

将用于USBD的UML2.0规范添加到模型之中。

您将首先对业务目标进行建模,尤其是那些对您已经描述过的业务处理过程产生影响的目标。

1.首先在您的UML模型的顶部创建一个包,并且将其命名为BusinessGoals(业务目标)。

2.接下来,通过USBD规范中的模板对其进行刻画。

3.然后,在该包中打开图表,并且创建两个类以反映两个业务目标,并且将它们模板化为

4.然后,您就能够为这些目标添加方法,作为相应的类属性,并且将它们模板化为

5.至此,您需要对建立这些目标的人进行建模,这是因为这是这些人希望收到关于公司如何实现这些目标的报告。

您可以通过向处理过程包中添加一个新的来完成这一操作。

同时,也要将模板添加进去。

其结果如图12中所示。

图12:

业务目标。

您现在就可以在导入的业务处理过程上进行业务分析,进一步指定处理过程活动。

这将允许您决定希望哪些活动被自动执行,从而得出用于相应的软件系统的需求。

1.您首先希望检查Batch和Schedule开发业务处理过程。

因此,展开包,然后是Batch和ScheduleDevelopment——即模板化的UML协作,然后是其中的UML活动。

2.您需要创建一个图表来查看该活动,右键双击活动结点,然后选择AddDiagram>ActivityDiagram。

3.这个新图表中自动加载了UML活动。

打开该图表,如图13所示,您将注意到原始的业务处理过程已经被转换为如下内容:

∙在原始处理过程中被调用的每一个简单任务、全局任务和全局处理过程,都成为新的处理形式中的一个调用操作活动。

∙每一个这样的调用操作活动都被放置到一个泳道中,用来表现执行原始任务或者全局处理过程的原始活动者。

每一个泳道都对应一个相应的业务活动者。

∙原始任务或者全局处理过程的输入和输出都被正确无误地转移到相应的调用操作活动中。

图13:

被转换的业务处理过程的摘录。

这个例子将关注ScheduleDevelopment全局处理过程,而图14显示了在您以同样的方法添加相应的活动图表之后的情况。

出于简单性的考虑,这个子处理过程只包含一个任务,此处被转化到一个被称为“为Batch创建一个Schedule定义”的CallOperationAction(调用操作活动)。

图14:

ScheduleDevelopment业务处理过程。

您希望进一步分析这个活动及其子任务。

您将通过开发一个(一个在表1中被显示的UML协作)来完成这一操作。

1.在进行这一操作之前,您需要分配一个适当的包来包含这些实现,所以我们创建另一个顶层包,并且通过模板来对其进行刻画。

2.此时,您将在一个SequenceDiagram(序列图表)中描述“为Batch创建一个Schedule定义”活动所需要的任务流程,如图15中所示。

处理过程中一个活动的实现是由相应的业务活动者发起的,并且由一组业务工作者执行。

将各种协作工作者从模型树中拖动到图表中,从而描述实现该处理过程活动的任务序列。

图15:

为Batch活动实现创建一个ScheduleDefini

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高中教育 > 理化生

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1