CN101164044A

CN101164044A - 平台无关服务建模技术

Info

Publication number: CN101164044A
Application number: CNA2006800135712A
Authority: CN
Inventors: 阿涅洛·博韦; 汉斯贝亚特·洛卡
Original assignee: UBS AG
Current assignee: UBS AG
Priority date: 2005-04-22
Filing date: 2006-04-21
Publication date: 2008-04-16
Anticipated expiration: 2026-04-21
Also published as: HK1112085A1; CN100573448C; US20060242195A1; WO2006111401A3; US7761844B2; EP1715419A1; WO2006111401A2

Abstract

描述了一种模板驱动系统，用于根据平台无关服务模型而产生平台特定工件，例如程序代码。所述系统包括：模板存储器(102)，具有平台特定模板，每一个模板包括平台特定模型转换信息；仓库(104)，具有多个至少本质上为平台无关的服务模型元素，以及根据所述模型元素而建模的一个或更多个服务模型；以及生成器(106)，适于通过把所述模板中包括的转换信息应用于所述服务模型而生成平台特定工件。

Description

平台无关服务建模技术

技术领域

本发明大体涉及产生平台无关服务模型的领域。更具体地，本发明涉及形成平台特定物理工件(artifact)的基础的平台无关服务模型的产生。

背景技术

软件开发通常以创建逻辑模型而开始，该逻辑模型反映了待开发软件的特定流程的功能性要求。在这种模型驱动方法中，必须把逻辑模型转换为额外地满足非功能性要求的物理表示或工件(例如代码表示)。非功能性要求中存在特定软件和硬件平台的技术性约束，包括必须加以考虑的编程语言。

为了产生物理代码，必须向逻辑模型应用规则和样式集。例如在某些情况下，软件架构定义了不同种类的类(class)。第一种类的类可以表示持久性实体，而第二种类的类表示流程(process)或流程步骤。逻辑模型的特定元素是实体，而流程当然是一个功能性问题。然而，将逻辑实体最终转换为相应的物理表示的方式通常对于所有逻辑实体是相同的，并且对于逻辑流程的转换也是相同的。

为了帮助软件开发者并使软件开发流程中尽可能多的步骤自动化，已经引入生成软件开发方法。生成软件开发利用如下事实：从逻辑模型到物理工件的步骤可以被看作向逻辑模型的各种元素应用转换规则集。所以基本上，需要定义各个转换，指定何时应用，并为逻辑模型标注一些控制信息，该控制信息控制自动化的转换流程。

典型地，通过模板来定义转换。对于需要产生的每一种不同的物理工件，必须提供单独的模板或模板集。该模板包括规定了怎样把逻辑模型的各个元素转换为其物理对应物的转换逻辑。该逻辑模型又包括规定将哪个模板用于特定类型的模型元素的标注。在传统的UML(统一建模语言)的场景下，该标注例如由构造型(stereotype)或标记值所组成。

由于模型中没有定义每个细节，所以可通过在所产生的物理结构中进行编程而定义特定的程序方面。因此，模型可以包括受保护区，在受保护区中，开发者可以直接写入受保护而免于进行转换的程序代码。受保护区确保手动输入的代码在模型中可经受变化。所以，即使模型(例如迭代地)发生变化，受保护区中的代码仍保留在相同的逻辑位置中。

当今，试图把模型驱动开发(MDD)的概念应用于作为所谓的面向服务架构(SOA)的基础的服务范例。SOA旨在通过各个服务而提供复杂软件组件的功能。在SOA的上下文中，可以使用和重新使用各个服务，而不是把相应的程序代码或更常见的物理工件进行复制。这是可能的，因为服务是从特殊的平台特定实现中抽取出的。

在传统的SOA中，各个服务仅被当作具有与其他服务的接口的“黑箱”。换句话说，该服务的内部结构对于SOA的实现并不扮演主要角色。然而，当把MDD的原理应用于各个服务的建模时，服务模型的内部结构当然是重要的方面。

因此，本发明的目的大体上涉及一种MDD与SOA的有效组合。具体地，需要一种针对生成软件开发的有效率的服务建模技术。

发明内容

根据第一方面，提供了一种模板驱动系统，用于根据平台无关服务模型而产生平台特定工件，例如程序代码。所述系统包括：模板存储器，具有平台特定模板，每一个模板包括平台特定模型转换信息；仓库，具有多个至少本质上为平台无关的服务模型元素，以及根据所述模型元素而建模的一个或更多个服务模型；以及生成器，适于通过把所述模板中包括的转换信息应用于所述服务模型而生成平台特定工件。

尽管服务模型和构成服务模型的模型元素可能在最大程度上是平台无关的，然而在一个变体中，模型元素可能与少量平台特定信息相关联。对于例如与属性相对应的模型元素，该平台特定信息可以包括与属性有关的格式信息。

服务模型元素中至少一些可以由两个或更多个服务模型共享。这种针对多个服务模型而重新使用先前定义的模型元素减少了冗余的建模工作量。此外，有利于进行改变管理，因为各个模型元素的改变将自动反映在包括该模型元素的每一个服务模型中。

所述系统还包括服务模型创建器，用于创建至少一个服务模型元素并根据所述服务模型元素而创建平台无关服务模型。所述服务模型创建器的输出优选地存储在所述仓库中。

在一个变体中，所述仓库中包括的服务模型元素具有分层结构。该分层结构便于创建服务模型，且额外地有助于对仓库的内部设计进行结构化。所述仓库可以被配置为数据库(例如关系数据库)。

基于具有分层结构的模型元素，根据较高层级的一个或更多个第一模型元素以及较低层级的一个或更多个第二模型元素，来建模每一个服务。在服务模型中，每一个第一模型元素可与一个或更多个第二模型元素相关联。在这种情况下，所述一个或更多个第二模型元素优选地构成了第一模型元素的属性。

第一模型元素可以定义一个或更多个服务输入参数以及一个或更多个服务输出参数中至少一项。另一方面，第二模型元素可以构成服务输入参数树(tree)和服务输出参数树中至少一项中的叶(leaf)字段。

在其他变体中，所述仓库中的服务模型与映射相关联。所述映射可以出现在两个或更多个模型元素之间，或出现在模型元素和数据库表之间。所述映射可以定义属于相同层级的模型元素之间的转移操作。在一种实现中，所述映射定义了一个或更多个服务输入参数与一个或更多个服务输出参数之间的转移操作。所述输入参数和输出参数可以属于同一个服务，或可选地，属于不同的服务。

对于服务建模，预定义的服务类型和服务公开度(publicity)是可选择的。服务模型创建器则可以允许选择服务类型和服务公开度中的至少一项。优选地，所述服务类型包括以下一种或多种：流程服务、实体服务、呈现服务、技术服务、批作业和查看。在这种情景下，所述模板存储器可包括针对每一个服务类型的至少一个专用模板。因此，所述服务类型可以被解释为转换控制参数。

另外，可定义特定种类的第一模型元素，并可通过服务模型创建器选择用于服务建模。所述种类的第一模型元素可以在生成物理工件时构成转换控制参数。所产生的工件可包括以下中的至少一项：Java代码、Cobol代码、HTML代码和XML代码。

可存在定义了特定服务模型的物理实现的多种预定义平台类型。优选地，所述生成器允许选择平台类型。对于每一种平台类型，所述模板存储器可以包括至少一个专用模板。此外，所述模板存储器可以包括针对服务类型和平台类型的各种组合的至少一个专用模板。

根据本发明的其他方面，提供了一种仓库数据库。所述仓库数据库包括至少本质上为平台无关的模型元素以及根据所述模型元素而建模的服务模型，所述服务模型形成了用于在平台特定模板的控制下生成平台特定工件的基础，每一个模板包括平台特定模型转换信息。

根据本发明的其他方面，提供了一种方法，用于根据平台无关服务模型而产生平台特定工件，例如程序代码。所述方法包括以下步骤：提供平台特定模板，每一个模板包括平台特定模型转换信息；提供多个至少本质上为平台无关的服务模型元素，以及根据所述模型元素而建模的一个或更多个服务模型；以及通过把所述模板中包括的转换信息应用于所述服务模型而生成平台特定工件。

本发明能够以硬件、软件或组合的硬件/软件方法来实践。对于软件方面，提供了一种计算机程序产品。所述计算机程序产品包括程序代码部分，当所述计算机程序产品运行在一个或更多个计算设备上时，所述程序代码部分用于执行本发明的步骤。所述计算机程序产品可以存储在计算机可读记录介质上。

附图说明

下文参考附图中所示的典型实施例来描述本发明，其中：

图1是示出本发明的第一设备实施例的示意性框图；

图2是示出本发明的第一方法实施例的流程图；

图3是示出本发明的第二设备实施例的示意性框图；

图4是示出第二实施例的主要功能的示意图；

图5是示出实施例的上下文以及两个不同的服务建模方法中所使用的迭代开发流程的示意图；

图6是示出实施例中所使用的逻辑数据模型的主要实体的示意图；

图7至9是示出图6中的逻辑数据模型的各个部分的示意图；

图10是示出与两个基础建模方法有关的决策过程的流程图；

图11是示出用于产生服务模型的第二方法实施例的基本步骤的流程图；

图11a是示出这里所用的各种服务的定义的概图；以及

图12至74示出了用于第二方法实施例中的各种用户界面。

具体实施方式

在下文描述中，为了说明而非限制，提出了特定细节，例如步骤的特定次序、用户界面以及设备配置，以提供对本发明的完整理解。对于本领域的技术人员明显的是，本发明可以以不同于这些特定细节的其他实施例来实践。

此外，本领域的技术人员可以理解，下文描述的功能可以使用与编程的微处理器或通用计算机一同工作的软件来实现。还可以理解的是，虽然本发明主要以方法和设备的形式来描述，然而本发明还可以在计算机程序产品或如下系统中体现：该系统包括计算机处理器和耦合至该处理器的存储器，其中，该存储器被编码有可以执行这里公开的功能的一个或更多个程序。

图1示出了用于根据平台无关服务模型而产生平台特定工件的模板驱动系统100的实施例。系统100包括三个主要组件：模板存储器102、仓库数据库104和平台特定工件生成器106。在模板存储器102中存储有平台特定模板。每一个模板包括平台特定转换信息。

仓库数据库104包括多个至少本质上为平台无关的服务模型元素以及根据该模型元素而建模的一个或更多个服务模型。优选地，仓库数据库中所包括的模型元素由若干服务模型共享。这减小了必须存储的模型元素的总数目。

生成器106产生平台特定工件。对此，将模板存储器102中所包括的一个或更多个平台特定模板应用于仓库数据库104中存储的平台无关服务模型。

图2是示出用于根据平台无关服务模型而产生平台特定工件的方法实施例的流程图200。该方法可以由图1所示的系统100或任意其他设备来执行。

该方法在步骤202处开始，提供平台特定模板。每一个模板包括把特定服务模型转换为特定工件所需的平台特定转换信息。

在步骤204，提供多个至少本质上为平台无关的服务模型元素。另外，提供根据该模型元素而建模的一个或更多个服务模型。

在步骤206，产生平台特定工件。为了产生工件，把一个或更多个平台特定模板应用于特定的平台无关服务模型。

图3示出了用于根据平台无关服务模型来产生工件的另一个系统300。该系统300包括针对服务模型(以及服务模型元素)的仓库数据库302，以及用于针对仓库数据库302中存储的服务模型而产生工件308的模板驱动生成器304。服务模型至工件的转换由模板文件306来控制。在本实施例中，针对每一个单独的平台，提供一个或更多个模板文件306的特定集合。如果需要，在把所产生的工件存储到软件组件管理仓库310中之前，可以手动地完成所产生的工件(例如在所谓的受保护区中)。

图4示意性地示出了在上文所述系统100和300中实现从平台无关模型至平台特定工件的方式。从平台无关组件模型开始，首先产生平台无关服务模型。然后把该平台无关服务模型转换为平台特定工件，例如可执行的呈现或应用(业务)服务。

图5的左侧示出了从服务模型开始的服务迭代产生。右侧示出了用于产生物理工件的两个基本方法，即自顶向下方法和自底向上方法。稍后参考图12至74的用户界面来详细描述这些方法。

图6中示出了本实施例中所使用的逻辑数据模型的主要元素。逻辑数据模型提供了仓库数据库302的物理数据库设计的基础。其与实施方式无关，因而使数据库规范和数据库实现之间存在明显的区别。其物理模型更为复杂，而且包含更多的元素，这些元素与存储关于每一个主要元素的所有细节信息有关。然而，图6所示的逻辑数据模型是整个仓库数据库的关键。

一种服务是根据两个基本的分层结构的模型元素而建模的，这两个模型元素即复合类型模型元素(简称为“复合类型”)以及数据项模型元素(或简称为“数据项”)，复合类型模型元素再次包括复合类型的模型元素。这些模型元素在图7中示出。服务与这两个模型元素类别之间的关系通过图8中所示的字段元素来表示。该字段元素是单独数据项的实例，并管理复合类型内的数据项的关系和使用。各个服务之间的关系通过图9中所示的映射元素而表示。

在下文中，参考图10至74来讨论用于产生针对特定软件组件的服务模型的工具。如图10所示，以及在图5的上下文中所提到的，该工具允许两种服务建模方式。图10左侧所示的自顶向下实现用于不存在可重新使用的特有工件的情况下(“绿字段建模”)。图10右侧所示的自底向上实现具有一些先决条件，一些物理实现(例如数据库表描述、源代码、...)将重新用于服务设计(“基于物理工件的建模”)。每一种情况下的元模型(meta model)相同。

首先，参考下表所列和图11所示的步骤来描述自顶向下的实现：

步骤	步骤名称	步骤的描述
步骤	步骤名称	步骤的描述	1	开始新的服务设计	创建新的服务标题
2	服务接口设计	创建新的复合类型创建新的数据项	1	开始新的服务设计	创建新的服务标题
2	服务接口设计	创建新的复合类型创建新的数据项	2a	树建模	利用树编辑器来创建属性

2b	图形建模	利用图形编辑器来创建属性
2b	图形建模	利用图形编辑器来创建属性	3	服务编排	创建映射
4	异常管理	错误消息管理	3	服务编排	创建映射
4	异常管理	错误消息管理	5	文档管理(可选)	文档
6	质量管理(可选)	请求服务版本回顾	5	文档管理(可选)	文档

例如，要为其创建服务模型的服务可以是数据库中顾客地址的变化(mutation)，或搜索满足特定标准的数据库中的顾客。在开始服务建模前，软件开发者必须考虑待建模的服务的接口，即输入和输出参数，并考虑怎样把输入参数传递(“映射”)给输出参数。

现在参考图11中的步骤1，针对特定软件组件(可能包括其他服务)的新服务模型的启动从显示图12所示的图形用户界面开始。图12中的用户界面要求输入下表中所示的服务参数：

ServiceName	明确的服务名称。特定软件组件内的名称和版本必须唯一
ServiceName	明确的服务名称。特定软件组件内的名称和版本必须唯一	Description	服务的简短描述
Version	新服务的版本号(通常是1.0.0，因为是新服务)	Description	服务的简短描述
Version	新服务的版本号(通常是1.0.0，因为是新服务)	ServiceType	在以下之间选择：●实体读服务●实体读列表服务●实体插入服务●实体删除服务●实体更新服务●批程序/作业/服务●流程服务-信息请求●流程服务-处理请求●服务-查看●技术服务●呈现服务

ServicePublicity

在以下之间选择：●软件组件内的局部●软件组件内的局部(出版)●业务域内的局部●业务系统内的局部●业务系统间的全局

该工具支持不同的服务类型和不同的公开度类别。图11a以分层的方式示意性地示出了可以选择的各种服务类型中的一些。呈现服务位于上层。这个服务类型主要提供在向用户请求信息和/或向用户显示信息的上下文中的可视功能。在低层，提供了数据库服务。中层提供了既不是呈现服务又不是数据库服务的一般应用服务(这里有时被称作业务服务)。存在两种类型的应用服务：流程服务和实体服务。实体服务通常进行数据库访问(例如使用相应的数据库服务从数据库读数据或向数据库写数据)。另一方面，流程服务不进行(直接的)数据库访问。其执行一个或更多个专用的处理操作，并包括该任务所需的应用逻辑。

通过图12的用户界面来选择特定的服务类型将会对稍后在把相应的服务模型转换为特定工件时所使用的模板(或模板集)产生影响。换句话说，将会有一个或更多个针对呈现服务的专用模板(例如指定所产生的图形用户界面的可视外观)、一个或更多个针对实体服务的专用模板(例如指定数据库接口)等。

上表中的每一个公开度类别指示服务模型(或其元素)重新使用分层软件环境的可能性，从较低层到较高层来说，该环境包括“软件组件”、“业务域”和“业务系统”。软件组件自身还以如下方式分类：每一个单独的软件组件类别与特定的服务类型子集(以及可选地，公开度类别)相关联。

原理上，服务总是属于特定的软件组件，这意味着通过相关的软件组件来执行服务管理。每一个软件组件都具有所有者，同时该所有者是分配给该软件组件的所有服务的所有者。如上所述，存在不同类别的软件组件(例如后端的应用组件、前端的呈现组件以及针对技术目的的技术组件)。因此，呈现服务可以仅存在于呈现组件内，应用服务可以仅存在于应用组件内，等等。一般说来，特定软件组件的类型控制可能与之相关联的服务类型。例如，呈现服务可能不会存在于应用组件内。另一方面，呈现服务总是请求至少一个应用服务执行后端中的操作(例如后端处理操作或数据库操作)。其原因是，呈现服务不被允许访问数据库或包括后端处理逻辑。这些任务总是由应用/业务服务来执行。

现在回到图12，点击“Next”按钮将导致图13的用户界面。使用这个用户界面，可以选择输入的类型(这里仅有选项“New，emptyinterface”可用)。通过点击“Finish”，该工具创建具有先前用户界面中设置的版本(如果没有改变，则是“1.0.0”)的新服务。为了改变服务参数或向服务添加属性，需要在服务编辑器模块(未示出)中重新打开该服务。图14示出了允许对新产生的服务的“basic data”进行编辑的相应的用户界面。

可以通过图14中所示用户界面左下角的标签“Attributes”来定义与实现(implementation)有关的属性。图15中示出了“Attributes”用户界面。应当注意的是，尽管服务建模在很大程度上是与实现无关的，然而在对服务进行建模时指定少量的与实现有关的信息是有利的。

一旦已经定义了新服务的基本数据和属性，该建模继续进行，把一个或更多个“复合类型”的模型元素与待建模的服务进行关联。已参考图7做出说明，在本实施例的服务模型中，每一个服务必须包括一个或更多个复合类型，而且每一个复合类型可能又包括一个或更多个其他的复合类型。

在详细讨论向服务分配复合类型的模型元素之前，首先讨论与复合类型有关的典型服务建模规则。在本实施例中，定义了三种不同的这种元素：即序列型(图16)、列表型(图17)和选择型(图18)。每一特定种类的复合类型与产生工件时特定的转换操作相关联。因此，与服务类型相似，模型创建期间所指定的复合类型的种类用作后续转换过程的控制参数。

为了更好的理解，在具有地址数据字段的典型上下文中解释不同的种类。

图16示出了序列类的复合类型“Adresse”。这种复合类型包括各个字段的序列(见图8)，这里标为“Address-Element_1”至“Address_Element_4”，如下表所示：

名称	类型	实现名称
名称	类型	实现名称	Adresse	复合类型/序列	ADRESSE
Address_Element_1	字段	ADR-ZEILE-1	Adresse	复合类型/序列	ADRESSE
Address_Element_1	字段	ADR-ZEILE-1	Address_Element_2	字段	ADR-ZEILE-2
Address_Element_3	字段	ADR-ZEILE-3	Address_Element_2	字段	ADR-ZEILE-2
Address_Element_3	字段	ADR-ZEILE-3	Address_Element_4	字段	ADR-ZEILE-4

当码生成器把图16中的复合类型“Adresse”转换为典型文档类型描述(DTD)码时，将产生如下输出(工件部分)：

<！ELEMENT Output(Adresse)>

<！ELEMENT Adresse(Address_Element_1，Address_Element_2，

Address_Element_3， Address_Element_4)>

<！ELEMENT Address_Element_1(#PCDATA)>

<！ELEMENT Address_Element_2(#PCDATA)>

<！ELEMENT Address_Element_3(#PCDATA)>

<！ELEMENT Address_Element_4(#PCDATA)>

当把图16中的复合类型“Adresse”转换为典型COBOL习字本(copybook)码时，将产生如下输出(工件部分)：

*Definition of OUTPUT Interface without flags for

Service*

*RWGStuff

05:BLW:-ADRESSE.

10:BLW:-ADR-ZEILE-1 PIC X(35).

10:BLW:-ADR-ZEILE-2 PIC X(35).

10:BLW:-ADR-ZEILE-3 PIC X(35).

10:BLW:-ADR-ZEILE-4 PIC X(35).

图17示出了列表型的复合类型“Address_Output”。这种复合类型包括一个或更多个序列型的复合类型(包括上述复合类型“Address”)，并还包括下表所示的各个字段(包括列表长度参数)：

名称	类型
名称	类型	Address_Output	复合类型/序列
Address_List_Length	字段/数字	Address_Output	复合类型/序列
Address_List_Length	字段/数字	Address_List	复合类型/序列
Address	复合类型/序列	Address_List	复合类型/序列
Address	复合类型/序列	Address_Element_1	字段
Address_Element_2	字段	Address_Element_1	字段
Address_Element_2	字段	Address_Element_3	字段
Address_Element_4	字段	Address_Element_3	字段

当把图17中的复合类型“Address_Output”转换为典型文档类型描述(DTD)码时，将产生如下输出(工件部分)：

<！ELEMENT Output(Address_Output)>

<！ELEMENT Address_Output(Address_List_Length，Address_List)>

<！ELEMENT Address_List_Length(#PCDATA)>

<！ELEMENT Address_List(Address+)>

<！ELEMENT Address (Address_Element_1，Address_Element_2，Address_Element_3，

Address_Element_4)>

<！ELEMENT Address_Element_1(#PCDATA)>

<！ELEMENT Address_Element_2(#PCDATA)>

<！ELEMENT Address Element_3(#PCDATA)>

<！ELEMENT Address_Element_4(#PCDATA)>

当把图17中的复合类型“Address_Output”转换为典型COBOL习字本码时，将产生如下输出(工件部分)：

*Definition of OUTPUT Interface without flags for Service*

*RWGStuff

05:BLW:-ADDRESS-OUTPUT.

10:BLW:-ADDRESS-LIST-LENGTH PIC 9(6).

10:BLW:-ADDRESS-LIST.

15:BLW:-ADDRESS

OCCURS 1 TO 999 TIMES DEPENDING ON

:BLW:-ADDRESS-LIST-LENGTH.

20:BLW:-ADR-ZEILE-1 PICX(35).

20:BLW:-ADR-ZEILE-2 PICX(35).

20:BLW:-ADR-ZEILE-3 PICX(35).

20:BLW:-ADR-ZEILE-4 PICX(35).

图18示出了选择型的复合类型“Choice”。这种复合类型典型地包括两种或更多种序列型(包括上述复合类型“Address”)，如下表所示：

名称	类型
名称	类型	Choice	复合类型/选择
AdressePrivat	复合类型/序列	Choice	复合类型/选择

Address_Element_1	字段
Address_Element_1	字段	Address_Element_2	字段
Address_Element_3	字段	Address_Element_2	字段
Address_Element_3	字段	Address_Element_4	字段
AdresseGeshaeft	复合类型/序列	Address_Element_4	字段
AdresseGeshaeft	复合类型/序列	Address_Element_1	字段
Address_Element_2	字段	Address_Element_1	字段
Address_Element_2	字段	Address_Element_3	字段
Address_Element_4	字段	Address_Element_3	字段

当把图18中的复合类型“Choice”转换为典型DTD码时，将产生如下输出(工件部分)：

<！ELEMENT Output(Choice)>

<！ELEMENT Choice(AdressePrivat|AdresseGeschaeft)>

<！ELEMENT AdressePrivat(Address_Element_1，Address_Element_2，Address_Element_3，Address_Element_4)>

<！ELEM ENT AdresseGeschaeft(Address_Element_1，Address_Element_2，

Address_Element_3，Address_Element_4)>

当把图18中的复合类型“Choice”转换为典型COBOL习字本码时，将产生如下输出(工件部分)：

*Definition of OUTPUT Interface without flags for Service*

*RWGStuff

05:BLW:-CHOICE.

10:BLW:-ADRESSEPRIVAT.

15:BLW:-ADDRESS-ELEMENT-1 PICX(35).

15:BLW:-ADDRESS-ELEMENT-2 PICX(35).

15:BLW:-ADDRESS-ELEMENT-3 PICX(3S).

15:BLW:-ADDRESS-ELEMENT-4 PICX(35).

10:BLW:-ADRESSEGESCHAEFT.

15:BLW:-ADDRESS-ELEMENT-1 PICX(35).

15:BLW:-ADDRESS-ELEMENT-2 PICX(35).

15:BLW:-ADDRESS-ELEMENT-3 PICX(35).

15:BLW:-ADDRESS-ELEMENT-4 PICX(35).

在一些情况下，服务模型可以重新使用现有的复合类型，在其他情况下，必须创建新的复合类型。对于重新使用，可以从仓库数据库中包括的先前定义的复合类型中简单地选择所需的复合类型。可通过不兼容的公开度而防止重新使用先前定义的复合类型。

现在，在图19至27所示的用户界面的上下文中讨论新的复合类型的创建。新的复合类型的创建(图11中的步骤2)从图19的用户界面开始。这个用户界面请求用户指定新的待创建复合类型的名称，以及该复合类型所要分配给的软件组件。一旦已经输入相应的数据，则可通过点击“OK”按钮来进行保存。

在下一步骤，可通过图20中所示的用户界面来编辑新创建的复合类型。该用户界面允许对复合类型的种类进行选择(即上述的序列、列表或选择型)。另外，图20中的用户界面基本上允许通过图21所示的菜单来创建输入或输出字段。这里，“sibling”创建会创建出相同级别的元素，“child”创建会创建出子辈元素。基于数据项类型的叶属性可以不包括任何子辈元素。

当选择“Create Child”或“Create Sibling”时，提供了5个选项(在图21所示的顶部上，选项“Create Sibling”被禁用)。这在下表中示出：

Fleld-Existing Data Item	基于现有数据项而插入属性
Fleld-Existing Data Item	基于现有数据项而插入属性	Field-Existing ComplexType	基于现有复合类型而插入结构
Field-New SequenceComplex Type	插入子辈元素形成序列的新的复合类型	Field-Existing ComplexType	基于现有复合类型而插入结构
Field-New SequenceComplex Type	插入子辈元素形成序列的新的复合类型	Field-New Choice	插入新的复合类型。在复合类型的具体

Complex Type

实例中，仅呈现一个子辈元素

在图21的用户界面中，如果选择选项“Existing Data Item”，则显示图22的用户界面。图22的用户界面构成了数据项选择对话框，其允许重新使用仓库数据库中所包括的已有数据项。所有当前加载的数据项显示在图21中的用户界面的下部。如果没有显示所需的数据项，则可以基于图22的用户界面的上部中指定的搜索标准而启动对该数据项的搜索。一旦选择将以新创建的复合类型而插入的数据项并点击按钮“OK”，则创建基于所选数据项的复合类型的新字段。在这个上下文中，将会显示图23中的用户界面，并且能够输入该字段的适当名称。

在图21的用户界面中，如果选择选项“Existing Complex Type”，则显示图24的用户界面。图24的用户界面构成了复合类型选择对话框。所有当前加载的复合类型显示在图24的用户界面下部的结果列表中。如果所需的复合类型仍没有显示，则可以基于图24的用户界面的底部中指定的搜索标准而启动搜索。一旦选择将以新创建的复合类型而插入的数据项并点击按钮“OK”，则创建基于所选复合类型的新字段，如图25中所示。

在图21的用户界面中，如果选择选项“New Sequence ComplexType”，则显示图26的用户界面以创建新的复合类型。在图26的用户界面中，新的复合类型可以被赋予有特点的名称，且参数“Kind”被预置为“Sequence”(见图27)。以类似的方式，如果用户在图21的用户界面中选择选项“New Choiee Complex Type”，则参数“Kind”将被预置为“Choice”。

本实施例的建模工具不仅允许创建新的复合类型，而且还允许创建新的数据项(也会存储在仓库数据库中)。在建模工具中，数据项主要用于定义服务参数。服务的输入或输出树中每一个叶均基于数据项。通常，应当尽可能地重新使用现有数据项(如同参考图21至23所述)。然而，仍可能存在这样的情况，即不可避免地要创建新的数据项。新的数据项总是特定数据项，这意味着其在特定域中被创建，但是对于其在其他域中的意义和使用，其可以变为核心数据项。核心数据项表示公司的主要数据字典。

图28示出了允许为新的将要创建的数据项定义数据项属性的用户界面。该属性包括name、description、length、category、parent和software component。在本实施例中，数据项必须总是属于特定的软件组件。初始属性在下表中详细示出：

Name	数据项的名称。该名称应当符合数据项的预定命名规则
Name	数据项的名称。该名称应当符合数据项的预定命名规则	Description	新数据项的描述
SoftwareComponent	允许选择具有新数据项的软件组件	Description	新数据项的描述
SoftwareComponent	允许选择具有新数据项的软件组件	Category	针对新数据项给出的选择是：-核心数据项-特定数据项-技术数据项
Parent Data Item：	除了基本数据项，所有数据项都从父数据项导出	Category	针对新数据项给出的选择是：-核心数据项-特定数据项-技术数据项
Parent Data Item：	除了基本数据项，所有数据项都从父数据项导出	Parent Length	表示父数据项的长度
Length	数据项的长度。该长度必须不为空。其必须小于或等于父长度。其必须不为零。	Parent Length	表示父数据项的长度

一旦已经指定新数据项的参数，则可以点击图28中用户界面的“OK”按钮以创建该数据项。该数据项可以在之后通过图29所示的数据项属性用户界面进行编辑。该用户界面具有5个标签，即“Basic”、“Physical”、“Business”、“GUI”和“Lifecycle”，分别如图29、30、31、32和33所示。

图29所示的“Basic”属性包括如下：

ID	内部标识，不可变
ID	内部标识，不可变	DIC-ID/Version-ID	标识符
Name	数据项的(英文)名称	DIC-ID/Version-ID	标识符
Name	数据项的(英文)名称	Version	版本号
Description	数据项描述	Version	版本号
Description	数据项描述	Parent Data Item	每个数据项必须基于另一个数据项(除了基本数据项)
Format	有效格式，其他地方可以定义	Parent Data Item	每个数据项必须基于另一个数据项(除了基本数据项)
Format	有效格式，其他地方可以定义	Length	有效长度，其他地方可以定义
Valid Value List	有效值列表	Length	有效长度，其他地方可以定义
Valid Value List	有效值列表	Category	新创建的数据项总是特定或技术数据项。数据管理者可以决定将其改变为核心数据项
Software Component	具有数据项的软件组件	Category	新创建的数据项总是特定或技术数据项。数据管理者可以决定将其改变为核心数据项
Software Component	具有数据项的软件组件	Ref Table ID	引用表中保持的代码；这是其标识
Ref Code Value Table	存储有引用值的表的名称	Ref Table ID	引用表中保持的代码；这是其标识
Ref Code Value Table	存储有引用值的表的名称	Ref Data Code Domain	如果数据项表示代码，则是用于解析值的代码域的名称。当点击“Select Domain...”时，弹出可以选择代码域的对话框。
Core Proposal	如果应当把特定或技术数据项提升为核心数据项，则应该选中	Ref Data Code Domain

图30所示的“Physical”属性允许关于新创建的数据项在模型级别上指定一些与实现有关的信息。可以指定的物理属性包括如下：

Context

实现环境；可针对每个上下文

	分别设置物理属性
	分别设置物理属性	Implementation	所选环境(上下文)中数据项的物理名称
Default Impl.Type	所选环境(上下文)中可用数据类型的选择	Implementation	所选环境(上下文)中数据项的物理名称
Default Impl.Type	所选环境(上下文)中可用数据类型的选择	Resulting Type	缺省类型的结果以及与上下文无关的DI定义的长度。这个类型在产生特定上下文的工件期间使用

图31所示的“Business”(或应用)属性包括如下：

Business Rule	定义数据项的有效值、基础标准或内部结构的一个或更多个规则；包括数据项的语法和语义验证
Business Rule	定义数据项的有效值、基础标准或内部结构的一个或更多个规则；包括数据项的语法和语义验证	Ext.Backus Naur Form	根据ISO-EBNF(生产规则)的数据项内部结构的正式定义
Object ConstraintLanguage	约束的正式描述，基于根据OCL的说明性语义	Ext.Backus Naur Form	根据ISO-EBNF(生产规则)的数据项内部结构的正式定义
Object ConstraintLanguage	约束的正式描述，基于根据OCL的说明性语义	Information Object	数据项所属于的来自应用架构的信息对象
Sensitive Data	定义是否对数值进行测试数据匿名	Information Object	数据项所属于的来自应用架构的信息对象

图32所示的“GUI”属性用于控制各个用户界面中数据项的呈现。注意，数据项总是以相同的方式并以相同的标记示出给用户。“GUI”属性包括如下：

Language	业务规则的非正式规定
Language	业务规则的非正式规定	Short Label	GUI中的标签(短版本)

Medium Label	GUI中的标签(中版本)
Medium Label	GUI中的标签(中版本)	Long Label	GUI中的标签(长版本)

图33所示的“Lifecycle”属性反映出特定数据项(“DI”)的当前状态。这些属性主要用于数据项回顾。多数设置仅能够由具有相应授权的用户(“Data Manager”)来设置和改变。“Lifecycle”属性包括如下：

DIC Lifecycle	数据项目录中的生命周期：提议的、注册的、不活动的
DIC Lifecycle	数据项目录中的生命周期：提议的、注册的、不活动的	State	数据项状态的一个值：在开发中的、生产、不活动的
Contact	最初是数据管理者的GPN：向其询问DI的业务含义的人	State	数据项状态的一个值：在开发中的、生产、不活动的
Contact	最初是数据管理者的GPN：向其询问DI的业务含义的人	Data Manager	当创建新数据项时，从父数据项继承来的数据管理者。
Review State	以下数值是可能的：未请求回顾、请求回顾、正在进行回顾、已回顾并接受、已回顾并拒绝、接受的先前版本	Data Manager	当创建新数据项时，从父数据项继承来的数据管理者。
Review State	以下数值是可能的：未请求回顾、请求回顾、正在进行回顾、已回顾并接受、已回顾并拒绝、接受的先前版本	Data ManagementRemarks	回顾期间通常给出的注释
Change Description	最新改变的描述	Data ManagementRemarks	回顾期间通常给出的注释
Change Description	最新改变的描述	Change Request Date	最新改变请求的日期
Version valid since	当前数据项版本有效的起始日期	Change Request Date	最新改变请求的日期
Version valid since	当前数据项版本有效的起始日期	Lifecycle Start Date	DI作为有用社会成员的生命周期的开始
Lifecycle End Date	DI无效的日期	Lifecycle Start Date	DI作为有用社会成员的生命周期的开始

服务的输入和输出参数组成了树结构(其形式为“复合类型”)。它们以类似于文件系统中的文件夹结构的方式而显示在建模工具中。即，复合类型与文件夹相对应，而字段(或属性)与文件相对应。必须将每个字段分配给数据项。

建模工具允许通过树编辑器(图11中的步骤2a)或备选地通过图形编辑器(图11中的步骤2b)来规定输入和输出参数(即创建属性)。在下文中，参考图34至36所示的用户界面来首先讨论树编辑器。

打开服务并连续选择“Interface”(见图14)和“Tree”标签将会打开图34所示的针对输入和输出参数的编辑器。上部中的下拉菜单允许在“Input”和“Output”之间进行切换。左侧框架中示出了输入或输出复合类型各自的结构。在右侧框架中，可以描述所选字段的属性。对左侧框架中所示的复合类型中的元素进行右击，创建新的输入或输出字段(图35)。当选择“Create Child”或“Create Sibling”时(还参见图21和相应描述)，提供了若干可能：

Field-Existing Data Item	插入基于现有数据项的属性
Field-Existing Data Item	插入基于现有数据项的属性	Field-Existing ComplexType	插入基于现有复合类型的结构
Field-New SequenceComplex Type	插入新的复合类型，其子辈形成序列	Field-Existing ComplexType	插入基于现有复合类型的结构
Field-New SequenceComplex Type	插入新的复合类型，其子辈形成序列	Field-New Choice ComplexType	插入新的复合类型。在复合类型的具体实例中，仅存在一个子辈

插入兄弟(sibling)将创建相同级别的元素；插入子辈(child)将创建元素的子辈。当然，基于数据项类型的叶属性可以不包括任何子辈。

应当注意的是，编辑器中不能创建新数据项。新数据项仅能够在数据项资源管理器(explorer)中创建，如上文在图28至33的上下文中所述。此外，不能够在服务或复合类型编辑器中直接改变数据项的属性。图36的用户界面示出了具有“choice”复合类型的元素的“Input”复合类型的示例，如数编辑器所显示。

打开服务并连续选择“Interface”(见图14)和“Graphical”标签将会打开图37所示的针对输入和输出参数的图形编辑器。在图37的图形编辑器中，以其各自的分层结构并行地示出输入和输出参数。不同种类的复合类型可以用不同的颜色以图形的方式来表示。

图37左侧的工具箱允许以如下选项来改变接口：

Select	选择一个或多个图形对象
Select	选择一个或多个图形对象	Marquee	通过向上拖曳矩形来选择对象
New Sequence	把新的序列复合类型放到图表上	Marquee	通过向上拖曳矩形来选择对象
New Sequence	把新的序列复合类型放到图表上	New Choice	把新的选择复合类型放到图表上
Add Complex Type	把现有的复合类型放到图表上	New Choice	把新的选择复合类型放到图表上
Add Complex Type	把现有的复合类型放到图表上	Add Reference	添加从一个复合类型到另一个复合类型的引用，即，向使用第二复合类型的第一复合类型添加字段

如上所述，复合类型可以用作服务的输入和输出参数(或参数集)。现在，映射(图11中的步骤3)定义了怎样把复合类型转为另一个复合类型并主要用于把特定服务的输入参数映射为其输出参数，如图38中所示的两个示范性复合类型。把服务的输入复合类型映射至输出复合类型意味着指定了服务的“算法”。其还意味着可以根据输入直接计算输出，而不需调用另一个服务。映射还用于把特定服务的输入参数映射至数据库表，或把第一服务的输出参数映射至第二服务的输入参数。

在建模工具中，映射在服务编辑器的“Mappings”页上定义。为了由后续的工件生成器进行正确处理，映射必须遵循特定命名惯例，这取决于映射类型。开发者可以为每一个映射定义名称。这些名称不存在技术限制，但应避免特殊符号，因为该名称还将被用作所产生的代码中的名称。如果在特定实体服务中存在多于一个的映射，则相同的名称应当用于所有映射。在流程服务中，相同的名称应当用于两个子步骤映射。

为了创建新的映射，必须点击服务编辑器的“Mappings”页(见图39)中的“Add”按钮。可通过图14所示的用户界面的“Mappings”标签来到达“Mappings”页。响应“Add”按钮的激活，可通过图40所示的窗口来选择映射类型，从而定义映射的主要属性。映射种类对服务代码框架的产生具有影响(如果需要，可以手动地完成“construct”)。这不会影响服务编辑器的功能(例如映射来源、映射目标、映射操作)。

在本实施例中，存在6种映射：Input、Output、Restriction、Substep Input(Invoke或Call)、Substep Output和Internal Mapping。这些映射种类的属性在下表中概括：

Input	使用服务输入或子集而没有任何限制
Input	使用服务输入或子集而没有任何限制	Output	没有限制地把复合类型映射至服务输出
Restriction	对两个复合类型的映射设置约束；在SQL中，这与WHERE子句相对应	Output	没有限制地把复合类型映射至服务输出
Restriction	对两个复合类型的映射设置约束；在SQL中，这与WHERE子句相对应	Substep-InputINVOKE	当调用服务以提供这个服务调用的输入参数时，必须使用
Substep-InputCALL	当调用服务以提供这个服务调用的输入参数时，可以使用(在z/OS中，仅用于相同的业务系统或共享服务)	Substep-InputINVOKE	当调用服务以提供这个服务调用的输入参数时，必须使用
Substep-InputCALL	当调用服务以提供这个服务调用的输入参数时，可以使用(在z/OS中，仅用于相同的业务系统或共享服务)	Substep-Output	必须使用以获取服务调用的输出参数
Internal-Mapping	内部处理的助手映射(Helper mapping)	Substep-Output	必须使用以获取服务调用的输出参数

如上所述，映射还可以用作两个单独服务之间转移数据的工具。图41示出了典型的场景。该示例示出了如何在服务“GetSingleKunde_Vl_0”(B)内调用服务“GetItemList_Vl_0”(A)。第一映射用于调用服务“B”，第二映射用于把服务“B”的结果返回服务“A”。图42中示出了相应的用户界面。首先，把服务“A”的输入复合类型映射到服务“B”的输入复合类型，以便向服务“B”提供所需信息。接下来，把服务“B”的输出复合类型映射到服务“A”的输出复合类型。这意味着把参数从被调用的服务“B”转移到“A”的输出参数(参见图43)。

映射来源(source)和映射目标(target)可以手动地选择，也可以通过图39、42和43所示的用户界面的“Use Service”按钮来选择。然后，出现搜索对话框，其允许作为子步骤而选择服务。在该选择得以确认后，提供映射来源和映射目标，如图44的用户界面所示。该用户界面提供了如下选项：

Use Input	使用服务输入
Use Input	使用服务输入	Use Output	使用服务输出
Use Other...	使用另一个复合类型。打开搜索窗口以查找复合类型	Use Output	使用服务输出

除了定义映射来源和映射目标外，还必须定义映射操作。映射操作定义了怎样把单独的输入字段转移至输出字段。图45示出了在其中示出复制操作的用户界面。该操作例如可用于：通过一个或更多个实体服务和/或流程服务，在数据库和呈现服务之间转移数据。

在图45的用户界面中，通过点击映射来源部分中的一个字段、映射目标部分中的一个字段，并通过激活“Add”按钮而向服务添加映射。如果需要，也可以定义更为复杂的操作。

该建模工具额外还允许针对待建模的服务的错误消息管理。现在，参考图46至52中的用户界面来详细描述错误消息管理(图11中的步骤4)。

在图14所示的服务编辑器起始页中，可通过“Error Messages”标签到达相应的“Error Messages”页(图46中所示)。已针对特定服务而定义的错误消息自动显示在表“Associated user errormessages”中。图46的用户界面示出了在任何消息与典型(业务)服务GetAddressingImageList相关联之前的页。

与业务服务相关联的消息有两种：Subcomponent-specific消息和Common消息。Subcomponent-specific消息可通过点击按钮“GAC消息...”而与服务相关联，其中<GAC>是定义了服务的软件子组件ID。同样，Common消息可通过点击按钮“Common messages...”而与服务相关联。点击这两个按钮中任一个都会导致图47所示的对话框用户界面。

对话框用户界面左手侧的表示出了与子组件相关联的所有可能的消息(或在“Common messages”场景中为Common消息)。选择表中的行会在该对话框的右手侧上显示消息概要。用户界面可能不显示消息，而是显示空表，其指示没有针对该子组件定义错误消息。

当打开对话框时，检查与服务相关联的消息。为了指明消息应当与服务相关联，必须对消息的复选框(checkbox)做出标记。为了指明消息应当不与服务相关联，必须清除消息的复选框。最后，为了做出关联，必须点击“Associate messages”按钮。

图48示出了添加Subcomponent-specific消息和Common消息后的原始编辑器屏幕。图48所示的用户界面提供以指示“MessageSeverity”。对于每一个消息，可以选择如下选项之一：“Warning”、“Exception”或“Severe”。

如上面在映射的上下文中所述，服务可以调用附加服务。这些调用在服务编辑器的“Mappings”标签中定义。在创建服务映射后，可以重新打开待调用的服务。在标签“Mapping”中，列出了被调用的服务的所有错误消息。建模工具提供了把这些“子辈”错误消息映射为属于作业中的服务的任何现有错误消息的可能，如图49所示。在这个上下文中，首先可以选择一个或更多个子辈消息，然后选择选项“Mapto...”，并从列表中选出一个错误消息，如图50中所示。子辈消息将被映射到所选消息。在这个动作之后，相应的信息将会显示在列“Mappedto”中，如图51所示。在标签“ErrorMessages”上，对子辈消息进行映射的所有消息被标有选中标记(见图52)。另外，提供了一种用于消除映射的机制。

最为示例，当产生Cobol服务代码时，对于每一个错误消息，可以把如下注释写入来源：

*<SwscId>:<MessagId><Productive text in english>

相应的输出代码看起来如下：

productive Application Error Messages to use for this Service:

*--------------------------------------------------------------

*GAC:00001 Invalid input data:{Field}

*GAC:00011 CIF Root{Root}，{Cinr}don’t exist or has no business

relationship

*GAC：00012 Business relationship{Busrel-ID}don’t exist

*GAC:00013 The relationship management{Role-OE-Krz}already exists

一旦为特定服务指定了错误消息，则完成从顶向下建模，而且该服务模型可以转移到用于产生所需工件的生成器。

作为上文讨论的从顶向下建模方法的替代，可以使用从底向上建模(见图5和10)。这种建模类型使用先前定义的一些工件，以确保仓库元信息的自动填写(fill-out)。该自动流程被称作向导。针对本实施例的建模工具定义了如下向导。

向导名称	描述
向导名称	描述	创建呈现服务	从业务组件开始创建呈现服务
创建实体服务	导入数据库表并创建实体服务	创建呈现服务	从业务组件开始创建呈现服务
创建实体服务	导入数据库表并创建实体服务	创建基于DTD的服务	导入DTD
创建基于习字本的服务	导入Cobol习字本	创建基于DTD的服务	导入DTD

现在从使用应用组件创建呈现服务开始，分别描述上表中所示的4个向导中每一个的操作。

为了根据后端应用(业务应用或技术应用)而创建呈现服务，首先必须创建呈现组件。建模工具可以从现有应用服务中创建呈现服务(例如WPS)。在这个上下文中，首先必须选择应用服务。一旦已经选择应用服务，必须选择容器，即针对呈现服务的软件子组件。图53的用户界面示出了建模工具关于此而提供的搜索功能。由于这里仅允许业务应用和技术应用，所以这些种类的软件组件自动地进行设置。图53的用户界面允许搜索期望的软件组件。通过点击‘OK’，可以选择软件组件，并将其分配作为呈现服务的容器。

接下来，需要通过图54的用户界面选择呈现服务类型。缺省的呈现服务类型是“Simple”。可以额外输入呈现服务的版本。在“Simple(Get，Open or Delete)”呈现服务(“simple”，例如关于相应的数据库操作)的情况下，将显示图55所示的确认对话框用户界面。在更为复杂的呈现服务(例如“Modify”呈现服务)的情况下，将需要启动额外的步骤，这里不做详细讨论。点击“Finish”按钮开始创建所请求的呈现服务。由此，针对建模工具的仓库数据库中的呈现服务而创建元素(对象)，而且呈现服务出现在软件组件资源管理器中的所选应用和软件子组件之下，如图56中所示。在图56中，数字(1)表示遵循简单呈现服务指令而创建的呈现服务，而(2)表示遵循“modify”呈现服务指令而创建的呈现服务。

如上所述，对于从底至下建模，定义了其他向导以导入数据库表并创建实体服务。例如，基于DB2表定义，可以产生所谓的DCLGEN文件，其包含表的描述以及至Cobol习字本的映射。这个文件可以用于导入建模工具中的表定义。DB2表在建模工具中表示为复合类型。从DCLGEN文件中创建该复合类型开始于图57所示的表选择对话框。DCLGen文件的目录应当已经包含正确的路径，例如

″|DataSets|Shrxtc1|SHRXTC1.TRO.DO.DCLGEN″.

输入DCLGEN文件名样式(pattern)将会刷新可用表的列表。选择一个或更多个表并点击“Import”按钮将开始创建针对每一个DCLGEN文件的新的复合类型。

在下一步中，可以选择一个或更多个已创建的复合类型，从而创建实体服务(见图11a)。可通过图58所示的用户界面来定义针对所选复合类型的实体服务。存在如下选项：

实体服务类型(Read、Search等)	实体服务的类型：●读(“Get”)对象●搜索(“GetList”)对象●插入(“Open”)新对象●更新(“Modify”现有对象)●删除(“Close”)现有对象
实体服务类型(Read、Search等)		Service Name	实体服务的逻辑名称
Service Version	服务版本	Service Name	实体服务的逻辑名称
Service Version	服务版本	Module Name	可选的模块名称
Item Name	仅当选择“Search”作为服务类型时才可用。定义了用于结果列表的名称。例如，ItemName＝“Partner”导致图59所示的服务结果列表的复合类型	Module Name	可选的模块名称
Item Name		Fields for Where-Clause	所产生的实体服务的输入复合类型。图60示出了该示例的配置。
Fields in Output	所产生的实体服务的输出复合类型。图61示出了该示例的配置。	Fields for Where-Clause	所产生的实体服务的输入复合类型。图60示出了该示例的配置。

在提供必需的数据后，软件组件释放，并通过图62所示的用户界面来选择其中将要创建实体服务的子组件。可通过使用“Search”按钮来打开该释放(如果其没有被打开)。点击“Create”将会在所选的软件子组件中创建实体服务，如图63所示。如果新创建的实体服务已打开且显示“Mapping”页，则定义两个映射，如图64和65所示。

在下文中，将参考现有DTD的导入而说明自底向下建模的另一个示例。为创建新的流程服务，首先必须在建模工具的软件组件资源管理器中打开软件组件释放。然后，选择应提供待创建服务的软件子组件(服务提供者)。图66所示的用户界面允许选择包含现有DTD的一个或更多个输入文件。在已经执行选择后，点击“Next”按钮将启动解析或所选DTD。然后，通过图67所示的用户界面来显示将被创建的复合类型。导入机制对所有等同的复合类型进行融合(merge)。点击“Finish”按钮启动该导入流程。在完成导入后，服务在软件组件资源管理器中显示，如图68所示。

现在，参考现有习字本文件的导入来说明自底向下建模的其他示例。为创建新的流程服务，必须在软件组件资源管理器中打开软件组件释放。然后，需要选择应提供待创建服务的软件子组件(服务提供者)。可通过图69所示的用户界面来执行Cobol习字本文件的导入。这个用户界面提供了如下选项。

SoftwareSubcomponent	预置为所选子组件。点击“Select...”打开Open Subcomponent对话框
SoftwareSubcomponent	预置为所选子组件。点击“Select...”打开Open Subcomponent对话框	Service Name	将要创建的服务名称
Service Version	将要创建的服务版本	Service Name	将要创建的服务名称
Service Version	将要创建的服务版本	ServiceDescription	新服务的描述
Service Type	实体读服务实体读列表服务实体插入服务实体删除服务实体更新服务批程序/作业/服务业务流程服务-信息请求业务流程服务-处理请求服务-查看技术服务	ServiceDescription	新服务的描述

Service Publicity	服务的公开度
Service Publicity	服务的公开度	Input CopyBook	针对输入的习字本结构；见下
Output CopyBook	针对输出的习字本结构	Input CopyBook	针对输入的习字本结构；见下
Output CopyBook	针对输出的习字本结构	Indicator Flags	忽视所选习字本中找到的指示符标志

对于输入和输出习字本文件，必须通过图70的用户界面来选择文件(扩展名为“.cpy”或“.cob”)。在设置所有字段后，“ImportDefinition”看起来可能如图71所示。利用“OK”关闭这个对话框，这个特定导入将显示为习字本导入对话框中的一行(见图72)。如图73所示，接下来的任务是向习字本中每个字段分配数据项(缺省地，所有数据项被分配给“Generic Data Item”)。如果将把一个或更多个字段分配给现有数据项，则可以通过“Link selected item(s)toexisting Data Items...”按钮启动相应的步骤，这会引出数据项选择对话框。如果针对一个或更多个字段创建新的数据项，这可以通过图73的用户界面的相应按钮而开始。在完成这些分配后，点击“Finish”完成操作，而且还完成了服务模型的自底向上的产生。

不考虑其创建(自顶向下或自底向上)，服务模型及其单独的模型参数将至少暂时存储在图3中所示系统的仓库数据库302中。如果需要特定的工件，则生成器304可以在任意时刻从仓库数据库302中获取服务模型。然后，生成器选择与基础服务类型和所请求的工件类型(例如Java代码)相关联的一个或更多个模板文件306，并在所选模板文件306的控制下将服务模型转换为工件。因此，同一个模型可以形成产生不同类型工件的基础，包括代码、测试案例、以及例如服务的物理描述的规范。对于这些类型的工件中的每一种，提供了一个或更多个专用的模板文件306。

在一些情况下，所产生的工件可以是构造(construct)(框架)，其通过在该构造的受保护区中输入代码(例如特定的应用逻辑)而手动地完成。该建模方法所具有的优点是，该服务模型与应用逻辑无关，这极大地便利了服务模型及其模型元素的重新使用。此外，应用逻辑的修改不需要改变基础服务模型。

从上文中明显看出，中央仓库数据库的提供允许有指导地并高度结构化地创建服务模型。可确保的是，先前定义的模型元素，例如复合类型和数据项，可以在软件开发者和软件开发项目之间共享。这种共享增加了可用模型元素的重新使用，因而减小了建模过程的冗余。

应当注意的是，在较大的软件开发环境中，中央仓库数据库可能包括多于5000个服务，多于25000个复合类型，以及多于5000个数据项。从这些数字中可以看出中央仓库的优点。在仓库中对服务模型和模型元素进行管理比管理相应的物理工件要容易得多(而且消耗更少的资源)。为此，仓库中每一个元素(服务、复合类型、数据项)可以和唯一的标识符相关联。该标识符便于改变管理，并允许(自动)改变修改。每一个仓库元素可以额外地和(重新使用)使用指示符相关联。这个指示符可以用于仓库管理，例如对于在特定时段内没有使用的元素进行删除和/或归档。此外，可以定义授权简档，其指示单独的软件开发者的(重新使用)使用权。

这里描述的再生软件开发方法利用高度结构化的仓库数据库以助于创建服务模型，其表示用于实现SOA的有利的模型驱动方法，即通过单独的可执行服务、而不是通过例如面向对象(OO)的方法中的对象来进行通信的体系结构。本领域的技术人员可以理解，上述方法和设备可以以各种方式进行调整或扩展。虽然上文描述参考了优选实施例，然而本发明的范围仅由所附权利要求以及这里引述的要素来限定。

Claims

1.一种模板驱动系统(100)，用于根据平台无关服务模型而产生平台特定工件，例如程序代码，所述系统包括：

-模板存储器(102)，具有平台特定模板，每一个模板包括平台特定模型转换信息；

-仓库(104)，具有

i.多个至少本质上为平台无关的服务模型元素，以及

ii.根据所述模型元素而建模的一个或更多个服务模型；以及

-生成器(106)，适于通过把所述模板中包括的转换信息应用于所述服务模型而生成平台特定工件。

2.根据权利要求1所述的系统，

其中，所述服务模型元素中至少一些由两个或更多个服务模型共享。

3.根据权利要求1或2所述的系统，

还包括服务模型创建器，用于根据所述服务模型元素而创建服务模型元素和平台无关服务模型中的至少一项。

4.根据权利要求1至3中任意一项所述的系统，

其中，所述仓库中包括的服务模型元素具有分层结构。

5.根据权利要求4所述的系统，

其中，根据较高层级的一个或更多个第一模型元素以及较低层级的一个或更多个第二模型元素，建模每一个服务。

6.根据权利要求5所述的系统，

其中，在所述服务模型中，每一个第一模型元素与一个或更多个第二模型元素相关联，所述一个或更多个第二模型元素构成了第一模型元素的属性。

7.根据权利要求5或6所述的系统，

其中，第一模型元素定义了一个或更多个服务输入参数以及一个或更多个服务输出参数中的至少一项。

8.根据权利要求5至7中任意一项所述的系统，

其中，第二模型元素构成服务输入参数树和服务输出参数树中的至少一项中的叶字段。

9.根据权利要求1至8中任意一项所述的系统，

其中，所述仓库中的服务模型与两个或更多个模型元素之间或模型元素与数据库表之间的映射相关联。

10.根据权利要求9所述的系统，

其中，所述映射定义了属于相同层级的模型元素之间的转移操作。

11.根据权利要求9或10所述的系统，

其中，所述映射定义了一个或更多个服务输入参数与一个或更多个服务输出参数之间的转移操作。

12.根据权利要求11所述的系统，

其中，输入参数和输出参数属于不同的服务。

13.根据权利要求1至12中任意一项所述的系统，

其中，预定义的服务类型可被选择用于服务建模。

14.根据权利要求13所述的系统，

其中，所述服务类型包括以下一种或多种：流程服务、实体服务、呈现服务、技术服务、批作业和查看。

15.根据权利要求13或14所述的系统，

其中，所述模板存储器包括针对每一个服务类型的至少一个专用模板。

16.根据权利要求1至15中任意一项所述的系统，

其中，存在多个预定义的平台类型。

17.根据权利要求16所述的系统，

其中，所述模板存储器包括针对每一个平台类型的至少一个专用模板。

18.根据权利要求16所述的系统，

其中，所述模板存储器包括针对服务类型和平台类型的各种组合的至少一个专用模板。

19.根据权利要求3至18中任意一项所述的系统，

其中，所述模板创建器允许选择服务类型和服务公开度中的至少一项。

20.根据权利要求1至19中任意一项所述的系统，

其中，所述生成器允许选择平台类型。

21.根据权利要求5至20中任意一项所述的系统，

其中，定义特定种类的第一模型元素，并可通过用于服务建模的服务模型创建器来选择。

22.根据权利要求1至21中任意一项所述的系统，

其中，所产生的工件包括以下至少一项：Java代码、Cobol代码、HTML代码和XML代码。

23.一种仓库数据库(302)，包括至少本质上为平台无关的模型元素以及根据所述模型元素而建模的服务模型，所述服务模型形成了用于在平台特定模板的控制下生成平台特定工件的基础，每一个模板包括平台特定模型转换信息。

24.一种方法，用于根据平台无关服务模型而产生平台特定工件，例如程序代码，所述方法包括：

-提供平台特定模板，每一个模板包括平台特定模型转换信息；

-提供

i.多个至少本质上为平台无关的服务模型元素，以及

ii.根据所述模型元素而建模的一个或更多个服务模型；以及

-通过把所述模板中包括的转换信息应用于所述服务模型而生成平台特定工件。

25.一种包括程序代码部分的计算机程序产品，当所述计算机程序产品在一个或更多个计算设备上运行时，所述程序代码部分用于执行权利要求24所述的步骤。

26.根据权利要求25所述的计算机程序产品，其存储在计算机可读记录介质上。