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.
For the term paradigm, we will rely on the classical definition from Thomas Kuhn [2]. According to Kuhn, a paradigm is a set of concepts, universally recognized rules, models, and methods of solving problems in a certain field of science.
The dualism of this concept lies on the one side in the community of experts who accept a certain paradigm. On the other, the acceptance of a certain paradigm means for a specialist to join such a community.
Thomas Kuhn considered in his book scientific paradigms. However, the usefulness of this concept very soon manifested in different areas of technology and social life. Numerous publications about paradigms and their influence began to appear in the specialized and popular literature about the automotive industry, urban planning, the treatment of certain diseases, etc.
Software engineering, and especially its important part programming, were no exception. Now there are many competing programming paradigms. Wikipedia [3] devoted an article to an overview of them; there are as well interesting reviews such as [4]. The paradigms covered focus on only one part of software engineering, namely writing programs in one or another programming language. Each professional software engineer knows that most real software projects cannot be performed with only one of paradigms (for example, functional programming).
The paradigm described in this article, on the contrary, is applicable all areas of software engineering. Some papers, for example [5], call paradigms different approaches for software project management, e.g., waterfall models or the agile model. From my point of view, these approaches are not acceptable as paradigms in the spirit of the Kuhn’s definition due to their relative theoretical simplicity and the absence of a broad useful theoretical basis after many years’ existence1 .
We use the term “Reification” in this article as an extension of the classical definition of reification in computer science: “Reification is the process by which an abstract idea about a computer program is turned into an explicit data model or other object created in a programming language” [6].
Consider the process of transition from the abstract (ideal) to the concrete (material) in more detail.
Already in the earliest of the philosophical tracts that have reached us it was customary to oppose the material to the ideal. We can at best feel (or think that we feel) ideal objects, that is, ideas. Indicators of such a sensation of ideal objects can be a change in mood or in the course of thoughts after listening to a piece of music, reading a fragment of a book, etc.
Attempts to formulate our sense of the Ideal as a rule do not lead to success. Even practical ideas such as minor repairs around the house or preparing a new variation of a familiar dish are difficult to formulate at first. Only after thinking about or trying to explain it to another person does the idea acquire more and more clear “outlines”.
Let us now turn from the consideration of the concept of the ideal to the consideration of the material. We can sense and register material objects around us, distinguish their properties qualitatively. The properties of many objects are measurable. We can also objectively identify hierarchies and other structures of material objects. To register or measure an object’s properties it is not even necessary to have an object. It is enough to have its model. Moreover, in many practical situations the model can be used without an object. Models can be discussed with other people. People can negotiate based on models. Models can be standardized (formalized).
In some areas of human activity, the standardization of models has gone so far that physical objects (e.g., a bolt) made from a standardized model (e.g., a technical drawing) by different people or automata are indistinguishable from each other.
Given the relative inaccuracy of the proposed definition, I will divide the world of phenomena of our inner and outer world U into two parts:
where the set M consists of phenomena that can be objectively recorded or measured (the material world), and I is everything else.
Whether this formula is applicable to all phenomena of the surrounding world is an open philosophical question. In this article, we will narrow this formula to the world of software engineering.
Each process of creation or update some software system begins with the emergence of some ideas about the future system or its parts in the minds of inventors, customers, or developers. We call these ideas mental models.
For simple systems or simple extensions or updates of large systems, the developer immediately writes the code or configures the system based on his or her mental model. However, in most cases people create and use various intermediate models from a simple requirements list to extensive formal models such as UML or BPMN models.
Thus, the process of creating or updating software systems can be represented as a cha
This content is AI-processed based on open access ArXiv data.
