PARADIGM Suite: Just-In-Time Dynamic Adaptation

• PARADIGM Suite is a modeling approach that employs the Paradigm coordination language and the reusable McPal component to facilitate continuous, on-the-fly evolution of dynamic systems.
• It treats migration as constraint orchestration, dynamically managing phases, traps, and consistency rules to enable just-in-time, coordinated changes without stopping execution.
• The suite is demonstrated through examples like critical section management and pipeline architecture, proving its capability to handle both foreseen and unforeseen evolutionary scenarios.

PARADIGM Suite is a modeling and evolution approach centered on the Paradigm coordination language and the special reusable component McPal, with UML-like visualizations used to support explanation of migration trajectories. In this setting, dynamic adaptation is treated as constraint orchestration: a running system is not stopped and rewritten wholesale, but is guided by changing which parts of component behavior are constrained, which traps have been entered, and which phase transitions are enabled. The objective is to describe, execute, and evolve dynamic systems without stopping execution while preserving behavioral coherence, including forms of evolution that were not fully specified in advance (0811.3492).

1. Conceptual basis: Paradigm, coordination, and dynamic consistency

In the terminology of the paper, Paradigm is the coordination modeling language, whereas the PARADIGM Suite denotes the broader modeling and evolution approach that combines Paradigm models, McPal, and UML-like visualizations. A Paradigm model organizes a system into detailed processes represented by state-transition diagrams, phases that constrain those processes, traps inside phases, global processes induced by partitions of phases and traps, and consistency rules that synchronize detailed behavior with protocol behavior. This yields a multi-level account of system dynamics rather than a single flat transition system.

The coordination problem is explicitly stratified. For stable, foreseen collaboration, Paradigm is said to guarantee coherence among four kinds of dynamics, called type A–D: A denotes local internal behavior of a component, B role behavior at a port, C link behavior such as send/receive and trap/phase information exchange, and D protocol behavior at the collaboration level. The suite extends this basis to evolution by adding McPal, so that migration itself is handled within the same formal coordination framework rather than as an external reconfiguration step.

A central claim is that evolution can be handled just-in-time and on-the-fly. The paper characterizes this through dynamic consistency problems T1–T7: ordinary Paradigm coordination addresses the stable cases T1–T3, while McPal extends the framework so that migration-related consistency problems T4–T7 are also handled coherently. This suggests that the suite is not only a notation for coordinated behavior, but also a formalism for coordinated change.

2. Formal model: processes, phases, traps, and consistency rules

The appendix gives the formal basis of the suite in terms of state-transition structure. A process or STD $Z$ is defined as

$Z = (ST, AC, TS)$

where $ST$ is a non-empty set of states, $AC$ is a set of actions, and $TS \subseteq ST \times AC \times ST$ is the transition relation. A transition $(x,a,x') \in TS$ is written as

$x \xrightarrow{a} x'.$

A phase $S$ of $Z$ is itself an STD,

$S = (st, ac, ts),$

with $Z = (ST, AC, TS)$0, $Z = (ST, AC, TS)$1, and

$Z = (ST, AC, TS)$2

Phases therefore act as behavioral restrictions: they select states and transitions that are currently permitted.

A trap $Z = (ST, AC, TS)$3 of a phase $Z = (ST, AC, TS)$4 is a nonempty set of states $Z = (ST, AC, TS)$5 such that

$Z = (ST, AC, TS)$6

If $Z = (ST, AC, TS)$7, the trap is the trivial trap, denoted triv or triv(S). The trap mechanism is fundamental because it records committed subregions of a phase that cannot be exited while that phase remains active.

For phases $Z = (ST, AC, TS)$8 and $Z = (ST, AC, TS)$9, a trap $ST$0 of $ST$1 is connecting from $ST$2 to $ST$3 if

$ST$4

Then $ST$5 is a phase change, written

$ST$6

A partition is a set $ST$7 with triv(S_i) ∈ T_i for each $ST$8; it is covering if

$ST$9

and

$AC$0

The paper remarks that covering partitions are standard for foreseen coordination, but are not appropriate for unforeseen evolution because later-added dynamics must not be excluded in advance (0811.3492).

A global process $AC$1 over a partition $AC$2 is an STD whose states are phases, whose actions are traps, and whose transitions are phase changes. This is the formal bridge from constrained detailed behavior to protocol-level behavior. For a set of detailed processes $AC$3, the product of their state spaces is the Cartesian frame $AC$4. Over this structure, the suite defines consistency rules of the general form

$AC$5

The part before * is the detailed step, the part to the right is the protocol step, and the square-bracketed clause is the change clause. A rule can be applied only if the detailed transition is contained in every currently valid phase of the manager process and if the relevant connecting traps of the employees’ global processes have been entered. Coordination correctness is thus enforced by construction rather than checked post hoc.

3. McPal and just-in-time specified evolution

McPal, short for Managing changing Processes ad libitum, is described as a special reusable component incorporated into a Paradigm model to manage unforeseen evolution. It is not specific to one migration pattern. Instead, it functions as a reusable migration coordinator capable of extending constraints while execution continues, coordinating migration from old execution to new execution, and removing obsolete behavior and constraints once the new stable situation has been reached (0811.3492).

The suite emphasizes that no temporary quiescence is required. Execution is never halted. McPal keeps the system running “as-is” while a new set of constraints and orchestration rules is specified just-in-time (JIT), then coordinates the transition from the current coordination to the future coordination, and finally returns to a stand-by condition. The paper explicitly presents this as on-the-fly evolution.

The key mechanism is again constraint orchestration. In stable coordination, phases restrict detailed behavior and traps record committed regions that enable disciplined phase change. For evolution, McPal extends the same machinery by allowing the set of constraints and their orchestration to be modified during execution. A plausible implication is that PARADIGM Suite treats migration not as a separate engineering artifact layered atop the model, but as another coordinated behavior expressed in the same formal vocabulary as ordinary collaboration.

The paper also describes McPal in terms of control states. In the adaptation workflow it appears in states such as Observing, JITting, NewRuleSet, and StartMigr, later returning to Observing or stand-by after migration-specific rules have been removed. These states make explicit that the suite models not only the target architecture and the source architecture, but also the governance process by which migration rules are introduced and retired.

4. Adaptation workflow and visual modeling apparatus

The adaptation workflow begins from a stable Paradigm model executing under existing phases, traps, and consistency rules. McPal, in its Observing state, notices that the architecture or collaboration should change. In JITting, it specifies the future collaboration and the migration rules needed to reach it. In NewRuleSet, the rule set for the old stable situation is extended with migration-only rules and rules for the new stable situation. Migration then starts through StartMigr, after which McPal coordinates participant evolution stepwise through changes in constraints, phase changes, and trap-based commitments, until cleanup removes migration-specific rules and McPal returns to stand-by.

The principal modeling concepts used throughout this workflow are components, ports, links, collaborations, roles, processes/STDs, phases, traps, global processes, consistency rules, the manager/employee distinction, and protocols as orchestration. The manager/employee distinction is particularly important: a manager process performs detailed steps that trigger synchronized protocol-level changes in one or more employee processes.

The paper stresses the role of UML-like diagrams: composite structure diagrams, state-machine diagrams, and activity diagrams visually supplement migration. These visualizations are not presented as merely pedagogical add-ons. Rather, they make the migration trajectory and the active consistency constraints understandable during architectural change. This suggests that the PARADIGM Suite combines formal operational semantics with a visual modeling layer intended to preserve intelligibility during nontrivial reconfiguration.

A common misconception would be to interpret the suite as ordinary reconfiguration scripting. The paper instead frames adaptation as a coordinated transition between constrained behavioral regimes. The operative units are not only components and connections, but the admissible subbehaviors of components under current phases and the trap commitments that permit migration to proceed.

5. Critical section management as the stable-coordination exemplar

The first major example is a critical section management (CSM) problem in which a Scheduler manages three Worker processes competing for permission to enter a critical section (0811.3492). A worker process has detailed states Free, NCrit, Pre, Crit, and Post. Its behavior is constrained by three phases:

• OutCS: no permission to enter critical section
• Inspec: interrupted / inspecting phase
• InCS: permission granted, inside critical section

The example also uses four traps:

• triv for OutCS
• notyet and started for Inspec
• done for InCS

The intuition of these constraints is explicit. OutCS behaves as if Crit does not exist. InCS allows entering Crit, but only once, so Pre becomes unreachable. Inspec is an interrupted form in which a worker cannot continue as before. Trap started means a request for permission; notyet means no request yet; done means permission can be withdrawn. From these elements, the global process Worker(CSM) is derived as the worker’s role behavior at its port, while the detailed worker STD remains the internal behavior.

The protocol is given by concrete consistency rules:

$AC$9

These rules synchronize the scheduler’s detailed steps with workers’ phase changes. Rule (1) grants access to worker $AC$6 when the relevant request trap has been entered. Rule (2) withdraws permission from worker $AC$7 and advances inspection to the next worker. Rule (3) advances inspection when no request has been made. The example demonstrates the formal coordination mechanism in its stable form: the scheduler’s transitions, the workers’ constrained roles, and the traps that enable phase change all interact through uniform rule syntax.

This example matters because it establishes the suite’s base semantics before any architectural evolution occurs. Migration is introduced later, but the paper first shows that ordinary concurrency control can already be represented as a disciplined interaction among detailed processes, global processes, and constraint-triggered synchronization.

6. Migration from critical section solution to pipeline architecture

The second major example shows how the same machinery handles architectural transformation. The source architecture is the CSM arrangement with a scheduler and three workers. The target architecture is a pipeline of four processes with three producer-consumer collaborations: ProdCons1, ProdCons2, and ProdCons3. The corresponding target roles are: Unit1, Unit2, Unit3, and Unit4 (0811.3492).

A distinctive feature of the example is that the original scheduler process must become Unit3, identified as the only process without an employee role and therefore without a global process in the new arrangement. Migration is gradual: the old collaboration shrinks, the new collaborations grow, and the same underlying process is reused in a new architectural role. This is not simple role reassignment; it is a staged transformation of the collaboration structure itself.

The paper states that there are six possible migration trajectories, corresponding to the six permutations of which worker becomes available first, second, and last:

$AC$8

McPal coordinates these alternatives through a specific migration phase, identified in the figures as Migr1-2, and through a chain of JIT-specified states such as WhoFirst, W_i as U1, W_j as U2, Conf_{i,j,k}, and Content. The migration is therefore both nondeterministic at the architectural level and formally constrained at the coordination level.

This example illustrates several properties of the suite. Migration is modeled as coordination rather than as ad hoc reconfiguration. Constraint orchestration carries the system from the old architecture to the new one while maintaining consistency at every step. Originally unforeseen evolution is supported because the migration rules are specified just-in-time. The same formal mechanism covers the old stable situation, the migration phase, and the new stable situation. UML-like diagrams are used to make the migration path explicit.

A plausible implication is that the suite’s distinctive contribution lies less in any single reconfiguration operator than in its ability to treat architectural change as a first-class protocol, governed by the same phase/trap/global-process semantics as ordinary collaboration.

7. Significance and interpretive boundaries

The significance of PARADIGM Suite lies in its combination of formal, operational, and visual mechanisms for dynamic adaptation under continuous execution. The paper’s central claim is that evolution is just-in-time specified coordination conducted by McPal and realized through constraint orchestration, so that a system can evolve consistently and on-the-fly, including in cases of originally unforeseen evolution (0811.3492).

This positions the suite differently from approaches that require quiescence, external orchestration, or complete pre-specification of adaptation paths. In PARADIGM Suite, the same semantic machinery governs stable coordination and migration coordination. Phases and traps do not merely document constraints; they operationalize when and how behavior may continue, be restricted, or be redirected. Consistency rules do not merely describe synchronization; they enforce it across detailed and protocol levels.

The paper’s examples also delimit the scope of the contribution. The suite is presented through coordination models, a reusable migration component, and UML-like views, rather than as a general-purpose software platform or benchmark infrastructure. Its primary domain is dynamic system adaptation, especially where business rules, software structure, and collaboration architecture must co-evolve during execution. The critical-section and pipeline examples show that the method is intended for architecture-changing migration, not only for local state repair or parameter tuning.

In that sense, PARADIGM Suite can be understood as a formal approach to evolution under execution. Its defining idea is that change itself is a coordinated behavior that must satisfy explicit constraints, and that these constraints can be introduced, orchestrated, and retired without stopping the system being changed.