用于验证交互式组件的属性的方法、软件和处理单元

摘要

本发明涉及具有递归树结构的子组件的交互式组件的属性的验证。所述验证包括：根据所述树来创建有向图，所述有向图包括用于所述树的子关系的弧，以及用于在所述组件之间耦合时创建耦合的弧。所述验证包括：创建表示所述属性的第二图，以及验证所述第二图是否展现在所述第一有向图内。

说明书

技术领域

本发明涉及交互式软件的属性(property)的验证。更具体地说，本发明涉及对按照交互式软件内的交互式组件(component)的层级结构组织的交互式组件的属性的制定和验证。

背景技术

验证和确认是工程中的重要过程。确认包括使用可用的方法来校验系统适合于其目的。对系统进行验证包括：定义所述系统必须在任何时候都具有的属性，以及使用可用的方法来校验所述属性在系统中的确得到保证。

软件的验证需要特定的方法。软件组件是可独立开发和组装以产生软件产品的指令的集合。软件属性是软件组件特有的特质或特性(attribute)。软件的验证可作为包括校验给定属性或属性的集合在给定软件产品或软件组件上是真还是伪的过程来执行。如果组件属性由软件组件实现，则组件属性为真，或者如果组件属性没有实现，则为伪。

测试、审查和分析是主要确立的软件验证过程。

测试包括向受控环境提交系统(软件产品或软件组件)，观察其行为并将其与参照物(例如规范)相比较。试验是一种简单的方法，易于使用，并且非常可信的，但如果受控环境的建立很复杂，则测试可能是非常昂贵的；当对软件与用户或环境的交互进行测试时，尤其如此。

审查包括向一个或几个审查人员提交系统以便检查、评论或批准。审查简单且灵活，但其成本随所需的可靠性水平急剧增加，并且其效率随软件的复杂度而降低，因为当软件的结构是难以阅读时，发现错误或校验属性是困难的。

分析包括：构建系统的模型，验证并确认该模型。因此，如果某个模型持有某种属性，并且如果系统是根据所述模型构建的，那么所述最终系统持有所述属性。存在多种建模技术和模型分析方法。例如，如在Baier等人的Principles of model-checking,MITPress,ISBN 026202649X,9780262026499文献中所描述的，可以构建状态转换模型，并且从穷举模拟产生的图可用于支持如LTL或CTL的与时间相关的属性的验证。如Abrial,The B-Book-Assigning Programs to Meanings,2005所描述的，另一种方法包括：通过应用推理规则对模型进行数学证明，目的是校验在向模型添加更多细节时属性被保留。或者如Proc.ACM POPL’77,ACM(1977),pp.238–252中的Cousot等的Abstract interpretation:Aunified lattice model for static analysis of programs by construction orapproximation of fixpoints所描述的，可以从程序的源代码提取抽象语义，并用于验证属性。

就覆盖度和可靠性来说，分析是一种非常有效的方法，但其复杂性要求专家的干预。此外，当对全软件产品进行分析时，只有有限的属性的集合的可用于验证。例如，有可能的是确保某些类型的软件故障将是不可能的，但不能确保软件正确地响应用户的操作。为新属性定义分析算法通常超出了本领域技术人员的能力，而程序员必须使其自身满足于可校验属性的可用列表。

更一般地，当用于创建软件的语言和用于制定属性的语言之间的语义距离增加时，验证方法的效率和成本降低。具体而言，当所述软件被表示为小的低级别组件的非结构化集合时，难以验证大型软件的高层属性。例如，如果软件产品编程为运算指令的集合，并且所述软件产品应该执行依赖于外部条件和过去历史的复杂运算，那么构建用于测试的受控环境将是非常昂贵的，审查将是困难的，并且分析对于如“仅当该软件接收该输入序列时，显示的该部分才将发生变化”的属性来说将是不可用的。

软件架构是用于将软件组件组织成更小的可重用的组件的规则的集合。软件架构涉及软件执行和数据二者是如何组织的。软件架构可由编程约定或编程语言支持。例如，函数式语言帮助将软件组织为名为函数的运算单元。类似地，面向对象的语言帮助将软件组织为既是数据单元又是运算单元的组件。

由编程语言实施的软件架构可用于通过使得可以制定和校验个体组件的属性，从而减少属性与组件之间的距离，来改进验证方法的有效性。本领域技术人员可容易地定义个体组件的属性，并创建名为单元测试的小型受控环境来在单元测试中使用与组件中相同类型的编程指令测试所述属性。本领域技术人员还可以提交组件用于审查，并期望审查人员能够校验使用用于对所述组件进行编程的相同概念表达的属性。此外，编译器的开发人员可使用他们的关于编程语言是如何组织组件的知识来构建所述组件的模型并校验其属性。例如，编译器可以校验函数是否具有未使用的自变量，或者函数的控制流是否停在非预期的位置。

当在重用任意组件来创建更大的组件时可使用用于创建所述组件的相同的规则的情况下，软件体系结构是递归的。递归的架构有助于管理软件复杂度，因为当将组件与其它组件进行组装时，程序员可选择忽视组件的内部复杂度，或者替代地，深入细节而不必学习新的架构。递归的架构使得本领域技术人员有可能表达可使用分析技术来校验的组件属性。开发人员或说明人员可使用某个组件及其直接子组件的特征来表达所述组件的属性，而忽略进一步的细节。如果需要，可使用相同的技术来为低级别组件定义低级别属性。在Computer(IEEE),25,10,October 1992,pp.40–51中，Meyer,B.的“Applying Design byContract”公开了一种名为面向契约的编程的方法，其依赖于以面向对象的语言对每个类的对象的名为不变量(invariant)的属性的定义。不变量很容易定义，因为它们接近组件并且可以相同语言来书写。然后编程语言编译器或运行时间执行系统校验不变量。类似地，Abrial(参见上文的参考文献)公开了一种名为基于模型完善原则的B方法的方法：更多的信息逐步添加到具有某些属性的有效性的保持的模型。这些方法允许程序员甚至在开始对软件组件本身进行编程之前，在其程序的所有级别的细节处定义属性。

交互式软件指的是：除了执行运算以外，从人、从物理环境或者从其它机器接收输入的软件。几乎所有的现代软件都是交互式软件。例如，文本编辑器、视频游戏、互联网浏览器、智能电话应用以及飞机座舱显示器的软件都是交互式软件。计算机操作系统、所连接的对象的固件以及网络服务器也是交互式软件。如今，新的人体输入和输出技术、智能电话、平板电脑、网络连接和所连接的对象的散布广泛增加了用于设计交互式软件的可能组合的数量。例如，在平板计算机上，输入现在可使用触摸感应表面、如空中指针这样的连接的对象以及如回转仪、加速计或温度计这样的传感器来输入。

交互式软件可与面向计算的软件进行对比。面向计算的软件具有开始和结束，其目标在于从初始的一组数据计算出结果。相反，交互式软件等待输入并根据接收到的输入来触发反应行为或计算。

交互式软件的期望的属性是传统软件的属性，外加非常大量的名为面向交互的属性的属性。面向交互的属性与软件如何响应其输入和用户如何获得其输出、以及软件如何帮助用户执行给定任务有关。仅有几个面向交互的属性适用于所有应用，而大多数必须针对当前的应用来定义。

用于验证传统软件的方法对于校验面向交互的属性来说要么过于昂贵要么不合适。在某种程度上，一些传统方法能有效地帮助开发人员防止应用崩溃。然而，属性验证的传统方法不适合用来验证交互式属性，例如验证无论用户的输入和应用的上下文如何，按钮是否将总是可见。已经定义了另外的方法，但它们是局部的，并且既不覆盖的交互式软件的范围也不覆盖上述属性的范围。提供更广泛包含交互式软件并支持更多属性的验证技术变得必要。

可以通过使终端用户向软件提供可能的输入，并验证应用的行为与其规范一致，并且与用户如何操作它兼容来对交互式软件执行测试。这种方法广泛使用，但其非常昂贵和费时，并且缺乏穷尽性，因为终端用户不能手动执行输入的所有可能的组合。

审查交互式软件是非常困难的，因为交互式行为的复杂度超出了本领域技术人员仅通过阅读程序所能理解的内容。如果审查人员想要校验面向行为的属性，则他们必须创建模型并手动执行分析方法。

已经定义了基于模型的分析方法来支持交互式软件中的组件的验证，通常关注具有高抽象级别的组件。例如，许多模型描述与抽象用户接口(AUI)相关的信息。与有形用户接口有关的大量细节(包括输入和输出模态的描述)没有或很少包括在这些模型中，这使得难以进行或者甚至排除了某些属性的验证。例如，在Proc.EIS 2007,LNCS 4940,Springer(2008)，501-518中，Thimbleby,H.和Gow.,J.的Applying graph theory to interactiondesign公开了一种用于基于图论来对遍及用户交互的软件的属性的验证应用静态分析的方法。Thimbleby和Gow将交互式软件的状态表示为图的节点，图的弧(arc)是确定交互式软件的状态变化的终端用户的输入。然后，该文献公开了一种用于校验处于所有可能状态的软件的属性的方法。然而，Thimbleby和Gow发表的文章公开了整个软件的全局状态和转换，其仅与高抽象级别(任务级别以及抽象用户接口级别)有关。低级别细节(与有形用户接口和最终实现方式有关)的缺乏阻碍了解决与这些级别有关的属性的验证。

更加概括地说，为了支持像编译器中的全自动验证，必须确保程序员或设计人员产生的内容包含要推导出抽象解释的所有必要信息。此外，由于大量面向交互的属性仅可针对给定组件而不是一般性地来定义，因此期望程序员在与面向契约编程类似的开发过程中能够定义尽量接近组件的属性。用传统语言编写的软件的任意部分都会使得这种方法失败，因为自动重构这条代码对程序的交互式行为的影响将是极端困难的。

传统的编程语言(诸如C、C++、Lisp或Java)是从关注运算而不是交互的编程语言得到的。它们主要使用函数调用来进行操作，其对于执行计算是有效的，但对于管理与环境的交互并不有效。在这些语言的情况下，交互是使用事件和回调的系统，或者诸如信号和时隙的变量来管理的。事件在交互发生时(例如，当用户点击鼠标时)由系统创建，然后传递到由程序员定义的并且名为回调函数的特别的函数，其地址被登记并与某种类型的输入关联。这定义了在低级别上依赖函数并且在高级别上依赖交互的非递归架构。在高级别上定义的属性以面向交互的语言表达，但组件是以关注运算操作的传统语言编写的。因此，语义距离很大，并且开发校验属性的算法是极其困难的。例如，控制流太复杂以至于无法确定两个对象的行为是否是独立的，或者图形对象是否总是可见的。

此外，交互式系统的交互式属性并不仅依赖于所述交互式系统的软件部分，而是还依赖于输入和输出设备或者软件操作的所连接的对象的行为。这些子系统的行为可以非常复杂，并且剧烈改变整个系统的行为，从而改变其属性。因此，期望提供不仅用于基于交互式软件的源来校验所述交互式软件的属性、而且用于校验不构建为软件程序或其源不可用的交互式子系统的属性的解决方案。应该是可能的是用与用于对软件子系统进行编程的语言兼容的语言创建这样的子系统的模型，以便将模型与软件源进行组合，并且校验整个所得到的系统描述的属性。

本申请的目的在于：通过提供用于以下操作的解决方案来解决上述问题：

-对交互式系统进行编程或建模；

-然后用接近该编程或建模语言的语言，在所述系统的各个级别的细节处制定个体组件的属性；

-然后自动校验所述属性。

更具体地说，其目的在于：提供用于自动校验交互式系统的组件的属性的工具，当在组件或所述组件的模型中修改或添加子组件时，属性验证的规则自动更新。

发明内容

为此，本发明公开了一种用于验证交互式组件的属性的方法，所述交互式组件被表示为子组件树，所述子组件树包括定义第一子组件与第二子组件之间的耦合的控制结构子组件，所述第二子组件是在所述第一子组件激活时被激活的，所述方法包括：创建表示所述交互式组件的第一有向图，所述第一有向图的节点包括所述第一子组件和所述第二子组件；获得表示所述属性的第二图；在所述第一有向图中验证所述第二图的存在或缺失之一，其中，创建所述有向图包括：创建所述交互式组件与所述组件的子组件之间的第一弧；创建所述第一子组件与所述第二子组件之间的第二弧。

优选地，获得表示所述属性的第二图包括在库中检索所述第二图。

优选地，获得表示所述属性的第二图包括在库中创建所述第二图。

优选地，验证所述第二图存在或缺失之一还包括：验证所述第二图的节点的特性的值。

优选地，所述方法还包括：验证所述特性的值是否在所述第二弧存在时遭到改变。

优选地，显示所述交互式组件包括：显示子组件的子集。

优选地，显示的顺序是由所述树的所述结构确定的。

优选地，显示的顺序是深度优先搜索算法的顺序。

优选地，所述属性是针对所述交互式组件的所述结构的。

优选地，所述属性是针对所述交互式组件的所述行为的。

优选地，所述方法还包括：将节点的类型的情况与所述交互式组件的属性相关联。

优选地，所述方法还包括：将节点的特性的值的情况与所述交互式组件的属性相关联。

优选地，至少一个组件表示将由人执行的一系列动作或将由人遵循的规程二者之一。

所述方法还公开了一种用于验证交互式组件的属性的计算机程序产品，所述交互式组件被表示为子组件树，所述子组件树包括定义第一子组件与第二子组件之间的耦合的控制结构子组件，所述第二子组件是在所述第一子组件激活时被激活的，所述计算机程序产品包括：用于创建表示所述交互式组件的第一有向图的代码指令，所述第一有向图的节点包括所述第一子组件和所述第二子组件；用于获得表示所述属性的第二图的代码指令；用于在所述第一有向图中验证所述第二图的存在或缺失之一的代码指令，其中，用于创建所述有向图的代码指令包括：用于创建所述交互式组件与所述组件的子组件之间的第一弧的代码指令；用于创建所述第一子组件与所述第二子组件之间的第二弧的代码指令。

所述方法还公开了一种被配置用于验证交互式组件的属性的处理器，所述交互式组件被表示为子组件树，所述子组件树包括定义第一子组件与第二子组件之间的耦合的控制结构子组件，所述第二子组件是在所述第一子组件激活时被激活的，所述处理器被配置用于：创建表示所述交互式组件的第一有向图，所述第一有向图的节点包括所述第一子组件和所述第二子组件；获得表示所述属性的第二图；在所述第一有向图中验证所述第二图的存在或缺失之一，其中，创建所述有向图包括：创建所述交互式组件与所述组件的子组件之间的第一弧；创建所述第一子组件与所述第二子组件之间的第二弧。

本发明允许自动验证交互式软件的交互式属性。

交互式属性的验证即使在属性所应用的组件或该应用的其它组件被修改的情况下仍然有效。

根据本发明的方法适合用于校验树形结构的交互式组件的属性。

根据本发明的方法允许对应用于不同组件类型的属性的预先确定的集合的定义。

根据本发明的方法简化了交互式应用的测试。

根据本发明的方法减少了交互式应用的测试时间。

根据本发明的方法适合于在软件开发期间(例如，在编译期间)验证交互式软件的属性。

根据本发明的方法适合于在运行时验证交互式软件的属性。

根据本发明的方法可用于验证软件符合规范或标准。

所提出的方案还适用于校验混合交互式系统的属性，所述混合交互式系统的组件包括硬件、软件、规程和人类行为。

根据本发明的方法适合于当交互式系统由软件组件、硬件组件、规程和人类行为构成时，验证该系统是否符合规范。

根据本发明的方法适合于验证所述系统的后续版本是否依然符合现有的要求和规范。

根据本发明的方法适合于随着发现对于交互式系统的要求和规范而逐步地累积这些要求和规范，并且验证所有的未来版本的系统是否符合这些新的要求和规范。

根据本发明的方法适合于验证规程和人类的组织。

根据本发明的方法适合于自动针对在交互式软件的环境中检测到的组件的属性来调整该交互式软件，以确保保持由该交互式软件和该环境组成的系统的属性。

附图说明

根据以下对多个示例性实施例及其附图的描述，将更好地理解本发明，并且本发明的各个特征和优点将由此显现，在附图中：

-图1a、1b和1c分别以Xml文件、树和显示器的形式显示了包括交互式组件树的交互式应用的三种表示；

-图2显示了本发明的多个实施例中的用于验证交互式组件的属性的方法；

-图3显示了本发明的多个实施例中的交互式组件树的子部分；

-图4a和4b显示了组件树的两个示例，其中，组件中的多个特性的存在的属性由根据本发明的方法验证。

具体实施方式

在本说明书中，将通过针对Djnn平台的组件的示例的方式对本发明进行说明。Djnn平台是(在http://djnn.net/可获得)由申请人开发用于通过对交互式组件进行组装来设计交互式应用的语言和编程工具。本说明书中的组件类型的命名指的是其在Djnn平台中的名称。申请人在与本申请同日提交的欧洲申请No.15305949.8中还公开了用于定义和控制交互式组件的执行的处理单元、软件和方法。本申请中公开的原理是Djnn语言以及用于表达交互式组件的其它语言的基础。

然而，本发明适用于其它语言，并且本领域技术人员可以在保持在本发明的范围内的前提下容易地定义新的属性。本说明书中描述的组件和实现方式仅是作为非限制性示例提供的，并不以任何方式限制本发明的范围，本发明的范围是在所附权利要求书中定义的。

值得注意的是：本发明不仅可用于已经用遵循欧洲申请No.15305949.8中描述的原理的某种语言产生的软件组件，而且还适用于独立存在并已经使用所述语言建模的软件、硬件或其它系统。出于本发明的目的，所描述的系统是根据其描述还是以其它方式执行并没有区别。在本发明的多个实施例中，还可能的是将预期的人类行为建模成组件。尤其可能在以下这样的情况下实现：其中人类行为可以被确定，并且人类行为包括从交互式系统接收信息和对交互式系统执行动作。这样的预期的人类行为可以被定义为期望人所要遵循的规程的集合和能够使用科学知识和观测来预期的可能的行为集合。还可能的是存在具有软件、硬件、规程、可能的人类行为和/或人类组件的混合的系统。例如，如果人执行了规定的行为，则软件和人类行为的混合允许验证人与交互式软件之间的完整的交互；并且可能的人类行为与规程的混合允许验证规程的可行性。相似地，表示规程、组织和人类行为的混合允许验证过程和组织的可行性。

本发明还可以用于创建自动评估其它组件(诸如人、规程和组织)的行为属性的交互式软件，并且使用该行为属性来自动地调整其自身的行为。

图1a、1b和1c分别显示了组件树、通过本发明的多个实施例中的方法从该树推导出的有向图、以及树初始化时的挂钟(wallclock)的布局。

所述组件树可用用于开发交互式应用的语言(如Djnn语言)来直接表达。其还可以通过对包括控制结构组件的组件树形式的现有应用进行建模来构建。

图1a显示了本发明的实施例中的交互式应用的子组件树100a。更一般地，应用可视为大型组件，并且本发明的原理适用于可重新集成到更大组件或应用中的组件或应用二者。在本说明书的其余部分中，符号“/”将表示组件及其其中一个子组件之间的，树中的父-子关系。组件“挂钟”110a具有三个子组件：“控制”120a、“图形”130a以及“连接器”160a。组件“控制”120a具有：

-对时钟进行管理的第一子组件时钟“c1”121a。在该示例中，该时钟是默认配置的，用于每毫秒发射一次滴答(tick)。在本发明的其它实施例中，可以在时钟的子组件中定义发射滴答的频率；

-第二子组件增量寄存器“incr”122a，其在激活时使其子组件状态124a递增；

-第三组件乘法器“mult”123a，其在激活时将其左子组件125a与其右子组件126a(其值总是“6”)相乘，进入其结果子组件127a中；

-第四组件连接器140a。在欧洲申请No.15305949.8中明确地公开了组件连接器的效果：其第一子组件141a指的是组件122a，而其第二子组件142a指的是组件125a。当其激活时，每当组件状态124a修改时，连接器将组件状态124a的值复制到左组件125a中；

-第五组件捆绑150a。在欧洲申请No.15305949.8中明确地公开了组件捆绑的效果：其第一子组件源151a指的是组件121a，而其第二组件152a指的是组件124a。当捆绑150a启动时，组件124a在每次时钟“c1”121a激活时激活。

组件“图形”130a具有三个子组件：圆圈“bkg”131a、具有一个子组件角度134a的旋转“r”132a，以及线“秒”133a。

第二组件连接器160a具有引用组件“mult”/结果127a的输入子组件161a，以及引用组件“r/角度”134a的输出子组件132a：当连接器160a激活时，“mult/结果”127a的值在每次“mult/结果”127a修改时复制到“r/角度”134a中。

因此，组件的行为如下：组件“图形”130a及其子组件定义组件“挂钟”110a的布局：其显示包括圆圈和秒针(由组件133a所画的线表示，具有角度由组件角度134a定义的旋转)的挂钟。每秒发生时钟的滴答，并且组件121a被激活。在捆绑150a激活时，每当组件121a激活，则组件122a被激活。因此，在每秒，组件增量寄存器“incr”122a被激活，并且其状态124a递增。递增组件124a的状态使得组件124a激活。当连接器140a激活时，每次激活时其值被复制到左组件125a中，这进而活组件125a及其父组件乘法器123a。组件123a的激活将左组件的值与右组件的值(其总是6)相乘，进入结果组件127a中。这激活组件127a。当连接器160a激活时，结果127a的值复制到角度组件134a中。这激活角度组件134a，其进而通过转动秒针来更新应用的布局。

因此，包括控制组件(如捆绑和连接器)的组件的组合使得针的角度每秒更新。由于时钟每分钟滴答60次数，并且将复制到角度值中的结果乘以6，因此，针将每分钟转动360°。在本发明的多个实施例中，在激活组件时，以取决于子组件位置的预定顺序来激活所有子组件。例如，可以以深度优先的搜索算法定义的顺序来相继地激活子组件。图形组件的激活可以触发其可视化。

本发明的目标之一是能够展示组件的属性的集合。在该示例中，属性可以是：秒针总是可见，秒针每秒更新，以及其60秒转一整圈。

在本发明的多个实施例中，树100a是由对XML文件进行解析的解释器创建的，例如，其可包括以下XML语句：

每个组件和子组件由XML标记定义，组件的类型由标记的类型定义，并且组件的特性用标记的特性的值来初始化。树的结构直接从标记的结构得出。例如，根节点“挂钟”将创建组件110a，并且其三个子节点“控制”、“图形”和连接器将分别被解析用于创建子组件120a、130a和160a。可以用标准类“组件”、或者如果类的名称是解释器已知的则可用更专门的组件类(如连接器组件)来初始化这些组件。

在本发明的其它实施例中，可以通过在支持Djnn函数和库的执行环境中执行代码语句来创建树100a。

例如，以下Java代码语句可用于在具有Djnn库的Java环境中创建树100a：

“new”关键字用于创建组件或子组件。当创建子组件时，其父组件作为Java类的构造函数的第一个自变量提供。向构造函数提供用于初始化组件和子组件的特性的值的其它参数。

本发明公开了用于定义包括子组件树的组件的属性的方法以及用于验证所述属性的方法。这些方法中的每种方法依赖于创建包括树的子组件的有向图。可以针对组件树中的每个组件来定义属性，从而允许在各个级别的细节处定义属性，同时以接近用于定义组件的语言的语言来表达所述属性。

图1b显示了由本发明的实施例中的方法创建的有向图的示例，所述有向图是根据树100a构建的。

有向图100b包括树100a的组件和子组件110a、120a、121a、122a、123a、124a、125a、126a、127a、130a、131a、132a、133a、134a、140a、141a、142a、150a、151a、152a、160a、161a和162a。在本发明的其它实施例中，由根据本发明的方法创建的有向图仅包括该树的子组件的子集。例如，其可以包括除了控制结构子组件140a、150a和160a以外的所有子组件。

有向图100b包括多个弧。这些弧中的一些(例如弧120b、150b、160b)与组件和子组件之间的子关系相对应。其它弧代表耦合。例如，弧153b是根据捆绑150a创建的，弧143b是根据连接器140a创建的，而弧163b是根据连接器160a创建的。

在本发明的多个实施例中，图的弧因此包括树的所有弧；图的弧还包括：对通过捆绑创建的耦合建模的弧(当捆绑是在组件S到组件A之间定义的，则弧添加到S和A之间的图)。要考虑的捆绑可以是复杂组件的子组件。在输入和输出子组件之间的连接器的情况下，添加从输入到输出子组件的弧。在包含名为S的状态子组件与名为D的状态子组件之间的一个转换、并且由名为I的输入子组件激活的FSM的情况下，添加从子组件I到FSM的状态子组件S的弧。在存在额外的转换的情况下，类似地添加额外的链路。

图1c显示树100a的初始化处的挂钟的布局。

时钟110c显示在包括垂直轴101c和水平轴102c的应用的参考框架中。参考框架的原点位于应用或屏幕的左上角。挂钟110c由圆圈131c和表示秒针的直线133c来表示，它们分别对应于子组件131a和133a。

圆圈131c用半径100和参考框架中的坐标(250,250)来初始化。例如，该值可以通过对XML文件中的标记<circle name＝"bkg"cx＝"250"cy＝"250"r＝"100"/>进行解析，或者通过执行Java代码的该语句new Circle(graphics,"bkg",250,250,100)；创建圆圈对象来获得。

指针133c初始化在坐标分别为(250,250)和(250,150)的两点之间。例如，这些值可以通过对XML文件中的标记<line name＝"sec"x1＝"250"y1＝"250"x2＝"250"y2＝"150"/>进行解析，或者执行Java代码的该语句new Line(graphics,"seconds",250,250,250,150)；来获得。

现在假设读者熟悉使用XML文件或Java代码来创建组件树的方法，以及根据组件树来创建有向图的方法。下面的图片将直接显示本发明的多个实施例中用于验证属性的有向图，并且将参考这些图来解释定义和验证属性的方式。

图2显示了本发明的多个实施例中的用于定义交互式组件的属性的方法。

方法200适用于交互式组件，所述交互式组件被表示为子组件树。所述子组件树包括定义第一子组件与第二子组件之间的耦合的控制结构子组件，所述第二子组件是在所述第一子组件激活时被激活的。例如，该方法适用于组件100a，或者更一般地，适用于由申请人在同一天提交的欧洲申请No.15305949.8中公开的任何交互式组件。

方法200包括以下步骤210：创建表示交互式组件的有向图，该有向图的节点包括第一子组件和第二子组件。用于创建有向图的方法的示例明确地包括：创建交互式组件与所述组件的子组件之间的第一弧；以及创建第一子组件与第二子组件之间的第二弧，并且针对创建有向图100b，参考图1描述了所述方法的示例。

该方法还包括获得表示属性的第二图的步骤220。

获得所述第二图可通过从与不同属性相关联的原型图的库中检索图来执行。还可以创建第二图用于验证属性。在本发明的其它实施例中，可通过调整表示某种类型的属性的原型图来获得所述第二图。在本发明的多个实施例中，第二图也是有向图。

第二图的构造依赖于要定义的属性。例如，可创建图不变量用于提供组件的静态接口。当不同开发者并行构建或发展交互式组件然后对其进行组合时，这是需要的。该验证确保组件提供之前在其说明中定义的静态接口。

组件的静态接口被称为签名。组件的签名是由其子组件的集合定义的。例如，小部件的签名可由2个子组件组成：宽和高。矩形的签名由下列各项组成：位置子组件(包括子子组件X和Y)、尺寸子组件(包括子子组件宽和高)、圆角尺寸子组件(包括水平和垂直尺寸)、鼠标按下事件子组件(包括子子组件位置X和Y)、鼠标释放事件子组件、鼠标移动事件子组件(包括子子组件X和Y)、鼠标输入事件子组件和鼠标离开事件子组件。

与组件的静态接口相关的属性可以变换成第二图。在这种情况下，图不变量由根组件及其包括接口的子组件组成。

所述第二图也可用于定义相对于应用的正确形成的属性。

有可能通过定义应该由以正确方式组装的子组件编译的规则的子集来定义应用的良好形成。

良好形成的规则的示例是：捆绑(属性1)涉及所定义的源和动作子组件，开关(属性2)包含至少一个子组件，FSM(属性3)包含状态和转换以便至少一个转换允许到达某个状态。

例如，属性1可转换成由组件源和组件动作以及从组件动作到组件源的弧组成的第二图。

第二图的其它示例与2个组件之间的控制流连接的存在有关。当不同开发者并行构建或发展交互式组件然后对其进行组合时，这是需要的。可以通过定义从组件A到组件S的路径来定义这样的不变量。

方法200还包括用于验证第二图在第一有向图中的存在和缺失中的一个的步骤230。

由第二图的存在验证的属性的示例包括关于组件的布局的属性。例如，包括矩形和在其左边的不透明组件的第二图的存在可用于证明不透明矩形存在于组件中。它们还包括针对交互式组件的正确形成的属性。例如，证明正确形成的FSM可由表示格式良好的FSM存在于第一有向图内的第二图证明。

由第二图的缺失验证的属性的示例包括例如关于组件的布局的属性。例如，包括矩形和其右侧的图形组件的第二图的缺失足以证明矩形不被另一个组件掩盖。

第二图的存在或缺失还可以有条件地基于所述第二图的节点的特性值来定义。例如，即使第二图包括矩形及其右侧的第二组件，如果所述第二组件的边界不与矩形的边界重叠，那么也可以执行证明矩形不被另一个组件掩盖。这可以通过将关于第二组件的尺寸和位置的特性与关于矩形的尺寸和位置的参数进行比较来验证。

在本发明的多个实施例中，还可关于交互式组件的执行的上下文来测试特性的值。例如，可使用将在其上以参数显示组件的屏幕的分辨率来验证关于组件的布局的属性的验证。

在本发明的其它实施例中，由组件之间的耦合创建的弧的使用不仅允许验证参数的立即值，而且允许验证这些值是否受到改变。例如，当验证矩形的不透明度时，表示针对不透明度的值的耦合的弧的缺失足以证明无论执行的上下文和输入如何，该值将不会改变。

在本发明的多个实施例中，在交互式组件或应用的开发期间执行方法200，以便定义之后将验证的精确属性，例如，在非回归测试中或者用于在开发小组中传输说明。例如，图形不变量可由用户定义或自动定义。

在本发明的其它实施例中，方法200可在组件或应用的执行的会话期间执行。例如，可自动定义的不变量(例如，关于应用的正确形成的不变量)的情况就是如此。

在本发明的多个实施例中，可以通过验证多个子属性来验证某个属性。例如，可以通过证明以下子属性来证明声明矩形总是可见的属性：

A)矩形存在，并且在其左侧存在具有不透明度的值高于0.5的不透明度

组件；

B)矩形存在，并且在其右侧没有组件与之重叠。

子属性还可与以该属性为特征的不同元件有关。例如，为了证明时钟包括分别表示小时、分钟、秒的三个指针，有可能验证：

-时钟包括表示小时的指针；

-时钟包括表示分钟的指针；

-时钟包括表示秒的指针；

即使三个指针不是作为相同组件的子组件的兄弟组件(例如，如果时钟由若干部件组成，并且时针、分针和秒针分别在时钟的不同部件中)，这也可以被验证。因此，该方法优选地允许证实交互式组件的抽象属性。

在本发明的多个实施例中，该方法应用于用具有组件树和代表耦合的组件的交互式应用结构的语言编写的软件。Djnn框架是允许以这种形式来编写程序的框架的示例。因此，获得组件树是直接的任务。

在本发明的其它实施例中，软件是用本身并不表达递归组件和交互的语言编写的。在这样的实施例中，方法200包括预先步骤210，其是创建包括至少一个定义两个组件之间的耦合的组件的组件树的预备步骤。所述预备步骤包括：将本身并不被表达为组件和交互的软件或应用建模成与欧洲申请No.15305949.8中公开的那些类似的交互式组件。这些实施例优选地允许对大量语言和软件使用由本申请公开的属性验证的可能性。在预备步骤中用于将软件或应用建模成组件树的方法依赖于所述软件或应用的特征，例如，它们的编写语言。

在本发明的多个实施例中，该方法用于证明应用开发期间的非回归。

在本发明的其它实施例中，该方法用于确认软件的说明。

在本发明的其它实施例中，该方法用于验证：属性是在执行该应用的上下文中验证的。

图3显示了本发明的多个实施例中的交互式组件树的子部分。

在一些情况下，在组件树中确定被另一个组件影响的组件的子集是有用的。例如，由颜色组件影响的组件的集合由其上应用由颜色组件定义的颜色的组件组成。

我们把定义要应用于其它组件的属性的组件称为“源组件”。我们把属性被应用到其上的组件的子集称为“受影响组件”。

受影响组件的集合由树300中的作为在源组件及其后代的之后的兄弟(弟)组件的组件组成，直到另一个类似的源组件被定义。

在图3中，标记为C12的组件320是源组件。在该示例中，组件320是定义所有受影响组件的颜色的颜色组件。受影响组件是组件320的之后兄弟组件：标记为C13的组件330以及标记为C14的组件340；及其后代：组件330的后代是分别标记为C131、C132和C133的组件331、332和333；组件340的后代是分别标记为C141和C142的组件341和342。

在图3中，受组件320影响的组件的集合是组件集合350。该示例展示了在本发明的多个实施例中，组件如何仅应用于树的组件的子集。因此，其上被应用诸如颜色这样的效果的组件部分依赖于组件的相对位置。因此，在本发明的大量的实施例中，一些属性是根据组件的相对位置来校验的。

图4a和4b分别显示了根据包括不透明度增加的矩形的组件树创建的有向图，以及可由根据本发明的方法在该图上验证的一些属性。

图4a显示了根据包括不透明度增加的矩形的组件树创建的有向图。

例如，组件树是通过对以下XML文件进行解析来创建的：

其包括：

-根组件410a；

-时钟420a，其每100ms滴答一次；

-增量组件430a，其每当激活时递增其状态431a；

-公式组件440a，每当激活时，该组件向其结果子组件442a分配等于1-i/100的值，i是由其子组件441a的特性定义的；

-四个图形组件：

-框架450a；

-颜色组件460a，其颜色是由RGB值(30,10,200)定义的。该颜色应用于所有是颜色组件及其后代之后的兄弟(弟)组件的图形组件，直到另一个颜色组件被定义。(图3)

-不透明度组件470a，其不透明度是由其子组件“a”471a的值(初始化为0.81)定义的；值为1表示完全不透明，而值为0表示完全透明。该不透明度应用于所有是颜色组件及其后代之后的兄弟(弟)组件的图形组件，直到另一个不透明度组件被定义。(图3)

-矩形480a；

在本发明的多个实施例中，当显示组件树时，组件从左至右，以深度优先顺序遍历，并且组件的特征可应用于其右侧的兄弟组件。在该示例中，矩形480a将具有由组件460a定义的颜色以及由组件470a定义的不透明度。

有向图400a包括所有这些组件。此外，其包括由树中的组件与子组件的父-子关系创建的弧，例如，弧490a。在本发明的多个实施例中，弧是针对树中的每个父-子关系创建的，并且方向是从父到子。

此外，有向图包括根据控制结构组件创建的弧，这些弧代表组件之间的耦合。例如，从子组件420a到子组件430a的边491a是根据捆绑创建的，而从子组件431a到子组件441a的边492a，以及从子组件442a到子组件471a的边493a二者都是根据连接器创建的。

组件的行为如下：每当时钟420a滴答时，由弧491a表示的捆绑激活增量器430a，其递增状态组件431a。这激活子组件431a。由弧492a表示的连接器将状态461a的值复制到子组件I 441a中。这激活子组件440a。公式应用于I 441a的值，并且结果分配给子组件结果442a。这激活子组件442a，并且由弧493a表示的连接器将结果的值复制到a中，a修改矩形的不透明度。

不透明度的值逐渐减小，因为其等于1-i/100，并且i每当时钟滴答时递增。因此，矩形逐渐消失。

图4b显示通过根据本发明的方法在该图上可验证的某些属性的范围。

例如，该验证可由本发明的多个实施例中的方法200执行。

在该示例中，将被验证的属性是：矩形总是可见的，在从0到1的标度范围上，具有大于0.5的不透明度。

根据本发明的多个实施例中的方法，该属性分解成若干子属性的结合。对该属性进行验证包括：对子属性的结合进行验证。

在该示例中，子属性是：1/矩形的存在；2/没有图形形状掩盖矩形；3/适用于矩形的不透明度大于0.5；4/不透明度组件的值不受改变。

根据本发明的多个实施例中的方法，属性1/转换成表示所述属性1/的图，并且然后针对组件的图来校验该图。

属性1/的图是由唯一组件：矩形组成的图。针对组件的图来校验属性1/的图包括：验证不变量图是组件的图的子图(通过这种方式来校验矩形的存在)。

可以定义第二条件402b：没有图形形状掩盖矩形。如果绘制子组件是从左至右执行的，那么这包括：验证没有矩形存在于矩形480a的右侧。由有向图400a验证该属性。然而，在包括位于矩形480a的右侧的矩形480b的有向图400b中，这将不会得到验证。然而在本发明的多个实施例中，如果矩形480b不与矩形480a重叠，则可以满足该条件。表示该第二属性的图由图形形状组件组成，并且属性是通过校验属性2/的图是否是矩形的兄弟子图之后的子图来验证的。

可以定义第三条件403b：适用于矩形的不透明度大于0.5。该条件由有向图400b满足。该第三属性的图包括唯一的组件不透明度。通过在图中搜索具有大于或等于0.5的不透明度值的该组件，并且验证矩形组件是其之后的兄弟子组件中的一个，来对其进行验证。

可以定义第四条件404b：不透明度的值不受改变。在图400a中，该条件没有被满足，因为连接器404b修改了不透明度的值。属性4/的图由不透明度和时钟组件、以及时钟组件和不透明度组件之间的弧组成。该验证包括：校验该不变图是否是图的传递闭包的子图。

已经关于软件组件描述了图4a和4b。然而，如上面所说明的那样，完全相同的属性验证的原理适用于其它类型的组件。例如，可能的是可以将“时钟”组件420a替换成表示人的一系列动作的组件，并且保持与“增量”组件430a的捆绑491a。因此，每次人提供对交互式软件的输入时(例如，每次用户点击按钮时)，“增量”组件430a将被激活。相似地，这适用于规程，每次用户被要求点击按钮时，组件430a被激活。

本实施例有利地使得能够验证在与用户进行规定的交互时是否某些属性得到验证。在该例子中，例如可以以与软件组件非常相似的方式验证矩形总是可见的，在范围为0至1的尺度上具有大于0.5的不透明度。

该实施例还可以用于验证人与交互式软件之间的更复杂的交互。例如，可以定义表示规程的组件(诸如“当警报响起，按下红色按钮”)或可能的行为(诸如“如果并未处在无意识失聪(inattentional deafness)状态下，当警报响起时用户将按下红色按钮”)。通过警报的激活与按钮的激活之间的捆绑，或通过更复杂的状态机可以表达这种行为。因此，如果与软件交互的人类操作者具有符合规程的行为或可能的被表示为组件的行为，则可以验证完整的交互。

该实施例有利地使得能够验证用户与交互式软件之间的复杂交互的属性。例如，其可以用于验证交互式软件符合交互的规范，或规程与软件系统和期望的行为二者都一致。

本实施例还可以用于验证人与除了软件以外的其它对象的物理和信息交互，例如，当使用文档、信号灯、等待队列等等设计组织和规程时。在将这些人、组织、规程和产品的行为表示为组件之后，可以应用相同类型的属性验证。

本实施例还可以用于将人、规程和组织的行为的组件表征与监控该行为的属性集合一起存储在交互式软件中，以使得在检测到改变所监控的属性的这些组件的给定子组件的激活和停用时，交互式软件可以相应地调整其自身的行为。例如，这是通过在软件中将所述属性表示为组件以及通过将动作捆绑至组件的改变而获得的。

本发明的应用的示例

本发明可由各个操作者用于各种系统工程过程。

作为示例，本发明可在交互式组件的独立开发期间使用：开发人员在其组件的设计期间使用本发明作为用于对由所述组件实现的属性的验证的方法。可在所述组件的设计期间的任何时刻来定义属性，包括：在设计之前、在设计期间、当要确定额外的要求时、或者当正在调试组件，并且错误追溯到没有实现并必须使其明确以避免回归的隐含要求时。

使用本发明的另一种方法是在之前开发的组件的集成期间。集成人员可定义和校验他们希望作为他们自己的组件的子组件进行重用的组件的额外属性，尤其是当所述属性对于他们自己的组件正确工作至关重要时。一旦针对其定义了属性，集成人员还可以决定用另一个子组件来替换某个子组件，并校验新的子组件也持有这些属性。

这两种之前的方法可在以定义和产生交互式软件为目标的开发环境中成组。软件产品的说明、开发和确认的各个操作者在他们的工作产生在其中所有定义的属性均被实现的软件产品的集体目标下，可并行生产组件和组件属性的集合。开发环境可以通过持续监测组件的变化以及重新校验属性来保持尚未实现的属性的列表。

本发明还可用于支持认证过程的一部分。例如，根据题为“SOFTWARECONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICATION”的ISO标准DO178中的语言，本发明可用于提供“系统是完整的并且对于其要求来说是正确的的证据”，以及支持“对哪些代码、软件要求或软件架构满足下一个更高级别的软件要求的确定”。

或者，本发明可用于规范和获取过程。公司可迭代地创建软件原型作为软件组件的集合，所述原型被指定为捕捉其要求。然后可以制定组成所述原型的大量的软件组件的属性，并向期望从其获得原型的工业版本的第三方供应商传送所得到的属性的集合。当软件供应商传送所得到的产品时，公司可以校验属性的实现。这确保外部源的优势和规范的优势二者都存在于最终的产品中。

或者，本发明可用于交互式软件的编译器，其中，所述交互式软件是用实现本发明中使用的交互式组件模型的语言编写的。编译器可以校验组件的属性，并且当属性没有实现时发出错误。

或者，本发明可在专用于单元测试的工具中使用，其中，组件属性的定义将是向单元测试的程序员提供的语言的子集。所述单元测试因此可将执行环境的仿真与属性的校验进行组合。

使用本发明的另一种方式是通过将在其中指定要使用软件组件的环境的全部或部分建模成交互式组件的集合，然后将所述模型与所述软件组件组合成更大的组件，然后定义并校验所述更大的组件的属性来使用本发明。例如，这允许通过对任务或活动进行建模来校验软件组件适合于所述任务或用户活动。同一种方法还可用于校验软件组件与硬件平台的兼容性。

本发明的另一种用途是用于定义其中必须使用软件组件的环境的属性，以存档所述软件组件的重用条件。例如，有可能在某个属性中声明图形按钮必须在至少一个指针可用的环境中使用。所述图形按钮的工程师或用户然后可获得他们希望在其中重用所述按钮的计算机和操作系统的模型，并校验计算机和操作系统的所述模型是否持有该属性。

本发明的另一种用途是在用于执行交互式组件的运行时间软件执行系统中。例如，当从文件加载组件时，或从网络连接接收组件时，或者当基于对硬件设备或执行上下文的其它元件的检测来创建组件时，所述执行系统可动态校验其从其环境接收的组件的属性。此外，所述执行系统可提供允许程序员定义属性和定义要对动态创建的组件执行的动作的应用编程接口(API)。这允许程序员在其软件中创建自动适应机制。

通过本发明的应用，可定义属性的存储库。例如，开发环境的供应商可以提出认为组件要正确执行所必需的属性的集合，并建议程序员校验他们的组件的所述属性。可针对具体类别的组件或具体的应用域来定义更加具体的属性。例如，民航部门的监管机构可定义以下面向交互的属性：必须具备特定的互动飞机驾驶舱设备以便用于运送乘客。存储库还可以提供用于根据这些判断标准来对属性进行搜索、分类、编辑和修改的单元。

或者，组件属性可用作用于对组件存储库中的交互式组件建立索引和进行检索的方法。所述存储库可针对由供应商上载的任何组件来校验属性的存储库的内容，用所述组件持有的所有那些属性来为其建立索引，以及然后允许用户通过选择所期望的属性来检索组件，或者根据可用属性来导航(navigate)其内容。

还可以在需要定义新的交互时或在识别到新的要求时，后续添加要验证的属性。尤其可以是当某些组件表示人类行为的情况。在该情况中，可能在初期开发软件时难以预想所有要验证的属性，因此可以倾向于基于交互式软件的用户的反馈来添加与用户和交互式软件之间的交互有关的属性。可以随后后续添加要验证的交互式属性，本发明的方法可被用于在软件的用户执行了期望的行为的情况下，在交互式软件的每个版本处验证该版本验证了所有的属性。

相同的原理可用于针对规范校验交互式软件。故本发明提供了强有力的工具来验证后续版本的交互式软件符合关于用户与软件之间的交互的后续版本的规范。

相同的原理可被用于校验被针对后续版本的交互式软件的使用定义的后续版本的规程，该规程具有后续版本的要求或规范。

相同的原理可被用于通过将表示软件和硬件的组件替换成表示组织和规程的组件，并且校验这些属性或这些组件与人类行为一起构成的系统的属性，来针对后续版本的要求和规范来校验后续版本的规程和组织。

上述示例是作为本发明的实施例的说明给出的。它们不以任何方式限制由所附权利要求书定义的本发明的范围。