Возможности СиММА в области графического представления (диаграммы)

Следует различать схемы и диаграммы, хотя сама терминология в этой области не совсем строгая. Большинство определений сводится к следующему различию:

• схемой называют то, что изображает структуру, а именно совокупность каких-то компонентов и их связей
• диаграммой называют то, что изображает соотношение каких-то величин, показателей, развитие значений какого-то параметра во времени. Системы, имеющие в качестве своего основного функционала построение диаграмм (пирожковых, секторных, пузырьковых, столбчатых) обычно относят к классу дашбордов (инфопанелей). Кроме возможностей визуализации данных они также позволяют хранить данные в структурах, содействующих этой визуализации, а также могут поддерживать различные вычислительные алгоритмы для апроксимации, интерполяции, суммирования, агрегации и т.п..

Базовые возможности графики в СиММА по созданию схем смотри здесь >>>

 

СиММА не относится к программным продуктам, нацеленным на диаграммирование и, если такая задача стоит перед Заказчиком, то стоит подключать СиММА к инфопанелям через API СиММА. Еще более продуктивным подходом будет периодическая перегрузка данных СиММА в BI-хранилище, откуда архитектурные или процессные данные можно анализировать в различных разрезах и техниках диаграммирования.

Тем не менее ряд возможностей можно реализовать и в графике СиММА. Например, вот такую тепловую карту. Для построения этой карты использовались как базовые графические возможности СиММА, так и возможность запустить в СиММА (по требованию) расчет каких-то показателей.

Замечание относительно терминологии на тему "диаграммы - схемы"

Ряд схем устойчиво называют диаграммами, например, диаграмма классов, ERD-диаграмма, диаграмма BPMN. Причина такого положения заключается в том, что схемы сущностей, классов или процессов следуют весьма строгим формализмам. Например:

• диаграмма BPMN изначально была задумана, как визуализация процесса, запрограммированного на языке BPEL, то есть она создается автоматически по данным программного кода BPM-движка. Схема/диаграмма BPMN - это строгий граф типа "конечный автомат".
• ERD-диаграмма строится автоматически на основании данных о таблицах и ключах в РСУБД.

Еще пара примеров:

• в инструменте Plant UML можно построить диаграмму на основании текстового описания.
• в ряде инструментов диаграммы типа С4 зачастую автоматически визуализируются на основании тщательно и строго структурированного текста.

В последних двух примерах построение диаграмм делается не просто на базе простых текстов - это тексты, созданные согласно синтаксису, традиционно используемому в языках программирования.  То есть мы называем такие схемы диаграммами лишь потому, что они визуализуют какие-то данные (структуры данных, описанные в виде очень формальных текстов) автоматически, ровно так, как это происходит при создании дашбордов. 

То есть главным основанием, на основании которого мы называем схему диаграммой, служит строгость тех правил, по которым она создана. Истинные BPMN и ERD диаграммы создаются согласно строгих формализмов теории графов, то есть каждый узел или дуга на схеме находятся строго в определенных местах, дуги соединяют только те узлы, для соединения которых они предназначены. Для таких диаграмм возможно запрограммировать контроль соблюдения формализмов, заложенных в нотацию (а точнее в метамодель нотации), что как правило и делают производители инструментов для моделирования.

Таким образом схемами обычно называют такие графические композиции, где состав элементов схемы и связей не строгий, соблюдение формализмов приветствуется, но не является обязательным. Практически все схемы на своем начальном этапе создания являются именно схемами, так как возникают они в ходе размышления-проектирования, требующего свободы. Превращение схемы в строгую диаграмму может быть востребовано лишь в том случае, если она поступает в автоматизацию, например, когда по ERD-диаграмме создают физическую модель данных. Или когда по BPMN-диаграмме создают алгоритм процесса в BPM-движке. Многие схемы бизнес-процессов являются именно схемами, так как они предназначены для людей, которые либо не знакомы с формализмами нотаций, либо способны додумывать/интерпретировать схему. Очень часто схемы бизнес-процессов являются ментальными картами, имеющими целью зафиксировать идею процесса (сущность процессности) в виде его поточной структуры. Так, например, 90% BPMN-диаграмм являются схематическими картинками, ибо никто не собирается отгружать их в BPM-движок. Назначание таких картинок - коммуникация бизнес-заказчиков с аналитиками. Именно по этой причине у BPMN есть аналитическое подмножество нотации - специально для задач простой и оперативной схематизации.

Планы по развитию СиММА в области диаграммирования

В 2026 году мы планируем развивать СиММА и реализовать ряд диаграмм графового характера. Такие диаграммы будут строиться автоматически по данным СиММА. Для отдельных наших клиентов реализация таких диаграмм возможна в рамках внедрения. Пример автоматически построенной диаграммы инфопотоков (диаграмма интеграций) см. ниже. Двухстрочные прямоугольники обозначают "системы", а четырехстрочные - интеграционные взаимодействия.

На диаграмму можно вывести параметры систем (число лицензий, вендор, аналитик) и параметры взаимодействий-интеграций (протокол, порты, передаваемые параметры и так далее). Возможна окраска прямоугольников в зависимости от статуса объектов, которые они отображают.

Еще один пример - пример динамической визуализации доменов данных и собственно объектов данных, иерархически организованных в модели СиММА:

Диаграмма, схема или модель?

В российской практике моделирования прижилось еще одно название для схем/диграмм - это модель. Например, в таких продуктах как Business Studio или Slia Union, схемы/диаграммы называют моделями. Не известно точно, откуда это повелось, возможно методология ARIS является источником происхождения такого рода именования. 

Конечно, это путает традиционный подход метамодель → модель → схема. Но если подвести под российский аналитический дискурс какое-то обоснование, то вероятно схемы называют моделями по той причине, что за ними стоит большое количество hardcode-логики: модели создаются по жестким наборам правил, зашитым в программном продукте, что делает их, как минимум, строгими диаграммами. Минус такого подхода - ограничение свободы аналитика, навязывание ему "модельной" дисциплины (жесткой методологии). Плюс такого подхода - по строго формализованным хардкодным диаграммам можно создавать регламенты и положения в виде зашитых в системы отчетов.