mirror of
https://github.com/bpmbpm/doc.git
synced 2026-04-28 11:30:42 +00:00
29 lines
9.1 KiB
Markdown
29 lines
9.1 KiB
Markdown
Много будет про ARIS, лучше вначале пролистать [ARIS-книжки](https://github.com/bpmbpm/doc/tree/main/BPM/ARIS/book)
|
||
|
||
## Базовый концепт Semantic BPM \ Semantic ARIS
|
||
Как раздел из [Концепты реализации Semantic BPM](https://github.com/bpmbpm/SemanticBPM/wiki/%D0%9A%D0%BE%D0%BD%D1%86%D0%B5%D0%BF%D1%82%D1%8B-%D1%80%D0%B5%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8-Semantic-BPM)
|
||
### Базовый концепт
|
||
Это ARIS + Linked Data как компоновка ARIS – based и RDF – based подсистем в одну систему.
|
||
Или: обычный с виду ARIS, но с RDF \ SPARQL “под капотом”. В базовом варианте использован подход «сначала схема» и пост-парсинг схемы (см. VAD-LD), в отличие от альтернативных: отрисовка схемы с одновременным формированием RDF (real-time) или авто построение (AutoVAD). Более универсальное направление ARIS Smart Design, но это отдельный большой проект [ВРМ. Смарт-инструменты «Таблица -> Схема»](https://habr.com/ru/articles/810851/)
|
||
|
||
### Базовый технологический концепт на примере VAD:
|
||
1. Отрисовка схемы процесса в VAD. Основной стартовый шаг: пользователь (участник процесса или консультант \ методолог) рисует схему процесса в какой – либо нотации (в MVP 0.1 в нотации VAD).
|
||
2. Корпоративный семантический шаблон. Схемы процессов рисуются во внешнем (MVP 0.1) редакторе с помощью корпоративного семантического шаблона, где все элементы шаблона (трафарета) имеют семантическую разметку определяет набор свойств (включая тип объекта, возможные отношения с другими объектами) элемента (фигуры). Причем даже в разных графических нотациях (BPMN, VAD), т.е. синтаксических обертках, суть (семантика) будет единой.
|
||
3. Парсер графических файлов. Допустим пользователь начал с нуля и нарисовал 10 схем в drawio, yEd и т.п. Далее модуль RDF-импорт парсит эти схемы и создает 10+1 файлов TriG, см. [wiki Repo MetaModel, TriG)](https://github.com/bpmbpm/SemanticBPM/wiki/%D0%9C%D0%B5%D1%82%D0%B0%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D0%B2#repo-metamodel-trig)
|
||
4. Сборка EKG, RDF-хранилище. TriG-файлы (один файл = одна схема процесса) загружаются в Хранилище (TriG \ RDF store \ triple store), что и представляет собой хранилище EKG предприятия в части процессов. Базовый интерфейс EKG = ARIS Publiser.
|
||
5. Отображение Treeview с деревом схем (дерево моделей) предусмотрено в левом верхнем углу основного экрана:
|
||
[главный экран приложения, mainGUI.md]( https://github.com/bpmbpm/doc/blob/main/Project/SemanticBPM/design/mainGUI.md)
|
||
6. Базовые запросы к EKG. Семантика, изначально отрисованная в графических файлов и далее переведенная на язык RDF, доступна из оболочки. RDF-Dia позволяет двунаправленный запрос:
|
||
- прямой запрос. Кнопками или прямым SPARQL запрашивать нужные элементы (схемы процессов, их элементы) и отображать их как в дереве процессов, так и в окне схем процессов, например, Отобразить схему процесса и в окне отображения схемы навести фокус на запрашиваемый элемент схемы (как результат запроса вывести карточку \ паспорт элемента);
|
||
- обратный запрос. Выбор на схеме процесса какого-либо элемента находит его в RDF-хранилище и выводит в окно карточки процесс все его свойства (или только отфильтрованные).
|
||
7. Расширенные запросы к EKG. Более глубокая аналитика подразумевает сложные запросы к RDF-хранилищу, например, с использованием [reasoner](https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%BC%D0%B0%D0%BD%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%BC%D0%B5%D1%85%D0%B0%D0%BD%D0%B8%D0%B7%D0%BC_%D1%80%D0%B0%D1%81%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B9) и т.п.
|
||
По большому счету – это инвентаризация процессов компании и их ресурсов: входы, исполнители, инструменты на семантических стандартах представления знаний. Если далее углубляться в инвентаризацию ИТ-активов, то это будет движение в сторону semantic CMDB (semantic ITIL) / RDF-based CMDB, а если еще далее в сторону семантических конфигов, то JSON-LD для конфигурирования ИТ-систем, т.е. конфигурационные конфиги отдельных ИТ-систем с семантическим слоем (но это совсем далеко).
|
||
### Базовый технологический концепт «простыми словами»
|
||
Нарисовать VAD схему (drawio, yEd) по заранее созданному Корпоративному семантическиому шаблону.
|
||
RDF-импорт парсит эти файлы и на выходе дает аналогичный набор TriG-файлов, которые загружаются в triple store. Элементы TreeView (левый верхний элемент основного GUI) оболочки RDF-Dia (базовый модуль приложения, пусть будет такое условное название) создаются на основе triple store (все элементы распределяются по дереву). В итоге мы получаем **привычный ARIS-интерфейс с семантическим движком**.
|
||
**Другими словами**: Мы закачиваем информацию из разных источников: yEd, drawio и т.п.
|
||
Закачиваем с трансляцией через свою онтологию (для начала [VAD](https://github.com/bpmbpm/SemanticBPM/blob/main/docs/VAD/README.md)) в формате trig, далее из них формируем triple store (для начала достаточно in-memory), далее любые к нему запросы (для начала SPARQL).
|
||
И все это aris-образное (ARIS-based), см. [mainGUI.md](https://github.com/bpmbpm/doc/blob/main/Project/SemanticBPM/design/mainGUI.md) \ [ARIS Publisher](http://www.bpm.processoffice.ru/).
|
||
### Корпоративный семантический шаблон
|
||
Фрагмент трафарета Visio показан на рис. 3 [Repo MetaModel, TriG](https://github.com/bpmbpm/SemanticBPM/wiki/%D0%9C%D0%B5%D1%82%D0%B0%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D0%B2)
|
||
В шаблоне "зашита" семантика, которую RDF-парсер к конкретному формату (visio, drawio, yEd и т.п.) преобразует в RDF. Справедливо и обратное, это уже [AutoVAD from rdf](https://github.com/bpmbpm/SemanticBPM?tab=readme-ov-file#autovad-from-rdf). Таким образом, реализуется двухстроняя связь "код - схема", т.е. в простейшем варианте ARIS SmartDesign см. [ВРМ. Смарт-инструменты «Таблица -> Схема»](https://habr.com/ru/articles/810851/), а в более общем (и сложном) [Architecture as Code](https://habr.com/ru/companies/otus/articles/885594/). Однако язык Architecture as Code должен быть не PlantUML / DOT / Mermaid, и т.п., а RDF (TriG) или "архитектурный DSL", но с явной семантикой (на триплетах - атомах знания).
|