CN102473097A

CN102473097A - 利用模型驱动技术开发可配置可扩展的业务应用产品线的高效计算系统

Info

Publication number: CN102473097A
Application number: CN2010800299282A
Authority: CN
Inventors: V·库尔卡尼; S·巴拉特
Original assignee: Tata Consultancy Services Ltd
Current assignee: Tata Consultancy Services Ltd
Priority date: 2010-01-13
Filing date: 2010-08-31
Publication date: 2012-05-23
Anticipated expiration: 2030-08-31
Also published as: US20120102451A1; EP2524304A1; US8990765B2; WO2011086571A1; CN102473097B

Abstract

本发明提供用于利用模型驱动技术来开发可配置可扩展的业务应用产品线的高效计算系统。本发明实现了创建具有一组预定变型的共用的业务应用、从该预定组选择合适的变型以及将所述共用应用与所选择的变型组合成专用的业务应用，本发明还提供了对共性和可变性建模且因此引起单一的规范。本发明提供了基于模型的解决方法，以实现在数据库集中式业务应用的功能性方面中的结构和行为方面的可扩展性和可配置性，本发明在数据库集中式业务应用个程序的应用开发的三个不同阶段(即，设计时、安装时以及运行时)支持配置过程。本发明降低了创建新的业务应用的成本以及计算时间，且引起有效维护以及平稳发展。

Description

利用模型驱动技术开发可配置可扩展的业务应用产品线的高效计算系统

技术领域

本发明涉及开发业务应用产品线，更具体地涉及用于利用模型驱动技术来开发可配置、可扩展的业务应用产品线的高效计算系统和方法。

现有技术参考

1)A Aho、R Sethi和J Ullman.Compilers：Principles，Techniques and Tools(编译原理).Addison Wesley Publishing Company(爱迪生-韦斯利出版公司)1986.

2)Alexander Nyβen、Shmuel Tyszberowicz、Thomas Weiler.Are Aspects useful forManaging Variability in Software Product Lines？A Case Study.Early aspectsworkshop at SPLC 2005.

3)Alexandre Bergel、St′ephane Ducasse和Oscar Nierstrasz.Classbox/J：Controllingthe scope of change in Java.In Proceedings of Object-Oriented Programming，Systems，Languages，and Applications(OOPSL A’05)，第177-189页，纽约，NY，美国，2005.ACM出版社.

4)A Goldberg、D Robson.Smalltalk-80：the language and its implementation.Addison-Wesley Longman Publishing Co.，Inc.波士顿，MA，1983.

5)Don Batory.Feature Models，Grammars，and Propositional Formulas.SoftwareProductlines，Volume 3714 of LNCS，第7-20页，Springer，2005.

6)Felix Bachmann、Michael Goedicke、Julio Leite、Robert Nord、Klaus Pohl，Balasubramaniam Ramesh and Alexander Vilbig.A Meta-model for RepresentingVariability in Product Family Development.Software Product Family Engineering，volume 3014 of LNCS，第66-80页，Springer，2004.

7)Gregor Kiczales、John Lamping、Anurag Mendhekar、Chris Maeda、CristinaVideira Lopes，、Jean-Marc Longtier和John Irwin.Aspect oriented programming.ECOOP’97LNCS 1241，第220-242页.Springer-Verlag.1997.6.

8)Hasan Gomaa、Diana L Webber.Modeling Adaptive and Evolvable SoftwareProduct Lines Using the Variation Point Model.Proceedings of the 37th AnnualHawaii International Conference on System Sciences(HICSS′04)-Track 9-Volume9.Page：90268.3

9)K.Czarnecki and M.Antkiewicz.Mapping features to models：A templateapproach based on superimposed variants.Generative Programming and ComponentEngineering，Volume 3676 of LNCS，第422-437页.Springer，2005.

10)M Clauβ、I Jena.Modeling variability with UML.GCSE 2001 Young ResearchersWorkshop，2001.

11)Nathaniel Nystrom、Xin Qi和Andrew C.Myers，J&：Software Composition withNested Intersection，OOPSLA 2006，第21-36页

12)Oscar Nierstrasz、Marcus Denker、Tudor

和Adrian Lienhard，“Analyzing，Capturing and Taming Software Change，”Proceedings of the Workshop on Revivalof Dynamic Languages(co-located with ECOOP′06)，2006年6月.

13)OSGi-The Dynamic Module System for Java，http://www.osgi.org/

14)Philip K.McKinley、Seyed Masoud Sadjadi、Eric P.Kasten、Betty H.C.Cheng，″Composing Adaptive Software，″Computer，vol.37，no.7，pp.56-64，2004年7月

15)Robert Bruce Findler、Matthew Flatt，Modular object-oriented programming withunits and mixins，Proceedings of the third ACM SIGPLAN international conferenceon Functional programming，第94-104页，1998年9月26-29，巴尔的摩，马里兰，美国

16)T.Coupaye、J.-B.Stefani.Fractal Component-Based Software Engineering-Report on the Fractal workshop at ECOOP′06，20th European Conference onObject-Oriented Programming(ECOOP 2006)Workshop Reader(面向对象的编程设计的第20届欧洲会议(ECOOP 2006)研讨会读物)，LNCS 4379，2007.

17)Vinay Kulkarni、R.Venkatesh和Sreedhar Reddy.Generating enterpriseapplications from models.OOIS’02，LNCS 2426，pp 270-279.2002.

18)Vinay Kulkarni、Sreedhar Reddy，An abstraction for reusable MDD components：model-based generation of model-based code generators.GPCE 2008：181-184

19)Vinay Kulkarni和Sreedhar Reddy，Separation of Concerns in Model-DrivenDevelopment.IEEE Software 20(5)：64-69(2003)

背景技术

通过先验的明确定义的重复操作任务的自动化，企业机构将IT系统用作机械效益。由于过去的业务动态较低，开发业务应用最初是为了提供固定操作环境中的确定性。近年来，导致企业内部和企业之间的连通性提高的互联网的问世以及技术平台的快速发展对业务动态的显著提高做出了贡献。提高的动态在开启了需要在越来越小的时间窗中处理的新机会的同时，对业务提出了新的要求。平稳性和鲁棒性好像让位于灵敏性和适应性。为了赋予这些重要的性质，这要求以全新的观点来设计(并实现)IT系统。

传统的业务应用在其实现中通常以对操作环境硬编码结束。因此，适应其操作环境中的变化导致扩展应用实现。该适应过程导致不可接受的反应。应该能够针对所需的操作环境来配置业务应用。新机遇可能对业务应用提出了不可构想的要求。应当能够快速扩展现有的实现，而不破坏与所需的扩展无关的部分。应当能够在不同程度的延时来支持这样的适应，所述不同程度的延时即应用设计时间、应用安装时间以及应用运行时间。而且，大型企业在引入这些适应的同时可能想要通过角色和责任结构推行一些纪律。

实现了符合分布式架构模式的数据库集中式企业应用，分布式架构模式需要大量不同的技术平台来实现。这样的应用可以随着以下5个方面变化，即功能性(F)、业务流程(P)、设计决策(D)、架构(A)以及技术平台(T)。

专用实现按以上提到的方面设置一组选择并通常以分散并混乱的方式对这些选择进行编码，如第7号现有技术参考中所提到的。该分散和混乱是现有的实现方式灵活地适应所需变化的主要障碍。大型企业应用进一步地加剧该问题。这是昂贵且容易产生误差的方法，需要有广泛精通业务领域、架构和技术平台的大型团队。模型驱动开发通过从它的高级规范自动获得实现来稍微减轻该问题，如第17号现有技术参考中所提到的。从其高级规范产生的基于模型的代码生成器进一步完善了该方法，如第18号现有技术参考中所提到的。

对于同样的商业目的，不同的企业、甚至来自同一商业领域的企业可能在上述的5个方面中具有不同的需求-可能期望他们的需求有大量重叠且因此规范有大量重叠。无视这些规范的相同地方则意味着重复工作且导致规范冗余，这以后会产生维护和演变问题。因此，捕捉共性同时突出变化(即产品线体系架构)是重要的，如第9号现有技术参考中所提到的。

基于规范的开发在一定程度上赋予了适应性，尤其是对于技术平台而言。通过代码生成，同一业务功能性可以传递至一组不同的设计决策选择、架构和技术平台-这与编译器中的可重定向代码生成相似，如第1号现有技术参考中所提到的。

然而，通过代码生成赋予适应性仅部分地解决了该问题，因为“适应系统”仍需要编译和部署以执行。因此，在基于规范开发的方法中，需要在各个不同的级别下支持适应性，所述级别即规范、代码生成、代码和部署。在代码生成器产品线的帮助下进行的模型驱动开发在D、A和T方面赋予了适应性和变化性，如第19号现有技术参考中所提到的。

然而，与F和P方面的变化需求相比，在D、A和T方面的变化需求相对不频繁。第13号和第14号现有技术参考中所提到的OSGi社区的不断发展的动态中间件相关制品的目的是解决部署级的适应性。

下列的目的是解决代码级的适应性：组合机制，如第7号现有技术参考中所提到的观点、如第15号现有技术参考中所提到的混合、如第16号现有技术参考中所提到的分形等；可变性管理机制，比如特征模型；以及变化规范语言，比如第12号现有技术参考中所提到的变化框(ChangeBox)、第3号现有技术参考中所提到的类框(ClassBox)以及第11号现有技术参考中所提到的Jx/J&。

处理开发业务应用产品线的一些发明是：

Goodwin等提交的US7152228教导了一种用于产生源代码对象的方法，该方法具有以下步骤：产生包括翻译逻辑的翻译文档；将该翻译文档输入至代码生成器；以及根据该翻译文档产生翻译源代码。用于通过翻译层访问数据库的系统包括：第一数据库；由翻译源代码定义的翻译层；以及用于通过该翻译层访问该数据库的应用。但是，其未能公开根据同一业务应用来为同一商业领域的两个或更多不同企业开发业务应用。

由Singh等提交的US20080133303教导了一种业务对象模型，该业务对象模型反映了指定的业务交易期间所使用的数据且用来产生接口。该业务对象模型通过提供这样的一致接口来有助于业务交易：在业务交易期间，该界面适于跨工厂、跨企业以及跨企业内的不同部门使用。但是，其未能公开根据同一业务应用来为同一商业领域的两个或更多不同企业开发业务应用。

更特定地，现有技术的缺点是：为不同的企业、甚至是来自同一业务领域的企业创建新的业务应用的计算成本以及计算时间是很高的。现有技术的另一缺点是：由于不同的企业甚至来自同一业务领域的企业的需求以及规范有大量重叠，则为他们创建新的业务应用时会导致维护和演变问题。无视该重叠将意味着重新工作且导致规范冗余。

因此，鉴于以上提出的现有技术，用于为来自同一业务领域的不同企业开发业务应用产品线的高效计算系统是显而易见的。

将参照附图在本发明的以下描述中说明本发明的其他特征和优势。

发明目的

本发明的主要目的是提供一种用于利用模型驱动技术来开发可配置、可扩展的业务应用产品线的高效计算系统。

本发明的另一重要目的是提供对共性和变化性建模，因此引起单一规范。

本发明的又一目的是创建具有一组预定变型的共用的业务应用、从该预定组选择合适的变型以及将所述共用应用与所选择的变型组合成专用的业务应用。

本发明的再一目的是提供一种基于模型的解决方法，以解决在数据库集中式业务应用的功能性方面中的结构和行为方面的可扩展性和可配置性。

本发明的另一目的是为创建新的业务应用降低成本以及计算时间，且引起有效维护以及平稳发展。

本发明的又一目的是提供组件抽象化和逻辑演算，逻辑演算有助于赋予数据库集中式业务应用的结构属性和行为属性，该组件抽象化和逻辑演算用来支持数据库集中式业务应用中的各种适应操作符。

本发明的再一目的是在数据库集中式业务应用个程序的应用开发的三个不同阶段(即，设计时、安装时以及运行时)支持配置过程。

本发明的另一目的是通过利用建模来检测数据库集中式业务应用的应用开发周期中的错误。

发明内容

在描述本发明的系统实现和方法实现之前，应当理解，本发明不局限于所描述的特定系统和方法，这些系统和方法是可以变化的。还应当理解，本说明书中所使用的术语仅是为了描述实施方式的特定形式且不意欲限制本发明的范围，本发明的范围将仅由所附的权利要求限制。

本发明提供了一种用于利用模型驱动技术来开发可扩展、可配置的业务应用产品线的高效计算系统。

一种用于利用模型驱动技术开发可配置、可扩展的业务应用产品线的高效计算系统，所述系统包括：

至少一个服务器；

网络；以及

主系统，所述主系统与所述网络和至少一个服务器通信，所述主系统具有处理器，所述处理器配置成执行用于以下的程序化指令：

(a)定义业务应用规范，所述业务应用规范要转化为应用架构上的具体实现方式，其中所述应用架构被分层，每一层表示所述系统的一个视图，所分成的层包括图形用户界面(图形用户界面)层、应用逻辑层以及数据库(Db)层；

(b)将业务应用规范分解为三个模型，所述三个模型包括图形用户界面层模型、应用层模型以及Db层模型；

(c)针对一个或多个抽象视图对业务应用的规范建模，其中每一独立的抽象视图定义与所述层及其相应的模型对应的一组属性；

(d)针对各独立的抽象视图创建三个元模型，其中所述元模型包括图形用户界面层元模型、应用层元模型以及Db层元模型；

(e)将各模型组合以形成单一的统一元模型，其中所述单一的统一元模型实现了规定要由不同层内和跨不同层的相关模型元素的实例满足的完整性约束，这实现了将图形用户界面层模型、应用层模型以及Db层模型独立地转化为它们相应的实现方式，即图形用户界面层代码、应用层代码以及Db层代码，并且转化为一致的整体；以及

(f)实现相应的规范以及其与其他规范之间的关系的每一单独转化，引起所述应用架构中的所述规范的一致实现。

本发明提供了对共性和变化性建模，因此引起单一的规范，且其能够创建具有预定义的一组变型的共用的业务应用、从所述预定义组选择合适的变型以及将所述共用应用与所选择的变型组合成专用的业务应用。本发明降低了创建新业务应用的成本以及计算时间且引起有效维护和平稳演变。

本发明实现一种基于模型的解决方法，以实现在数据库集中式业务应用的功能性方面中的结构和行为方面的可扩展性和可配置性。本发明还提供组件抽象化和逻辑演算，逻辑演算有助于赋予数据库集中式业务应用的结构性质和行为性质，该组件抽象化和逻辑演算用来支持数据库集中式业务应用中的各种适应操作符。本发明在数据库集中式业务应用个程序的应用开发的三个不同阶段(即，设计时、安装时以及运行时)支持配置过程。

附图说明

当结合附图阅读上述内容和下文中的优选实施方式的详细描述时，可以更好地理解所述内容和所述详细描述。出于说明本发明的目的，在附图中示出了本发明的示例结构。然而，本发明不局限于所公开的具体方法和系统。在附图中：

图1示出了根据本发明的各个实施方式的应用开发过程的流程图。

图2示出了根据本发明的各个实施方式的基于模型的开发方法。

图3示出了根据本发明的各个实施方式的作为统一的元模型的视图的、针对每一架构层的元模型以及横跨架构层模型的关联性。

图4示出了根据本发明的一个实施方式处理用户界面层的可配置性属性和可扩展性属性的元模型。

图5示出了根据本发明的一个实施方式用于处理类的结构和行为方面的可配置性和可扩展性的元模型。

图6示出了根据本发明的一个实施方式用于处理数据库层的可配置性和可扩展性的元模型。

图7示出了根据本发明的一个实施方式的将一特征的可追踪性捕捉至其实现产物的元模型的关联子集。

图8示出了根据本发明的一个实施方式用于组件抽象化的核心元模型。

具体实施方式

现在将详细讨论本发明的说明本发明的所有特征的一些实施方式。

词语“包含”、“具有”、“含有”和“包括”以及它们的其他形式在含义上是等同的并且是开放式的，因为跟在这些词语中的任一词语后的一项或多项并不意味着是这样的一项或多项的详尽列表，或者并不意味着仅局限于所列出的一项或多项。

还必须注意到，除非本文另外清楚指明，否则在这里和所附的权利要求书中使用的单数形式的“一”和“该”包括复数提及物。尽管与本文描述的方法和系统相似或等同的任何方法和系统可以在本发明的实践中或在测试本发明的实施方式中予以利用，但现在将描述优选的方法和系统。

所公开的实施方式仅是本发明的示例性实施方式，所述示例性实施方式可以以各种方式体现。

定义：

适应性：当业务应用适用于应用操作环境时，其中所述适应性将可配置性(即，选择很多可用变型中的一个变型)和可扩展性(即，添加新的变型)纳入。

变型：存在以满足可变点的不同可能性称为变型。

可变点：可变点描述最终系统中存在差异的地方。

可变性的相依性：这用作表示能够填充一可变点的不同选择的依据。相依性的规范包括基数选项(比如1/n，m/n等)以及比如强制性变型、互斥的变型等的限制。

可配置性和可扩展性：可配置性指的是从一个已知的情况快速切换到另一情况，可扩展性指的是轻松处理尚未见过的情况。

来自相同的业务领域比如银行业的不同企业想要为金融业务开户。在数据库集中式业务应用中，他们可能根据五个方面{功能(F)、业务流程(P)、设计决策(D)、架构(A)以及技术平台(T)}具有不同的需求，因此期望它们的需求且因此规范中有大量重叠。无视该重叠将意味着重新工作且导致规范冗余，这在以后会产生维护和演变问题。本发明提供了对共性和变化性建模，因此产生单一规范。

因此，本发明提供了：创建具有预定义的一组变型的共用的业务应用、从所述预定义的组中选择合适的变型以及将所述共用的应用与所选择的变型组合成专用的业务应用。

本发明提供了用于利用模型驱动技术来开发可配置、可扩展的业务应用产品线的高效计算系统。通过说明和举例，现在将利用以下系统来详细描述本发明。

高效计算系统包括：主系统，其具有用于实现用户互动和控制系统实体的图形用户界面；服务器，其通过通信网络连接到主系统并用于存储描述应用功能所需的文字性规范，其中所述通信网络可以是选自局域网(LAN)、广域网(WAN)、互联网、内联网、电信网中的至少一个网；以及至少一个其他服务器，其通过通信网络连接到主系统并且具有用于存储应用开发所需的数据资料的数据存储库，其中所述主系统具有配置成执行程序化指令的处理器，以利用模型驱动技术来开发可配置、可扩展的业务应用。

以上的所述高效计算系统还包括用于测试所开发的应用的至少一个部署框架，其中所述部署框架包括：至少一个主系统，其具有图形用户界面以实现用户与系统的互动；具有应用服务器的至少一个服务器，该应用服务器安装在该系统上并用于存储开发的应用和元数据；具有网络服务器的至少一个服务器，该网络服务器安装在该系统上并用于将用户请求发送至应用服务器；以及还具有用以存储应用数据的一个数据存储库。

图1示出了根据本发明的各个实施方式的应用开发过程(100)的流程图。首先，主系统从服务器捕捉客户需求并分析该客户的需求。基于分析，具有配置为执行程序化指令的处理器的该系统遵循以下提出的三种方式以开发新的业务应用，所述的三种方式包括新开发、扩展或配置。如果该系统选择新开发业务应用，则其进行功能设计，随后其定义可变点，接着其对该应用进行功能开发、测试且最后进行部署。如果系统选择扩展，则其接着查明是纯扩展还是用于变型的扩展。如果是纯扩展，则其接着引起功能设计，随后其定义可变点并接着对该应用进行功能开发、测试和最后部署。如果是用于变型的扩展，则该系统进行变型设计、变型开发以及测试和最后部署该应用。如果该系统选择配置，则其进行配置、测试和最后部署该应用。一旦该系统完成部署该应用，则其在终端用户/客户系统进行配置该应用的部署。最后，客户能够在它们的系统上利用开发出的应用。

图2示出了根据本发明的各个实施方式的基于模型的开发方法(200)。模型驱动开发方法以定义抽象规范开始，该抽象规范要在应用架构上转化为具体的实现，如第17号现有技术参考中所提到的。该应用架构通常被分层，每一层表示系统的一个视图，例如图形用户界面(GUI)层、应用逻辑层和数据库(Db)层。该建模方法利用一个或多个抽象视图构造该应用规范，其中每一不同的抽象视图定义与该抽象视图所模型化的层相对应的一组属性。具有配置成执行程序化指令的处理器的该系统将应用规范分解为三个这样的模型-GUI模型、应用层模型以及Db层模型，如图2中所示。具有配置成执行程序化指令的处理器的该系统产生三个元模型，即GUI层元模型、应用层元模型和Db层元模型，用于规范的每一独立的抽象视图。每一模型组合以形成单个统一的元模型，如图2中所示。具有单个元模型实现了完整性约束的规范，该完整性约束需要由不同层内的和跨不同层的相关模型元素的实例满足。这实现了将GUI层模型、应用层模型和DB层模型独立地转化成它们的相应的实现，即GUI层代码、应用层代码以及Db层代码，并确保这些代码片段组合成一致的整体。这些转化可以手动执行或利用代码生成器执行。所述转化是在元模型级规定的且因此适于所有的模型示例。如果每一单独转化正确地实现相应的规范以及其与其他规范的关系，则所产生的实现将联系在一起，给出规范的一致实现，如图2中所描绘。模型可以与实现技术无关，且通过代码生成，应用规范可以以多个技术平台为目标。根据独立的模型构造应用规范有助于分解和合成，其中所述分解和合成策略在图8中说明。建模有助于在应用开发周期中较早地检测出错误。每一模型与一组规则和约束有关联，该规则和约束限定该模型的实例的有效性。这些规则和约束能够包括用于类型检查的规则和用于不同层的规范之间的一致性的规则。自动代码生成引起较高的产率和均匀的高代码质量。

图3示出了根据本发明的各个实施方式的作为统一的元模型的视图的、针对每一架构层的元模型以及横跨架构层模型(300)的关联性。业务应用是跨三个架构层实施的-用户界面、应用功能以及数据库。用户通过其用户界面与应用进行互动。用户利用表格输入信息，利用查询和报告浏览可用信息。表格、查询和报告是利用标准图形用户界面基元在应用平台上实施的，所述标准图形界面元素比如为窗口、控件和按钮。窗口是用户和系统之间进行互动的单元且由控件和按钮组成。控件以特定格式接收或呈现数据。该用户可以通过点击按钮来执行特定任务。应用层根据业务逻辑、业务规则和业务流程来执行业务功能。该功能性是利用类、属性、方法以及类之间的关联性来建模的。业务逻辑根据方法来规定应用要执行的计算。用于规定业务逻辑的较高级语言可以使应用开发者免于关注低级实现，所述低级实现关注比如为存储器管理、指针、资源管理等，该较高级语言可以重定向至选择流行编程语言。数据库层利用以下来为应用对象提供持久性：RDBWS表、主键以及基于访问这些表格的查询以及访问应用层的面向对象视图。

根据本发明的各个实施方式，该系统解决了数据库集中式业务应用的结构和行为方面的可扩展性和可配置性。元模型捕捉GUI模型、应用模型以及数据库模型等允许的变化，适应技术将需要的变化以一致的方式实现应用实现。

图4示出了根据本发明的一个实施方式解决用户界面层的可配置性属性和可扩展性属性的元模型(400)。GUI屏幕是使用户与应用互动的一个通道。实质上，GUI屏幕能够使用户提供输入数据以执行工作逻辑单元。为了提供相同的商业目的，GUI屏幕可以根据引起多种情况的什么(例如，用户需要输入和/或可以查看的数据)以及如何(即，用于显示的布局信息和GUI控件)来变化。可配置性意味着从一种已知的情况快速切换到另一情况，可扩展性意味着轻松处理尚未见过的情况。该元模型是图3标注出的用户界面元模型的扩展，如下：

-将字段分为固定的和自由的。前者需要在所有情况下显示，而后者特定于某情况。

-将按钮分为固定的和自由的。前者需要在所有情况下显示，而后者特定于某情况。

-字段可以在不同的情况下利用不同的GUI控件来显示且可以符合不同的类型。

-事件可以在不同的情况下以不同的方式处理。

-屏幕以多个变型存在，每一变型内部由字段、按钮和事件处理器一致地组成。

-情况帮助从多个可选方案中选择所需的屏幕变型。

因此，上述元模型能够对一系列屏幕建模，其中每一成员(屏幕系列的每一成员)在特定情况下用于相同目的。通过使上述信息作为元数据在应用运行期间可利用，GUI实现方式可以在应用运行时间中从一个已知的情况切换到另一情况。在元数据表中添加新行对应于处理尚未知晓的情况的能力。但在应用运行时间并不是所有情况适应都能够被处理，例如，事件处理器代码的改变将需要再编译，之后部署。类似地，定义全新的屏幕作为对现有的功能的扩展是无法在应用运行时间下进行处理的。但是，该元模型能够处理这样的新情况：新情况添加至现有的配置可选方案组中。

图5示出了根据本发明的一个实施方式用于处理类的结构和行为方面的可配置性和可扩展性属性的元模型(500)。应用层根据类、属性和操作规定业务逻辑。作为结构方面和行为方面的封装，类是在最佳抽象级别赋予可配置性和可扩展性的自然选择。该元模型是图3中标示出的应用层元模型的扩展，如下：

-将属性分为固定的、自由的和删除/修改的(delmod)。类在所有情况下含有固定的属性，而自由的属性特定于某情况。标记为删除/修改的性质表示情况特定删除和/或修改。

-属性可以符合不同的类型。

-将操作分类为可配置的和特定的。前者具有特定情况的行为，而后者在所有情况下具有同样的行为。

-可配置操作的主体是具有明确定义的扩展点的模板(TxtnPoint)，在所述扩展点处，可以插入不同的行为。扩展点是以界面调用的形式规定的-工厂返回实现扩展的恰当对象(Txtn)。

-扩展现有的行为相当于为现有的扩展点提供新的扩展(Ov)或为正在被扩展的操作提供新的模板(Ox)或者两者。

-Cv描述情况特定的类定义。

-情况帮助从多个可选方案中选择类的所需变型。

因此，上述元模型能够对一系列类建模，其中每一成员(类系列的每一成员)在特定情况下用于相同目的。通过使上述信息作为元数据在应用运行期间可利用，应用实现可以在应用运行时间中从一个已知的情况切换到另一情况。在元数据表中添加新行对应于处理尚未知晓的情况的能力。但在应用运行时间并不是所有情况适应都能够被处理，例如，添加新的行为扩展将需要再编译，之后部署。类似地，定义全新的类作为对现有的功能的扩展是无法在应用运行时间下进行处理的。但是，该元模型能够处理这样的新情况：其添加至现有的配置可选方案组中。

图6示出了根据本发明的一个实施方式用于处理数据库层的可配置型和可扩展性属性的元模型(600)。该系统考虑了对象-关系型数据库层，该对象-关系型数据库层将对象外观提供至关系数据库表以实现持久性。由于应用对象可以根据情况而发生结构变化，其所映射到的数据库表也需要满足该变型。且结构扩展同样如此。该元模型是图3中标出的数据库层元模型的扩展，如下：

-将列分为固定的和自由的，前者在所有情况下与实体有关，而后者特定于某情况。

-列也可符合不同的类型。

-Tv示出的情况特定的实体定义。

-情况帮助从多个可选方案中选择实体的所需变型。

因此，上述元模型能够对一系列实体建模，其中每一成员(实体系列的每一成员)在特定情况下用于相同目的。实际上，上述信息使通用模式特定于指定情况。数据库访问方法(比如基于创建、更新、获取和删除的主键)以及复杂的数据访问(比如连接)可以在它们的实现中对该信息的解释进行编码。通过使上述信息作为元数据在应用运行期间可利用，应用实现方式可以在应用运行时间中从一个已知的情况切换到另一情况。在元数据表中添加新行对应于处理尚未知晓的情况的能力。但在应用运行时间并不是所有情况适应能够被处理，例如，删除一列将需要对该模式进行重定义，导致对该数据库访问层代码再编译，之后部署。但是，该元模型能够处理这样的新情况：其添加至现有的配置可选方案组中。

图7示出了根据本发明的一个实施方式的将一特征的可追踪性捕捉至其实现产物的元模型(700)的关联子集。实际上，到目前为止所描述的元模型有助于在每一架构层对系列建模，使得该系列的所有成员共享共同部分且在特定于成员的各部分上有区别。如图2中所示，统一的元模型实现了跨越所述架构层而合格的约束的规范。一旦确定了来自每一架构层的一组所需成员，可能使它们组成合格的规范，所述规范可以自动地转化为一致的且完整的解决方法。该系统利用特征模型化技术来实现选择属于所需类型的系列成员。

根据本发明的一个实施方式，本发明的系统利用一组预定义的变型来开发共用的业务应用、从预定义的组中选择合适的变型以及将所述共用的应用与所选择的变型组合成专用的业务应用。

图8示出了根据本发明的一个实施方式用于组件抽象化的核心元模型(800)。在分解和合成策略中，应用被模型化为一组模块化单元，所述模块化单元可以被并行地开发。该系统将这样的开发单元看作组件。组件共享它们之间的生产者-消费者关系。组件封装数据和计算并通过其界面显示一组服务。组件之间的相互关系是混乱规范的典型原因，混乱的规范限制了独立开发。该系统通过提供的和所需的界面的独立规范来处理混乱，所述界面作为组件和其环境之间的合约。只要环境满足该组件的所需界面，则该组件将传递所提供的界面。对于应用运行时，这是广为接收的概念，该组件抽象化的目的是在应用建立时支持所述概念。该系统利用组件抽象化来封装业务层和数据库层。组件规范包括界面规范以及其内部实现的规范。实际上，内部实现是根据类、类关联、实体和类的方法主体的规范而定义的。组件界面规范可以被看作其实现规范的投影。组件作为用于应用的组成单元，需要支持可配置性和可扩展性的概念。如图8中所示，该系统通过扩展点(xtnPoints)和可变点(varPoints)来扩展组件抽象化。扩展点具有以下两种类型：数据扩展点(DxtnPoint)和行为扩展点(PRxtnPoint)。可变点具有以下三种类型：与实体有关的变化(EvarPoint)、与操作有关的变化(OvarPoint)以及与类有关的变化(CvarPoint)。实体扩展和类扩展(分别为Ex和Cx)纳入DxtnPoint，以及可以在PRxtnPoint插入操作扩展和类扩展(分别为Ox和Cx)。类似地，实体变化和类变化(分别为Ev和Cv)以及操作变化(Ov)可以分别插在EvarPoint、CvarPoint和OvarPoint处。

该系统在形式上将组件(Cmop)定义为数组<Own，P，R，EO，ER，X，V>，其中：

-Own：组件实现规范，通常作为元模型的实例

-P：设定组件提供的操作

-R：设定组件所需的操作(以便承认P有效)

-EO：设定组件具有的实体

-ER：设定组件引用的实体，该实体为其他组件所有

-X：设定该组件的扩展

-V：设定该组件的变型。

操作还定义为数组<operName，In，Out>，其中：

-operName：操作的名称

-In和Out是一组类型化参数-类型由类定义。

扩展(X)在形式上定义为数组<Cx，Ex，Ox>，其中：

-Cx根据图5中提到的元模型样式Cxp确定一组扩展类

-Ex根据图6中提到的元模型样式Exp确定一组扩展实体

-Ox根据图5中提到的元模型样式Oxp确定一组扩展操作组件变型(V)定义为数组<Cv，Ev，Ov>，其中

-Cv根据图5中提到的元模型样式Cvp确定一组可配置类变型

-Ev根据图6中提到的元模型样式Evp确定一组可配置实体变型

-Ov根据图5中提到的元模型样式Ovp确定一组可配置操作主体变型如果有以下，则组件是合格的：

-P.Operation(P操作)被认为是Own中的Class.Operation(类操作)，即

&ForAll; o &Element; Comp . P

满足以下条件

c . operation = = o)

-R.Operation(R操作)期待由其他组件的Class.Operation(类操作)实现，即

&ForAll; o &Element; Comp . R,

满足以下条件

o and c &NotElement; Comp . Own)

可以通过将类、实体和操作元模型实例化来规定应用层针对情况所需的变化。一旦规定了变化，下一挑战是在应用中如何以一致的方式实现所述变化。该系统将变化表征为添加新的情况和/或从一个情况切换为另一情况。该新情况可以通过扩展应用、将不同的应用组件组合成或整合成一致整体来实现，而切换情况可以通过选择一组有效的组件变型来实现。为了利用不同的元模型实现所述所描述的变化，该系统提出了一组操作符来实现该变化，并确保一致性提高。这些操作符如下：

扩展操作符根据图4、图5和图6中定义的扩展样式在类、实体和操作方面扩展现有的组件。

给出组件Comp＝<Own，P，R，EO，ER，X，V>以及组件扩展X＝<Cx，Ex，Ox>，产生的组件CompR＝Extend(Comp)定义为

CompR.Own＝Comp.Own∪X

Comp_R.X.C_x＝Comp.X.C_x∪ⁿ _i＝1Extend(Class_i)∪Instantiate(C_xp)∪Instantiate(O_xp)

Comp_R.X.E_x＝Comp.X.E_x∪ⁿ _i＝1Extend(Entity_i)∪Instantiate(E_xp)

Comp_R.X.O_x＝Comp.X.O_x∪ⁿ _i＝1Extend(Operation_i)

Comp_R.P.O＝Comp.P.Operation∪provided(Comp_R.X.O_x)

假如

({Comp}_{R} . X . O_{x}) = {&ForAll; c . Operation &Element; {Comp}_{R} . X . O_{x} | c &Element; Comp . Own}

Comp_R.R.O＝Comp.R.Operation∪required(Comp_R.X.O_x)

假如

({Comp}_{R} . X . O_{x}) = {&ForAll; c . Operation &Element; {Comp}_{R} . X . O_{x} | c &NotElement; Comp . Own}

Comp_R.EO＝Comp.EO∪provided(Comp_R.X.E_x)

假如

({Comp}_{R} . X . E_{x}) = {&ForAll; e &Element; {Comp}_{R} . X . E_{x} | e &Element; Comp . Own}

Comp_R.ER＝Comp.ER∪required(Comp_R.X.E_x)

假如

({Comp}_{R} . X . E_{x}) = {&ForAll; e &Element; {Comp}_{R} . X . E_{x} | e &NotElement; Comp . Own}

Comp_R.V＝Comp.V

变化操作符通过添加类、实体和/或操作变型来为组件添加新的变型。给出组件Comp<Own，P，R，EO，RO，X，V>以及其现有变型V＝<C_v，E_v，O_v>，在Comp中添加一新变型V_new产生组件Comp_R，其中

Comp_R＝Variation(Comp，V_new)

使得

Comp_R.V＝Comp.V∪V_new

其中V_new C_V＝Instantiate(C_vp)

V_new.E_V＝Instantiate(T_vp)

V_new.O_V＝Instantiate(O_vp)

Comp_R.D＝Comp.D

Comp_R.P＝Comp.P

Comp_R.R＝Comp.R

Comp_R.X＝Comp.X

用于将新变型添加在组件抽象化中的合格的准则：

且c∈C_v.CmetaData

且e∈E_v.metaData

&ForAll; op &Element; O_{v},

&Exists; c &Element; Own . Class | c . operation, override = op

组合操作符将两个或更多组件组装(组合)以引起：组件还可与其他组件组合。

给出组件Comp₁＝<Own，P，R，EO，ER，X，V>，Comp₂<Own，P，R，EO，ER，X，V>，以及P2R映射关系(所提供的界面和实体与所需的界面和实体之间的一组映射)

界面map^o(Comp1.Operation_i→Comp2.Operation_j)定义为

或

类似地，实体map^E(Comp₁.entity_i→Comp₂.entity_j)定义为

(entity_i∈Comp₁.EO and entity_j∈Comp₂.ER)OR(entity_i∈Comp₁.ER and entity_j∈Comp₂.EO)

则

Comp_R＝Assembly(Comp₁，Comp₂，P2R)定义

Comp_R.Own＝Comp₁.Own∪Comp₂.Own

Comp_R.P＝Comp₁.P∪ComP₂.P

Comp_R.R＝Comp₁.R∪ComP₂.R-Resolved(P2R)

Comp_R.EO＝Comp₁.EO.own∪Comp₂.EO

Comp_R.ER＝Comp₁.ER∪Comp₂.ER-Comp_R.EO

Comp_R.X＝Comp₁.X∪Comp₂.X

Comp_R.V＝Comp₁.V∪Comp₂.V

其中

得出的(P2R)＝一组操作，这些操作满足Comp₁和Comp₂之间的生产者和消费者关系，即

根据本发明的各个实施方式，该系统能够在包括设计阶段、安装阶段和运行阶段的阶段中配置数据库集中式业务应用。业务应用包括组件组，每一组件根据一组类、实体和操作定义。因此，可以按照元对象组件、类、实体和操作来看到业务应用的变化。提出的元模型规定预定义的可变点、可能的变型以及约束，所述约束通过变型规定可变点的一致插入。配置是选择适当的变型的过程，使得针对一应用的所有可变点一致地插入。该系统在应用开发的三个不同阶段支持该配置过程，所述三个不同阶段为设计时、安装时和运行时。设计时配置是通过模型变换技术和模型合并技术支持的。安装时和运行时配置是通过为所有可能的变型产生适当的元数据来支持的-配置取得所需情况的元数据。

示例

本发明在以下给出的示例中予以描述，该示例仅是为了说明本发明而提供的，因此不构成对本发明的范围的限制。

来自同一商业领域例如银行业的不同企业想要为金融业务开户。它们可能按照数据库集中式业务应用中的五个方面{功能性(F)、业务流程(P)、设计决策(D)、架构(A)以及技术平台(T)}具有不同的需求，因此可能期望在他们的需求中有大量重叠且因此在规范中有大量重叠。忽略该重叠将意味着重做，且导致规范冗余，以后这将产生维护和演变问题。本发明了提供用于利用模型化驱动技术来开发可配置可扩展的业务应用产品线的高效计算系统，且还提供了共性和变化性建模，因此导致单一的规范。

因此，本发明提供了创建具有一组预定义变型的共用的业务应用、从预定组选择适当的变型以及将所述共用应用与所选择的变型组合成专用的业务应用。

例如，考虑针对不同的操作环境开发具有核心银行功能的银行应用。我们假设具有核心银行功能例如开户、存款、取款、转账的银行应用需要针对不同的地理位置例如美国和印度以及同一地理位置的不同部门例如针对印度的地理位置的农村银行、公共部门银行以及私有银行等开发。

尽管该应用就功能内容方面在用户看来将是相同的，但其内部结构和行为可以根据操作环境而变化，即美国的大型银行、印度的私有银行以及印度农村银行。本发明将这样的差异视为可变性。下面列出了其中一些情况和可变性：

●通常，美国银行利用社会安全号码(SSN)作为客户的主要标识，而在印度私人银行使用永久账号(PAN)作为类似用途。另一方面，印度农村银行可能使用属性的组合，例如客户的名称和母亲的名称作为客户的主要标识。这导致用于美国银行、印度私人银行以及印度农村银行的类和实体模型上有一些差异。

●对于印度私人银行和印度农村银行而言，用以显示客户细节的屏幕的布局可能不同，因为母亲的名称对于农村银行而言应当可见，而对于其他银行应当隐藏。

这导致了用于印度农村银行和其他印度银行的GUI模型是不同的。

●从一个账户到另一账户的转账功能对于印度农村银行、印度私人银行以及美国银行可能是不同的，因为他们根据不同的银行业监管。

本发明提供了一种用于规定上述结构变化和行为变化的方法，所述结构变化和行为变化导致规定包括若干相关成员的应用系列，所述成员中的每一成员的规范可以源于应用系列规范。系列成员共享一共用的核心并以以上列出的预定义方式彼此不同。此外，取决于成员的特定环境的需求，所述成员可以独立地演变，例如，如果是已婚客户，印度私人银行可以决定捕捉客户的结婚周年日作为附加信息。本发明中描述的概念可扩展性可以将这些类型的扩展规定为新变型。而且，本发明中规定的方法能够通过配置过程选择系列的适当成员。例如，新的美国银行可以利用SSN码配置为主要的客户标识并利用适当的配置将客户的结婚周年日(这是在印度私人银行中存在的)作为客户细节的附加字段。

而且，本发明降低了用于创建新业务应用的计算成本以及计算时间并引起有效的维护和平稳的演变。

已经参照本发明的各实施方式呈现了前述描述。本发明所属领域的技术人员将理解，描述的结构和操作方法中的改动以及变化能够被实施而不脱离本发明的原则、精神和范围

Claims

1.一种用于利用模型驱动技术开发可配置、可扩展的业务应用产品线的高效计算系统，所述系统包括：

至少一个服务器；

网络；以及

(g)定义业务应用规范，所述业务应用规范要转化为应用架构上的具体实现，其中所述应用架构被分层，每一层表示所述系统的一个视图，所分成的层包括图形用户界面层、应用逻辑层以及数据库层；

(h)将业务应用规范分解为三个模型，所述三个模型包括图形用户界面层模型、应用层模型以及数据库层模型；

(i)针对一个或多个抽象视图对所述业务应用规范建模，其中每一独立的抽象视图定义与所述层及其相应的模型对应的一组属性；

(j)针对各独立的抽象视图创建三个元模型，其中所述元模型包括图形用户界面层元模型、应用层元模型以及数据库层元模型；

(k)将各模型组合以形成单一的统一元模型，其中所述单一的统一元模型实现了规定要由不同层内和跨不同层的相关模型元素的实例满足的完整性约束，这实现了将图形用户界面层模型、应用层模型以及数据库层模型独立地转化为它们相应的实现，即图形用户界面层代码、应用层代码以及数据库层代码，并且转化为一致的整体；以及

(i)实现相应的规范以及其与其他规范之间的关系的每一单独转化，引起所述应用架构中的所述规范的一致实现。

2.如权利要求1所述的系统，所述系统还包括至少一个用于测试开发的应用的部署框架，其中所述部署框架包括：

a)至少一个主系统，其用于实现用户与系统互动；

b)具有应用服务器的至少一个服务器，所述应用服务器安装在所述系统上并用于存储开发的应用和元数据；

c)具有网络服务器的至少一个服务器，所述网络服务器安装在所述系统上并用于将用户请求发送至应用服务器；以及

d)数据存储库，其用于存储应用数据。

3.如权利要求1所述的系统，其中所述转化可以手动执行或利用代码生成器执行。

4.如权利要求1所述的系统，其中所述转化是以元模型级规定的，所述元模型级适用于所有的模型实例。

5.如权利要求1所述的系统，其中模型与实现技术无关，且所述业务应用规范能够利用代码生成器，定向至多个技术平台。

6.如权利要求1所述的系统，其中一组规则和约束与每一模型关联，以用于类型检查并保持架构层的业务应用规范之间的一致性。

7.如权利要求1所述的系统，其中所述元模型实现数据库集中式业务应用的结构方面和行为方面的可扩展性和可配置性。

8.如权利要求1所述的系统，其中元模型捕捉图形用户界面模型、应用模型或数据库模型所允许的变化，并将需要的变化以一致的方式实现成应用实现。

9.如权利要求1所述的系统，其中所述元模型能够对一系列屏幕建模，其中所述一系列屏幕的每一成员在所述图形用户界面层中的特定情况下用于相同业务目的。

10.如权利要求1所述的系统，其中所述元模型能够对一系列类建模，其中所述一系列类的每一成员在所述应用逻辑层中的特定情况下用于相同业务目的。

11.如权利要求1所述的系统，其中所述元模型能够对一系列实体建模，其中所述一系列实体的每一成员在数据库层中的特定情况下用于相同业务目的。

12.如权利要求1所述的系统，其中所述单一的统一元模型能够实现跨越多个架构层的合格的约束的规范。

13.如权利要求1所述的系统，其中所述系统提供组件抽象化和逻辑演算，所述逻辑演算有助于赋予数据库集中式业务应用的结构属性和行为属性。

14.如权利要求1所述的系统，其中所述系统能够在包括设计阶段、安装阶段和运行阶段的多个阶段中配置所述数据库集中式业务应用。