ПНСТ 1044-2025. Предварительный национальный стандарт Российской Федерации. Системы киберфизические. Национальная киберфизическая платформа. Часть 4. Программирование расширенных иерархических машин состояний. Формат документа описания диаграмм машин состояний

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

6.7.1 Требования к структуре описания связи

Базовые требования к структуре описания дуги представлены в 5.8.

Ключ dPivot:

• первый и обязательный дочерний тег узла edge для связи комментария и предмета комментирования;
• значения: текстовая строка, принимающая одно из трех значений:
• dName, если предметом комментария является фрагмент имени комментируемого элемента, значение фрагмента указывается в ключе dChunk (см. далее);
• dData, если предметом комментирования является фрагмент тела комментируемого элемента, значение фрагмента указывается в ключе dChunk (см. далее);
• пустое значение, если комментарий относится ко всему элементу.

Ключ dChunk:

• допустимый дочерний тег дуги, который используется в случае комментирования фрагмента элемента. Указывается обязательно, если ключ dPivot имеет значения dName или dData;
• значение: Конкретный фрагмент текста из комментируемого элемента. При этом значение ключа не может быть пустой строкой.

Прочие допустимые ключи:

• описание параметров геометрии дуг машины состояний (см. 9.1);
• дополнительные описания дуги связи комментария и предмета комментирования, представленные в разделе 9.

6.7.2 Требования к использованию связи

В графе машины состояний может быть описано любое число дуг edge, связывающих комментарии и предметы комментирования. Дуги связей описываются как часть графов машин состояний.

Дуга связи может иметь в качестве исходного узла только элемент типа комментарий, принадлежащий той же машине состояний. Целевым узлом в базовой реализации стандарта может быть любая вершина (в том числе и другой комментарий) диаграммы ПРИМС, представленная узлом в том же графе машины состояний. В расширенной реализации стандарта дуга может также вести к другой дуге, представляющей переход в той же диаграмме ПРИМС (см. 8.5).

Данный формат не позволяет описать связь между комментарием и предметом комментирования, представляющим собой тот же самый узел комментария. Другими словами, дуги связей в виде петель в графе не поддерживаются форматом CGML.

Дуга связи может быть отображена и иметь геометрию, только если исходная и целевая вершины, представленные узлами в графе машины состояний, имеют геометрию.

6.8 События, ограждающие условия и поведение

Элементы состояний и переходов в диаграммах ПРИМС содержат описание событий, ограждающих условий и поведения. Для этого используется ключ dData, принадлежащий к соответствующему узлу или дуге графа машины состояний. Значением ключа является текстовая строка, содержащая описание внутреннего поведения, состояний, ограждающих условий и поведения для переходов всех типов, соответствующего требованиям стандарта ПРИМС (см. ПНСТ 984-2024).

Для состояний, содержащих более одного описания внутреннего поведения или внутреннего события, используются разделители в виде двойного переноса строки или пустой строки (обозначенные в примерах далее символом ):

Событие1 [Условие1]/ Поведение_1_1 Поведение_1_2 Событие2 [Условие2]/ Поведение_2_1 Поведение_2_2

Пример описания внутреннего поведения и внутреннего события в состоянии:

entry/ Сенсор.ПоискЦелиПоДистанции(мин) Сенсор.ЦельПолучена/ МодульДвижения.ЗадатьКоординатуВверх(34) exit/ Сенсор.ОстановкаПоиска

Пример описания события и ограждающего условия для перехода:

Сенсор.ЦельПолучена [Счетчик.ТекущееЗначениеСчетчика >= 2]

Пример описания события с использованием экранирования специальных символов:

TIMER [pressure > 100 && temperature < 50]/ turn_off();

6.8.1 Требования к структуре описания

Ключ dData:

• содержит текстовое описание внутреннего поведения, событий, ограждающих условий и поведения переходов. Текстовая строка может быть пустой, в этом случае не задавать никакого поведения;
• отдельные блоки в содержании ключа отделяются двойным переносом строки ( ). Количество блоков в содержании ключа не ограничено;
• в содержании ключа dData, как и во всем документе, требуется экранирование служебных символов XML, таких как угловые скобки (<, >) или амперсанд (&) (см. 5.2);
• описание внутреннего поведения начинается с ключевых слов entry/, exit/ и do/, соответствующих поведению входа, выхода и исполнения;
• описание событий начинается с имени события, которое должно быть строкой, соответствующей синтаксису языка целевой платформы;
• описание событий может содержать параметры обработки событий из стандарта ПРИМС (ПНСТ 984), задаваемые ключевыми словами propagate, block или defer;
• блок описания ограждающего условия может содержать ключевое слово else.

При описании ограждающих условий необходимо экранировать как символы отношений (<, > или &) в соответствии с требованиями, описанными в 5.2, так и символы прямых скобок ([ и ]), если они используются в логическом выражении с помощью символа обратной косой черты (), например так:

[Строка.Содержит([Пример])].

6.8.2 Требования к использованию

Узлы и дуги могут содержать не более одного ключа dData. При необходимости описания в состоянии нескольких блоков внутреннего поведения или внутренних событий используется один ключ dData, в значении которого отдельные блоки поведения или события отделяются двойным переносом строки.

6.9 Метаданные документа

Правильный документ CGML должен содержать в первом из описанных графов машин состояний узел формального комментария с именем CGML_META, который содержит метаданные документа. Параметры метаданных документа представляют собой пары строк имен и значений, разделенных пустой строкой. Набор параметров включает в себя обязательные параметры, может включать в себя однозначно интерпретируемые рекомендуемые параметры, а также любое число дополнительно введенных параметров.

Состав обязательных и рекомендуемых параметров метаданных документа включает следующие параметры:

• standardVersion — версия стандарта ПРИМС (см. ПНСТ 984-2024), имеющая значение 1.0 (обязательный параметр);
• geometry — тип геометрии документа (см. подробнее в разделе 7), принимающий одно из следующих значений:

- none — отсутствие геометрии (по умолчанию);

- short — базовый формат описания геометрии;

- full — расширенный формат описания геометрии;

• platform — идентификатор целевой платформы;
• platformVersion — версия целевой платформы;
• platformLanguage — язык целевой платформы;
• target — название целевой управляемой системы;
• name — имя документа;
• author — имя автора документа;
• contact — контактные данные автора документа (почта, ссылка на соцсети или другая контактная информация);
• description — описание документа;
• version — версия документа;
• createdAt — дата и время создания документа в формате ISO 8601, в формате всемирного координированного времени (UTC);
• transitionOrder — принятый по умолчанию для диаграмм в документе порядок выполнения действий (в соответствии со стандартом ПРИМС (ПНСТ 984)), принимает одно из следующих значений:
• actionFirst — сначала поведение в переходе (используется при отсутствии параметра);
• exitFirst — сначала поведение при выходе из состояния;
• eventPropagation — принятый по умолчанию для диаграмм в документе порядок обработки передаваемых событий (в соответствии со стандартом ПРИМС (ПНСТ 984)), принимает одно из следующих значений:
• block — прерывать на первом же обработчике (используется при отсутствии параметра);
• propagate — передавать дальше;
• markupLanguage — язык разметки неформальных комментариев по умолчанию, используемый в расширенной версии формата (см. подробнее в 9.3.2).

Пример описания метаданных документа:

formal CGML_META platform/BearsTowerDefence standardVersion/1.0 geometry/short name/Важный документ author/Матросов В.М. contact/v.m.matrosov@mail.ru description/Пример описания документа, который может быть многострочным, потому что так удобнее target/Autoborder

6.9.1 Требования к структуре описания метаданных документа

Базовые требования к узлу, описывающему формальный комментарий, определены в 6.6.

Ключ dNote:

• обязателен для любого узла формального комментария;
• значение: formal.

Ключ dName:

• узел с метаданными документами должен иметь имя со стандартным названием;
• значение: CGML_META.

Ключ dData:

• содержит текст, содержащий список параметров метаданных документа, соответствующий следующим требованиям:
• каждый параметр задается строкой вида: имя/значение. Имя и значение параметра разделяются символом косой черты (/);
• имя параметра может включать только латинские символы a — z или A — Z. Рекомендуется начинать имена новых параметров с маленькой буквы и использовать для названий стиль «camel case», например, так: newParameter;
• пробелы и табуляции перед и после символа косой черты (/) игнорируются и не являются частью значения параметра;
• возможны многострочные значения параметров;
• параметры отделяются друг от друга двумя символами переноса строки (пустая строка).

6.9.2 Требования к использованию метаданных документа

Узел формального комментария с метаданными обязан быть единственным в документе и размещаться на верхнем уровне первой машины состояний документа.

Узел формального комментария с метаданными документа не должен иметь предметов комментирования или быть предметом комментирования.

Минимально необходимый узел с метаданными документа содержит единственный параметр с именем standardVersion и значением 1.0.

Список параметров может расширяться в зависимости от потребности целевой платформы исполнения.

7 Описание геометрии в документе

В рамках формата CGML предполагается описание геометрии для определения визуальных положения и размеров элементов диаграммы ПРИМС при отображении и редактировании документа [3]. Геометрия элементов диаграммы не влияет на ее исполнение на целевой платформе.

7.1 Типы геометрии в документе

Документ CGML может иметь один из трех вариантов описания геометрии, который указывается в метаданных документа (см. 6.9).

1. Формат без геометрии (например, для случая машиночитаемых описаний машин состояний). В этом случае документ содержит только логические связи (топологию) элементов диаграммы.

2. Базовый формат геометрии — сокращенный вариант описания геометрии, представленный в 7.2, который содержит только описание координат графа машины состояний, его узлов и подграфов, а также меток на переходах.

3. Расширенный вариант геометрии, который включает в себя сокращенный формат описания геометрии и предполагает указание дополнительных геометрических параметров не только для узлов графа, но и для дуг (см. 9.1).

По умолчанию, если в метаданных документа не указано иное, документ CGML имеет формат без геометрии. В случае использования формата без геометрии или базового формата геометрии визуализация диаграммы ПРИМС подразумевает восстановление недостающих параметров геометрии элементов при их отображении в соответствии с содержимым элементов.

При визуализации расширенного варианта геометрии предполагается, что параметров геометрии элементов диаграммы ПРИМС, описанных в документе, достаточно для однозначного представления диаграммы.

7.2 Базовый формат геометрии в документе

Базовый формат геометрии предполагает минимальное описание геометрии, необходимое для визуального восстановления диаграммы ПРИМС. В таблице 4 указано, геометрия каких элементов описывается в базовом формате.

Таблица 4

Описание геометрии элементов диаграммы в базовом формате

Ключ геометрии dGeometry используется для определения геометрии элемента диаграммы ПРИМС. Отсутствие ключа dGeometry у элемента диаграммы означает, что данный элемент не должен быть визуализирован. Если составное состояние не отображается, также не отображаются и его дочерние элементы.

Ключ геометрии прописывается через вложенные теги point и rect, аналогичные по формату используемым в SVG для обозначения соответственно точки и прямоугольника. Примеры описания ключа dGeometry:

...

7.2.1 Требования к структуре описания геометрии

Ключ dGeometry:

• в базовом формате геометрии обязателен для любого узла графа машин состояний, который должен быть визуализирован;
• значение:
• тег point для точечных объектов, содержащий атрибуты x и y с координатами центра элемента;
• тег rect для прямоугольных объектов, содержащий атрибуты x и y с координатами левого верхнего угла элемента и параметры width и height, которые используются для определения размеров элемента;
• все координаты задаются на графической плоскости, в которой ось y направлена сверху вниз, а ось x слева направо. Величины координат указываются в вещественных числах;
• величины координат считаются относительно левого верхнего угла элемента, родительского для того, где прописана геометрия. Такими родительскими элементами могут быть:
• машина состояний;
• составное состояние (для областей);
• область;
• координаты элементов машин состояний задаются относительно глобальных координат всего документа (диаграммы).

Ключ dLabelGeometry:

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

7.2.2 Требования к использованию геометрии:

В базовом формате геометрии необходимо для всех отображаемых узлов указывать тег dGeometry со значением координат левого верхнего угла прямоугольных элементов и центров точечных элементов.

В базовом формате геометрии ширина и высота прямоугольных элементов с тегом dGeometry может задаваться нестрого и интерпретироваться редактором в зависимости от содержания элементов.

Все элементы графа машин состояний и принадлежащие им узлы с заданным тегом dGeometry визуализируются. Дуги, принадлежащие графам машин состояний визуализируются, если визуализированы исходный и целевой элементы. Метки дуг визуализируются, если они заданы, и если отображается сама дуга. Геометрия для меток таких дуг должна быть описана тегом dLabelGeometry (точка центра метки или прямоугольника метки).

8 Расширения формата в части полноты реализации стандарта ПРИМС

Помимо базовой версии реализации формата CGML формат предполагает ряд расширений, направленных на более полную реализацию стандарта ПРИМС (см. ПНСТ 984-2024).

В таблице 5 представлено соответствие между элементами диаграмм ПРИМС и элементами расширения формата CGML-документа (тегами, атрибутами и т.п.), описывающего диаграмму. В настоящем разделе рассматриваются требования к описанию данных элементов в расширенном формате документа CGML.

8.1 Состояние с вложенной машиной состояний

Стандарт ПРИМС (см. ПНСТ 984-2024) дает возможность встраивать описанные машины состояний в качестве отдельных элементов диаграммы. Для этого используется особый тип элемента — состояние с вложенной машиной состояний. Расширение формата CGML предполагает использование узла с ключом dSubmachineState, который соответствует состоянию с вложенной машиной состояний, значение этого ключа задает ссылку на машину состояний внутри документа или вовне.

Пример состояния с вложенной машиной состояний, которая описана во внешнем документе:

file://../VacuumCleanAndFlush.graphml

Пример состояния с вложенной машиной состояний, описанной в том же документе:

Vacuum Charge ... Vacuum Charge

Узел состояния с вложенной машиной состояний может по аналогии с составным состоянием иметь дочерние узлы, объединенные подграфом. Дочерними узлами состояния с вложенной машиной состояний могут быть исключительно точки входа и выхода, описанные подробно в 8.3.

Пример состояния с вложенной машиной состояний, содержащей узлы точек входа и выхода:

Cash Machine entryPoint Вход exitPoint Выход

8.1.1 Требования к структуре описания состояния с вложенной машиной состояний

Базовые требования к структуре описания узла представлены в 5.7.

Ключ dSubmachineState:

• первый и обязательный дочерний тег для тега node состояния с вложенной машиной состояний;
• значение: строка, содержащая идентификатор вложенной машины состояний. Возможны два варианта обозначения идентификатора машины состояний: - id машины состояний — для внутренней машины состояний, описанной в том же документе; — строка пути к описанию машины состояний в формате URI — для внешней машины состояний.

Прочие допустимые ключи:

• ключ dName, используемый аналогично элементу состояний (см. 6.2);
• описание параметров геометрии элементов машины состояний (см. 7);
• дополнительные описания элементов псевдосостояний и конечных состояний представлены в разделах 9 и 10.

Подграф (graph):

• размещается внутри узла состояния с вложенной машиной состояний и обязателен исключительно для описания вложенных дочерних узлов точек входа и выхода — через использование соответствующих вложенных тегов node;

- в качестве идентификатора подграфа рекомендуется использовать идентификатор родительского узла с добавлением разделителя: (например, n_SM:);

• тег graph подграфа состояния с вложенной машиной состояний не может содержать никаких ключей.

8.1.2 Требования к использованию состояния с вложенной машиной состояний

В диаграмме может быть описано любое число состояний с вложенной машиной состояний. Узлы таких состояний описываются как часть графов и подграфов.

Состояния с вложенной машиной состояний не могут содержать блоки внутреннего поведения или внутренних событий.

Применение состояний с вложенной машиной состояний предполагает использование точек входа и выхода, описанных в 8.3. В этом случае узлы точек входа и выхода обозначаются как дочерние узлы подграфа состояния с вложенной машиной состояний.

8.2 Псевдосостояния истории

Стандарт ПРИМС (см. ПНСТ 984-2024) вводит псевдосостояния локальной и глубокой истории. Расширение формата CGML позволяет описывать узлы (node) псевдосостояний локальной и глубокой истории. Для используется ключ dVertex со следующими значениями:

• для локальной истории: shallowHistory;
• для глубокой истории: deepHistory.

Пример тега псевдосостояния локальной истории:

shallowHistory

8.2.1 Требования к структуре описания состояний истории

Базовые требования к структуре описания псевдосостояний в 6.4.

ключ dVertex:

• принимает значение shallowHistory для локальной истории или deepHistory для глубокой истории.

Прочие допустимые ключи:

• ключ dName, используемый аналогично элементу состояний (см. 6.2);
• описание параметров геометрии элементов машины состояний (см. раздел 7);
• дополнительные описания элементов псевдосостояний и конечных состояний представлены в разделах 9 и 10.

8.2.2 Требования к использованию состояний истории

Число псевдосостояний локальной и глубокой истории в графе машины состояний ограничено только требованиями стандарта ПРИМС (см. ПНСТ 984-2024) к использованию данных элементов.

8.3 Псевдосостояния точек входа и выхода

Стандарт ПРИМС (см. ПНСТ 984-2024) вводит псевдосостояния точек входа и выхода, которые позволяют описывать отдельные варианты начала работы и завершения работы состояния или машины состояний, а также используются совместно с состояниями с вложенной машиной состояний. Расширение формата CGML позволяет описывать узлы псевдосостояний точек входа и выхода. Для используется ключ dVertex со следующими значениями:

• для точки входа: entryPoint;
• для точки выхода: exitPoint.

Пример использования точки выхода в рамках машины состояний:

... exitPoint Отмена ...

Пример использования точек входа и выхода в рамках состояния с вложенной машиной состояний:

Cash Machine entryPoint Вход exitPoint Выход

8.3.1 Требования к структуре описания точек входа и выхода

Базовые требования к структуре описания псевдосостояний определены в 6.4.

Ключ dVertex:

• должен быть первым ключом тега node;
• значения: текстовая строка, равная entrypoint для точки входа или exitpoint для точки выхода.

Прочие допустимые ключи:

• ключ dName, используемый аналогично элементу состояний (см. 6.2);
• описание параметров геометрии элементов машины состояний (см. раздел 7);
• дополнительные описания элементов псевдосостояний и конечных состояний представлены в разделах 9 и 10.

8.3.2 Требования к использованию точек входа и выхода

Число псевдосостояний точек входа и точек выхода в графе машины состояний ограничено только требованиями стандарта ПРИМС (см. ПНСТ 984-2024) к использованию данных элементов.

Узлы точек входа и выхода могут быть дочерними по отношению к графам машин состояний, узлам составных состояний и узлам состояний с вложенными машинами состояний.

Геометрия точек входа и точек выхода должна предусматривать их расположения внутри родительского элемента или на его границе.

8.4 Составные состояния со скрытым блоком декомпозиции

Стандарт ПРИМС (см. ПНСТ 984-2024) предполагает возможность скрывать содержимое блока декомпозиции составного состояния (см. рисунок 2). Расширение формата CGML позволяет описывать состояния, блок декомпозиции которых является скрытым и в таком виде должен отображаться при визуализации диаграммы. Для этого используется ключ dCollapsed узла node составного состояния.

Рисунок 2 — Состояние со скрытым блоком декомпозиции

Составное состояние ...

8.4.1 Требования к структуре описания состояния со скрытым блоком декомпозиции

Ключ dCollapsed:

• включается в тег node, если блок декомпозиции должен быть скрыт. Если данный тег отсутствует, блок декомпозиции должен быть отображен при визуализации диаграммы;
• значения: пустая строка.

8.4.2 Требования к использованию состояния со скрытым блоком декомпозиции

Блок декомпозиции предполагается и может быть скрыт только для составных состояний.

Если используется ключ dCollapsed, блок декомпозиции скрывает все свое содержимое (включая дочерние элементы и переходы между ними). При этом для всех переходов, целью или источником которых являются дочерние элементы, в качестве цели или источника перехода в диаграмме при визуализации отображается данное состояние.

Символ скрытого блока декомпозиции отображается в соответствии с требованиями стандарта ПРИМС (см. ПНСТ 984-2024).

8.5 Расширенный вариант описания связи элементов «Комментарий» с предметами комментирования

Связь комментария с другими элементами в диаграмме ПРИМС описывается через дугу, ведущую от узла комментария к предмету комментирования. В 6.7 описывается базовая версия стандарта, предполагающая связь между двумя узлами графа машины состояний, тогда как в расширенной реализации можно описать связь между комментарием и предметом комментария — переходом.

В этом случае при описании дуги в атрибуте target тега edge указывается идентификатор дуги, который, в свою очередь, является предметом комментирования. Пример расширенного описания комментирования перехода как предмета комментирования:

informal Так надо!

8.5.1 Требования к структуре описания связи

Требования к структуре описания связи определены в 6.7.1.

8.5.2 Требования к использованию связи

Базовые требования к использованию связи определены в 6.7.2.

В расширенной реализации стандарта дуга может также вести к другой дуге, представляющей переход в той же диаграмме ПРИМС.

9 Расширения формата в части отображения элементов диаграммы ПРИМС

Формат CGML предлагает набор дополнительных возможностей, направленных на расширенное представление диаграммы и ее содержимого при визуализации.

9.1 Расширенный формат описания геометрии в документе

Расширенный вариант геометрии, который наследует базовый формат описания геометрии, предполагает указание дополнительных геометрических параметров с целью однозначного описания геометрии всех элементов документа ПРИМС. В расширенном варианте геометрии предполагается точное соответствие геометрии всех отображаемых объектов значениям координат и размеров.

В таблице 6 указано, геометрия каких элементов описывается в расширенном варианте геометрии.

Таблица 6

Описание геометрии элементов диаграммы в расширенном формате

Описанные в таблице ключи геометрии используются для определения геометрии элемента диаграммы ПРИМС. При описании геометрии ребер для привязки ребра к конкретным местам исходного и целевого состояния, комментария или псевдосостояния выбора должны использоваться ключи dSourcePoint и dTargetPoint, в которых аналогично тегу dGeometry через тег point указывается координата относительно левого верхнего угла соответствующего узла. Описание ломаной линии (polyline) производится через набор точек внутри тега dGeometry.

Отсутствие ключа dGeometry у узлов диаграммы означает, что данный элемент не должен быть визуализирован. Если составное состояние не отображается, также не отображаются и его дочерние элементы.

Примеры описания расширенной геометрии:

Пример описания ломаной линии (polyline) в расширенной геометрии:

9.1.1 Требования к структуре описания геометрии

Требования к структуре описания геометрии в расширенном формате наследуют требования базового формата (см. 7.2.1).

Ключ dGeometry:

• в расширенном формате описания геометрии ключ обязателен для любого узла графа машин состояний, который может быть визуализирован. В дугах графа машин состояний используется только для описания ломаных линий с хотя бы одной промежуточной точкой;
• значение: - для описания геометрии узлов аналогично базовому формату геометрии (см. раздел 7), с дополнительным требованием точного соответствия размеров прямоугольников (ширина и высота) в документе их предполагаемой визуализации; - для описания ломаной линии — непустой набор тегов point для описания промежуточных точек ломаной линии.

Ключ dSourcePoint:

• для каждой дуги должна быть задана исходная точка привязки на границе исходного узла перехода или комментария, для которого задается предмет комментирования;
• значение: - тег point, содержащий атрибуты x и y с координатами точки привязки. Координаты задаются относительно верхнего левого угла исходного узла.

Ключ dTargetPoint:

• применяется по-разному в зависимости от типа дуги: - в случае дуги перехода — должна быть задана целевая точка привязки на границе целевого узла, координаты задаются относительно верхнего левого угла целевого узла; - в случае дуги связи комментария с предметом комментирования -

элементом,  представленным  узлом,  -  должна  быть  задана  целевая  точка
привязки   на   границе  целевого узла,  координаты  задаются  относительно

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

• значение: если используется, тег point, содержащий атрибуты x и y с координатами точки привязки.

Ключ dLabelGeometry:

• в расширенной версии формата геометрии повторяет требования, описанные в 7.2.1.

9.1.2 Требования к использованию геометрии

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

Для всех дуг должна указываться исходная точка привязки dSourcePoint. Целевая точка привязки dTargetPoint указывается для всех дуг кроме связей между комментариями и предметами комментирования — фрагментами элементов.

Все элементы графы машин состояний и принадлежащие им узлы с заданным тегом dGeometry визуализируются. Дуги, принадлежащие графам машин состояний визуализируются, если визуализированы исходный и целевой элементы. Метки дуг визуализируются, если они заданы и если отображается сама дуга. Геометрия для меток таких дуг должна быть описана тегом dLabelGeometry (точка центра метки или прямоугольник).

9.2 Цветовая маркировка дуг и узлов

Расширение формата CGML позволяет выделять элементы диаграммы по смыслу, задавая для узлов и дуг графа машины состояний цвета, отличные от черного цвета диаграммы по умолчанию.

Для указания цвета соответствующего элемента диаграммы (прямоугольной обводки или наполнения точки узла, цвета линии дуги) может использоваться ключ dColor, указываемый в соответствующем теге узла или дуги. Цвет обозначается в формате строки, стандартной для CSS или SVG. Пример задания красного цвета для элемента диаграммы:

#ff0000 red

9.2.1 Требования к структуре описания цветовой маркировки

Ключ dColor:

• может быть задан для тега node или тега edge;
• значение: непустая строка с префиксом # и шести- или восьмизначным шестнадцатеричным кодом цвета, кодирующим соответственно трехбайтное значение цвета RGB или четырехбайтное значение цвета RGBA, включающий байт альфа-канала. Также рекомендуется поддержка альтернативного обозначения цвета в виде наименования из стандартов CSS и HTML, например red, green и т.д.

9.2.2 Требования к использованию цветовой маркировки

Цветовая маркировка может быть задана для узлов (состояния, псевдосостояния, комментарии) и дуг графа машин состояний (переходы и связи комментариев с предметами комментирования). Цветовая маркировка не задается для элементов машин состояний и областей.

Цветовая маркировка, как и текстовые комментарии в документе CGML, не имеет семантической нагрузки при исполнении машины состояний, а служит цели смыслового выделения фрагментов диаграммы при ее визуализации.

9.3 Форматирование комментариев

Расширение формата CGML позволяет форматировать человекочитаемые (неформальные) комментарии для удобства их визуализации. Для форматирования содержания человекочитаемых комментариев используется ключ dMarkup, применяемый в теге узла комментария и определяющий язык разметки. Пример задания формата комментария:

informal markdown И как мы опишем вот это?

Пример текста комментария в формате Markdown:

Жирный текст, курсив, ссылка.

9.3.1 Поддерживаемые языки разметки

Возможные значения ключа dMarkup соответствуют поддерживаемым языкам разметки. По умолчанию используется значение plain, которое соответствует отсутствию разметки. При использовании распространенного синтаксиса разметки Markdown необходимо использовать значение ключа markdown. Разработчики редакторов диаграмм ПРИМС могут вводить собственные значения ключа, соответствующие другим типам разметки (например, HTML или вики-разметки).

9.3.2 Параметр метаданных документа markupLanguage

В метаданных документа (см. 6.9) может быть установлен язык разметки по умолчанию для всех неформальных комментариев в документе. Это позволяет не прописывать формат разметки, отличный от plain, в каждом узле неформального комментария. Пример параметра установки языка разметки в блоке метаданных документа (в теле комментария CGML_META):

markupLanguage/markdown

9.3.3 Требования к структуре описания языка разметки

Ключ dMarkup:

• применяется только в узлах неформальных комментариев (наличие ключа dNote со значением informal);
• значение: непустая строка. При отсутствии ключа dMarkup используется значение по умолчанию plain.

9.3.4 Требования к использованию описания языка разметки

Язык разметки неформальных комментариев может быть задан для всего документа в параметре markupLanguage метаданных документа. Иначе по умолчанию принимается формат plain, означающий отсутствие языка разметки.

Для каждого неформального комментария может быть задан явно язык разметки, отличный от языка по умолчанию.

Если язык разметки поддерживается редактором ПРИМС, он интерпретируется при визуализации соответствующих комментариев диаграммы.

10 Расширения формата в части поддержки особенностей целевых платформ исполнения диаграмм ПРИМС

Стандарт ПРИМС (см. ПНСТ 984-2024) предполагает поддержку различных платформ исполнения, прежде всего тех платформ, которые предполагают программное исполнение поведения, описанного в элементах диаграммы. Диаграмма машины состояний может также транслироваться в код на языке программирования (таком как C++ или Python), например, для работы во встраиваемой системе. В связи с этим может быть полезным ряд расширений формата, направленных на поддержку специфики различных платформ исполнения и процесса трансляции программ. Это может быть сделано в опоре на специальные теги или машиночитаемые (формальные) комментарии в диаграмме.

10.1 Машиночитаемые имена элементов диаграммы

В связи с тем, что имена состояний и псевдосостояний в диаграмме ПРИМС могут содержать любые символы в кодировке UTF-8, трансляция имен состояний в код языков программирования, таких как C, затруднена. В этой ситуации можно воспользоваться расширением стандарта и задать для элемента диаграммы его формальное имя с помощью специального ключа dFormalName. Это имя должно использоваться соответствующими платформами исполнения и трансляторами эквивалентно имени элемента. Редакторы и другие инструменты визуализации диаграмм могут использовать какой-либо способ отображения формального имени элемента в дополнение к его имени.

Пример описания формального имени для состояния:

Поиск Scan entry/ scan_start(); exit/ scan_stop ();

10.1.1 Требования к структуре описания языка формального имени

Ключ dFormalName:

- допустимый дочерний тег для тегов graph и node. Может быть задано вне зависимости от наличия имени элемента;

- значение: формальное имя машины состояний не может быть пустым, должно начинаться с букв латинского алфавита (a — z или A — Z) или знака подчеркивания (_), за которыми следует любое количество букв латинского алфавита, знаков подчеркивания или цифр.

10.1.2 Требования к использованию описания формального имени

Формальное имя может быть задано любому элементу, для которого может быть задано имя (ключ dName). При этом формальное имя может быть задано элементу вне зависимости от наличия имени элемента.

На использование формальных имен распространяются те же требования, что на использование имен элементов диаграммы (см. 6.1.1 и 6.1.2).

10.2 Использование формальных комментариев для инициализации программ

Распространенной практикой использования диаграмм ПРИМС является трансляция диаграммы в исполняемый код на языке программирования высокого уровня (например, C++ или Python). В этом случае для технической реализации транслятора или работы интерпретатора может понадобиться специальная инициализация переменных или структур, используемых при работе диаграммы. Для этого используются формальные комментарии, требования к описанию и использованию которых даны в 6.6.

Содержание формальных комментариев не регламентируется данным стандартом и может меняться в зависимости от платформ исполнения.

Пример использования формального комментария для инициализации программы, получаемой из диаграммы ПРИМС:

formal #include «hal.h» #define SIGNAL_CRASH 1 unsigned int value = 0;

При реализации данного подхода важно в цепях прозрачности логики диаграмм ПРИМС удерживать баланс между кодом инициализации и собственно исполняемым кодом диаграммы и избегать помещения логики работы программы в формальные комментарии.

10.3 Использование формальных комментариев для описания динамических компонентов

Формальные комментарии в диаграммах ПРИМС могут также использоваться для расширения функционала редактора за счет инкапсуляции логики реализации компонентов диаграммы. Примером такого использования формальных комментариев может являться описание динамических компонентов диаграммы, которые могут определяться узлом формального комментарием с ключом со специально структурированным телом комментария. Пример возможного описания динамических компонентов диаграммы:

formal CGML_COMPONENT

id/LED1

type/LED

name/Светодиод

description/Встроенный в плату светодиод, чтобы им мигать

pin/13

В приложении Г представлен расширенный пример использования динамических компонентов при описании диаграммы.

10.3.1 Требования к структуре описания динамических компонентов

Ключ dData:

• тело формального комментария должно начинаться со строки CGML_COMPONENT, за которой следует набор параметров вида название/значение, разделенные символом косой черты (/), отдельные параметры отделяются пустой строкой (по аналогии с параметрами метаданных документа, см. 6.9);
• значение параметров: обязательно использование параметров id (уникальный идентификатор компонента) и type (тип компонента, например, LED или Sensor). Могут использоваться другие опциональные параметры, определяемые платформой, такие как name, description и т.п.

10.3.2 Требования к использованию описания динамических компонентов

Если динамические компоненты поддерживаются платформой исполнения, они должны определяться в каждой из машин состояний, представленных в диаграмме.

Приложение А (обязательное)

ДЕРЕВО ТЕГОВ ДОКУМЕНТА

В настоящем приложении приводится структура тегов, используемая в документе CGML. Так как формат во многом опирается на теги data, для информативности эти теги в дереве указываются вместе с ключом, например, data. Звездочка (*) указывает на возможное повторение данного тега (0 и более раз). В прямоугольных скобках ([...]) указываются теги, относящиеся к расширениям стандарта CGML.

Приложение Б (обязательное)

В настоящем приложении приводятся объявления всех ключей, описанных в формате CGML (включая стандартные расширения формата CGML, описанные в настоящем стандарте). Этот блок рекомендуется использовать во всех документах CGML, исключая при необходимости неиспользуемые ключи.

ЭЛЕМЕНТЫ ПРИМС В CGML

Элемент ПРИМС в диаграмме	Графическое обозначение	Представление в формате CGML	Фрагмент graphml-файла
Выбор		Тег node с ключом dVertex, принимающим значение choice. Геометрия элемента, задается прямоугольником (rect)	choice <rect x=«250» y=«100» width=«100» height=«70»/>
Глубокая история		Тег node с ключом dVertex, принимающим значение deepHistory. Геометрия элемента, задается точкой (point). Относится к расширенной версии формата CGML	deepHistory
Завершение		Тег node с ключом dVertex, принимающим значение terminate. Геометрия элемента, задается точкой (point)	terminate
Комментарий без имени и с именем (человекочитаемый, без предмета комментирования)		Ter node с ключом dNote, принимающим значение informal, и ключом dName, задающим имя элемента (при наличии), и ключом dData, задающим тело комментария. Геометрия элемента, задается прямоугольником (rect)	Управление теплицей</ data> informal Комментарий <rect x=«100» y=«100» width=«150» height=«50»/> ... informal Для разработчиков</ data> Требуется уточнить параметры старта системы после выхода из режима сна <rect x=«50.0» y=«10.0» width=«300.0» height=«200.0»/>
Комментарий (машиночитаемый, без предмета комментирования)		Тег node с ключом dNote, принимающим значение formal. Геометрия элемента, задается прямоугольником (rect)	formal #include &guot;io.h&guot; CONTEXT c; init_io(&c); <rect x=«200» y=«50» width=«300» height=«100»/>
Комментарий к элементу		Тег node с ключом dNote, описывающий узел комментария, и тег edge, описывающий дугу в графе между узлом комментария и его предметом комментирования, с ключом dPivot без заданного значения, связывающий узел комментария с узлом комментируемого элемента	informal Требуется для уточнения параметров <rect x=«400» y=«20» width=«200» height=«100»/> ... <data кеу=«dName»>Ожидание <rect x=«80» y=«450» width=«180» height=«80»/> ... <edge id=«n_temp-n1» source=«n_temp» target=«n1»>
Комментарий к фрагменту		Тег node с ключом dNote, описывающий узел комментария, и тег edge, описывающий дугу в графе между узлом комментария и его предметом комментирования, с ключом dPivot со значением dData, связывающий узел комментария с конкретной частью комментируемого элемента, указанной в дополнительном ключе dChunk	informal Требуется для уточнения параметров <rect x=«150» y=«20» width=«200» height=«100»/> ... informal Временно: считаем, пока, что 10 сек достаточно <rect x=«300» y=«300» width=«200» height=«150»/> ... dData уточнения
Конечное состояние		Тег node с ключом dVertex, принимающим значение final. Геометрия элемента, задается точкой (point)	final
Локальная история		Тег node с ключом dVertex, принимающим значение shallowHistory. Геометрия элемента, задается точкой (point). Относится к расширенной версии формата CGML	shallowHistory
Машина состояний		Верхнеуровневый тег graph с ключом dStateMachine и заданной геометрией прямоугольника (rect), если машина состояния должна быть видима на диаграмме	Машина состояний</ data> <rect x=«100» y=«100» width=«150» height=«50»/> ...
Начальное псевдосостояние		Тег node с ключом dVertex, принимающим значение initial. Геометрия элемента, задается точкой (point)	initial
Область		Тег node без специальных ключей. Имя состояния задается ключом dName. Блок декомпозиции включает одну или более областей, каждая из которых определяется тегом graph для подграфа с ключом dRegion, включающим узлы, задающие дочерние элементы области. Геометрия области, задается прямоугольником (rect)	Состояние <rect x=«10.0» y=«10.0» width=«500.0» height=«300.0»/> <rect x=«0.0» y=«0.0» width=«250.0» height=«300.0»/> <rect x=«250.0» y=«0.0» width=«250.0» height=«300.0»/>
Объединение		Тег node с ключом dVertex, принимающим значение join. Геометрия элемента, задается точкой (point). Относится к будущим версиям формата CGML	join
Простое состояние, представленное только именем		Тег node без специальных ключей. Имя состояния задается ключом dName. Геометрия элемента, задается прямоугольником (rect)	Простое состояние</ data> <rect x=«10» y=«10» width=«500» height=«250»/>
Простое состояние с блоками внутреннего поведения и внутренних переходов		Тег node без специальных ключей. Имя состояния задается ключом dName. Блоки внутреннего поведения и внутренних переходов задаются ключом dData. Геометрия элемента, задается прямоугольником (rect)	Ожидание ответа entry/ индикатор(ВКЛ) ОШИБКА(e) / вывод(e) ПАУЗА / сменить_режим <rect x=«10» y=«10» width=«500» height=«250»/> Скан entry/ Сканер. ИскатьЦель(мин) Таймер.Выполнен/ Таймер.Установить(5) exit/ Сканер.Стоп() <rect x=«10» y=«10» width=«400» height=«380»/>
Разветвление		Тег node с ключом dVertex, принимающим значение fork. Геометрия элемента, задается точкой (point). Относится к будущим версиям формата CGML	fork
Составное состояние		Тег node без специальных ключей. Имя состояния задается ключом dName. Блок декомпозиции определяется тегом graph для подграфа с ключом dRegion, включающим узлы, задающие дочерние элементы. Дуги, заданные тегами edge и принадлежащие подграфу, описываются вместе со всеми остальными дугами в конце описания графа узла машины состояний. Геометрия элемента, задается прямоугольником (rect)	C0 <rect x=«10.0» y=«10.0» width=«500.0» height=«300.0»/> <rect x=«10.0» y=«50.0» width=«450.0» height=«240.0»/> C1 <rect x=«20.0» y=«75.0» width=«150.0» height=«50.0»/> C2 <rect x=«270.0» y=«75.0» width=«150.0» height=«50.0»/> C3 <rect x=«270.0» y=«150.0» width=«150.0» height=«50.0»/> ... <edge id=«e1» source=«n0::n1» target=«n0::n2»/> <edge id=«e2» source=«n0::n2» target=«n0::n3»/>
Составное состояние со скрытым блоком декомпозиции (с вариантами символа декомпозиции)		Тег node со специальным ключом dCollapsed. Имя состояния задается ключом dName. Геометрия элемента, задается прямоугольником (rect). Относится к расширенной версии формата CGML	Составное состояние</ data> <rect x=«10» y=«10» width=«500» height=«250»/>
Состояние с вложенной машиной состояний		Тег node с ключом dSubmachineState, значение которого указывает на описание вложенной машины состояний (URL или идентификатор внутри документа). Имя состояния задается ключом dName. Геометрия элемента, задается прямоугольником (rect). Относится к расширенной версии формата CGML	... Машина состояний Состояние <rect x=«10» y=«10» width=«500» height=«250»/> ... Машина состояний</ data> ...
Точка входа		Тег node с ключом dVertex, принимающим значение entrypoint. Геометрия элемента, задается точкой (point). Относится к расширенной версии формата CGML	entryPoint
Точка выхода		Тег node с ключом dVertex, принимающим значение exitPoint. Геометрия элемента, задается точкой (point). Относится к расширенной версии формата CGML	exitPoint
Переход		Тег edge, описывающий дугу в графе, с ключом dData, содержащим возможные события, ограждающее условие или действия	СОБЫТИЕ [o.y.]/ поведение <edge id=«edge-n1-n2» source=«n1» taget=«n2»> Сканер.ЦельОбнаружена [Пылесос.ОбъектовВЗонеДействия = 1]/ Таймер.Установить (2)

Приложение Г (справочное)

ПРИМЕРЫ ДИАГРАММ ПРИМС И СООТВЕТСТВУЮЩИХ ДОКУМЕНТОВ CGML

Г.1 Минимально допустимый документ

Приведенный пример описывает минимально допустимый документ с пустой машиной состояний.

Cyberiada-GraphML-1.0

  <node id="n0::n2">
    <data key="dName">Уборка</data>
    <data key="dData">entry/