CN1983172A - 对象模型转换的设计模式和方法 - Google Patents

Abstract

本发明涉及一种适于在计算机上以对象模型(40)的元素转换序列实施的设计模式(70)。本发明还涉及计算机程序产品(50)，例如包含适于解释该模式的向导。本发明还涉及对象模型的转换方法，包含：访问所述模式的步骤(E2)和执行对象模型的元素转换序列的步骤(E3)。然后可以简单地、系统地且不出错地生成代码。

Description

对象模型转换的设计模式和方法

技术领域

本发明涉及对象模型转换的设计模式和方法。

背景技术

在本说明书中，以下使用的术语具有所说明的含义，除非另有说明：

-“类”：将类的概念指定为在建模体系中共同操作和面向对象的程序语言，尤其是打算在电子数据处理应用中一起工作的数据和进程(或各自的属性和方法)的集合。在面向对象的语言中，每一个对象的型由它的类来定义。类代表共享同样的属性、操作、方法、关系和语义的一组对象。

-“图”：建模元素集合的图形表示，例如示出弧度(关系)和峰值(其它建模元素)的图。UML(标准建模语言)标准建议以下图：类图、对象图、使用情况图、序列图、协作图、转换状态图、活动图、组件图和部署图。

-“代码生成”：这里表示源代码生成器对电子数据处理应用的自动或半自动的产生。它在对软件应用的抽象描述的基础上实现，所述软件应用供应给生成器并服务于控制生成。在分析该描述之后，发生器构造期望的输出代码。该描述通常以比将产生的代码的级别更高的语言表示。这样能使用生成器而不必知道在生成的代码中使用的程序设计语言的形式。

“模型驱动体系结构”(MDA)：表示一组OMG规范，其涉及使用一系列的模型和它们连续的转换的开发过程。这些模型结合了计划的多个维，并从功能模型扩展到源代码模型。这些模型遵照UML标准。从一个模型到另一个模型的进展包含应用规格的渐进提高，且使用由UML元模型授权的转换。

-“建模”：表明状态、问题或系统的抽象表示的活动，其实现目的一方面在于综合和所述综合的传递，另一方面在于解决问题或系统的具体实施。

-“面向对象建模”：表示特定类型的建模，其中建模元素为类、对象、属性、方法、关联等，和“功能建模”相反，在“功能建模”中建模元素为处理函数和数据流。也可参见“UML”。

-“设计模式”(也使用术语“可再使用的设计模式”)：表示解决已知问题的标准方法，所述已知问题例如复现的结构或软件设计问题。设计模式是给定的和复现的设计问题的抽象描述。例如：如何监控对象的持续性？如何监控图形界面？如何控制代码的执行？如何应用状态机？等等。例如，设计模式已在著名的参考著作“Design Patterns，Elements ofReusable Object-Oriented Software”中公开，该著作1995年(Reading，MA：Addison-Wesley)由Erich Gamma等人所著。这些模式区别于算法，算法从形式上描述如何解决问题；这些模式还常常独立于任何程序设计语言。这些模式的描述通常符合固定的形式：

-名称。

-要解决问题的描述。

-解决方案的描述：解决方案的元素和它们的关系。

-结果：解决方案的结果。

-“OMG”(对象管理组)，表示这样的组织，该组织的一个对象要定义标准，以便保证用面向对象的语言的编程的应用的相互兼容性(参考http://www.omg.org)。

-“对象”：表示在面向对象的建模或程序设计中的类的实例，由一组数据(定义类的内部数据)和对其操作有用的程序组成。

-“面向对象”：是指例如模型、语言、应用或应用元素，其组件为类和对象。例如，面向对象的语言为程序设计语言，其中基础组件是类，对象的实例动态地存在于使用它们的电子数据处理程序中。

-“构造型”，表示扩展元模型的语义的建模元素的类型。构造型必须基于存在于元模型中的某些型或类。构造型能扩展语义，但不能扩展已存在的类和型的结构。某些构造型能在UML中预先确定，其它可由用户定义。构造型构成UML的三个扩展机制中的一个，另两个为“标签值”和“注解”。

-“UML”(统一建模语言)：表示由对象建模的记号(而不是语言)，用于在对象系统的开发过程中决定并呈现对象系统的组件，在适当的情况下也产生它的记录。UML通常为OMG标准。这是由Jim Rumbaugh、Grady Booch和Ivar Jacobson所做工作合并的结果，且演化为多种方法。当前已被标准化的UML记号对不同的图表提出图形表示(参见上面)。

“对象建模”在现有技术中已知，并在于按照类和对象创建对现实世界的元素的表示，独立于任何程序设计语言。例如，对象的类被确定，它们内部的数据和使用它们的函数被分离。存在不同的形式。UML是这些形式中的一种(实际上它不仅是记号的编目)。

每种面向对象的语言都具有实施类概念的特定方法。特别地，对象方法或形式用于定义“高级抽象”的问题，而无需进入指定语言的细节。例如，UML提供工具用于简单地用图表现问题，使其更易接近其解决方案涉及的不同的动作者。

典型地，首先产生抽象的对象模型，例如以解决给出的问题为目的。

抽象的对象模型通常按多个步骤产生。当开发面对对象的电子数据处理应用时，常使用模型转换程序。因此操作多个模型，这些模型是对象模型：

-首先，“分析模型”(或“专业模型”或“问题模型”)；

-然后，“体系结构模型”(将被用于构造该解决方案的不同技术元素的模型)；

-将分析模型与体系结构要求相交得出“设计模型”(或“解决方案模型”)；其最初是“大致的”，然后对其应用不同的“设计模型”，使其变成“详细的设计模型”；

-然后该模型准备产生最终代码(可能被称作“实施模型”)。

然后用面对对象语言(如C#或Java)实施该模型。因此期望对象形式被尽可能严格地定义，优选地被唯一定义，以减少不确定性。

在用Java、C++或C#做软件对象开发的背景下产生了一个问题，该问题是：例如根据MDA规范，恰当地应用设计模式(如从上述引用的参考工作中采取的模式，但不排除其它)到例如UML模型的模型，并附带地、正确地产生对应代码。

这个问题常规的解决办法是人工应用模型到代表预想应用设计的UML模型，以便将该模型转换成新的详细的UML模型，从该UML模型产生代码。

然而该解决方法不尽如人意，因为它是人工的。所以慢并且易生成误差。而且，还可能引起最终模型内的矛盾。此外，它必须一个接一个的应用模式。

因此，对于对象模型的转换的设计模式和方法提出要求，以能够转换对象模型到新的对象模型而不会引起模型内的误差或矛盾。此外，该设计模型必须被设为能更有效地应用多个类似模式。

发明内容

为此，本发明提出一种适于以对象模型的元素转换序列被实施到计算机上的设计模式，其特征在于每个元素转换都是对象模型的建模元素的修改、取消或创建。

在优选实施例中，根据本发明的设计模式还包含一个或多个以下特征：

-对象模型符合UML记号；

-该模式能被计算机程序解释，且该模式适于触发该程序对转换序列的执行；且

-该程序包含向导。

本发明还涉及一种例如包含向导的计算机程序产品，所述向导适于解释根据本发明的设计模式。

本发明还提出一种对象模型的转换方法，包含访问根据本发明的设计模型的步骤，和执行该模式的初始对象模型的元素转换序列的步骤。

在优选实施例中，根据本发明的对象模型的转换方法包含一个或多个以下特征：

-转换对象模型的方法预先包含：访问初始对象模型的步骤，后者包含多个建模元素；对初始对象模型的每个建模元素搜索相关构造型的步骤；以及如果在搜索步骤发现构造型，搜索对应于已被发现的构造型的设计模式的步骤；

-转换对象模型的方法预先包含：备份初始对象模型的步骤；和

-至少一些根据本发明的对象模型转换的步骤由向导实现。

本发明还涉及代码生成方法，该方法包含根据本发明转换对象模型的方法的步骤，以及从对象模型生成代码的步骤，其中所述对象模型是在转换序列的执行步骤中转换的。

附图说明

阅读以下对通过举例的方式给出的本发明实施例的详细描述，并参考附图，本发明的其它特点和优势将显而易见，单张附图示出根据本发明方法的实施例的步骤和组件。

具体实施方式

本发明的基本思想在于重新定义设计模式；本发明意义上的设计模式被设计成能在计算机上以对象模型的元素转换序列的形式实施。

该模式典型地包括对应于指定构造型的标识符，以便它能被找回。

给出的元素转换，例如对象模型的指定建模元素的修改、取消或创建，从而能容易并系统地被恰当的电子数据处理工具实现。此外，对于由常规意义(如上述定义的)上理解的设计模型理论上解决的问题，能发现指定的元素转换序列。因此，以对象模型的元素转换序列来实施设计模式使得对象模型向详细模型发展，然后所述详细模型能实现向代码的系统转换(代码生成)。

更特别地，本发明意义上的设计模式可由数据结构(如计算机文件)描述，这样，当其被程序访问然后解释时，它触发该模式的对象模型的元素转换序列的执行。这样执行特殊的程序用于自动应用设计模式到模型上。

典型地，建模形式为UML记号；在这种情况下建模元素为UML常规操作的元素，也就是包、类、属性、运算、关联、基数、遗传等。

单图示出根据本发明方法一个的实施例的步骤和组件。

该图概略地表示了例如初始对象模型40(如UML模型)、详细的最终模型80、目录(即“模式的编目”)60和程序50，其中目录60包含多个设计模式70(本发明意义上的)，程序50包含向导(用户帮助或辅助程序)。初始模型40是普通模型，即在模型具有足够能产生代码的详细等级之前它以模型的设计阶段的形式出现。

编目可由向导访问，并且它包含的设计模式70能由向导解释。如果需要，向导被连接到建模工具，所述建模工具如IBM的Rational Rose、Softeam的Objecteering或i-Logix的Rhapsody。这样的结果是，建模工具被向导控制并执行诸如将UML模型元素转换或变换成代码的任务。这种情况下，向导和建模工具可被视为形成程序实体50。

如果需要，根据本发明的方法包含访问被开发者指定应用的初始对象模型40的步骤。初始模型包括多个建模元素(即，用标准的UML术语的模型“原子”)。模型包含“建模元素”，例如包、属性或类的操作都是这种元素。初始模型40能被分析(步骤E1)，也就是说，对于初始对象模型的每个“元素”都实现搜索相关构造型的步骤。如果在搜索步骤发现构造型，则接着执行搜索对应于已被发现的构造型的设计模式70的步骤(步骤E2)。

实际上，在开发者的应用的初始UML模型中，向导提供给他选择建模元素的可能性，其中指定的设计模式应用到所述建模元素(或元素组)。为此，在执行程序前，初始模型40被“标记”，即设计模式将要应用到的模型的每个元素被特定的构造型注释，其标签为模式名。因此程序被优选地设计成对用户友好的辅助程序，特别适合上述预备的测量。

然后开发者启动对模式70的执行：为此，例如向导可访问目录60并选则要执行的模式70。为此，恰当的模式70包括对应于已被发现的构造型的标识符。

程序能优选地保存初始模型40的备份，以允许取消或执行出错时的“取消”命令。

已选择模式70的转换序列典型地通过建模工具以可执行脚本的形式产生，由向导使所述可执行脚本与这些工具相联系。例如，向导用UML环境提供的脚本语言编写(例如用Rational Rose的VBA或用objecteering的J语言)，且“设计模式”被向导模块读取，所述向导模块解释每个元素转换的正式记号。

然而，用于每个元素转换的正式记号能保持独立于UML工具。因此这些模式自身可从UML工具再使用到其它工具。为此目的，向导的引擎可适于每个建模工具的环境。这样，程序实体50(即，向导加建模工具)适于访问并解释模式以便执行元素转换序列。

例如，模式70可以是一组元素转换，每个元素转换是独立于任何特定建模工具的正式子句。这样，可提供单个通用的脚本(即程序50的引擎)，所述脚本读取、解释并执行这些模式70。

元素转换序列因此对应于模式70。然后由向导选择的序列被传递给解释并执行转换序列的程序50的特定“引擎”(步骤E3)，其中所述转换序列应用到出现在建模工具的存储器中的对象模型。该序列的执行将初始模型40逐渐转换成更详细的新模型80。每个设计模式70(例如：“单元素”、“工厂”、“代理”、“迭代器”、“状态”等，见引用的参考著作)以元素转换序列的形式执行。每次转换引起模型40的基本变化，例如增加属性、创建类、叙述属性的型、增加关联等。因此元素转换是“动作量”。每个量对应于独立的动作，例如由建模工具独自处理的动作。这可通过呼叫特定的原语取得，所述原语符合在建模工具中实施的模型(例如：“加属性”、“重命名关联”、“创建包”等)。特定的动作序列解决特定的问题(根据设计模式)。这样对每个模式70而言对应存在这样的程序，该程序自动应用到建模工具中实施的UML模型40。假定多个序列具有相同逻辑结构(相同逻辑面的“动作量”序列)，那么它们可以另外地被相同电子数据处理方法成功并系统地执行，而不引起矛盾。

应用元素转换序列到初始模型40产生详细模型80。然后，在所用建模工具的内部专有表示的基础上，详细模型80用于自动生成相应代码。应当注意也可以是模型的基本原语转换应用到该内部内部专有表示。

生成的代码例如是Java、C++或C#代码。例如，为了实现代码生成，向导可恰当地指示建模工具，该建模工具配备有代码生成器。例如，在具有Rational Rose建模工具的情况下。

例如，考虑希望应用以下模式到设计模型40的情况：模式“状态”应用到模型40的三个类，模式“单元素”应用到四个类，且模式“迭代器”应用到两类。该例中，模型的三个状态类用构造型“状态”标记，四个单元素类用构造型“单元素”标记，且两个“迭加器”类用相应的构造型标记。在标记模型后，程序50执行以下步骤：

-复制初始模型40到详细模型；

-对于初始模型40的每个类：

-分析类并搜索构造型；

-如果发现构造型：

-在目录60中搜索对应于该构造型的模式70；

-开始执行该模式70(其创建、修改或消除详细模型80中的建模元素)；

-结束“如果”测试；

-结束“对于初始模型40的每个类”的循环；

-//该步中构造新的详细的设计模型80；

-从详细的设计模型生成代码。

上述方法系统地、快速而无误地将初始的模型40转换到详细模型80，且该详细模型随后被用作自动生成代码。根据该方法，开发者随后可应用多个设计模式到单个执行指令，这提高了方法的功效。这是可能的，因为根据本发明的模式70具有指定的逻辑结构。而且，每个具有相同逻辑结构的模式70能在其它模式后执行。

对于本领域的技术人员显见的是，本发明不限于以上描述的变体并易受许多其它变体的影响。例如，使用上述机制的精神是可能的：

-从或多或少的正式描述创建/生成新的模型(例如从文本)，这为从文本开始的UML产生机制提供了可选项；

-利用“分析模式”将规范模型转换成例如分析对象模型，或利用“结构模式”从分析模型构造设计对象模型；更一般地，可以设想将本发明应用到任何类型的对象模型；对于具有其它可用模式类型来说这是足够的，不仅仅是设计模式；

-转换模型(例如从非对象模型到对象模型或从LDS到UML或反之亦然)；且

-制造语言转换器(例如从COBOL转换成C或从C转换成Java等)，因为程序设计语言可以借助于元模型描述，并且以另一种语言来重写一种语言的方式能被转换成设计模式的形式。

最后应当注意，本发明还能用于通过应用“结构模式”，从分析对象模型产生设计对象模型。为此，通过应用MDA准则，可能的是通过“交叉”分析模型和结构模型来构造设计模型。

Claims (10)

1.一种适于在计算机上以对象模型的元素转换序列实施的设计模式(70)，其特征在于，每个元素转换是所述对象模型的建模元素的修改、取消或创建。

2.根据权利要求1的设计模式(70)，其中所述对象模型遵照通用建模语言记号。

3.根据权利要求1的设计模式(70)，其特征在于：

-所述模式能被计算机程序(50)解释；

-所述模式适于触发所述程序(50)对所述转换序列的执行。

4.根据权利要求3的设计模式(70)，其中所述程序(50)包括向导。

5.一种计算机程序产品(50)，例如包含适于解释根据权利要求1的设计模式(70)的向导。

6.一种对象模型的转换方法，包含：

-访问根据权利要求1的设计模式(70)的步骤(E2)；和

-执行所述模式的初始对象模型的元素转换序列的步骤(E3)。

7.根据权利要求6的方法，在权利要求6的步骤之前包含：

-访问所述初始对象模型的步骤，所述初始对象模型包含多个建模元素；

-对所述初始对象模型的每个建模元素，搜索相关构造型的步骤(E1)；及

如果在所述搜索步骤发现构造型，搜索对应于已被发现的构造型的设计模式(70)的步骤。

8.根据权利要求6的方法，在权利要求6的步骤之前包含：备份所述初始对象模型的步骤。

9.根据权利要求6的方法，其中所述步骤部分地由向导实现。

10.一种代码生成方法，包含：

-根据权利要求6的方法的步骤；及

-从所述对象模型生成代码的步骤，其中所述对象模型是在执行所述转换序列的步骤中转换的。

Images