Taxonomie des opérateurs Caméléon

Version : v3 — 07/03/2026 Auteurs : O. Cugnon de Sévricourt · Léa (Recherche)

Principe de classification

Chaque opérateur est défini par une famille et zéro à trois attributs orthogonaux.

La famille est structurelle — elle découle de la topologie (ports, firing policy). Les attributs sont orthogonaux à la famille — ils décrivent le comportement au runtime.

Deux familles

Structurel

Contrôle de flux. Pas de logique métier, pas de transformation de données. La topologie dit tout — l'opérateur route, duplique, synchronise ou filtre.

Comportemental

Logique propre. Traitement de données, interaction, ou production de valeur.

Note terminologique — rapport à la littérature

La distinction Structurel / Comportemental est propre à Caméléon. Elle recouvre des distinctions analogues dans la littérature, sans leur être identique :

• Van der Aalst et al. (2003) distinguent routing constructs (places et
• transitions de contrôle dans les CPN) et activity nodes (transitions portant
• une logique métier). Notre Structurel correspond aux routing constructs, notre
• Comportemental aux activity nodes.

• BPMN (OMG, 2011) distingue gateways (contrôle de flux exclusif, parallèle,
• inclusif) et tasks (unités de travail). La correspondance est directe :
• Gateway ≈ Structurel, Task ≈ Comportemental.

• YAWL (van der Aalst & ter Hofstede, 2005) utilise les termes conditions
• et tasks, où les conditions sont des places de contrôle et les tasks portent
• la logique. Même structure conceptuelle.

Ce qui est original dans Caméléon : les attributs orthogonaux human et live n'ont pas d'équivalent direct dans ces formalismes. human rejoint partiellement le concept de human task dans YAWL et les resource patterns (Russell et al., 2006), mais avec une sémantique plus précise (bloquant + validation unique). live est une contribution originale — ancré dans les open nets (Lohmann et al., 2007) et les langages réactifs synchrones (Caspi et al., 1987), mais inexistant comme attribut d'opérateur dans YAWL, BPMN ou LangChain.

Ces écarts terminologiques sont à documenter explicitement dans le paper v2 — ils ne sont pas des faiblesses mais des contributions.

Références - van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B., & Barros, A.P. (2003). Workflow Patterns. Distributed and Parallel Databases, 14(3), 5–51. - van der Aalst, W.M.P. & ter Hofstede, A.H.M. (2005). YAWL: Yet Another Workflow Language. Information Systems, 30(4), 245–275. - Russell, N., ter Hofstede, A.H.M., van der Aalst, W.M.P., & Mulyar, N. (2006). Workflow Control-Flow Patterns: A Revised View. BPM Center Report BPM-06-22. - OMG (2011). Business Process Model and Notation (BPMN) 2.0. - Lohmann, N., Massuthe, P., & Wolf, K. (2007). Operating Guidelines for Finite-State Services. TACAS 2007, LNCS 4424. - Caspi, P. et al. (1987). Lustre: A Declarative Language for Programming Synchronous Systems. POPL 1987.

Trois attributs orthogonaux

Un opérateur sans attribut s'exécute automatiquement, sans config ni interaction. Les attributs sont cumulables — un opérateur peut être config + human. La présence de live dans une composition la rend ouverte (ADR-035).

Catalogue des opérateurs

Structurels

Comportementaux

Règle de tir par défaut

ANY + garde EMPTY : tire dès qu'au moins une entrée est NEW, à condition qu'aucune ne soit EMPTY.

Au premier passage, l'opérateur attend que toutes ses entrées aient reçu une donnée. Ensuite il devient réactif — tire dès qu'un input est rafraîchi (NEW), même si les autres sont OLD. C'était le comportement de l'implémentation C++/QT originale.

Les trois firing policies

Source : fire si toutes les sorties sont EMPTY. LiveSource : fire sur user_event() — transition d'environnement (ADR-035).

canFire() — Template Method sur l'opérateur

Le moteur appelle op.canFire(), point. La règle est portée par l'opérateur.

// Défaut ANY + garde EMPTY
const Operator = {
  canFire(inputStates, outputStates) {
    if (inputStates.some(s => s === "EMPTY")) return false;
    return inputStates.some(s => s === "NEW");
  }
};

// Overrides
Merge.canFire   = (ins) => ins.some(s => s === "NEW");  // XOR-join — EMPTY ignored
Barrier.canFire = (ins) => ins.every(s => s === "NEW");
Switch.canFire = (ins) => ins.in_data === "NEW" && ins.in_index === "NEW";
Gate.canFire   = (ins) => ins.in_data === "NEW" && ins.in_condition === "NEW";
Filter.canFire = (ins) => ins.in_data === "NEW";
Source.canFire = (ins, outs) => outs.every(s => s === "EMPTY");
// LiveSource : eop = user_event() — géré par le renderer (ADR-035)

Boucles

• Merge (ANY) est la pièce maîtresse — réinjecte un token dans la boucle
• Guard (COND, backlog) sort de la boucle quand une condition config est remplie
• Sécurité : max_loop_iterations dans la config pour détecter les boucles infinies

Modes d'exécution

Signature type

// Structurel — pas de config, pas d'attribut
{
  id:           "fork",
  family:       "structural",
  firingPolicy: "ANY",
  inputs:       [{ id: "in", type: "Any" }],
  outputs:      [{ id: "out_0", type: "Any" }, { id: "out_1", type: "Any" }],
  run(inputs) { return { out_0: inputs.in, out_1: inputs.in }; }
}

// Comportemental avec config
{
  id:           "processor_example",
  family:       "behavioral",
  attributes:   ["config"],
  inputs:       [{ id: "in_a", type: "DataString" }],
  outputs:      [{ id: "out_a", type: "DataString" }],
  run(inputs, { config }) {
    return { out_a: transform(inputs.in_a, config) };
  }
}

// Comportemental avec human
{
  id:           "human_input",
  family:       "behavioral",
  attributes:   ["human"],
  control:      "text_input_control",
  inputs:       [{ id: "in_context", type: "Any" }],
  outputs:      [{ id: "out_value", type: "DataString" }],
  run(inputs, { signal }) {
    return new Promise((resolve, reject) => {
      signal?.addEventListener("abort", () => reject(new Error("cancelled")))
    })
  }
}

// Comportemental avec live — ouvre la composition
{
  id:           "live_source",
  family:       "behavioral",
  attributes:   ["live"],
  control:      "live_input_control",
  inputs:       [],
  outputs:      [{ id: "out_data", type: "Any" }],
  run(inputs, { signal }) {
    return new Promise((resolve, reject) => {
      signal?.addEventListener("abort", () => reject(new Error("cancelled")))
    })
  }
}

Correspondance Workflow Patterns (van der Aalst et al.)

Source : Russell, N., ter Hofstede, A.H.M., van der Aalst, W.M.P., & Mulyar, N. (2006). Workflow Control-Flow Patterns: A Revised View. BPM Center Report BPM-06-22.

Légende

Groupe 1 — Basic Control Flow (WCP 1–5)

Groupe 2 — Advanced Branching and Synchronization (WCP 6–9)

Groupe 3 — Structural (WCP 10–11)

Groupe 4 — Multiple Instance (WCP 12–15)

WCP 12–15 forment le cluster MapReduce. Priorité haute pour les workflows IA.

Groupe 5 — State-Based (WCP 16–18)

Groupe 6 — Cancellation and Force Completion (WCP 19–24)

Groupe 7 — Advanced Cancellation (WCP 25–27)

Groupe 8 — Advanced Synchronization (WCP 28–36)

Groupe 9 — Structural (WCP 37–38)

Groupe 10 — Instance Patterns (WCP 39–43)

Récapitulatif

Couverture (natif + composable) : 19/43 — 44 %

Clusters manquants

Historique des décisions