Triple Graph Grammars (TGGs) are one formal approach to specifying and incrementally maintaining consistency between two related models (e.g., a platform-independent model and a platform-specific model) as either one changes. How does TGG's approach to incremental synchronization differ from simply re-running a full bidirectional transformation from scratch after every change, and what does a team give up by adopting a rule-based grammar formalism like this?

## What a TGG is Triple Graph Grammars (TGGs) are a formalism, originally developed in the graph-transformation research community and later adopted by tools such as Eclipse-based eMoflon, for specifying how two models relate to each other and for automatically deriving forward transformations, backward transformations, and incremental synchronization from a single declarative rule set—rather than hand-writing three separate mechanisms. ## The triple: source, target, correspondence The core idea is a 'triple' graph: alongside the source model graph and the target model graph, TGGs introduce an explicit third graph of correspondence nodes, each linking a specific piece of the source to the specific piece(s) of the target it produced or depends on. A TGG rule describes, all at once: - a small pattern of **source** elements; - a small pattern of **target** elements; - the **correspondence** elements connecting them. For example, a rule might say a source `Class` node corresponds to a target `Table` node via a `ClassTableLink` correspondence node, and each of the Class's Attribute children correspond to that Table's Column children via `AttributeColumnLink` nodes. A complete, consistent pair of models is one that can be built up entirely by applying such rules repeatedly, so the grammar defines exactly which source/target configurations are considered 'in sync' by construction. ## Why that makes synchronization incremental Because the correspondence graph explicitly records which source elements produced which target elements (unlike a plain function-based transformation that discards this provenance after running), a TGG engine can support genuinely incremental synchronization. Given a specific, localized edit to the source model (say, one new attribute added to one class), the engine: 1. looks up the correspondence links touching that class; 2. identifies which rule instances are affected; 3. applies only the additional rule matches needed to extend the target model and correspondence graph to cover the new attribute. It does not recompute the entire target model from scratch, nor does it need to diff a freshly regenerated target against the old one, because the correspondence graph already tells it exactly what's new. This incremental behavior is the main practical reason to reach for a TGG-based tool over a simpler batch bidirectional transformation: on large models (thousands of elements), full re-transformation-and-diff is expensive and its cost scales with total model size, while TGG incremental propagation's cost scales roughly with the size of the change, which matters enormously for continuous, high-frequency synchronization scenarios like a live model kept current against a codebase on every commit. ## Bidirectionality 'for free' TGGs also give bidirectionality 'for free' in a specific formal sense: because a rule declares a source pattern, a target pattern, and their correspondence together as one symmetric structure, the same rule set can be operated in three ways, without hand-authoring three separate mechanisms that could drift out of alignment with each other the way three independently-written functions might: - **forward** — derive target + correspondence from a given source; - **backward** — derive source + correspondence from a given target; - **as a consistency check** — verify an existing source/target/correspondence triple is a valid derivation. ## The cost The cost is substantial and specific to this formalism. - Every legal correspondence between source and target patterns has to be captured explicitly as a grammar rule before any of this works—there is no way to 'mostly define the mapping and handle exceptions ad hoc' the way a general-purpose scripting transformation allows. - A **rule set** for a nontrivial domain (e.g., a full UML-to-relational-schema mapping covering inheritance strategies, many-to-many associations, and constraints) can run to dozens of interacting rules, and authoring, testing, and debugging a rule set at that scale requires specialized graph-transformation modeling skill that most engineering teams don't have on staff. - TGGs assume the mapping decomposes into local, composable patterns; domains with genuinely global constraints—where correctness of one correspondence depends on non-local information spanning the whole model, not a small neighborhood—fit the formalism poorly, and forcing such a domain into TGG rules produces a rule set that's technically correct but extremely difficult for a human to read, review, or maintain. ## The failure mode, and where TGGs actually pay off The predictable failure mode for teams that adopt TGGs without matching investment is a project that sinks significant effort into rule authoring before delivering any synchronization value, then discovers late that a core part of their domain (e.g., a cross-cutting naming convention or a global uniqueness constraint) doesn't decompose into local patterns and needs an escape hatch, undermining the clean formal guarantees that were the entire reason to choose the formalism. In practice, TGGs see real industrial and research use in domains with a genuinely large-scale, high-change-frequency, structurally regular mapping—model-driven engineering of automotive or avionics software product lines is a commonly cited application area—but are rarely the right choice for a small team's day-to-day model/code alignment problem, where a simpler protected-region round-trip tool or even manual reconciliation is proportionate to the actual change volume.