CN101946261A - 基于计算机的业务过程的自动化模型产生 - Google Patents

Abstract

一种用于产生表示现有基于计算机的业务过程的模型的系统涉及分析添加有注释(920)的现有源内容(910)以提供用于建模的信息。对注释的静态分析可以提供一些信息。如果注释更改运行时间行为以产生示出所述行为的监视事件，则可以在运行时间发现其它信息。注释不需要被限制为源内容的语言的代码或符号或结构，并且可以使用与正产生的模型中的那些概念更接近的概念。使用注释而不是手动建模可以减少错误并且导致从模型更好地预测性能，并且导致软件或计算基础设施的更好的重新配置从而更高效地使用共享资源。

Description

基于计算机的业务过程的自动化模型产生

相关申请

本申请涉及题为“MODEL BASED DEPLOYMENT OF COMPUTER BASED BUSINESS PROCESS ON DEDICATED HARDWARE”(申请人参考编号200702144)、题为“VISUAL INTERFACE FOR SYSTEM FOR DEPLOYING COMPUTER BASED PROCESS ON SHARED INFRASTRUCTURE”(申请人参考编号200702356)、题为“MODELLING COMPUTER BASED BUSINESS PROCESS FOR CUSTOMISATION AND DELIVERY”(申请人参考编号200702363)、题为″MODELLING COMPUTER BASED BUSINESS PROCESS AND SIMULATING OPERATION″(申请人参考编号200702377)、题为“SETTING UP DEVELOPMENT ENVIRONMENT FOR COMPUTER BASED BUSINESS PROCESS”(申请人参考编号200702145)、和题为“INCORPORATING DEVELOPMENT TOOLS IN SYSTEM FOR DEPLOYING COMPUTER BASED PROCESS ON SHARED INFRASTRUCTURE”(申请人参考编号200702601)的同一日期的共同待决美国申请、以及题为“DERIVING GROUNDED MODEL OF BUSINESS PROCESS SUITABLE FOR AUTOMATIC DEPLOYMENT”(序列号11/741878)的先前提交的美国申请，上述申请全部整体地通过引用结合到本文中。

技术领域

本发明涉及产生模型的方法并且涉及对应的系统和软件，其中所述模型表示具有若干功能性步骤的基于计算机的业务过程(business process)的至少一部分，所述模型是根据指定所述功能性步骤的现有源内容以及根据实施所述功能性步骤的软件实体的源内容而产生的。

背景技术

物理IT(信息技术)基础设施难以管理。改变网络配置、添加新机器或存储设备通常是复杂且容易出错的手动任务。在大多数物理IT基础设施中，资源利用率非常低：对于服务器而言，15％的利用率并不罕见，对于台式计算机而言则是5％。为了解决此问题，现代计算机基础设施正在变得越来越可(重新)配置，并且以由服务提供商提供的数据中心的形式更多地使用共享基础设施。

Hewlett Packard的UDC(公用数据中心)是已在商业上应用并允许物理基础设施：诸如服务器的处理机器、诸如盘的存储设备、和耦合各部分的网络的自动重配置的示例。重配置可以涉及例如移动或启动软件应用、改变存储空间分配、或改变对不同过程的处理时间的分配。贡献更多可重配置性的另一种方式是通过允许在单个物理机上主控许多“虚拟”计算机。术语“虚拟”通常意指真实或物理的反面，并且在存在一定水平的间接性、或资源用户与物理资源之间的某种调解的情况下使用。

另外，某些现代计算架构允许重配置底层硬件。在一种情况中，可能将该架构配置为提供若干四路计算机。在另一种情况中，可能将其重配置为提供四倍的单处理器计算机。

对上述完全可重配置性进行建模是极其复杂的。较高级实体的模型在包含或引用用来实现它们或实现它们所需的较低级实体的意义上需要是递归的(例如，虚拟机VM，可以根据当前使用什么底层基础设施来实现它(例如，如下文将更详细地描述的，硬件分区nPAR或虚拟分区vPAR)而较快或较慢地操作)。这意味着模型需要展现出下一代计算机架构的底层可配置性-nPAR由特定的硬件分区组成。这使得模型如此复杂，以致于变得越来越难以让自动化工具(和人)理解并处理模型，以实现a)业务过程，b)应用和应用配置，以及c)基础设施和基础设施配置的设计和管理。在DMTF的用于“System Virtualization，Partitioning and Clustering”的简档：http://www.dmtf.org/apps/org/workgroup/redundancy/中举例说明了对系统的完全可重配置性和递归性质进行建模的需要。

建模方面的困难的另一示例是WO2004090684，其涉及对系统进行建模以便执行处理功能。它记载了“潜在的大量组件可能使得该方法不切实际。例如，具有所有其硬件组件、主机、交换机、路由器、台式计算机、操作系统、应用、业务过程等的IT系统可以包括几百万个对象。可能难以采用任何手动或自动化方法来创建此类大量组件及其关系的单体模型。这个问题由于具有频繁添加/移动/改变的IT系统的典型动态性质而复杂化。其次，不存在细节的隐藏或抽象化，以允许处理功能在隐藏较不相关的组件细节的同时集中于特定的一组相关组件的细节。第三，由于所涉及的组件的数目，在整个系统上执行任何处理可能是不切实际的。”

已经进行了自动且快速地提供计算基础设施的尝试：惠普的公用数据中心、惠普实验室的SoftUDC、惠普的Caveo和Amazon的弹性计算云(可以在http://www.amazon.com/gp/browse.html？node＝201590011处看到)。所有这些提供一种或另一种形式的计算基础设施，并且某些已针对测试者和开发者，例如惠普的公用数据中心。

来自IDS-Scheer的Aris是一种已知的业务过程建模平台，其具有包含关于系统的结构和预期行为的信息的模型仓库。特别地，更详细地对业务过程进行建模。其意图将系统实现方式和文档资料(documentation)的所有方面绑在一起。

Aris UML设计器是Aris平台的组件，其将传统业务过程建模与软件开发相组合以开发从过程分析到系统设计的业务应用。用户经由web浏览器来访问过程模型数据和UML内容，从而实现多用户环境内的处理和改变管理。其可以提供开发文档资料的创建和传送，并且可以链接面向对象的设计和代码生成(CASE工具)。其依赖于模型的人类输入。

发明内容

目的在于提供改进的装置或方法。在一个方面，本发明提供了：

一种产生模型的方法，其中所述模型表示具有若干功能性步骤的基于计算机的业务过程的至少一部分，所述模型是根据指定所述功能性步骤的现有源内容以及根据实施所述功能性步骤的软件实体的源内容而产生的，所述源内容添加有注释，以提供用于建模的信息，该方法具有以下步骤：

收集由所述注释提供的信息，以及

使用由收集器收集的信息来产生所述功能性步骤和实施所述功能性步骤的软件实体的表示，并且被布置为将这些表示合并到所述模型中。

使用注释来发现关于业务过程和实施功能性步骤的软件实体的信息可以使得能够更高效且灵活地实施建模，因为注释不需要被限制为源内容的语言的代码或符号或结构。因此，注释可以使用与正产生的模型中的那些概念更接近的概念。与手动产生模型相比，需要来自缺乏经验人员的较少输入，并且可以减少错误的风险，导致从模型更好地预测性能。这进而可以导致软件或计算基础设施的更好或最好的配置，其可以导致更高效地使用可用资源进行现场部署，并且因此导致更低成本。这对于其中许多业务过程共享可用资源的常见情况尤其有用。

本发明的实施例可以具有任何附加特征，而不脱离权利要求书的范围，并且在从属权利要求和在下述的实施例中阐述一些这样的附加特征。

另一方面提供了机器可读介质上的软件，所述软件在执行时实施上述方法。

另一方面提供了一种用于产生模型的系统，其中所述模型表示具有若干功能性步骤的基于计算机的业务过程的至少一部分，所述模型是根据指定所述功能性步骤的现有源内容以及根据实施所述功能性步骤的软件实体的源内容而产生的，所述源内容添加有注释，以提供用于建模的信息，该系统具有：收集器，布置为收集由所述注释提供的信息；以及建模器，布置为使用由收集器收集的信息来产生所述功能性步骤和实施所述功能性步骤的软件实体的表示，并且布置为将这些表示合并到所述模型中。

其他方面可以涵盖使用该系统的人类操作员所进行的对应步骤，以在侵权者的系统部分地或主要地远离本专利所覆盖的权限范围并且在该权限范围之外(如许多此类系统都可行的那样)然而人类操作员正在该权限范围内使用该系统并且从中获益的情况下使得能够直接侵权或引起直接侵权。特别是优于其他现有技术的其它优点对于本领域的技术人员来说将是显而易见的。如对于本领域的技术人员来说显而易见的那样，可以将任何附加特征组合在一起，并与任何方面组合。所述实施例仅仅是示例，范围不受这些示例的限制，并且在权利要求的范围内可以设想许多其它示例。

附图说明

现在将参照附图以示例的方式描述本发明的特定实施例，在附图中：

图1示出实施例的示意图，其示出模型、自适应基础设施和管理系统，

图2示出根据实施例的由操作员和管理系统进行的某些操作步骤的示意图，

图3示出根据实施例的某些主要动作和模型的示意图，

图4示出根据另一实施例的采取模型信息流MIF的形式的从业务过程到已部署模型的步骤序列的示意图，

图5示出根据另一实施例的模型和步骤序列，

图6示出根据实施例的导出植基模型(grounded model)的步骤，

图7示出根据实施例的用于分布式设计的主应用服务器和从应用服务器的布置，

图8示出图7的实施例的主应用服务器的各部分，

图9示出供在实施例中使用的服务器上的虚拟实体的布置，

图10示出销售和分销业务过程(SD)基准(Benchmark)对话步骤和事务(transaction)的示例，

图11示出用于SD Benchmark的示例性定制模型实例，

图12示出用于未绑定模型(unbound model)类的类图示，

图13示出适合用于分散式SD示例的模板的示例，

图14示出分散式SD的植基模型实例，

图15示出适合用于集中式安全SD示例的模板的另一示例，

图16示出了用于基于注释产生模型的系统的实施例的概图，

图17示出了根据实施例的主要步骤中的一些，

图18示出了与从注释源内容静态产生文档资料、自动化模型以及可执行代码有关的实施例，

图19示出了与根据运行时间模型报告功能性而对文档资料和自动化模型进行运行时间产生和修改有关的实施例，以及

图20、21和22示出了根据实施例的方法步骤。

具体实施方式

定义：

“注释”意欲涵盖被添加到由业务过程直接或间接使用的任何软件实体的源内容的任何额外信息以便在业务过程的软件模型以及其关联的软件组件使用的概念集的方面描述该实体。注释可以被编译器或源内容的其他处理器用来修改根据源内容产生可执行逻辑的过程以便改变该可执行逻辑的行为从而允许提取包含在注释中的信息。

“非功能性要求”可以涵盖在诸如性能、安全性、成本、可用性及其他方面将功能性步骤实现得多好。其在非功能性要求的维基百科(http://en.wikipedia.org/wiki/Non-functional_requirements)中有所解释，如下-“在系统工程和要求工程中，非功能性要求是指定可以用来判断系统的操作、而不是特定行为的标准的要求。这应与指定特定行为或功能的功能性要求形成对比。典型的非功能性要求是可靠性、可伸缩性、和成本。非功能性要求通常称为系统的能力特性(ilities)。用于非功能性要求的其它术语是“约束”、“质量属性”和“服务质量要求”。”

功能性步骤可以涵盖用于任何目的的业务过程的任何类型的功能，诸如与接收输入的操作员交互、检索存储数据、处理数据、将数据或命令传递至其它实体等等，通常但不一定表示为人类可读形式...。

“已部署”意图涵盖对于其已分配并配置计算基础设施且软件应用组件已被安装并配置好准备开始运行的建模业务过程。根据该上下文，其还可以涵盖已开始运行的业务过程。

“适合于自动化部署”可以涵盖这样的模型，所述模型提供机器可读信息以使得能够部署基础设施设计，并使得能够由部署服务安装并配置软件应用组件(或自发地或利用由部署服务引导的某种人类输入)。

“业务过程”意图涵盖用于任何类型的业务目的的涉及计算机实现的步骤和可选地其它步骤(诸如人类输入或来自例如传感器或监视器的输入)的任何过程，所述业务目的诸如例如面向服务的应用，用于销售和分销、库存控制、制造过程的控制或调度。其还可以涵盖涉及用于非业务应用的计算机实现步骤的任何其它过程，所述非业务应用诸如教育工具、娱乐应用、科学应用、包括批处理、网格计算等的任何类型的信息处理。可以以序列、循环、递归、和分支方式组合一个或多个业务过程步骤以形成完整的业务过程。业务过程还可以涵盖业务管理过程，诸如CRM、销售支持、库存管理、预算、生产调度等，以及用于商业或科学目的(诸如对气候进行建模、对结构进行建模、或对核反应进行建模)的任何其它过程。

“应用组件”意图涵盖任何类型的软件元素，诸如可单独或以组合方式使用以实现业务过程的计算机实现步骤的模块、子例程、任何量的代码。其可以是可以被操纵以递送业务过程步骤(BPStep)(诸如事务或数据库表)的数据或代码。由SAP产生的销售和分销(SD)产品由若干事务组成，每个事务例如具有若干应用组件。

“未绑定模型”意图涵盖以任何方式(直接地或间接地)指定将用于业务过程的每个计算机实现步骤的至少应用组件的软件，而没有计算基础设施的完整设计，并且可以可选地用来计算业务过程的基础设施资源需求，并且可以可选地散布在两个或更多子模型上或由两个或更多子模型组成。未绑定模型还可以指定每个应用组件所需的诸如应用服务器和数据库服务器的对应执行组件的类型或版本，而不指定例如需要这些中的多少。

“植基模型”意图涵盖以任何方式(直接地或间接地)指定适合于业务过程的自动部署的计算基础设施的至少完整设计的软件。其可以是计算基础设施和将部署在基础设施上的应用组件的完整规范。

“绑定模型”涵盖具有植基模型到物理资源的绑定的任何模型。该绑定可以是在植基模型中的ComputerSystems(计算机系统)、Disks(盘)、StorageSystems(存储系统)、Networks(网络)、NICS与在实际计算基础设施中可用的真实物理部分之间的关联的形式。“基础设施设计模板”意图涵盖任何类型的软件，所述软件通过以任何方式指示计算基础设施的至少某些部分并指示该部分之间的预定关系来确定设计选择。这将留下有限数目的选项要完成，以创建植基模型。这些模板可以指示例如可容许选择范围或可容许改变范围。它们可以通过具有如何创建植基模型或如何改变现有植基模型的指令来确定设计选择。

“计算基础设施”意图涵盖任何类型的资源，诸如用于处理、用于存储(诸如盘或芯片存储器)、以及用于诸如联网的通信的硬件和软件，并且包括例如服务器、操作系统、虚拟实体、和诸如监视器的管理基础设施，其用于监视硬件、软件和应用。在例如配置和/或分配资源(诸如处理时间或处理器硬件配置或操作系统配置或盘空间)、以及对各种资源之间的链接或软件进行实例化的意义上，可以“设计”所有这些项目。可以或可以不在多个业务过程之间共享资源。资源的配置或分配还可以涵盖改变现有资源配置或分配。计算基础设施可以涵盖所有物理实体或所有虚拟化实体、或虚拟化实体、用于主控虚拟化实体的物理实体和用于运行软件应用组件而没有虚拟化层的物理实体的混合物。

“计算基础设施的部分”意图涵盖例如诸如服务器、盘、联网硬件和软件的部分。

“服务器”可以意指用于运行诸如可用于外部客户端的服务的应用软件的硬件处理器、或形成能够被诸如另一服务器的主控实体主控并最终被硬件处理器主控的虚拟服务器的软件元素。

“AIService”是用户消费的信息服务。其实现业务过程。

“应用约束模型”可以意指对定制过程、应用打包和组件性能模型中的组件的任意约束。在MIF从左到右前进时这些约束可以被工具用来生成附加模型。

“ApplicationExecutionComponent(应用执行组件)”是例如执行应用组件的(工人)进程、线程或servlet。示例将是由SAP提供的对话工作过程。

“ApplicationExecutionService(应用执行服务)”意指可以管理诸如工作过程、servlet或数据库过程的ApplicationExecutionComponents(应用执行组件)的执行的服务。示例将是由SAP提供的应用服务器。此类应用服务器包括对话工作过程及其它过程的集合，所述其他过程诸如如在主应用服务器(图8)的图中所示的更新和排队过程。

“应用打包模型”是描述软件的内部结构：需要什么产品和从该产品需要什么模块的任何模型，并且通常被未绑定模型包含。

“应用性能模型”意指具有为每个业务过程(BP)步骤定义直接和间接的资源需求的目的的任何模型。其可以被包含在未绑定模型中。

“组件性能模型”可以意指包含应用组件的一般性能特性的任何模型。这可以用来通过使用在定制模型中指定的特定业务过程步骤和数据特性连同在应用约束模型中指定的约束一起导出应用性能模型(其可以被包含在未绑定模型中)。

“定制模型”意指反映特定业务要求的业务过程的一般定制化模式。

“已部署模型”意指具有用于在系统中运行的管理服务的绑定信息的绑定模型。

“候选植基模型”可以是可以由工具在其将未绑定模型变换成植基模型时生成的中间模型。

“植基组件”可以包含用于植基执行组件和植基执行服务两者的安装和配置信息、以及关于策略和开始/停止依赖性的信息。

“植基执行组件”可以是执行应用组件的(工人)进程、线程或servlet的植基模型中的表示。

“植基执行服务”是管理诸如工作过程、servlet或数据库过程的执行组件的执行的实体的植基模型中的表示。

“基础设施能力模型”可以是可以由诸如不同计算机类型的公用设施以及诸如防火墙和负载平衡器的设备配置的资源的目录。

MIF(模型信息流)是用来在其整个生命周期中管理业务过程的模型的集合。

本发明可以应用于许多领域，详细描述的实施例只能覆盖这些领域中的某些。其可以涵盖建模动态或静态系统，诸如企业管理系统、联网信息技术系统、公用计算系统、用于管理诸如电信网络、蜂窝网络、电力网的复杂系统的系统、生物系统、医疗系统、天气预报系统、财务分析系统、搜索引擎等。建模的细节通常将取决于模型的用途或目的。因此，计算机系统的模型可以表示诸如服务器、处理器、存储器、网络链路、盘的组件，每个组件具有诸如处理器速度、存储容量、盘响应时间等相关属性。还可以表示组件之间的关系，诸如包含性、连接性等。

可以使用面向对象的范例，其中，使用对象对系统组件进行建模，并且将系统的组件之间的关系建模为对象的属性、或对象本身。可以使用其它范例，其中，模型集中于系统做什么而不是其如何操作，或者描述系统如何操作。数据库范例可以指定实体和关系。用于系统建模的形式语言包括基于文本的DMTF公共信息模型(CIM)、Varilog、NS、C++、C、SQL、或基于图形表示的方案。

图16和17，第一实施例

图16和17示出了第一实施例。图16示出了用于产生现有业务过程的模型的系统的概图。该业务过程在计算基础设施950上运行，并且具有源代码910，该源代码通常存储在别处。存在指定业务过程的功能性步骤的源代码和实施所述功能性步骤的软件实体的源代码。注释920被添加到源代码。收集器930从注释收集建模信息。建模器940被提供以根据收集的信息来产生模型960的部分。该模型可以具有建模的功能性步骤和建模的软件实体980。

图17示出了根据本发明实施例的图16的系统的步骤。在步骤900收集来自源内容中的注释的信息。在步骤903，该系统为该模型根据收集的信息来产生业务过程的功能性步骤的表示。这使得系统能够在步骤907根据收集的信息来为该模型产生用于实施功能性步骤的软件实体的表示。在步骤913这些被合并到模型中。步骤903和907可以以相反的次序实施。

附加特征

从属权利要求的附加特征的一些示例如下：

建模器可以被布置成为该模型产生软件实体对计算基础设施的需求的表示。这对实现更丰富的模型是有用的，该模型可以用于重新配置计算基础设施以更高效地满足这些需求，或者在例如重新配置业务过程或软件实体时预测这种需求的更改。

至少一些注释可以是描述性注释，该描述性注释具有识别功能性步骤和用于实施功能性步骤的软件实体的静态可确定的信息，并且收集器可以布置为读取源内容以收集该信息。这可以使得建模器能够建模软件实体的某种结构，而不是行为信息，诸如依赖于例如状态或使用模式的对计算基础设施的需求。

描述性注释可以使用实体类型和关系类型，其中所述类型对应于在模型中使用的类型。这意味着从模型的角度来对描述性注释的描述定向。这可以帮助使得建模器能够更高效地产生模型的各部分。该方法可以提供在源内容不止一种格式的情况下尤其有用的一致性。

至少一些注释可以是监视注释，其被布置为指定探测(instrumentation)点，所述探测点修改业务过程的运行时间行为以产生与运行时间行为有关的信息，并且收集器可以被布置为使得由收集器收集的至少一些信息是与运行时间行为有关的信息。这可以使得能够产生更丰富的模型。并不是业务过程和软件实体之间的所有关系都可以是静态已知的，并且因此一些可以在运行时间被发现。例如，业务过程中功能性步骤(业务过程步骤)的集合以及它们的次序或概率可以取决于用户行为或系统的状态。使用监视注释来发现行为可以使得能够更高效且灵活地实施更丰富的建模，因为注释不需要被限制为源内容的语言的代码或符号或结构。

建模器可以被布置为使用收集的运行时间行为信息来产生软件实体对计算基础设施的需求的表示。这对于实现更完整的模型来说是尤其有用的信息，所述模型可以帮助更高效地使用可用的计算基础设施。

建模器可以被布置为将关于运行时间行为所收集的信息与模型中软件实体和功能性步骤的对应表示相关。这可以使得模型在建模行为时更加完整，所述模型可以用于预测例如对计算基础设施的需求。由监视事件产生的信息可以被布置为包含在注释中包含的建模数据，以帮助使得该相关更容易。

监视运行时间行为的细节的等级可以是可配置的。这可以使得能够将监视聚焦于感兴趣的区域，这对于否则可能产生太多信息的较复杂系统而言尤其有用。

该系统可以具有文档资料生成器，其被布置为根据收集的信息来产生与功能性步骤和用于实施功能性步骤的软件实体有关的人类可读文档资料。这可以帮助使得能够更高效地实施该重要任务。这种文档资料可以是关于可以静态发现的信息，也可以是关于在运行时间发现的信息。例如，其可以包含关于实际执行了什么功能性步骤以及它们的需求的报告。

该模型可以包括未绑定模型和植基(grounded)模型，所述建模器布置为产生未绑定模型，并且该系统进一步具有设计服务以产生未绑定模型的逻辑组件到计算基础设施上的映射，从而提供适于在计算基础设施上自动化部署的业务过程的植基模型。通过提供找到软件或到计算基础设施的映射的更好或最好配置的方式，以导致更高效地使用可用资源来进行现场部署，这可以帮助利用建模的一些优势。所述映射可以具有例如用于主控软件组件的逻辑基础设施组件到特定类型的物理基础设施的映射。其可以是模板的形式，或者可选地所述注释可以包含这种信息。这可以被看作是对模板的改进，或看作附加的约束集合。可设想的是使完整的模板包括在注释中。未绑定模型或植基模型可以用于在对功能性步骤、软件或计算基础设施的改变的方面开发并且测试现有业务过程的可选方案，而不是冒着对现有业务过程的未经测试的改变的风险。

所述注释可以在指定业务过程的源内容中以及在实施该业务过程的软件实体的源内容中。如果这二者之间的关系是相关的，诸如在一些操作员仅感兴趣于业务过程步骤的序列而其他操作员感兴趣于底层的软件实体和较低层的情况下，则这二者可能都是重要的。

服务提供商可以提议在企业本地的专用硬件上进行部署，而由服务提供商提供日常管理。对于此示例的更多细节请参考上面提及的共同待决的申请号200702144。这可能增加服务提供商的复杂性，在这种情况下如所述的使用注释的优点可以变得更加有价值。

在与游戏服务器一起提供3-D视觉接口以使得多个开发者能够在相同的模型上工作并且看到彼此的改变的情况下，开发者可以更快地导航复杂模型。对于此示例的更多细节请参考上面提及的共同待决的申请号200702356。随着复杂性的增加，再次如所述的使用注释的优点可能变得更加有价值。

在企业接口被提供以使得企业能够彼此独立地定制非功能性要求的情况下，则服务提供商可能面临更复杂的开发努力来满足定制要求。对于此示例的更多细节请参考上面提及的共同待决的申请号200702363。将此与所述的使用注释相组合可以辅助开发者进行文档资料和模型生成并且帮助处理更复杂的开发努力。

在业务过程的操作可以被模拟的情况下或在可以并行进行多个测试部署的情况下，可以加速开发。对于此示例的更多细节请参考上面提及的共同待决的申请号200702377。将此与所述的使用注释相组合可以辅助开发者并且使得能够增强二者的优点。

设置开发环境可以通过提供哪些工具适合于给定开发目的以及给定模型部分的预定映射、或者通过包括与该模型一起部署的工具的模型来促进。对于此示例的更多细节请参考上面提及的共同待决的申请号200702145和200702601。将此与所述的使用注释相组合可以进一步辅助开发者并且使得能够增强二者的优点。

基于模型的方法

在描述的实施例中，在各种基于模型的方法中使用注释。这些基于模型的方法的一般目的是使得能够开发和管理业务过程以提供对三个主层的匹配改变：过程的功能性步骤、用来实现过程的功能性步骤的应用、以及所述应用所使用的计算基础设施的配置。通过使用与对上述部分进行建模的模型交互的适当软件工具来自动地实施此类改变。到目前为止，尚未有在整个系统生命周期中将集成业务过程、应用和基础设施管理的工具链接在一起的任何尝试。

将描述用于管理此类复杂的基于计算机的过程的基于模型的方法。此类模型可以具有CIM/UML的结构化数据模型以对以下三层进行建模：

·基础设施元素，诸如物理机、VM、网络链接。

·应用元素，诸如数据库、应用服务器。

·业务级元素，诸如在应用服务器中运行的业务过程的功能性步骤。

模型是例如以UML建模的元素的有组织集合。某些实施例的目的是将这些数据模型用于遵循软件即服务(SaaS)范例的企业应用的自动化按需供应。

问题陈述

用于诸如企业应用的大型业务过程的硬件基础设施和软件布局(landscape)的设计是极其复杂的任务，要求专业人员设计软件和硬件布局。一旦已经部署了企业应用，则存在响应于改变的工作负荷和要求来修改硬件和软件布局的日常(ongoing)要求。此手动设计任务昂贵、耗时、易于出错、并且对快速变化的工作负荷、功能性要求、和非功能性要求反应迟钝。实施例描述了自动地创建企业应用的最优化设计、监视运行的已部署系统、并动态地修改设计以最好地满足非功能性要求的机制。

存在到设计过程的两个基本输入：

·功能性要求的规范。通常，这采取应用要支持的业务步骤集合的形式。这些从最终用户的角度描述系统意图做什么。该规范将从标准目录中指定要求的标准业务步骤集合、以及这些步骤的任何系统特定的定制。此规范将确定必须被包括在用于企业应用的适当软件布局的设计中的产品和可选组件的集合。

·非功能性要求的规范。这定义设计必须满足的要求，诸如性能、安全性、可靠性、成本、和可维护性。性能的示例可以包括将支持的用户的总数和并发数目、事务吞吐量、或响应时间。

该设计过程包括创建将满足上述功能性要求和非功能性要求的企业应用的硬件和软件布局的规范。其可以由以下各项组成：

·选自可用池的物理硬件资源的集合。该基础设施将由计算机、存储器、盘、网络、存储装置、以及诸如防火墙的其他装置组成。

·要部署到物理资源上的虚拟基础设施、以及虚拟基础设施到物理基础设施的分配映射。必须以最好地利用物理基础设施并支持在其上运行的软件的要求的这样的方式来配置虚拟基础设施。例如，分配给虚拟机的虚拟存储器的量或优先级。

·在虚拟和物理基础设施上分布的经适当配置的软件组件和服务的选择。该软件必须被配置为满足系统特定的功能性要求，诸如标准业务过程的定制。此外，该软件必须配置为最好地利用它部署在其上的基础设施，同时满足功能和非功能性要求。配置参数可以包括数据库中线程的级别、在应用服务器中启动的内部过程的集合、或被保留供应用服务器的各种内部操作使用的存储器的量。

使用基于模型的技术来自动地设计和管理企业应用可以提供强大的预测能力，以及自动设计、部署、修改、监视和管理用以实施业务过程的运行系统同时最小化对人类干预的要求的能力。

可以在4个互连的层对企业应用建模：

·物理基础设施

·虚拟基础设施

·软件布局，对应于诸如上面提到的应用元素的软件实体

·业务过程

该模型称为企业应用模型。在每一层，其由两个模型集合组成-自动化模型和文档模型。

·自动化模型描述了系统的结构和行为，并且用于自动产生、评估、部署和修改企业应用的设计。在这四个层的每一层处的来自部署的物理系统的监视数据可以与建模的行为相关并用于基于实际测量做出运行时间管理决策。

自动化模型由在MI F中描述的那些模型组成(业务过程模型、定制模型、未绑定模型、植基模型、绑定模型和已部署模型)，所述模型实现了企业应用从设计到部署的整个生命周期中的自动化。

一般而言，自动化模型由两类子模型组成-静态模型和操作模型。静态模型描述系统的静态结构-企业应用的候选设计的选择和配置选项。操作模型描述基础设施和软件的内部结构、运行时间操作以及性能需求(诸如CPU、存储器、盘或网络I/O)。是这些操作模型允许模拟和评估候选设计将在多大程度上满足系统的非功能性要求。

文档模型包含可以被提取并变换成系统的文档资料的有价值源的信息。对文档模型有贡献的该信息可以与自动化模型中的实体密切相关联。该文档资料可以由人类用来针对功能正确性以及针对诸如性能的非功能性行为理解和检查系统的结构和操作行为。文档资料还可以用于训练和教育目的。文档资料的示例包括：

●业务过程步骤的UML图。

●业务对象的功能、它们的接口以及副作用的描述

●软件应用就组成软件组件而言的内部静态结构的UML图。

●软件组件之间的交互的活动图。

来自监视和报告服务的输出还可以被分类为文档模型的特殊情况，以人类可读形式描述系统的运行时间行为和性能。企业应用非常复杂，并且建模技术下面的模型对应地复杂并且难以创建。这些模型可以随着修改、修补和重新设计系统而随时间改变。此外，这些模型可以依赖于特定系统内包含的实际数据和配置以及观察的运行系统的行为。

一般而言，所需模型的详细结构和参数的大部分太复杂且是动态的而不能由人类及时地手动产生。本发明解决的问题是如何自动地产生自动化和文档模型的至少一些部分。模型中的信息必须是一致的且相关的-在系统的一个部分中的活动必须可跟踪并且与有关活动相关。例如，活动A可以导致一连串的其他活动B、C和D；希望这些关系可以在运行时间被表示并且被捕获在模型中。

自动设计和管理企业应用的基于模型的技术-参见Brand等人的“Adaptive Infrastructure meets Adaptive Applications”，其公布为外部HP实验室技术报告：http://www.hpl.hp.com/techreports/2007/HPL-2007-138.html并且在此引入以供参考-可以提供自动设计、部署、修改、监视和管理用以实施业务过程的运行系统同时最小化对人类干预的要求的能力。

这些实施例涉及提供自动产生企业应用的所需自动化模型的关键方面以及由人类用来理解和分析该系统的附加文档模型的机制。这些实施例描述了将一致且相关的注释(模型标记)添加到企业应用的软件的各种形式的源内容。所述注释可以从要产生的模型的角度来描述系统的结构。这些模型和注释可以共享相同的概念，诸如业务过程、业务过程步骤、业务对象以及软件组件。这些概念类型的实例以及它们之间的关系在注释中被描述。

使用静态分析和运行时间发现的组合，从注释中自动捕获用于创建或补充所需模型的信息。

源内容

企业应用的软件可以通过各种源内容来描述。通常，源内容由企业应用供应商拥有，其还负责添加模型标记注释。可以存在几种形式的源内容，诸如：

●以诸如Java或ABAP的语言写的程序代码。该代码可以由人类直接创建、或自动地根据其他程序模型或工具产生。

●程序模型描述系统的方面，诸如其静态结构或运行时间行为。程序模型它们本身以某种形式的标记语言(诸如XML)来表示。示例可能是：

●用于软件组件的行为的状态和动作图

●描述业务过程步骤集合的业务过程图。

●描述将软件静态打包成可部署单元、可执行文件和产品的结构图。

程序代码或程序模型可以经由诸如图形编辑器的工具产生或直接由人类产生。用于描述源内容的语法和语言可以广泛变化。然而，作为注释添加到源内容的模型标记应该具有一致的语义、概念和标识符，因此可以使得系统的各个部分相关并对其进行分析。尽管是单个概念模型，但是用于添加模型标记的语法机制将必要地变化，以与每种形式的源内容兼容。

图18，静态分析

图18示出了涉及静态分析的本发明的实施例。该图示出了用模型标记注释的企业应用的源内容，以及根据对注释的静态分析，使用模型变换工具集合来产生文档模型、自动化模型和可执行代码及数据的至少一些部分。

该图示出了源内容A、B和C以及形式为模型标记A、B和C的对应注释。在静态分析中，示出为模型变换工具的工具集合可以提取源内容中的模型标记并将其变换成自动化和文档模型的元素。例如，这可以捕获系统中业务过程和业务步骤的集合、以及它们之间的任何静态已知的调用关系。

在静态分析期间将使用注释来把信息添加到MIF中的模型的各个部分。特别地，注释描述了形成未绑定模型的各部分的信息。现在给出在静态分析期间使用注释的一些示例，但是这些示例不应认为是穷尽的而仅仅是说明原理。

业务过程的源内容中的注释将按照业务和定制模型使用的概念来描述业务过程和业务过程步骤-业务过程的集合、它们如何组成业务过程步骤、这些步骤之间的调用关系以及这些业务过程步骤如何被实施为应用软件组件。业务过程和业务过程步骤之间的关系可以被静态地描述，其中它们被业务过程或业务过程步骤的设计者已知。例如，业务过程将总是利用业务过程步骤、或者一个业务过程步骤的执行总是立即接着另一业务过程步骤的执行。可能存在其中这些关系不能由静态分析进行描述和发现并且必须在运行时间经由运行时间模型报告功能性来发现的情况。例如，业务过程步骤可以是通用的并且能够用在许多业务过程中，其中业务过程步骤的执行视系统的运行时间状态或人类动作而定。

类似地，程序代码或程序模型中的注释将按照应用打包模型理解的术语来描述软件结构-应用组件依赖的其他应用组件、应用组件作为其一部分的软件模块、应用组件依赖的软件模块、软件模块如何被打包成产品、以及执行应用组件的软件服务。

本发明的一些实施例的另外特征是使用相同的模型标记进行系统的运行时间发现和分析。这在图18中示出为可执行代码和数据中的运行时间模型报告。该标记定义了运行时间探测点、以及在这些点处要报告的模型信息。

图19

图19示意地示出了根据运行时间模型报告功能性在运行时间产生和修改文档资料和自动化模型。在静态变换阶段期间，模型变换工具使得模型标记的实例触发源内容的变换以补充企业应用的产生的可执行代码的行为，使得修改的代码报告模型信息给模型发现服务。修改的可执行代码用从注释导出的基于模型的结构信息来补充运行系统的执行上下文。该附加上下文按照所需模型中的概念捕获运行时间行为以及系统的各个部分之间的交互。从注释产生的运行时间监视(在一些情况下具有可控等级的细节)可以用于改进模型并且可以引起设计选择的运行时间重新评估并因此产生新的植基模型。

另一特征是使用注释来将建模的概念与软件组件施加于基础设施的所测量的性能需求相关，使得所得模型最终可以将业务过程与基础设施要求相关。

图19示出了在运行时间根据已部署系统的模型产生。模型标记的子集导致附加的功能性被添加到产生的可执行代码-运行时间模型报告-用于将关于系统在运行时间的结构和行为的信息馈送到模型发现服务。模型发现服务基于报告的信息创建、扩展或修改自动化模型和文档资料模型二者。自动化模型的任何修改又可以使基于模型的设计服务重新评估为该系统产生的植基模型，并且新的植基模型被提交以由基于模型的自动化服务部署在可用的基础设施上。如何可以实施基于模型的设计服务和基于模型的自动化服务的示例将在下面参考图1-图15来更详细描述。模型发现服务还可以用于为操作员产生报告。

若干互补实施机制可能用于运行时间模型报告功能性，包括：

●源内容的修改-变换工具分析模型标记并且添加或修改源内容到中间形式，之后其被变换成最后的可执行代码。这些工具将附加方法调用插入在程序代码中以利用软件库来向模型发现服务进行报告。这些方法调用将被插在从模型标记导出的点处并且与从模型标记导出的参数一起插入。

●字节代码的修改产生。代替例如通过添加附加的功能调用来直接修改源内容，可以由产生目标代码或字节代码(诸如Java字节代码)的编译工具直接解释模型标记；产生的代码将被修改以向模型发现服务报告信息。这种技术的优点是其可能更好地提供(instrument)运行代码的执行细节。例如为了分析CPU利用率，存储器消耗(堆和栈大小)或Java虚拟机中的现场对象引用，将这些性能需求包括在报告的信息中。

对于上面针对运行时间模型报告功能性描述的两种机制，模型标记明确地在源代码的特定点处触发对源内容或字节代码的修改。此外，变换工具可以直接分析源内容，例如以在方法调用的明显集合周围放置包装器(wrapper)或陷阱，诸如特定的源文件；在这种情况下，模型标记可以例如通过指定细节等级或为特殊的报告处理命名特定参数来简单地修改该过程。

本发明的一些实施例的特征是从产生的运行时间模型报告收集和报告的信息的子集或细节等级是在产生时静态可配置的或在运行时间动态可配置的。例如报告的细节等级可以是针对：

●在应用服务器内执行的线程

●业务对象的特定方法

●业务对象的所有使用

●功能单元(有关业务对象和业务过程的集合)

●特定企业应用，诸如数据库或应用服务器

收集的信息可以根据对该信息感兴趣的人或体系架构的观点/性质来定目标或呈现。例如：

●仅针对诸如销售和分销的特定模块来开启模块监视。

●对于业务对象、软件组件和虚拟机的指定集合产生相关的运行时间性能需求。

本发明的一些实施例的另一特征是还使用注释来将建模的概念与软件组件施加于基础设施的所测量的性能需求相关，使得所得模型最终可以将业务过程与基础设施要求相关。这通过用从系统的运行时间监视导出的信息来补充从标记中的信息捕获的执行上下文来实现。例如，模型标记将指示业务过程步骤的开始和结束。可能的是将对正执行该步骤的系统部分的测量需求与步骤本身相关联(例如CPU、存储器、网络I/O)并且与虚拟/物理基础设施的细节相关联，并且将此合并到产生的模型中以做出未来性能预测。

在运行时间发现分析期间将使用注释来将输入提供给MIF中模型的各个部分。特别地，该注释描述将形成未绑定模型的各部分的信息。

业务过程的源内容中的用于运行时间模型报告的注释允许在运行时间发现业务过程和业务过程步骤之间的关系，其中这些关系不为业务过程的设计者所知。例如，业务过程步骤可能是通用的并且能够在许多业务过程中使用或者业务过程步骤的执行视系统的运行时间状态或人类动作而定，并且因此可以用在业务过程步骤的设计者曾经未预测到的业务过程中。关于这些发现的关系的信息扩展并且补充了业务和定制模型。现在给出如何可以扩展和补充业务和定制模型的示例。这些示例不应认为是穷尽的，而仅仅是说明原理。组织实际使用的业务过程集合、在该业务过程内使用的业务过程步骤的实际集合以及这些步骤之间的调用顺序可以在运行时间根据组织内的实际使用而被发现。形成定制模型的一部分的业务过程之间的详细调用关系可以被测量，导致基于真实用户行为更准确地预测系统上的未来负载。例如，在用户随着他们前进通过业务过程而做出决策的时候，业务过程步骤之间的实际分支概率可以被代入定制模型。

类似地，程序代码或程序模型中用于运行时间模型报告的注释将允许发现用于按照定制模型、应用打包模型和应用性能模型理解的术语扩展和补充软件结构和性能的表示的信息和关系，如图12所示并且下面更详细描述的。这是重要的，因为该信息依赖于系统在特定组织中的实际使用并且难以在所有组织上一般化。现在将给出一些示例，但是这些示例不应被视为是穷尽的，而仅仅是说明原理。在定制模型中，运行时间模型报告将允许图11示出的BPStep和应用组件之间的AI_BPStepToApplicationComponentMapping映射关系被改进以反映应用组件的真实世界使用。在应用打包模型中，运行时间模型报告将允许根据发现的实际使用(诸如应用组件所依赖的其他应用组件集合)来改进应用组件之间的依赖性关系。在下面参考图12描述的应用性能模型中，运行时间模型报告将允许改进资源需求和应用组件之间的调用关系。例如，从监视基础设施测量的诸如CPU、存储器、网络I/O、或盘I/O之类的资源需求将与从运行时间模型报告发现的应用组件和业务过程步骤之间的调用关系的调用链相关以改进应用性能模型中的AI_IndirectComponentResourceDemands(AI_间接组件资源需求)和AI_DirectComponentResourceDemands(AI_直接组件资源需求)。此外，应用性能模型中的应用组件之间的调用图的表示可以根据发现的信息来更新。

图20

这示出了由根据实施例的系统实施的步骤。在步骤917，将注释添加到软件实体和业务过程功能性步骤的源内容以识别实体和关系的初步步骤被示出。这通常是手动完成的，不过可以设想让软件来引导操作员并且限制注释类型以确保它们是一致的并且匹配模型的分层结构。这同样应用于步骤923，即将监视注释添加到源内容以监视行为的初步步骤。这更改了运行时间行为以产生监视事件。这样的示例在上面进行了讨论。在步骤927该系统然后可以进行静态分析：通过分析源内容而根据描述性注释导出关系和实体的结构。这可以在运行时间分析之前或可能在其之后完成，如步骤930-941所示。在步骤930，实施业务过程或其相关部分。在步骤933收集关于行为的信息，并且在步骤937处理该信息以将行为与建模的实体相关。在步骤941实施进一步处理以推断调用关系和给定实体对计算基础设施的需求。步骤943示出了将发现的关系和需求合并到业务过程的未绑定模型中。

图21

该图示出了由根据实施例的系统实施的步骤，并且示出了运行时间分析的示例的更多细节。在步骤947具有注释的源内容被编译成可执行代码并且加载到目标机器中。在运行时间，在步骤951监视注释传递作为参数的对共享模型上下文的引用。模型上下文是共享仓库以存储和捕获由运行时间模型报告在建模实体之间的有关交互序列期间报告的信息，并且根据运行时间模型报告为软件组件的有关交互的调用链识别有关事件集合。模型上下文例如可以位于模型信息收集器内。模型上下文可以存储有关交互集合的所有报告的模型事件，诸如由执行业务过程中的业务过程步骤而产生的应用组件之间的调用图。对模型上下文的引用在应用组件之间传递以维护用于有关事件序列的标识符。该信息包括当前执行的业务过程的细节、业务过程步骤的调用链、以及实施它们的应用组件之间的调用关系。在执行从一个应用组件传到另一个应用组件时，关于该组件的执行环境的细节的信息可以被添加到发送到模型上下文的所产生的运行时间模型报告事件-例如，执行该组件的软件执行服务、主机操作系统和主机硬件的细节。模型上下文中的信息可以附加地用来自其他源的已经与根据运行时间模型报告发现的信息相关的信息来补充。例如，对于应用组件交互的相关集合，来自监视子系统的在诸如CPU、存储器或盘IO的计算基础设施上测量的资源利用率的信息可以被添加到模型上下文。在步骤953，根据指定的细节等级将事件报告给模型上下文，所述事件例如调用链中每个阶段消耗的cpu/存储器/带宽的量。在步骤957，将诸如事件和性能的行为与建模的实体相关。然后，模型发现服务可以分析模型上下文以按照报告的和相关的事件以及性能度量记录业务过程的执行，如步骤961所示。在步骤963，工具可以使用模型上下文来导出未绑定模型的各部分，诸如应用性能模型、组件性能模型和定制过程模型。未绑定模型的这些部分的示例将在下面参考图4和其他附图更详细地讨论。

图22

图22示出了由根据另一实施例的系统实施的步骤，并且示出了监视注释的更多细节。在这种情况下，监视注释被布置为更改运行时间行为以便报告事件时间，这可以帮助使得能够更准确地评估和建模性能。首先，在步骤971，监视注释将给定事件的时间戳与所涉及的实体的标识一起报告给模型发现服务。然后在步骤973，可以在给定的地方和时间测量计算基础设施上的通信量(traffic)负载。在步骤981，这些测量的表示或根据这些测量的性能导出的表示被添加到与给定实体相关联的模型上下文。

可能的实施技术的概述

现在将给出可以添加的注释种类的示例。这些示例不打算是完整的或者暗示仅存在实施该机制的一种方式-它们仅仅是说明原理。以伪XML格式示出注释。使用的实际语法可以不同，以更好地匹配特定源内容类型的细节。

所述原理是在源代码中识别将出现在源代码实施的系统的生成模型中的各个概念的实例。例如，业务过程、业务对象、方法调用等。对于每个注释实例，该概念实例的细节被给出为关键值对的集合。模型概念的一些示例被给出。

与业务过程相关联的元数据可以位于单独的模型标记文件中或嵌入在描述该过程的源内容文件中。对于每个业务过程，将仅存在一个实例。示例可以是：

<BusinessProcess>

      <name＝”Sales and Distribution”>

      <id＝fah9597wg86>//对业务过程唯一的ID

      <description＝”This is a description of my Business Process”>//它是

       做什么？

      <levelOfDetail＝high>//发现和报告的细节

</BusinessProcess>

示例1用于销售和分销的业务过程的注释

ID字段允许其他注释实例唯一地引用它。几种机制有可能将定义业务过程的源内容与业务过程注释相关联。典型的使用情况可能是描述该过程的完整源内容文件被用该过程的ID打上标签并且该过程的任何所得代码在其执行上下文中包含BusinessProcess(业务过程)。可选地，该标签与源内容文件的仅仅子部分相关联，并且仅仅从该部分内产生的功能性将Business Process(业务过程)添加到沿着调用链传递的上下文。

业务过程由一个或多个有关业务过程步骤的调用组成。这些业务过程步骤是可以在不止一个业务过程中再使用的在语义上有意义的功能性单元。步骤本身在BusinessProcessStep(业务过程步骤)结构中描述，BusinessProcessStep结构类似于BusinessProcess可以嵌入在该步骤的源内容文件中或者位于单独的标记文件中。业务过程步骤注释的每个实例本身将具有唯一的ID。

<BusinessProcesStep>

      <name＝”Create Sales Order”>

      <id＝3f87wwoqofo8f8>//BP步骤的ID

      <bpid＝fah9597wg86>//对特定业务过程1的引用

        (静态已知)

      <bpid＝d3i8ffisfug83>//对特定业务过程2的引用

        (静态已知)

      <description＝”Description of this step”

      <levelOfDetail＝high>//发现和报告的细节

</BusinessProcessStep>

示例2业务过程步骤的注释

当业务过程的设计者静态地知道业务过程和业务过程步骤之间的关系时，可以明确地在注释中捕获所述关系。存在两种可能的允许工具用简单的静态分析来容易地发现调用关系的互补机制：

●业务过程步骤注释可以明确地引用它作为其一部分的业务过程集合-这在示例2中的bpid属性集合中表示。当设计者对于至少由指定过程使用的步骤存在确定意图时这将被使用。

●明确的注释可以被添加到定义业务过程的源内容以标记业务过程步骤的调用点-BusinessProcessStepInvocation(业务过程步骤调用)注释将被用于此，仅仅指定业务过程步骤的ID。

这些静态注释不约束该Step(步骤)的使用-如果该Step(步骤)在许多业务过程中可再使用，则将在运行时间通过查看在上下文中从业务过程中的调用传递的业务过程标识符来发现这些附加使用。此外，在注释中静态指定的步骤的预期使用可以在运行时间被验证。

导致实施业务过程步骤的源内容将包含更详细描述步骤的行为的注释。源内容内的这些附加注释描述步骤内的有意义的操作或点，诸如开始、停止、或与第三方系统的外部交互。

<BusinessProcesStepOperation>

      <id＝3f87wwoqofo8f8>//BP步骤的ID

      <operation＝start>//业务过程步骤的开始

      <description＝”Description of this step operation”

      <levelOfDetail＝high>//发现和报告的细节

</BusinessProcessStepOperation>

示例3业务过程步骤内的业务过程步骤操作的注释

形式为业务对象(BO)的业务功能性的实施方式将以类似的方式进行描述。对于每种类型的BO将存在单个注释实例。

<BusinessObject>

      <name＝”Sales Order”>

      <id＝yfgf6i7if99hf4d＞//BO的类型的唯一ID

      <description＝”Description of this Business Object”

      <levelOfDetail＝high>//发现和报告的细节

</BusinessObject>

示例4业务对象的注释

在业务对象的实施方式内，每个外部可见的方法也将被注释。所述方法将引用业务对象的类型。

<BusinessObjectMethod>

      <name＝”Create Sales Order”>

      <id＝5y34lkudhl326236>//方法的唯一ID

      <id＝yfgf6i7if99hf4d>//对BO类型的ID的引用

      <description＝”Description of this Business Object Method”

      <levelOfDetail＝medium>//发现和报告的细节

</BusinessObjectMethod>

示例5业务对象的方法的注释

在运行时间，将维持上下文(模型上下文)以从各种注释收集数据来建立应用执行的情景(picture)。将使用在注释定义中定义的结构(结构化的关键值对的集合)来组织该上下文。对上下文的引用将作为参数沿着产生的代码的调用链传递，甚至越过机器边界。上下文本身可以位于中央仓库或服务(诸如模型发现服务)中。解释模型标记的工具将需要处理源内容以扩展所有生成代码的方法签名来引用该共享的上下文。修改的源内容将负责适当地在模型上下文中添加或移除数据。

method_foo(...)->method_foo(...，Model_Context contextReference)

示例6变换程序代码以传递对模型上下文的引用

模型上下文可以包含不仅关于软件的而且关于它在其上运行的基础设施的信息。基础设施有关数据将不仅包括当前调用上下文在其上运行的基础设施，而且包括在调用链中已经涉及的分布式基础设施的集合-例如代码在特定物理机上的Linux虚拟机上运行。此外，执行环境和监视基础设施可以用诸如由调用链中的每个步骤和机器消耗的CPU/存储器/带宽的量的信息来补充上下文。

对于来自运行时间模型报告功能性的每个报告的事件，工具可以检查模型上下文以从模型的角度发现结构和运行时间行为-例如涉及哪个应用模块、业务过程、业务过程步骤、业务对象、业务对象方法等。由执行环境生成的监视信息(诸如CPU或存储器使用)也与此相关联。

将标记添加到软件的源内容以引导生成代码或文档资料的变换的概念可以使用已知技术来实施。文档生成的示例是来自嵌入在Java源文件的注解中的Javadoc标记的HTML输出。影响代码产生的标记示例是嵌入在Eclipse建模框架(EMF)的Java类中的指示，其对于诸如实例创建和持续性之类的功能性影响模型类的自动生成代码的产生。

已知的基于模型的系统不尝试自动产生模型，或提供用于管理如在所述实施例中示出的关系的框架种类。

已知系统也没有示出：注释可以驱动现有企业业务过程的静态和运行时间发现和分析，以自动地且同时地创建系统的文档资料模型和计算模型。所得的计算模型可以用于使系统的模拟、评估和设计自动化。

现在将描述将一系列模型用于此类目的的示例的更多细节。如果从打草稿(scratch)开始，使用业务过程建模工具来设计业务过程。从可用业务过程的目录中选择业务过程并由业务过程建模工具对其进行定制。可用业务过程是可以被构建并运行的业务过程。如下所述，将存在用于这些的对应模板。然后，指定诸如可靠性和性能要求的非功能性特性。

接下来，选择实现业务过程所需的软件实体，诸如产品和组件。这通常通过在整个产品模型目录中搜索来完成，其中，用于每个产品的模型指定实现什么业务过程。此模型由应用专家或产品供应商提供。

接下来，设计计算基础设施，诸如虚拟机、操作系统、和底层硬件。这可以使用在下文和在通过引用结合到本文中的上文提及的先前提交的申请序列号11/741878“Using templates in automated model-based system design”中更详细地描述的模板。模板是具有参数和选项的模型，通过填入参数和选择选项，设计工具将模板变换成可部署系统的完整模型。该申请示出一种使用软件应用组件对具有许多计算机实现步骤的业务过程进行建模以使得能够在计算基础设施上自动部署的方法，该方法具有步骤：

从业务过程的未绑定模型自动地导出业务过程的植基模型，该未绑定模型指定将用于业务过程的每个计算机实现步骤的应用组件，而没有计算基础设施的完整设计，并且所述植基模型指定适合于业务过程的自动部署的计算基础设施的完整设计，

植基模型的导出具有步骤：提供具有计算基础设施的预定部分、该部分之间的预定关系、并具有要完成的有限数目的选项的基础设施设计模板、通过基于基础设施设计模板生成完整的候选基础设施设计以及生成未绑定模型所使用的软件应用组件的候选配置来生成候选植基模型、以及评估候选植基模型，以确定是否可以将其用作植基模型。

接下来，识别并分配来自数据中心中的共享资源池的物理资源。最后，配置并部署物理资源并且可以执行系统的日常管理。

所有这些可以使用SAP R/3作为示例，但是也可适用于其它SAP系统或非SAP系统。如下讨论的模板不仅可以包括实现业务过程所需的组件和管理该业务过程所需的管理组件，而且可以包括用于计算基础设施的设计。

可以以各种方式来实现模型生成部。一种方式是基于称为模型信息流(MIF)的六级模型流。这涉及在从业务要求一直到完整的运行系统的捕获过程的生命周期的各级或各阶段中开发模型。在下述图4中示出六个阶段，并且每个阶段具有可以如下概括的对应类型的模型：

·一般模型：起点，例如，基于用户可以从中进行选择的软件包的“开箱即用”功能的业务步骤的高级描述。

·定制过程模型：上文已定义，并且例如利用企业做出的选择对前一模型(一般模型)的特殊化。此模型捕获非功能性要求，诸如响应时间、吞吐量和安全性水平。另外，其可以指定对用于企业的一般业务过程的修改。

·未绑定模型：上文已定义，并且例如能够以企业所指定的要求运行业务过程的系统的结构和行为的抽象逻辑描述。

·植基模型：上文已定义，并且例如可以是对前一模型(未绑定模型)的变换以指定基础设施选择(诸如要使用的虚拟化技术以及硬件的数量和类型)以及还指定运行业务过程的软件的结构和配置。

·绑定模型：已为其保留数据中心中的资源的植基模型。

·已部署模型：已经部署并配置基础设施和软件组件的植基模型。此时，服务启动并运行。

该流程的每个阶段具有存储在模型仓库中的对应类型的模型。管理服务消费(consume)由模型仓库提供的模型并执行管理动作以实现阶段之间的过渡，以在MIF中生成下一个模型。那些服务可以是例如：

·基于模板的设计服务(TDS)(和基于模型的设计服务的示例)：基于模板将非功能性要求转换成用于植基模板的设计选择。

·资源获取服务(RAS)：其目的是在诸如vm的虚拟资源的部署之前分配物理资源。

·资源配置服务(RCS)：其作用是创建/更新虚拟和物理基础设施。

·软件部署服务(SDS)：安装并配置运行业务过程所需的应用和潜在的其它软件。

·监视服务(MS)部署探测器以监视已部署模型的行为。这可以包括在这三个层级中的任何一个或多个处进行监视：

○基础设施：例如监视CPU、RAM、网络1/O使用，与哪个应用或功能性步骤正在执行无关。

○应用：例如监视所花费的时间或操作系统上的诸如DB过程的给定应用的CPU消耗，与使用哪个特定的基础设施组件无关。

○业务过程：例如计算每小时销售订单的数目，与使用哪些基础设施组件或应用无关。

用于计算基础设施设计的模板

使用模板来捕获已知(使用上述管理服务)成功实例化的设计。示例性模板描述在具有一定量的存储器的Linux虚拟机(vm)上运行的SAP模块。模板还捕获已知可以执行的管理操作，例如特定种类的vm的迁移、增加vm的存储器、部署附加应用服务器以对高负荷进行响应等。如果变化管理服务参考模板，则可以使用模板来限制可以应用于模型的变化(改变(deltas))的类型。

模板有时已在特定工具中用来限制选择。另一种方法是使用为工具和用户提供更大自由的约束。在这种方法中，指定解决方案必须满足的约束或规则。一个示例可能是在应用配置中必须存在至少一个应用服务器和至少一个数据库。这些约束自己对于典型的业务过程而言并不充分地降低复杂性，因为如果存在很少的约束，则存在大量的可能设计(也称为大的解空间)。如果存在(表征解所需的)大量的约束，则搜索所有约束并对其求解是非常困难的-有巨大的解空间要探索。并且，从大的约束列表中找出哪个约束使给定的可能设计无效将花费很长的时间。

模板还可能包含用于管理变化的指令。例如，其可以包括需要发布给应用组件以添加具有新的从应用服务器的新虚拟机的重配置指令。

植基模型的导出可以涉及指定应用组件所需的所有服务器。这是自适应基础设施的设计的一部分以及已部署业务过程的性能的主要决定因素之一。模板可以限制服务器的数目或类型，以减少选项的数目，从而降低例如找出最优化解决方案的复杂性。

从未绑定模型导出植基模型可以涉及指定每个应用组件到服务器的映射。这是将应用组件配置为适合自适应基础设施的设计的一部分。模板可以限制可能的映射的范围，以减少选项的数目，从而降低例如复杂性。

植基模型的导出可以涉及指定用于监视在使用中的已部署业务过程的管理基础设施的配置。此监视可以是在一个或多个不同层级，诸如监视软件应用组件、或底层自适应基础设施，诸如软件操作系统，或处理硬件、存储或通信。

可以导出多于一个的植基模型，每个模型用于在不同的时间部署同一业务过程。例如，这可以使得能够更高效地将资源用于对那些资源具有随时间变化的需求的业务过程。可以以任何持续时间切换在给定时间部署哪个植基模型，诸如每小时、每天、每夜、每周、每月、每个季度等等。该切换可以是在预定时间，或者可以根据所监视的需求、诸如硬件故障的所检测的资源变化、或任何其它因素来布置切换。

在计算基础设施具有虚拟化实体的情况下，可以将植基模型的导出布置为指定一个或多个虚拟化实体，而不指示如何主控所述虚拟化实体。现在已经认识到可以通过隐藏此类主控来简化模型及其导出，因为在一虚拟实体由另一虚拟实体主控、所述另一虚拟实体本身由另一个虚拟实体主控等等的意义上，该主控可以涉及任意的递归。模板可以指定虚拟实体，并将应用组件映射到此类虚拟实体，以限制要选择的选项的数目，从而再次降低复杂性。如果此类模板不需要指定虚拟实体的主控，则其将是更简单的。可以例如通过单独的资源分配服务在部署之前的某一时间定义该主控。

可以通过在自适应基础设施中保留用于部署绑定模型的资源来将植基模型转换成绑定模型。此时，所需的资源的量是已知的，因此，这时保留资源可以比较早的保留更高效，不过可以设想其它可能性。如果植基模型是对于现有部署的变化，则该方法可以具有确定与现有已部署模型的差异并仅保留所需的附加资源的步骤。

可以通过安装并启动绑定模型的应用组件来部署绑定模型。这使得能够使用业务过程。如果植基模型是对于现有部署的变化，则可以确定与现有已部署模型的差异，并且只需要安装和启动附加应用组件。

建模基本原理中值得注意的两点是使用模板来呈现可以实例化的资源的有限目录，以及不暴露虚拟化资源的主控关系。任一者或两者可以帮助降低模型的复杂性并因此使得能够更高效地处理模型以进行部署或在部署之后进行改变。

某些实施例可以使用基础设施能力模型来呈现可以由计算架构提供的资源的可能类型。基础设施能力模型的实例包含可以由底层公用计算架构部署和配置的每种类型的计算机系统或设备的一个实例。每当公用设施部署并配置这些类型之一时，配置将始终是相同的。对于计算机系统而言，这可以例如意味着以下各项。

相同的存储器、CPU、操作系统

具有相同I/O容量的相同数目的NIC

具有相同特性的相同数目的盘

模板可以将应用组件映射到计算机，同时允许改变应用组件和计算机两者的范围。另外，该模板还可以包括某些或所有网络设计，包括例如防火墙和子网是否将解决方案中的计算机分离。在下文更详细地描述的实施例中，应用打包模型连同定制过程模型一起示出各种应用组件可以如何实现业务过程，并被打包在植基模型内。

还可以使用所选的模板来限制对系统的改变，诸如对业务过程的改变、对应用组件的改变、或对基础设施的改变，或由这些中的任何一个引起的作为结果的变化。这可能使自适应基础设施的日常管理成为更易处理的计算问题，并因此允许更多的自动化并因此降低成本。在某些示例性模板中，某些性质具有范围：例如0至n、或2至n。变化管理工具(或向导(wizard)，或工具或向导集合)仅允许对系统进行与模板一致的改变。该模板被此变化管理工具用来计算可容许变化集合；其仅仅允许可容许变化。如果不存在限制否则几乎数目无穷的可能配置的模板，这可以帮助避免在计算当前和下一个状态的模型之间的差异方面的上述困难。

这些特征的某些优点或后果如下：

1.简单性：通过使用模板，构建链接的工具集合以在设计、部署和改变的整个生命周期中集成业务过程、应用及基础设施设计和管理在计算上变得易处理。

2.通过限制自适应基础设施的可能配置的数目，减轻或避免了必须计算复杂模型的较早和稍后状态之间的差异的特定计算问题。这可以帮助实现用于自适应基础设施的管理系统，其可以自动地确定如何将系统从任意的现有状态发展到任意的期望变化状态。作为替代，模板固定可容许变化的集合且被用作变化管理工具的配置。

3.模板模型在形式上将业务过程、应用组件和基础设施设计相关。这意味着例如对这些中的任何一个的设计、或改变可以根据其它项进行，以便避免与其它不一致的设计或改变。

图1概观

图1示出根据实施例的基础设施、应用、以及管理工具和模型的概观。通常可选地经由业务过程BP调用中心300，通过互联网将自适应基础设施280耦合到客户290。管理系统210具有使用许多模型来管理设计和部署及对已部署业务过程的日常改变的工具和服务。例如，如所示，管理系统具有初始设计工具211、设计改变工具213、部署工具215、以及监视和管理工具217。这些可以采取在可以是分布式的常规处理硬件上运行的软件工具的形式。初始设计工具和设计改变工具的示例由下述图5所示的服务示出。

示出了用于两个业务过程的某些模型的高级示意图：可能存在更多业务过程。通常，管理系统属于服务提供商，该服务提供商受雇向企业提供IT服务，该企业控制其自己的用于其客户的业务过程。业务过程1的模型230用来开发软件应用组件的设计250。这被用来创建用于运行应用组件以实现业务过程的基础设施设计270。此设计然后可以被管理系统部署为在实际自适应基础设施上运行，在那里，其可以例如被客户、调用中心和供应商(为明了起见未示出)使用。类似地，项目220示出第二业务过程的模型，其用来开发软件应用组件的设计240。这被用来创建用于运行应用组件以实现第二业务过程的基础设施设计260。此设计然后也可以被管理系统部署为在实际自适应基础设施上运行。

该管理系统具有到基础设施管理操作员200的接口(可选为3D视觉接口)。该操作员可以是服务提供商人员，或在一些情况下可以是拥有该过程的企业的经过培训的人员。服务提供商人员可以能够查看和管理在共享基础设施上部署的不同业务的过程。给定企业的操作员将能够查看和管理仅仅他们自己的过程。如上所述，接口可以耦合到管理系统210以能够与各种类型的模型交互以及与基础设施设计模板交互。

自适应基础设施可以包括管理基础设施283，用于耦合到管理系统的监视和管理工具217。不需要将所有这些模型一起保持在单个仓库中：原则上，可以将其存储在任何地方。

图2操作

图2示出根据实施例的由操作员和管理系统进行的某些操作步骤的示意图。人类操作员动作在左侧列中示出，并且管理系统的动作在右侧列中示出。在步骤500处，人类操作员设计并输入业务过程(BP)。在步骤510处，管理系统创建BP的未绑定模型。在步骤520处，操作员选择用于设计计算基础设施的模板。在步骤530处，系统使用所选模板根据未绑定模型和所选模板来创建BP的植基模型。原则上，模板的选择可能是自动化的或由系统引导。服务提供商的人类操作员然后促使植基模型被部署，或者作为具有真实客户的现场业务过程或作为在受控或模拟条件下的测试部署。可以在将植基模型部署为现场业务过程之前对其适合性进行评估：下面参照图3来描述如何这样做的示例。

在步骤550处，系统在自适应基础设施中部署BP的植基模型。由任何类型的监视装置来监视已部署的BP，并将监视结果传递给人类操作员。在步骤570处审查监视结果之后，在步骤575处，企业的操作员可以设计对BP的改变，或者服务提供商的操作员可以设计对基础设施的改变。这些被输入到系统，并且在步骤580处，系统判定改变是否被同一模板允许。如果不是，则在步骤585处，操作员判定赞成新模板，这涉及返回到步骤520；或者判定在同一模板的限制内进行重新设计，这涉及在步骤587处，系统基于同一模板创建该改变的植基模型。

在步骤590处，服务提供商的操作员引起植基模型的部署以用于测试或现场部署。在步骤595处，系统部署所述改变的植基模型。原则上，稍后可以通过生成完整的植基模型并在稍后确定差异来导出该改变，但是这可能更加困难。

图3操作

图3示出实施例的概观，其示出在对业务过程进行自动化部署中涉及的某些步骤和模型。这些步骤可以由图1的管理系统来执行，或者可以在其它实施例中使用。

业务过程模型15具有步骤1-N的规范。例如，如众所周知的那样，可能存在许多循环和条件分支。其可以是人类和计算机实现步骤的混合，人类输入例如由客户或供应商或第三方执行。在步骤65处，针对业务过程的每个计算机实现步骤指定应用组件。在步骤75处，基于未绑定模型25，自动地指定计算基础设施的完整设计。这可以涉及在步骤85处获取基础设施设计模板35，并选择模板允许的选项来创建候选基础设施设计。这可以包括软件和硬件部分的设计。在步骤95处，创建模板允许的软件应用组件的候选配置，以适合候选基础设施设计。这些一起形成候选植基模型。

在步骤105处，评估候选植基模型。如果必要，创建并评估另外的候选植基模型。识别候选中的哪一个最佳地适合业务过程和可用资源的要求。存在许多可能的评估方式和许多可能的标准，其可以被布置为适应于业务过程的类型。例如，可以将该标准结合到未绑定模型中。

可以存在每个用于不同时间或不同条件的几个植基模型。例如，随时间变化的非功能性要求可以导致不同的物理资源、或乃至重配置：VM可能在不办公的时间移除存储器，因为较少人将在使用它。甚至可能关闭未充分利用的从应用服务器VM。不同的植基模型通常但不一定来自同一模板，其中不同参数被应用以生成不同的植基模型。

模板、植基模型和后续模型可以包含用于管理基础设施的配置信息和用于管理基础设施的指令，以便在部署时监视业务过程。示例是在每个新部署的虚拟机中设置监视器，其在CPU利用率上升至一定水平-例如60％-以上时发出警报。

图4MIF

图4示出在从定制模型到已部署实例的过渡中涉及的MIF的某些主要元素。为简单起见，其未示出在典型应用生命周期中将涉及的许多循环和迭代-这些可能被采用。业务过程的一般模型15是起点，并且假设客户或咨询者已经设计了定制业务过程。可以以各种方式来对其进行表示，因此许多实施例中的初步步骤是对其进行定制。定制模型18是一般模型的定制化。因此，很可能使用与针对建模定制模型说明的技术类似的技术来对一般模型进行建模：将存在不同的业务过程步骤。定制模型在以下方面不同于一般模型。其将包括非功能性要求，诸如用户数目、响应时间、安全性和可用性要求。另外，其可以可选地涉及重新布置业务过程步骤：新分支、新循环、新步骤、不同/替换步骤、涉及遗留或外部系统的步骤。

用诸如应用性能31、应用打包21、和应用约束27的输入将定制模型转换成未绑定模型25。未绑定模型可以至少指定将用于业务过程的每个计算机实现步骤的应用组件，而没有计算基础设施的完整设计。用来自基础设施能力33的模型的输入和基础设施设计模板35将未绑定模型转换成植基模型55。

植基模型的部署可以涉及转换到绑定模型57，然后将绑定模型转换到已部署模型63。绑定模型可以保留资源，并且已部署模型涉及安装并启动应用。

图5MIF

图5示出根据另一实施例的模型和步骤序列。其示出模型仓库310，该模型仓库310可以具有诸如模板(TMP)、未绑定模型(UM)、绑定模型(BM)、部分已部署模型(PDM)、完全已部署模型(FDM)的模型。该图还示出各种服务，诸如用于使用模板根据未绑定模型生成植基模型的服务320。另一服务是用于使用资源目录340保留资源以创建绑定模型的资源获取服务330。

自适应基础设施管理服务350可以根据绑定模型在自适应基础设施280中配置并激发(ignite)虚拟机，以创建部分已部署模型。最后，可以使用软件部署服务360来获取部分已部署模型并安装且启动应用组件以启动业务过程，并创建完全已部署模型。

图6导出植基模型

图6示出根据实施例的导出植基模型中的步骤。在步骤400处，从诸如集中式或分散式布置的示例中选择模板。集中式布置意味着在单个服务器或虚拟服务器上主控全部。其它模板选择可以是例如高或低安全性，取决于例如提供什么防火墙或其它安全性特征。其它模板选择可以是例如高或低可用性，其可以意味着为某些或所有部分提供冗余。

在步骤410处，填充所选模板中的其余选项。这可以涉及选择例如盘大小、对话过程的数目、服务器的数目、服务器存储器、网络带宽、服务器存储器、网络带宽、允许的数据库时间等。在步骤420处，通过所述选择来创建候选植基模型。步骤430涉及例如通过用所表示的资源并用表示处理延迟、db延迟等的同步点来构建排队网络而评估候选植基模型。可替换地，所述评估可以涉及将模型部署在具有模拟输入和条件的隔离网络中。

在步骤440处，将评估或模拟结果与用于未绑定模型的目标相比较。这些可以是性能目标，诸如在给定响应时间的情况下同时用户的最大数目，或对于给定数目的用户而言的最大响应时间。在步骤450处，可以用模板所允许的不同选项来创建并测试另一候选植基模型。在步骤460处，针对一个或多个不同模板重复该过程。在步骤470处，比较结果以识别哪个或哪些候选提供最佳的适合。如果例如目标或要求例如在不同的时间是不同的，则可以选择多于一个的植基模型。在这种情况下，可以以对第一植基模型的改变的形式来创建第二或后续植基模型。

图7主应用服务器和从应用服务器

图7示出根据实施例的用于计算基础设施的分散式或分布式设计的主应用服务器和从应用服务器的布置。主应用服务器50被提供为通过网络耦合到数据库60、并耦合到许多从应用服务器70。可以将某些从应用服务器实现为虚拟从应用服务器72。每个从应用服务器可以具有许多对话工人过程80。主应用服务器还使用客户端软件10耦合到远程用户。这些均可以具有在例如通过互联网耦合的台式PC 20上的图形用户界面GUI。一旦客户端已使用主应用服务器登陆，则客户端可以直接使用从应用服务器。

图8主应用服务器

图8示出用于图7的实施例的主应用服务器的各部分。提供排队过程100以管理数据库上的锁。提供消息服务器120以管理用户的登录和用户到例如从应用服务器的分配。提供更新服务器130以用于管理提交工作以在数据库中永久性存储。如果需要，可以提供打印服务器140。可以提供假脱机(spool)服务器150以运行诸如报告的批任务。在160处，示出了用于运行应用组件的实例的对话工人过程。

图9虚拟实体

图9示出供在实施例中使用的服务器上的虚拟实体的布置。示出了虚拟实体的分级结构。在操作系统层级，存在许多虚拟机VM。在其它VM上主控某些VM。例如通过时间共享或通过并行处理电路，在表示硬件处理实体的可重配置分区的虚拟分区VPAR 610上主控某些VM。这些中的若干可以由表示例如安装若干硬件处理实体的电路板的硬分区实体nPAR 620来主控。多个nPAR构成物理计算机630，物理计算机630通常通过网络接口650耦合到网络并诸如经由存储区域网络SAN接口640耦合到存储装置。

在市场上存在来自HP、IBM、EMC以及其他公司的许多商业存储装置虚拟化产品。这些产品集中于管理可用于物理机的存储装置和增加存储装置的利用率。虚拟机技术是独立于其它操作系统实例在一个物理机上运行操作系统实例的一种已知机制。已知的是在单个物理机内具有由此机器上的虚拟网络连接的两个虚拟机。VMware是虚拟机技术的已知示例，并可以提供用于在同一物理机上运行的不同操作系统实例的隔离环境。

还存在可以发生虚拟化的许多层级。例如，HP的蜂窝体系架构允许将单个物理计算机划分成许多硬分区或nPAR。每个nPAR对于操作系统和应用表现为单独的物理机。类似地，可以将每个nPAR划分成许多虚拟分区或vPAR，并且可以将每个vPAR划分成许多虚拟机(例如，HPVM、Xen、VMware)。

图10至15

本文接下来的部分参照图10至15来更详细地描述可以在图1至9、特别是图4所示的模型信息流(MIF)内使用的模型的示例。这些模型可以用来在公用基础设施内在其整个生命周期中管理SAP应用或其它业务过程。使用众所周知的使用CIM(公共信息模型)样式的UML(统一建模语言)示出了这些图示。该实现可以是以Java或其它软件语言。

定制模型可以具有BusinessProcess(业务过程)与AIService的实例之间的一一对应关系。AIService是实现业务过程的信息服务。

可以将业务过程分解成若干业务过程步骤(BPstep)，因此，BusinessProcess类的实例可以包含1个或多个BPStep。可以将BPStep的实例拆分成多个较小BPStep，涉及例如序列、分支、递归、和循环。一旦BusinessProcess步骤被分解成足够的细节，可以使每个最低水平的BPStep与ApplicationComponent(应用组件)匹配。ApplicationComponent(应用组件)是实现BPStep的程序或函数。对于SAP而言，示例将是SAP R/3 Enterprise的SD(销售和分销包)中的称为VA01的SAP事务。另一示例可以是特定的web服务(在应用服务器中运行)。

BPStep可以具有stepType(步骤类型)和stepParams(步骤参数)字段以不仅描述类似于步骤的较高级序列的执行和分支概念，而且描述步骤本身。stepType字段用来定义顺序或并行执行、循环、以及if-then-else(如果-则-否则)语句。stepParams字段用来定义关联数据。例如，在循环的情况下，stepParams字段可以是循环计数或终止标准。BPStep集合本质上描述具有诸如循环、if-then-else(如果-则-否则)语句、分支概率等各种控制的步骤的图。

关系BPStepsToApplicationComponentMapping(BPStep到应用组件映射)是详细描述BPStep被如何映射到Application Component(应用组件)的复杂映射。其以精简形式表示BPStep对Application Component(应用组件)的调用的潜在复杂混合物，诸如在ApplicationComponent(应用组件)内调用的特定对话步骤或函数或对web服务的方法调用的集合，以及提供的参数细节，诸如销售订单中的行式项目的平均数目。

BPStep可以具有与之相关的一组非功能性要求(NonFunctionalRequirements)：性能、可用性、安全性以及其他。可以由串：“高”、“中”、“低”来对可用性和安全性要求进行建模。在例如注册用户数目(NoUsersReq)、系统的并发用户数目、以秒为单位的响应时间和对于每秒事务数目的吞吐量要求方面指定性能要求。许多BPStep可以共享同一组非功能性要求。可以由串来表示时间函数。其指定何时应用非功能性要求，因此可以在办公时间到正常办公时间之外的时间期间应用不同的要求。更丰富的时变函数也是可能的以捕获月末峰值等。

图10、11定制模型

对于定制模型的示例而言，将讨论众所周知的销售和分销(SD)Benchmark(基准)。这是由众所周知的德国公司SAP生产的软件。其为SAP R/3系统的一部分，SAP R/3系统是执行诸如制造、会计、财务管理、和人力资源的用于公司的标准业务功能的软件的集合。SAP R/3系统是能够在几乎任何硬件/软件平台上运行且能够使用许多不同的数据库管理系统的客户端服务器系统。例如，其可以使用利用数据库系统DB2运行操作系统OS/400的IBM AS/400服务器；或使用Oracle数据库系统的Sun Solaris(Unix的衍生版本)；或使用SQL服务器运行Windows NT的IBM PC。

SAP R/3被设计为允许客户选择其自己的业务功能集合，并进行定制以添加新的数据库实体或新功能。SD Benchmark使用SD(销售和分销)应用模拟许多并发用户以评估硬件的性能能力。对于每个用户而言，交互由一遍又一遍地重复的16个单独步骤(对话步骤)组成。在图10中示出该步骤及其到SAP事务的映射。这里，事务是应用组件的示例。每个事务被示为行中的若干方框。每行中的第一个方框表示用户例如通过键入/nva01以开始事务VA01来调用事务。如图10所示，顶行中的事务VA01涉及调用创建销售订单事务、然后填充订单细节、然后保存售达方、以及以保存数据的“返回”功能F3结束的业务过程步骤。在第二行中示出下一个事务VL01N，并且其涉及如下步骤以创建外出递送。调用该事务，填充并保存装运信息。在第三行中示出下一个事务VA03，其用于显示客户销售订单。这涉及调用该事务，并填充随后的文档。在第四行中是第四事务VL02N，其用于改变外出递送。在调用此事务之后，下一个方框示出保存外出递送。第五行所示的下一个事务是VA05，其用于列出销售订单。在调用此事务之后，下一个方框示出提示用户填充日期，并且然后第三方框示出列出给定日期的销售订单。最后，在第六行中，事务VF01用于创建账单文档，并示出填充表格且保存已填充表格。

图11示出用于SD Benchmark的定制模型实例的示例。顶部的两个方框指示业务过程“BPModel”包含一个顶层级BPStep：“SD Benchmark”，其中stepType＝Sequence(序列)。示出了从此方框引出的两条线，一个线到与此顶层级BPStep相关的并由左侧的方框示出的非功能性要求。在这种特定情况下，仅仅指定性能要求-一个用于9am～5pm且另一个用于5pm～9am。未示出的其它类型的非功能性要求可以包括例如安全性或可用性要求。在每种情况下，可以如所示地指定性能要求，诸如用户的数目、并发用户的数目、所需的响应时间、以及所需的吞吐量。这些仅仅是示例，可以指定其它要求以适合业务过程的类型。如所示，表示相应时间函数的方框被耦合到每个性能要求方框。在本示例中，一个指示9am至5pm且另一指示5pm至9am。

在右侧，一条线从SD Benchmark BPStep引出到被示为六个BPStep的功能性要求，其中stepType＝Step(步骤)-一个用于图10所示的每个SAP事务(VA01、VL01N等)。为方便起见，将图10所示的每个事务的第一对话步骤的名称用作图11所示的对应BPStep的名称(“创建销售订单”、“创建外出递送”、“显示客户销售订单”、“改变外出递送”、“列出销售订单”、和“创建递送文档”)。对于这些步骤中的每一个而言，BPStepToApplicationComponentMapping关系指定所涉及的对话步骤的细节。例如，在CreateSalesOrder(创建销售订单)的情况下，图10示出BPStepToApplicationComponentMapping需要指定按顺序执行以下对话步骤：“创建销售订单”、“填充订单细节”、“售达方”和“返回”。另外，其可能指定“填充订单细节”所需的行式项目的数目。在图的右侧，每个BP步骤经由相应映射耦合到其对应的ApplicationComponent(应用组件)的实例。因此，BPstep“创建销售订单”经由具有ID：001的映射耦合到ApplicationComponent(应用组件)VA01。BPstep“创建外出递送”经由具有ID：002的映射耦合到ApplicationComponent(应用组件)VL01N。BPstep“显示客户销售订单”经由具有ID：003的映射耦合到ApplicationComponent(应用组件)VA03。BPstep“改变外出递送”经由具有ID：004的映射耦合到ApplicationComponent(应用组件)VL02N。BPstep“列出销售订单”经由具有ID：005的映射耦合到ApplicationComponent(应用组件)VA05。BPstep“创建递送文档”经由具有ID：006的映射耦合到ApplicationComponent(应用组件)VF01。

图12未绑定模型

未绑定模型用来计算资源需求。如图12所示，此模型可以由四个模型构成：定制模型(标记为CustomizedProcessingModel(定制处理模型))、应用打包、应用约束和应用性能模型，其中的每一个的示例将在下文描述(除定制模型之外，定制模型的示例已在上文关于图11进行了描述)。可以设想其它布置。未引入尚未包含在这四个模型中的新信息。

图12应用打包模型

应用打包模型描述软件的内部结构：需要什么产品和需要来自该产品的什么模块。可以在ApplicationModule(应用模块)中包含ApplicationComponent(应用组件)。ApplicationModule(应用模块)可以对应于用于应用服务器的JAR(Java存档)文件或数据库中的表格。在SAP的情况下，其可能是从特定产品加载到诸如SD或FI(财务)的应用服务器中的模块。应用打包模型可以具有DiskFootPrint(盘足迹)以指示ApplicationModule(应用模块)所需的盘存储量。在图10中的ApplicationComponent(应用组件)VA01的情况下，其来自例如具有2MB的DiskFootPrint的SD。

在产品内包含一个或多个ApplicationModule(应用模块)。因此，例如，SAP R/3ENTERPRISE包含SD。ApplicationModule(应用模块)可以依赖于其它ApplicationModule(应用模块)。例如，用于应用服务器的SD代码依赖于被加载到数据库中的SD数据和SD可执行代码两者。

定制模型可以具有执行ApplicationComponent(应用组件)的ApplicationExecutionComponent(应用执行组件)。这可以是在应用服务器或web服务器中运行的servlet。其还可以是特定组件的线程或过程。在SD的VA01事务的情况下，其为对话工作过程。当其执行时，ApplicationComponent(应用组件)可以间接地使用或调用其它应用组件来运行：servlet可能需要访问数据库过程；SD事务需要访问其它ApplicationComponent(应用组件)，诸如排队工作过程和更新工作过程，以及数据库ApplicationExecutionComponent(应用执行组件)。

可以由ApplicationExecutionService(应用执行服务)(SAP应用服务器)包含并在其上下文中执行ApplicationExecutionComponent(应用执行组件)，ApplicationExecutionService(应用执行服务)加载或包含ApplicationModule(应用模块)(SD)并管理ApplicationExecutionComponent(应用执行组件)(对话WP)的执行，ApplicationExecutionComponent(应用执行组件)又执行ApplicationComponent(应用组件)(VA01)以递送BPStep。

图12，应用约束模型

应用约束模型表示对定制过程、应用打包和组件性能模型中的组件的任意约束。在MIF从左到右前进时这些约束可以被工具用来生成附加模型。约束的示例包括：

·如何扩增应用服务器-什么ApplicationExecutionComponent(应用执行组件)被复制且什么不被复制。例如，为了扩增SAP应用服务器以处理更多的用户，不能仅仅复制第一实例-图7和8的主应用服务器50，一般称为中央实例。作为替代，需要中央实例内的组件的子集。这也是设计原则的示例：可能存在对最佳设计原则进行编码的其它约束。

·用于ApplicationComponent(应用组件)、ApplicationExecutionComponent(应用执行组件)和ApplicationExecutionService(应用执行服务)的安装和配置信息

·对ApplicationExecutionService(应用执行服务)的性能约束-例如不在具有大于60％的CPU利用率的机器上运行应用服务器

约束的其它示例包括命令：需要在应用服务器之前启动数据库。可以使用其它约束来对部署和配置信息进行编码。该约束可以全部被包含在模板中，或除模板之外另外提供，以进一步限制用于植基模型的选项的数目。

图12.应用性能模型

应用性能模型的目的是定义用于每个BPStep的资源需求。存在要考虑的两种类型的资源需求。

1.由使用CPU、存储器I/O、网络I/O和存储器的ApplicationExecutionComponent(应用执行组件)(例如，对话WP)在其执行BPStep时直接生成的资源需求-ComponentResourceDemand(组件资源需求)

2.在上述ApplicationExecutionComponent(应用执行组件)使用、调用或援引其它组件(例如，使用更新WP的对话WP)时由其引起的组件所生成的资源需求-IndirectComponentResourceDemand(间接组件资源需求)

IndirectComponentResourceDemand(间接组件资源需求)是递归的。因此，将存在类似于调用图或活动图的树。

完整的应用性能模型将包含用于图11所示的所有BPStep的类似信息。例如，BPStep“创建销售订单”中的对话步骤集合可消耗0.2SAPS。此外，其由四个单独的调用(或者，按SAP术语，为对话步骤)组成。该调用是同步的。

以下是可能出现在IndirectComponentResourceDemand(间接组件资源需求)和ComponentResourceDemand(组件资源需求)中的属性的某些示例。

·delayProperties(延迟性质)：与不消耗任何CPU、NetIOProperties(网络IO性质)和DiskIOProperties(盘IO性质)的组件活动相关的任何延迟(例如，等待或睡眠)。

·NumInvocation(调用数目)：在BPStep的执行期间调用组件的次数。

·InvocationType(调用类型)：如果调用程序被阻止，则同步；如果调用程序可以立即继续活动，则异步。

·BPStepToAppCompID：其为BPStepToApplicationComponentMapping的ID属性。其原因是在几个不同的BPStep中很可能涉及特定的ApplicationExecutionComponent(应用执行组件)。

·ApplicationEntryPoint(应用进入点)：其为正在执行的程序或函数。在“创建销售订单”的情况下，其为用于DialogWP的VA01。其还可以是web服务的方法。

可以以SAP为单位或用其它单位来表示CPUProperties(CPU性质)。存在各种表示MemProperties(存储器性质)、NetIOProperties和DiskIOProperties的方式。

图12，组件性能模型

对于定制模型的每个实例存在应用性能模型的一个实例。这是因为在一般情况下，每个业务过程将具有唯一的特性：唯一的BPStep排序和/或用于每个BPStep的唯一的数据特性集合。DirectComponentResourceDemands(直接组件资源需求)和IndirectComponentResourceDemand(间接组件资源需求)关联指定每个BPStep的唯一资源需求。需要根据从基准导出的每个ApplicationComponent(应用组件)的已知特性以及还有已安装系统的踪迹来计算这些需求。

组件性能模型包含每个ApplicationComponent(应用组件)的已知性能特性。通过将以下各项组合来计算特定的应用性能模型。

·包含在定制模型中的BPStepToApplicationComponentMapping(BPStep到应用组件映射)关联中的信息

·应用约束模型中的任何性能相关约束。

·组件性能模型

合起来，未绑定模型的这些模型不仅指定系统的非功能性要求，而且指定如何生成并评估满足那些要求的可能软件和硬件配置的方法。可能的硬件配置的生成受到使用基础设施能力模型中的信息进行的可从特定基础设施提供商处获得的基础设施的选择、以及所选模板的约束。

适用于诸如ApplicationExecutionComponent(应用执行组件)或ApplicationExecutionService(应用执行服务)的在未绑定模型中描述的可部署软件元素的一般原理是模型仅包含描述应用拓扑结构所需的每种类型的元素的最小数目的实例。例如，在SD的情况下，在未绑定模型中只需要与应用服务器的单个实例ApplicationExecutionService(应用执行服务)相关的对话工作过程的单个实例ApplicationExecutionComponent(应用执行组件)来描述实例化植基模型中的两个元素的植基等价物的无数种可能方式。准确地确定可以如何复制这些实体并使其共同定位的是模板和打包信息。

基础设施能力模型

如上文所讨论的，所述建模基本原理的两个值得注意的特征是：

1.呈现具有可以实例化的资源的有限目录的模板，以便存在固定且有限数目的选择。例如，小xen-vm 1-盘、中xen-vm 2-盘、大xen-vm3-盘、物理hpux机等。这使得由任何容量规划工具进行的资源类型的选择更简单。其还可以使得基础设施管理更容易，因为在资源配置中存在较低的复杂性-可以使用标准模板。

2.不暴露虚拟化资源的主控关系。DMTF虚拟化系统简档将主控关系建模为“HostedDependency(主控依赖性)”关联。如果只需要对有限数目的资源类型进行建模，则这看起来是不需要的，因此其未出现在这里所讨论的任何模型中。这使模型保持更简单，因为不需要处理任意的递归。这并不意味着如果方便的话处理这些模型的工具不能在内部使用DMTF方法。资源目录服务和资源分配服务在其内部模型中使用此关系可能是很方便的。

基础设施能力模型的实例包含用于可以由底层公用计算架构部署和配置的每种类型的计算机系统或设备的一个实例。每当公用设施部署并配置这些类型之一时，配置将始终是相同的。对于计算机系统而言，这意指以下各项。

·相同的存储器、CPU、操作系统

·具有相同I/O容量的相同数目的NIC

·具有相同特性的相同数目的盘

图13模板示例

图13示出具有计算基础设施的预定部分、该部分之间的预定关系、以及具有有限数目的要完成的选项的基础设施设计模板的示例。在这种情况下，其适合于分散式SD业务过程，而没有安全性或可用性特征。该图示出通过标记为“AI_network”的网络耦合的三个计算机系统，三个系统中的右侧的一个对应于主应用服务器，并且中央的一个对应于从应用服务器，如图7所示。因此，其是分散式的。AI是自适应基础设施的缩写。这些计算机系统的左侧的一个用于数据库。指定每个计算机系统的类型，在这种情况下指定为BL20/Xen。对应于从应用服务器的中央的一个具有属性“range＝0..n”。这意味着该模板允许任何数目的这些从应用服务器。

主应用服务器被耦合到标记为AI_GroundedExecutionService：AppServer(AI_植基执行服务：应用服务器)的方框，指示其可以用来运行此类软件元素。其具有包含足以允许自动地安装、部署和管理AI_GroundedExecutionService的配置信息和部署信息的相关AIDeploymentSetting(AI部署设置)方框。AI_GroundedExecutionService：AppServer被示为包括三个组件，标记为AI_GroundedExecutionComponent(AI_植基执行组件)，并且每个具有相关的AIDeploymentSetting方框。这些组件中的第一个是对话工作过程，用于指定业务过程的步骤的应用组件，另一个是更新过程，负责提交工作以进行永久性存储，并且另一个是排队过程，用于管理数据库上的锁。如所示，对于更新和对话工作过程而言，范围属性是2..n，意味着允许这些部分的多个实例。

从应用服务器具有GroundedExecutionService(植基执行服务)，其具有用于任何数目的对话工作过程的仅一种类型的AI_GroundedExecutionComponent。从应用服务器被示为具有rangePolicy(范围策略)＝Time function(时间函数)，意味着其被允许在给定时间是活动的。再次地，服务和执行组件每个具有相关的AIDeploymentSetting方框。

主和从应用服务器以及数据库计算机系统具有被示为AI_disk：OSDisk的操作系统。主应用服务器被示为具有AI_Disk：CIDisk作为供应用组件使用的存储装置。对于网络而言，每个计算机系统具有被示为AI_Nicl的网络接口，其耦合到由AI_Network：subnet1所示的网络。

数据库计算机系统耦合到标记为AI_GroundedExecutionService：Database(数据库)的方框，其具有用于该数据库的仅一种类型的AI_GroundedExecutionComponent，SD DB。再次地，服务和执行组件每个具有相关的AIDeploymentSetting方框。AIDeploymentSetting承载用来部署、配置、启动、管理和改变组件的配置和管理信息。下面参照图14来描述其示例的更多细节。此计算机系统被耦合到标记为AI_Disk：DBDisk的用于数据库的存储装置。

可选地，模板可以具有在生成植基模型时或生成变化的植基模型以改变现有植基模型时被工具调用的命令。此类命令可以被布置为限制可用选项，并且可以使用指定某些基础设施设计的模板的各部分作为输入。其还可以使用未绑定模型的各部分作为输入。

图14植基模型

可以由设计工具在其将未绑定模型变换成植基模型时生成植基模型。可以将其视为候选植基模型，直至被评估和选作选定植基模型为止。以下是与图13所示的模板相比较的图14的示例性植基模型的某些特性，图14的示例性植基模型是从图13所示的模板导出的。

·已经指定GroundedExecutionComponent(植基执行组件)的实例的数目。

·由GroundedExecution-Service(植基执行服务)来执行GroundedExecutionComponent(植基执行组件)。执行关系与在应用打包模型中所表示的关系一致。

·GroundedExecutionService(植基执行服务)在其类型已从基础设施能力模型中选出的ComputerSystem(计算机系统)上运行。

·存在两个更新组件，Update1和Update2。存在两个DialogWorkProcess(对话工作过程)，DialogWorkProcess1和DialogWorkProcess2。

·从应用服务器的数目已被设置为零。

管理系统被布置为进行这些选择以使用未绑定模型从模板导出植基模型。在所示的示例中，用于选择的标准包括系统的总容量，其必须满足定制模型中的随时间变化的性能要求。通过将这些性能要求与应用性能模型的聚合ResourceDemand(资源需求)[直接和间接]相组合来确定所需容量。如果第一选择证明提供了太少的容量或也许提供了太多的容量，则可以进行其它选择并进行评估。其它示例可以具有评估候选植基模型有多接近最佳适合的不同标准和不同方式。

在某些示例中，服务器可以仅附接有OS盘；这是因为此类装置(installation)中的惯例是NFS安装CI盘以获得其SAP可执行文件。其它示例性模板可以具有可选择细节或选项，诸如CIDisk和DBDisk是100GB、20MB/秒、非Raid等的细节。OS盘可以是EVA800型的。主和从应用服务器可以具有2至5个对话工作过程。计算机系统被指定为具有例如3GB存储装置、2.6GHz CPU和SLES 10-Xen操作系统。可以尝试不同的参数以形成候选植基模型，可以对该候选植基模型进行评估以针对期望性能或容量或其它标准找出最佳适合。

因此，植基模型指定所需的软件和硬件可部署实体的实例的精确数目和类型，所述实体诸如GroundedExecutionComponent(植基执行组件)、GroundedExecutionService(植基执行服务)、和AlComputerSystem(AI计算机系统)。AIDeploymentSetting(AI部署设置)可以包括例如：

·基础设施设置，诸如用于基础设施管理组件的阈值信息，例如MaxCPUUtilization(最大CPU利用率)-如果其上升至设定数字(例如60％)以上，则应触发警报。

·管理策略可以指定用于管理组件的其它策略信息-例如，如果利用率上升至60％以上，则向上伸展(flex up)。

·GroundedDeploymentSetting(植基部署设置)，其可以包括所有命令行和配置信息，以便可以在全功能状态下安装、配置并启动系统。

·SettingData(设置数据)，其可以提供可以覆盖在GroundedDeploymentSetting(植基部署设置)中提供的信息的附加配置信息。这允许许多GroundedComponent(植基组件)共享相同的GroundedDeploymentSetting(植基部署设置)(比较(c.f.)，类别(typing)的概念)，其中特定参数或覆盖参数由SettingData(设置数据)提供。由部署服务在部署期间解释GroundedDeploymentSetting(植基部署设置)和SettingData(设置数据)两者。

·与对组件的可能改变有关的数据，诸如在管理对组件的改变时执行的指令，以实现改变的更多自动化。

在植基模型中并未设置所有属性。例如，在植基模型中设置MAC地址没有意义，因为尚不存在任何分配的物理资源。

图15，可替换自适应基础设施设计模板

图15以适合于集中式安全SD业务过程的形式示出可替换自适应基础设施设计模板。与图13相比，其仅具有一个计算机系统，因此，其是集中式的。其示出形式为网络经由防火墙到外部子网的连接的安全特征。这由接口AI_Nic：nicFW示出，并且防火墙由AI_Appliance：FireWall示出。可以设想具有任何配置的其它模板。其它示例可以包括分散式安全SD模板、分散式高度可用SD模板、和分散式安全且高度可用的SD模板。

绑定模型

除物理资源分配之外，SD系统示例的绑定模型实例可以具有诸如子网掩码和MAC地址的其它参数集。已部署模型可以仅在一方面不同于绑定模型。其示出在系统中运行的管理服务的绑定信息。所有实体将具有例如管理服务的形式的管理基础设施。在这里未定义用于到管理服务的接口的实现机制，但是其可以是对例如web服务或SmartFrog组件的引用。管理服务可以用来改变状态以及观察当前状态。在模型的核心中没必要定义由管理服务使得可获得的状态信息、或由其执行的操作，而是可以在相关模型中进行定义。

这样的一个示例可以是管理虚拟机迁移。管理该迁移的应用将使用在PhysicalComputerSystem(物理计算机系统)上运行的管理服务来进行该迁移。一旦该迁移完成，管理应用将更新已部署模型和绑定模型以示出新的物理系统。需要注意保持模型的一致性。所有先前模型实例均被保持在模型仓库中，因此当迁移完成时，将存在绑定模型和已部署模型的新实例(版本)。

信息隐藏和模型信息流

对于MIF而言，情况并不总是所有工具和每个参与者都可以看见模型中的所有信息。特别地，对于具有要求参与者之间的强分离的安全性模型的部署服务而言情况不是这样。例如，在公用设施管理平面与虚拟机群之间可能存在非常强的分离。如果植基模型被馈送到企业的管理平面的部署服务，则其将不会返回示出虚拟机到物理机的绑定的任何绑定信息；该信息将被保持在管理平面内部。这意味着没有办法获知该群被绑定到什么硬件或两个群可能正在共享什么。从管理平面返回的内容可以包括群中的虚拟机的IP地址(其仅仅处理虚拟机)以及给定群中的那些机器的登录证书。信赖管理平面来管理群，使得其获得所请求的资源。一旦部署服务已完成工作，则可以使用应用安装和管理服务来安装、启动并管理应用。通常，不同的工具将看到MIF的投影。有可能从MIF模型提取这些工具要求的信息并用工具返回的结果填充该模型。将有可能在各种工具使用的数据格式与MIF模型之间变换。

实现方式：

可以使用任何常规的编程语言来实现诸如模型、模型仓库、和用于操纵模型的工具或服务的软件部分，所述语言包括遵循惯例编译的诸如Java、或C的语言。可以使用具有常规处理器的常规硬件来实现服务器和网络元件。处理元件不必是相同的，但应能够例如通过交换IP消息来相互通信。

已出于说明和描述的目的给出了本发明的实施例的前述说明。其并不意图是穷尽的或使本发明限于所公开的精确形式，并且按照以上教导修改和变化是可能的，或者可以从本发明的实践中获得该修改和变化。选择并描述了实施例以便解释本发明后面的原理及其实际应用以使得本领域的技术人员能够在各种实施例中并以适合于预期的特定用途的各种修改利用本发明。可以在权利要求的范围内设想其它变化。

Claims (21)

1.一种产生模型的方法，其中所述模型表示具有若干功能性步骤的基于计算机的业务过程的至少一部分，所述模型是根据指定所述功能性步骤的现有源内容以及根据实施所述功能性步骤的软件实体的源内容而产生的，所述源内容添加有注释，以提供用于建模的信息，该方法具有以下步骤：

收集由所述注释提供的信息，以及

使用由收集器收集的信息来产生所述功能性步骤和实施所述功能性步骤的软件实体的表示，并且被布置为将这些表示合并到所述模型中。

2.权利要求1的方法，具有为该模型产生软件实体对计算基础设施的需求的表示的步骤。

3.权利要求1的方法，至少一些注释是描述性注释，该描述性注释具有识别功能性步骤和用于实施功能性步骤的软件实体的静态可确定的信息，并且该方法具有读取源内容以收集该信息的步骤。

4.权利要求3的方法，描述性注释使用实体类型和关系类型，其中所述类型对应于在模型中使用的类型。

5.权利要求1的方法，至少一些注释是监视注释，所述监视注释被布置成修改业务过程的运行时间行为以产生与运行时间行为有关的信息，并且该方法具有收集与运行时间行为有关的信息的步骤。

6.权利要求5的方法，具有使用收集的运行时间行为信息来产生软件实体对计算基础设施的需求的表示的步骤。

7.权利要求6的方法，具有将关于运行时间行为所收集的信息与模型中软件实体和功能性步骤的对应表示相关的步骤。

8.权利要求5的方法，监视运行时间行为的细节的等级是能够配置的。

9.权利要求1的方法，具有文档资料生成器，其被布置为根据收集的信息来产生与功能性步骤和用于实施功能性步骤的软件实体有关的人类可读文档资料。

10.权利要求1的方法，该模型包括未绑定模型和植基模型，具有使用注释来产生未绑定模型、以及产生未绑定模型的逻辑组件到计算基础设施的映射以提供适于在计算基础设施上进行自动化部署的业务过程的植基模型的步骤。

11.机器可读介质上的软件，其在被执行时实施权利要求1的方法。

12.一种用于产生模型的系统，其中所述模型表示具有若干功能性步骤的基于计算机的业务过程的至少一部分，所述模型是根据指定所述功能性步骤的现有源内容以及根据实施所述功能性步骤的软件实体的源内容而产生的，所述源内容添加有注释以提供用于建模的信息，该系统具有：

收集器，其被布置为收集由所述注释提供的信息；以及建模器，其被布置为使用由收集器收集的信息来产生所述功能性步骤和实施所述功能性步骤的软件实体的表示，并且布置为将这些表示合并到所述模型中。

13.权利要求12的系统，建模器被布置成为该模型产生软件实体对计算基础设施的需求的表示。

14.权利要求12的系统，至少一些注释是描述性注释，该描述性注释具有识别功能性步骤和用于实施功能性步骤的软件实体的静态可确定的信息，并且该收集器被布置成读取源内容以收集该信息。

15.权利要求14的系统，描述性注释使用实体类型和关系类型，其中所述类型对应于在模型中使用的类型。

16.权利要求12的系统，至少一些注释是监视注释，所述监视注释被布置成修改业务过程的运行时间行为以产生与运行时间行为有关的信息，并且该收集器被布置成使得由收集器收集的至少一些信息是与运行时间行为有关的信息。

17.权利要求16的系统，建模器被布置成使用收集的运行时间行为信息来产生软件实体对计算基础设施的需求的表示。

18.权利要求17的系统，建模器被布置为将关于运行时间行为所收集的信息与模型中软件实体和功能性步骤的对应表示相关。

19.权利要求16的系统，监视运行时间行为的细节的等级是能够配置的。

20.权利要求12的系统，具有文档资料生成器，其被布置成根据收集的信息来产生与功能性步骤和用于实施功能性步骤的软件实体有关的人类可读文档资料。

21.权利要求12的系统，该模型包括未绑定模型和植基模型，所述建模器被布置为产生未绑定模型，并且该系统进一步具有设计服务以产生未绑定模型的逻辑组件到计算基础设施的映射从而提供适于在计算基础设施上进行自动化部署的业务过程的植基模型。

Images