Программирование — это материализация идей
Основной тезис этой статьи: Разработку программного обеспечения следует рассматривать как материализацию идей посредством трансформации ментальных моделей в программный код.
В статье описывается парадигма материализации идей в программной инженерии (engl.: RPSE: Reification as Paradigm of Software Engineering).
Английский вариант статьи: RPSE: Reification as Paradigm of Software Engineering. Сокращение RPSE используется далее в тексте для обозначения описываемой парадигмы.
Основные определения
Перед тем как перейти к обсуждению основных тезисов этой статьи, необходимо договориться о значении базовых терминов, используемых в ней.
Программная инженерия
Под программной инженерией мы будем понимать классическое определение дисциплины Software Engineering из словаря IEEE [1]: Программная инженерия — это «The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software».
Парадигма
Используемый в этой статье термин парадигма, опирается на ставшее классическим определение парадигмы Томаса Куна [2]: Парадигма — это круг проблем, набор понятий, общепризнанных правил и законов, приёмов решения задач в некоторой области науки.
Под парадигмами я подразумеваю признанные всеми научные достижения, которые в течение определенного времени дают научному сообществу модель постановки проблем и их решений…
Вводя этот термин, я имел в виду, что некоторые общепринятые примеры фактической практики научных исследований — примеры, которые включают закон, теорию, их практическое применение и необходимое оборудование, — все в совокупности дают нам модели, из которых возникают конкретные традиции научного исследования.
Дуализм этого понятия заключается в том, что парадигма с одной стороны характеризуется через сообщество признающих её специалистов. Именно специалисты определённой области определяют, создают и развивают её части. С другой стороны, признание определённой парадигмы означает для специалиста присоединение к такому сообществу.
Томас Кун рассматривал в своей книге научные парадигмы. Однако очень скоро после выхода первого издания книги проявилась полезность использования этого понятия в технике и различных областях социальной жизни. В связи с этим в специальной и популярной литературе стали появляться многочисленные публикации о парадигмах и их смене в автомобилестроении, градостроительстве, лечении определённых болезней и т.д.
Программная инженерия и особенно её важная составная часть — программирование, не стали исключением. На данный момент существует много конкурирующих парадигм программирования. Их перечислению посвящена отдельная статья в Википедии[3], а также такие интересные обзоры как [4].
Описанная в этой статье парадигма, напротив, применима к самым разным предметным областям и фазам создания программного обеспечения.
Предлагаемая в данной статье парадигма тоже пока не обладает собственной развитой теоретической базой, однако уже сегодня видны пути её развития.
Материализация идей
Используемый в этой статье термин материализация идей (engl: reification) является расширением классического определения reification в информатике: «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].
Уже в самых ранних из дошедших до нас философских трактах было принято противопоставлять Идеальноe (мир идей) Материальному (миру вещей).
Идеальное мы можем в лучшем случае ощущать (или думать, что мы это ощущаем). Индикатором такого ощущения Идеального может быть изменение настроения или хода мыслей после прослушанного музыкального произведения, прочитанного фрагмента книги и т.д. Разумеется, я имею в виду опосредованное воздействие, например музыки, на наше сознание, а не примитивное физиологическое подчинение организма грохоту рок-концерта или ритму дискотеки.
Попытки сформулировать наше ощущение Идеального как правило не приводят к успеху.
Об этом замечательно сказал великий русский поэт Федор Иванович Тютчев:
Даже практические идеи типа мелкого ремонта по дому или приготовления новой вариации знакомого блюда вначале трудно сформулировать. И только после обдумывания либо попытки объяснить другому, идея приобретает всё более чёткие «очертания».Как сердцу высказать себя?
Другому как понять тебя?
Поймёт ли он чем ты живёшь?
Мысль изречённая есть ложь…[7]
Перейдём теперь от рассмотрения понятия Идеального к рассмотрению Материального. Мы можем ощущать и регистрировать материальные объекты вокруг нас, различать качественно их свойства. Свойства многих объектов можно объективно измерять. Мы можем также объективно выделять иерархии и иные структуры материальных объектов.
Чтобы оценивать или измерять (получать количественные характеристики) не обязательно иметь предмет. Достаточно иметь его модель. Более того, во многих практически интересных ситуациях модель можно использовать и без предмета. Модели можно обсуждать с другими. О моделях можно договариваться. Модели можно стандартизировать (формализовать).
В некоторых областях человеческой деятельности стандартизация моделей зашла так далеко, что изготовленные на основе стандартизованной модели (например — чертежа) разными людьми или автоматами детали (например болты с резьбой) с технологической точки зрения и визуально будут неотличимы друг от друга.
Отдавая себе отчёт об относительной неточности предлагаемого определения, далее в этой статье я буду разделять мир феноменов нашего внутреннего и внешнего мира U на две части:
U = M + I
где множество М состоит их феноменов, которые можно объективно регистрировать или измерять (материальный мир) и I — всё остальное.
Применима ли эта формула к абсолютно всем феноменам окружающего мира — это открытый философский вопрос. Далее в этой статье мы сузим область применения этой формулы на мир феноменов из мира программной инженерии.
Или, сформулировав в виде тезиса: Всё множество относящихся к программной инженерии феноменов можно разделить на подмножество идеальных и подмножество материальных. При этом материальный феномены регистрируемы либо измеряемы на основе их моделей.
Процесс создания или изменения программной системы заканчивается в большинстве случаев созданием того или иного кода, который с помощью компьютера отображается в физический процесс (феномен реального мира).
Начинается же этот процесс возникновением неких идей о будущей системе в головах заказчиков или разработчиков. Эти идеи и представления мы будем именовать ментальной моделью.
В простых системах или при несложных добавлениях/изменениях больших систем разработчик сразу пишет код или конфигурирует систему на основании своей ментальной модели. Однако в большинстве случаев создаются промежуточные модели разной сложности и уровня формализации — от простого списка требований до обширных формальных моделей (например — UML или ВРМN моделей)
Материализация идей в соседних с Программной Инженерией областях
Понятно, что приведённое выше определение не является радикально новым и широко применяется (осознанно или неосознанно) в соседних программированию областях интеллектуального труда. Рассмотрим для примера две таких области — машиностроение и математику.
Эти две области используют материализацию идей давно и эффективно. Программированию у них есть в этом отношении чему поучиться.
В машиностроении мы видим полный цикл материализации идей — от возникновения идеи в голове конструктора через её продумывание, детализацию, отображение в модель и наконец — изготовление из определённого материала.
По-другому обстоит дело в математике
Интересные факты и соображения по поводу материализации идей в математике можно найти в параграфе 7.3 в книге[8].
«Конечным продуктом» математики являются формальные модели со строго доказанными свойствами.
С этой точки зрения программирование лежит посредине. Графически это можно изобразить следующим образом:
Таким образом, математика использует большее количество более абстрактных моделей и практически совсем не касается области предельно конкретных моделей типа машиностроительных чертежей.
Машиностроение же наоборот, использует относительно мало абстрактных моделей, но много конкретных. Например таких, по которым однозначно могут быть изготовлены физические объекты.
С этой точки зрения программирование лежит посередине.
Конечный продукт программирования — программный код. И хотя он при выполнении на hardware отображается в конкретные физические объекты (электрические сигналы и поля различной физической природы), эти объекты трудно сравнить с гайками, шестерёнками и корпусами машин. С другой стороны, программный код близок к математическим формулам, а иногда является их прямым отображением. Однако в любой реальной программной системе надо учитывать массу конкретных аспектов окружения и взаимодействия с пользователями или другими системами. Это делает программный код более конкретным, чем математические формулы.
Мультимодельность мира
За несколько тысяч лет своего развития математика научилась описывать одни и те же феномены реального или воображаемого мира в очень разных терминах. Древние греки научились чисто словесные описания задач подменять геометрическими фигурами и с их помощью решать практически важные задачи. Позже появилось понимание о взаимозаменяемости отрезков на плоскости и чисел. Затем кристаллизовалось понятие алгебраической переменной и сведения геометрических задач к системам алгебраических уравнений.
Сегодня уже школьники старших классов знают, что одну и ту же задачу можно решить разными способами (например — геометрически или алгебраически) и что одна и та же математическая модель, например — алгебраическое уравнение, описывает много самых разных физических, химических и т.д. явлений.
Морфизм моделей и согласованность понятий и нотаций
Математика хорошо научилась не только описывать одни и те же реальные или воображаемые объекты и процессы с помощью моделей самой разной математической природы. Важным достижении математики является умение определять степень подобия моделей из разных разделов математики, а также умение трансформировать их друг в друга. Многие прорывные решения важнейших математических проблем последних лет являются по сути цепочками отдельных доказательств, каждое из которых использует специализированных аппарат из специального раздела математики. В местах соединения этих узкоспециализированных доказательств математики умело трансформирует модели одного раздела математики в модели другого раздела. В программировании нечто подобное происходит уже сейчас при компилировании исходного кода программы и при генерации кода из DSL (Domain Specific Language) или метаданных. Но культура работы с моделями в области программного инжиниринга далеко отстаёт от математической.
Модели в машиностроении
А чему программная инженерия может поучиться в плане материализации у машиностроения?
Во многих отраслях и даже внутри крупных концернов существуют цепочки согласованных формальных и семи-формальных моделей. Эти цепочки заканчиваются моделями, на основании которых изготавливаются и монтируются физические объекты — приборы и машины. Как правило, на большинство типов промежуточных моделей существуют формальные методы проверки их корректности (технические нормы). Модели являются основным языком коммуникации специалистов разного профиля в процессе проектирования и изготовления машиностроительных изделий.
На этом фоне ситуации в ИТ выглядит намного хуже. Только внутри очень крупных ИТ концернов в последние годы делались попытки построения сопоставимых наборов моделей и процессов. Мелкие фирмы и ИТ-стартапы, как правило, не только не имеют развитых формальных моделей и процессов, но даже не подозревают об их существовании. Такое положение определяется в настоящий момент следующими факторами:
- Недостаточной эффективностью существующих моделей и процессов
- Недостаточной известностью этих моделей за пределами больших концернов
- Недостатками образования разработчиков и особенно менеджеров
- Отставанием университетского образования от реальных потребностей программной инженерии.
Определение и контуры парадигмы материализации идей (RPSE)
Мы определили все необходимые понятия, чтобы дать основное определение предлагаемой парадигмы. Вот оно:
Разработка программного обеспечения — это материализация идей посредством трансформации ментальных моделей в код, выполняемый на компьютерах.
В рамках предлагаемой парадигмы:
- Все основные процессы разработки программного обеспечения являются конкретными вариантами (реализациями) процесса построения цепочек ментальных и материальных моделей. Последней наиболее конкретной моделью в этой цепочке является, как правило, программный код.
- Суть разработки программного обеспечения заключается в создании таких цепочек.
- Все основные вопросы оптимизации разработки, снижения её стоимости и повышения её качества могут быть сведены к оптимизации построения соответствующей цепочки моделей.
Отметим, что хотя в определении RPSE говорится о построении цепочек моделей, тем не менее парадигму предложено называть материализацией, а не моделизацией. Тем самым делается попытка подчеркнуть особенность цепочек моделей, которые становятся всё менее абстрактными/идеальными и все более конкретными/материальными.
Приведённое выше определение имеет свои особенности и вариации в разных областях программной инженерии. Только в очень небольшом количестве случаев бывает так, что в голове программиста сначала полностью вызревает ясное представление о способе решения стоящей перед ним задачи, которое он после этого за небольшое время отображает в код на языке программирования. В большинстве реальных проектов процессы поиска решения и его реализация сосуществуют, развиваются параллельно и взаимодействуют друг с другом. Т.е. ментальные модели, код и зачастую промежуточные модели (в виде теста, изображений, формальных моделей типа UML) растут и изменяются параллельно, оказывая влияние друг на друга.
Нередко код на некотором языке программирования фактически отсутствует, поскольку создание нового решения сводится к управлению масками конфигураторов или генераторов, как например при работе с инструментами разработки в системах типа SAP или WebSphere.
Варианты превращения вручную написанного или автоматически сгенерированного кода в исполняемый код в наше время стали также очень многообразны.
И наконец, само понятие процессора, на котором исполняется код, также значительно расширилось в последние годы. Если раньше это были процессоры, которые находились на платах, которые в свою очередь были вставлены в корпуса десктопов, ноутбуков и серверных стоек, то теперь это множество расширилось различными чипами самого разного размера, которые встроены в мобильные телефоны, игровые приставки, видеокамеры наблюдения, «умные» домашние приборы и т.д. Не говоря уже о квантовых компьютерах.
И тем не менее, RPSE, в силу её общности, применимо ко всем перечисленным выше областям.
Что ещё можно сказать об определённой парадигме сегодня, можно ли как то очертить её контуры поточнее?
Следующим шагом к уточнению парадигмы после попытки дать её основное определение является попытка перечислить основные категории феноменов, которые она затрагивает. Вспоминая определение Куна, нам надо попытаться перечислить типы моделей, которые вводит и использует RPSE.
Модели RPSE можно разделить на три основные категории:
- Ментальные модели
- Код на языках программирования или его эквиваленты как модели исполняемого кода.
- Промежуточные модели.
Наименее исследованными в этой триаде являются ментальные модели. Что конкретно понимается под ними?
Ментальные модели — это термин для обозначения идей, которые существует в голове заказчиков, программистов и других участников процесса и на основании которых возникает в конце концов исполняемый код. Наличие таких моделей бесспорно и может быть на психическом уровне зарегистрировано, например — самим программистом. На современном уровне развития техники эти модели не могут быть достоверно измерены приборами.
Одним из хорошо работающих способов фиксации и измерения таких моделей является интевьюирование носителя идеи. Очевидно, что процесс интервьюирования или схожие с ним резко влияют на саму ментальную модель. Каждый из нас наверняка не раз переживал ситуацию, когда одна только попытка сформулировать проблему с целью посоветоваться с коллегой приводила к «озарению», а часто и к решению проблемы.
Интервьюирование позволяет на основании правильно сформулированных вопросов относительно объективно построить модели различной сложности. Наиболее употребительными являются:
Структурные модели:
- Списки с бинарными, перечислительными (enumeration), числовыми, строковыми и иными значениями.
- Графовые и сетевые структуры данных
Модели описания поведения:
- Семи-формальные модели определения поведения
- Формальные модели определения поведения (например — конечные автоматы)
Эти модели являются отражением ментальных моделей. Степенью близости ментальных моделей к реальным моделям должна бы заниматься психология или теоретическая педагогика. К сожалению, автору не известны серьёзные работы в этой области. (Это не означает, что такие работы не существуют).
Зачем программной инженерии нужна «сквозная» парадигма?
Наличие «сквозной» парадигмы открывает перед участниками использующего эту парадигму процесса создания, модификации и использования программного обеспечения следующие возможности:
- Возможность всем участникам процесса использовать одинаковую терминологию.
- Возможность строить сквозной процесс создания нового ПО.
- Возможность оценивать его параметры процесса, его промежуточные результаты и управлять им.
.
Основные задачи по развитию парадигмы
Теоретические задачи
Как уже неоднократно отмечалось, в том числе и в книге Куна[2], в большинстве случаев учёные занимаются решением потенциально решаемых задач, и реже берутся за такие, к которым не очень понятно как подойти. Но именно таковы наши задачи. Вот основные из них:
- Конструктивное определение понятия ментальной модели.
- Нахождение конструктивных критериев оценки степени абстрактности/идеальности vs. конкретности/материальности моделей.
- Нахождение критериев для отбора кандидатов на роль промежуточных и дополнительных моделей.
- Отбор и разработка критериев и методов сравнения моделей различных типов, включая их прямую и обратную трассировку.
- Разработка методов автоматизированной и автоматической трансформации моделей.
Практические задачи
Наряду с теоретическими задачами для развития и внедрения описываемой парадигмы в практику программной инженерии необходимо решить как минимум следующие практические задачи:
- Создание инструментов для: а) Экстрагирования и фиксации ментальных моделей. б) Автоматизированной и автоматической трансформации ментальных моделей в промежуточные. в) Трассировки и оценки изменения содержания трансформируемых моделей
- Создание необходимой технической и обучающей литературы и иного медиального обучающего материала.
- Организация форумов и конференций на эту тему
Заключение
В этой статье сделана попытка определить парадигму программной инженерии как материализации идей. Слово определить (а не открыть) употреблено здесь не случайно. Фактически участники ИТ-проектов давно занимаются созданием, трансформацией и использованием моделей, может не отдавая себе в том отчета.
В строгом смысле определения Куна описанный подход пока не может претендовать на право именоваться парадигмой, а только кандидатом в парадигмы, поскольку не обладает обширным сообществом поддерживающих его людей, а также развитой системой взаимосвязанных моделей. Однако, хочется верить, что недостатки будут уже в скором времени преодолены.
Это первая статья из запланированной серии статей. В следующих статьях я собираюсь рассказать о ментальных и промежуточных моделях.
Литература
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 — 27.08.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 — 27.08.2018)
6. Reification (computer science) en.wikipedia.org/wiki/Reification_(computer_science) (state — 27.08.2018)
7. Федор Иванович Тютчев. Silentium! (Молчание (лат.), 1829 г.
8. Borovik, Alexandre. Mathematics under the microscope: notes on cognitive aspects of mathematical practice. American Mathematical Society. ISBN-13: 978–0821847619.
Иллюстрация: geralt
