Комментарии 32
А мой внутренний "стеклянный шар" говорит вот что. Будущее за code first. Дело практически никогда не в инструментах, а в гибкости (не только самого рисования). И текст дает ее максимально, ты хранишь код в Git и он как ДНК твоих диаграмм, исходники. Это же удобно. Может, нужно прокачать PlantUML или Mermaid, может нужно создать новый язык, не знаю. Но в моих фантазиях, нужен нормальный двусторонний редактор, когда ты можешь менять код и поменяется превью диаграммы, или же менять диаграмму в превью и код поменяется тоже. Таких тулов я пока не видел.
На мой взгляд, нет противоречия между code first и model first. Модель — это упрощенно граф, у которого могут быть разные формы представления: диаграмма, таблица, текст/код, ... В том числе, одновременно несколько форм представления. Model first часто отождествляется с diagram first, но это не так.
Тут на скриншоте две равнозначные формы представления одной модели: диаграмма и код. Можно редактировать любое из представлений, при этом обновится второе:
Вот ещё пример, на схеме Diagram Editors и Textual DSLs:
Потом ниже более крупный пример «Coffee Editor NG»:
Ой, только я в смотрелся в их скриншот и на диаграмме и в текстовом редакторе две разные модели. Вот, другой пример:
В нашем инструменте разные формы представления моделей, включая текстовые — это одна из основных фич, ради которой мы начали его делать. В текущем релизе этого нет, но мне просто не хотелось пытаться реализовать сразу все фичи и бесконечно откладывать релиз.
Насчёт того где удобнее работать с моделями: 1) в IDE там же где код или 2) в отдельном инструменте моделирования. Я думаю это зависит от того кому. Разработчику конечно удобнее в IDE, но, например, для бизнес‑пользователей BPMN, EPC и др. модели удобнее редактировать в более простом приложении. Ещё есть промежуточные категории пользователей (архитекторы, аналитики), для которых спорный вопрос какой вариант удобнее. Поэтому мы хотим реализовать оба варианта, но не сразу.
Насчёт того где лучше хранить модели. Я сталкивался со специфическими требованиями, которые трудно закрыть Git'ом. Может требоваться версионирование отдельных моделей, а не всего проекта. Может требоваться разграничение прав доступа на уровне отдельных моделей. Может требоваться сертификация ФСТЭК, если есть модели для служебного пользования. Это отдельная большая тема: 1) если мы реализуем это на уровне приложения, то может потребоваться его сертификация, потому что оно выполняет функции безопасности 2) если это реализовано на уровне внешней системы, например, сертифицированного PostgreSQL, то нам не нужно заморачиваться с сертификацией. В общем, если хранить модели в сертифицированной СУБД, то у нас жизнь упрощается, мы относительно легко закрываем все эти требования. Плюс Git добавляет сложностей с поиском моделей, обеспечением ссылочной целостности для межмодельных связей, с производительностью. Но я понимаю, что есть много проектов, где было бы удобнее хранить модели в Git рядом с кодом, это планируется в будущем
На мой взгляд, нет противоречия между code first и model first. Модель — это упрощенно граф
А вот и причина. Текст — это тоже модель. И таблица модель. Вы зачем-то подменяете понятие модели именно графической моделью, причём именно структурной схемой (а не графиком и не макетом интерфейса).
Те вы в своей онтологии промахнулись на 2 системных уровня.
Нет‑нет, я наоборот чуть ли не в каждой статье акцентирую внимание на том, что модель и представление модели — это две разные вещи :) Модель состоит из объектов, отношений между ними, у объектов и отношений могут быть атрибуты. По крайней мере, если мы говорим об объектных моделях, есть и другие подходы. А представлена модель может быть в виде чего угодно: диаграммы, таблицы, текста,...
Например, вот, модель классов:
Вот, эта же модель описанная текстом на PlantUML:
@startuml
Person : name
Car : model
Person --> Car : owns
@endumlЭта же модель описана на Mermaid:
classDiagram
class Person {
name
}
class Car {
model
}
Person --> Car : ownsЭта же модель описана на русском языке:
Есть класс объектов «Человек» (Person), у людей может быть имя (name). Есть класс объектов «Машина» (Car), у машин есть модель (model). Люди могут владеть машиной
То же самое можно проговорить голосом, показать языком жестов. Во всех случаях модель одна и та же, формы представления — разные.
Но в моих фантазиях, нужен нормальный двусторонний редактор, когда ты можешь менять код и поменяется превью диаграммы, или же менять диаграмму в превью и код поменяется тоже.
Лет 20-25 назад хайп вокруг UML именно вокруг такого ви́дения светлого будущего и был - мол, редактор UML станет генератором кода и инструментом рефакторинга. Помню, ставил Rational Rose с интеграцией в Visual Studio и оно с грехом пополам как-то работало. Но потом выяснилось, что есть много нюансов, из-за которых всё ломается, и вообще модели более актуальны на стадии проектирования, а на стадии разработки усилия по поддержанию их актуальности уже не особо оправданы... и это в т.ч. способствовало снижению интереса к UML в целом. А уж сейчас с расцветом разных, в т.ч. смешанных, парадигм программирования, тем более сложно представить, как это могло бы взлететь.
P.S. Или Вы не про код программы, а про код самой диаграммы? Тогда присоединюсь к примерам выше, ну и самая база - расширение PlantUML для VSCode так же работает.
То есть я правильно понимаю, что модели у вас хранятся в виде текста, который удобно в условном git-е хранить и мониторить изменения, а при интеграции в CI/CD можно запустить из командной строки вашу тулзу, чтобы сгенерить изображения?
К слову, недавно познакомился с таким инструментом как IcePanel - выглядит очень достойно. Уже успели выявить конкурентные преимущества по сравнению с этим решением?=)
На данный момент модели хранятся в JSON. Для примера модель из статьи:
Пример модели в JSON
{
"ns": {
"ecore": "http://www.eclipse.org/emf/2002/Ecore",
"classmodel": "https://architeezy.com/metamodel/class-model/dev/class-model"
},
"json": {
"version": "1.0",
"encoding": "utf-8"
},
"content": [
{
"id": "01961ffe-1c41-7a49-8765-92cdca1ad16e",
"data": {
"name": "Data Model",
"classes": [
{
"id": "0196240e-43dc-7bd3-8751-39344db5f624",
"data": {
"name": "User",
"properties": [
{
"id": "0196240f-4cab-7c7c-84c7-7fa30d9bcd09",
"data": {
"name": "firstName",
"lower": "0",
"upper": "1",
"dataType": "classmodel:StringType 0195515f-aa13-7ece-992e-b3a9340e5b6b#0195515f-bf91-7e9d-86ab-e6107ad65ac6",
"localizedName": [
{
"id": "01962413-d80e-7f7a-89e0-14e9032b9ddd",
"data": {
"key": "ru-RU",
"value": "имя"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Attribute"
},
{
"id": "01962411-af83-79f9-b853-a8cf42992c21",
"data": {
"name": "lastName",
"lower": "0",
"upper": "1",
"dataType": "classmodel:StringType 0195515f-aa13-7ece-992e-b3a9340e5b6b#0195515f-bf91-7e9d-86ab-e6107ad65ac6",
"localizedName": [
{
"id": "01962413-ea6e-7e32-86ea-8d955d6740ae",
"data": {
"key": "ru-RU",
"value": "фамилия"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Attribute"
},
{
"id": "01962412-1f0b-7b62-9f32-90959bd9455f",
"data": {
"name": "birthDate",
"lower": "0",
"upper": "1",
"dataType": "classmodel:TimeType 0195515f-aa13-7ece-992e-b3a9340e5b6b#0195b499-6517-74d3-9576-6d1597ca0722",
"localizedName": [
{
"id": "01962414-25ea-7a90-b9f1-aa12f4717ecd",
"data": {
"key": "ru-RU",
"value": "дата рождения"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Attribute"
},
{
"id": "01962411-ec60-796d-8c8a-ee77bdee02e6",
"data": {
"name": "email",
"lower": "1",
"upper": "1",
"dataType": "classmodel:StringType 0195515f-aa13-7ece-992e-b3a9340e5b6b#0195515f-bf91-7e9d-86ab-e6107ad65ac6",
"localizedName": [
{
"id": "01962414-0a73-75f0-b9da-6ff1544207a9",
"data": {
"key": "ru-RU",
"value": "электронная почта"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Attribute"
}
],
"localizedName": [
{
"id": "01962413-9a75-7847-b531-a457db1acf26",
"data": {
"key": "ru-RU",
"value": "пользователь"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Class"
},
{
"id": "01962306-056e-7951-a4c1-33c3dc5ffb6b",
"data": {
"name": "Order",
"properties": [
{
"id": "01962431-d53f-7ff1-839f-1329ea83fe04",
"data": {
"name": "deliveryAddress",
"lower": "1",
"upper": "1",
"dataType": "classmodel:StringType 0195515f-aa13-7ece-992e-b3a9340e5b6b#0195515f-bf91-7e9d-86ab-e6107ad65ac6",
"localizedName": [
{
"id": "01962448-533a-756d-bfc9-03394be248ec",
"data": {
"key": "ru-RU",
"value": "адрес доставки"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Attribute"
},
{
"id": "0196240f-3776-7b6c-a0db-de579542dd7b",
"data": {
"name": "user",
"lower": "1",
"upper": "1",
"target": "0196240e-43dc-7bd3-8751-39344db5f624",
"localizedName": [
{
"id": "01962566-cc90-70ff-b326-ee739aae78e6",
"data": {
"key": "ru-RU",
"value": "пользователь"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Reference"
},
{
"id": "0196240d-da5e-77bb-b006-c57ca21ebe9e",
"data": {
"kind": "Composition",
"name": "items",
"lower": "0",
"upper": "-1",
"target": "01961ffe-7c4e-7dfd-94e1-29901f5f02c4",
"opposite": "01962577-1deb-7f01-b8c9-76a04710045f",
"localizedName": [
{
"id": "01962566-54ad-77da-af02-43cfb198af8b",
"data": {
"key": "ru-RU",
"value": "элементы"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Reference"
}
],
"localizedName": [
{
"id": "01962415-4a5e-7692-b874-910cb1cdea46",
"data": {
"key": "ru-RU",
"value": "заказ"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Class"
},
{
"id": "01961ffe-7c4e-7dfd-94e1-29901f5f02c4",
"data": {
"name": "OrderItem",
"properties": [
{
"id": "01962430-daa4-7a71-979a-01340000f8aa",
"data": {
"name": "quantity",
"lower": "1",
"upper": "1",
"dataType": "classmodel:NumericType 0195515f-aa13-7ece-992e-b3a9340e5b6b#0195676e-9ae5-79eb-a151-0517c7b15dba",
"localizedName": [
{
"id": "01962431-0eff-74fb-aa83-644522372618",
"data": {
"key": "ru-RU",
"value": "количество"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Attribute"
},
{
"id": "01962415-dafc-7891-9a3f-9c32f90c4766",
"data": {
"name": "price",
"lower": "1",
"upper": "1",
"dataType": "0196242d-fbac-7c3f-b854-4afd9282ad86",
"localizedName": [
{
"id": "01962448-71ff-7686-accb-629c86168044",
"data": {
"key": "ru-RU",
"value": "стоимость"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Attribute"
},
{
"id": "01961ffe-ff00-7746-8e1e-0b0286ac5031",
"data": {
"name": "product",
"lower": "1",
"upper": "1",
"target": "01961ffe-2a5a-7c83-bdec-aec0658b0646",
"localizedName": [
{
"id": "01962576-1752-7312-9196-b17f0d7b371a",
"data": {
"key": "ru-RU",
"value": "продукт"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Reference"
},
{
"id": "01962577-1deb-7f01-b8c9-76a04710045f",
"data": {
"name": "order",
"lower": "1",
"upper": "1",
"target": "01962306-056e-7951-a4c1-33c3dc5ffb6b",
"opposite": "0196240d-da5e-77bb-b006-c57ca21ebe9e"
},
"eClass": "classmodel:Reference"
}
],
"localizedName": [
{
"id": "01962415-8f2a-7999-af61-794d05e17be6",
"data": {
"key": "ru-RU",
"value": "элемент заказа"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Class"
},
{
"id": "01961ffe-2a5a-7c83-bdec-aec0658b0646",
"data": {
"kind": "Abstract",
"name": "Product",
"properties": [
{
"id": "01962005-e913-778b-b086-4ee9231580d6",
"data": {
"name": "name",
"lower": "1",
"upper": "1",
"dataType": "classmodel:StringType 0195515f-aa13-7ece-992e-b3a9340e5b6b#0195515f-bf91-7e9d-86ab-e6107ad65ac6",
"localizedName": [
{
"id": "01962415-b986-70ba-8a9f-c29b3159c17c",
"data": {
"key": "ru-RU",
"value": "название"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Attribute"
}
],
"localizedName": [
{
"id": "01962415-a3ec-7588-bc94-8149c3c6b077",
"data": {
"key": "ru-RU",
"value": "продукт"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Class"
},
{
"id": "01962001-cc38-7001-92d5-6cff9fefd62f",
"data": {
"name": "Book",
"generals": [
"01961ffe-2a5a-7c83-bdec-aec0658b0646"
],
"properties": [
{
"id": "01962006-0c1d-7d8e-87c8-3e50d899eac5",
"data": {
"name": "author",
"lower": "1",
"upper": "1",
"dataType": "classmodel:StringType 0195515f-aa13-7ece-992e-b3a9340e5b6b#0195515f-bf91-7e9d-86ab-e6107ad65ac6"
},
"eClass": "classmodel:Attribute"
}
],
"localizedName": [
{
"id": "01962449-1f47-7753-bd3c-4a032d508072",
"data": {
"key": "ru-RU",
"value": "книга"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Class"
},
{
"id": "01962002-011f-7db5-9367-25039ffcd036",
"data": {
"name": "Pen",
"generals": [
"01961ffe-2a5a-7c83-bdec-aec0658b0646"
],
"properties": [
{
"id": "01962006-3502-7f12-87c0-64f06c4b0276",
"data": {
"name": "color",
"lower": "1",
"upper": "1",
"dataType": "01962006-8b6c-780e-bd63-038b6bd1e951",
"localizedName": [
{
"id": "01962449-8a9e-7f5d-bc93-07fe51e8209a",
"data": {
"key": "ru-RU",
"value": "цвет"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Attribute"
}
],
"localizedName": [
{
"id": "01962449-7a12-7f2e-9da3-ca50712d9a2f",
"data": {
"key": "ru-RU",
"value": "ручка"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:Class"
}
],
"dataTypes": [
{
"id": "0196242d-fbac-7c3f-b854-4afd9282ad86",
"data": {
"name": "Money",
"totalDigits": "19",
"minInclusive": "0",
"localizedName": [
{
"id": "01962430-5830-741c-b539-cb0fc851a3de",
"data": {
"key": "ru-RU",
"value": "денежный тип"
},
"eClass": "ecore:EStringToStringMapEntry"
}
],
"fractionDigits": "4"
},
"eClass": "classmodel:NumericType"
},
{
"id": "01962006-8b6c-780e-bd63-038b6bd1e951",
"data": {
"name": "Color",
"literals": [
{
"id": "01962006-dab5-7f51-b9e4-275e984fd447",
"data": {
"name": "Red",
"localizedName": [
{
"id": "01962449-b7f2-7b5d-8916-a3f2a364e001",
"data": {
"key": "ru-RU",
"value": "красный"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:EnumeratedTypeLiteral"
},
{
"id": "01962006-f161-7b16-84a7-02337e992cd1",
"data": {
"name": "Green",
"localizedName": [
{
"id": "01962449-c92a-772e-b073-41dfe2deede0",
"data": {
"key": "ru-RU",
"value": "зеленый"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:EnumeratedTypeLiteral"
},
{
"id": "01962007-0697-7908-a9a8-9beef0d310c9",
"data": {
"name": "Blue",
"localizedName": [
{
"id": "01962449-dadd-7448-96b7-1a65304d1007",
"data": {
"key": "ru-RU",
"value": "синий"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:EnumeratedTypeLiteral"
},
{
"id": "01962007-1c49-75b1-a045-d5790ed94540",
"data": {
"name": "Black",
"localizedName": [
{
"id": "01962449-eb37-7579-af4f-a132e22e7d2f",
"data": {
"key": "ru-RU",
"value": "черный"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:EnumeratedTypeLiteral"
}
],
"localizedName": [
{
"id": "01962449-a756-71c8-8d86-5c5e671a24d7",
"data": {
"key": "ru-RU",
"value": "цвет"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:EnumeratedType"
}
],
"localizedName": [
{
"id": "0196255c-4341-7013-ae0b-53a194d584d5",
"data": {
"key": "ru-RU",
"value": "модель данных интернет-магазина"
},
"eClass": "ecore:EStringToStringMapEntry"
}
]
},
"eClass": "classmodel:ClassModel"
}
]
}Для обмена моделями есть стандартный формат OMG XMI, который поддерживается в разных инструментах моделирования. У нас JSON по структуре совпадает с этим XMI и легко в него мапится при необходиомсти.
Диаграммы хранятся отдельно тоже в JSON (в котором уже информация о координатах фигур и связей и т. д.), т. е. модели и их представления отделены и это упрощает версионирование моделей, слияние изменений.
Почему вместо JSON не использовать более человеческий формат типа PlantUML, Structurizr и т. д.? Потому что для каждого типа моделей нужно создавать свою грамматику. Мы бы так и сделали, если бы у нас было ограниченное количество языков моделирования (модели данных, C4 и всё). Но у нас расширяемый инструмент моделирования, который поддерживает произвольные языки моделирования (например, модели требований, модели для поддержки принятия решений и всё что угодно). Если для моделей классов ещё есть какие‑то текстовые нотации, то для EPC, VAD и многих других моделей обычно используют только диаграммы. т. е. нет универсальной текстовой нотации.
Можно было бы вместо JSON использовать YAML или ещё какую‑нибудь упрощенную (по сравнению с JSON), но универсальную (по сравнению с PlantUML) нотацию, но с ними будет сложнее работать чем с JSON. Для технического внутреннего представления JSON удобнее.
Короче на данный момент можно выгрузить/загрузить модель в JSON через API.
В следующих релизах мы планируем текстовые нотации для моделей (типа PlantUML, Structurizr и т. д.). Тогда можно будет редактировать, загружать, выгружать, хранить модели в таком виде. Но пока этого нет.
Насчёт запуска преобразований моделей, генерации документов и кода. На данный момент они запускаются внутри инструмента моделирования. Можно через API загрузить в него модель, запустить преобразование, получить результат. В том числе через CI/CD. Но все эти преобразования у нас пишутся на относительно стандартных языках (преобразования модель‑модель на QVTo, преобразования модель‑текст на Acceleo). Вот, например, шаблон для генерации документов из статьи:
Пример шаблона для генерации документов
[module module('https://architeezy.com/metamodel/class-model/dev/class-model')/]
[template public generate(model : classmodel::ClassModel)]
# [model.getCapitalizedName()/]
```mermaid
---
config:
class:
hideEmptyMembersBox: true
---
classDiagram
[for (cls : classmodel::Class | model.classes)]
class `[cls.getCapitalizedName()/]`
[/for]
[for (cls : classmodel::Class | model.classes)]
[for (general : classmodel::Class | cls.generals)]
`[general.getCapitalizedName()/]` <|-- `[cls.getCapitalizedName()/]`
[/for]
[/for]
[for (cls : classmodel::Class | model.classes)]
[for (ref : classmodel::Property | cls.properties->filter(classmodel::Reference)->select(ref | ref.isForward()))]
`[cls.getCapitalizedName()/]` [ref.getEdge()/] `[ref.target.getCapitalizedName()/]`
[/for]
[/for]
```
[for (cls : classmodel::Class | model.classes)]
## [cls.getCapitalizedName()/]
| Свойство | Название (англ.) | Тип данных | Мн. | Описание |
| -------- | ---------------- | ---------- | :-: | -------- |
[for (prop : classmodel::Property | cls.getAllProperties())]
| [prop.getCapitalizedName()/] | [prop.name/] | [prop.getType().getName()/] | [prop.getMultiplicity()/] | [prop.getDescription()/] |
[/for]
[/for]
[/template]
[query private isForward(ref : classmodel::Reference) : Boolean =
ref.opposite = null or
ref <> ref.opposite.opposite or
ref.owner = null or
ref.opposite.owner = null or
ref.kind <> classmodel::ReferenceKind::Association or
ref.owner.model <> ref.opposite.owner.model or
ref.owner.model.classes->indexOf(ref.owner) < ref.owner.model.classes->indexOf(ref.opposite.owner) or
ref.owner.model.classes->indexOf(ref.owner) = ref.owner.model.classes->indexOf(ref.opposite.owner)
and (ref.name = null or ref.opposite.name = null or ref.name <= ref.opposite.name) /]
[query private getEdge(ref : classmodel::Reference) : String =
if ref.kind = classmodel::ReferenceKind::Composition then '*-->' else
if ref.kind = classmodel::ReferenceKind::Aggregation then 'o-->' else '-->' endif endif /]
[query private getAllProperties(class : classmodel::Class) : OrderedSet(classmodel::Property) =
class.generals.getAllProperties()->union(class.properties) /]
[query private getName(element : classmodel::NamedElement) : String =
if element.localizedName->exists(entry | entry.key = 'ru-RU')
then element.localizedName->select(entry | entry.key = 'ru-RU')->first().value
else element.name endif /]
[query private getCapitalizedName(element : classmodel::NamedElement) : String =
element.getName().toUpperFirst() /]
[query private getDescription(element : classmodel::NamedElement) : String =
if element.localizedDescription->exists(entry | entry.key = 'ru-RU')
then element.localizedDescription->select(entry | entry.key = 'ru-RU')->first().value
else '' endif /]
[query private getType(prop : classmodel::Property) : classmodel::NamedElement =
if prop.oclIsKindOf(classmodel::Attribute)
then prop.oclAsType(classmodel::Attribute).dataType
else prop.oclAsType(classmodel::Reference).target endif /]
[query private getMultiplicity(prop : classmodel::Property) : String =
if prop.lower = prop.upper
then prop.lower
else prop.lower + '..' + if prop.upper.toString().toInteger() = -1 then '*' else prop.upper endif endif /]И эти QVTo и Acceleo преобразования вполне могут запускаться вне нашего инструмента моделирования. Они написаны на относительно стандартных для этой области языках и не являются чем‑то проприетарным, внутренними деталями нашего инструмента.
Но эти DSL мало знакомы людям, поэтому планируется, что для подобных преобразований будет поддерживаться ещё Python. Скрипты можно будет запускать как внутри приложения, так и снаружи.
Мне немного стрёмно отвечать, что пока этого нет, но планируется. Но невозможно сделать всё сразу.
Насчет IcePanel. Мы не ограничиваемся только проектированием информационных систем. У нас основной акцент на расширяемости инструмента моделирования, чтобы можно было легко добавлять новые нотации моделирования. Кроме C4 мне ещё много всего нужно, например, описать бизнес‑требования и системные требования, оценить трудозатраты, приоритеты, описать API, модель данных и т. д. Плюс нужны модели, которые вообще далеко за рамками проектирования ПО. Генерить из этого разные документы и код по своим шаблонам. IcePanel — это более узкоспециализированный инструмент, который решает более узкую задачу. И безусловно делает это лучше, у них диаграммы гораздо приятнее и много всего из коробки. У нас другой приоритет — сделать максимально гибкую платформу для произвольных инструментов моделирования и на базе неё уже создавать архитектурные репозитории и т. д. Грубо говоря, создать платформу для IcePanel и аналогичных инструментов. В долгосрочной перспективе я уверен, что наш подход лучше, но мы ещё только в начале пути
Более того, даже если это online‑моделер типа ARIS Express, то заполнять кучу форм на сайте, чтобы они позволили мне 30 дней пользоваться их инструментом я тоже не буду.
Ранее было необходимо при инсталляции ARIS Express разово зайти под учеткой Aris Community и далее работало off-line. Полагаю, что и сейчас также.
Метамодель определяет объекты каких типов могут использоваться в модели, какими типами отношений они могут связываться и какие атрибуты могут быть у объектов и отношений.
Подробно про метамодель ARIS в двух книжках (вторая на 5000+ страницах): https://github.com/bpmbpm/doc/tree/main/BPM/ARIS/SCHEER/BASE
В draw.io всё это делать нельзя, потому что в нём диаграмма — это просто картинка, состоящая из квадратиков, кружочков или более сложных фигур, а не модель, состоящая из классов, процессов, функций с соответствующими атрибутами типа стоимости и длительности выполнения функции.
В drawio, yEd, visio и подобном задается «корпоративный шаблон», откуда уже выбираются фигуры. Шаблон отражает заданную метамодель. Контроль синтаксиса также возможен, например, в visio через вкладку Процесс можно задать правила и валидировать схему.
И увидеть такой замечательный Markdown‑документ с Mermaid‑диаграммой:
Про это же, где вместо кода табличка:
Преобразование код – табличка и наоборот не проблема.
На сколько бредовая идея разрабатывать свой инструмент моделирования?
Инструментов моделирования много. Кого видите ближайшим конкурентом «Наш инструмент моделирования»?
1 Пока нет ни одного нормального Open Source инструмента моделирования бизнес-процессов, поэтому актуален именно Open source проект \ Open source ARIS. ARIS – это «система номер 1» в моделировании.
2 Пока нет семантического инструмента моделирования бизнес-процессов. Поэтому лучше сразу скрестить «два мира»: мир моделирования (формализация процессов и архитектур) и формализацию знаний (Linked Dada), что и планируем в проекте Semantic BPM (Semantic ARIS). Присоединяйтесь.
Например, Метамодель процессов
Модели планируется хранить как TriG (RDF) / QuadStore, запросы (изменения) через SPARQL, т.е. каркас ARIS-based (классическая BPM-система), а внутри системы моделирования семантический движок (RDF-based). Semantic BPM – это концепт BPM – системы: «два в одном флаконе» классическая ARIS подобная система с классической семантикой (Linked Dada) «под капотом».
Насчет ARIS. У них действительно огромные справочники типов объектов и связей. И они даже включают UML, BPMN, ArchiMate. Меня смущает в их подходе то, что они не используют стандартные метамодели: UML, BPMN, ArchiMate. Они просто добавили такие же типы объектов, но вопрос все ли. Плюс исходные метамодели сложнее, например, в ArchiMate иерархия классов:
А в ARIS нет этой иерархии, справочник плоский.
Хотя для человека, который строит модель, вообще не принципиально какая метамодель под капотом, есть там это наследование классов или нет. Но если метамодель стандартная, то это упрощает интеграцию с тем же Archi или BPMN-, UML-моделерами. Не нужно реализовывать кастомный импорт/экспорт как в ARIS. Просто используется готовая метамодель ArchiMate, такая же как в Archi, и модели имеют одинаковую структуру во всех инструментах.
Или для тех же EPC, VAD моделей так и не появилось единого стандарта. В каждом инструменте используется свой вариант EPC и их десятки. Это логично, потому что ARIS — наверное один из основных инструментов, в котором используются EPC, но ARIS создавался ещё до появления стандартов OMG. Поэтому метамодели они хранят в своём кастомном формате, а не MOF. Из этого следует то, что у них и модели хранятся в проприетарном формате, и для скриптов нельзя использовать стандартные языки типа QVTo, Acceleo, или готовые сторонние инструменты для работы с моделями. ARIS — вещь в себе. Они даже не озадачивались продвижением единого стандарта для EPC моделей и т. д. Но может это и не задача разработчиков ARIS, у них есть методика, есть инструмент, который работает и много где используется.
С другой стороны, я уверен, что если бы ARIS создавался сейчас, то они наверняка использовали бы стандарты OMG, а не делали проприетарные форматы для метамоделей, моделей, проприетарные API для работы с моделями. Я не ругаю ARIS, просто на тот момент у них не было такого выбора инструментов, большую часть вещей приходилось создавать с нуля. И в вашем проекте как‑раз используются стандарты — RDF, SPARQL, что позволяет переиспользовать готовые инструменты и не создавать многие вещи с нуля.
Проблема в том, что они разные и содержательно, и визульно в разных инструментах моделирования, нет единого стандарта. В ARIS я видел три стиля для диаграмм:
Как по вашей ссылке, фигуры между собой сильно отличаются по форме (овалы для участников, пятиугольники для продуктов, ...). Такой вариант был в каких‑то версиях ARIS, и сейчас используется в других инструментах, например, в Business Studio
Потом в одной из версий почти все фигуры сделали прямоугольными, и они отличаются только цветом и значком слева. Например, EPC. Этот вариант я как‑раз и брал за основу, нарисовал что‑то похожее по смыслу. И по моим ощущениям, он многим нравится больше, чем 1-ый вариант
И ещё есть слишком разноцветный вариант с градиентами, я точно не знаю, может это последние версии ARIS, но для меня это too much
В drawio, yEd, visio и подобном задается «корпоративный шаблон», откуда уже выбираются фигуры. Шаблон отражает заданную метамодель. Контроль синтаксиса также возможен, например, в visio через вкладку Процесс можно задать правила и валидировать схему.
Наверное, да, я не погружался на столько глубоко в Visio. Для меня проблема Visio в том, что они не используют никакие стандарты в области моделирования. Например, для описания структуры моделей есть OMG MOF, а для описания дополнительных ограничений - OMG OCL. В этой статье про оба стандарта. Они поддерживаются в большом количестве инструментов моделирования. И если их использовать, то нет vendor lock. Если в силу разных причин понадобилось перейти на другой инструмент моделирования, то все метамодели и OCL‑правила просто переносятся в этот инструмент как есть, не нужно всё переделывать. А шаблоны и правила валидации Visio работают только в Visio, также как и методологические фильтры, скрипты, дополнительные модули для ARIS работают только в ARIS — это vendor lock.
Насчёт ближайших конкурентов. Это важный вопрос, но наверное я его отложу до следующих статей ( Мы точно не делаем аналог ARIS и не планируем с ним конкурировать. ARIS — это инструмент для крупных корпораций с отделами моделирования, с сотрудниками, которые долго обучались моделированию. Мы хотим сделать что‑то гораздо более простое и массовое. Например, я архитектор, мне нужно описать архитектуру приложения, сгенерить по модели документацию, код, приоритезировать требования. Или другой пример, я вообще не из ИТ и не из бизнеса, просто хочу сменить работу, квартиру, машину — хочу потратить 15 минут и сделать оптимальный выбор. Хотелось бы инструмент моделирования, который поможет мне в этих задачах. Хотя я не вижу противоречия, не обязательно корпоративные инструменты моделирования должны быть супер‑сложными, и не обязательно массовые инструменты моделирования должны быть слишком примитивными.
У вас клёвый подход с RDF, семантическим движком. У нас пока основной акцент на связанных, но немного других вещах, мы ещё не озадачивались логическим выводом фактов, интеграцией с инструментами, основанными на RDF и связанных стандартах, вместо семантической разметки диаграмм у нас по сути обратный подход тоже семантическая разметка (потому что диаграммы и модели хранятся отдельно), но только своих диаграмм, а не сторонних
ARIS развивался до его продажи Software AG. И visio был также давно заброшен MS.
Это уже BPM – мастодонты. Однако концептуально ничего нового не придумано и все, во всяком случае отечественные BPM – системы, пытаются всего лишь повторить «старину» ARIS. "BPM - концепту" нужен новый импульс, ... и это семантика: семантические технологии, графы знаний и т.п.
С вашими сторонниками «с Сириуса» обсуждали в свете BPM (M=modeling) тему MOFvsRDF
В своем проекте вы как-то формализовали такие понятия как «образ процесса – индивид процесса – исполняемый экземпляр процесса» с формированием соответствующих логических элементов (отдельных деревьев \ иерархических структур) в общем репозитарии? См. E1 Ontology
У нас такая схема:
1) На верхнем уровне метамодель, которая описывает основные понятия предметной области. Вот, например, для EPC (BPMN не делали, возьмем готовую):
В соответствии с метамоделью есть корневая сущность «Событийная цепочка процесса» (EventDrivenProcessChain), она состоит из сущностей (Entity) и отношений (Relationship). Сущности могут быть следующих видов: событие, функция, участник и т. д. И для отношений тоже разные подтипы.
2) На следующем уровне создаём уже конкретную модель с конкретными событиями, функциями и т. д.
Т. е. в метамодели определены классы объектов, а в модели их экземпляры.
3) На следующем уровне по идее этот процесс должен выполняться (в системе управления процессами или физически в реальности). По каждому исполнению может собираться какая‑то статистика о конкретных исполнителях, о длительности выполнения функций, о стоимости используемых ресурсов и т. д. В принципе этот уровень может понадобиться в системе моделирования, например, чтобы посчитать среднее время выполнения разных функций и показать его в модели на 2-м уровне. Или чтобы по этим журналам выполнения построить модель процесса на 2-м уровне (process mining). Или при имитационном моделировании процесса такой журнал может генерироваться. В этом случае нужна метамодель, которая описывает такую сущность как «Информация о выполнении процесса» (или «Журнал выполнения процесса»), включающая информацию о выполнении отдельных функций, об используемых ресурсах. А на уровне модели будут конкретные значения для всего этого
В своем проекте вы как-то формализовали такие понятия как «образ процесса – индивид процесса – исполняемый экземпляр процесса»
Если я правильно понял, то в нашей терминологии «образ процесса» — это модель процесса, «индивид процесса» — это ссылка на модель процесса из более верхнеуровневой модели, «исполняемый экземпляр процесса» — это информация о конкретном исполнении процесса.
Пусть для примера будет одна из самых популярных тем на хабре — процесс найма сотрудников :) Есть верхнеуровневый процесс «Нанять сотрудника». Условно он состоит из функций/шагов: собрать требования по вакансии, разместить вакансию, отобрать кандидатов, пригласить кандидата на собеседование, провести собеседование, оценить кандидата, предложить кандидату условия работы, закрыть вакансию. Каждая из этих функций может быть описана более детально. Например, оценка кандидата может включать шаги: оценка софт‑скилов, оценка хард‑скилов, оценка стрессоустойчивости и т. д.
Короче, в этом примере «Нанять сотрудника» — это модель процесса (в вашей терминологии — «образ процесса»), она включает функцию «Оценить сотрудника» (в вашей терминологии — «индивид процесса»), которая может детализироваться на модель «Оценить сотрудника» (в вашей терминологии — «образ процесса»), которая включает в себя функции которые могут дальше детализироваться. Модель «Оценить сотрудника» может переиспользоваться в разных процессах: найм сотрудников извне, внутренний найм, ежегодная оценка эффективности сотрудника и т. д.
Где‑то рядом с инструментом моделирования может быть HR‑система или CRM или система управления процессами или ещё что‑то, где фиксируется информация о выполнении этих процессов. Какой именно HR работает по этой вакансии, какого числа и в какое время он разместил вакансию, сколько кандидатов нашёл, когда отправил им приглашение, когда они ответили, когда было собеседование, сколько оно длилось, сколько человек в нём участвовало и соответственно во сколько это обошлось компании и т. д. В вашей терминологии это «исполняемый экземпляр процесса». В нашей терминологии все эти данные можно втянуть обратно в инструмент моделирования в виде модели «Журнал выполнения процесса». В итоге у нас есть две модели «Модель процесса» и «Журнал выполнения процесса» и мы можем делать с этими моделями разные вещи, описанные выше
Был у меня недолгий период увлечения UML. На практике оказалось, что поддерживать модель в актуальном состоянии практически невозможно. Не было (и насколько я знаю, до сих пор нет) ни одного инструмента, способного её качественно перегенерить согласно изменениям в коде. Даже такие очевидные разновидности, как диаграмма классов – не говоря уж о более высоких абстракциях типа use cases. А без этого оно бесполезно.
Ещё как-то случилось чуток поработать с IBM Visual Age C++. Воспоминания жуткие, любой сколько-нибудь сложный проект тут же превращается с месиво из стрелочек, которое даже авторы вскоре перестают понимать – не говоря уж о всех остальных.
У меня обратная проблема :) Например, у приложения есть схема данных. Для неё нужен Java‑код, нужны SQL скрипты с миграциями базы данных и нужна документация. Java‑код должен быть нормально оформлен, чтобы в нём был Javadoc, чтобы поля, геттеры, сеттеры шли в осмысленном порядке (чтобы этот код было проще читать), чтобы нигде не забыть аннотации Hibernate (если мы его используем), чтобы был корректный код для двунаправленных связей (в Hibernate это отдельная боль). Аналогично для SQL‑скриптов — нигде не забыть индексы, внешние ключи, ограничения, чтобы названия у всего этого были по единой схеме. Плюс ещё документация постоянно устаревает.
Вручную запаришься всё это делать. На много проще, например, добавить новый класс в модель, а всё остальное перегенерить.
Т. е. для моделей данных такой подход на мой взгляд вполне оправдан. Применимо ли это ещё для каких‑то моделей? Возможно для машин состояний. Например, в одном проекте используется XState (что меня совсем не радует, потому что он там используется для вещей, для которых вообще не должен использоваться), но в принципе визуализировать это в виде диаграммы удобно.
Другой пример — OpenAPI (Swagger), который используется повсеместно. Можно либо описать модель API (на языке YAML, но это просто форма представления модели, она может быть и текстовой, не обязательно в виде диаграммы) и сгенерить по ней скелет кода, либо модель API строится по уже существующему коду, а затем по ней генерится HTML‑страничка с описанием API и возможностью отправлять запросы.
Protobuf — та же история.
И вообще любые DSL — это в чистом виде использование модельно‑ориентированного подхода. Это просто модели, но с текстовой нотацией.
ETL‑процессы обычно описываются в виде моделей.
Я думаю, что раньше было утопичное представление о моделировании и модельно‑ориентированном подходе: человек, который вообще ничего не понимает в программировании рисует UML модель, нажимает кнопку и генерится код для чего угодно (код для модели данных, Photoshop, компьютерная игра любой сложности, система управления космическими кораблями :) Мне это что‑то напоминает, наверное: пишешь промпт для ИИ, нажимаешь кнопку и получаешь что угодно.
В итоге это оказалось нереально. Но сейчас на мой взгляд этот подход стал достаточно зрелым и используется повсеместно, если не ограничиваться только UML. К UML я и сам скептически отношусь.
для моделей данных такой подход на мой взгляд вполне оправдан
Да, в таком ограниченном варианте использования – вполне возможно. Но мечталось-то, что весь проект можно будет держать в понятной визуальной модели 🙂 Не получилось.
Я лет через 10 после того, как сам бросил это дело, был на каком-то митапе, и одна из лекций была как раз по моделированию – заглянул по старой памяти. Мужик долго рассказывал, какой UML чудесный, а закончил тем, что его повсеместному внедрению пока мешает одно мелкое, но досадное обстоятельство: отсутствие средств переноса изменений кода в модель. Надо кому-то это быстренько сделать (желательно, для всех основных языков) , и сразу наступит всеобщее щастье.
Непонятно, в чем конкурентное преимущество этого инструмента (новизна, существенные отличия и полезность)? Похожих можно найти десяток. Могу назвать область, куда еще имеет смысл двигаться, так как там всё еще новое, сырое, ограниченное и негибкое, и поэтому конкурентов легче обойти: Data Catalog, заменяющий архаичные и трудоемкие маппинги на Excel и в Confluence. Но туда имеет смысл двигаться, только если у вас есть эрудированные, творческие системные аналитики (аналитики DWH) с разнообразным опытом, знающие проблемы изнутри
Основное отличие — это совмещение двух несовместимых вещей: 1) простота и массовость инструментов типа draw.io, figma 2) фичи enterprise‑моделеров (возможность создавать свои нотации, свои преобразования моделей, шаблоны для генерации документов и кода, поддержка разных форм представления моделей, разные методы анализа моделей, валидация и версионирование моделей, соответствие стандартам, удобное API).
Data Catalog — на сколько я понимаю, это агрегированная модель данных для всех баз данных на предприятии и наверное не только баз данных, возможность перехода от модели к самим данным, метрики для данных, наверное описание потоков данных и другие сопутствующие вещи? Для такого проекта действительно нужно либо самим быть погруженными в эту предметную область, либо найти погруженных людей, но для этого нужен заказчик/инвестор, который оплатит их работу. Лично я что‑то понимаю в разработке инструментов моделирования, в моделировании, в кодогенерации, в архитектуре, в целом в процессе разработке, поэтому мне проще двигаться с этой стороны. Но в итоге у нас цель придти к инструменту, в котором «эрудированный системный аналитик» сможет создать каталог данных или что‑то подобное, а в идеале даже не аналитик и вообще не ИТшник сможет решить свою задачу типа такой
Каким инструментом моделирования пользовались при проектировании данного продукта? Просто интересно.
Мы используем только Eclipse Modeling Framework для описания таких метамоделей:
По ним генерится Java‑код. У нас порядка 30% кода сгенерировано таким образом. Но Eclipse — не самый удобный и простой инструмент, это одна из причин почему мы начали делать свой.
Одна из целей — это чтобы в нашем же инструменте моделирования были модель данных нашего приложения, C4 архитектура, дорожная карта, бизнес‑требования, их оценка и приоритезация, возможно сценарии использования системы. Чтобы придти к этому нам нужно:
Описывать метамодели для всех этих языков моделирования (модели данных, C4, дорожная карта, бизнес‑требования,...) не в Eclipse, а у нас. Чтобы в нашем инструменте в принципе поддерживались эти языки моделирования
Получить упрощенный древовидный редактор и формы свойств для этих моделей
Получить более сложный диаграммный редактор моделей
Добавить генераторы документов и кода из моделей (генератор SQL‑скриптов, Java‑кода, чтобы не использовать для генерации Eclipse или не писать этот рутинный код руками)
Добавить табличный редактор моделей для дорожной карты и бизнес‑требований. Да и для моделей данных тоже
Добавить текстовый редактор для моделей данных, C4 и других моделей если понадобится. Для меня лично это не является блокирующей фичей, но учитывая хайп с code first, architecture as code, с языковыми моделями и т. д. это важная фича
Сейчас мы на середине 4-го шага.
Конкретно на этом проекте мы принципиально ничем другим не пользуемся, цель довести свой инструмент моделирования до ума. А в целом обычно это комбинация XWiki или Confluence + draw.io + Excel. Это примитивно, но закрывает большую часть потребностей, просто нет нужды в каких‑то более сложных инструментах типа Archi, Capella, Papyrus, не говоря о коммерческих инструментах типа Rational Software Architect, Enterprise Architect и т. д. Если нужно генерить какой‑нибудь код или документы, то ещё Eclipse, Eclipse Sirius, Acceleo, QVTo.
Это одна из причин, по которой мы начали делать свой инструмент, есть
Слишком примитивные и разрозненные XWiki, draw.io, Excel
Более целостные и функциональные enterprise‑моделеры, но при этом с кучей лишней функциональности и не всегда легко расширяемые
Максимально расширяемые, но слишком сложные для нормальных людей инструменты на базе Eclipse
Хочется сделать что‑то среднее между всем этим, чтобы инструмент был и простым, и функциональным, и расширяемым
Моделирования чего? Изменения давления в трубах при фазовых переходах? Развития межличностных отношений у сусликов?
Удивительно, что энтузиасты моделирования не умеют точно называть предмет обсуждения
Я не специалист по сусликам, не знаю на сколько точная модель:
Но в принципе, можно для ветвлений добавить вероятности перехода по одной или другой ветке. Задать распределение вероятностей появления новых сусликов, длительности прогулки суслика и т. д. Запустить имитационное моделирование для этой модели (в текущей версии этого пока нет) и дальше что‑то делать с результатами в зависимости от целей моделирования.
В фазовых переходах в трубах я разбираюсь ещё меньше, не знаю что там обычно моделируют, но идея та же. Я согласен, что есть много разных инструментов моделирования, мы не пытаемся сделать Matlab, BIM‑систему, инструмент для 3D‑моделирования или что‑то подобное. Но очень сложно в двух словах описать что в этом инструменте можно моделировать, да, что угодно — архитектуру ПО, деятельность предприятия, генеалогическое древо, рецепты приготовления пирожков
Если про имитационное моделирование процессов, то простой и open source:
Да, согласен, хороший, и я даже черпал из него какие‑то идеи, когда мы реализовывали имитационное моделирование в одном проекте. Но лично мне часто требовалось реализовать разные методы анализа моделей (например, функционально‑стоимостный анализ или метод анализа иерархий) и хочется чтобы такие задачи решались с минимальными усилиями в самом инструменте моделирования. Чтобы эти методы анализа при необходимости легко расширялись. Например, мне понадобилось не просто задать фиксированную длительность выполнения задачи в процессе, а задать для неё логнормальное распределение. Или понадобилось учитывать производственный календарь. Или чтобы имитационное моделирование запускалось для EPC‑моделей или ещё каких‑нибудь моделей. В большинстве инструментов моделирования сделать что‑то подобное — это целая проблема: приходится покупать дополнительные модули и платить кучу денег за их доработку или самим писать кучу сложного кода или использовать сторонние системы и заморачиваться с экспортом/импортом моделей. Хотя реально, если инструмент моделирования нормальный, то в нём эта задача может быть решена гораздо проще
Но очень сложно в двух словах описать что в этом инструменте можно моделировать, да, что угодно — архитектуру ПО, деятельность предприятия, генеалогическое древо, рецепты приготовления пирожков
Работа аналитиков, архитекторов, а тем более онтологов и методологов, на которых вы замахиваетесь, как раз и состоит в выборе адекватных моделей. Именование категории моделей — это тоже модель и моделирование.
Вы видимо говорите о графовых схемах.
Вот модель классов из статьи в виде диаграммы:
Вот эта же модель в виде таблицы (пока очень стрёмной с одним столбцом «Название», но тем не менее):
Текстовые представления у нас пока есть только в десктопном инструменте моделирования:
На скриншоте три разных представления (диаграмма, таблица, текст) одной и той же модели. Можно вносить изменения в любое из них, при этом обновятся остальные. Иными словами, содержательно это может быть какая угодно модель (модель данных, модель процессов, модель описывающая требования к ПО, организационная структура и т. д.) и визуально она может быть представлена разными способами (точно в виде диаграммы, таблицы, текста, возможно в специфических нотациях типа blockly). т. е. мы не ограничиваемся рисовалкой диаграмм. Но в веб‑моделере у нас пока для редактирования моделей есть только дерево в навигаторе, диаграммы, форма свойств, пока не очень удобные таблицы. Текстовых представлений сейчас нет, но они планируются в обозримом будущем
итого, это видимо именно структурные модели
> какая угодно модель (модель данных, модель процессов, модель описывающая требования к ПО, организационная структура и т. д.
ещё раз.
1. есть модели в виде текста — например, журналистской статьи
2. есть математические модели в виде формул y = x^2 (это НЕ просто текстовые модели, это опять излишнее необоснованное обобщение)
3. есть математические модели в виде графика (НЕ векторного)
4. есть модели в виде натурных макетов (папье маше, 1:43 и т.д.)
5. есть модели в виде 3D-4D-баз данных
и т.д.
перестаньте пожалуйста заниматься детским максимализмом «наш рынок — весь мир», «мы моделируем что угодно», «agile походит везде, и в атомной промышленности», найдите зону применимости инструмента
Согласен, ещё есть модели, которые ходят по подиуму и показывают платья. И наверное у большинства людей с этим словом возникают именно такие ассоциации. Это очень многозначное слово
Структурная модель в моём понимании описывает структурные элементы объекта и отношения часть‑целое между ними. Например, автомобиль состоит из кузова, двигателя, ... Двигатель состоит из чего‑то ещё и т. д. Если мы описываем схему работы двигателя, то в моём понимании эту будет уже не структурная модель, а модель процесса, машина состояний или ещё что‑нибудь
Зона применимости для меня лично очень простая. Например, мне понадобилось описать модель данных для приложения, сгенерить её описание, сгенерить по ней Java код, SQL‑скрипты. И если этот инструмент позволит мне потратить полчаса и больше никогда не тратить время на эту рутину, то отлично. Та же история с генерацией документации для API
Или понадобилось описать бизнес‑требования к ПО, оценить их, приоритезировать, сгенерить табличку для ТЗ
Или понадобилось описать сценарии использования системы, связать их с бизнес‑требованиями, посмотреть какие бизнес‑требования не покрыты сценариями. Втянуть задачи из трекера, связать их со сценариями, посмотреть сколько времени ушло на реализацию бизнес‑требований
Конечно я могу использовать для этого Excel или ещё кучу других приложений, но, блин, я занимаюсь инструментами моделирования (не любыми, а достаточно специфическими, но это ничего не меняет), поэтому на всё смотрю через призму моделей
Или захотелось сменить работу, машину, квартиру, ... Есть куча способов как принять оптимальное решение, но я это буду делать таким образом и для этого мне нужен удобный инструмент
Или захотелось разобраться кем были мои предки. Конечно есть куча инструментов для построения генеалогических деревьев. Но очевидно, что лично я буду строить эти деревья в инструменте моделирования
Или захотелось улучшить баланс между работой и остальной жизнью. Я могу конечно в Excel фиксировать на что трачу время, ставить себе планы типа на час меньше работать, на два часа раньше ложиться спать. А могу в инструменте моделирования с помощью Process Mining построить модель процесса AS‑IS для моего типового дня. Поправить её и получить модель TO‑DO (типа не залипать в youtube два часа перед сном, а слушать аудиокнигу и засыпать через 5 минут или в обед гулять полчаса). И потом сопоставлять эти две модели
Или мне захотелось построить план оптимальной тренировки в зале, сравнить его с планами других людей
Или мне надоело ИТ, решил заняться психологией и фигачу метамодели для разных методик типа СМЭР. Кидаю людям ссылку на табличку, где они могут фиксировать свои ситуации, мысли, эмоции, реакции. Даю людям другие аналогичные шаблоны
А потом разочаровываюсь в психологии, решаю заняться изготовлением столов из дерева, компьютерными сборками и т. д. И тоже первым делом описываю эти предметные области в виде метамоделей, делаю текстовый или графический DSL для описания сборок или для описания заказов на столы и т. д. Добавляю правила валидации для моделей, которые проверяют будет ли вообще эта сборка работать, пишу бота который на вход получает описание сборки и ищет в магазинах комплектующие, или пишу скрипт, который проверяет сборку на оптимальность, предлагает изменить в ней некоторые параметры
Я могу часами говорить о том, что моделирование — это не удел исключительно «аналитиков, архитекторов, онтологов» в крупных корпорациях, а то чем подавляющее большинство людей занимаются ежедневно на бытовом уровне не задумываясь об этом. Даже когда они планируют поездку в магазин, выбирают время, маршрут, составляют список покупок, оценивают бюджет, сравнивают варианты покупок. За всем этим стоит пусть очень простая или не очень простая модель со своей метамоделью
Конечно мы не делаем в данный момент инструмент для планирования покупок :) А начали с более прозаичных вещей — моделирование данных и архитектуры ПО
Я не специалист по сусликам, не знаю на сколько точная модель.
Из структурно-графовых моделей как минимум тут скорее бы пригодилась модель состояний, тк она именно показывает смену отношений.
Но я скорее о том, что вот у вас колония из 120 сусликов, между ними есть какие-то отношения и они как-то меняются во времени. Эти отношения можно описать триадами Суслик1, Суслик2, Характер отношения А, [Интервал действия]. Это я предложил фактически текстово-табличную модель, которой можно описать все 120 сусликов и все их отношения. Как тут помогут ваши графовые схемы, пока плохо понятно.
Помогут следующим образом:
1) Описываем метамодель:
В соответствии с метамоделью есть суслики, у сусликов есть имя и пол. Есть три типа отношений между сусликами (дружба, любовь, вражда). У отношений есть дата начала и дата окончания.
2) После этого автоматически получаем древовидный редактор этих моделей (слева), форму свойств (справа), пока стрёмный табличный редактор, дефолтный диаграммный редактор или не автоматически получаем немного улучшенный диаграммный редактор с сусликами в виде значков, а не прямоугольников (по центру):
3) В перспективе описываем грамматику для этих моделей (слева) и получаем такой текстовый DSL для их редактирования (по центру):
Справа абстрактное синтаксическое дерево для этого кода = модель. Структура этого дерева (модели) соответствует метамодели, описанной выше.
Содержательно это одна и та же модель, она не графическая, не текстовая, не табличная. Можно по‑разному её называть: концептуальная (исходя из того, что она описывает понятия и отношения между ними) или объектная (если ориентироваться на стандарт). Эта модель описывает сусликов и отношения между ними. Формы представления у этой модели могут быть разными (диаграмма, таблица, дерево, текст).
Пока у нас нет таких текстовых представлений, я описал грамматику в другой системе, но это вопрос времени. В принципе и сейчас у нас диаграммы не обязательные, можно создавать модель в навигаторе слева. Для каких-то моделей возможно и не нужны будут диаграммы, будет только текстовая нотация
Идеи классные, но не превратится ли это в ещё один перегруженный инструмент для моделирования?
Надеюсь, что нет. Хотелось бы, чтобы в нём было хорошо сделано всё что относится к моделированию:
Разные формы представления моделей (диаграммы, таблицы, деревья, текст) + возможно специфические нотации типа blockly, но для их поддержки нужно будет уже писать код
Возможность создавать свои нотации и методики моделирования
Валидация моделей
Версионирование моделей
Управление доступом к моделям
Запросы и поиск по моделям
Преобразование моделей в другие модели и в документы/код. Это могут быть и простые преобразования, и более сложные типа имитационного моделирования. Но они не усложняют сам инструмент моделирования, главное что движок в принципе поддерживает преобразования, а все сложности дописываются пользователями
Удобное API
Значительная часть из этого есть, но пока без нормального UI и описания. Самая непроработанная тема — это пока текстовые представления для моделей.
На мой взгляд, на базе этой функциональности можно будет собрать любой инструмент моделирования, добавив нужные нотации и преобразования моделей. А если понадобится что‑то более сложное типа системы исполнения процессов, BI и т. д., то можно добавить сбоку готовую стороннюю систему
Возможно я ошибаюсь, но то, что вы хотите сделать - MetaEdit+
Да, очень похоже на MetaEdit+, но
с более простым веб‑интерфейсом
с API
с возможностью легко делиться нотациями моделирования и моделями
не только с диаграммами и таблицами, но и с текстовыми нотациями
наверняка с более интересной валидацией и оценкой качества моделей
бесплатное и ориентированное на большую аудиторию
и кучей разных идей связанных с машинным обучением и других
Наверное единственная новая идея у нас — это сделать инструменты типа MetaEdit+ более доступными, удобными, массовыми
Наш инструмент моделирования