CN101617294A - 组件式开发的改进 - Google Patents

Abstract

本发明披露了一种改进软件组件的方法和工具，该方法利用上下文引导的改进规范和改进规则通过执行深度组件改进来大大的增加组件在不同上下文的可重用性。

Description

组件式开发的改进

技术领域

本发明涉及组件式开发(CBD)，特别涉及使组件适合于在不同上下文使用的新方法。

背景技术

在过去的十年间，信息技术产业领域的许多软件***已经采用了组件式***(CBS)这一创新的***架构，并相应的采用了组件式开发(CBD)的软件开发过程，这一架构和过程大大地减少了开发的时间和成本。组件式***由同一团队或第三方公司开发，封装了早先开发知识和专门技术的资产，使用可重复使用的软件组件进行软件***的设计和构建。组件式***将软件设计的重点从软件编程转向了整合软件***。

“组件”是指可在不同软件***中重用的一部分代码或程序。组件由它的接口特性来说明，可能包含了组件的语义、操作或逻辑约束，或组件的行为。定义接口特性的数据被称为“组件规范”。组件规范给出了组件的特性及在不同上下文或用例场景下的适用性。

组件重用和无缝的***连接的一个难点在于重用上下文的高度变化性。在此，由数据模型的类型、组件将放置的***架构及企图使用的程序特性来表示组件使用的上下文。术语“上下文”一词不同于单一的用例场景，单一的用例场景仅仅由组件将使用的应用程序类型来说明。

组件式***的基本原理在于组件是构建应用程序的独立重用单元。然而，目前，不经改进而可重复使用的组件不多。引起该问题的原因举例如下：不完整的组件规范、组件和包括应用软件架构的重用上下文之间的错配、功能性需求、软硬件环境、质量属性以及其他相关的协作组件。为解决该问题，有必要提供一种自动化深度组件改进技术。“深度”改进意味着组件结构的改进，也即是超出组件基本的输入输出转化的一种改进，依据改进可将组件视为一个“黑匣子”，无需了解组件的功能性知识。

多种改进技术已被提出来了。它们中的第一项被称为“组件定制”，它适用于简单层面的改进。最终用户可从一套预包装在软件组件包中的固定选项中定制所需的软件组件。组件应当可定制以适应在重用过程中特定真实环境的需求。很显然，组件定制是整个组件重用过程中一项十分有效的工作，但那些组件需要内建一套特定的服务以实现定制的需求。

在另一项被称为“活跃接口”的改进技术中，组件接口被定义为一系列端口。该接口在帮助软件开发者进行组件改进时必然发挥更重要的作用。当一个方法被调用时，组件的一个活跃接口可以通过编程来实现。由于一个端口与一系列方法相关联，每个方法的请求也是对一个端口的请求。内部组件接口由私有的和受保护的方法组成。尽管某些内部方法对于组件是私有的，它们仍可支持一个活跃接口并拥有他们自己的生命周期前后阶段。然而，用这种方法展现的组件内部接口并不暴露它的实现过程。

如前所述，活跃接口机制被限制在标准接口界限内改进组件的行为。一般而言，组件的设计者可以建立特殊的端口，允许组件的策略决定被改进。通过这种方式，加强了组件接口，如同在众所周知的开放实现(由施乐公司的帕洛阿尔托研究中心(PARC研究中心)提出)中，使得关键决定得以改进。活跃接口的改进技术由组件仲裁器的内部改进机制所支持。这样的仲裁器可以很轻松地集成到任何组件中。

更常用的组件重用技术是组件封装。例如，Microsoft.NET框架提供了一个封装工具(COM Wrapper)为开发人员在.NET环境中封装先前Windows组件所使用。虽然适用于某些情况，但组件封装在改进组件时无疑产生了繁重的代码冗余，并时常使改进组件和目标***性能下降。此外，组件封装只能在非常有限的范围内进行组件接口的改进。

发明内容

从而，依然需要对组件式开发领域进行改进。

本发明的第一个方面提供了一种软件组件改进的方法，其包括：

从第一组件中提取一个包含二进制码和元数据的组件规范；

建立一个上下文引导的改进规范；

依照上下文引导的改进规范及改进规则来改进至少第一组件的一部分；

以第一组件中改进的和未改进的部分为基础生成改进组件。

优选地，该方法进一步包括建立改进规则的步骤。

优选地，改进规则从预定义的改进规则集中筛选。

优选地，当一个选定的改进被请求时，上述改进规则将被自动触发，同时上述改进规则执行一个改进算法以产生一个或多个合成改进。

优选地，上述改进算法被存储于库中，通过改进规则调用。

优选地，资格预审过程依据包括***架构、功能性和质量属性的***需求来选择第一组件。

优选地，改进规则从库中选择。

优选地，库拥有一个开放的结构。

优选地，改进规则以组件式***和组件的程序域知识或以应用域知识为基础建立。

优选地，组件改进规则被绑定入组件改进规则对象的二进制类中。

优选地，根据健康性条件检查组件改进的步骤，使其符合正确的操作。

优选地，当拟定改进破坏了健康条件时，***向软件开发人员或用户提出警告。

优选地，健康性条件以组件式***和组件的程序域知识或以应用域知识为基础建立。

优选地，生成一个依赖关系图以描述改进对于其它组件或同一组件中其它部分的影响。

优选地，在最终通过审核并使用前，根据提出的上下文引导的改进规范检查突变式改进的组件的适用性。

优选地，该方法适用于.NET平台中。

优选地，组件规范包括组件的结构和由功能性及服务质量组成的语义。

优选地，第一组件的骨架由第一组件的类型，类，方法特征符创建，骨架中不包含方法体。

优选地，改进规则对象被应用于改进相关改进组件的方法体。

优选地，一个改进组件的骨架由改进的或***的方法体或方法体的部分所构成，用于建立改进组件。

优选地，该方法适用于JAVA平台。

优选地，组件改进在源代码层执行。

优选地，提取和改进的组件规范采用XML格式。

优选地，组件改进在二进制码层执行。

优选地，组件规范包括组件的JVM二进制码和Java元数据。

优选地，组件规范包括组件的结构和接口的简要规范。

优选地，Java的字节码引擎类库据上下文改进规则定义的改进规则实例改进组件的二进制码。

本发明的第二方面提供了一种生成改进组件的工具，其包括：

从一个第一组件中提取组件规范的装置；

建立和/或编辑上下文引导的改进规范的装置；

依照上下文引导的改进规范及改进规则来改进至少第一组件的一部分的装置；

以第一组件的改进的和非改进的部分为基础生成改进组件的装置。

优选地，该工具进一步包括一个改进规则提取器，用以创建和编辑改进规则。

优选地，该工具进一步包括一个开放结构的改进规则库。

优选地，该工具进一步包括一个类库生成器，用以自动生成改进规则库的类库。

优选地，该工具进一步包括一个组件规范(CS)浏览器工具，用以对组件的结构进行导航。

优选地，组件规范浏览器中的依赖关系图显示了组件和/或改进规则实例之间的依赖关系。

优选地，该工具被改进用以第一方面的方法的实现。

根据进一步的方面，提供了一个包括第二方面的工具的计算机程序产品。

附图说明

在此，将以实例的方法介绍本发明，并附以下参考图进行说明：

图1根据本发明的一方面，描述上下文引导的规则驱动的突变式组件改进的过程；

图2根据本发明的一方面，描述自动实现改进机制的组件改进工具的***架构；

图3根据本发明的一方面，描述在.NET框架中实际突变式组件的改进实现过程；

图4根据本发明的一方面，描述在Java环境下实际突变式组件的改进实现过程；以及

图5根据本发明的一方面，描述了改进规则库、自动绑定和改进规则应用程序。

具体实施方式

下面将阐述本发明的方法和装置。一种新的不附加额外代码冗余、并对基于组件的目标***不产生性能退化的生成组件改进方法。

在此提出了三项关键技术：上下文引导的改进规范(COAS)，自动改进规则及相应的开放结构库，以及规则驱动的组件改进和生成引擎。

组件改进和生成可包含一个独立的组件改进引擎及组件生成引擎。组件改进引擎及组件生成引擎可被统一到同一工具中，同时分别执行不同的逻辑功能。他们通常会被视为独立的组件，由于本应用程序使用的图表目的是作为逻辑图，而不是表述任何特定***的物理结构。因此，提到“组件改进和生成引擎”一般意味着改进或生成功能的其一或全部，除非上下文另有描述说明。

“规则”管理自动化过程；它们协助组成上下文引导的改进规范(COAS)。规则存储于一个开放的结构库中，使得开发者可对其进行完善及添加。规则包括一个推论，即它的一般结构是“A意味着B”。然而，在这里，规则不同于推理规则在其他软件工程领域(如商业规则引擎)中的应用，因为在这种场合下，一条规则也可能会要求用户确认输出结果。

规则可基于组件式***一般性的程序域知识或来源于开发者所在应用域知识。基于一般程序域知识的规则可应用于交叉领域，但依然需要由特定开发者来进行改进或添加。

改进规则包括三个主要方面。首先，一个特定的改进被定义为触发规则的应用程序。当这种改进作为需求改进输入时，规则将自动被触发。其次，改进算法描述了所要求的改进可能会在组件上产生的结果。第三，改进规则介绍了一套由规则的应用程序所实现的改进结果。

所需的和所产生的改进被描述为使用相同的XML语义，用于储存建立自身的上下文引导的改进规范(COAS)的清单。

在一个具体实施例中，使用的改进算法并不完全定义为改进规则的一部分，而是存储于库中。该规则包括了从库中调用的改进算法的名称和任何需要的参数，以及是否应该提示用户确认每个触发的改进。增加了新的算法需要手动编程，但***可以被设计为帮助减轻这一工作，总体目的是将同样的算法使用在多个不同的规则中。

当开发者开始使用该工具时，它已经包括了一套常用的算法(和一套以程序域知识为基础的规则)。许多算法将利用组件(或多个组件)的依赖关系图作为组件开发的基础，这是一个由工具建立的组件结构模型(见下文)。

以下是一则实例，在这一实例中，描述了一则程序域知识如何来定义规则。

实例：

该工具可能会允许在组件内修改方法的访问性/可见性。程序员可能希望在再工程化组件的过程中限制某个方法的可见性。我们知道，如果通过使其变为“私有”属性来限制访问，那么该方法的所有外部调用都将被移除。这是众所周知的。规则的第一个方面如下：

<RequiredEvolution>

<ModifyMemberAccess>

<TypeName>*</TypeName>

<MemberName>*</MemberName>

<MemberAccess>Private</MemberAccess>

</ModifyMemberAccess>

</RequiredEvolution>

匹配′RequiredEvolution′标签内容的修改将触发规则的应用程序(星号在匹配时代表通配符，而且还表示这些空格中的值需要被输入进算法使用)。下面介绍了该算法的使用和规则触发改进的设置：

<Algorithm prompt＝″true″>

<ForEachMethodInBackwardSlice scope＝″external″>

<RemoveMember>

<TypeName>TYPENAME</TypeName>

<MemberName>METHODNAME</MemberName>

</RemoveMember>

</ForEachMethodInBackwardSlice>

</Algorithm>

′ForEachMethodInBackwardsSlice′是算法的名称，该算法还有一个叫“范围”的参数。它是基于依赖关系图使用的算法之一。多个“类别名称”和“方法名称”对是算法的输出，这些是用来生成改进结果的。因此，在形成上下文引导的改进规范(COAS)的同时，如果方法的访问受限，那么该工具将知道外部方法的调用应该被移除。如果算法的提示属性被设为True，那么用户将被提示确认这些变化。

实例结束

以下有两种类型的改进规则：原子改进规则和复合改进规则。一套原子改进规则是基于被提取组件和组件式***上的程序域知识而制定的。复合改进规则是一个原子改进规则支持特定域改进的组合。复合改进规则适用于应用域知识，并生成用户可扩展的改进规则库，支持在特定的商业领域改进的重用。

原子改进规则

Syntax:

If requires“…”evolution then

Defines value of

{…}

{…}

Triggers evolution algorithms

{..}

XML implementation:

XML实现：

<Current evolution>

        <Defined value>

…

        </Defined value>

</Current evolution>

<Algorithm>

        <Triggered evolutions>

…

</Triggered evolutions>

             <Specific healthiness conditions>

…

</Specific healthiness conditions>

</Algorithm>

复合改进规则

XML实现：

<Applicable evolution context>

…

</Applicable evolution context>

<Evolution rules to apply>

            <Atomic evolution rule 1>

       ……

   </Atomic evolution rule 1>

            <Atomic evolution rule 2>

       ……

   </Atomic evolution rule 2>

       ……

   <Atomic evolution rule n>

       ……

   </Atomic evolution rule n>

</Evolution rules to apply>

涵盖了其***架构和特点，组件和组件式***中的软件程序域知识被提取和应用在新的基于组件的开发(CBD)工具中，作为改进算法或改进规则来自动执行生成组件改进过程。这样，组件改进知识可像它本身一样被重复使用。改进知识与改进规则和改进算法一同被获取。改进算法控制整个改进过程，并被内建在组件改进和生成引擎中。改进规则是特定改进知识的提炼。在一个特定改进上下文中的实例，一个改进规则可以创造出一系列的改进规则实例，其中每个实例都是改进规则重用的例子。

高层的程序域知识整体控制生成改进过程，它被模式化成为改进算法并通过一个组件改进和生成引擎使用，同时，低层更具体的知识被提取到改进规则中。

一个可扩展的改进规则库被设置为可存储重用改进规则。应用域知识也可被模式化为改进规则模型并存储在改进规则库中。库作为一种支持典型的现有改进知识重用的方法，它拥有一个开放的架构并可存储新开发的改进规则。自动绑定和应用技术被设计为在运行时自动将组件改进规则及他们的实例捆绑至组件改进和生成引擎中。任何组件改进库的更新都将触发改进规则库的重新绑定，以保持一致性。

一系列健康性条件是保证改进组件有效性的必要工具，例如，保持组件在功能和非功能性方面的连贯性。一系列健康性条件是保证改进有效性的必要工具。在改进过程中，一个健康性条件是决不能被违反的。组件元素间的依赖关系图被生成，包括其类型，方法和子组件。根据依赖和健康性条件，机制决定是否该改进规则实例能够有效执行，以及是否改进规则将被触发，以保证维持受到影响的组件部分和相关组件的一致性。

一个步骤用以生成改进预审资格的组件来消除找到的组件与特定重用上下文之间的错配，首先包括一个根据改进需求和提取的改进规范组成的上下文引导的改进规范(COAS)。上下文引导的改进规范包括了环境、需求功能和质量属性以及方法在内的改进上下文作为一套相关联的改进规则实例。组件改进引擎将上下文引导的改进规范(COAS)作为它的输入。上下文引导的改进规范是贯穿整个组件改进和生成工作过程中最基本的控制文件，它可在XML架构中执行，例如：

<COAS>

<Aimed context>

  Context definition in text or ontological language

</Aimed context>

<Evolution rules to be applied>

  <Instance of evolution rule 1>

  ……

  </Instance of evolution rule 1>

  <Instance of evolution rule 2>

  ……

  </Instance of evolution rule 2>

  ……

  <Instance of evolution rule n>

  ……

  </Instance of evolution rule n>

</COAS>

一个改进规则实例通过集成目标改进的上下文内容，从改进规则库的改进规则得到。该方法还可通过改进引擎来改进组件代码，将上下文引导的改进规范作为指定的输入。最终的方法通过集成已改进部分和组件代码中原始的未变化部分生成目标组件。

图1描述了一个方法的实体及组件改进***的实例。组件库10存储了可重用的组件及它们的组件规范(CS)、缺省的改进上下文及原始的组件代码。改进需求和重用上下文12被输入至一个组件识别组件14，它询问组件库10并从库中选择一个符合改进要求及重用上下文的组件。这一组件是被识别组件16。从库10中选择被识别组件16是基于***架构、功能性及服务质量而获得的。被识别组件16由原始代码组成。

然后，为实现新***的需求或完美匹配重用上下文，被识别组件16需要进行改进。第一步，定义一个上下文引导的改进规范(COAS)。这一规范的合成工具18由程序设计者定义为交互式改进任务集合。它们与重用上下文一起被记录在上下文引导的改进规范的对象20中。换言之，上下文引导的改进规范包含重用上下文的描述，它包括了需求功能、环境，例如软件平台和硬件平台、以及质量属性和一系列相关适用的改进规则的实例22(下文将进行更详细的讨论)。

从应用域知识和组件及组件式***的程序域知识中提取的改进算法和健康性条件应用于上下文引导的改进规范生成的整个过程，以保证改进的正确性和改进组件的连续性。组件的开发者可定义一系列默认的改进上下文以涵盖典型改进过程。这些默认的改进上下文可作为模板来建立新的上下文引导的改进规范。

改进规则实例22与当前的目标改进上下文集成，选自改进规则库24。由改进引擎(稍后描述)提供的组件改进过程26从被识别组件16和适用的上下文引导的改进规范20中接收原始代码作为输入，并用于生成改进代码28。

为了保证改进组件的有效性(对于确保一致性十分重要)，健康性条件从程序域知识32和应用域知识34中生成。健康性条件的有效性必须在组件被视为有效改进前得到确认。执行改进过程的改进引擎26被设计为保证健康性条件在改进过程中决不被违反。

一个描述组件各元素，包括它的类别、方法和子组件之间关系的依赖关系图由执行改进过程的组件改进引擎26生成。

依赖关系图模式化了软件中各个部分的调用关系。依赖关系图的使用可追溯至1984年(K.Ottenstein和L.Ottenstein在ACM IGSOFT/SIGPLAN软件工程研讨会公报中关于实用软件开发环境的“软件开发环境中的程序依赖关系图”177-184页，1984。)在当时，过程性开发是软件开发的主导方式。由于过程式开发只由子程序组成，完整的过程开发依赖关系图也就是子程序的调用关系图。

然而，对于使用面向对象编程的现代软件，情况则更为复杂。例如，见文章“Java***依赖关系图”(Walkinshaw，N.Roper，M.Wood，M.第三次IEEE国际源码分析和操作专题讨论会公报，2003.)。正如在此文中所说，Java程序完整的依赖关系图由四个相关交迭的关系图组成：方法依赖关系图(等同于调用关系图)，类依赖关系图，接口依赖关系图和包依赖关系图。

可视化的依赖关系图是帮助理解代码的一个有效手段，有时甚至在软件再工程化任务中起到相当重要的作用。本发明的工具帮助用户分别查看依赖关系图不同部分的细节(例如类依赖关系图或方法依赖关系图)，而非一次性提供用户过多的信息。

在数学方面，依赖关系图是一个有向图。此外，类依赖关系图是一个无环有向图。普通的用户界面组件已经包括查看和浏览一个无环图、树(如：在Windows资源管理器左边的“文件夹”面板)。如果有任何软件递归调用(几乎可以肯定会有一些)，那么该依赖关系图的方法将包含一个调用周期，而且并不太适合显示在树中。然而，其他可视化技术可使用在无环图中，如节点链接图表。

依赖关系的可视化表现形式同样包含了依赖种类的其它信息，和/或是否对该部分实施任何的修改。通过与依赖关系图的可视化直接交互，将可能使用户实现一些改进。

如上所述，已经有两个领域的知识被识别，一个程序域知识，另一个是基于开发者工作领域的应用域知识(例如，电子商务)。依赖关系图是一种程序域知识，但他们应用了基于改进的更抽象的规则。例如，在改进规则上下文中，我们可以考虑一个“当通过使其私有化的方法限制公共访问，那么所有该方法的外部调用将被移除”的规则。依赖关系图使我们能够识别这些外部调用所处的位置。此外，移除这些外部调用本身将对使用他们的部分代码产生影响。这仅仅是一则应用依赖关系图类型的实例。

因此，依赖关系图可以被用来提醒用户，如果他们要破坏组件的完整性，例如，移除被另一部分所使用的一部分。依赖关系图的显示改进了开发者对“代码的理解”——任何在软件再工程过程中重要和费时的部分(包括组件改进)。在用户界面显示依赖关系图提高了用户对于组件的理解。

根据依赖和健康性条件，改进过程26决定改进规则实例22是否有效被执行，以及进一步判断改进规则22是否被触发，以保证受影响的组件部分及其它相关组件的一致性。

下一个阶段是组件生成38，由下述一个适当的生成引擎所激活。改进组件的目标组件代码40基于改进代码28和从组件库10中提取的原始组件代码42的集合生成。此后，目标组件代码40通过一个校验过程44以检验其在当前重用上下文中的适用性。如果目标组件代码40不符合，则上下文引导的改进规范(COAS)将进一步完善使更适合的组件被改进和生成以达到开发者满意的效果。在这一阶段校验组件可被集成到一个应用程序或一个更大的组件46中，它会在发布至最终用户前进行一次最终的测试。改进规则库24和组件改进及生成引擎都拥有开放式架构。更多的改进规则可从应用域知识34或与组件和组件式***相关的程序域知识32中提取，然后通过改进规则提取器30装配到改进规则库24中。这就提供了通过将新的改进算法知识模式化并***组件改进和生成引擎中将高层次新发现的程序域知识32或应用域知识34应用于***中的可能性。尽管一个开发式架式由组件改进和生成引擎提供，改进算法的提取和***仍需要大量的来自软件开发者的介入。

图1的过程由一个合适的改进工具激活。这一合适工具的实体显示于图2中。这一规则驱动的智能***目的旨在减少组件改进的复杂性和难度，以便在进程和组件间进行区分。

本工具的架构由三部分组成：组件分析，组件改进和组件生成。

在本工具中，上下文引导的改进规范(COAS)被定义在一个基于XML的规范语言中。整个生成组件改进过程由改进和生成引擎中内建的改进算法控制，由上下文引导的改进规范指挥，作为输入提供。组件规范(CS)是XML中组件的接口和架构的规范，它由组件规范提取器50自动提取并显示在组件规范浏览器52中。

一个组件规范提取器50从组件的元数据中生成一个组件规范，同时组件规范浏览器52可令组件开发者54或软件开发者56查看组件规范，给开发者提供关于接口架构和组件逻辑过程的知识。组件改进规则存储在改进规则库60中。改进规则是组件改进已知规则的正式定义，它由提取器组件62从组件和组件式***的程序域知识64及应用域知识66中提取。改进任务由一组改进规则实例实现，这些实例是在目标改进上下文中特定的改进规则的实例。改进规范定义了目标改进上下文以及被识别组件68是什么、在哪里以及如何被改进的信息。被识别组件68拥有它自己的由组件规范提取器50提取的组件规范58。组件改进引擎70通知组件生成引擎72如何通过向其提供改进代码74来重组组件。改进组件74和76的变化部分将与识别组件68的未变化部分(即组件68的源代码)集成。

本工具支持动态和扩展的组件改进规则。改进规则库生成器78映射了一张从改进规则库60提取的改进规则图到二进制类80中，这个映射关系可通过组件改进引擎70访问。软件开发者66可从他们的专业领域的应用域知识或他们的组件或组件式***中的程序域知识中提取更多的改进规则。这些新的规则通过改进规则提取器62存放于库60中。

将新发现的高级程序域知识64或应用域知识66作为新的改进算法建模并将其***组件改进引擎70中可能会更加合适。这一过程由改进算法提取器82支持。不过，它常常是通过手动来处理。

软件开发者56和工具间的接口包括一个上下文引导的改进规范生成器84和一个组件规范浏览器52。上下文引导的改进规范生成器接受改进算法和健康性条件，在建立正确的上下文引导的改进规范时使用。对于软件开发者而言，改进一个组件等同于完成一个改进规范文档。这样，改进组件可在无需更多用户干预的情况下被自动地生成。

由于不同的组件模型都拥有他们各自的执行结构，本工具可在.NET和Java平台中执行。在任一环境中，本工具由以下部分组成：1)一个组件规范提取器，用以从被识别组件中提取组件规范，也就是它们的二进制代码和元数据；2)一个组件规范浏览器，用于软件开发者获取对于组件交互结构和行为的认识；3)一个上下文引导的改进规范生成器，用于软件开发者建立和编辑改进规范；4)一个改进规则提取器，用于软件开发者建立和修改改进规则；5)一个改进规则库，用于存储、提取和维护改进规则；6)一个类库生成器，用于自动生成改进规则库的类库；7)一个组件改进引擎，用于根据上下文引导的改进规范来建立被改进组件的变化部分；8)一个组件生成引擎以二进制代码为基础自动地生成改进组件。

组件可进行改进得益于现代编程语言的框架性结构，例如Java和.NET。以现代语言编写的组件可同时在运行和编译时期进行改进。一个被识别组件的改进通过将组件的变化部分替换为组件改进引擎生成的中间代码来实现。组件生成引擎通过从它的原始代码和被改变的代码来重组组件产生二进制改进组件。

图3描述了生成组件在.NET框架中改进过程的实现。在图3中的参考编号的作用与图2相同。在这一实现中，一个在.NET中的原始组件100，由可执行档格式标题(PE)、元数据和中间语言(IL)代码三部分组成，根据特定的重用上下文改进，改进组件生成为三个部分，也即是可执行档格式标题(PE)、元数据和中间语言(IL)代码。被改进的组件将被集成进目标程序中。

过程的实现包括三个方面：组件规范提取器102，用户环境104和改进及生成引擎106。

组件规范提取器102从组件的中间语言代码和元数据中提取结构和接口的概略规范，并显示在组件规范浏览器52中，作为用户环境104的一部分。

用户环境104提供给软件开发者一个交互的窗口用以检查组件100的结构和行为，并根据遵循的改进需求从改进规则库112中选择适当的改进规则110，组成上下文引导的改进规范108。改进算法和健康性条件被应用在在创造基于上下文的改进规范时。

在图1和图2的描述中，改进和生成引擎106遵循一般改进改进过程，但在.NET环境下却需要遵循许多.NET下的规则。组件种类和成员的结构首先从原始组件100中被提取(102)并复制生成一个原始组件的骨架(114)，它由组件的类型、类和方法签名组成，但方法实体为空。定义在上下文引导的改进规范108中的改进规则实例被绑定和实例化到相应的二进制对象，它被称作改进规则对象116。改进规则对象116在二进制代码的级别上直接适用于原始组件100。改进规则对象116的一部分适用于改进原始组件的骨架，生成一个新的方法实体为空的改进组件骨架118。其它改进规则对象可适用于改进原始组件相关方法的实体120。方法体的被改进中间语言代码122被保存在方法缓存122中。如果一个演动作包括了在原始方法体前或后***一个新的方法或新代码的一部分，新的方法体或部分将通过上下文引导的改进规范108以任何.NET支持的源代码形式获得。新的方法体或部分于是被保存在方法缓存122中。在下一步中，方法缓存中的源代码被编译进中间语言代码120并验证其正确性。

在生成改进的上一步，引擎106将改进组件骨架118视为原始组件代码的突变，并将其与改进或***的方法体或主体的部分122进行集成。也即是，如果方法缓存中的中间语言代码是新方法体，那么将其***相应骨架的方法中；如果方法缓存中的中间语言代码是新方法体的一部分新代码，那么将其***相关方法中方法体的开头或结尾部分。对于其它组件中未变化的部分，引擎只是简单地将其从原始中间语言代码拷贝至新的组件中。一个新的元数据将从组件的改进中间语言代码中产生。

总之，只有原始组件的变化部分会被它的改进版本所替代。组件生成的最后步骤是产生新的二进制格式的.NET组件。

图4描述了生成组件改进过程在Java平台上的实现。生成组件改进的实现在不同的平台中有所不同，正如现有的组件模型也不尽相同。

在Java平台中，组件的改进可以在源代码或二进制码层中发生。

在源代码层，组件改进引擎支持基于XML组件规范的修改并发布一个新的改进组件的组件规范，也即是，被改进组件规范130。在第一步中，一个上下文引导的改进规范132被描述并绑定在组件改进引擎134中。接着，组件改进引擎134根据在上下文引导的改进规范132中的改进规则实例140修改原始组件138的组件规范136。最后，被改进组件规范130作为一个新的XML格式的组件规范被生成。

对于源代码层的改进，组件138的组件规范136需要非常详细地被称作全面组件规范的代码详述。组件生成引擎142首先将组件改变部分的改进综合组件规范130转换为Java的源代码，接着，它集成了原始代码的改变部分与其它未改变部分的代码。组件生成引擎最终发布为Java源代码中的改进组件144。

对于二进制代码层的改进，与.NET中间语言代码和元数据不同，在Java组件模型中Java虚拟机二进制码和Java元数据被作为等价的技术被使用，例如来源于Sun Microsystems的Java元数据接口和Java EE 5平台的注解。其它的二进制代码层重构技术也可能被用于支持生成组件改进过程的执行，例如，Java字节码引擎类库。

在二进制代码层的改进，组件的组件规范136是组件结构和接口的概要规范，它不包括代码细节。组件改进引擎使用例如Java字节码引擎类库的技术，根据定义在上下文改进规范中的改进规则实例来适配组件的二进制代码。组件改进引擎通过集成二进制代码中改变和未改变部分，重组生成最终由Java虚拟机二进制代码和Java元数据组成的组件。

注释是一种新的特征，最初在Java2平台中被引入至标准版本(J2SE)5.0。他们是包括了非常简单句法的元数据，由于以@开头可被识别。注释常用于嵌入程序数据中，也可作为单独的文件存在。

图5描述了自动绑定和改进规则的过程。

改进规则库支持改进知识在较低级别控制层次的重用，即，改进规则和他们的实例，以及上下文引导的改进规范的全部或部分。改进规则库是一个资产存储库，它跟踪和管理改进规则，并能在未来的组件改进过程中被使用。

改进规则库操作的生命周期包括四个阶段：1)使用改进规则提取器62建立组件改进规则；2)组件改进规则存储于库***60中；3)组件改进***绑定至二进级类80；4)通过引入它们的类，参考在组件改进和生成引擎70，72的组件改进规则。

伴随着XML数据绑定技术，生成了一系列的类以反映定义在改进规则中的数据模型。改进规则的实例可像来源于改进规则类中的对象一样被绑定在自动化工具中。接着，组件改进引擎将直接使用这些对象实现组件改进。一个新的改进规则将从应用域知识中提取并添加到库中。

随着自动绑定，一个组件改进规则150被映射在组件改进规则对象的类152中，组件改进规则实例154被动态地映射在面向对象的编程对象156。组件改进规则实例的程序通过将信息传递至活跃方法并在对象中触发方法来存档。随着自动绑定，组件改进和生成引擎独立地改变改进规则。改进规则的改变将触发对组件改进和生成引擎规则的重新绑定。

自动绑定机制包括一个规划编辑器，它将组件改进规则译为一系列特定的规划类，包含适当的正确访问和突变方法，数据编组框架支持在XML格式改进规范和现有及概要驱动的类的相关联实例图表间进行编组和解组。

在改进类型的编译中，XML格式的组件改进规则被编译为Java或C#的类。由XML格式改进规则编译的Java或C#的类可直接被组件改进和生成引擎所使用。

改进规则的编组/解组在注释类和改进规则间建立转换。XML概要为改进行为和一个注释类的实例之间定义解释。它用于将改进规则实例关联至组件改进和生成引擎中的特定对象

总之，可见本发明的方法和工具与现有基于组件的开发和组件改进方法及工具相比，具有较大优势。

本发明为组件改进和重用技术作出了杰出的贡献。本方法和相关设备通过无缝地重用现有的相关组件，减少了开发成本和时间，以及组件式***投放市场的周期，同时由于消除了组件间接口和行为的不匹配性，提高了组建式***的质量和效率。本发明同样可用于组建式***的***改进。也即是，通过组件改进改变组件，从而向组建式***引入新的功能或服务质量。

与现有的其它技术相比，本方法和装置独特的竞争优势在于它有助于改进组件和目标***在深层次上附带零或较少的冗余而实现组件改进。另一个竞争优势在于它在改进和突变过程中的高自动化程度。

改进规则是动态且以过程为引导的，提供了上下文引导的改进规范的基础，它由一个上下文描述而非仅仅是用户用例场景组成。这一方法实现了一种低代码冗余的突变改进，一种全新的深层改进以及高质量和正确性的改进组件。

在不脱离本发明范围之外，可进行各种改进和修正。尤其是，可以预见本发明将在除.NET和Java平台之外的其它软件平台使用。

Claims (35)

1.一种改进软件组件的方法，包括：

从第一组件中提取一个包含二进制码和元数据的组件规范；

建立一个上下文引导的改进规范；

依照上下文引导的改进规范及改进规则来改进至少第一组件的一部分；

以第一组件中改进的和未改进的部分为基础生成一个改进组件。

2.根据权利要求1所述的方法，进一步包括建立一个改进规则的步骤。

3.根据权利要求1所述的方法，其特征在于，所述改进规则选自预定改进规则集。

4.根据权利要求2或3所述的方法，其特征在于，当一个选定的改进被请求时，所述改进规则将被自动触发，同时所述改进规则执行一个改进算法以产生一个或多个合成改进。

5.根据权利要求4所述的方法，其特征在于，所述改进算法被存储于库中，并由改进规则调用。

6.根据任一前述的权利要求所述的方法，其特征在于，资格预审过程依据包括***架构、功能性和质量属性的***需求来选择第一组件。

7.根据任一前述的权利要求所述的方法，其特征在于，所述改进规则由库中选择。

8.根据权利要求7所述的方法，其特征在于，所述库拥有一个开放的架构。

9.根据任一前述的权利要求所述的方法，其特征在于，改进规则以组件式***和组件的程序域知识或应用域知识为基础建立。

10.根据权利要求7至9中任一权利要求所述的方法，其特征在于，组件改进规则被绑定入组件改进规则对象的二进制类中。

11.根据任一前述的权利要求所述的方法，其特征在于，根据健康条件检查组件改进的步骤，使其符合正确的操作。

12.根据权利要求11所述的方法，其特征在于，当拟定改进破坏了健康条件时，***向软件开发人员或用户提出警告。

13.根据任一前述权利要求所述的方法，其特征在于，健康性条件以组件式***和组件的程序域知识或应用域知识为基础建立。

14.根据任一前述权利要求所述的方法，其特征在于，生成一个依赖关系图以描述改进对于其它组件或同一组件中其它部分的影响。

15.根据任一前述权利要求所述的方法，其特征在于，在最终通过审核并使用前，根据提出的上下文引导的改进规范检查生成的改进组件的适用性。

16.根据任一前述权利要求所述的方法，适用于一个.NET的平台。

17.根据权利要求16所述的方法，其特征在于，组件规范包括组件的架构和由功能性及服务质量组成的语义。

18.根据权利要求16或17所述的方法，其特征在于，第一组件的骨架由类型，类，方法标识符组成，骨架中不包含方法体。

19.根据权利要求18所述的方法，其特征在于，改进规则对象可适用于改进相关改进组件的方法体。

20.根据权利要求16至19中任一权利要求所述的方法，其特征在于，改进组件的骨架由改进的或***的方法体或方法体的部分所构成，用于建立改进组件。

21.根据权利要求1至权利要求15中任一权利要求所述的方法，适用于一个JAVA平台。

22.根据权利要求21所述的方法，其特征在于，组件改进在原代码层执行。

23.根据权利要求22所述的方法，其特征在于，提取和改进的组件规范采用XML格式

24.根据权利要求23所述的方法，其特征在于，组件改进在二进制代码层执行。

25.根据权利要求24所述的方法，其特征在于，组件规范包括组件的JVM二进制码和Java元数据。

26.根据权利要求25所述的方法，其特征在于，组件规范包括组件的结构和接口的简要规范。

27.根据权利要求24至26所述的方法，其特征在于，Java的字节码引擎类库据上下文改进规则定义的改进规则实例改进组件的二进制码。

28.一种生成改进组件的工具，包括：

从一个第一组件中提取组件规范的装置；

建立和/或编辑上下文引导的改进规范的装置；

根据上下文引导改进规范和一则改进规则，改进至少第一组件的一部分的装置；

以第一组件中改进的和未改进的部分为基础生成一个改进组件的装置。

29.根据权利要求28所述的工具，进一步包括一个改进规则提取器以建立和编辑改进规则。

30.根据权利要求28或29所述的工具，进一步包括一个开放结构的改进规则库。

31.根据权利要求28至权利要求230间任一权利要求所述的工具，进一步包括一个类库生成器，以自动成生改进规则库的类库。

32.根据权利要求28至权利要求331间的任一权利要求所述的工具，进一步包括一个组件规范(CS)浏览器工具，用以对组件的结构进行导航。

33.根据权利要求32所述的工具，其特征在于，组件规范浏览器中的依赖关系图显示了组件和/或改进规则实例之间的依赖关系。

34.权利要求28至33间的任一权利要求所述的工具，被改进用于权利要求1至27之间的任一权利要求的方法的实现。

35.一个计算机程序产品包括了权利要求28至34之间的任一权利要求的工具。

Images