14、创建全面的面向代理方法学：利用方法工程和OPEN元模型

创建全面的面向代理方法学：利用方法工程和OPEN元模型

1. 引言

在软件开发领域，单一的面向代理方法学往往适用于特定场景。例如，有些方法学是为特定领域或特定生命周期阶段而设计的。然而，很多用户会错误地认为一种方法学能普遍适用，这可能导致“方法学失败”，使软件开发组织拒绝采用方法学。

实际上，寻找一种适用于所有情况的通用方法学是不现实的。为了满足不同软件开发人员的需求，情境化方法工程（SME）应运而生。它通过分离概念化的方法片段来建模方法学过程和产品，这些片段就像方法学的“构建块”，可以组合成适合各种情况的专门方法学。

2. 情境化方法工程（SME）

SME认识到开发适用于所有情况的全面方法学是不切实际的。它将方法学的过程和产品分解为概念化的方法片段，这些片段是方法学的连贯部分。例如，识别代理类型的特定技术或在AUML中使用序列图的方法就是方法片段的例子。

方法学家负责创建方法片段并将其存储在存储库中，同时提供构建指南。用户（通常是内部方法工程师）使用这些构建指南和存储库内容来创建适合特定项目或上下文的“个性化开发方法学”。

理想情况下，SME存储库中的元素应符合元模型所描述的概念集。元模型定义了允许的方法片段的规则。例如，元模型中可能有一个名为“任务”的实体，它描述了所有任务的特征和规则。从这个“任务”概念可以实例化出许多不同类型的任务，如创建类图的任务、识别用例的任务等。

以下是SME的主要参与者和流程：
| 参与者 | 职责 |
| ---- | ---- |
| 方法学家 | 创建方法片段、元模型和构建指南 |
| 用户（内部方法工程师） | 使用构建指南和存储库内容创建个性化方法学 |

mermaid图展示SME流程：

graph LR
    A[方法学家] --> B[方法片段存储库]
    A --> C[构建指南]
    B --> D[用户（内部方法工程师）]
    C --> D
    D --> E[个性化开发方法学]

3. 方法工程框架：OPEN

考虑到未来的商业应用，选择一个具有元模型和大量方法片段目录的方法学框架很重要。这里使用的是面向对象的过程、环境和符号（OPEN）。

OPEN元模型包含许多通过面向对象类建模的概念实体，通常使用UML符号描述。与创建面向代理方法学标准相关的概念主要有任务、技术和工作产品。这些元类可以实例化出许多实例，并存储在OPEN存储库中。

OPEN元模型定义了以下主要的高级类：
- 工作产品 ：开发过程中产生、使用或修改的有价值的东西，包括外部提供的现有工件。
- 生产者 ：负责创建、评估、迭代和维护工作产品的实体，可以是人、软件工具或硬件。
- 工作单元 ：由生产者执行的功能内聚的操作，包括活动、任务和技术。活动和任务描述了需要完成的工作，而技术则说明了如何完成工作。
- 语言 ：用于记录工作产品的媒介，如自然语言、UML、Java。
- 阶段 ：软件开发生命周期中被识别和管理的时间段或某个成就被认可的时间点。

4. 方法片段选择

创建了OPEN方法片段存储库后，方法工程（或SME）通过从该存储库中选择合适的方法片段，并使用提供的指南来构建特定于站点或项目的方法学。这些指南基于道义矩阵的概念，为选择特定片段提供建议。

道义矩阵是一个二维矩阵，代表OPEN中每对方法片段之间可能或可能的关系。它用于链接活动和任务、任务和技术、生产者和任务、任务和工作产品、生产者和工作产品以及工作产品和语言。矩阵中的实际值会根据项目大小、组织文化、应用领域以及开发团队的技能和偏好等因素而变化。目前这些值是手动评估的，但未来有望得到工具支持。

例如，使用OPEN任务“评估质量”来帮助完成活动“验证和确认（V&V）”的可能性值可能被评估为“推荐”。道义矩阵完成后，可为方法片段的选择提供指导。对于特定项目，通常使用二进制值，但随着组织的成熟，可以使用更广泛的道义值。

5. 使用OPEN构建方法学

可以通过自上而下或自下而上的方式构建过程，这里以自上而下的方式为例。首先确定一些活动，这些活动描述了高层次的“待办工作”，并将它们连接起来形成特定于问题或组织的OPEN过程架构。过程本身体现在这些活动之间的工作流中。

在OPEN的合同驱动生命周期模型中，活动之间的转换只有在当前活动的后置条件完成且下一个活动的前置条件满足时才允许。这些合同由过程工程师创建，包括测试标准、可交付成果、质量标准等。

OPEN活动是对需要完成的工作的粗略描述，活动对象通过前后链接形成过程。调度来自规划活动和任务，结合项目管理元素。OPEN任务则更详细，提供项目管理支持，是可以进行项目管理并产生可交付成果的最小工作单元。

此外，让业务文化适应特定方法学并不是明智的商业决策，重要的是方法学要适合业务。

以下是使用OPEN构建方法学的步骤：
1. 确定高层次的活动。
2. 连接活动形成过程架构。
3. 定义活动之间的转换条件（合同）。
4. 根据活动确定任务。
5. 为任务选择合适的技术。

创建全面的面向代理方法学：利用方法工程和OPEN元模型

6. 对代理的支持

最初，OPEN是为面向对象的系统开发而设计的，但近年来，已经开始开发适用于面向代理系统的方法片段。通过对现有面向代理方法学（如Tropos、MASE、Gaia、Prometheus等）的分析，确定了哪些方法片段已经在非代理的OPEN中得到支持，哪些需要添加到存储库中。

在分析过程中，仅在Tropos的情况下需要添加一个新活动，即早期需求工程。同时，还确定了大量新任务、子任务、技术和工作产品。不过，目前这些新方法片段的整合和合理化工作仍在进行中，是一个正在进行的研究项目（2004 - 2006）的主题。

以下是部分分析过的面向代理方法学及其相关情况：
| 方法学 | 新增活动 | 新增任务及子任务 | 新增技术 | 新增工作产品 |
| ---- | ---- | ---- | ---- | ---- |
| Tropos | 早期需求工程 | 较多 | 较多 | 较多 |
| MASE | 无 | 部分 | 部分 | 部分 |
| Gaia | 无 | 部分 | 部分 | 部分 |
| Prometheus | 无 | 部分 | 部分 | 部分 |

mermaid图展示代理方法学分析与OPEN整合流程：

graph LR
    A[Tropos等AO方法学] --> B[分析方法片段]
    B --> C{是否已有支持}
    C -->|是| D[使用现有OPEN支持]
    C -->|否| E[添加到OPEN存储库]
    E --> F[整合与合理化]
    D --> F
    F --> G[扩展后的OPEN]

7. 案例研究

在这个案例研究中，将构建一个类似于Prometheus的方法学，但弥补其一些不足，特别是考虑早期需求工程，如Tropos中所描述的那样。同时，开发者倾向于按照Gaia中倡导的责任和权限来开发代理。

Prometheus遵循RUP方法，有系统规范、架构设计、详细设计等阶段，还隐含了一个构建阶段。在OPEN中，这些阶段最好建模为活动。基于Prometheus和Tropos的早期需求工程，整体软件开发生命周期模型是强线性的，迭代发生在OPEN活动内部。

对于每个活动，可以确定相应的任务，再为每个任务确定合适的技术。例如，在一个链接任务和技术的矩阵中，可以看到一些技术适用于多个任务，一个任务也可能受到多个技术的影响，呈现多对多的关系。同时，工作产品也可以与各种任务相关联，通过引入Tropos和OPEN预代理存储库中的新方法片段，有效地扩展了Prometheus。

以下是案例研究中生命周期的主要活动：
1. 早期需求工程
2. 系统规范
3. 架构设计
4. 详细设计
5. 实现

8. 面向代理方法学的未来

使用情境化方法工程是实现团结、支持创新并创建行业可接受的方法学方法的有效途径。由于已经有一个基于SME的行业认可的方法片段存储库OPEN，因此建议将OPEN作为这一发展的初始框架。

随着对更多面向代理方法学（如BDI模型、PASSI、ADELFE、INGENIAS、MESSAGE、RAP等）的分析，OPEN存储库将不断得到增强。同时，将对来自不同面向代理方法学的相似方法片段进行合理化，并更好地与OPEN的面向对象方法片段集成。这将通过研究近年来发布的各种分类框架来促进。此外，还将利用TAO的概念建模工作来为扩展后的OPEN存储库和元模型提供严谨的学术理论基础。

方法学测试是确保方法学“产品”质量的必要部分，特别是对于广泛的行业采用而言。使用内部工具支持，目标是评估新兴的（代理）OPEN存储库在工业环境中的表现，可能采用行动研究方法来收集和分析定性结果。

未来还可以开展一些社区工作，例如对不同方法学进行比较，不仅在理论上，还在实际测试示例和工业环境中进行比较，这有助于更好地理解哪些方法有效，哪些不太成功，从而帮助研究人员确定最有成果的研究领域。最终，各种面向代理方法学团队的努力，结合方法工程技术，将有助于整合面向代理方法学社区的贡献，推动商业软件系统的更好开发。

以下是未来OPEN存储库扩展与整合的计划：
1. 持续分析新的面向代理方法学。
2. 整合和合理化不同方法学的相似片段。
3. 与OPEN的面向对象片段更好地集成。
4. 利用分类框架和概念建模工作提供理论支持。
5. 进行方法学测试和评估。