When keeping a UML or domain model in sync with running code, what is the difference between 'forward engineering' (generating code from a model) and 'reverse engineering' (deriving a model from existing code)?
answer
- model→code vs code→model
- generator overwrites hand-edits
- MDA PIM→PSM→code
- reverse = snapshot not intent
- JPA entities as model or as output
basics
~20 sForward engineering writes the model first, then a tool generates code from it. Reverse engineering starts from existing code and builds or updates a model to describe it. Same goal—keep model and code matching—different starting point.
solid answer
~40 sForward engineering treats the model as the source of truth: a designer edits a UML/domain model, and a code generator produces classes, interfaces, or scaffolding from it, so changes flow model→code. Reverse engineering treats the code as the source of truth: a tool parses source files (or bytecode) and reconstructs a model—class diagrams, state charts—that reflects current structure, so changes flow code→model. In practice teams rarely pick one purely; most codebases evolve through both directions over time, which is why round-trip tooling exists. The trade-off: forward engineering keeps the model authoritative and enforces discipline but breaks down when developers hand-edit generated code; reverse engineering always reflects reality but the model becomes a lagging snapshot regenerated on demand rather than a living design artifact developers author intentionally.
go deeper
Should correctly state the direction of each (model→code vs code→model) and give one plausible example of each without confusing them.
Should additionally explain why forward-engineered code shouldn't be hand-edited, and recognize reverse engineering loses intent, not just recovers structure.
Should discuss protected/generated regions, when to prefer forward vs reverse per subsystem, and the operational cost of keeping a generator pipeline healthy.
Should connect this to organizational choices—where to draw the authoritative-model boundary across a legacy migration, and how to sequence introducing forward engineering into a codebase that has only ever been reverse-engineered.
## Two artifacts that must agree Model-driven design assumes two artifacts must stay consistent: - a **model** — a diagram, schema, or specification capturing structure and behavior at a higher level of abstraction; - the **running code** that implements it. There are two directions you can move between them, and almost every real synchronization strategy is built from some combination of the two. ## Forward engineering: the model is authoritative Forward engineering starts with the model as authoritative. A designer edits a class diagram, an entity-relationship diagram, a state machine, or a domain-specific model in a tool (Enterprise Architect, MagicDraw, or a JPA-annotated domain model treated as the model). A code generator walks that model and emits source artifacts: - class skeletons - interfaces - database DDL - API stubs Generation is mechanical and repeatable—run it again and you get the same output for the same model. The intent is that the model is edited, not the generated code; if different behavior is needed, the model (or a template/marker the generator respects) is changed and regenerated, not the output patched by hand. ## Reverse engineering: the code is authoritative Reverse engineering runs the opposite direction: the code is authoritative, and a tool parses source files, bytecode, or a running schema to reconstruct a model describing what already exists. - A **static-analysis tool** walks a codebase and produces a class diagram. - A **database-introspection tool** reads table and foreign-key metadata and produces an ER diagram. The output model mirrors current reality, generated on demand, not a design artifact anyone intentionally authored. ## Why both directions exist Both solve the same underlying problem: models are useful for communication and reasoning above the level of individual lines of code, but hand-maintained models drift the moment someone edits code without updating the diagram, or edits the diagram without touching code. Forward engineering solves this by making the model the single point of truth and mechanically deriving code, so nothing drifts as long as nobody edits generated output directly. Reverse engineering accepts that code is truth and regenerates a fresh model on demand, so the model is never stale by construction—it's simply rebuilt. ## The trade-off The trade-off is real on both sides. - **Forward engineering** captures intent—naming, relationships, invariants a human chose—and strong traceability, but only holds up if generated code is never hand-edited; the moment someone patches generated output under deadline pressure, the next regeneration either silently overwrites the fix or the pipeline is manually skipped, freezing the model as fiction. - **Reverse engineering** gives an always-accurate reflection, useful for onboarding into legacy systems or auditing what's deployed, but the reconstructed model is usually low-level and noisy: it captures classes and associations that exist, not the intent behind them, and can't recover information the code never expressed. ## Failure modes 1. The classic forward-engineering failure is **'drift by stealth edit'**: a hotfix goes directly into generated files because the generator is slow or broken, and eventually nobody trusts the model enough to regenerate, so the pipeline is quietly abandoned. 2. The classic reverse-engineering failure is **'model as noise'**: running it on a large legacy codebase produces a diagram so dense with every getter and utility class that it communicates nothing, and the team stops looking. ## Where it shows up A concrete example is OMG's **Model Driven Architecture (MDA)**, which formalizes forward engineering as a pipeline from a Platform-Independent Model to a Platform-Specific Model to code, relying on the model being edited and code regenerated. A more everyday example is **JPA/Hibernate**: teams sometimes hand-write annotated entity classes as the model and forward-engineer the database DDL from them, while others point a reverse-engineering plugin at an existing legacy database to generate the entity classes from its schema—the same annotation vocabulary used in opposite directions depending on which side is authoritative.
- What typically breaks when a team regenerates code from a forward-engineered model after someone has hand-edited the previously generated output?The regeneration either silently overwrites the hand-edit, losing the fix, or the generator is skipped to preserve it, which freezes the model as a fiction that no longer matches the code. Good generators mitigate this with protected regions or partial classes the generator won't touch, but that only helps if the team consistently uses them.
- Why is a reverse-engineered class diagram from a large legacy codebase often not useful on its own?It reflects every class, getter, and utility method that exists, without any intent-level pruning a human author would apply, so it's dense and low-signal. Teams usually need to filter it—by package, by exclude-noise rules, or by hand-curating a subset—before it communicates anything about architecture.
- Give an example of a real technology stack where the same annotation vocabulary can drive either forward or reverse engineering.JPA/Hibernate: annotated entity classes (@Entity, @Column, @OneToMany) can be the source model that Hibernate's schema-generation forward-engineers into DDL, or a reverse-engineering plugin can point at an existing database and generate those same annotated classes from its schema, depending on which side the team treats as authoritative.
Forward engineering is like an architect's blueprint driving construction—change the blueprint, rebuild from it. Reverse engineering is like a surveyor measuring an already-built house to draw a floor plan after the fact—accurate today, but capturing nothing about why the builder made the choices they did.
saying these in an interview costs you the question
- Says forward and reverse engineering are the same activity in opposite directions with no different failure modes
- Claims regenerating from a model is always safe with no mention of hand-edits being lost
- Thinks reverse engineering recovers design intent, not just structure
- Can't name a concrete tool or example on either side
- Assumes a project picks exactly one direction forever and never mixes them