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:
Дуализм этого понятия заключается в том, что парадигма с одной стороны характеризуется через сообщество признающих её специалистов. Именно специалисты определённой области определяют, создают и развивают её части. С другой стороны, признание определённой парадигмы означает для специалиста присоединение к такому сообществу.
Под парадигмами я подразумеваю признанные всеми научные достижения, которые в течение определенного времени дают научному сообществу модель постановки проблем и их решений…
Вводя этот термин, я имел в виду, что некоторые общепринятые примеры фактической практики научных исследований — примеры, которые включают закон, теорию, их практическое применение и необходимое оборудование, — все в совокупности дают нам модели, из которых возникают конкретные традиции научного исследования.
Дуализм этого понятия заключается в том, что парадигма с одной стороны характеризуется через сообщество признающих её специалистов. Именно специалисты определённой области определяют, создают и развивают её части. С другой стороны, признание определённой парадигмы означает для специалиста присоединение к такому сообществу.
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
Авторы описанных в [3] и [4] парадигм концентрируются на узкой под-области программной инженерии, а именно — написании программ на том или ином языке программирования. Я думаю, многие профессионалы согласны с мнением, что реальные программные проекты не получается выполнить в рамках только одной из этих парадигм (например — функционального программирования).
Описанная в этой статье парадигма, напротив, применима к самым разным предметным областям и фазам создания программного обеспечения.
Описанная в этой статье парадигма, напротив, применима к самым разным предметным областям и фазам создания программного обеспечения.
On the limitations of software project management paradigms
Некоторые авторы, например, в обзоре [5], называют парадигмами различные подходы или модели организации и проведения программных проектов. Например, сравниваются модели водопада, V-модель или Agile-модель. Вряд ли эти подходы, в отличие от парадигм программирования, упомянутых выше, можно назвать парадигмами в духе определения Куна в силу их относительной теоретической простоты и отсутствия широкой теоретической базы.
Предлагаемая в данной статье парадигма тоже пока не обладает собственной развитой теоретической базой, однако уже сегодня видны пути её развития.
Предлагаемая в данной статье парадигма тоже пока не обладает собственной развитой теоретической базой, однако уже сегодня видны пути её развития.
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
Суть используемого в этой статье расширения классического определения понятия материализации можно определить следующим образом.
Уже в самых ранних из дошедших до нас философских трактах было принято противопоставлять Идеальноe (мир идей) Материальному (миру вещей).
Идеальное мы можем в лучшем случае ощущать (или думать, что мы это ощущаем). Индикатором такого ощущения Идеального может быть изменение настроения или хода мыслей после прослушанного музыкального произведения, прочитанного фрагмента книги и т.д. Разумеется, я имею в виду опосредованное воздействие, например музыки, на наше сознание, а не примитивное физиологическое подчинение организма грохоту рок-концерта или ритму дискотеки.
Попытки сформулировать наше ощущение Идеального как правило не приводят к успеху.
Об этом замечательно сказал великий русский поэт Федор Иванович Тютчев:
Перейдём теперь от рассмотрения понятия Идеального к рассмотрению Материального. Мы можем ощущать и регистрировать материальные объекты вокруг нас, различать качественно их свойства. Свойства многих объектов можно объективно измерять. Мы можем также объективно выделять иерархии и иные структуры материальных объектов.
Уже в самых ранних из дошедших до нас философских трактах было принято противопоставлять Идеальноe (мир идей) Материальному (миру вещей).
Идеальное мы можем в лучшем случае ощущать (или думать, что мы это ощущаем). Индикатором такого ощущения Идеального может быть изменение настроения или хода мыслей после прослушанного музыкального произведения, прочитанного фрагмента книги и т.д. Разумеется, я имею в виду опосредованное воздействие, например музыки, на наше сознание, а не примитивное физиологическое подчинение организма грохоту рок-концерта или ритму дискотеки.
Попытки сформулировать наше ощущение Идеального как правило не приводят к успеху.
Об этом замечательно сказал великий русский поэт Федор Иванович Тютчев:
Как сердцу высказать себя?Даже практические идеи типа мелкого ремонта по дому или приготовления новой вариации знакомого блюда вначале трудно сформулировать. И только после обдумывания либо попытки объяснить другому, идея приобретает всё более чёткие «очертания».
Другому как понять тебя?
Поймёт ли он чем ты живёшь?
Мысль изречённая есть ложь...[7]
Перейдём теперь от рассмотрения понятия Идеального к рассмотрению Материального. Мы можем ощущать и регистрировать материальные объекты вокруг нас, различать качественно их свойства. Свойства многих объектов можно объективно измерять. Мы можем также объективно выделять иерархии и иные структуры материальных объектов.
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 share the world of the phenomena of our internal and external world Uinto 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
В простых системах или при несложных добавлениях/изменениях больших систем разработчик сразу пишет код или конфигурирует систему на основании своей ментальной модели. Однако в большинстве случаев создаются промежуточные модели разной сложности и уровня формализации — от простого списка требований до обширных формальных моделей (например — UML или ВРМN моделей)
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
Интересные факты и соображения по поводу материализации идей в математике можно найти в параграфе 7.3 в книге[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?
Конечный продукт программирования — программный код. И хотя он при выполнении на hardware отображается в конкретные физические объекты (электрические сигналы и поля различной физической природы), эти объекты трудно сравнить с гайками, шестерёнками и корпусами машин. С другой стороны, программный код близок к математическим формулам, а иногда является их прямым отображением. Однако в любой реальной программной системе надо учитывать массу конкретных аспектов окружения и взаимодействия с пользователями или другими системами. Это делает программный код более конкретным, чем математические формулы.
What software engineering can learn from neighboring areas in terms of using models
Рассмотрим вначале математику.
За несколько тысяч лет своего развития математика научилась описывать одни и те же феномены реального или воображаемого мира в очень разных терминах. Древние греки научились чисто словесные описания задач подменять геометрическими фигурами и с их помощью решать практически важные задачи. Позже появилось понимание о взаимозаменяемости отрезков на плоскости и чисел. Затем кристаллизовалось понятие алгебраической переменной и сведения геометрических задач к системам алгебраических уравнений.
Сегодня уже школьники старших классов знают, что одну и ту же задачу можно решить разными способами (например — геометрически или алгебраически) и что одна и та же математическая модель, например — алгебраическое уравнение, описывает много самых разных физических, химических и т.д. явлений.
Математика хорошо научилась не только описывать одни и те же реальные или воображаемые объекты и процессы с помощью моделей самой разной математической природы. Важным достижении математики является умение определять степень подобия моделей из разных разделов математики а также умение трансформировать их друг в друга. Многие прорывные решения важнейших математических проблем последних лет являются по сути цепочками отдельных доказательств, каждое из которых использует специализированных аппарат из специального раздела математики. В местах соединения этих узкоспециализированных доказательств математики умело трансформирует модели одного раздела математики в модели другого раздела. В программировании нечто подобное происходит уже сейчас при компилировании исходного кода программы и при генерации кода из DSL (Domain Specific Language) или метаданных. Но культура работы с моделями в области программного инжиниринга далеко отстаёт от математической.
А чему программная инженерия может поучиться в плане материализации у машиностроения?
Во многих отраслях и даже внутри крупных концернов существуют цепочки согласованных формальных и семи-формальных моделей. Эти цепочки заканчиваются моделями, на основании которых изготавливаются и монтируются физические объекты — приборы и машины. Как правило, на большинство типов промежуточных моделей существуют формальные методы проверки их корректности (технические нормы). Модели являются основным языком коммуникации специалистов разного профиля в процессе проектирования и изготовления машиностроительных изделий.
На этом фоне ситуации в ИТ выглядит намного хуже. Только внутри очень крупных ИТ концернов в последние годы делались попытки построения сопоставимых наборов моделей и процессов. Мелкие фирмы и ИТ-стартапы, как правило, не только не имеют развитых формальных моделей и процессов, но даже не подозревают об их существовании. Такое положение определяется в настоящий момент следующими факторами:
Мультимодельность мира
За несколько тысяч лет своего развития математика научилась описывать одни и те же феномены реального или воображаемого мира в очень разных терминах. Древние греки научились чисто словесные описания задач подменять геометрическими фигурами и с их помощью решать практически важные задачи. Позже появилось понимание о взаимозаменяемости отрезков на плоскости и чисел. Затем кристаллизовалось понятие алгебраической переменной и сведения геометрических задач к системам алгебраических уравнений.
Сегодня уже школьники старших классов знают, что одну и ту же задачу можно решить разными способами (например — геометрически или алгебраически) и что одна и та же математическая модель, например — алгебраическое уравнение, описывает много самых разных физических, химических и т.д. явлений.
Морфизм моделей и согласованность понятий и нотаций
Математика хорошо научилась не только описывать одни и те же реальные или воображаемые объекты и процессы с помощью моделей самой разной математической природы. Важным достижении математики является умение определять степень подобия моделей из разных разделов математики а также умение трансформировать их друг в друга. Многие прорывные решения важнейших математических проблем последних лет являются по сути цепочками отдельных доказательств, каждое из которых использует специализированных аппарат из специального раздела математики. В местах соединения этих узкоспециализированных доказательств математики умело трансформирует модели одного раздела математики в модели другого раздела. В программировании нечто подобное происходит уже сейчас при компилировании исходного кода программы и при генерации кода из DSL (Domain Specific Language) или метаданных. Но культура работы с моделями в области программного инжиниринга далеко отстаёт от математической.
Модели в машиностроении
А чему программная инженерия может поучиться в плане материализации у машиностроения?
Во многих отраслях и даже внутри крупных концернов существуют цепочки согласованных формальных и семи-формальных моделей. Эти цепочки заканчиваются моделями, на основании которых изготавливаются и монтируются физические объекты — приборы и машины. Как правило, на большинство типов промежуточных моделей существуют формальные методы проверки их корректности (технические нормы). Модели являются основным языком коммуникации специалистов разного профиля в процессе проектирования и изготовления машиностроительных изделий.
На этом фоне ситуации в ИТ выглядит намного хуже. Только внутри очень крупных ИТ концернов в последние годы делались попытки построения сопоставимых наборов моделей и процессов. Мелкие фирмы и ИТ-стартапы, как правило, не только не имеют развитых формальных моделей и процессов, но даже не подозревают об их существовании. Такое положение определяется в настоящий момент следующими факторами:
- Недостаточной эффективностью существующих моделей и процессов
- Недостаточной известностью этих моделей за пределами больших концернов
- Недостатками образования разработчиков и особенно менеджеров
- Отставанием университетского образования от реальных потребностей программной инженерии.
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?
Отметим, что хотя в определении RPSE говорится о построении цепочек моделей, тем не менее парадигму предложено называть материализацией а не моделизацией. Тем самым делается попытка подчеркнуть особенность цепочек моделей, которые становятся всё менее абстрактными/идеальными и все более конкретными/материальными.
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
Очень часто над проблемой работает одновременно несколько человек. Каждый из них имеет свою собственную ментальную модель и, возможно, свои промежуточные модели и фрагменты кода.
Нередко код на некотором языке программирования фактически отсутствует, поскольку создание нового решения сводится к управлению масками конфигураторов или генераторов, как например при работе с инструментами разработки в системах типа SAP или WebSphere.
Варианты превращения вручную написанного или автоматически сгенерированного кода в исполняемый код в наше время стали также очень многообразны.
И наконец, само понятие процессора, на котором исполняется код, также значительно расширилось в последние годы. Если раньше это были процессоры, которые находились на платах, которые в свою очередь были вставлены в корпуса десктопов, ноутбуков и серверных стоек, то теперь это множество расширилось различными чипами самого разного размера, которые встроены в мобильные телефоны, игровые приставки, видеокамеры наблюдения, «умные» домашние приборы и т.д. Не говоря уже о квантовых компьютерах.
И тем не менее, RPSE, в силу её общности, применимо ко всем перечисленным выше областям.
Нередко код на некотором языке программирования фактически отсутствует, поскольку создание нового решения сводится к управлению масками конфигураторов или генераторов, как например при работе с инструментами разработки в системах типа SAP или WebSphere.
Варианты превращения вручную написанного или автоматически сгенерированного кода в исполняемый код в наше время стали также очень многообразны.
И наконец, само понятие процессора, на котором исполняется код, также значительно расширилось в последние годы. Если раньше это были процессоры, которые находились на платах, которые в свою очередь были вставлены в корпуса десктопов, ноутбуков и серверных стоек, то теперь это множество расширилось различными чипами самого разного размера, которые встроены в мобильные телефоны, игровые приставки, видеокамеры наблюдения, «умные» домашние приборы и т.д. Не говоря уже о квантовых компьютерах.
И тем не менее, RPSE, в силу её общности, применимо ко всем перечисленным выше областям.
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
Эти модели являются отражением ментальных моделей. Степенью близости ментальных моделей к реальным моделям должна бы заниматься психология или теоретическая педагогика. К сожалению, автору не известны серьёзные работы в этой области. (Это не означает, что такие работы не существуют).
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 (lat.), 1829.
8. Borovik, Alexandre. Mathematics under the microscope: notes on cognitive aspects of mathematical practice. American Mathematical Society. ISBN-13: 978-0821847619.
Illustration: geralt