Если я ошибаюсь, то надеюсь, что кто‑нибудь меня поправит. На сколько я понимаю TOGAF — это подход в соответствии с которым архитектура предприятия описывается на нескольких уровнях. Причём в TOGAF нет конкретной нотации, конкретных типов объектов, это просто идея, подход. А ArchiMate — это уже нотация с конкретными типами объектов и диаграммами, которая реализует подход TOGAF. ARIS тоже реализует TOGAF, но там уже другие диаграммы и объекты.
Спецификация ArchiMate, да, закрытая, но гуглятся неофициальные варианты
Да, эти диаграммы меня тоже смутили. Можно показывать отправку сообщения через triggering, а получение ответа через flow. Иногда они сразу отправку сообщения показывают через flow. Иногда вставляют промежуточный data object и показывают его отправку и получение через access. Очень большая вариативность. Но на сколько я понимаю, ArchiMate в первую очередь для моделирования бизнес‑вещей, а не технических и не математических. Поэтому нотация такая свободная. Здесь нет маркеров как в сетях Петри и нет строгой семантики
хочется найти «дотошное» описание всех соединителей в Archimate и примеры. В идеале полную онтологию Archimate в OWL
Есть спецификация в машиночитаемом виде: метамодель, правила какие связи какие объекты могут соединять, перечень точек зрения (например, точка зрения «Организация» включает актора, роли и подобные типы объектов). Но там нет человеческого описания в каких случаях какие типы связей использовать
Должна быть строгая нотация (строгие правила): и только один вариант описания верный (эталонный) — остальные нет (не очень). Это к вопросу строгой семантики в архитектурных моделях. Хотелось бы найти подборку с примерами на Archimate схем интеграции приложений. Также хотелось бы найти некий »Сокращенный вариант Archimate», желательно прямо в виде Соглашения о моделировании
Да, я не смог найти такое, нашёл только много разрозненных руководств, статей и курсов. И в этой статье как‑раз попробовал описать «сокращенный вариант ArchiMate» или «соглашение о моделировании», которое удобно для нашего проекта, с акцентом на процесс разработки, а не корпоративную архитектуру или ещё что‑то. Понятно, что статья написана в свободном неформальном стиле, но назначение статьи именно такое. Но для других компаний и проектов будет совершенно другое соглашение о моделировании
Ну, как минимум, у нас уже есть одновременное редактирование моделей разными пользователями, управление доступом, API для интеграции с другими системами, не только диаграммные, но и текстовые нотации, no‑code конструктор для создания своих нотаций моделирования, плюс в целом веб‑интерфейс приятнее.
На мой взгляд мы уступаем IBM Rational Rose или аналогичным продуктам в количестве поддерживаемых нотаций. Реализовать полностью UML — не очень тривиальная задача, на это действительно может уйти много времени. Но вопрос нужен ли полный UML. Мы пока активно добавляем более простые нотации.
Другая вещь, в которой мы уступаем — это обилие всякого обвеса в виде кодогенераторов или наоборот инструментов для обратного инжиниринга. Но я уверен, что всё это не должно быть частью инструмента моделирования. Инструмент моделирования должен хорошо выполнять очень узкие задачи: редактирование, хранение, версионирование, валидация моделей, создание новых нотаций моделирования, возможно преобразование и анализ моделей. А всё остальное может работать через API. У нас цель сделать не многофункциональный комбайн, а очень простой инструмент, который решает узкую задачу, но делает это максимально хорошо
Очень интересно! А в какие модели импортировали схемы данных? В PlantUML? И что импортировали из Кубера? Модели для DevOps? Им эти модели были нужны, чтобы просто собрать информацию о своём ИТ ландшафте или потом они правили модели и что-нибудь генерировали из них?
Насчёт спора про Hibernate. Меня конечно удивила аргументация в стиле: Hibernate делали умные люди, много людей им пользуются, на stackoverflow много вопросов и если у вас с ним проблемы, то включите критическое мышление, проблема не в Hibernate, а в том, что вы в нём не разобрались. Я долго им пользовался, на некоторых проектах даже писал кучу правил на ArchUnit, чтобы проверять, что используются правильные аннотации, что правильно реализованы двунаправленные связи (если они есть), что названия соответствуют соглашению и т. д.
Но всё равно постоянно натыкаешься на какие‑нибудь безумные исключения, по которым вообще ничего не понять — EclipseLink в этом плане гораздо более адекватный. Или на какие‑нибудь баги, которые годами висят, или не реализовано что‑то.
Из той же области Spring Data (да и с Spring Data REST) — в теории отличная штука, но чуть что сразу куча гемора и запаришься это отлаживать, гуглить, копаться в этих тоннах пресловутых вопросов на stackoverflow, читать эту объёмную и безусловно прекрасно написанную документацию. Зачем мне все эти абстракции над абстракциями над абстракциями, зачем мне все эти максимально «полезные» знания о куче багофич Hibernate и остального?
Для меня таким облегчением было после этого попробовать Spring JDBC с JdbcClient! Оно просто работает. Да, наверное нет универсального инструмента для любого проекта. Но автоматически везде тянуть Hibernate я точно не буду.
Короче, я думаю, что отказ от Hibernate — это и есть проявление критического мышления
Точно можно править! Спасибо, я упустил этот момент или забыл уже
PlantUML всё равно не закрывает все требования. Например, нам нужны в модели данных платформо независимые типы (number, string,...) с разными параметрами (количество знаков после запятой, максимальная длина, шаблон для строки,...), чтобы потом по этим моделям генерировать SQL скрипты (при этом типы преобразуются в типы для конкретной СУБД — varchar, decimal,...), генерировать Java‑код (здесь типы будут заменяться уже на другие). Или нам для сущностей в модели данных нужно два названия (техническое на английском языке и на русском языке), чтобы можно было генерировать документацию
Или, например, для описания требований к системе в PlantUML нет нотации. Плюс PlantUML не позволяет двигать фигуры. Не позволяет делать межмодельные ссылки
С одной стороны, есть инструменты типа Structurizr, PlantUML и т. д., которые позволяют с минимальными усилиями закрыть требования. С другой стороны, есть более сложные инструменты моделирования типа Archi, Enterprise Architect, Rational Sofrtware Architect Designer и т. д. Мы хотим сделать что‑то среднее. Чтобы эта штука была простой и бесплатной, но по функциональности не сильно уступала Enterprise решениям
Да, и в конце концов, наличие аналогичных проектов для меня это скорее признак, что на такой продукт есть спрос, чем повод не делать этот проект, я уверен, что у нас во многом получится лучше
Нельзя поправить диаграммы, они очень корявыми получались. Хочется, чтобы модели редактировались и в коде, и чтобы можно было подвигать фигуры на диаграмме при необходимости
Кроме C4 нам нужно много других моделей для описания требований, функциональных подсистем, сценариев использования, структур данных и т. д.
Не очень удобный интерфейс, хотелось древовидный навигатор по всем моделям и объектам
У Structurizr сложный тулинг. Как, например, генерить документы?.. И в целом это вещь в себе. Для инструментов моделирования есть много стандартов и готовых инструментов, а в Structurizr всё это игнорируется, у них свой формат хранения моделей, нельзя использовать готовые инструменты для генерации документов по этим моделям или для их анализа
Нет управления доступом к моделям. Что если проектов много? Хотя Structurizr модели можно хранить в Git рядом с кодом. Но хотелось бы централизованный архитектурный репозиторий
Хотелось бы описать архитектурные правила (для именования сущностей и связей, правила типа не больше N фигур и не больше M связей на диаграмме и т. д.) и потом валидировать по ним модели
В целом всё это наверное достаточно специфические требования. Я думаю, что есть много проектов, где Structurizr вполне норм
Новостей пока нет. Мне немного грустно от того, что мы вроде делаем интересный, нетривиальный проект. Но здесь статьи не очень заходят. Хотя я стараюсь добавлять технических деталей, делать демки с исходниками. Чтобы всё это реализовать, причесать код, написать статью нужно достаточно много усилий. Хорошо, что KPI, который я себе установил — это не количество плюсов к статье :)
1) Для заставки я написал промпт «Волшебница превращает модель в код». Не ожидал, что ChatGPT поймёт слово «модель» таким образом, но переделывать не стал )
2) У нас подход очень простой. Модель — это граф. Граф в математическом смысле (вершины, связи, атрибуты), не диаграмма. Граф хранится в JSON. Он может быть визуализирован разными способами:
в виде диаграммы (диаграмма это отдельный от модели JSON, в котором хранится информация о координатах и размерах фигур, цветах и т. д.)
в виде текста
в виде дерева
в виде таблицы
...
У одной модели может быть одновременно несколько разных представлений. Можно редактировать любое из них, при этом будет обновляться модель под капотом и все остальные представления
Наверное это ближе всего к варианту «в» из вашего описания
3) Просто перетащить эти объекты на диаграмме. У нас диаграммы редактируемые в отличие от PlantUML. Конкретно эта модель не редактируется потому что для этого нужен доступ. Можно создать свой проект, в нём VAD модель и тогда она будет редактируемая
4) У нас нет в явном виде генерации схемы по коду как в PlantUML. Я просто открываю модель в удобном для меня редакторе, при этом обновляются другие. Могу одновременно открыть одну и ту же модель в текстовом и диаграммном редакторах, вносить изменения в любом из них, при этом в реальном времени будет обновляться второй. Это видно в видео. Редактирую текст — сразу обновляется диаграмма. Редактирую диаграмму — сразу обновляется текст
5) У нас полноценный репозиторий моделей. С API, с управлением доступом к моделям (дискреционный и мандатный на трёх уровнях: пространство моделирования, проект, модель), с прицелом на версионирование моделей (но пока нет)
Для объектов и связей хранятся атрибуты. Для любых объектов можно задавать любые атрибуты, это настраивается на уровне метамодели. Модель с атрибутами хранится в JSON и доступна через API
Можно ли подключать внешний репозиторий? Есть два варианта:
Проще всего реализовать интеграцию, чтобы из стороннего репозитория модели по API передавались в наш или наоборот забирались из нашего репозитория во внешний
Можно написать свой компонент хранения моделей. Он достаточно простой и изолированный
6) Формат хранения моделей описан в стандарте OMG XML Metadata Interchange. Он поддерживается во многих инструментах моделирования. Но с поправкой на то, что заменили XML на JSON. Добавить API для моделей в XML формате не долго. Тем более что это и есть изначальный формат, просто с JSON удобнее работать
7) У нас можно генерировать из моделей Markdown документы с Mermaid диаграммами. Выше пример. т. е. у нас рендерится Mermaid. PlantUML тоже можно будет прикрутить, но с ним больше сложностей, чем с Mermaid — нужно отправлять запросы на сервер (в отличие от Mermaid, который генерит диаграммы в браузере), это дополнительная морока, возможно поэтому он не поддерживается в GitHub
А какая соседняя ветка? Не могу найти... У нас документация тоже генерится:
Насчёт ИИ согласен, в принципе это один из сценариев для чего мы прикручивали текстовый редактор к моделеру. В целом, я думаю, что модели — это промежуточное звено между промптом пользователя и конечным результатом. Есть много областей, где не работает сценарий: «промпт → какая‑то ИИ магия → критичный код для управления атомной станцией». Но зато работает сценарий: «промпт → верхнеуровневая модель → более детальная модель → ещё более детальная модель → конечный артефакт». Каждая из промежуточных моделей может быть верифицирована пользователем или автоматически. Я уверен, что по крайней мере в критичных областях ИИ будет развиваться в эту сторону
Дети в любом случае получат свою порцию трудностей в детском саду, в школе, в целом в жизни. А, вот, чего они реально могут не получить — это чувство опоры, ощущение и осознание, что они могут положиться на своих родителей, ощущение что они могут доверять родителям. Никто другой им этого не даст. Потом они вырастают травмированными людьми без личных границ, не способные построить здоровые отношения. Поэтому хотя бы от родителей они должны получать любовь и поддержку, а не психологическое насилие. Жизнь — это не только борьба и преодоление, а взаимопонимание, любовь, открытость и этому им тоже нужно где‑то научиться
Спасибо за поддержку! Железо почти ничего не стоит, там сейчас вечный (без абонентской платы) сервак на 4 CPU и 8 Гб RAM. На несколько тысяч активных пользователей должно хватить, можно легко масштабировать. Но чтобы проект активно развивался действительно нужны люди и деньги. Пока мысли такие:
Возможно какой‑нибудь крупной компании понадобится инструмент моделирования и она вложится в развитие open source проекта
Может быть подход как у GitLab. Основная функциональность бесплатная и без ограничений, но приоритетная поддержка и Enterprise‑фичи (сложная схема управления доступом, нотации моделирования нужные только на крупных предприятиях, хостинг отдельно развернутого для компании моделера и т. д.) — на коммерческой основе
Может быть схема как у coda.io — пользователи разрабатывают нотации, шаблоны для генерации документов и кода, преобразования моделей, сложные методы анализа моделей, сами модели. Предоставляют к ним доступ на платной основе, а проект получает процент с этих транзакций
Донаты от пользователей
Если будет большая аудитория, то реклама
Предполагается, что на базе нашего проекта должны с минимальными усилиями реализовываться инструменты типа https://structurizr.com/https://linkml.io/ и другие подобные инструменты связанные с моделированием. Разработчики таких систем могут использовать нашу платформу, где реализована вся базовая функциональность для работы с моделями (версионирование, управление доступом, валидация, преобразование моделей, генерация кода и документов, разные формы представления моделей), и добавлять свою специфику. Возможно они будут спонсировать наш проект
Возможно сотрудничество с вузами, гранты
На текущем этапе у нас цель постепенно развивать проект, сейчас например, добавить текстовые представления для моделей, реализовать небольшой, но завершенный сценарий (например, описали модель данных и сгенерили для неё документацию, SQL‑скрипты, Java‑код, JSON‑схему и т. д.). Постепенно добавлять всё новые нотации и сценарии. Я думаю, что это реально делать на энтузиазме и в какой‑то момент накопится критическая масса фич, благодаря которым появится монетизация
Ну на самом деле писали один раз, когда придумывали синтаксис для Tree. Но если этот универсальный синтаксис не подходит, то придётся описать грамматику для DSL.
Либо если понадобится более сложная логика для автодополнения и валидации. Например, для атрибута можно указать только тип данных (а не класс):
Класс может наследоваться только от другого класса:
В качестве обратной ссылки можно выбрать только подходящую. В данном случае items указывает на класс OrderItem. Соответственно обратной ссылкой может быть ссылка только из OrderItem, которая указывает обратно на Order:
Т. е. универсальный формат не закрывает все сценарии
Начал отвечать на комментарий и в итоге получилась мини‑статья :)
1) Про Tree и DSL
По сути любая модель — это дерево с дополнительными горизонтальными связями (или, если так удобнее, то граф с двумя видами связей: вложенность и ссылка). Соответственно её можно представить в XML, JSON, YAML, Tree формате. Хотя мне ближе всего S‑expressions :) Всё это универсальные форматы, в которых можно представить любую древовидную структуру. Но иногда хочется не универсальный формат, а кастомный.
Например, классы и типы данных в статье вложены в модель классов и по логике они должны были бы в тексте писаться с отступом и/или внутри фигурных скобок:
classModel OnlineStore {
class User { }
class Order { }
}
Но это избыточно и код выглядит и пишется проще, если этой дополнительной группировки нет (например, по аналогии с package и class в Java):
classModel OnlineStore
class User { }
class Order { }
Или, например, параметры @name и @description принадлежат модели, классу, атрибуту, ... и логично поместить их внутрь соответствующего объекта:
class User {
@name('ru-RU', 'пользователь')
attribute firstName String[0..1] {
@name('ru-RU', 'имя')
}
}
Но так код сложнее воспринимается, потому что в Java, C#, ... аннотации обычно пишутся до объекта, к которому они относятся:
@name('ru-RU', 'пользователь')
class User {
@name('ru-RU', 'имя')
attribute firstName String[0..1]
}
Соответственно если помещать их внутрь объекта, то для части людей будет не очевидно эта аннотация @name относится к классу, внутри которого она указана, или к первому свойству этого класса.
Причём в зависимости от множества разных факторов могут быть удобны разные варианты: 1) с группировкой классов и типов данных внутри модели с помощью фигурных скобок/отступа или без 2) с аннотациями до описания объекта или внутри описания объекта. В этом и смысл, что синтаксис не универсальный, а кастомный, потому что по какой‑то причине так сложилось, так удобнее воспринимать код.
2) Про DSL в целом
Честно говоря, в глубине души я считаю, что вообще не нужны никакие языки кроме Lisp. Изначально у меня даже введение к этой статье было на эту тему, про программирование снизу вверху, про то, что любое приложение можно разбить на несколько предметных областей, для каждой из них запилить свой микрофреймворк/DSL и потом из них как из конструктора Lego собирать всё приложение.
При этом даже не обязательно пилить какой‑то кастомный синтаксис. В Lisp это просто не нужно, а в других языках можно использовать имеющиеся языковые конструкции. Например, ту же модель данных можно описывать просто в виде классов, в виде классов с аннотациями (Hibernate), в виде JSON, XML, YAML, Tree, с помощью Fluent API, на SQL, на DBML, на другом DSL. Или та же история с API: можно описать его на JSON или YAML (OpenAPI), можно просто для классов и методов добавить аннотации, можно описать в коде с помощью Fluent API, ... Форма не так важна, а важно, что в принципе такие вещи вынесены в отдельные домены. Аналогичные домены могут быть для валидации данных, для формочек, для проверки доступа, для бизнес‑правил, ...
3) Про ФП vs ООП
Но меня уже далеко понесло, сейчас бы ещё накинуть про ФП vs ООП. В ФП преимущественно используется описанный подход, а в ООП обычно разработка идёт наоборот сверху вниз, поэтому на нижних уровнях в коде иногда оказывается неподдерживаемая и непереиспользуемая трешатина.
4) Про ИИ, который заменит программистов
А ещё можно накинуть про то, что программирование для меня лично в значительной степени про язык:
In Lisp, you don't just write your program down toward the language, you also build the language up toward your program.
И с этой точки зрения в перспективе у людей просто нет шансов писать код лучше, чем языковые модели. Если последние будут писать код таким образом: выделять домены, под каждый домен создавать свой предметно‑ориентированный язык, транслировать его в нужную форму как я описал выше (просто в классы, в классы с аннотациями (Hibernate, ...), в JSON, в XML, в YAML, в Tree, в код, использующий Fluent API из какого‑нибудь фреймворка, ...).
Словом, хорошо, что я удалил такое введение к статье и не стал развивать все эти темы, иначе я бы ещё год писал саму статью :)
Согласен, ещё есть модели, которые ходят по подиуму и показывают платья. И наверное у большинства людей с этим словом возникают именно такие ассоциации. Это очень многозначное слово
Структурная модель в моём понимании описывает структурные элементы объекта и отношения часть‑целое между ними. Например, автомобиль состоит из кузова, двигателя, ... Двигатель состоит из чего‑то ещё и т. д. Если мы описываем схему работы двигателя, то в моём понимании эту будет уже не структурная модель, а модель процесса, машина состояний или ещё что‑нибудь
Зона применимости для меня лично очень простая. Например, мне понадобилось описать модель данных для приложения, сгенерить её описание, сгенерить по ней Java код, SQL‑скрипты. И если этот инструмент позволит мне потратить полчаса и больше никогда не тратить время на эту рутину, то отлично. Та же история с генерацией документации для API
Или понадобилось описать бизнес‑требования к ПО, оценить их, приоритезировать, сгенерить табличку для ТЗ
Или понадобилось описать сценарии использования системы, связать их с бизнес‑требованиями, посмотреть какие бизнес‑требования не покрыты сценариями. Втянуть задачи из трекера, связать их со сценариями, посмотреть сколько времени ушло на реализацию бизнес‑требований
Конечно я могу использовать для этого Excel или ещё кучу других приложений, но, блин, я занимаюсь инструментами моделирования (не любыми, а достаточно специфическими, но это ничего не меняет), поэтому на всё смотрю через призму моделей
Или захотелось сменить работу, машину, квартиру, ... Есть куча способов как принять оптимальное решение, но я это буду делать таким образом и для этого мне нужен удобный инструмент
Или захотелось разобраться кем были мои предки. Конечно есть куча инструментов для построения генеалогических деревьев. Но очевидно, что лично я буду строить эти деревья в инструменте моделирования
Или захотелось улучшить баланс между работой и остальной жизнью. Я могу конечно в Excel фиксировать на что трачу время, ставить себе планы типа на час меньше работать, на два часа раньше ложиться спать. А могу в инструменте моделирования с помощью Process Mining построить модель процесса AS‑IS для моего типового дня. Поправить её и получить модель TO‑DO (типа не залипать в youtube два часа перед сном, а слушать аудиокнигу и засыпать через 5 минут или в обед гулять полчаса). И потом сопоставлять эти две модели
Или мне захотелось построить план оптимальной тренировки в зале, сравнить его с планами других людей
Или мне надоело ИТ, решил заняться психологией и фигачу метамодели для разных методик типа СМЭР. Кидаю людям ссылку на табличку, где они могут фиксировать свои ситуации, мысли, эмоции, реакции. Даю людям другие аналогичные шаблоны
А потом разочаровываюсь в психологии, решаю заняться изготовлением столов из дерева, компьютерными сборками и т. д. И тоже первым делом описываю эти предметные области в виде метамоделей, делаю текстовый или графический DSL для описания сборок или для описания заказов на столы и т. д. Добавляю правила валидации для моделей, которые проверяют будет ли вообще эта сборка работать, пишу бота который на вход получает описание сборки и ищет в магазинах комплектующие, или пишу скрипт, который проверяет сборку на оптимальность, предлагает изменить в ней некоторые параметры
Я могу часами говорить о том, что моделирование — это не удел исключительно «аналитиков, архитекторов, онтологов» в крупных корпорациях, а то чем подавляющее большинство людей занимаются ежедневно на бытовом уровне не задумываясь об этом. Даже когда они планируют поездку в магазин, выбирают время, маршрут, составляют список покупок, оценивают бюджет, сравнивают варианты покупок. За всем этим стоит пусть очень простая или не очень простая модель со своей метамоделью
Конечно мы не делаем в данный момент инструмент для планирования покупок :) А начали с более прозаичных вещей — моделирование данных и архитектуры ПО
В соответствии с метамоделью есть суслики, у сусликов есть имя и пол. Есть три типа отношений между сусликами (дружба, любовь, вражда). У отношений есть дата начала и дата окончания.
2) После этого автоматически получаем древовидный редактор этих моделей (слева), форму свойств (справа), пока стрёмный табличный редактор, дефолтный диаграммный редактор или не автоматически получаем немного улучшенный диаграммный редактор с сусликами в виде значков, а не прямоугольников (по центру):
3) В перспективе описываем грамматику для этих моделей (слева) и получаем такой текстовый DSL для их редактирования (по центру):
Справа абстрактное синтаксическое дерево для этого кода = модель. Структура этого дерева (модели) соответствует метамодели, описанной выше.
Содержательно это одна и та же модель, она не графическая, не текстовая, не табличная. Можно по‑разному её называть: концептуальная (исходя из того, что она описывает понятия и отношения между ними) или объектная (если ориентироваться на стандарт). Эта модель описывает сусликов и отношения между ними. Формы представления у этой модели могут быть разными (диаграмма, таблица, дерево, текст).
Пока у нас нет таких текстовых представлений, я описал грамматику в другой системе, но это вопрос времени. В принципе и сейчас у нас диаграммы не обязательные, можно создавать модель в навигаторе слева. Для каких-то моделей возможно и не нужны будут диаграммы, будет только текстовая нотация
Вот эта же модель в виде таблицы (пока очень стрёмной с одним столбцом «Название», но тем не менее):
Текстовые представления у нас пока есть только в десктопном инструменте моделирования:
На скриншоте три разных представления (диаграмма, таблица, текст) одной и той же модели. Можно вносить изменения в любое из них, при этом обновятся остальные. Иными словами, содержательно это может быть какая угодно модель (модель данных, модель процессов, модель описывающая требования к ПО, организационная структура и т. д.) и визуально она может быть представлена разными способами (точно в виде диаграммы, таблицы, текста, возможно в специфических нотациях типа blockly). т. е. мы не ограничиваемся рисовалкой диаграмм. Но в веб‑моделере у нас пока для редактирования моделей есть только дерево в навигаторе, диаграммы, форма свойств, пока не очень удобные таблицы. Текстовых представлений сейчас нет, но они планируются в обозримом будущем
Надеюсь, что нет. Хотелось бы, чтобы в нём было хорошо сделано всё что относится к моделированию:
Разные формы представления моделей (диаграммы, таблицы, деревья, текст) + возможно специфические нотации типа blockly, но для их поддержки нужно будет уже писать код
Возможность создавать свои нотации и методики моделирования
Валидация моделей
Версионирование моделей
Управление доступом к моделям
Запросы и поиск по моделям
Преобразование моделей в другие модели и в документы/код. Это могут быть и простые преобразования, и более сложные типа имитационного моделирования. Но они не усложняют сам инструмент моделирования, главное что движок в принципе поддерживает преобразования, а все сложности дописываются пользователями
Удобное API
Значительная часть из этого есть, но пока без нормального UI и описания. Самая непроработанная тема — это пока текстовые представления для моделей.
На мой взгляд, на базе этой функциональности можно будет собрать любой инструмент моделирования, добавив нужные нотации и преобразования моделей. А если понадобится что‑то более сложное типа системы исполнения процессов, BI и т. д., то можно добавить сбоку готовую стороннюю систему
Если я ошибаюсь, то надеюсь, что кто‑нибудь меня поправит. На сколько я понимаю TOGAF — это подход в соответствии с которым архитектура предприятия описывается на нескольких уровнях. Причём в TOGAF нет конкретной нотации, конкретных типов объектов, это просто идея, подход. А ArchiMate — это уже нотация с конкретными типами объектов и диаграммами, которая реализует подход TOGAF. ARIS тоже реализует TOGAF, но там уже другие диаграммы и объекты.
Спецификация ArchiMate, да, закрытая, но гуглятся неофициальные варианты
Да, эти диаграммы меня тоже смутили. Можно показывать отправку сообщения через triggering, а получение ответа через flow. Иногда они сразу отправку сообщения показывают через flow. Иногда вставляют промежуточный data object и показывают его отправку и получение через access. Очень большая вариативность. Но на сколько я понимаю, ArchiMate в первую очередь для моделирования бизнес‑вещей, а не технических и не математических. Поэтому нотация такая свободная. Здесь нет маркеров как в сетях Петри и нет строгой семантики
Есть спецификация в машиночитаемом виде: метамодель, правила какие связи какие объекты могут соединять, перечень точек зрения (например, точка зрения «Организация» включает актора, роли и подобные типы объектов). Но там нет человеческого описания в каких случаях какие типы связей использовать
Да, я не смог найти такое, нашёл только много разрозненных руководств, статей и курсов. И в этой статье как‑раз попробовал описать «сокращенный вариант ArchiMate» или «соглашение о моделировании», которое удобно для нашего проекта, с акцентом на процесс разработки, а не корпоративную архитектуру или ещё что‑то. Понятно, что статья написана в свободном неформальном стиле, но назначение статьи именно такое. Но для других компаний и проектов будет совершенно другое соглашение о моделировании
Ну, как минимум, у нас уже есть одновременное редактирование моделей разными пользователями, управление доступом, API для интеграции с другими системами, не только диаграммные, но и текстовые нотации, no‑code конструктор для создания своих нотаций моделирования, плюс в целом веб‑интерфейс приятнее.
На мой взгляд мы уступаем IBM Rational Rose или аналогичным продуктам в количестве поддерживаемых нотаций. Реализовать полностью UML — не очень тривиальная задача, на это действительно может уйти много времени. Но вопрос нужен ли полный UML. Мы пока активно добавляем более простые нотации.
Другая вещь, в которой мы уступаем — это обилие всякого обвеса в виде кодогенераторов или наоборот инструментов для обратного инжиниринга. Но я уверен, что всё это не должно быть частью инструмента моделирования. Инструмент моделирования должен хорошо выполнять очень узкие задачи: редактирование, хранение, версионирование, валидация моделей, создание новых нотаций моделирования, возможно преобразование и анализ моделей. А всё остальное может работать через API. У нас цель сделать не многофункциональный комбайн, а очень простой инструмент, который решает узкую задачу, но делает это максимально хорошо
Очень интересно! А в какие модели импортировали схемы данных? В PlantUML? И что импортировали из Кубера? Модели для DevOps? Им эти модели были нужны, чтобы просто собрать информацию о своём ИТ ландшафте или потом они правили модели и что-нибудь генерировали из них?
Насчёт спора про Hibernate. Меня конечно удивила аргументация в стиле: Hibernate делали умные люди, много людей им пользуются, на stackoverflow много вопросов и если у вас с ним проблемы, то включите критическое мышление, проблема не в Hibernate, а в том, что вы в нём не разобрались. Я долго им пользовался, на некоторых проектах даже писал кучу правил на ArchUnit, чтобы проверять, что используются правильные аннотации, что правильно реализованы двунаправленные связи (если они есть), что названия соответствуют соглашению и т. д.
Но всё равно постоянно натыкаешься на какие‑нибудь безумные исключения, по которым вообще ничего не понять — EclipseLink в этом плане гораздо более адекватный. Или на какие‑нибудь баги, которые годами висят, или не реализовано что‑то.
Из той же области Spring Data (да и с Spring Data REST) — в теории отличная штука, но чуть что сразу куча гемора и запаришься это отлаживать, гуглить, копаться в этих тоннах пресловутых вопросов на stackoverflow, читать эту объёмную и безусловно прекрасно написанную документацию. Зачем мне все эти абстракции над абстракциями над абстракциями, зачем мне все эти максимально «полезные» знания о куче багофич Hibernate и остального?
Для меня таким облегчением было после этого попробовать Spring JDBC с JdbcClient! Оно просто работает. Да, наверное нет универсального инструмента для любого проекта. Но автоматически везде тянуть Hibernate я точно не буду.
Короче, я думаю, что отказ от Hibernate — это и есть проявление критического мышления
Точно можно править! Спасибо, я упустил этот момент или забыл уже
PlantUML всё равно не закрывает все требования. Например, нам нужны в модели данных платформо независимые типы (number, string,...) с разными параметрами (количество знаков после запятой, максимальная длина, шаблон для строки,...), чтобы потом по этим моделям генерировать SQL скрипты (при этом типы преобразуются в типы для конкретной СУБД — varchar, decimal,...), генерировать Java‑код (здесь типы будут заменяться уже на другие). Или нам для сущностей в модели данных нужно два названия (техническое на английском языке и на русском языке), чтобы можно было генерировать документацию
Или, например, для описания требований к системе в PlantUML нет нотации. Плюс PlantUML не позволяет двигать фигуры. Не позволяет делать межмодельные ссылки
С одной стороны, есть инструменты типа Structurizr, PlantUML и т. д., которые позволяют с минимальными усилиями закрыть требования. С другой стороны, есть более сложные инструменты моделирования типа Archi, Enterprise Architect, Rational Sofrtware Architect Designer и т. д. Мы хотим сделать что‑то среднее. Чтобы эта штука была простой и бесплатной, но по функциональности не сильно уступала Enterprise решениям
Да, и в конце концов, наличие аналогичных проектов для меня это скорее признак, что на такой продукт есть спрос, чем повод не делать этот проект, я уверен, что у нас во многом получится лучше
Нельзя поправить диаграммы, они очень корявыми получались. Хочется, чтобы модели редактировались и в коде, и чтобы можно было подвигать фигуры на диаграмме при необходимости
Кроме C4 нам нужно много других моделей для описания требований, функциональных подсистем, сценариев использования, структур данных и т. д.
Не очень удобный интерфейс, хотелось древовидный навигатор по всем моделям и объектам
У Structurizr сложный тулинг. Как, например, генерить документы?.. И в целом это вещь в себе. Для инструментов моделирования есть много стандартов и готовых инструментов, а в Structurizr всё это игнорируется, у них свой формат хранения моделей, нельзя использовать готовые инструменты для генерации документов по этим моделям или для их анализа
Нет управления доступом к моделям. Что если проектов много? Хотя Structurizr модели можно хранить в Git рядом с кодом. Но хотелось бы централизованный архитектурный репозиторий
Хотелось бы описать архитектурные правила (для именования сущностей и связей, правила типа не больше N фигур и не больше M связей на диаграмме и т. д.) и потом валидировать по ним модели
В целом всё это наверное достаточно специфические требования. Я думаю, что есть много проектов, где Structurizr вполне норм
Меня пока что-то пугает в этом шаге, хотя возможно зря
Технически у нас это уже есть и гораздо больше. Я думаю не хватает примеров конкретных моделей...
Новостей пока нет. Мне немного грустно от того, что мы вроде делаем интересный, нетривиальный проект. Но здесь статьи не очень заходят. Хотя я стараюсь добавлять технических деталей, делать демки с исходниками. Чтобы всё это реализовать, причесать код, написать статью нужно достаточно много усилий. Хорошо, что KPI, который я себе установил — это не количество плюсов к статье :)
1) Для заставки я написал промпт «Волшебница превращает модель в код». Не ожидал, что ChatGPT поймёт слово «модель» таким образом, но переделывать не стал )
2) У нас подход очень простой. Модель — это граф. Граф в математическом смысле (вершины, связи, атрибуты), не диаграмма. Граф хранится в JSON. Он может быть визуализирован разными способами:
в виде диаграммы (диаграмма это отдельный от модели JSON, в котором хранится информация о координатах и размерах фигур, цветах и т. д.)
в виде текста
в виде дерева
в виде таблицы
...
У одной модели может быть одновременно несколько разных представлений. Можно редактировать любое из них, при этом будет обновляться модель под капотом и все остальные представления
Наверное это ближе всего к варианту «в» из вашего описания
3) Просто перетащить эти объекты на диаграмме. У нас диаграммы редактируемые в отличие от PlantUML. Конкретно эта модель не редактируется потому что для этого нужен доступ. Можно создать свой проект, в нём VAD модель и тогда она будет редактируемая
4) У нас нет в явном виде генерации схемы по коду как в PlantUML. Я просто открываю модель в удобном для меня редакторе, при этом обновляются другие. Могу одновременно открыть одну и ту же модель в текстовом и диаграммном редакторах, вносить изменения в любом из них, при этом в реальном времени будет обновляться второй. Это видно в видео. Редактирую текст — сразу обновляется диаграмма. Редактирую диаграмму — сразу обновляется текст
5) У нас полноценный репозиторий моделей. С API, с управлением доступом к моделям (дискреционный и мандатный на трёх уровнях: пространство моделирования, проект, модель), с прицелом на версионирование моделей (но пока нет)
Для объектов и связей хранятся атрибуты. Для любых объектов можно задавать любые атрибуты, это настраивается на уровне метамодели. Модель с атрибутами хранится в JSON и доступна через API
Можно ли подключать внешний репозиторий? Есть два варианта:
Проще всего реализовать интеграцию, чтобы из стороннего репозитория модели по API передавались в наш или наоборот забирались из нашего репозитория во внешний
Можно написать свой компонент хранения моделей. Он достаточно простой и изолированный
6) Формат хранения моделей описан в стандарте OMG XML Metadata Interchange. Он поддерживается во многих инструментах моделирования. Но с поправкой на то, что заменили XML на JSON. Добавить API для моделей в XML формате не долго. Тем более что это и есть изначальный формат, просто с JSON удобнее работать
7) У нас можно генерировать из моделей Markdown документы с Mermaid диаграммами. Выше пример. т. е. у нас рендерится Mermaid. PlantUML тоже можно будет прикрутить, но с ним больше сложностей, чем с Mermaid — нужно отправлять запросы на сервер (в отличие от Mermaid, который генерит диаграммы в браузере), это дополнительная морока, возможно поэтому он не поддерживается в GitHub
А какая соседняя ветка? Не могу найти... У нас документация тоже генерится:
Насчёт ИИ согласен, в принципе это один из сценариев для чего мы прикручивали текстовый редактор к моделеру. В целом, я думаю, что модели — это промежуточное звено между промптом пользователя и конечным результатом. Есть много областей, где не работает сценарий: «промпт → какая‑то ИИ магия → критичный код для управления атомной станцией». Но зато работает сценарий: «промпт → верхнеуровневая модель → более детальная модель → ещё более детальная модель → конечный артефакт». Каждая из промежуточных моделей может быть верифицирована пользователем или автоматически. Я уверен, что по крайней мере в критичных областях ИИ будет развиваться в эту сторону
Дети в любом случае получат свою порцию трудностей в детском саду, в школе, в целом в жизни. А, вот, чего они реально могут не получить — это чувство опоры, ощущение и осознание, что они могут положиться на своих родителей, ощущение что они могут доверять родителям. Никто другой им этого не даст. Потом они вырастают травмированными людьми без личных границ, не способные построить здоровые отношения. Поэтому хотя бы от родителей они должны получать любовь и поддержку, а не психологическое насилие. Жизнь — это не только борьба и преодоление, а взаимопонимание, любовь, открытость и этому им тоже нужно где‑то научиться
Спасибо за поддержку! Железо почти ничего не стоит, там сейчас вечный (без абонентской платы) сервак на 4 CPU и 8 Гб RAM. На несколько тысяч активных пользователей должно хватить, можно легко масштабировать. Но чтобы проект активно развивался действительно нужны люди и деньги. Пока мысли такие:
Возможно какой‑нибудь крупной компании понадобится инструмент моделирования и она вложится в развитие open source проекта
Может быть подход как у GitLab. Основная функциональность бесплатная и без ограничений, но приоритетная поддержка и Enterprise‑фичи (сложная схема управления доступом, нотации моделирования нужные только на крупных предприятиях, хостинг отдельно развернутого для компании моделера и т. д.) — на коммерческой основе
Может быть схема как у coda.io — пользователи разрабатывают нотации, шаблоны для генерации документов и кода, преобразования моделей, сложные методы анализа моделей, сами модели. Предоставляют к ним доступ на платной основе, а проект получает процент с этих транзакций
Донаты от пользователей
Если будет большая аудитория, то реклама
Предполагается, что на базе нашего проекта должны с минимальными усилиями реализовываться инструменты типа https://structurizr.com/ https://linkml.io/ и другие подобные инструменты связанные с моделированием. Разработчики таких систем могут использовать нашу платформу, где реализована вся базовая функциональность для работы с моделями (версионирование, управление доступом, валидация, преобразование моделей, генерация кода и документов, разные формы представления моделей), и добавлять свою специфику. Возможно они будут спонсировать наш проект
Возможно сотрудничество с вузами, гранты
На текущем этапе у нас цель постепенно развивать проект, сейчас например, добавить текстовые представления для моделей, реализовать небольшой, но завершенный сценарий (например, описали модель данных и сгенерили для неё документацию, SQL‑скрипты, Java‑код, JSON‑схему и т. д.). Постепенно добавлять всё новые нотации и сценарии. Я думаю, что это реально делать на энтузиазме и в какой‑то момент накопится критическая масса фич, благодаря которым появится монетизация
Ну на самом деле писали один раз, когда придумывали синтаксис для Tree. Но если этот универсальный синтаксис не подходит, то придётся описать грамматику для DSL.
Либо если понадобится более сложная логика для автодополнения и валидации. Например, для атрибута можно указать только тип данных (а не класс):
Класс может наследоваться только от другого класса:
В качестве обратной ссылки можно выбрать только подходящую. В данном случае items указывает на класс OrderItem. Соответственно обратной ссылкой может быть ссылка только из OrderItem, которая указывает обратно на Order:
Т. е. универсальный формат не закрывает все сценарии
Здесь тоже не нужно с нуля писать парсер и остальное. Слева пишется грамматика один раз, а справа готовый редактор со всем что нужно
Начал отвечать на комментарий и в итоге получилась мини‑статья :)
1) Про Tree и DSL
По сути любая модель — это дерево с дополнительными горизонтальными связями (или, если так удобнее, то граф с двумя видами связей: вложенность и ссылка). Соответственно её можно представить в XML, JSON, YAML, Tree формате. Хотя мне ближе всего S‑expressions :) Всё это универсальные форматы, в которых можно представить любую древовидную структуру. Но иногда хочется не универсальный формат, а кастомный.
Например, классы и типы данных в статье вложены в модель классов и по логике они должны были бы в тексте писаться с отступом и/или внутри фигурных скобок:
Но это избыточно и код выглядит и пишется проще, если этой дополнительной группировки нет (например, по аналогии с package и class в Java):
Или, например, параметры
@nameи@descriptionпринадлежат модели, классу, атрибуту, ... и логично поместить их внутрь соответствующего объекта:Но так код сложнее воспринимается, потому что в Java, C#, ... аннотации обычно пишутся до объекта, к которому они относятся:
Соответственно если помещать их внутрь объекта, то для части людей будет не очевидно эта аннотация
@nameотносится к классу, внутри которого она указана, или к первому свойству этого класса.Причём в зависимости от множества разных факторов могут быть удобны разные варианты: 1) с группировкой классов и типов данных внутри модели с помощью фигурных скобок/отступа или без 2) с аннотациями до описания объекта или внутри описания объекта. В этом и смысл, что синтаксис не универсальный, а кастомный, потому что по какой‑то причине так сложилось, так удобнее воспринимать код.
2) Про DSL в целом
Честно говоря, в глубине души я считаю, что вообще не нужны никакие языки кроме Lisp. Изначально у меня даже введение к этой статье было на эту тему, про программирование снизу вверху, про то, что любое приложение можно разбить на несколько предметных областей, для каждой из них запилить свой микрофреймворк/DSL и потом из них как из конструктора Lego собирать всё приложение.
При этом даже не обязательно пилить какой‑то кастомный синтаксис. В Lisp это просто не нужно, а в других языках можно использовать имеющиеся языковые конструкции. Например, ту же модель данных можно описывать просто в виде классов, в виде классов с аннотациями (Hibernate), в виде JSON, XML, YAML, Tree, с помощью Fluent API, на SQL, на DBML, на другом DSL. Или та же история с API: можно описать его на JSON или YAML (OpenAPI), можно просто для классов и методов добавить аннотации, можно описать в коде с помощью Fluent API, ... Форма не так важна, а важно, что в принципе такие вещи вынесены в отдельные домены. Аналогичные домены могут быть для валидации данных, для формочек, для проверки доступа, для бизнес‑правил, ...
3) Про ФП vs ООП
Но меня уже далеко понесло, сейчас бы ещё накинуть про ФП vs ООП. В ФП преимущественно используется описанный подход, а в ООП обычно разработка идёт наоборот сверху вниз, поэтому на нижних уровнях в коде иногда оказывается неподдерживаемая и непереиспользуемая трешатина.
4) Про ИИ, который заменит программистов
А ещё можно накинуть про то, что программирование для меня лично в значительной степени про язык:
И с этой точки зрения в перспективе у людей просто нет шансов писать код лучше, чем языковые модели. Если последние будут писать код таким образом: выделять домены, под каждый домен создавать свой предметно‑ориентированный язык, транслировать его в нужную форму как я описал выше (просто в классы, в классы с аннотациями (Hibernate, ...), в JSON, в XML, в YAML, в Tree, в код, использующий Fluent API из какого‑нибудь фреймворка, ...).
Словом, хорошо, что я удалил такое введение к статье и не стал развивать все эти темы, иначе я бы ещё год писал саму статью :)
Согласен, ещё есть модели, которые ходят по подиуму и показывают платья. И наверное у большинства людей с этим словом возникают именно такие ассоциации. Это очень многозначное слово
Структурная модель в моём понимании описывает структурные элементы объекта и отношения часть‑целое между ними. Например, автомобиль состоит из кузова, двигателя, ... Двигатель состоит из чего‑то ещё и т. д. Если мы описываем схему работы двигателя, то в моём понимании эту будет уже не структурная модель, а модель процесса, машина состояний или ещё что‑нибудь
Зона применимости для меня лично очень простая. Например, мне понадобилось описать модель данных для приложения, сгенерить её описание, сгенерить по ней Java код, SQL‑скрипты. И если этот инструмент позволит мне потратить полчаса и больше никогда не тратить время на эту рутину, то отлично. Та же история с генерацией документации для API
Или понадобилось описать бизнес‑требования к ПО, оценить их, приоритезировать, сгенерить табличку для ТЗ
Или понадобилось описать сценарии использования системы, связать их с бизнес‑требованиями, посмотреть какие бизнес‑требования не покрыты сценариями. Втянуть задачи из трекера, связать их со сценариями, посмотреть сколько времени ушло на реализацию бизнес‑требований
Конечно я могу использовать для этого Excel или ещё кучу других приложений, но, блин, я занимаюсь инструментами моделирования (не любыми, а достаточно специфическими, но это ничего не меняет), поэтому на всё смотрю через призму моделей
Или захотелось сменить работу, машину, квартиру, ... Есть куча способов как принять оптимальное решение, но я это буду делать таким образом и для этого мне нужен удобный инструмент
Или захотелось разобраться кем были мои предки. Конечно есть куча инструментов для построения генеалогических деревьев. Но очевидно, что лично я буду строить эти деревья в инструменте моделирования
Или захотелось улучшить баланс между работой и остальной жизнью. Я могу конечно в Excel фиксировать на что трачу время, ставить себе планы типа на час меньше работать, на два часа раньше ложиться спать. А могу в инструменте моделирования с помощью Process Mining построить модель процесса AS‑IS для моего типового дня. Поправить её и получить модель TO‑DO (типа не залипать в youtube два часа перед сном, а слушать аудиокнигу и засыпать через 5 минут или в обед гулять полчаса). И потом сопоставлять эти две модели
Или мне захотелось построить план оптимальной тренировки в зале, сравнить его с планами других людей
Или мне надоело ИТ, решил заняться психологией и фигачу метамодели для разных методик типа СМЭР. Кидаю людям ссылку на табличку, где они могут фиксировать свои ситуации, мысли, эмоции, реакции. Даю людям другие аналогичные шаблоны
А потом разочаровываюсь в психологии, решаю заняться изготовлением столов из дерева, компьютерными сборками и т. д. И тоже первым делом описываю эти предметные области в виде метамоделей, делаю текстовый или графический DSL для описания сборок или для описания заказов на столы и т. д. Добавляю правила валидации для моделей, которые проверяют будет ли вообще эта сборка работать, пишу бота который на вход получает описание сборки и ищет в магазинах комплектующие, или пишу скрипт, который проверяет сборку на оптимальность, предлагает изменить в ней некоторые параметры
Я могу часами говорить о том, что моделирование — это не удел исключительно «аналитиков, архитекторов, онтологов» в крупных корпорациях, а то чем подавляющее большинство людей занимаются ежедневно на бытовом уровне не задумываясь об этом. Даже когда они планируют поездку в магазин, выбирают время, маршрут, составляют список покупок, оценивают бюджет, сравнивают варианты покупок. За всем этим стоит пусть очень простая или не очень простая модель со своей метамоделью
Конечно мы не делаем в данный момент инструмент для планирования покупок :) А начали с более прозаичных вещей — моделирование данных и архитектуры ПО
Помогут следующим образом:
1) Описываем метамодель:
В соответствии с метамоделью есть суслики, у сусликов есть имя и пол. Есть три типа отношений между сусликами (дружба, любовь, вражда). У отношений есть дата начала и дата окончания.
2) После этого автоматически получаем древовидный редактор этих моделей (слева), форму свойств (справа), пока стрёмный табличный редактор, дефолтный диаграммный редактор или не автоматически получаем немного улучшенный диаграммный редактор с сусликами в виде значков, а не прямоугольников (по центру):
3) В перспективе описываем грамматику для этих моделей (слева) и получаем такой текстовый DSL для их редактирования (по центру):
Справа абстрактное синтаксическое дерево для этого кода = модель. Структура этого дерева (модели) соответствует метамодели, описанной выше.
Содержательно это одна и та же модель, она не графическая, не текстовая, не табличная. Можно по‑разному её называть: концептуальная (исходя из того, что она описывает понятия и отношения между ними) или объектная (если ориентироваться на стандарт). Эта модель описывает сусликов и отношения между ними. Формы представления у этой модели могут быть разными (диаграмма, таблица, дерево, текст).
Пока у нас нет таких текстовых представлений, я описал грамматику в другой системе, но это вопрос времени. В принципе и сейчас у нас диаграммы не обязательные, можно создавать модель в навигаторе слева. Для каких-то моделей возможно и не нужны будут диаграммы, будет только текстовая нотация
Да, очень похоже на MetaEdit+, но
с более простым веб‑интерфейсом
с API
с возможностью легко делиться нотациями моделирования и моделями
не только с диаграммами и таблицами, но и с текстовыми нотациями
наверняка с более интересной валидацией и оценкой качества моделей
бесплатное и ориентированное на большую аудиторию
и кучей разных идей связанных с машинным обучением и других
Наверное единственная новая идея у нас — это сделать инструменты типа MetaEdit+ более доступными, удобными, массовыми
Вот модель классов из статьи в виде диаграммы:
Вот эта же модель в виде таблицы (пока очень стрёмной с одним столбцом «Название», но тем не менее):
Текстовые представления у нас пока есть только в десктопном инструменте моделирования:
На скриншоте три разных представления (диаграмма, таблица, текст) одной и той же модели. Можно вносить изменения в любое из них, при этом обновятся остальные. Иными словами, содержательно это может быть какая угодно модель (модель данных, модель процессов, модель описывающая требования к ПО, организационная структура и т. д.) и визуально она может быть представлена разными способами (точно в виде диаграммы, таблицы, текста, возможно в специфических нотациях типа blockly). т. е. мы не ограничиваемся рисовалкой диаграмм. Но в веб‑моделере у нас пока для редактирования моделей есть только дерево в навигаторе, диаграммы, форма свойств, пока не очень удобные таблицы. Текстовых представлений сейчас нет, но они планируются в обозримом будущем
Надеюсь, что нет. Хотелось бы, чтобы в нём было хорошо сделано всё что относится к моделированию:
Разные формы представления моделей (диаграммы, таблицы, деревья, текст) + возможно специфические нотации типа blockly, но для их поддержки нужно будет уже писать код
Возможность создавать свои нотации и методики моделирования
Валидация моделей
Версионирование моделей
Управление доступом к моделям
Запросы и поиск по моделям
Преобразование моделей в другие модели и в документы/код. Это могут быть и простые преобразования, и более сложные типа имитационного моделирования. Но они не усложняют сам инструмент моделирования, главное что движок в принципе поддерживает преобразования, а все сложности дописываются пользователями
Удобное API
Значительная часть из этого есть, но пока без нормального UI и описания. Самая непроработанная тема — это пока текстовые представления для моделей.
На мой взгляд, на базе этой функциональности можно будет собрать любой инструмент моделирования, добавив нужные нотации и преобразования моделей. А если понадобится что‑то более сложное типа системы исполнения процессов, BI и т. д., то можно добавить сбоку готовую стороннюю систему