论文阅读笔记

Self-adaptive Software: Landscape and Research Challenges

 

摘要：
软件系统处理处于动态环境中的分布式应用时需要人的监管来执行操作。配置、诊断故障和维护任务导致大量时间和金钱消耗。主要由于软件开发过程中遵循的Open-loop架构。因此，需要在合理的时间和金钱范围内，降低管理复杂度、管理自动化、健壮性并达到质量需求。
自适应软件能满足这些需求，它采用闭环系统包括反馈环来在操作过程中适应环境变化。这些变化可能来源于软件系统自身或周围环境（context）。这种系统需要监控自己和环境，检测重要改变，并作出相应反应，执行决策。
这些过程依赖于适应属性、领域特点和用户偏好。需要新的模型和框架来设计自适应软件。
这篇文章基于自适应考虑进行了分类，提供该领域的一个landscape。并讲解其他学科中用到的自适应系统。
从而弥补潜在的研究鸿沟和面临的挑战

1.Introduction
自适应系统考虑性能、安全和错误管理。
自适应软件系统，将自适应机制用于软件系统。通常使用开环系统（open-loop system）实现软件应用被转换为使用反馈（feedback）的闭环系统（closed-loop system）。自适应性也可能通过feed-forward（前馈）机制实现。反馈环从整体考虑在应用和环境中发生了什么。

自适应软件目标是：调整不同的artifacts或属性对软件系统的self和context作出相应。self指软件自身，context指影响系统属性和行为的任何事。因此，自适应软件是一个从self和context获取反馈的闭环系统。

为什么需要自适应软件？处理软件系统复杂性的代价增加。在软件开发和内部质量属性模型中已经关注过处理复杂性和达到质量目标的研究，但最近，需要在运行时处理这些，起因是由于软件组件的分层，在运行时context/goals和需求更频繁的改变，以及高安全性需求。

自适应软件需要在运行时对改变作出相应。为达到该目标需要self-*属性，用来克服与预期目标的背离。
在自适应软件中动态/运行时的改变是自适应的基础。

这篇文章对自适应软件的基本学科、属性以及背景作出综述，对自适应进行分类，回答何时、什么、怎么和where的问题。采用这个分类对大量有自适应软件的学科和研究项目得出landscape，并进行对比，得出面临的挑战、当前研究gap以及将来建议。

section2讨论自适应软件的学科，section3介绍自适应软件的分类，基于获取适应需求的分级架构。section4解释适应系统的技术。section5将来的研究挑战并根据研究gap进行分类。section6是总结。

2.Self-adaptive software:principles and requirements
介绍自适应软件的基本概念

2.1 Definition
自适应软件的定义：
BAA【Laddaga 1997】提出：自适应软件评估自己的行为，并改变行为，当评估表明软件将要做的行为未完成，或当有更好的功能或性能时。
Oreizy et al.【1999】：自适应软件在运行时的改变作出反应从而改变自己的行为。运行是环境是指，软件系统观察到的任何事，如最终用户输入，外部软建设部和sensors或者程序探测。

将自适应编程作为oop的扩展，【Lieberherr and Palsberg 1993】：oop对象表现改变而不会影响程序。自适应程序：一般的过程模型被图约束参数化，这些约束定义了兼容的架构模型作为过程模型的参数。

适应映射到进化。
Buckley et al.【2005】：提出进化的分类，基于对象的改变（where），系统属性（what），临时属性（when）和改变支持（how）。
Salehie et al.【2009】：将该分类银蛇到自适应软件领域，并基于Activity Theory提出了适应改变的概念模型。
静态和动态适应，被映射为编译时进化和加载时/运行时进化。动态适应有时被称为动态进化。
Lehman【1996】：将自适应属性用于反馈和反馈控制，在软件context的进化过程中。

自适应软件系统与其他系统相关，如自治和自管理系统。这些术语很难区别。
Huebscher【2008】：自适应、自治计算和自管理可交换使用。
自适应软件与自治计算进行比较：自适应软件领域更受限制，而自治计算较宽的context，包括自适应软件。
【Schmidt 2002】软件敏感系统的分层模型包括：应用层，中间件，网络，操作系统，硬件和中间件子层。
自适应软件覆盖应用层和中间件层，自治计算覆盖更低层次，甚至可覆盖网络层和草走系统层。
然而自适应和自治计算关系紧密，在许多情况下可交替使用。

自适应软件的关键在于开发和初始安装完成后它的生命周期不会停止。生命周期将会继续，来评估系统并对作出响应改变。这样一个闭环可以处理不同的变化，关于用户需求，配置，安全等。

2.2 self-* Properties
IBM提出八个属性

2.2.1 A Hierarchical View

——General Level：包括自适应软件的全局属性。
self-adaptiveness：包括自管理，self-governing，自维护，自控制和自评估。
self-organizing：强调分散和意外功能。具有该属性的系统通常包括交互式元素，对整个系统或绝对没有意识到或只有部分认识。
self-organizing是自底向上的，而self-adaptiveness是自顶向下的。
本文主要关注self-adaptiveness。

——Major Level：【Horn 2002】IBM定义四个属性，根据生物学进行的定义。
self-configuring：是一种自动重新配置和对改变作出动态响应的能力，这些改变包括安装、更新、整个和组合/分解软件实体。
self-healing：与self-diagnosing和self-repairing相关。是发现、诊断并对破坏作出反应的能力。也可以预测潜在的问题，采取相应的合适行为来防止失败。self-diagnosing涉及诊断errors，faults，和失败，而sefl-repairing则关注于如何恢复。
self-optimizing：又叫self-tuning（自调整）或self-adjusing，是为了满足不同用户需求而管理性能和资源分配的能力。端对端响应时间，吞吐量，利用率和工作量与该属性有关。
self-protecting：检测安全漏洞并恢复效果的能力。包括两方面：抵御恶意攻击，预测问题并执行操作来避免或减轻影响。

——Primitive Level：self-awareness，self-monitoring，self-situated和context-awareness
Self-awareness：系统意识它自身的状态和行为。该属性基于自监控（反映了被监控的东西）
Context-awareness：系统意识它的环境，也就是运行的环境

2.2.2 Relationships with Quality Factors
self-*属性与软件质量因素有关。他们的联系帮助我们更好的定义和理解self-*属性，并利用在开发和运行自适应软件时现有的知识因素体系、度量和需求。
self-configuring影响的质量因素：可维护性、功能性、可移植性和可用性。
self-healing目标是最大化系统的availabitiy，survivability（生命力）、maintainability（维护性）和reliability（可靠性）
self-optimizing：efficiency（效率，因为减少响应时间通常是系统的主要需求之一），functionality功能性。
self-protecting：与reliability有关，也与functionality有关。
Primitive属性影响质量因素：maintaninability，functionality，portability可移植性。

2.3 Adaptation requirement elicitation（抽出、捕获）

提取自适应软件需求的问题Where, When, What, Why, Who, How

Where:关注改变的需求在哪。哪个artifacts哪一层，需要改变的粒度层次。为此，需要收集信息，关于适应软件的属性信息、组建和层之间的依赖，运行剖面的信息（operational profile）。因此，where陈列需要通过适应解决的问题所在位置。

When：解决改变的时间方面。什么时候需要应用变化，什么时候这样做可行？它能随时被应用，或有约束限制某些类型的改变么？多长时间系统需要改变？这些改变是持续发生的，还是只在需要时才发生？被动地执行适应操作足够么，或者我们需要预测一些改变并主动相应？

What：识别什么样的属性或系统atrifacts可以通过适应行为改变，在每种情形下什么需要改变。这些东西从参数方法到组件、架构风格和系统资源。同样重要的是，需要确定可供选择的行为和属性变化的范围。而且，确定应该检测什么样的事件和属性从而跟踪变化，适应行为所必需具备的资源是什么？

Why：建立自适应软件应用的动机。这些问题设计系统目标（如健壮性）。如果采用面向目标的需求工程方法来提取需求，这类问题用来确认自适应软件系统的目标goals。

Who：解决自适应软件的自动化水平和人类的参与水平。对于自动化，预期最少的人类干预，然而，为了建立信任和转让策略，与系统拥有者和管理人员进行有效地互动也是需要的。

How：自适应的一个重要需求是确定适应的artifacts如何被改变，哪些适应行为应用于一个给定的条件是合适的？为了确定下一步行动/计划，需要考虑改变的顺序，成本和副作用等。

为了实现自适应软件，上述问题需要在两个阶段内被回答：a）开发阶段，scratch（修改）或重构遗留系统时，开发和构建自适应软件。b）运行阶段，对在运行时基于自身或环境作出的合适变化，进行管理。在开发阶段，为了构建适应软件，也为了建立用于运行阶段的机制和alternatives可替代品，设计者需要基于上述问题提取需求。在运行阶段，系统需要基于这些问题适应自己。实际上，该阶段常问的问题包括，改变需要的资源在哪，什么需要被改变，什么时候怎么样更好的改变。在运行阶段这些问题的答案依赖于在开发阶段选择的适应方法和类型。这些问题可能通过policies策略由管理员和经理回答，剩下的由系统自己决定。
what和where的问题是显著的。where解决系统的哪部分引起的问题（如背离质量目标），而what涉及为了解决问题需要进行改变的属性和artifacts。例如，在多层企业应用中，知道哪部分引起性能下降是必要的（由于缺乏资源的数据库层），什么需要被改变（改变web层的服务水平）。有时，引起改变实体也是需要被改变的实体（组件交换）。因此，虽然这些问题是相关的，但它们针对适应的不同方面。

2.4 Adaptation Loop
在自治计算环境中称为MAPE-K loop：包括Monitoring，Analyzing，Planning和Executing functions，以及共享的Knowledge-base。

2.4.1 Adaptation Processes
存在于运行阶段的适应过程总结如下：
——The monitoring process：负责收集和关联从传感器获取的数据，并将它们转换为行为模式和征兆。该过程部分解决运行阶段的where、when和what问题。该过程可以通过事件关联，或简单的阈值检查等方法来实现。
——The detecting process：为了检测改变什么时候发生，负责分析由监控阶段和系统历史获取的症状。帮助确认转变到新状态（背离需要的状态或目标）的来源。
——The deciding process：决定什么需要被改变，以及怎么进行改变以达到最好的结果。这依赖于确定的标准来比较应用改变的不同方式，例如通过不同的行为计划。
——The acting process：负责应用由决策过程的操作，这包括通过预定义的工作流管理非原始的操作，或者映射行为到effectors和潜在的动态适应技术提供的。该过程设计的问题是how、what、什么时候改变。

2.4.2 Sensors and Effectors
Sensors 监控软件实体，生成影响系统状态的数据集合，而effectors应用改变，实现适应行为。Sensors和effectors是自适应软件系统的必要部分。
表1介绍在自适应软件中常用的sensors和effectors。Logging是捕获软件信息的最简单技术。Logs需要被过滤、processed和分析为mine重大信息。
来自其他领域的sensing和monitoring技术：CBE，WBME和SIENA，ARM，ARM使得开发者能创建可理解的端到端的管理系统，它有测量应用的可用性、性能、usage、和端到端响应时间的能力。SNMP中对网络和分布式系统的思想也适用于自适应软件。

剖析工具和技术也能帮助定义sensors。为此Java环境提供了JVMTI。软件管理框架，如JMX为sensing和effecting提供强大的功能。由网格计算采用的脉冲监控是心跳监控过程的扩展。该技术对监控实体进行编码。

effectors基于一系列设计模式，允许软件系统在运行时改变某些artifacts。例如，wrapper、proxy和strategy是比较常用的设计模式。Landauer【2001】在适应系统的架构层利用wrapping思想。另外，microkernel、refection和interception是使用软件系统适应性的架构模式。此外，Kephart【2005】为self-configuring、self-healing和self-optimizing分别提出几种设计模式，目标驱动的self-assembly，self-healing clusters，和效应函数驱动的资源分配。Babaoglu【2006】从生物学得出设计模式，如plain diffusion（分散？）和replication（复制），应用于分布式适应系统。

effectors技术的一个重要类别是基于中间件的。系统开发人员在中间件层通过拦截软件流或使用设计模式实现effectors。其他实现effectors的方案：使用动态方面编织（如JAC），原对象协议（如TRAP/J)，和功能指针技术（CASA）来实现。一些中间件提供动态方面编织，如JBoss的AOP模块。

3. A taxonomy of self-adaptation

3.1 Object to Adapt
处理开发和运行阶段的where和what问题。

——Layer层：软件系统基于需求那一层是不被期望的？系统哪一层可被改变并需要改变？适应行为可应用于不同的层。为此，McKinley et al.【2004】定义了应用和中间件两种水平，中间件被分解为四个子层。应用层适应于中间件层在很多方面有所不同，如，应用层适应的变化通常对用户有直接影响，它们可能需要用户的直接显示的赞成和信任。

——Artifact and Granularity：哪些artifacts，哪一粒度层次需要被改变。什么artifact、属性或资源需要被改变？适应可以改变模块或架构和它们的组成方式。应用可以被分解为服务、方法、对象、组件、aspects和依赖架构和实现中使用的技术的子系统。这些实体的每一个和它们的属性、compositions一样可以从属于改变，因此，适应可以应用于细粒度或粗粒度水平。

——Impact & cost：impact描述后效的范围，而cost涉及执行时间、需要的资源和适应行为的复杂性。与适应行为应用于what和部分如何how被应用相关。
基于impact和cost因素，适应行为可被分为弱类和强类别。弱适应包含修改参数或执行低成本/有限影响的操作，而强适应处理高成本/广泛影响的操作，如替换组件以改善系统质量。通常来讲，弱适应包括改变参数（带宽限制）、使用预先定义的静态机制（负载平衡）、或其他局部影响和低成本的操作（压缩数据）。强适应可能改变、添加、删除或替换系统artifact。该分类的成本涉及一个操作需要花费多少时间和资源。很大程度上取决于操作需求（可供选择的交换）是已经准备好了，还是在运行时准备好。强适应可能包含弱适应，如改变架构可能需要改变组件的部署并改变少量参数。

3.2 Realization Issues
处理如何how应用适应。分为approach和type两类。

3.2.1 Adaptation Approach
将适应合并到系统的方法。

——Static/Dynamic Decision Making：处理决策过程如何被执行和修改。对于静态，决策过程是硬编码的（如决策树），它的修改需要重新编译和重新部署系统或系统的一些组件。而动态决策制定，决策规则或QoS定义在外部被定义和管理，所以它们在运行时可以被改变，从而根据功能性和非功能性软件需求来创建新的行为。

——External/Internal Adaptaion：从不同的视角，对于适应机制和应用逻辑可将适应分为两类：Internal/External。

Internal：内部方法于应用和应用逻辑有关。该方法基于编程语言特征，如条件表达式、参数化和异常。该方法中，整个sensors、effectors集合和适应过程于应用代码混合在一起，导致扩展性和维护性差。该方法处理局部适应（异常处理）比较有用。然而，适应通常需要系统和发生在自身和环境中的相关事件的全局信息。通常，该方法可能通过扩展已存在的编程语言或定义新的适应语言来实现。

External：外部方法使用一个包含适应过程的外部适应引擎。使用该方法，自适应软件系统包括适应引擎和适应软件两部分。外部引擎在中间件、决策policy引擎或其他应用独立机制的帮助下实现适应逻辑。在一个复杂的腹部是系统中，通常需要多个自适应元素，每个都包含这两部分。这种情况下，在一个合适的架构组成元素和交互式的基础设施是必要的。

内部方法有明显的缺陷。如，系统测试和维护/进化代价高，通常不可扩展。
外部方法的重要优势，适应引擎或一些对不同应用实现过程的重用性。这意味着，一个适应引擎可为不同系统进行定制和配置。

——Making/Achieving Adaptation：一般来讲，可以使用两种策略将自适应性引入到软件系统。第一种策略是：在开发阶段将自适应性工程化到系统。第二种策略是：通过适应学习实现自适应。 Sterrit【2003】称这两种方法为making和achieving。Making有一种暗含系统或软件工程的观点，将适应性工程化到各个系统。而Achieving暗含人工智能和适应学习的观点来实现适适应行为。这两栋方法在某种意义上说并不抵触，它们也可被组合起来使用。

3.2.2 Adaptation Type
它指明：对于新的选择，适应是开的还是闭的，领域是特定的还是普通的，是基于模型的还是无模型的。

——Close/Open Adaptaion：闭适应系统仅有固定数量的适应行为，在运行时没有新的行为和选择被引入。另一方面，在开适应中，自适应软件可被扩展，结果，新的选择被添加，甚至新的适应实体可以被引入到适应机制中。

——Model-Based/Free Adaptation：在无模型的适应中，适应机制没有环境和系统自身的预定义模型，适应机制通过了解需求、目标和alternatives对系统进行调整。如，Dowling在适应中使用无模型的RL。另一方面，基于模型的适应，适应机制利用系统和环境模型。这可以使用不同的模型方法来实现，如，self-optimizing的队列模型，self-healing的架构模型，或【Karsai 1999】中的领域相关模型。

——Specific/Generic Adaptaion：一些现存的解决方案只针对特定领域/应用，如数据库。然而，通用方案也是可用的，通过为不同领域设定决策、alternatives替代方案和适应过程来对其进行配置。该类型除了解决how问题外，还解决where和what，因为特定类型仅关注软件系统特定部分的artifacts或属性的适应。

3.3 Temporal Characteristics
处理问题：什么时候artifacts需要被改变。

——Reactive/Proactive Adaptation被动/主动：捕获自适应软件的预期属性。在被动模式下，当改变已经发生时系统才做出响应，而主动模式下，系统预测改变将会何时发生。该问题影响检测和决策过程。

——Continuous/Adaptive Monitoring：捕获监控过程是连续收集和处理数据，还是适应的（它监控少量选择出来的特征，在发现异常的情况下，旨在收集更多数据）。该决定影响监控成本和检测时间。

3.4 Interaction Concerns
包括与人的交互和与其他元素/系统的交互。与where、when、what、how、who相关。

——Human Invovlement：改变的agent是谁who。在自适应软件中，人类的参与可从两个角度进行讨论。第一，机制自动化的程度；第二，与用户和管理员的交互有多好（交互程度）。前者，我们可以使用在自治计算中提出的成熟度模型。该模型级别包括basic、managed、predictive、adaptive和autonomic。人类的参与是不想要的，因此要求更多的自动化。然而，第二个观点解决与人类的交互质量，与或者表达他们的期望和方针policies，或者观察系统发生了什么交互。根据这个观点，人类的参与是必要的，并且对于改善自适应软件的易管理性和可信赖性是很有价值的。这篇文章采用第二种观点。

——Trust：信任是一种基于过去经验或行为透明度的信赖关系。信任的一种观点是安全，正如Dobson【2006】在自治系统中提到highlighted的。另一种观点，人类或其他系统依赖自适应软件系统完成多少任务，这种观点与assurance保障性和dependability可靠性相关。Georgas【2005】认为dependability是：对于合适的和正确的适应系统可以被信任的程度。然而McCann指出基于自适应服务或质量 信任是不必要的，他们讨论，如何通过揭示关于系统状态和适应过程能见性的重要信息来建立信任。这解释了为什么可预测性被认为是将信任置于自适应软件的一个重要因素。

——Interoperability Support：自适应软件通常包括元素、模块和子系统。在复杂的分布式系统中，为了在所有构成元素和子系统间维护数据和行为的完整性，总是需要关注互操作性。在自适应软件中，元素间需要协调从而拥有self-*属性和实现预期需求。在不同的层和系统平台中，如果元素和指定机制间可互操作，将会满足全局的适应需求。


4. A landscape of the research area
这节提供了自适应软件系统中当前研究的landscape。讨论了两个宏观方面：i）支持学科；ii）选定的项目。前者指出不同的学科处理适应系统，系统支持构建、评估和使用自适应软件系统，而后者给出了该领域当前状态的picture。

4.1 Supporting Disciplines

landscape的第一个观点显示，能够支持和促进开发和运行自适应软件系统的这些学科有多么不同。值得注意的一点是，自适应软件本质上是跨学科的，学科间的融合很大程度上依赖于为了构建特定的自适应软件系统而采用设计隐喻metaphor，Laddaga列举了被早期研究员使用的设计隐喻：应用程序编码为动态规划系统，应用程序编码为控制系统，编码自意识（self-aware）系统。这些隐喻利用了人工智能、控制理论和决策理论的思想。下面小节将会讨论一些学科——即软件工程，人工智能，决策理论，控制理论和网络及分布式计算。虽然其他学科，像优化理论也可被加到该列表中，但由于篇幅限制，仅部分讨论与其他学科的联系。

4.1.1 Software Engineering
软件工程中的神经研究领域和自适应软件相关。正如2.2.2节讨论到的self-*属性与质量因素相关。因此，在软件质量环境中实现和测量质量的思想可能适用于自适应软件。一些研究工作，如【Salehie和Tahvildari 2007】，只在建立该链接。关键点是self-*属性大多与非功能需求NFR相关，如安全和性能。事实上，满足这些需求是改变的主要诱因。然而，功能需求也与自适应相关。一个例子是，为了改善组件性能，改变组件的行为使其达到可接受的较低级别的功能。这些问题也将需求工程引入picture。几个研究员已经在自适应软件中使用NFR模型，尤其是目标模型，如Lapouchnian et al.【2005】和Subramanian【2001】。

将软件和说明与以及形式化模型结合在一起可以监测正确性以及许多其他关于特定功能和self-*属性的指标。形式化方法为建模软件系统以及利用这些模型提供了多种方式。在适应过程中有可能依赖形式化方法建模适应软件。此外，形式化方法可以用来验证和核查自适应软件以确保软件具有正确的功能，并理解软件的行为。由于传统和自适应软件之间的差别，不能直接使用现有的模型和为非自适应软件系统开发的方法。这意味着需要基于形式化模型的新方法，如Model-Integrated Computing（MIC）。MIC已被成功应用到领域相关的嵌入式系统中来管理运行时配置。

Software Architecture软件架构模型和语言，如ADL，对软件建模和管理很有帮助，尤其是在运行时。Bradbury et al.[2004]研究了几个ADLs，它们是基于图、进程代数和动态软件架构中的其他形式化内容的。Garlan et al.[2004]使用Acme ADL来描述适应软件的架构，并检测与定义好的约束间的冲突。Klein et al【1999】指出，软件架构也能帮助管理变化。另一个有用的思想，ABAS基于属性的架构风格，为了提供一个方法，来实现架构设计和交互组件类型的行为，因此ABAS包括质量属性依赖模型。

CBSE基于组件的软件工程，可以在两方面帮助自适应软件的开发。首先，依赖组件模型来设计和实现适应软件是很容易的。其次，适应引擎需要被模块化和可重用，CBSE可以用于适应引擎的开发。此外，正如在ACT中指出的，组件模型可被用于适应系统，作为并入动态适应和适应管理的潜在服务。另一个相关的领域，AOP（Aspect-Oriented Programming）和更加具体的动态AOP，也可以用于实现自适应软件。这有利于通过动态运行时适应将适应concerns以aspects的形式进行封装。它也有助于在比组件更低水平上，实现细粒度的适应行为。例如JAC（dynamic AOP framework）采用封装来动态的改变现有或新加入的节点。AOP也可像在IBM BtM工具中一样用于插装传感器。

服务计算和SOA，通过促进松耦合服务的组合来支持实现自适应软件。Web服务由于其组合的灵活性、服务编排（orchestration？）和服务组装（choreography？），对于实现动态适应业务流程和面向服务的软件系统来说，通常是一个合适的选择。Birman et al【2004】提出了web服务架构的扩展，用来支持关键任务应用。例如，跟踪组件健康状况的标准服务、将自诊断整合到应用中的机制、和自动化配置工具。另一个值得重视的工作，AWP动态Web流程，是支持self-*属性的基于web服务的流程。

4.1.2 Artificial Intelligence
正如Laddaga【1999】所指出的，并没有过多的将人工智能技术应用于开发和管理系统，想规划和概率推理。尤其是，自适应软件与AI和自适应系统有着显著的共同点。在检测过程，AI可以辅助日志/跟踪分析，以及模式/征兆匹配以识别异常情况或违反约束。AI有丰富的规划、推理和学习技术，这些在决策过程中都是很有用的。然而，基于AI的系统中质量保证成为一个问题，因为使用了智能的、启发式和基于搜索的技术，质量保证变得很必要。在软件系统的特定类别中，二十多年前Parnas【1985】指出了该问题，但同时这也是其他系统中遇到的问题。

实现自适应软件的一个有趣的方法是基于AI规划。该方法中，软件系统会规划或重新规划它的行为，而不是简单的执行特定算法。这与决策过程中选择合适的操作尤其相关。基于规划的适应应该总是积极的，通过在现有的规划中搜索或组合适应行为。实际上，适应引擎需要连续的规划，通过应急规划或重规划。前者基于传感信息提供带有可替代路径的条件规划，而后者当原规划失败的时候生成一个可替代的规划。规划的基本形式不能用于所有的self-*属性。Srivastava【2005】称所有的self-*属性中，规划最可能用于self-healing。将AI规划用于self-healing的例子Arshad et al【2003】。用于自适应软件的一个重要概念是，软件代理对它们的领域、目标、决策制定属性模型化的方式。例如，Maes【1990】为选择操作而提出了一个基于目标的模型。在基于代理的系统中，面向目标的需求建模是一个比较成熟的领域，有许多研究成果包括在自适应软件中的模型和方法。

MAS：协调模型和分布式优化技术，在多元素自适应软件中很有用。在这些系统中，从self-*属性中获取到的局部和全局目标需要被调整。Tesauro【2004】实现了MAS的一个例子——Unity，作为基于多元交互代理的分散自治架构。Weyns【2005】也在自适应软件中使用多代理架构。如，他们对自适应使用了一个合适的多代理架构来自动知道车辆交通系统。

Machine Learning and Soft Computing：机器学习和软计算，通过achieving方法，在自适应软件中发挥着重要作用。Achieving需要分析传感数据流和学习最好的操作方式。Oreizy【1999】制定进化编程和基于AI的学习为一种处理不可预测的变化的方法类别，这些变化有着明确的关注点分离。这些算法通常使用环境属性和早期的尝试中获取到的知识来生成新的算法。遗传算法和不同的在线学习算法，也可使用RL强化学习。RL对于动态行为选择和分散合作的自适应软件来说是一个很有前途的选择。Tesauro【2007】认为，RL比传统的方法有更好的潜能来实现更好的性能，而只需要少量的领域知识。他还说，对于训练来说RL依赖于探测，在一个自生系统中学习策略并不总是可行的。相反的，可以使用离线训练或使用现有政策的混合方法。Salehid【2005b】认为模糊逻辑也适用于解决质量目标和政策的模糊问题。

Decision theory：决策理论，以古典和定性两种形式有利于决策过程的实现。古典形式适用情形，决策制定依赖于以确定的方式最大化效应函数，而定性形式适用于不确定的问题。

Utility theory：效用理论，效用指一个行为、选择或alternative有用的质量，可通过确定或不确定来指定。因此，效用理论将一个合适的效用值赋值到每个可能的结果，并基于最大的效用值选择出最好的操作序列。Walsh【2004】称，在一个动态异构的环境中，效用函数能够使得自治元素持续的优化计算资源。Poladian【2004】在资源意识服务中对用户需求和偏好使用效用函数。他们使用效用函数对这些服务的配置形式化一个最优的问题。Nowicki【2005】使用效用函数处理分散的优化。Boutilier在self-optimizing中使用效用函数，并依赖增量效用提取来执行必要的计算，这些计算仅使用从基础函数获得的少量样本点。

由于不确定性，在决策制定中需要概率推理和决策理论规划。MDP（马尔科夫决策过程）和贝叶斯网络是两个比较成熟的技术，通常由于它们的不确定属性适用于实现self-*属性。如，有些研究成果使用这些模型来用于诊断和自我恢复self-recovery，如，How【1995】，Robertson【2005】，Williams【2006】。Porcarelli【2003】也将随机Petri网用于决策制定中的容错问题。

4.1.3 Control Theory/Engineering
与自适应软件类似，控制理论和工程也是通过sense-plan-act换与周围环境进行重复交互。在控制理论和工程中，适应和反馈的概念已被讨论了十多年，并在很多领域中用于设计和开发系统。基于控制的范式将软件系统（适应软件）作为一个有两种输入类型的可控plant，两种输入类型：控制输入，控制plant的行为；disturbances干扰，以不可预测的方式改变plant的行为。控制器controller（适应引擎）改变plant的控制输入值。

基于控制的范式通常被用于基于软件plant的行为模型。如，Litoiu【2005】软件系统的分级层次队列模型（LQM）来调整参数（弱适应）。Abdelwahed【2004】表明，基于模型的控制架构可通过调整plant参数来实现self-optimizing属性。此外，Bhat【2006】通过扩展ACCORD组件框架，将在线控制模型应用于实现自管理目标。虽然对于基于控制的自适应软件来说，closed-loop是最常用的模型，由于某些原因适应的和可重新配置的模型也被推荐，这些原因包括大范围的动态干扰disturbances。另一方面，考虑到软件系统的离散型，适用于自适应软件的一个基于控制的方法是DES（离散时间系统监督控制），如Tziallas【2004】。

传统上，控制理论已在物理定律控制的系统中被考虑到。这使得系统能够断言确定属性的存在与否，然而，这是软件系统中不必要的情形。实际上，检查软件的可控性或构建一个可控的软件是一个挑战，通常包括非直觉分析和系统修改。因此，一些研究员认为，在软件中应用这种方法通常比在传统的控制系统中应用更复杂。


4.1.4 Network and Distributed Computing
网络和分布式计算，其技术可被广泛应用于自适应软件。这是由于大部分的现有系统都是分布式的和以网络为中心的。虽然将这些技术用于自适应软件的所有层会很困难，但在解决适应需求和系统的工程化方面很有前景。该领域的另一研究方向，P2P应用和ad hoc网络，处理环境、架构和质量需求的动态变化。在该领域的研究通常以自底向上的方法使用self-orgnizing元素。然而，本文不过多的关注具有self-organizing属性的系统。

Policy-based management：基于政策的管理是网络和分布式计算中最成功的方法之一。给予政策的管理针对如何处理可能发生的场景。policy定义大多强调在决策制定和操作中提供指导。政策管理服务通常包括政策库、用于解释政策的PDP集（Policy Decision Points政策决策节点）和应用政策的PEP集（Policy enforcement points，政策实施节点）。在网络中最常用的决策类型是action policy（动作策略or实施方针），也适用于自适应软件。另外，像goal policy和utility policy等政策类型也可用于自适应软件。适应策略需要根据新的需求和条件进行改变。一些研究成果针对该问题，如，Aly【2007】在数据中心中对政策的动态改变提出一个控制理论技术。Keeney【2003】基于政策的管理已被大量自适应软件研究所采纳。如，为了开发基于政策的自适应软件一些框架也被引入，如基于Java的企业系统领域中的StarMX框架。

Quality of Service management：QoS管理，网络和分布式系统中另一成功的领域，与政策管理密切相关。QoS需求与系统的非功能需求相关，因此，QoS需求与分布式软件系统中的self-*属性有关。因此，QoS管理方法或依赖于应用程序建模（如，队列模型），或使用易于理解的组件（如PECT，prediction-enabled component technology，能预测的组件技术）。因此，QoS管理帮助自适应软件系统对质量因素建模，并帮助实现适应过程。

Middleware：基于建模的适应也适用于适应过程。如，Floch【2006】制定决策和检测改变的通用组件可在中间件层被实现。

Resource Management：资源管理，虚拟技术对自适应软件的质量有重要影响。Menasce【2006】虚拟技术将适应引擎领域降至虚拟机内容。因此，很容易处理动态资源管理和资源国际。虚拟提供了一种有效地方式，使得遗留软件系统可以与当前操作环境共存。该属性可被用于通过遗留系统构建适应软件。

Monitoring and sensing techniques：监控和传感技术，基本技术如心跳监控，高级技术如脉冲监控被用于自适应和自管理软件。自适应软件中的一个重要问题，传感和监控的成本。该问题在网络和分布式系统中被广泛研究。

4.2 Research Projects
本节中的项目，从不同的学术和商业部门中选择出来，主要捕捉自适应软件领域中的主要研究趋势。从很多学术和商业研究项目中收集信息。然而，我们只选择了该少量能够代表该领域主要研究思想的项目。
主要目的：获取自适应软件领域中的主要研究趋势
另一目的：该领域中现存的研究问题。

表3中以发表时间排序，列举出选择的项目。基于它们在领域中的影响和方法的新颖、重要性进行选择。以三个观点进行对比，self-*属性，适应过程和分类。

表4表明，大多数项目一个或两个self-*属性，这表明，多元self-*属性的调整和编排仍未得到足有的重视。另一个显著的点，只有有限数量的项目支持self-protecting（只有一个支持）。通常来讲，这是、由于网络拓扑结构的不断变化、软件组件或服务日益增长的多样性、日益增长的复杂性以及攻击和病毒的多样化。多数处理self-protecting的研究关注网络层，特别是攻击检测。

第二个观点，项目如何解决适应过程。表5按4个级别对项目进行了分类和比较。每个过程的级别是基于效率和不同方面的覆盖以及对可用标准的支持的。每个过程也有自己的特定方面，如，为了评估决策过程，我们研究项目是否考虑了动态性和不确定性。
column-wise 评估表明，监控、检测、决策和执行中的每一个只有两到三个项目是high-support的。这表明，需要提供全面（综合）的解决方案来高度high level实现适应过程。

第三节中介绍的分类，提供第三个观点，在表4中被总结，分析该表前，需要注意，一些方面facets的可能值并不是相互排斥的。如，一个项目可以采用making和achieving混合使用的方法。

——Layer（L）：大多数项目关注期望的应用层。注意，这篇文章主要处理软件密集系统的上层。
——Artifact & Granularity（A & G）：解决了在不同粒度级别的多种artifacts，这是积极的角度。
——Impact & Cost（I & C）：大多数项目实现了弱适应和强适应操作。这是积极的角度，因为依靠环境采用低/高成本和局部/全局的行为是可能的。
——Making/Achieving（M/A）：很少使用achieving方法，这意味着在该领域中学习和进化算法还未普遍使用。
——External/Internal（E/I）：所有项目都是用external方法，它们都支持适应机制和适应逻辑的分离。
——Static/Dynamic Decision-Making（S/D DM）：动态决策过程的数量不是很多，但很显著。部分由于给予政策管理领域的研究活动。
——Open/Close（O/C）：另一个值得注意的观察是，很多项目支持close适应。这是由于稳定性和保证性考虑不能获得openness开放。
——Specific/Generic（S/G）：多数7/16的项目是基于组件系统开发的。组件是松耦合的实体，能比其他实体更容易地在运行时被动态改变。
——Model-Baed/-Free（MB/F）：大多是项目是Model-based，在工程学科中，基于模型的广泛应用和模型驱动方法并不奇怪。
——Reactive/Proactive（R/P）：大多数项目是reactive的，这通常不是一个缺点。然而，对一些领域来说，为了减少改变的副作用，或阻止改变的传播，需要具有主动性（积极性）。
——Continuous/Adaptvie Monitoring（C/A M）：大多数项目仍使用continuous monitoring，考虑到成本和过程的负载不是很好。
——Human Involvement（HI）：大多数项目未包括一个合适的人类接口。这影响了系统的可用性和可信性。
——Interoperability（I）：只有一个项目提出了互操作机制，该机制使得系统可与其他自适应或自治元素或系统互操作。这限制了实用性applicability，尤其是在紧急面向服务的应用中。

5. Research Challenges

自适应软件为软件密集型系统的发展和运作提供了新的机遇，同时也带来了新的挑战。本节旨在指出实现自适应软件的挑战。

依据自治计算领域，宏观上提出挑战：
i）：Element/Component-Level Challenges：构建元素接口和共享信息；设计或实现合适的适应过程；为了执行和调整适应过程为元素设计合适的架构。
ii）System-Level Challenges：调整self—*属性和元素间的自适应过程；指定评价标准；定义合适的架构以实现该层的需求（如，元素间的交流）。
iii）Human-System Interaction Challenges：构建信任；提供合适的机制收集用户策略；构建合适的机制使人参与到适应循环中。

虽然，上述分类提供了关于自适应系统挑战的见解，但对于本文前面降到的分类和landscape并不是很合适。此外，对一些依赖潜在设计决策的确定挑战来说，，它们可能存在于元素层或系统层。为了弥补这个缺陷，接下来，我们只在基于图5中总结的points来对潜在的挑战进行分类。这些挑战与前面介绍到的概念相关。

5.1 Challenges in Engineering Self-Adaptive Software
本节处理需求分析、设计、实现和自适应软件评估的工程挑战。

——Requirements analysis：系统需求（尤其是非功能性需求）、self-*属性和质量因素三者之间相互关联。因此，除了需求工程的主要任务——即捕获利益相关者的期望，另一个关键的挑战是，如何将这些期望进行转化translate、模型化，并与在运行时用到的适应需求和目标进行关联。在开发和运行阶段，desired模型被作为回答适应需求问题的基础使用。换句话说，secifications不仅用于开发自适应软件，也用于运行阶段的冲突解决和改变管理。Goal-oriented需求工程被认为是解决这些挑战的有前途的方法。

——Design issues：一个关键挑战是，如何设计自适应软件使其满足适应需求。虽然大量研究关注自适应软件的设计，但在该领域中仍存在一些重要的开放性问题。在internal方法中，需要扩展现有的编程语言，或定义新的适应语言。然而，正如section4.2中的项目landscape表明，大多数现有的研究都是基于external方法的。因此，挑战被分解为：i）设计基本的（underlying）适应软件系统和软件引擎；ii）连接它们形成架构。下面列出了这些挑战的总结。

第一个问题是，如何设计适应软件，或者从遗留系统出发。该问题主要处理：适应设计design of adaptablity。适应软件需要从传感器揭露重要信息，并促进effectors变化。相关问题如下：i）为此，哪种架构风格和设计模式适用；ii）哪种组件对sensing和effecting提供最好的支持；iii）哪种接口或合约（contracts）需要被考虑；最重要的是，iv）如何采用重构的方法，将遗留系统转换为适应软件？另一个挑战是，如何在再造reengineering、逆向工程、重构re-factoring中使用现有的经验。Parekh【2006】通过提出一个框架将自治能力改造纳入到遗留系统中，部分的解决了该挑战。对于可变性管理来说，来自产品体系结构的思想也会非常有用。

设计适应引擎的主要挑战将在5.3节中讲解。然而，漏掉了两点：i）如何设计政策enforcement需要，且连接适应软件的接口？ii）对于内部过程交流和引擎内共享知识来说，哪种架构是合适的。最后是，互操作性和系统范围的架构。几个研究员研究了该问题，Smith【2005】解决系统元素间或系统间交互的复杂性和可变性；McKinley【2004】讨论了，适应系统中跨层调整组件的需要；Parekh【2006】该挑战的一个方面是，元素间交流渠道的可用性。

——Implementation languages, tools, and frameworks：通常来讲，可以通过两种方式构建自适应和自治软件。i）扩展现有编程语言/系统 或定义新的适应语言（如基于aspects）；ii）通过在运行时允许添加、一处和修改软件实体（如基于中间件），使其能动态适应。实际上，需要将这些方案组合起来，以构建元素、促进组合、为交互和管理提供运行时基础结构。虽然在解决方案和它们的组合上有大量研究成果，但仍然缺少强大语言、工具、框架，来帮助系统的实现适应过程和sensors/effectors设备。基于中间件的方法看起来比较有前途，因为有infrastructure。然而，动态操作（如effectors）仍未被广泛支持，或不稳定。

——Testing and assurance：在自适应软件工程中关注很少，只有少量研究成果。挑战是，系统中适应artifacts和参数的几个替代方案是否可用。这导致不同场景中的几条执行路径。如果我们在该场景中加入动态决策制定和achieving方法，将会更加复杂。有一些尝试，为了验证改变，在运行时使用self-test机制。King【2007】为此提出，在自治系统中加入测试管理器的思想；Zhang【2007】提出，对适应验证verification提出一个运行时模型检查方法。

——Evaluation and quality of adaptation：到目前为止，还没有任何全面的工作，来解决适应软件（更一般的说，自治计算）的评估标准和指标问题。self-*属性和软件质量目标中有联系，然而，帮助测量适应质量的质量指标仍然是一个开放的问题。因素，像Gjorven【2006】讨论到得安全性safety、security和性能，以及McCann【2004】讨论到的QoS、成本和粒度/灵活性。benchmarks基准、testbeds试验台以及案例分析可以帮助对不同的适应方案进行评估和对比，至少与每个适应过程相关。

——5.2 Challenges Related to Self-* Properties
self-*属性是自适应软件的重要特征。本节总结了实现这些属性的挑战。

——Individual self-*属性：按照4.2节的分析，self-protecting受到最少的重视。通常，大多数寡欲self-protecting的研究关注于检测异常症状（如，入侵）。这些研究还关注，安全管理和恢复中不同技术的整合。然而，在所有的适应过程中实现该属性，尤其是在上层（如，中间件和应用层），很有挑战。

实现self-*属性的重要问题，在适应软件或环境中，系统检测改变的能力以及潜在结果。这些挑战包括，基于在运行时的软件动态模型或数据分析来推理或预测改变传播。而且，对于self-healing和self-protecting属性来说，问题是，如何限制或隔离问题组件，并最终恢复这些组件。这需要嵌入式的effectors，它们可以使系统在不崩溃或中断的情况下得以恢复。

——Building multiproperty self-adaptive software：正如表4中显示，大多数项目没有解决超过一个self-*属性。此外，解决多元属性的那些项目，没有系统的调整这些属性。通常，大多数提出的方案没有解决self-*属性（包括priority、confilict）和运行时操作执行顺序之间的关系。很明显，在自适应软件中，调整、编制这些属性和它们在不同的力度层派生出来的目标，是很重要的挑战之一。IBM【2005】IBM在self-*属性在学科间或学科内部的引用架构中解决了该问题。Cheng【2006】在一个基于架构的适应中也关注了该挑战。

每个self-*属性处理几个问题concerns，如成本和时间。实现想要的self-*属性意味着满足与这些concerns相关的目标，这些目标受制于给定的约束。可用方案的问题是，在适应中，这些方案通常不依赖多问题观点multi-concern view。漏掉的concern一个例子是，与软件系统业务方面相关的操作成本/效益。

5.3 Challenges in Adaptation Processes
研究挑战的一个合适方法是，基于适应过程对它们进行分类

——Monitoring challenges：在适应软件中，对于不同属性监控的一个重要挑战是，sensors的成本/负载。在多数情况下，许多vivo方法收集多种信息，这些信息可能不被desired self-*属性所需要。一些情况下，监控过程不需要事件详情，而，在违背正常行为的情况下，将需要更多的数据。因此，为了增加认知awareness水平，对于适应软件情形，监控过程需要被适配。这样的过程，叫做适应监控过程。Oreizy【1999】争论，为了决定需要when和where的适应，一个自适应软件需要一个规划过程来指定哪些观察是必要的。很少的成果研究适应监控，如，Diaconescu【2004】在J2EE应用中的COMPAS框架。虽然这些成果部分解决了监控挑战，但需得到更多注意。

——Detecting challenges：检测过程的突出问题是，软件系统的哪些行为/状态是健康/正常的？回答该问题，通常需要非常耗时的对系统进行静态或动态分析，可能会受到潜在随机因素的影响（如，用户请求到达的次数、和不同组件的错误）。虽然一些成果，应用统计和数据挖掘技术来解决该问题，该过程的现有实现大部分仍然是ad hoc和不完全的。

——Deciding challenges：决策过程需要在局部层（适应引擎）和系统层引起重视。正如McKinley【2004】指出，大多数已知的方法是静态的，并且只对特定领域有效。正如表5所示，很少研究项目为该过程提供强大支持，特别是同时关注在动态和不确定环境中的多重self-*属性的项目。此外，如表4所示，一半的项目针对动态决策制定。由于多重目标存在，再加上在线和动态决策的必要性，面临如下附加挑战：i）为多目标决策制定问题找出近似或部分最优的解决方案；ii）处理来自系统自身和周围环境的事件/信息的不确定性和不完整性；iii）关联局部和全局决策制定机制；iv）采用集中或分散模型解决决策制定机制的可扩展性和易错性。

——Acting challenges：一个重要挑战，如何确保，适应将保持稳定并且对于潜在软件系统的功能和非功能方面有可预测的影响。i）适应操作是否遵守合约contracts和系统的架构风格；ii）它们是否影响应用的安全性和完整性；iii）如果操作失败将会发生什么，或者为了推迟当前操作，处理更高优先级的操作需要进行抢占，这时会发生什么。这些问题很重要，尤其是对于那些在不稳定的环境中具有开放式适应和动态决策制定的系统。Laddaga【2006】在适应软件稳定的环境中解决了这些挑战，并且Karsai【2001】将这些挑战关联到验证verification。这些问题仍然需要更多的重新研究，因为文献中提到的大多数解决方案是ad hoc和问题相关的。形式化方法和模型驱动的解决方案，并加上模型/约束检查的辅助，是这方面一个有前途的方向。

5.4 Challenges in Interaction

初看，自适应软件的人类接口看起来比非适应软件的构建起来容易许多。然而，正如Russell【2003】指出的，存在一些问题：政策管理、信任和人类参与。4.2节的分析显示，大多数项目，对于政策改变或者适应过程追踪都没有人的参与。这些挑战概括如下：

————Policy management：由于缺乏显式的政策和目标表示，现有解决方案呈下滑趋势。这导致了两个问题：

——Policy translation：政策和目标通常需要被分解为或转化newi系统元素能够理解的低级/局部政策和目标。在复杂的大规模的系统中，如果没有目标/政策模型，要高效的完成这项任务是很困难的。这需要高度灵活的模型和算法，这是一个很有价值的研究问题。

——Dynamic policies and goals：对于决策过程，开发者需要硬编码或预先编译操作选择机制。为此，通常使用基于规则的机制，该机制是基于一个固定的静态冲突解决方案机制的。系统中的规则，是以设计阶段的目标、政策或desired行为的声明描述为基础，而进行手动编码或编译的。

————Building trust：另一值得注意的挑战，建立信任。信任问题并不局限于自适应软件，在很多基于计算机的和软件密集型的系统中，它是一个通常的研究课题。然而，自适应软件，由于它的动态和自动的特征，对该问题添加了新的concerns。对于用户和利益相关者来说，独立和智能使得这类系统难以追踪。考虑到安全性，自适应应用帮助新人管理是非常必要的，并且，为了向管理员揭露正在发生的事情，自适应应用需要回报它的活动和决策。增加信任的构建，以确保适应过程是安全的。信任也可以在自适应元素和服务之间定义，其中，该问题将会影响互操作性。

————Interoperability：在大多数分布式复杂系统中，尤其是在所谓的系统中的系统，该问题是一个很大的挑战。在自适应软件中，除了数据相关的问题，调整和编排所有元素的自适应行为是个很有挑战的任务。对于每个属性和不同的属性之间，实现全局的需求和self-*属性并不是一个直接简明的任务。ULS（Ultra-Large Scale）系统的出现增加了互操作的重要性，同时产生了新的挑战。

6. Summary
自适应软件领域越来越受重视（越来越重要）。尽管有大量的优秀研究成果，但该领域仍处于初步阶段（幼儿期），在今天的动态和常变的环境中，现有知识远远不足以解决软件日益增长的自适应性要求。自适应软件为计算机科学家和工程师提供了许多新的机会和挑战。为了使用这些机会和处理相关的挑战以实现需求，需要新的模型和理论。

这篇综述文章，讨论了自适应软件背后的基本学科，并提出了适应的分类。where、when、what、why、who、how这些问题形成了分类的基本。基于与自适应软件相关的大量学科和一些选择的研究项目，展示了一个landscape。比较landscape的不同观点，提出了识别gaps差距的一个框架。如，self-protecting属性需要做更多的工作以提供更安全的软件系统。对在线分布系统的各种威胁是解决该问题的驱动力（推动力）。适应过程也需要被改善从而更高效的适应软件系统。

landscape也帮助在emerging新兴得研究领域定位将来的挑战。这些挑战被分成四类：self-*属性、适应过程、工程问题和交互。这些分类基于前面章节讨论过的自适应软件的基本原则。这些挑战已与相关讨论和概念相联系。