97、面向方面与模型驱动：管理动态可变性的新途径-优快云博客

本文链接：https://blog.youkuaiyun.com/peach/article/details/149520468

面向方面与模型驱动：管理动态可变性的新途径

1. 自适应系统的挑战

在当今社会的基础设施中，能够自动适应环境变化的上下文感知软件系统正发挥着越来越重要的作用。这些自适应系统的需求广泛存在于各个应用领域，从危机管理（如灾难和电力管理）到娱乐和商业应用（如移动互动游戏、旅游引导和商业合作）。

然而，构建和执行自适应系统面临着多项挑战。首先，自适应软件系统通常部署在由异构计算设备组成的分布式平台上，目标平台的范围从各种规模的计算机网络到小型便携式设备（如手机或 PDA）。而且，系统由具有可变配置的组件组成，这些组件之间可能存在依赖关系，在适应过程中需要解决这些关系，这进一步增加了复杂性。因此，在开发过程中需要更好的技术来控制自适应软件的复杂性。

另一个挑战是组合爆炸问题。自适应系统常常通过定义多个变化点来开发，这些变化点代表软件中可以选择不同实现变体以导出最终系统配置的位置。解决这些变化点会导致可能的系统配置数量呈指数级增长。由于这些系统通常面临严格的响应时间要求，要在大量配置中推理出当前上下文的最佳配置变得十分耗时，这成为一个重大问题。

2. 现有解决原则

在软件工程中，抽象是应对不断增加的问题范围和复杂性的最基本原则。在模型驱动工程（MDE）中，使用抽象和不同层次之间的转换来管理复杂性。例如，模型驱动架构（MDA）指定了三个抽象层次：计算独立模型（CIM）描述环境并指定需求；平台独立模型（PIM）描述不随平台变化的部分；平台特定模型（PSM）包含与平台相关部分的描述。

另一个常用于处理复杂性的原则是关注点分离。面向方面建模（AOM）方法提供了高级的关注点分离机制，例如封装横切特征和组合横切特征以形成集成模型的机制。

3. 新的解决方法

为了解决自适应系统构建和执行中的挑战，提出了一种将面向方面和模型驱动技术相结合的新方法：
- 面向方面建模技术 ：用于解决变体组合爆炸的问题。AOM 允许将不同的变化点封装到与系统功能基础模型分离的方面中。然后，将不同的方面组合到基础模型中以获得不同的配置。这种方法使我们能够基于有限且线性增长的方面进行推理，从而避免了其他方法中出现的组合爆炸问题。
- 模型驱动技术 ：用于自动化和改进创建使运行中的系统从一个配置演化到另一个配置所需的重新配置脚本。目前，自适应中间件的适应逻辑依赖于执行低级的手写重新配置脚本，这些脚本指定了所有可能的配置之间的转换。由于这些脚本决定了可能对安全至关重要的系统在运行时的操作方式，因此需要进行严格的验证。这个过程既耗时又容易出错。通过应用模型驱动技术，可以通过分析系统的不同变体来生成这些脚本。此外，应用模型驱动原则在运行时提供模型，以更抽象的级别管理适应的执行。这使得我们能够提供针对适应任务进行微调的抽象，降低复杂性，并且由于运行时模型是以平台独立模型的形式提供的，因此该方法适用于许多执行平台。

4. 动态服务发现示例

以移动应用的动态服务发现为例，移动应用需要根据其操作上下文的变化进行动态调整。移动设备（如 PDA、手机或笔记本电脑）能够根据用户的偏好检测并通知用户有关新的可用服务。然而，移动自适应应用预计要支持与用户偏好和操作上下文属性相关的意外变体，这些变体在执行过程中不可避免地会出现。此外，已经提出了不同的服务发现协议（SDP）设计，因此在设计时可能无法完全指定用户偏好、与上下文相关的属性或在给定上下文执行中用于广告服务的协议。

Flores 等人提出了一种解决方案，以克服异构服务发现协议带来的挑战。该解决方案提供了一个通用的核心架构，各个发现协议都遵循该架构。利用最终架构，可以实现发现协议并将其动态插入到中间件平台中。通过这个解决方案，服务发现交互平台可以承担以下角色：
- 用户代理（UA） ：代表客户端发现服务。
- 服务代理（SA） ：宣传服务。
- 目录代理（DA） ：支持一个服务目录，SA 在其中注册其服务，UA 发送其服务请求。DA 还会宣布请求与广告的正匹配。

下面是服务发现交互平台角色的表格总结：
| 角色 | 功能 |
| ---- | ---- |
| 用户代理（UA） | 代表客户端发现服务 |
| 服务代理（SA） | 宣传服务 |
| 目录代理（DA） | 支持服务目录，注册服务和接收请求，宣布匹配结果 |

其流程可以用以下 mermaid 流程图表示：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(用户偏好):::process --> B(移动设备):::process
    B --> C{服务发现}:::process
    C -->|UA| D(发现服务):::process
    C -->|SA| E(宣传服务):::process
    C -->|DA| F(服务目录):::process
    D --> F
    E --> F
    F --> G(匹配结果):::process
    G --> B

通过这个示例可以看出，在实际的移动应用场景中，动态服务发现面临着诸多不确定性和复杂性，而结合面向方面和模型驱动的技术可以更好地应对这些问题，实现系统的自适应和高效运行。

面向方面与模型驱动：管理动态可变性的新途径

5. 面向方面模型编织的优势与对比

在软件领域，有一种面向方面的模型编织方法具有独特的优势。它能够在特定的（动态）条件下，将方面静态地编织到给定的基础系统中。这些条件具有两个特点：一是在运行时之前无法评估；二是评估所需的信息不能从受方面影响的特定程序元素的局部上下文中收集。

与现有的模型驱动开发（MDD）方法相比，当前的 MDD 方法无法处理这样的约束。如果开发者使用现有的 MDD 方法，可能会面临严重的后果，这与 MDD “在更高抽象级别开发软件” 的初衷相冲突。

为了克服这个问题，采用了连接点指定图（JPDDs）。JPDDs 是一种在面向方面软件开发（AOSD）中表示连接点选择的方式，特别是为表示动态（选择）约束提供了抽象。通过这些抽象，这种模型编织方法将面向方面研究的重大进展引入到了 MDD 领域。开发者能够以局部化和声明式的方式指定连接点选择的标准，从而无需手动识别程序中所有需要收集相关信息的点，以便在程序的后续点中在动态选择约束中进行评估。

以下是现有方法与本文提出方法的对比表格：
| 方法 | 能否处理动态条件 | 是否需手动收集信息 | 能否自动查找连接点 | 对模型符号一致性要求 |
| ---- | ---- | ---- | ---- | ---- |
| 现有 MDD 方法 | 否 | 是 | 否 | 高 |
| 本文提出方法 | 是 | 否 | 是 | 低 |

与其他相关方法相比，这种方法也有明显的不同：
- 手动实例化方面模型 ：像 Role Models 和 Kompose 要求在将方面模型与基础模型实际合并之前，为每个连接点手动实例化方面模型。而本文提出的方法允许开发者声明方面应生效的所有连接点的相关必要特征，然后让编织器自动在基础模型中找到满足这些特征的所有点。
- 连接点选择类型 ：MATA 和 Motorola WEAVR 允许基于状态的连接点选择，与本文方法类似，它们改进了许多当前可用的面向方面编程语言，并允许指定大量的高级方面。然而，本文提出的方法更进一步，允许基于控制流和数据流的连接点选择。虽然基于控制流的连接点选择可以借助 MATA 和 WEAVR 提供的基于状态的连接点选择方法进行模拟，但基于数据流的连接点选择实际上是不可能的，需要额外的手段才能实现。
- 模型符号一致性 ：使用 MATA、xWeave 或 KerTheme 进行模型转换时，所有模型（即基础模型、建议模型和切入点模型）必须使用相同的符号（如序列图或状态机）进行指定。而在本文的方法中，编织器可以将用于指定连接点选择的概念（以及稍后用于指定方面增强的概念）映射到用于指定基础模型的概念上。因此，开发者可以始终使用在概念上最适合表达其意图的符号。

下面是几种方法在不同特性上的对比 mermaid 流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(现有方法):::process --> B(手动实例化方面模型):::process
    A --> C(仅支持状态连接点选择):::process
    A --> D(模型符号需一致):::process
    E(本文方法):::process --> F(自动查找连接点):::process
    E --> G(支持多种连接点选择):::process
    E --> H(模型符号灵活):::process

6. 方法的特点与局限性

这种结合 JPDDs 和新型模型编织器的方法提高了抽象级别，符合 MDD 的精神，旨在提供更抽象、更 “面向问题” 的软件开发方式。它隐藏了在基础系统中编织动态选择约束的具体细节，相比当前需要软件开发人员手动完成此操作的 MDD 方法，是一个显著的改进。这也是面向方面编织的一个特点，使其与传统的模型转换和模型组合方式区分开来。

不过，该方法也有局限性。如果所有信息在方面需要生效的点处都是局部可用的，那么与使用传统 MDD 方法指定的模型转换相比，本文提出方法的优势最小。此外，对于本文指出的问题，从基础程序的不同位置收集的信息越多，问题就越大。

一种可能的解决方法是重构给定的基础系统，使所有相关信息集中在一个地方，然后使用传统的模型转换技术进行方面修改。但通常这种重构会导致其他信息的分散，可能会将问题转移到其他位置，这是 “主导分解的暴政” 现象的直接后果。

在面向方面软件开发领域，已经进行了大量研究，重点是提供表达动态选择约束的合适抽象。众多的选择抽象已经被提出，可见这个领域的研究活动非常活跃，也表明这是一个高度相关的问题。可以预期，动态选择约束的抽象也将对 MDD 领域产生重大影响。

综上所述，无论是面向方面与模型驱动结合管理动态可变性，还是面向方面的模型编织方法，都在软件领域为解决复杂问题提供了新的思路和途径，但同时也需要根据具体情况权衡其优势和局限性，以选择最合适的方法来开发软件。