BY POSITION IN THE PROCESS: UPPER CASE (front-end) supports the early phases: planning, requirements, analysis, design · diagram editors (DFD, ER, UML), requirement management, prototyping, screen designers LOWER CASE (back-end) supports implementation and maintenance · code generators, compilers, debuggers, test tools, reverse-engineering tools INTEGRATED CASE (I-CASE) both, sharing a common repository so a change in the design propagates to the code and vice versa · this was the 1990s ambition, and it is where the category failed BY FUNCTION: DIAGRAMMING draw and edit models QUERY & REPORT interrogate the repository DICTIONARY the central store of names, types, meanings ANALYSIS & DESIGN check models for consistency and completeness CODE GENERATION produce source from a model REVERSE ENGINEERING produce a model from existing source REENGINEERING restructure existing code DOCUMENTATION generate documents from the repository CONFIGURATION MGT version control, build, release TESTING test-case generation, coverage, execution PROJECT MGT estimation, scheduling, tracking METRICS measure size, complexity, quality THE CENTRAL REPOSITORY is the architectural heart of I-CASE: one store holding requirements, models, code, tests and their RELATIONSHIPS, so that · a requirement can be TRACED to the design element and code that implement it and the test that verifies it · a change can be assessed for impact before being made · consistency can be checked automatically That traceability is genuinely valuable and is still required in regulated industries — which is why requirements-management tools (DOORS, Jama, Polarion) remain a real market even though "CASE" is not.

FORWARD ENGINEERING the normal direction: requirements → design → code. CODE GENERATION from a model is the CASE promise. ✔ works well for repetitive, structured artefacts — database schema from an ER model, API stubs from an interface definition, boilerplate from an ORM ✗ fails for behaviour: a diagram that fully specifies logic is as complex as the code, so nothing is saved. This is the key reason full code generation failed. REVERSE ENGINEERING code → model. Recover the design of a system whose documentation is lost or never existed. ✔ essential for LEGACY SOFTWARE (from the characteristics topic): the business rules exist only in the code ✗ recovers STRUCTURE but not INTENT. A tool can produce a class diagram; it cannot tell you why the design is that shape or which parts are accidental. RESTRUCTURING code → better code, same functionality and same abstraction level. Automated reformatting, dead-code removal, control-flow simplification. REENGINEERING the full cycle: reverse engineer to recover the design, improve it, then forward engineer to new code. Expensive, and the honest alternative to a rewrite. reengineering = reverse engineering + restructuring + forward engineering ROUND-TRIP ENGINEERING — keep model and code synchronised in both directions. ✗ THE PROBLEM THAT KILLED IT: which one is the source of truth? If both can be edited, they diverge, and merging a diagram is far harder than merging text. Every tool that tried this eventually forced one direction to win. The modern resolution is to make the CODE authoritative and GENERATE diagrams from it on demand — which is why tools like PlantUML, Mermaid and Doxygen won over graphical modellers. A diagram in version control as text is diffable; a binary model file is not.

WHAT WENT WRONG WITH I-CASE: 1. THE MODEL/CODE SYNCHRONISATION PROBLEM (above). Two representations of one truth always diverge. 2. COST AND LOCK-IN. Tools were expensive, proprietary, and stored work in formats only they could read. When the vendor failed, so did your archive. 3. THE ABSTRACTION DID NOT PAY. Specifying behaviour graphically is not simpler than specifying it textually — it is usually harder, because text has better tooling (diff, merge, search, grep). 4. PROCESS RIGIDITY. Tools encoded one methodology and resisted any other, arriving just as the industry moved toward lighter processes. 5. NOT INTEGRATED WITH THE REAL WORKFLOW. Developers lived in editors and compilers; CASE lived elsewhere and had to be visited. WHAT ACTUALLY WON — the same functions, unbundled and integrated through version control: CASE category what shipped ───────────────────────────────────────────────────────── diagramming PlantUML, Mermaid, draw.io (text-based, diffable) central repository GIT — the code IS the repository analysis & design check linters, type checkers, static analysis (ESLint, mypy, SonarQube) code generation scaffolding, ORMs, OpenAPI codegen, protobuf reverse engineering IDE call hierarchies, Doxygen, dependency graphs configuration management git, GitHub/GitLab testing JUnit/pytest, coverage tools, CI project management Jira, Linear, GitHub Projects metrics SonarQube, CodeClimate documentation docs-as-code in the repository THE PATTERN: each function survived; the INTEGRATION strategy changed from "one vendor's repository" to "plain text files in git, many tools reading them". That is why "docs as code" and "diagrams as code" are now the default advice. WHAT CASE GOT RIGHT, and is worth keeping: · TRACEABILITY from requirement to test is genuinely valuable · a single source of truth for names and definitions prevents whole classes of misunderstanding · automating the mechanical parts of engineering is correct; the mistake was believing DESIGN is mechanical CASE ENVIRONMENT vs WORKBENCH vs TOOL — the standard taxonomy: TOOL one function (a debugger) WORKBENCH several integrated tools for one activity (an IDE) ENVIRONMENT a complete set covering the whole process (the I-CASE ambition)