Programming is the materialization of ideas.
3r33561. 3r3-31. 3r33561. 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.
3r33561. The article describes the paradigm of materialization of ideas in software engineering (engl .: RPSE: Reification as Paradigm of Software Engineering) 3r339. 3r33466.
3r33561. English version of the article: 3r3133. RPSE: Reification as Paradigm of Software Engineering 3r33434. . The abbreviation RPSE is used hereafter to refer to the described paradigm.
3r33561. 3r3409. Basic definitions 3r33410.
3r33561. 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.
3r33561. 3r33434. Software Engineering
3r33561. Under software engineering we will understand the classic definition of Software Engineering discipline from the IEEEdictionary. : Software engineering is "The application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software."
3r33561. 3r33434. The
3r33561. The term used in this article. paradigm based on the classic definition of the paradigm of Thomas Kuhn: A paradigm is a circle of problems, a set of concepts, generally accepted rules and laws, methods of solving problems in a certain area of science.
3r33561. 3r33333. 3r33333. Learn more about the [/b] paradigms.
In order to more accurately define the concept of paradigm used further, it is useful to cite two well-known quotes from the book of Kuhn: 3r-3333. By paradigms, I mean recognized by all scientific achievements, which for a certain time give the scientific community a model for posing problems and their solutions 3r3451. 3r33561. Introducing this term, I meant that some generally accepted examples of actual research practice — 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. 3r33557. 3r33557. 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 connection, 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.
3r33561. Software engineering and especially its important component - programming, were no exception. Currently there are many competing programming paradigms. Their listing is devoted to a separate article in Wikipediaand interesting reviews like. 3r33333. 3r33333. On the limitations of programming paradigms 3r33333.
The authors described inandparadigms focus on a narrow sub-field of software engineering, namely, writing programs in a particular 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).
3r33561. The paradigm described in this article, on the contrary, is applicable to the most different subject areas and phases of software creation. 3r33557. 3r33557. 3r33333. 3r33333. On the limitations of software project management paradigms 3-333333.
Some authors, for example, in the reviewParadigms call various approaches or models for organizing and conducting software projects. 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 due to their relative theoretical simplicity and the absence of a broad theoretical base.
3r33561. The paradigm proposed in this article also does not yet have its own developed theoretical base, however, its development paths are already visible today. 3r33557. 3r33557.
3r33561. 3r33434. Materialization of ideas
3r33561. The term used in this article. materialization of ideas (engl: reification ) is an extension of the classical definition of reification in computer science: “. 3r33333. 3r33333. Read more about the world of ideas, the world of things and materialization [/b]
The essence of the extension of the classical definition of the concept of materialization used in this article can be defined as follows.
3r33561. Already in the earliest extant philosophical paths, it was customary to oppose the Ideal (world of ideas) to the Material (world of things).
3r33561. 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 effect, 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.
3r33561. Attempts to formulate our sense of the Ideal as a rule do not lead to success.
3r33561. The great Russian poet Fedor Ivanovich Tyutchev remarkably said this:
How does the heart express itself?
3r33561. Other how to understand you?
3r33561. Will he understand what you live?
3r33561. The thought expressed is a lie 
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”.
3r33561. 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. 3r33557. 3r33557. To evaluate or measure (obtain quantitative characteristics) it is not necessary to have an item. It is 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).
3r33561. 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) are technologically and visually indistinguishable from each other.
3r33561. Aware of the relative inaccuracy of the proposed definition, later in this article I will share the world of the phenomena of our internal and external world 3r-3297. U [/b] into two parts:
3r33561. U = M + I
3r33561. where set M consists of phenomena that can be objectively recorded or measured (the material world) and 3r329797. I [/b] - all the rest.
3r33561. 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.
3r33561. Or, formulated as a thesis: The whole set of phenomena relating 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.
3r33561. 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.
3r33561. 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 mental model . 3r33333. 3r33333. About intermediate models 3r33333.
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) 3r35577. 3r33557.
3r33561. 3r3409. Materialization of ideas in the areas adjacent to Software Engineering 3r3-3410.
3r33561. 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 adjacent to programming. Consider, for example, two such areas - mechanical engineering and mathematics.
3r33561. These two areas use the materialization of ideas for a long time and effectively. They have a lot to learn from programming.
3r33561. In mechanical engineering, we see the 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.
3r33561. The situation is different in math
3r33333. On the materialization of ideas in mathematics 3r3333333.
Interesting facts and ideas about the materialization of ideas in mathematics can be found in paragraph 7.3 in the book. 3r33557. 3r33557. The “final product” of mathematics is formal models with strictly proved properties.
3r33561. From this point of view, programming lies in the middle. Graphically, this can be represented as follows:
3r33561. Thus, mathematics uses a larger number of more abstract models and almost never touches the field of extremely specific models such as engineering drawings.
3r33561. 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.
3r33561. From this point of view, programming lies in the middle. 3r33333. 3r33333. Why is programming in the middle? 3r33333.
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, these objects are difficult to compare 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. 3r33557. 3r33557. 3r33333. 3r33333. What software engineering can learn from neighboring areas in terms of using models 3r-3333.
Consider first the mathematics.
3r33561. 3r33434. Multi-modeling of the world
3r33561. 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.
3r33561. 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, the algebraic equation, describes many different physical, chemical, etc. phenomena.
3r33561. 3r33434. Model morphism and consistency of concepts and notations 3r33424.
3r33561. 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 essentially chains of individual 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.
3r33561. 3r33434. Models in mechanical engineering
3r33561. And what software engineering can learn in terms of the materialization of engineering?
3r33561. 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 for specialists of different profiles in the process of designing and manufacturing engineering products.
3r33561. 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:
3r33561. 3r33333. 3r33561. 3r3403. Lack of effectiveness of existing models and processes 3r354545. 3r33561. 3r3403. The lack of fame of these models outside of large concerns 3r3353545. 3r33561. 3r3403. The disadvantages of educating developers and especially managers are 3-333545. 3r33561. 3r3403. The lag of university education from the real needs of software engineering. 3r33545. 3r33561. 3r33547. 3r33557. 3r33557.
3r33561. 3r3409. The definition and contours of the paradigm of materialization of ideas (RPSE) 3r33410.
3r33561. 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.
3r33561. In the framework of the proposed paradigm:
3r33561. 3r33395. 3r33561. 3r3403. All basic software development processes are specific variants (implementations) of the process of building chains of mental andmaterial models. The last most specific model in this chain is, as a rule, program code. 3r33545. 3r33561. 3r3403. The essence of software development is to create such chains. 3r33545. 3r33561. 3r3403. 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. 3r33545. 3r33561. 3r3406.
3r33561. 3r33333. 3r33333. Why Materialization and not Modeling? 3r33333.
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. 3r33557. 3r33557.
3r33561. 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. 3r33333. 3r33333. Definitions of the definition of [/b]
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.
3r33561. Often, the code in a certain programming language is actually absent, since the creation of a new solution is reduced to managing the masks of configurators or generators, such as when working with development tools in systems like SAP or WebSphere.
3r33561. The variants of turning manually written or automatically generated code into executable code in our time have also become very diverse.
3r33561. 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 by various chips of various sizes, which are built into mobile phones, game consoles, video surveillance cameras, " smart home appliances, etc. Not to mention quantum computers.
3r33561. Nevertheless, RPSE, by virtue of its generality, is applicable to all the areas listed above. 3r33557. 3r33557. What else can be said about a certain paradigm today, is it possible to outline its contours more precisely?
3r33561. The next step to clarifying the paradigm after trying to give its basic definition is to attempt 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.
3r33561. RPSE models can be divided into three main categories:
3r33561. 3r33333. 3r33561. 3r3403. Mental models 3r33545. 3r33561. 3r3403. Code in programming languages or its equivalents as models of executable code. 3r33545. 3r33561. 3r3403. Intermediate models. 3r33545. 3r33561. 3r33547.
3r33561. The least studied in this triad are mental models. What exactly is meant by them?
3r33561. Mental Models - it is a term for designating ideas that exist in the minds of customers, programmers and other participants in the process and on the basis of which the executable code ultimately 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.
3r33561. One of the well-functioning methods of fixing and measuring such models is the introduction of the idea carrier. Obviously, the process of interviewing or similar to it has a dramatic effect on 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 “enlightenment”, and often to a solution to the problem.
3r33561. Interviewing allows, on the basis of properly formulated questions regarding the objective to build models of varying complexity. The most commonly used are:
3r33561. Structural models:
3r33561. 3r33333. 3r33561. 3r3403. Lists with binary, enumeration, numeric, string and other values. 3r33545. 3r33561. 3r3403. Graph and network data structures 3r33545. 3r33561. 3r33547.
3r33561. Behavior description models:
3r33561. 3r33333. 3r33561. 3r3403. Seven-formal models for determining behavior 3r3353545. 3r33561. 3r3403. Formal models for determining behavior (for example, finite automata) 3r33545. 3r33561. 3r33547.
3r33561. 3r33333. 3r33333. On the theory of mental models 3r33333.
These models are reflections of mental models. The degree of proximity 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). 3r33557. 3r33557.
3r33561. 3r3409. Why does software engineering need an end-to-end paradigm? 3r33410.
3r33561. The presence of the “end-to-end” paradigm opens up the participants using the paradigm of the process of creating, modifying and using software as follows: 3r3451. 3r33561. 3r33333. 3r33561. 3r3403. The ability of all participants in the process to use the same terminology. 3r33545. 3r33561. 3r3403. Ability to build through the process of creating new software. 3r33545. 3r33561. 3r3403. The ability to evaluate its process parameters, its intermediate results and manage it. 3r33545. 3r33561. 3r33547. .
3r33561. 3r3409. The main objectives for the development of the paradigm
3r33561. 3r33434. Theoretical problems 3r33424.
3r33561. As has been repeatedly noted, including in the book Kuhn, in most cases, scientists are engaged in solving potentially solvable problems, and less often they take on those that are not very clear how to approach. But these are our tasks. Here are the main ones:
3r33561. 3r33395. 3r33561. 3r3403. Constructive definition of the mental model. 3r33545. 3r33561. 3r3403. Finding constructive criteria for assessing the degree of abstractness /ideality vs. concreteness /materiality of models. 3r33545. 3r33561. 3r3403. Finding criteria for the selection of candidates for the role of intermediate and additional models. 3r33545. 3r33561. 3r3403. Selection and development of criteria and methods for comparing models of various types, including their direct and reverse tracing. 3r33545. 3r33561. 3r3403. Development of methods for automated and automatic transformation of models. 3r33545. 3r33561. 3r3406.
3r33561. 3r33434. Practical problems 3r33424.
3r33561. 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: 3r3451. 3r33561. 3r33395. 3r33561. 3r3403. 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 transformed models 3-33545. 3r33561. 3r3403. Creating the necessary technical and teaching literature and other medial teaching material. 3r33545. 3r33561. 3r3403. Organizing forums and conferences on this topic 3r3353545. 3r33561. 3r3406.
3r33561. 3r3409. Conclusion 3r33410.
3r33561. This article attempts to define the paradigm of software engineering 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.
3r33561. 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 developed system of interconnected models. However, I want to believe that the shortcomings will soon be overcome.
3r33561. 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.
3r33561. 3r33434. Literature
3r33561. 1. IEEE Standard Glossary of Software Engineering Terminology, IEEE std ???-199? 1990. 3r3451. 3r33561. 2. Kuhn, Thomas S. The Scientific Revolutions. 3rd ed. Chicago, IL: University of Chicago Press, 1996.
3r33561. 3. Programming paradigm:
en.wikipedia.org/wiki/Programming_paradigm (state - 08/27/2018)
3r33561. 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.
3r33561. 5. Software Engineering Paradigms And Models Information Technology Essay
3r33561. www.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (state - 08/27/2018)
3r33561. 6. Reification (computer science) en.wikipedia.org/wiki/Reification_ (computer_science) (state - 08/27/2018)
3r33561. 7. Fedor Ivanovich Tyutchev. Silentium! (Silence (Latin), 1829.
3r33561. 8. Borovik, Alexandre. Mathematics under the microscope: notes on the cognitive aspects of mathematical practice. American Mathematical Society. ISBN-13: 978-0821847619.
3r33561. Illustration: geralt 3r33557. 3r33561. 3r33561.
3r33561. 3r33557. 3r33561. 3r33561. 3r33464. Only registered users can participate in the survey. 3rr3465. Enter
, you are welcome.
3r33561. 3r33561. 3r33470. 3r33561.
3r33561. 3r37474. How close is this topic to you? 3r33540. 3r33561. 3r33557. 3r33561. 3r33561. 3r38080. 3r33561.
3r33561. 3r33333. 3r33561. 3r33535. 3r33561.
3r? 3539. Not interested. This is a bare theorizing with no practical meaning. 3r33540. 3r33561. 3r33542. 3r33561. 3r33561. 3r33545. 3r33561. 3r33333. 3r33561. 3r33535. 3r33561.
3r? 3539. I did not understand some theses of the author. 3r33540. 3r33561. 3r33542. 3r33561. 3r33561. 3r33545. 3r33561. 3r33333. 3r33561. 3r33535. 3r33561.
3r? 3539. With some of the author's theses, I disagree 3r33540. 3r33561. 3r33542. 3r33561. 3r33561. 3r33545. 3r33561. 3r33333. 3r33561. 3r33535. 3r33561.
3r? 3539. The article interested me. I will wait for the continuation of the series with practically useful information and recommendations. 3r33540. 3r33561. 3r33542. 3r33561. 3r33561. 3r33545. 3r33561. 3r33547. 3r33561. 3r33561. 3r33550. 3r33561. 3r33557. 3r33561. 3r33554. 2 users have voted. There are no abstentions. 3r33557. 3r33561. 3r33557. 3r33561. 3r33561. 3r33561. 3r33561.
It may be interesting
RFP response software
RFP response software