UML Rev. Mapper

UML Reverse Mapper (URM) is a Java tool that automatically generates class diagrams from compiled code. Rather than parsing source files, it uses Java reflection to scan one or more specified packages, inspect the loaded classes, and infer the relationships between them, then emits diagram markup describing that structure. It was created by Ilkka Seppälä (GitHub user iluwatar, best known for the Java Design Patterns project) as a fork of NitorCreations' DomainReverseMapper. The repository is now explicitly archived as unmaintained: no new features are planned and issues and pull requests are not monitored.

Its data model is the object graph of a Java package: nodes are classes, interfaces and enums, and edges are the structural links a reflection pass can recover, such as inheritance, interface implementation and field-based associations (composition/aggregation). URM ships in two forms. The command-line component urm-core is invoked as com.iluwatar.urm.DomainMapperCli with the target classpath, taking -p to name packages to scan, -i to ignore specific classes, -s to select the output presenter and -f to set the output filename. The urm-maven-plugin binds to the Maven process-classes lifecycle phase and writes a diagram to target/${project.name}.urm.<ext>, configured via output directory, target packages, ignored classes and presenter.

URM is a producer of graph-description formats rather than a graph-data converter. Its three presenters emit format:dot for Graphviz, format:plantuml, and format:mermaid, so the actual rendering is delegated downstream. In practice a URM run feeds directly into the Graphviz tool:graphviz toolchain or a PlantUML/Mermaid renderer, and its format:dot output can be fed into general-purpose converters such as tool:graph-easy or ingested by graph tools to reach interchange formats like format:graphml. This makes it a bridge from live JVM bytecode into the same diagram ecosystem used by hand-authored format:plantuml and format:mermaid sources.

Typical use cases are documenting an existing or legacy codebase's architecture, communicating package structure during design reviews, and embedding auto-refreshed diagrams in build output. Its strengths are minimal setup (no source parsing, works from bytecode), multiple output targets, and both CLI and build-tool integration. Its main limitations are that it is unmaintained and may not build against recent Java or Maven releases; that reflection sees only statically declared class members, so dynamically loaded or reflection-constructed relationships are invisible; and that it is confined to JVM classes, offering no analysis of non-Java code.