彭鑫陈碧欢赵文耘复旦大学需求驱动的软件自适应方法关键词：软件需求自适应考结构（如图1所示）在自适应软件研究和实践中得到了广泛应用。
按照这一参考结构，每一个具备自适应能力的软件实体都具有一个称为MAPE-K 的控制环路。
其中，监控(monitor环节负责侦测上下文环境及系统自身的事件，发现可能导致自适应调整的变化，分析(analyze环节负责分析变化对于需求及相关约束的影响，规划(plan环节负责规划能够适应变化的自适应调整方案，执行(execute环节负责执行规划的调整方案，知识(know-ledge 则表示完成以上各项任务所需的知识。
自适应软件与自治计算目前，以网构软件为代表的新形态网络化软件系统逐渐成为主流。
同时，普适计算和社会计算的兴起促使软件与物理世界和社会环境进一步融合。
这些都使得软件系统越来越多地运行在复杂、开放并且动态变化的网络环境、物理环境和社会环境之中，导致软件的运行时行为经常偏离系统的需求规约或处于非优化的运行状态。
因此，自适应逐渐成为许多软件系统必备的能力。
具备自适应能力的软件系统能够在运行时根据上下文环境和需求的变化动态地调整自身的结构和行为。
通过运行时的自适应调整，软件系统可以实现一系列重要的运行时特性，包括保障可靠性和鲁棒性、提高能源利用效率、实现失效的自动恢复、动态配置和定制以及动态自优化等[1]。
软件系统的自适应是一种典型的自治管理能力（包括自配置、自优化、自治愈和自保护四个方面[2]）。
IBM提出的自治元素参图1IBM 提出的自治元素参考结构[2]需求反射与运行时需求模型传统的软件系统（即非自适应系统）的规格说明建立在对于需求和系统上下文环境充分理解的基础上。
例如，一个救护车系统的需求规格说明及体系结构设计往往建立在一系列涉众需求和上下文环境的假设基础上，例如涉众的质量偏好、系统的峰值和平均请求量、可用的救护车资源、网络通信状况等。
在这些因素相对稳定且能够被充分理解的情况下，软件开发者可以在开发阶段通过权衡决策确定软件规格说明，并开发相应的软件解决方案。
然而，网络化软件系统面临的运行时环境往往具有很大的不确定性并处于持续变化中。
这就使得开发者关于系统需求和设计的静态决策无法适应动态变化且不确定的运行时环境。
而另一方面，系统需求中往往包含一些在任何情况下都应当满足的关键性目标，同时包含一些可以适当放宽的非关键性目标，从而为系统提供了运行时动态调整所需的灵活性[1]。
例如，按照传统的开发过程，救护车系统的需求规格说明需要对上下文环境做出假设（如每分钟呼救请求在10个以内，救护车与调度中心的网络通信一直保持畅通等），同时明确相关的质量要求（如调度中心对于救护车导航请求的响应时间在5秒之内，导航精度在10米范围内等）。
然而，在实际运行过程中，某些突发事件可能会造成短时间内救护车的请求数量激增，从而导致调度系统无法及时响应调度和导航请求。
此时，适当放宽导航精度要求（如50米范围内）从而确保更加关键的响应时间需求（如改为采用精度较低但效率更高的导航方式）是一种合理的选择。
因此，需求感知应成为自适应软件系统的一种基本特性，即系统能够在运行时感知自身的需求并根据需要进行调整。
自适应系统的实现一般都依赖于不同层次上的反射(reflection能力，即系统在运行时观察并感知自身结构和行为的能力。
基于体系结构的软件自适应方法（例如Rainbow [3]）以及基于体系结构的反射式中间件[4]提供了体系结构级的反射能力，使得系统可以动态监控系统的运行时体系结构及行为，并在必要时进行调整。
与之相似，需求感知系统需要具备需求层面上的反射能力，即系统维护需求模型的运行时表示，并使其与运行中的系统保持双向的因果关联。
这种运行时需求模型应当支持需求的自省(introspec-tion ，即运行时需求实体能够提供自身的信息，从而允许系统对运行时需求进行推理[5]。
需求目标模型与目标推理为了实现需求的动态评价和推理，运行时需求模型应当支持一系列丰富的运行时分析能力，包括涉众目标、软件的功能和非功能性需求、候选方案、领域假设、场景、风险和冲突等[5]。
鉴于需求目标模型的表达能力和推理能力，一些研究工作已将该模型应用于运行时需求模型的表示、推理和自适应方案规划。
目标模型目标模型描述了涉众的需求及其精化和依赖关系，同时捕捉了满足系统高层目标的多种候选方案以及相应的质量关注。
目前比较常用的目标建模主要包括基于与/或(AND/OR分解[6]、基于i*框架[7]和基于KAOS 框架[8]等方法。
这些方法有不同的关注点和侧重点：基于AND/OR分解的目标建模主要关注于目标精化，面向主体的建模框架i*主要关注于社会性系统的分析建模，KAOS 框架主要关注于目标的冲突建模、操作化以及责任分配。
在目标模型中，功能性需求用硬目标来建模，它的满足性是确定的，即满足或不满足；而非功能性需求用软目标来建摸，它的满足程度并没有一个明确的标准，即软件系统在一定程度上满足或者不满足需求。
图2是一个基于i*框架的救护车系统的目标模型。
其中，“救护车调度”是一个硬目标，“导航精度”是一个软目标。
目标可以通过AND 分解和OR 分解持续精化，直至得到软件、硬件或者人可直接完成的任务。
其中，OR 分解刻画了满足系统目标的多种候选方案。
例如，图2中的“目的地导航”可以被OR 分解为“GSM 导航”和“GPS 导航”，意味着目的地导航可以通过GSM 或GPS 实现。
除了分解关系，目标之间还存在相互影响的关系，例如一个目标的不同候选方案（如OR 分解子目标或任务）往往对相关软目标有着不同的影响，从而支持不同的质量偏好。
目标之间的影响可以通过贡献度链接Make(++, Help(+, Hurt(-和Break(--来表示，其含义是一个目标的满足对于另一个目标的满足程度起到正面或负面的影响。
Make/Help表示一个目标的满足图2救护车系统目标模型将使另一个目标完全满足/部分满足；Break/Hurt表示一个目标的满足将使另一个目标完全不满足/部分不满足。
此外，还可以通过在Help 和Hurt 链接上附加一个(0, 1 区间的值来定量地表示部分满足和部分不满足的程度。
一般而言，OR 分解的子目标对同一个软目标往往有不同的贡献度链接。
例如，“GPS 导航”相对于“GSM 导航”而言导航精度更高，因此“GPS 导航”的满足使得“导航精度”部分满足（Help 链接或者+0.8链接），而“GSM 导航”的满足使得“导航精度”部分不满足（Hurt 链接或者-0.7链接）。
目标推理目标推理是根据AND/OR分解和贡献度链接的语义以及期望的一组目标的满足程度，通过标签传递算法得到各个目标的满足程度[9,10]。
目标推理根据贡献度链接的定性或者定量表示方法，分为定性推理和定量推理；根据标签传递的方向，分为自顶向下推理和自底向上推理。
例如，给定“安排合适的救护车”、“GSM 导航”和“自动更新”的满足程度都为1.0（完全满足），那么通过自底向上推理得到“目的地导航”、“救护车位置更新”和“救护车调度”的满足程度都为1.0（完全满足）；给定“紧急电话接听”的满足程度为1.0（完全满足），那么通过自顶向下推理得到“记录紧急事故信息”、“判断紧急电话是否重复”和“报告新事故”的满足程度都为1.0（完全满足）。
由于目标模型建模了满足系统高层目标的多种候选实现方案，而不同的实现方案往往对不同的非功能需求有不同的质量关注，因此，不同的候选方案对多个非功能性需求的综合贡献度的度量值（即多个非功能性需求的满足程度的权重和）成为运行时目标推理的衡量标准。
例如，在救护车请求数量激增的情况下，“响应时间”和“位置精度”比“导航精度”和“开销”有更高的偏好值。
由于“GSM 导航”和“人工更新”分别对“响应时间”和“位置精度”有Help 贡献度链接，因此选取它们分别作为实现“目的地导航”和“救护车位置更新”的方案。
自适应需求分析方法上下文环境的不确定性和系统需求本身的动态性使得自适应系统的需求往往包含一定程度的不确定性或者不完整性[1]。
自适应需求的分析和规约方法应当能够处理这种上下文环境的不确定性以及由此导致的系统行为的不完整性，而且可以支持需求的运行时动态演化。
运行时的需求自适应要求所使用的需求模型和描述语言支持动态调整，例如需求和约束能够在运行时动态放宽或加强。
为此，文献[11]提出了一种需求语言RELAX 来帮助分析和识别自适应系统中的不变(invariant需求和可变(non-invariant 需求。
其中，不变需求表示必须严格满足的关键性需求，而可变需求则表示可以在运行时有所放宽的需求。
为了支持需求的动态调整，RELAX 定义了一组用于需求规约的RELAX 操作，例如SHALL （表示必须被满足）、AFTER （表示必须在某个事件发生之后被满足）、AS EARLY AS POSSIBLE （表示需要尽早满足某个条件）、AS CLOSE AS POSSIBLE TO（表示需要尽可能达到或接近某个数量或频率）等；RELAX 定义了4个属性并关联到每个可变需求来描述环境的不确定性：ENV （定义了环境中的上下文特性）、MON （定义了环境中可观察到的信息）、REL （定义了如何通过MON 属性来推导出ENV 属性）和DEP （定义了可变需求被放松之后对其他需求的影响程度）；RELAX 利用了模糊分支时序逻辑来进行形式化规约。
以智能办公室为例[11]，爱丽丝(Alice的手机、平板电脑和台式电脑等设备会在爱丽丝走进办公室之后开始进行客户联系方式同步，此后每隔30分钟进行一次同步。
这个需求按照传统的需求分析方法可规约为R1。
由于网络延迟或者设备故障等环境的不确定性，R1并不能严格地被满足，同时需求分析师也难以枚举所有可能的系统自适应行为。
而这个需求按照RELAX 可规约为R1’，其中描述了与该项需求相关的上下文环境特性，即爱丽丝的位置和同步间隔；定义了如何通过监控获得这些特性，即通过运动传感器得到爱丽丝的位置和通过网络传感器得到同步间隔。
因此，只要满足需求中声明的灵活性，任何可能的自适应行为都是允许的。
为了提高运行时自适应所需的灵活性，自适应需求应当明确业务需求、领域假设、质量约束等可以被放松和调整的限度。
例如，一些关键性需求应当一直满足或具有比较高的满足概率，而其他非关键性需求的满足概率可以较低。
为此，文献[12]提出了感知需求(awareness require-ments 的概念，并提供了典型的类型和模式，以便于进行形式化规约。
感知需求刻画了业务需求、感知需求本身、领域假设或者质量约束在运行时的满足状况。
以救护车系统为例[12]，当接线员收到一个紧急电话后，首先要记录紧急事故的信息，然后判断紧急电话是否重复，如果不重复则报告一个新事故，最后调度救护车到达事故现场。