В статье, опубликованной в Stack Overflow Blog, предлагается переосмыслить понятие программирования, ориентированного на модели (Model Oriented Programming) как направление, способное разделить требования к системе и её программный дизайн, а затем использовать саму модель для помощи в создании и сопровождении системы. Автор опирается на прежний опыт: 13 лет назад он разработал язык и среду разработки под названием Mo+, которые, по его словам, использовал в корпоративных проектах, однако идея не получила широкого распространения.
Материал не является объявлением доступного языка или нового исследовательского проекта, а представляет собой призыв к дальнейшим исследованиям и разработкам в этой области, особенно в контексте мира, где возрастает значение искусственного интеллекта и сложность программных систем.
Модель как структура и данные
Автор предлагает определять модель через два элемента: структуру, задающую правила или схему, и данные, соответствующие этой структуре. Структура является иерархической: она начинается с корневого узла и разветвляется на узлы и свойства, при этом при необходимости свойство может ссылаться на другой узел. С этой точки зрения схему реляционной базы данных можно представить в иерархическом виде, включающем такие узлы, как база данных, таблица, столбец и ключ, даже если сами данные распределены по строкам и связям.
В статье используется упрощённый сценарий ресторана для разъяснения идеи. Он включает рестораны, клиентов, сотрудников, позиции меню и связи между ними. Автор показывает несколько возможных структур для представления одного и того же сценария, поясняя, что выбор структуры влияет на удобство обхода модели и на способ написания зависящих от неё программ.
Четыре формы разработки, ориентированной на модели
- Неформальное моделирование: модели в сознании, на бумаге или на схемах, которые непосредственно не используются программными инструментами.
- Встроенное моделирование: модель внутри кода, как в ORM-фреймворках, таких как Entity Framework и NHibernate, или во фреймворках пользовательских интерфейсов, таких как Angular и React.
- Связанное моделирование: внешняя модель, обычно созданная с использованием UML, которая тесно связана с элементами кода и инструментами их управления.
- Раздельное моделирование: модель, сосредоточенная на требованиях, данных и рабочих процессах, при этом детальный дизайн кода остаётся за пределами модели, так что каждый элемент модели не связан с конкретным программным компонентом.
Автор считает, что наибольшие возможности дают связанное и раздельное моделирование, особенно последнее, поскольку требования помещаются в модель, а дизайн — в код. По его словам, личный опыт показал, что такое разделение сделало процесс моделирования и программирования более плавным.
От модели к системе
В статье использование программирования, ориентированного на модели, разделяется на три области. В переходном режиме программа интерпретирует модель и создаёт исходный код, конфигурационные файлы или документацию, которые впоследствии можно дорабатывать. В режиме моделирования моделей язык помогает создавать и сопровождать структуру модели и её данные. В целевом режиме язык непосредственно используется для построения среды системы и управления ею, что требует более полноценного языка.
Предлагаемые возможности языка
Одно из главных предложений — сделать структуру модели частью правил языка, чтобы напрямую работать с такими узлами, как Entity, Property и Relationship, вместо создания специальных классов и объектов для их представления. Автор также предлагает контекст модели, зависящий от местоположения программы внутри дерева данных, со стеком, позволяющим подниматься к родительским узлам или спускаться к дочерним элементам и искать среди них.
Другая идея представлена в виде «свойств, ориентированных на модель»: это независимые фрагменты кода, связанные с определённым типом узла и способные вычисляться для нескольких экземпляров. Такие свойства можно комбинировать для генерации кода, например создания определения класса или его свойств, либо использовать в операциях поиска и фильтрации. В переходном режиме свойство может включать операцию put для сохранения результата в файл или целевую среду.
Автор также предлагает динамические правила, при которых интерпретатор добавляет узлы модели и её свойства в правила языка при начале программной сессии. Это полезно, когда стандартная модель не содержит достаточной информации или когда модель специфична для определённой организации или области. Кроме того, он рассматривает контекстные правила, ограничивающие допустимые операции внутри разных частей программы, чтобы уменьшить побочные эффекты и разделить обязанности чтения и записи.
Почему это предложение важно?
Практическая ценность идеи заключается в попытке сделать модель исполняемой, а не просто отдельным проектным документом, не связанным с циклом разработки. Если требования, данные и рабочие процессы удастся связать с механизмами генерации и сопровождения, пригодными для повторного использования, это может уменьшить дублирование между моделью и кодом. Однако в статье не представлено стандартизированного языка, доступных инструментов или сравнительных результатов, подтверждающих превосходство этого подхода над существующими фреймворками моделирования и генерации кода.
Открытыми остаются важные вопросы: как управлять большими и изменяющимися моделями? Как тестировать сгенерированный код? Каковы ограничения динамических правил с точки зрения читаемости, безопасности и интеграции с инструментами разработки? Поэтому материал выглядит ценным исследовательским призывом к разработчикам языков и исследователям, а не готовым решением для немедленного использования.