Это первая статья в блоге нашего стартапа, надеюсь, что не последняя. Мы разрабатываем инструмент моделирования и будем делиться нашим видением идеального продукта, рассказывать про наши успехи и неудачи, надеюсь, что будем получать критику и в итоге у нас получится что‑то полезное.
Почему мы решили создать ещё один инструмент моделирования?
У меня было много проектов связанных с моделированием и я изрядно намучился с разными инструментами моделирования.
В чём заключались эти боли и что хотелось бы улучшить:
Самая очевидная вещь — это удобство редактирования моделей. При редактировании диаграмм часто приходится заниматься пиксель хантингом, тратить кучу времени на то, чтобы связи были ровными, исправлять диаграмму после того как всё куда‑то уехало, делать несколько кликов, когда можно было бы обойтись одним
Поддержка разных форм представления моделей. Многие вещи удобнее редактировать не на диаграмме, а в таблице или в виде текста
Возможность локализации моделей, это важно для генерации документов, для многоязычных проектов
Тормоза во всём — при запуске инструмента моделирования, при открытии моделей, при редактировании диаграмм, при валидации моделей
Сложность автоматизации разной рутины. Например, присвоить коды новым объектам в соответствии со схемой кодирования. Найти объекты, удовлетворяющие разным условиям. Сделать массовые правки в моделях. Выгрузить CSV‑файл со списком объектов
Сложность расширения. Добавление своих нотаций моделирования, кодогенераторов, преобразований моделей (например, из UML в BPMN), методов анализа моделей
Сложность совместной работы над моделями
Сложность версионирования моделей и в целом управления их жизненным циклом (рецензирование, согласование и т. д.)
Высокий порог входа, очень ограниченные сценарии применения инструментов моделирования. Например, если мне нужно по‑быстрому нарисовать модель и с кем‑то поделиться ей, то я не буду ради этого покупать лицензию на Rational Software Architect Designer, два часа его устанавливать, месяц учиться им пользоваться. Более того, даже если это online‑моделер типа ARIS Express, то заполнять кучу форм на сайте, чтобы они позволили мне 30 дней пользоваться их инструментом я тоже не буду. Всё это для крупных компаний с отделами моделирования. Хотя, на мой взгляд, область применения моделирования существенно шире. С другой стороны, если нужно по‑быстрому нарисовать модель и поделиться с кем‑то, то можно же взять draw.io, но ...
Проблема в инструментах типа draw.io, что там рисуется просто картинка, а не модель. И с этой картинкой потом ничего полезного не сделать, например, ничего не сгенерить по ней
Отсутствие бесплатной версии или много ограничений на количество моделей, объектов
Отсутствие возможности развернуть инструмент моделирования локально
Сложность интеграции с другими инструментами
Отсутствие соответствия стандартам или отсутствие стандартов. Например, модели хранятся в проприетарном формате и для работы с ними используется проприетарный API. Или в каждом инструменте моделирования реализована своя версия event‑driven process chain моделей
И конечно же фатальный недостаток
Вообще есть разные инструменты моделирования, в которых нет некоторых из этих проблем. Но нет прямо идеального варианта, чтобы он был проще чем draw.io и функциональнее чем enterprise‑моделеры. Как нет и сомнений, что в рамках нашего скромного стартапа мы его реализуем :) Но не сразу, наше решение пока тоже далеко от идеала.
Что у нас есть на данный момент?
Аутентификация
Вы можете войти в систему с учетной записью Google, GitHub или Яндекс:
Также Keycloak предоставляет личный кабинет, в котором можно изменить язык интерфейса (для применения изменений пока требуется перезайти в приложение):
Хотелось бы конечно сделать для Keycloak более красивую кастомную тему, сделать личный кабинет более удобным, обнаружить, что мы потратили на второстепенную функциональность тысячи человеко‑часов, год откладываем релиз, ... :) Это совершенно очевидная вещь, но полезно оценивать для каждой задачи её важность и трудоёмкость. В первую очередь делать самые важные и простые вещи, а сомнительные и трудоёмкие откладывать. Я часто сталкивался не с тем, что люди не могут придумать как и что делать, а с тем, что не могут решить, что, нет, это мы сейчас делать не будем, сделаем потом, если останется время.
Создание проекта
После аутентификации у вас появляется возможность создавать проекты. Вообще это немного противоречит идее сделать инструмент проще чем draw.io. Хотелось бы открыть сайт и сразу рисовать модель, а здесь целых три лишних шага: вход в систему, создание проекта, создание модели. Но, надеюсь, в будущем мы это улучшим.
При создании проекта вы указываете его название и пространство моделирования. Пространство моделирования — это аналог scope в npm, организаций в GitHub, групп в GitLab. Сейчас по умолчанию вам доступно персональное пространство моделирования. В будущем будет возможность создавать дополнительные пространства.
Управление доступом к проекту
Можно добавить участников проекта:
И указать для них роль:
Гость — может только просматривать модели
Редактор — дополнительно может создавать, редактировать и удалять модели
Владелец — дополнительно может управлять участниками проекта
Возможно вас удивит роль «Нет». У пространств моделирования тоже могут быть участники, которых пока нельзя редактировать. Таким образом мы получаем двухуровневую систему управления доступом: пространства моделирования и проекты. Роль «Нет» позволяет ограничить для участника пространства моделирования доступ к отдельному проекту.
Возможно такая схема управления доступом выглядит слишком примитивной. Хотелось бы создавать кастомные роли, для которых можно указывать какие функции они могут выполнять. Чтобы, например, администратор проекта мог только управлять участниками, раздавать доступы, но сам не мог просматривать или тем более редактировать модели. У нас это реализовано через уровни допуска (мандатное управление доступом), но это тема для отдельной статьи.
Создание модели
Для создания модели необходимо указать её название и тип:
У нас все модели строго типизированы, структура моделей описана в метамоделях. Метамодель определяет объекты каких типов могут использоваться в модели, какими типами отношений они могут связываться и какие атрибуты могут быть у объектов и отношений.
Это существенное отличие от инструментов типа draw.io, в которых вы создаёте диаграмму и добавляете на неё произвольные фигуры. С одной стороны, это ограничение, потому что вы не можете нарисовать на одной диаграмме одновременно и модель данных, и модель процесса, и добавить каких‑нибудь человечков, облачка и т. д. Но в этом есть и свои преимущества. Например, вы можете формировать из этих моделей документы (с таблицей со списком классов), можете преобразовывать одни модели в другие (например, UML в BPMN), можете анализировать модели (например, выполнить имитационное моделирование процесса). В draw.io всё это делать нельзя, потому что в нём диаграмма — это просто картинка, состоящая из квадратиков, кружочков или более сложных фигур, а не модель, состоящая из классов, процессов, функций с соответствующими атрибутами типа стоимости и длительности выполнения функции.
Представьте, что в коде на вашем любимом языке программирования вы можете писать произвольный текст в произвольном месте и при этом компилятор должен с этим текстом что‑то делать. Например, код на языке Java содержит классы, поля, методы, переменные, ... и ничего другого он содержать не может. Код на языке SQL состоит из других конструкций, потому что у него другое назначение. Код на языке Bash, DOT и т. д. состоит из совершенно других конструкций. Аналогично и для разных типов моделей. Я так много внимания уделяю этой банальной теме, потому что никого не удивляет, что один файл не может быть одновременно Java‑классом, Bash‑скриптом и SQL‑скриптом, но то что в одной модели нельзя одновременно описывать и процесс, и структуру данных, и нарисовать что‑то произвольное — иногда удивляет.
Редактирование модели
Интерфейс редактирования моделей типовой:
Слева — навигатор по моделям, каждая модель представляет собой древовидную структуру
Справа — форма свойств, свойства объектов определены в метамодели и настраиваются
По центру — редактор диаграмм
Редактор пока далёк от идеала. Добавление и редактирование связей или изменение размера фигур — с элементами геймификации тот ещё квест. Но есть и положительные моменты, например, модель могут редактировать одновременно несколько человек.
Пока у нас поддерживается не так много типов моделей (модели классов, C4, EPC, VAD). Более подробно я расскажу про них в следующих статьях, а также покажу на сколько легко добавляются новые типы моделей.
Локализация
Локализация поддерживается для всего чего только возможно на трёх уровнях:
Интерфейс приложения
Метамодели. Например, в палитре инструментов диаграммы показываются локализованные названия классов, а на форме свойств — локализованные названия атрибутов из метамодели
Модели. См. скриншот выше, на форме свойств в разделе «Локализация» название класса на русском языке. Вообще это достаточно специфическая фича, я не могу вспомнить ни одного инструмента моделирования, где это поддерживается. Возможно потому что это и требуется не так часто: для моделей данных (чтобы разделять технические названия классов и их названия на естественном языке для документации) или для моделей в международных/многоязычных проектах. Для меня это всегда была наболевшая тема, поэтому добавили это в первом релизе. Локализованные названия пока не отображаются в навигаторе и на диаграмме, сначала нужно будет добавить возможность переключения языка на уровне моделей, а не только всего приложения
Генерация документов по модели
Рисование моделей — это конечно замечательно, чтобы разобраться в предметной области, поделиться своими знаниями с коллегами, но хотелось бы делать с моделями и много других вещей. В этой статье я расскажу про самый базовый сценарий — генерация документов.
Чтобы сформировать описание модели данных необходимо создать модель с типом «Текст» (не путать с текстовой нотацией для моделей, это будет в следующих релизах). Фактически это модель из одного объекта с двумя атрибутами: название и содержимое.
Затем создать модель с типом «Преобразование моделей». Преобразования моделей, как и многое другое в нашем инструменте, являются так же моделями просто со своей специфической метамоделью. И метамодель тоже является моделью со своей метамоделью (Ecore), которая является метамоделью для самой себя :) Звучит очень заморочено, но это существенно упрощает разработку инструмента моделирования, да и в целом решение разных задач с помощью модельно‑ориентированного подхода. Вся предметная область в основе инструмента моделирования сводится к нескольким базовым понятиям типа модель, метамодель, представление моделей, валидация и преобразование моделей. Я попытался раскрыть эту идею в предыдущей статье, но она не очень зашла, вернусь к этой теме в будущих статьях.
Для преобразования моделей необходимо указать спецификацию преобразования моделей, которая тоже является моделью :)
В спецификации задано какие типы моделей могут подаваться на вход преобразования (в данном случае модели классов), какие модели будут на выходе (текстовые модели) и описан сам поток преобразования моделей. Если вам любопытно, то всё это доступно в проекте «Class Model». Можно создавать свои правила преобразования моделей, но для этого пока нет удобного интерфейса. Вернёмся к этой теме в следующих статьях.
Указать вход и выход преобразования моделей:
Запустить преобразование (в будущем добавим автозапуск):
И увидеть такой замечательный Markdown‑документ с Mermaid‑диаграммой:
Зачем генерировать Mermaid‑диаграмму, если мы уже нарисовали диаграмму, почему нельзя использовать её? Это планируется и это относительно тривиальная задача, но вся разработка инструмента моделирования состоит из подобных задач, и если их не откладывать, то будет откладываться каждый релиз. С другой стороны, мы не обязаны были рисовать диаграмму, могли создать все классы и атрибуты в навигаторе. Плюс в будущем планируются табличный и текстовый редакторы моделей, лично для меня они удобнее, чем редактор диаграмм. В этом случае есть смысл генерировать диаграммы.
Заключение
Вообще это только часть функциональности, которая сейчас реализована, про остальное буду рассказывать в следующих статьях. Что вы думаете по поводу всего этого? :)
На сколько бредовая идея разрабатывать свой инструмент моделирования?
На сколько высосаны из пальца недостатки существующих инструментов?
На сколько оторвано от реальности наше видение продукта про метамодели, которые являются метамоделями самих себя, и вообще?
На сколько стрёмная реализация?
На сколько мало технических деталей в статье?
На сколько высоко поднялся автор этой статьи на пик глупости, сначала пишет, что все инструменты моделирования — отстой, потом делает ещё больший отстой?