RPSE: Reification as Paradigm of Software Engineering

The paper introduces RPSE, Reification as a Paradigm of Software Engineering, and enumerates the most important theoretical and practical problems of the development and application of this paradigm. Main thesis: Software engineering is the reification (materialization of ideas) via the transformation of mental models into code executed on computers . Within the proposed paradigm: 1.All basic processes of software engineering are concrete variants (implementations) of the process of constructing chains of mental and material models I1, I2,..In, M1, M2, ..Mm. The last most specific model in this chain is, as a rule, program code. 2.The essence of software engineering is the construction of such chains. 3.All main issues of optimizing the development, its cost, and quality can be reduced to the optimization of construction of the corresponding chain of models.

💡 Research Summary

The paper “RPSE: Reification as a Paradigm of Software Engineering” proposes a novel way of looking at software engineering by treating it as a process of reification – the materialization of ideas. The authors argue that every activity in software development can be understood as constructing a chain of models that progressively transform a mental conception into executable code. This chain consists of a series of mental models (I₁, I₂ … Iₙ) such as requirements, domain knowledge, and design concepts, followed by a series of material models (M₁, M₂ … Mₘ) such as UML diagrams, prototypes, test cases, and finally the program code itself. The central thesis is that the essence of software engineering is the construction of these model chains, and that all classic concerns—cost, schedule, quality, productivity—can be reduced to the problem of optimizing the construction and transformation of the chain.

The paper first situates RPSE (Reification as a Paradigm of Software Engineering) within the landscape of existing paradigms (procedural, object‑oriented, functional). Rather than treating these as competing methodologies, RPSE abstracts them as concrete implementations of the same underlying activity: moving from one model to the next. Consequently, “process improvement” is reframed not as a series of stage‑by‑stage efficiencies but as the minimization of a global cost function defined over the entire model chain.

To make this claim operational, the authors introduce quantitative metrics for each link in the chain:

• Model transition cost – the effort (person‑hours, cognitive load, tooling) required to convert a mental model into a material one.
• Transformation accuracy – the degree to which the target model preserves the semantics of the source model, i.e., the loss of intent during reification.
• Reuse ratio – the proportion of existing models (e.g., component libraries, design patterns) that can be incorporated into a new chain without recreation.

These metrics enable the definition of a total cost function C = Σ (transition_cost + error_penalty – reuse_benefit) over the entire chain. The optimization problem then becomes: find the sequence of model transformations that minimizes C while satisfying functional and non‑functional constraints.

The authors propose a graph‑theoretic solution. The model chain is represented as a directed acyclic graph (DAG) where vertices are individual models and edges are permissible transformations. Edge weights encode the cost function components described above. Classical shortest‑path algorithms (Dijkstra, A*) can be applied to compute the optimal path from the initial mental model I₁ to the final code node Mₘ. The paper suggests embedding this computation into development environments so that, as developers create or modify models, the IDE continuously updates the optimal transformation plan and highlights high‑cost or high‑risk links.

Beyond the algorithmic contribution, the paper discusses educational implications. Traditional curricula focus on teaching programming languages and frameworks; RPSE advocates teaching “model‑chain thinking” so that students learn to explicitly articulate each abstraction level, evaluate trade‑offs, and verify each transformation. This is especially valuable for domains with deep abstraction hierarchies such as AI model pipelines, embedded systems, or large‑scale enterprise architectures.

Potential pitfalls are also addressed. Over‑modeling can inflate the transition cost and introduce unnecessary verification steps, while under‑modeling (directly jumping from requirements to code) can dramatically increase error rates. To mitigate these risks, the authors propose three guidelines:

1. Model minimization principle – keep only those intermediate models that provide measurable value (e.g., validation, reuse).
2. Automated transformation verification – integrate static analysis, model checking, and test generation at each edge to catch semantic drift early.
3. Meta‑model standardization – adopt common interchange formats (e.g., OMG’s MDA standards) to reduce friction when reusing models across projects.

In conclusion, RPSE reframes software engineering as a single, coherent activity of reifying ideas through a chain of increasingly concrete models. By reducing cost, schedule, and quality concerns to the optimization of this chain, the paradigm offers a unified theoretical foundation and a practical roadmap for tooling, process improvement, and education. The paper positions RPSE as a catalyst for future research into model‑centric development environments, automated transformation pipelines, and quantitative metrics that can drive the next generation of software engineering practices.