О семантике и прагматике проекта парадигмы материализации идей

Это третий из цикла и последний комментарий к статье Виктора Сиротина «Программирование — это материализация идей».

В первую очередь, необходимо заметить, что участники телеграм-группы КОДИФИКАЦИЯ являются «держателями» определенных идей или ментальных репрезентаций, «материализуя» их в код (выражения на естественном языке). То есть наша виртуальная организация — коллектив разработчиков программного (или информационного) обеспечения на естественном языке. Вся наша потенциальная деятельность может быть моделью процесса конструирования и реализации определенной парадигмы. Можно провести, например, аналогию с тем же нейролингвистическим программированием. Именно, в таком ракурсе, как пример, может быть принят основной тезис автора «манифеста». Более того, среди участников группы есть эксперт в реализации сквозной технологии информационного обеспечения - БИМ. Если наши амбиции распространяются на участие в создании некой универсальной эпистемы (парадигма в лексике Фуко).

Следуя семантики автора манифеста (или декларации), в части той же трассировки, первые прагматические шаги можно сделать без спецификации модели и использовать общее определение, автором которого является участник нашей группы.

Опять же, поскольку на текущий момент отсутствуют критерии определения «абстрактности» моделей (в этом аспекте в дальнейшем можно рассмотреть концепцию метамодельного или метасистемного перехода Турчина), на начальном этапе предлагается процитировать содержание авторской декларации в следующей редакции.

Определение и контуры парадигмы материализации идей

Разработка программного обеспечения — это материализация идей посредством трансформации моделей в код, выполняемый на компьютерах.

В рамках предлагаемой парадигмы:

1. Все основные процессы разработки программного обеспечения являются вариантами (реализациями) процесса построения цепочек моделей. Последней в этой цепочке является, как правило, программный код.
2. Суть разработки программного обеспечения заключается в создании таких цепочек.
3. Все основные вопросы оптимизации разработки, снижения её стоимости и повышения её качества могут быть сведены к оптимизации построения соответствующей цепочки моделей.

Следующим шагом к уточнению парадигмы после попытки дать её основное определение является попытка перечислить основные категории феноменов, которые она затрагивает. Нам надо попытаться перечислить типы моделей ...

К теме "Классификация моделей" ...

Зачем программной инженерии нужна «сквозная» парадигма?

Наличие «сквозной» парадигмы открывает перед участниками использующего эту парадигму процесса создания, модификации и использования программного обеспечения следующие возможности:

• Возможность всем участникам процесса использовать одинаковую терминологию.
• Возможность строить сквозной процесс создания нового ПО.
• Возможность оценивать его параметры процесса, его промежуточные результаты и управлять им.

Основные задачи по развитию парадигмы

Теоретические задачи

В большинстве случаев учёные занимаются решением потенциально решаемых задач, и реже берутся за такие, к которым не очень понятно как подойти. Но именно таковы наши задачи. Вот основные из них:

1. Конструктивное определение понятия модели.
2. Нахождение конструктивных критериев оценки степени абстрактности моделей * (см. ссылки).
3. Нахождение критериев для отбора кандидатов на роль промежуточных и дополнительных моделей.
4. Отбор и разработка критериев и методов сравнения моделей различных типов, включая их прямую и обратную трассировку.
5. Разработка методов автоматизированной и автоматической трансформации моделей.

Практические задачи

Наряду с теоретическими задачами для развития и внедрения описываемой парадигмы в практику программной инженерии необходимо решить как минимум следующие практические задачи:

1. Создание инструментов для: а) Экстрагирования и фиксации моделей, б) Автоматизированной и автоматической трансформации моделей в промежуточные, в) Трассировки и оценки изменения содержания моделей
2. Создание необходимой технической и обучающей литературы и иного медиального обучающего материала.
3. Организация форумов и конференций на эту тему

P. S. Учитывая комментарии из "телеграм" и "принцип трассировки" предлагается на следующем шаге за основу классификации моделей взять паттерны проектирования, реализованные в UML.

*- Некоторые ресурсы на тему "абстрагирования"

С. А. Шишкин