doc/Project/SemanticBPM/method/arisLDconcept.md
2025-03-08 21:18:13 +03:00

29 lines
9.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Много будет про 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", но с явной семантикой (на триплетах - атомах знания).