Programming is the materialization of ideas.
The main thesis of this article: Software development should be viewed as the materialization of ideas through the transformation of mental models into program code.
The article describes the paradigm of materialization of ideas in software engineering (engl .: RPSE: Reification as Paradigm of Software Engineering).
English version of the article: RPSE: Reification as Paradigm of Software Engineering . The abbreviation RPSE is used hereafter to refer to the described paradigm.
Basic definitions
Before proceeding to the discussion of the main theses of this article, it is necessary to agree on the meaning of the basic terms used in it.
')
Software engineering
By software engineering, we mean the classic definition of Software Engineering discipline from the IEEE dictionary [1]: Software engineering is "The application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software."
Paradigm
The term paradigm used in this article is based on the classic definition of the paradigm of Thomas Kuhn [2]: A paradigm is a set of problems, a set of concepts, generally accepted rules and laws, methods of solving problems in a certain field of science.
More on paradigms
In order to more accurately define the concept of paradigm used further, it is useful to quote two well-known quotes from the book of Kuhn:
The dualism of this concept is that, on the one hand, the paradigm is characterized through a community of experts recognizing it. It is the specialists of a certain area who determine, create and develop its parts. On the other hand, the recognition of a certain paradigm means for a specialist to join such a community.
By paradigms, I mean the recognized scientific achievements, which for a certain time give the scientific community a model of problem statement and their solutions ...
Introducing this term, I meant that some generally accepted examples of actual practice of scientific research — examples that include law, theory, their practical application and necessary equipment — all together give us models from which specific traditions of scientific research arise.
The dualism of this concept is that, on the one hand, the paradigm is characterized through a community of experts recognizing it. It is the specialists of a certain area who determine, create and develop its parts. On the other hand, the recognition of a certain paradigm means for a specialist to join such a community.
Thomas Kuhn considered scientific paradigms in his book. However, very soon after the release of the first edition of the book, the utility of using this concept in technology and various areas of social life became apparent. In this regard, numerous publications on paradigms and their change in the automotive industry, urban planning, treatment of certain diseases, etc. began to appear in the special and popular literature.
Software engineering and especially its important component - programming, were no exception. Currently there are many competing programming paradigms. They are listed in a separate Wikipedia article [3], as well as such interesting reviews as [4].
On the limitations of programming paradigms
The authors of the paradigms described in [3] and [4] concentrate on a narrow sub-field of software engineering, namely, writing programs in one or another programming language. I think many professionals agree with the opinion that real software projects cannot be done within only one of these paradigms (for example, functional programming).
The paradigm described in this article, on the contrary, is applicable to the most different subject areas and phases of software development.
The paradigm described in this article, on the contrary, is applicable to the most different subject areas and phases of software development.
On the limitations of software project management paradigms
Some authors, for example, in the review [5], call various approaches or models for organizing and conducting software projects as paradigms. For example, waterfall models, V-model or Agile-model are compared. It is unlikely that these approaches, unlike the programming paradigms mentioned above, can be called paradigms in the spirit of Kuhn’s definition because of their relative theoretical simplicity and the absence of a broad theoretical base.
The paradigm proposed in this article also does not yet have its own developed theoretical base, however, its development paths are already visible today.
The paradigm proposed in this article also does not yet have its own developed theoretical base, however, its development paths are already visible today.
Materialization of ideas
The term materialization of ideas used in this article (engl: reification ) is an extension of the classical definition of reification in computer science: “ [6].
More about the world of ideas, the world of things and materialization
The essence of the extension of the classical definition of the concept of materialization used in this article can be defined as follows.
Already in the earliest extant philosophical paths, it was customary to oppose the Ideal (world of ideas) to the Material (world of things).
We can feel the ideal at best (or think that we feel it). An indicator of such a feeling of the Ideal may be a change in mood or train of thought after listening to a piece of music, a read fragment of a book, etc. Of course, I mean the indirect impact, for example, of music, on our consciousness, and not on the primitive physiological subordination of the organism to the rumble of a rock concert or the rhythm of a disco.
Attempts to formulate our sense of the Ideal as a rule do not lead to success.
The great Russian poet Fedor Ivanovich Tyutchev remarkably said this:
We 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 can be objectively measured. We can also objectively select hierarchies and other structures of material objects.
Already in the earliest extant philosophical paths, it was customary to oppose the Ideal (world of ideas) to the Material (world of things).
We can feel the ideal at best (or think that we feel it). An indicator of such a feeling of the Ideal may be a change in mood or train of thought after listening to a piece of music, a read fragment of a book, etc. Of course, I mean the indirect impact, for example, of music, on our consciousness, and not on the primitive physiological subordination of the organism to the rumble of a rock concert or the rhythm of a disco.
Attempts to formulate our sense of the Ideal as a rule do not lead to success.
The great Russian poet Fedor Ivanovich Tyutchev remarkably said this:
How does the heart express itself?Even practical ideas such as small repairs around the house or preparing a new variation of a familiar dish are difficult to formulate at first. And only after thinking about or trying to explain to another, the idea gets more and more clear “outlines”.
Other how to understand you?
Will he understand what you live?
The thought expressed is a lie ... [7]
We 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 can be objectively measured. We can also objectively select hierarchies and other structures of material objects.
To evaluate or measure (obtain quantitative characteristics) it is not necessary to have an item. Enough to have his model. Moreover, in many practically interesting situations, the model can be used without an object. Models can be discussed with others. Models can be negotiated. Models can be standardized (formalized).
In some areas of human activity, the standardization of models has gone so far that parts made on the basis of a standardized model (for example, a drawing) by different people or automata (for example, threaded bolts) from a technological point of view will be visually indistinguishable from each other.
Being aware of the relative inaccuracy of the proposed definition, later in this article I will divide the world of the phenomena of our internal and external world U into two parts:
U = M + I
where the set M consists of their phenomena, which can be objectively recorded or measured (the material world) and I - everything else.
Whether this formula applies to absolutely all phenomena of the world is an open philosophical question. Further in this article we will narrow the scope of this formula to the world of phenomena from the world of software engineering.
Or, formulated as a thesis: The whole set of phenomena related to software engineering can be divided into a subset of the ideal and a subset of the material. At the same time, material phenomena are recorded or measured on the basis of their models.
The process of creating or changing a software system ends in most cases with the creation of one or another code that is mapped into a physical process (real-world phenomenon) using a computer.
This process begins with the emergence of some ideas about the future system in the heads of customers or developers. These ideas and ideas will be referred to as the mental model .
About intermediate models
In simple systems or with simple additions / changes to large systems, the developer immediately writes code or configures the system based on his mental model. However, in most cases, intermediate models of varying complexity and level of formalization are created - from a simple list of requirements to extensive formal models (for example, UML or BPMN models)
Materialization of ideas in the areas adjacent to Software Engineering
It is clear that the definition given above is not radically new and is widely used (consciously or unconsciously) in the fields of intellectual work that are adjacent to programming. Consider, for example, two such areas - mechanical engineering and mathematics.
These two areas use the materialization of ideas for a long time and effectively. They have a lot to learn from programming.
In mechanical engineering, we see a full cycle of materialization of ideas - from the emergence of an idea in the designer’s head through its thinking through, detailing, mapping into a model, and finally - manufacturing from a certain material.
It's different in math
On the materialization of ideas in mathematics
Interesting facts and ideas about the materialization of ideas in mathematics can be found in paragraph 7.3 in the book [8].
The "final product" of mathematics is formal models with strictly proved properties.
From this point of view, programming lies in the middle. Graphically, this can be represented as follows:
Thus, mathematics uses a larger number of more abstract models and practically does not touch at all the field of extremely specific models such as engineering drawings.
Mechanical engineering, on the contrary, uses relatively few abstract models, but many concrete ones. For example, those for which physical objects can be uniquely manufactured.
From this point of view, programming lies in the middle.
Why is programming in the middle?
The final programming product is the program code. Although it is mapped to specific physical objects (electrical signals and fields of different physical nature) when executed on hardware, it is difficult to compare these objects with nuts, gears and machine bodies. On the other hand, the program code is close to mathematical formulas, and sometimes is their direct mapping. However, in any real software system it is necessary to take into account the mass of specific aspects of the environment and interaction with users or other systems. This makes program code more specific than mathematical formulas.
What software engineering can learn from neighboring areas in terms of using models
Consider first the mathematics.
For several thousand years of its development, mathematics has learned to describe the same phenomena of the real or imaginary world in very different terms. The ancient Greeks learned to replace purely verbal descriptions of tasks with geometric figures and with their help solve practically important problems. Later, an understanding emerged about the interchangeability of line segments and numbers. Then the concept of an algebraic variable and the reduction of geometric problems to systems of algebraic equations crystallized.
Today, high school students know that the same problem can be solved in different ways (for example, geometrically or algebraically) and that the same mathematical model, for example, an algebraic equation, describes many different physical, chemical, etc. phenomena.
Mathematics has learned well not only to describe the same real or imaginary objects and processes with the help of models of very different mathematical nature. An important achievement of mathematics is the ability to determine the degree of similarity of models from different branches of mathematics and the ability to transform them into each other. Many breakthrough solutions to the most important mathematical problems of recent years are in fact chains of separate evidence, each of which uses a specialized apparatus from a special section of mathematics. At the junctions of these highly specialized proofs of mathematics, they skillfully transform the models of one branch of mathematics into models of another section. In programming, something like this happens already now when compiling the source code of a program and when generating code from DSL (Domain Specific Language) or metadata. But the culture of working with models in software engineering is far behind the mathematical one.
And what software engineering can learn in terms of the materialization of engineering?
In many industries and even within large corporations, there are chains of coordinated formal and semi-formal models. These chains end with models on the basis of which physical objects — devices and machines — are manufactured and mounted. As a rule, for most types of intermediate models there are formal methods for checking their correctness (technical standards). Models are the main language of communication specialists of different profiles in the design and manufacture of engineering products.
Against this background, the situation in IT looks much worse. Only within very large IT concerns in recent years have attempts been made to build comparable sets of models and processes. Small firms and IT startups, as a rule, not only do not have developed formal models and processes, but are not even aware of their existence. This situation is currently determined by the following factors:
Multi-mode of the world
For several thousand years of its development, mathematics has learned to describe the same phenomena of the real or imaginary world in very different terms. The ancient Greeks learned to replace purely verbal descriptions of tasks with geometric figures and with their help solve practically important problems. Later, an understanding emerged about the interchangeability of line segments and numbers. Then the concept of an algebraic variable and the reduction of geometric problems to systems of algebraic equations crystallized.
Today, high school students know that the same problem can be solved in different ways (for example, geometrically or algebraically) and that the same mathematical model, for example, an algebraic equation, describes many different physical, chemical, etc. phenomena.
Model morphism and consistency of concepts and notations
Mathematics has learned well not only to describe the same real or imaginary objects and processes with the help of models of very different mathematical nature. An important achievement of mathematics is the ability to determine the degree of similarity of models from different branches of mathematics and the ability to transform them into each other. Many breakthrough solutions to the most important mathematical problems of recent years are in fact chains of separate evidence, each of which uses a specialized apparatus from a special section of mathematics. At the junctions of these highly specialized proofs of mathematics, they skillfully transform the models of one branch of mathematics into models of another section. In programming, something like this happens already now when compiling the source code of a program and when generating code from DSL (Domain Specific Language) or metadata. But the culture of working with models in software engineering is far behind the mathematical one.
Models in mechanical engineering
And what software engineering can learn in terms of the materialization of engineering?
In many industries and even within large corporations, there are chains of coordinated formal and semi-formal models. These chains end with models on the basis of which physical objects — devices and machines — are manufactured and mounted. As a rule, for most types of intermediate models there are formal methods for checking their correctness (technical standards). Models are the main language of communication specialists of different profiles in the design and manufacture of engineering products.
Against this background, the situation in IT looks much worse. Only within very large IT concerns in recent years have attempts been made to build comparable sets of models and processes. Small firms and IT startups, as a rule, not only do not have developed formal models and processes, but are not even aware of their existence. This situation is currently determined by the following factors:
- Lack of effectiveness of existing models and processes
- Lack of fame of these models outside of large concerns
- The disadvantages of educating developers and especially managers
- The lag of university education from the real needs of software engineering.
Definition and Outlines of the Ideas Materialization Paradigm (RPSE)
We have defined all the necessary concepts to give a basic definition of the proposed paradigm. Here it is:
Software development is the materialization of ideas through the transformation of mental models into code executed on computers.
Within the framework of the proposed paradigm:
- All basic software development processes are concrete variants (implementations) of the process of building chains of mental and material models. The last most specific model in this chain is, as a rule, program code.
- The essence of software development is to create such chains.
- All the main issues of optimizing development, reducing its cost and improving its quality can be reduced to optimizing the construction of an appropriate chain of models.
Why Materialization and not Modeling?
Note that although the definition of RPSE refers to the construction of chains of models, it is nevertheless proposed to call the paradigm a materialization and not a modeling. Thus, an attempt is made to emphasize the peculiarity of chains of models that are becoming less and less abstract / ideal and more and more concrete / material.
The above definition has its own characteristics and variations in different areas of software engineering. Only in a very small number of cases does it happen that at first the programmer’s head fully matures a clear idea of ​​how to solve the task before him, which he then translates into code in a programming language in a short time. In most real projects, the processes of finding a solution and its implementation coexist, develop in parallel and interact with each other. Those. mental models, code and often intermediate models (in the form of a test, images, formal models like UML) grow and change in parallel, affecting each other.
Definitions
Very often several people work on a problem at the same time. Each of them has its own mental model and, possibly, its own intermediate models and code fragments.
Often, the code in a certain programming language is actually absent, since the creation of a new solution is reduced to controlling the masks of configurators or generators, such as when working with development tools in systems like SAP or WebSphere.
The variants of turning manually written or automatically generated code into executable code in our time have also become very diverse.
Finally, the very concept of the processor on which the code is executed has also expanded significantly in recent years. If earlier they were processors that were on the boards, which in turn were inserted into the cases of desktops, laptops and server racks, now this set has been expanded with various chips of various sizes, which are built into mobile phones, game consoles, surveillance cameras, " smart home appliances, etc. Not to mention quantum computers.
Nevertheless, RPSE, by virtue of its generality, is applicable to all the areas listed above.
Often, the code in a certain programming language is actually absent, since the creation of a new solution is reduced to controlling the masks of configurators or generators, such as when working with development tools in systems like SAP or WebSphere.
The variants of turning manually written or automatically generated code into executable code in our time have also become very diverse.
Finally, the very concept of the processor on which the code is executed has also expanded significantly in recent years. If earlier they were processors that were on the boards, which in turn were inserted into the cases of desktops, laptops and server racks, now this set has been expanded with various chips of various sizes, which are built into mobile phones, game consoles, surveillance cameras, " smart home appliances, etc. Not to mention quantum computers.
Nevertheless, RPSE, by virtue of its generality, is applicable to all the areas listed above.
What else can be said about a certain paradigm today? Is it possible to outline its contours more precisely?
The next step to clarifying the paradigm after trying to give its basic definition is to try to list the main categories of phenomena that it affects. Recalling Kuhn’s definition, we need to try to list the types of models that RPSE enters and uses.
RPSE models can be divided into three main categories:
- Mental models
- Code in programming languages ​​or its equivalents as models of executable code.
- Intermediate models.
The least studied in this triad are mental models. What exactly is meant by them?
Mental models are a term to refer to ideas that exist in the minds of customers, programmers, and other participants in the process and on the basis of which ultimately executable code arises. The presence of such models is indisputable and can be registered at the mental level, for example, by the programmer himself. At the present level of technological development, these models cannot be reliably measured by instruments.
One of the well-functioning methods of fixing and measuring such models is the introduction of the idea carrier. It is obvious that the process of interviewing or similar to it dramatically affect the mental model itself. Each of us probably experienced more than once a situation where only one attempt to formulate a problem in order to consult with a colleague led to an “insight”, and often to a solution to the problem.
Interviewing allows for objectively constructing models of varying complexity on the basis of correctly formulated questions. The most commonly used are:
Structural models:
- Lists with binary, enumeration, numeric, string and other values.
- Graph and network data structures
Behavior description models:
- Seven-formal behavioral models
- Formal behavioral models (for example, finite automata)
On the theory of mental models
These models are reflections of mental models. The degree of closeness of mental models to real models should be dealt with by psychology or theoretical pedagogy. Unfortunately, the author is not aware of serious work in this area. (This does not mean that such works do not exist).
Why does software engineering need an end-to-end paradigm?
The presence of the “end-to-end” paradigm opens up the following opportunities for participants using the process of creating, modifying and using software using this paradigm:
- The ability of all participants in the process to use the same terminology.
- Ability to build through the process of creating new software.
- The ability to evaluate its process parameters, its intermediate results and manage it.
The main objectives of the development paradigm
Theoretical problems
As has been repeatedly noted, including in the book by Kuhn [2], in most cases, scientists are engaged in solving potentially solvable problems, and less often they are taken for those that are not very clear how to approach. But these are exactly our tasks. Here are the main ones:
- Constructive definition of the mental model.
- Finding constructive criteria for assessing the degree of abstractness / ideality vs. concreteness / materiality of models.
- Finding criteria for the selection of candidates for the role of intermediate and additional models.
- Selection and development of criteria and methods for comparing models of various types, including their direct and reverse tracing.
- Development of methods for automated and automatic transformation of models.
Practical tasks
Along with theoretical problems for the development and implementation of the described paradigm in the practice of software engineering, it is necessary to solve at least the following practical tasks:
- Creating tools for: a) Extracting and fixing mental models. b) Automated and automatic transformation of mental models into intermediate ones. c) Tracing and evaluation of changes in the content of transformable models
- Creating the necessary technical and teaching literature and other medial teaching material.
- Organization of forums and conferences on this topic.
Conclusion
This article attempts to define the software engineering paradigm as the materialization of ideas. The word define (and not open) is not used here by chance. In fact, participants in IT projects have long been engaged in the creation, transformation, and use of models, but they may not be aware of that.
In the strict sense of Kuhn’s definition, the described approach cannot yet claim the right to be called a paradigm, but only a candidate for a paradigm, since it does not have an extensive community of people supporting it and a well-developed system of interconnected models. However, I want to believe that the shortcomings will soon be overcome.
This is the first article in the scheduled series of articles. In the following articles I am going to talk about mental and intermediate models.
Literature
1. IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.12-1990, 1990.
2. Kuhn, Thomas S. The Structure of Scientific Revolutions. 3rd ed. Chicago, IL: University of Chicago Press, 1996.
3. Programming paradigm: en.wikipedia.org/wiki/Programming_paradigm (state - 08/27/2018)
4. Peter A. Henning, Holger Vogelsang Taschenbuch Programmiersprachen. Carl Hanser Verlag GmbH & Co. KG; Auflage: 2., neu bearbeitete (5. September 2007). ISBN-13: 978-3446407442.
5. Software Engineering Paradigms And Models Information Technology Essay
www.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (state - 08/27/2018)
6. Reification (computer science) en.wikipedia.org/wiki/Reification_ (computer_science) (state - 08/27/2018)
7. Fedor Ivanovich Tyutchev. Silentium! (Silence (Latin), 1829
8. Borovik, Alexandre. Mathematics under the microscope: notes on the cognitive aspects of mathematical practice. American Mathematical Society. ISBN-13: 978-0821847619.
Illustration: geralt
Source: https://habr.com/ru/post/425321/
All Articles