组件功能外属性的定义及其在软件构件中的应用

理论计算机科学电子笔记264（2010）55-71www.elsevier.com/locate/entcs一种与上下文无关的函数外属性描述符组分1卡米尔·杰·泽克·普·布拉达{谢泽克|brada}@ kiv.zcu.cz西波希米亚大学计算机科学与工程系比尔森彼得·斯维特·谢潘stepanp@cs.man.ac.uk曼彻斯特大学计算机科学学院Manchester M139PL，英国摘要基于从预先存在的组件组合目标应用程序功能的体系结构已成功地用于许多项目中，但在几个方面，它们未能达到理想的成熟度水平。由于不同的供应商可能提供具有相同功能的组件，因此必须考虑额外的功能属性，以帮助开发人员选择适合最终系统的组件。此外，所选组件必须符合目标部署环境。本文解决了不充分的手段来定义组件的额外功能属性的方式，允许表达组件的属性相对于不同的计算环境的问题。我们提供了一个有代表性的调查，目前的最先进的额外的功能特性，并提出了一个形式主义的基础上，现有的方法，解决这一不足。我们的形式主义还允许我们使用额外的功能属性来描述组件和部署环境之间的依赖关系，称为部署合同。我们的方法使用了一个系统的注册表，具有一致的解释的额外功能的属性上发现的任何给定的组件，无论其使用上下文和分离的语义和语法的每个属性的优势。关键词：软件构件，功能外属性，非功能属性，组合，规范，注册表，部署契约1这项工作得到了捷克共和国资助机构的支持，资助号为201/08/0266“先 进 组 件 应 用 程 序一 致 性 验 证 的 方 法和 模 型 ”。1571-0661© 2010 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2010.07.00556K. Ježek等人理论计算机科学电子笔记264（2010）551介绍如今，有竞争力的软件公司需要在更短的时间内以更低的价格交付软件。相反，软件产品的规模和复杂性稳步增加。已经定义了许多管理这些方面的技术。今天的软件通常是软件库和新编写的代码的组合。较新的技术--基于组件的编程--从一组组件组成最终产品，这样很少的代码（除了创建新的组件）需要编写。虽然这些技术允许快速的软件开发，但仍然存在一些障碍（见1.1），阻止我们充分受益于它们。最终基于组件的产品必须在功能和额外功能特性2（简称EFP）方面达到特定要求。这些特性包括可靠性、可维护性、可用性、安全性、可移植性、可重用性等。因此，组件需要提供额外的功能属性来保存这些附加信息。开发人员使用这些属性来检查哪个组件最适合最终产品。1.1论文的目标正如我们所定义的，功能外属性是一种特殊的信息，表达了一个软件所提供的和所需要的质量已经提出了许多定义和检查EFP的方法[20]，[15]包括用于描述EFP的语言[6]，[1]。其中一个探索较少的问题是如何针对特定域和上下文3（例如移动电话，台式计算机，服务器）的EFP。有些特征在一种情况下很重要，但在另一种情况下却不那么相关，而且相似的EFP的具体值通常是不同的。 由于这个原因，EFP现在主要用于一种情况下，没有任何可能在另一种情况下重复使用。短信了例如，实时（R-T）应用程序的上下文通常成功地使用EFP（例如响应时间），但这些属性并不能简单地移植到桌面应用程序。这显然与基于组件的编程目标不一致，在基于组件的编程目标中，组件的目的是独立于上下文。 在这项工作中，我们的目标是引入一种方法来定义额外的功能属性，这些属性可以在与域相关的不同上下文中可靠且一致地解释。此外，我们提供了一种可能性来表达一个组件的关系，其环境 所提出的工作的主要技术贡献是登记册系统，该系统存储一组相关的EFP并将特定的值绑定到它们。本文中引入的属性、部署契约和注册表的定义被表示为精确的数学模型。虽然一个实际的2通常也被称为非功能性质或特征。3“上下文 ”是指特定的计 算环境-具有特定的硬 件、软件、性 能或用户舒适度需求 。K. Ježek等人理论计算机科学电子笔记264（2010）5557∧ ∨ ≤ ≥¬建议的使用还需要开发足够的技术手段，本文的目标是建立其基本模型，而不是建议一种具体的技术。 本文中给出的定义旨在简单易用的模型 和抽象，这将相应地增加工业采用的机会本文的组织结构如下。下一节简要概述了与额外功能特性相关的技术和研究方法。第3节描述了我们工作的一般原则，它展示了我们如何定义EFP及其与部署契约的关系，包括我们引入的修改现有的方法。然后是关于我们的注册表系统的详细信息。本文的最后一部分提供了一个案例研究，在其中我们展示了如何使用我们提出的方法，可以提高目前的系统开发的捷克公司。2相关工作本节包含有关处理基于组件的编程和额外功能属性的方法的信息。2.1定义超函数性质的语言描述一般EFP的方法之一是NoFun [6]。它区分简单的属性，很容易测量（时间，内存，速度，...）以及使用逻辑表达式（、><、、=、...）从简单或导出的性质计算的导出性质。NoFun方法缺乏分配给属性和值的语义。人们可以为属性赋值并组成派生属性，但是一旦定义了值，它们就被固定了。与上下文和域的相关性没有得到解决。Aagedal提出的一种新方法是CQML [1]语言。他描述了EFP语言的完整语法，并为质量属性引入了UML概要。 CQML方法是一种可用于EFP一般描述的语言。该语言定义了以下基本类型：Number，Enum或Set;没有提供复杂类型。CQML也提供了派生属性，但它们只是为了扩展现有的简单属性或从其他属性组合派生属性，而没有进一步定义如何处理这种组合。 CQML允许在组件部署之前和部署之后处理属性。虽然属性通常在不同的阶段被不同地处理，但CQML并不区分它。CQML为组件分配一个profile。 配置文件包含一组具有一组QoS属性的质量。 质量允许封装上下文相关值，但假设我们有c个上下文和n个QoS属性，它可能会产生多达2n个质量记录和22n个不同的配置文件。此外，每个配置文件都必须为C上下文创建。这可能会导致难以管理的记录数量。CQML已被其他作者扩展。由R？ottger和Zschaler提出的一种扩展语言称为CQML +[14]。它们都明确定义了组件所需的资源他们不仅考虑资源，58K. Ježek等人理论计算机科学电子笔记264（2010）55组件之间的资源也是组件和系统（框架或硬件）之间的资源。这是基于组件的开发的一个重要方面，其中组件不仅与其他组件有关系，而且与部署环境有关系。CQML+扩展了原始CQML的语法，而不是提供一种更通用的方法。还有另一组针对特定领域的语言。其中，TADL [11]是一种专门用于可信系统的语言，其中可用性，可靠性，安全性和安全性被选为最重要的EFP。 该语言包含描述这四个特征的明确结构。另一个是HQML [7]，它是一种基于XML的语言，专门用于具有服务质量（QoS）功能的Web应用程序。另一种语言叫俚语[8]面向EFP也发挥作用的服务水平协议领域 一个重要的角色俚语使用XML来描述EFP。它区分了垂直SLA和水平SLA。垂直SLA涉及不同的基础设施，水平SLA涉及不同的抽象层。每个抽象层覆盖不同的EFP组，允许将不同的EFP用于不同的抽象层。这些方法的缺点是它们针对特定情况并开发有限的属性集相反，我们的目标是提供一个通用的解决方案。2.2组件的功能外属性一种利用结构化属性在构件模型中集成EFP的方法在[15]中提出并在ProCom组件模型中实现。ProCom 数据部分包含属性类型注册表中属性定义中指定类型的测量EFP的实际值。元数据部分用于区分特定的属性值及其描述（例如值的来源）。 有效性条件指定属性值在哪些上下文中在平台、使用配置文件或属性间依赖性方面有效。所提出的属性结构可能导致复杂的EFP描述，如果没有广泛的工具支持，这些描述很难管理。作者试图通过引入一种语言来解决这些问题，该语言用于根据当前配置定义哪些值是有效的（所谓的配置过滤器）。 这使得整个系统更加复杂。此外，虽然ProCom属性旨在在整个系统生命周期中使用，这促使引入多值属性，但我们对描述最终黑盒组件的EFP感兴趣。 ProCom中最有趣的想法是使用注册表存储EFP。引入注册中心的主要原因是收集属性类型。V. Ukis提出的部署契约[9]专注于检测组件之间或组件及其执行环境之间可能的冲突。部署契约（DC）定义了一组全面的元数据，描述了（i）组件的环境依赖性和（ii）组件的线程模型。K. Ježek等人理论计算机科学电子笔记264（2010）5559（i）的描述包括组件需要哪些资源以及如何访问它们（例如，对文件的读写独占访问或只读共享访问）。（ii）的描述包括关于线程问题和并发性的组件的各个方面（例如，组件是否产生线程，或者组件是否假定在单个线程中执行）。这些元数据具有参数化属性的形式，可以附加到组件、组件的方法、方法的参数或返回值。 在DC的原型中，元数据被实现为.NET注释。在组件部署阶段，根据执行环境的规范检查组件的DC，以防止可能的运行时冲突。DC可以被认为是某种EFP。 与我们的方法相比，该方法并无对DCs的基本正式定义，亦无指定应如何比较，这是由于整体专注于预防冲突，而非如我们的情况般选择最合适的候选成分。 我们我们的目标是在我们的工作中使用DC属性，但我们为它们创建了一个通用的形式主义与我们的EFP一致PECT [19]专注于实时质量属性及其预测。ROBO- COP4使用了一组各种模型，其中包含有关系统的特定信息，包括EFP模型，即可靠性，CPU和内存使用率。然而，这两个模型都不允许EFP上下文无关的规范。例如，不可能用特定平台来参数化EFP与以前的模型不同，Palladio [3]允许EFP通过上下文进行参数化。组件开发人员可以使用称为资源需求服务执行规范（RDSES）的附加规范来注释组件的每个提供的服务（提供的接口之一的方法）。使用UML活动diagram来描述服务的简化控制流程，它可以表达服务对输入参数的依赖性和对抽象资源类型（存储在全局资源库中）的资源需求。在系统开发的进一步阶段，RDSES由资源模型参数化，该资源模型将抽象资源类型绑定到目标资源容器中的具体服务的资源需求，并且描述服务使用场景和预期工作量的使用模型。 最后，将所有模型组合在一起，可以用于组件与我们的方法相比，Palladio只关注与性能相关的EFP，它为这些EFP提供了丰富的模型。具体而言，EFP的值被定义为随机变量，并考虑到使用情况，这是一个强概念。另一方面，创建大量详细模型的必要性给系统和组件开发人员带来了沉重的负担。此外，必须以资源模型的形式创建资源平台规范因为资源库只包含资源类型，而不包含具有性能特征的特定实例。 在我们的方法中， 我们尝试从相似的上下文（包括硬件）中封装EFP的值4http://www.hitech-projects.com/euprojects/robocop/index.htm60K. Ježek等人理论计算机科学电子笔记264（2010）55在本地注册表中，它们可以被许多系统重用，但EFP定义在跨系统中仍然有效在面向服务的架构领域，服务质量（QoS）特性是一个重要的问题，[20]扩展了Web服务建模本体以更好地支持EFP，并提出了一种使用质量特性的服务比较方法。我们的工作遵循类似的目标，使用更传统的方法。在强有力的工业框架领域，对额外功能特性的支持相当罕见。EnterpriseJavaBeans [16]（EJB）组件模型使用几个预定义的属性，这些属性可以归类到这个领域：位置性（是否bean的服务可以远程访问或只能由本地客户端访问），状态（bean可以定义为无状态或状态完整），事务界定（定义预期的事务支持级别），安全性（涉及用户角色及其权限）。EJB没有提供定义新的或派生的EFP的机制。2.3质量建模由于建模技术与语言具有同样的重要性，因此有必要提及OMG组开发的UML Profilefor Modeling Quality of Service and Fault Tolerance[12] 。 它 提 供 了 一 个 扩 展 “ 标准”UML图的UML概要文件，可以添加额外的功能属性。不幸的是，这个轮廓与Aagedal在他的CQML中提出的轮廓不一致EFP的列表已经放在组件质量模型[2]中，该模型可以用于定义特定系统的EFP集合。一种不同的方法，性能树[17]，旨在对随机系统进行易于使用的图形表示，其中对状态，状态之间的转换和转换条件以及概率进行建模。它允许将性能查询表示为图形树，这对于性能要求高的系统的EFP建模是有用的2.4总结图1总结了我们对最新技术水平的调查。(i) 允许EFP的一般定义，（ii）处理组件的上下文和域依赖性，（iii）易于使用，以及（iv）允许表达依赖性，对其他组件和环境的影响。下表显示了当前的工作如何满足我们的需求，以及缺少哪些要求3我们的方法当系统开发人员有一组具有相同功能的组件时，他或她需要了解“更多”才能为特定目的选择最合适的组件。这个“更多”是分配给组件或其服务的额外功能属性。开发人员可以通过比较EFP来决定哪个组件更好（更合适）。5EJB模型中的组件K. Ježek等人理论计算机科学电子笔记264（2010）5561框架一般上下文 独立Easy-to-UseDCNoFun√√√√√√√√√√√√√√√CQMLQQ +ProcomUkisEJBTADL、HQML、Slang贝拉蒂Fig. 1. 现有作品从上面对相关工作的分析可以看出，对于功能外属性应该是什么样子，应该存储在哪里以及应该如何定义，并没有一致的理解。 在我们看来，EFP是关于组件及其功能的附加信息。他们的作用是提高组件规格并扩展组件验证的可能性本节描述了我们提出的定义和使用额外功能属性的系统，该系统支持它们的重用和可靠的比较。3.1一般原则为了获得可比较的属性，不同的组件供应商和用户之间必须对可用属性及其特性有共同的理解。除了使用CQM [2]等标准之外，这种理解还可以通过技术基础设施来帮助，该技术基础设施包括一个通用存储库，其中包含域（使用领域）中所有可用的属性。它允许假设属性在组件创建之前就已定义，因此供应商可以使用它将具有相同含义的属性附加到组件上。图二. 组件选择在图2中，假设供应商通过有效的EFP（62K. Ježek等人理论计算机科学电子笔记264（2010）55从存储库中获得，因此具有可比性）。 则比较并从中选出最佳组分请注意，在此过程中需要检查声明的EFP值是否有效的技术。它们可以包括任何类型的静态分析、模拟、测试等，然而，具体的技术超出了本文的范围3.2功能外财产登记处在我们的工作中，EFP存储库是由一个创新的注册表系统实现的。本文的这一部分提供了它们的描述，并解释了它们之间的关系 到组件。接下来的小节将对整个系统进行形式化图3.第三章。由上下文和域调整的注册表和组件的关系图3显示了我们系统的核心思想，展示了两个维度：一个关注上下文依赖性，另一个关注使用域。 通过上下文，我们指的是不同的计算环境（例如，移动电话，桌面机器，服务器的上下文），域是最终系统开发的区域（例如，图书馆、医院、学校、汽车工业的系统所有的注册表、组件和计算环境都以一个域（一个使用区域）为每个上下文也绑定到域。全局注册表（GR）是一个存储区，定义了EFP类型。GR包含具有每个属性的名称和类型的记录。它只定义了属性本身，但不包含它们的值。全局注册表对注册表域指定的所有上下文都有效。它包含由领域专家定义的所有有意义的EFP的定义。领域专家可以是一个程序，它使用一个领域规范，也可以是一个了解该领域的人地方登记处（LR）关注的是EFP的语境意义。 每个上下文都有一个本地注册表（具有到域GR的链接），它存储对上下文有效的值。它们与GR. A组件提供的定义相关联，该组件将在与LR相关联的特定上下文中部署。因此，它将上下文相关的值绑定到其属性（从GR获取）。K. Ježek等人理论计算机科学电子笔记264（2010）5563这种机制为值创建符号名称，由了解上下文的专家准备。EFP本身也可以在其他具有不同值的上下文中使用，因为值名称可以保持不变，而底层值可以更改。这种设计背后的基本原理是，一个EFP通常只为一个目的而定义，并且只在一个上下文中保持有效值。例如，对于“内存消耗”EFP，20 MB的值在桌面系统上被认为是“小”的，但在移动设备上被认为是“高”的。由于组件可以在非常不同的环境中使用，因此这种技术由于缺乏通用性而无法使用注意事项：部署合约显示组件对执行环境或框架的依赖性（例如，作为操作系统中的文件的资源，对硬件的访问，其他进程/二进制文件的执行）。登记册系统不区分功能外属性和部署合同属性。它们的定义是相同的，当它们用于组件时，它们是不同的。3.3将特性附着到构件一旦属性在类型（在全局注册表中）和命名值（对于给定的上下文）方面被定义，它们就可以用作特定组件的规范的一部分。我们假设使用所提出的方法的特定组件模型将允许将EFP单独分配给每个服务以及整个组件。组件因此，描述符能够处理EFP值的名称（如果为属性分配了名称）或直接值(if没有为属性指定名称EFP描述符包含两种EFP的声明--pro-vided和required。 提供的属性表示组件拥有的特性，由其开发人员确定。Required properties定义了组件的实现在组装/部署阶段和运行时所期望的特性。组件的服务通常包含提供的属性和需要的属性。整个组件只能向其他组件提供一些额外的功能属性。组件请注意，对于每个属性，在本地注册表中有一个记录是可选的。每个本质上不依赖于上下文的属性可以直接在组件描述符中赋值。它通常是每个部署合同或其他EFP（例如，物理值，如t=0oC，重力=6， 67或上下文无关的价格，适销性）。64K. Ježek等人理论计算机科学电子笔记264（2010）55defdef我...|∈}× →∈ {−}∈∪--4功能外属性和部署合同的形式化在我们的方法中，我们区分两种类型的额外的功能属性：简单的属性和派生的属性。一个简单的属性是任何可测量的属性，通常有一个测量单位。派生属性基于一组使用逻辑表达式的简单属性或派生属性我们将CQML模型用于简单属性，其类型为numeric、set和enum，但我们添加了一个字符串、一个比率类型和一个复杂类型。 复杂类型是简单类型或复杂类型的组合我们还推广了部署契约属性[9]，以与我们的（简单或派生）属性保持一致所提供的一般化定义了一个部署契约，其定义方式与额外功能属性相同，当它们在组件上使用时，它们会发生变化。绑定到组件的EFP严格地表达与其他组件的关系，而绑定到组件的DC严格地表达与运行时环境的关系，即使两者的定义没有不同。4.1EFP和部署合同4.1简单性质和导出性质（一）（二）（三）esimple=（n，γ，t，Meta）ederived=（n，E，γ，t，META）e部署合同e简单部署合同e派生其中，该公式的含义是：n是属性不T=T c是属性的类型T s是一组简单类型。 T s= real，integer，boolean，enum，set，ratio，string T c=（t1，，t N）N>1，t T是一组包含非原始值它聚合其他（简单或复杂）类型。其本质类似于C语言中的struct或Pascal中的recordγ：xyz; z1， 0， 1，是一个比较两个实例的函数属性类型t的x，y，说明两个值中哪个更好。 我们使用几个预定义的伽马函数，如增加（越多越好），减少（越少越好），并假设有可能定义新的伽马函数。返回值的含义是：-1：x比y差，0：x等于y，+1：x比y更好，该函数可以不被显式定义，然后以下隐式规则成立：（i）实数，整数，比率使用映射-1：x y，0：x=y，+1：x > y，(ii) string使用映射0：x字面上等于yelse当显式规则不存在且无法通过K. Ježek等人理论计算机科学电子笔记264（2010）5565--∈关于 我们隐式规则，得到值E={e1，···，eN}是构成导出性质的性质Meta是一个包含域引用的任何附加信息的记录。它的元素由一个可扩展模型描述，该模型当前包含项目单元、名称，其中unit：字符串是属性的度量单位names是一个有序枚举，包含允许在本地注册表中使用的请注意，所有Meta值都是可选的，仅在域中需要且有意义时4.2登记册形式主义本节提供了3.2节中提到的注册系统的形式化。定义4.2全局注册表是一个简单的属性定义列表（四） 其中：GR=（loc，{ei}）loc是注册表{ei}是一组（简单的或派生的）额外功能属性loc值由注册表部署位置隐式定义，不必显式提供定义4.3假设存在一个全局注册表GR，那么一个上下文的本地注册表包含定义上下文中有效值的记录因此，这为属性分配了语义。（五） 其中：LR=（loc，locgr，S，D）loc是将其与上下文关联的注册表的URIlocgr是指向全局注册表的链接S= si是定义简单属性的si=（name，value name，range）是属性名、值名和值的范围的元组name：String是GR中的属性的名称value name：String是值的指定名称，必须从GR中属性定义的Meta：：names部分中给出的可用名称列表中range是一个区间，一个集合或一个值T，它定义了对可用值的限制D=di：ri1，riK是一组派生属性定义，其中每个派生属性di由rij规则管理66K. Ježek等人理论计算机科学电子笔记264（2010）55⇒∈{−}×→∈∈di=（name）;从GR派生的属性名rij：F x;x=value nameorx=value Tenum是一个结果名称或枚举值，当逻辑表达式F被计算为true本地注册表包含对名称的赋值（集合S）和表示派生属性的派生的规则（集合D）。集合S的元素只是通过名称将值与简单属性相关联。集合D的元素也关联名称，但使用逻辑规则来表达派生属性的定义4.3性能比较两个组件C1和C2可以被标记为兼容，当（i）在提供侧的额外功能属性保证至少相同的质量水平，（ii）在需要侧的额外功能或部署合同属性声明需要相同或更低的质量水平，（iii）具有相同名称的属性匹配6。比较组件（通常是同一组件的两个版本或不同环境中的组件）的算法分为两个步骤。首先，它匹配提供的和必需的属性，比较它们的名称，然后检查是否在提供的一侧没有属性丢失，并且在必需的一侧没有添加其次，比较函数应用于所有等价属性。 利用序列EC（C1，C2）=（（xi，yi）k），xiefp（C1），yiEfp（C2），两个组件的命名属性，函数m：CC（zk），z k1，0，1，n/d通过计算函数γ（x，y）来比较分量 其由上面的公式1和2定义比较函数的非正式定义是：(6)m（C1，C2）：zk=γk（EC（C1，C2）k）算法对于提供的和必需的（部署契约或额外功能）属性是相同的。只有当每个zprov∈ {0， 1}为所提供的属性，每个zreq∈ {−1， 0}为所需的属性时，这两个组件才是兼容的。K K相同的函数m（C1，C2）还将一个组件的提供侧匹配到一个组件的提供侧。当要绑定互操作组件时，另一个组件需要的一方，反之亦然。DC比较要求运行时环境通过执行比较的属性来丰富。尽管这里没有显示环境的详细模型，但是将属性附加到环境的工作方式基本上与附加到组件的工作方式相同。该环境提供了一些属性，这些属性可以在组件部署合同中进行比较6请注意，我们这里只处理额外功能。当然，在版本、提供的服务和要求的服务等方面必须匹配。K. Ježek等人理论计算机科学电子笔记264（2010）55675案例研究和示例在本节中，我们将展示使用EFP和部署契约对现有系统的重新设计。这个案例研究解释了我们的解决方案如何在实际应用中使用，并展示了如何在注册表中设置具体值并在组件5.1问题说明捷克共和国内政部提供公民信息对于每个城市。 这些数据以从数据库导出的文本文件的形式提供列出个人地址数据的部门。数据被导入城市数据库。该系统如图4所示，它是一个复杂软件产品的一部分。有一个组件从文本文件中读取数据并将信息存储到数据库中。还有一个组件是地址数据库。它存储捷克共和国的所有地址，并可以通过网络服务提供这些地址。该部提供的关于公民的数据可能有错误。因此，有关地址的数据在导入过程中会同步，错误也会得到纠正。当地址的正确工作组件存在时，它必须始终提供有效的地址图四、公民信息导入系统我们定义了两个简单的属性，即数据传输和处理时间，它们涉及数据库导入的速度和传输数据量。这两个属性都由派生属性性能引用。 系统依赖于 在已安装的数据库引擎上，我们将其定义为部署合同，因为 它是一种外部资源。地址的假定正确性由数据正确属性表示。例5.1该系统的全局注册表包含额外功能属性的定义.该示例显示了与案例研究应用程序相关的GR的一部分。#简单属性data_transferred：递增整数{unitupdate_period：递减实数{unit：“Month”}#DC属性db_engine：complex {db：enum{Oracle，MSSQL，MySQL}，transactional： boolean}#派生属性性能：派生（data_transferred，time_to_process）枚举{sufficient，insufficient}例5.2在本地注册表中指定值的特定值的定义。注册表为名称分配特定值准备以下值68K. Ježek等人理论计算机科学电子笔记264（2010）55对于网址：http://services.kiv.zcu.cz/citizens/extrafunc/smaller/v1/处理时间：高=（500;+INFINITY）处理时间：平均=（100; 500]处理时间：低=（0; 100]###派生属性性能：充足=数据传输>=高AND时间处理<=低，不足=数据传输<=低或时间处理>高“大城市”上下文的LRURI：http://services.kiv.zcu.cz/citizens/extrafunc/big/v1/time_to_process：high=（100;+INFINITY）处理时间：平均值=（50; 100]处理时间：低=（0; 50]#.例5.3这些EFP然后被分配给组件描述符中的Citizens组件#注册表ExtraFunc-Catalog：http://services.kiv.zcu.cz/citizens/extrafunc/smaller/v1/# EFP对整个组件Bundle-ExtraFunc有效：性能=足够， update_period= 3.0Bundle-DeplContr：db_engine={db = Oracle，transactional= true}提供的服务：cz.zcu.kiv.services.DataReader; extrafunc=（数据传输=平均值，处理时间=低）加密-服务：cz.zcu.kiv.services.DataWriter; extrafunc=（time_to_process= high）加密-服务：cz.zcu.kiv.services.AddressSynch; extrafunc=（data_correct=true）最后一个例子展示了注册表如何允许将组件部署到不同的上下文中，而不会有误解其额外功能属性的危险处理EFP时间的符号名称“low“的解释在但是，只要组件引用相同的EFP注册表（除非其清单文件被篡改，否则该注册表将保持不变），其处理时间=低EFP声明将评估为相同的值，而不管其部署的环境如何这种方法的另一个优点是，应用程序设计人员可以抽象地推理服务和组件的EFP，特定于域，因此更容易处理术语-例如，实时系统的设计人员和桌面应用程序员都可以声明他们的系统需要连接到“平均或高”处理速度的服务。注册中心之间的链接确保这些符号名称背后的值在每个上下文中都是明确的，并且设计者总是能够获得隐藏在符号名称背后的精确值。K. Ježek等人理论计算机科学电子笔记264（2010）5569--5.2执行为了测试和研究的目的，我们扩展了CoSi组件框架[5]。这个框架受到OSGi [13]的启发，但CoSi在组件的可扩展性检查方面更加严格。 CoSi中的每个组件都被严格视为黑盒（按照Szyperski的书[ 18 ]中描述的规则我们能够通过它们的版本比较两个组件，以及检查提供的和需要的服务是否匹配，并决定它们是否兼容（有关框架功能的进一步描述，请参见[4]）。这项工作扩展了我们的框架，允许附加EFP的组件，后来比较它们。在我们的特殊情况下，CoSi框架将组件视为具有扩展清单文件的Java文件。清单文件包含有关组件的公共API的信息。它包括一个版本的组件，提供和要求的服务及其版本等。由于这构成了组件的规范，它适合于通过所需和所提供的EFP以及部署合同进行增强。CoSi中的属性可以分配给整个组件或仅分配给服务。部署契约总是附加到整个组件。 还包括到注册表6评价和进一步研究由于这项工作仍在进行中，有几个问题需要进一步研究。我们需要找到一个关于上下文注册表的实际位置的好的解决方案。 一种选择是将此信息存储为全局注册表的一部分文件，另一个是为每个上下文提供其他（物理上分离的）注册表，并将它们链接到全局文件。然而，登记制度引起了一组新的问题。一旦定义了价值观的名称，它们的感知就会随着时间而改变--被定义为快的东西可能在几年后会变慢。 注册表的版本系统将有所帮助 以使旧值无效并保持与旧组件的向后兼容性。所提出的模型仅适用于静态定义的属性值。 用户仅将属性与注册表中定义的值进行比较。在现实世界中，组件连接在一个组件链中，其中提供侧的属性可能会受到所需侧连接的属性的影响。同样的想法也适用于组件和运行时环境。我们的模型在这方面被简化了，因为它不考虑这种影响。 在我们未来的工作中，我们将引入描述属性如何被 连接组件（或运行时环境）的属性。目的是获得一个函数的规范：eprov=f（ereq），表示所提供属性受一组必需属性的影响本地注册表定义了上下文的值，但没有解决为其他或新上下文重新调整值的问题。 目前，每个本地注册表必须手动创建。我们想提供一个上下文模型，它与定义属性的函数一起，允许自动定义70K. Ježek等人理论计算机科学电子笔记264（2010）55其他背景。此外，如果组件我们已经用[10]中提出的原始算法形式化了部署合同属性，但我们想简化算法。我们只允许将属性放在组件和服务上，尽管原始工作允许这样做，即使是方法，参数和方法的返回类型。这不会造成问题，因为资源需求被移动到组件或服务，但它仍然存在。我们还假设不使用原始工作的每个属性，因为有些属性与部署的关系很弱（例如，方法的重入和状态），有些属性很难管理（例如，存储浏览器cookie的能力虽然本文已经为EFP和DC的静态定义开发了一个基本的数学模型，但允许实际使用该模型的技术手段尚未创建。我们目前正在开发一个工具，它使用XML来形成注册表和Java GUI，它作为注册表的编辑器。 我们的下一个目标是完成验证模型的工具7结论本文提出了一种针对可重用软件组件领域的额外功能属性和部署合同的定义方法。对现有方法的研究表明，早期开发的一些描述额外功能特性的语言是进一步开发的有用基础。我们提出的系统建立在CQML和NoFun的基础上，但简化了它们的语法，并在几个方向上进行了扩展，以更好地满足我们的需求。我们已进一步采用该方法，将现有的非正式定义的部署合同正式化。我们的研究的主要重点是允许解释额外的功能属性绑定到一个组件一致时，该组件被部署在各种环境或使用上下文。所提出的方法保留了价值的可测量尺度，即。他们的语义。我们提出了一个注册表系统，作为存储在注册表记录中的现有额外功能属性的存储库，该注册表记录定义每个计算环境的属性值，并为它们分配表示其含义的名称。核心思想已经在我们的实验框架CoSi中实现引用[1] Aagedal，J. J.，“分布式系统开发中的服务质量支持”，博士。论文，奥斯陆大学（2001年）。[2] 阿尔瓦罗，A.，E. S. de Almeida和S. L. Meira，软件组件质量模型：初步评估，在：EUROMICRO28比37[3] Becker，S.，H. Koziolek和R.Reussner，用于模型驱动性能预测的Palladio组件模型，系统与软件杂志82（2009），pp.3- 建模和分析。K. Ježek等人理论计算机科学电子笔记264（2010）5571[4] Brada，P.，CoSi组件模型，技术报告DCSE/TR-2008-07，西波希米亚大学计算机科学与工程系（2008年）。[5] Brada，P.，CoSi组件模型：恢复组件的黑盒性质，在：第11届基于组件的软件工程国际研讨会论文集，编号5282，LNCS（2008）。[6] Franch，X.，软件的非功能特性的系统化表述，在：国际需求工程会议（ICRE），1998年，pp. 174-181。[7] 顾 ， X. ， K. Nahrstedt ， W. Yuan ， 云 南 杜 父 花 D. Wichadakul 和 D. Xu ， An XML based Quality ofService Enabling Language for the Web，Journal of Visual Language and Computing，Special Issueon Multimedia Language for the Web13（2001），pp.61比95[8] Lamanna ， D. D 、 J. Skene 和 W. Emmerich ， Slang ： A Language for Defining Service LevelAgreements ， Future Trends of Distributed Computing Systems ， IEEE International Workshop（2003）.100块。[9] 刘 ， K.- K. 和 V.Ukis ， Defining and checking deployment contracts for software components ，Proc.9th Int.Symp. 基于代理的软件工程，LNCS 4063（2006），pp.1比16[10] 刘，K.- K.和V. Ukis，预印本系列cspp-37：部署合同分析的推理框架，曼彻斯特大学（2006年）。[11] 穆罕默德，M.和V.S. Alagar，TADL -一种用于可信的基于组件的系统的体系结构描述语言。ECSA290-297.[12] OMG ， UML profile for modeling quality of service and fault tolerance characteristics andmechanism specification，技术报告，OMG-对象管理组（2008）。[13] OSGi联盟，www.osgi.org/。[14] R？ottger，S. 和S. Zs chaler，CQML+：Enhan cementstoCQML，in：J.- M. Bruel ，editor，P roc.1st43比56[15] Sentilles ， S. ， P. Stepan ， J. Carlson 和 I. Crnkovic ， Integration of extra-functional properties incomponent models，12th International Symposium on Component Based Software Engineering（CBSE2009），LNCS 5582（2009）.[16] Sun Microsystems，EJB Core Contracts and Requirements，[17] Suto，T.，性能树：定量性能规范的新方法，在：在Proc.14th I