ГОСТ Р 70317—2022
повторное использование концепций конкретных пакетов UML. Целью настоящего стандарта являет ся
определение отношений между пакетами UML и пространствами имен XML таким образом, чтобы
обеспечить их модульность и многократное применение. Правила, контролирующие отношения между
пакетами и пространствами имен, используемыми в настоящем стандарте, следующие:
a) реализация XML-схемы будет включать как минимум одно пространство имен для каждого па
кета UML в концептуальной модели, т. е. несколько пакетов UML не должны быть объединены в одно
пространство имен;
b
) пакеты UML могут быть разделены на несколько пространств имен, если это необходимо для
упрощения реализации и управления жизненными циклами различных компонентов;
c) исключения из правила по перечислению а) могут потребоваться для минимизации зависимо
стей между пространствами имен и устранения циклических зависимостей.
8.2 Модель UML для реализации XML-схемы
В ГОСТ Р 57668 определены ряд пакетов UML и отношения между ними. Эти отношения приводят
к зависимостям между теми пакетами, которые делают невозможным их повторное использование без
включения всей модели. Для обеспечения модульности и автоматической генерации схемы в модель
UML добавлен специфичный для XML-схемы уровень реализации, не влияющий на ее семантику. Этот
уровень включает абстрактные классы, которые позволяют разделять пакеты моделей, добавлять тего
вые значения и стереотипы, необходимые для программного обеспечения преобразования UML в XML,
и рефакторинг некоторых пакетов элементов модели, где это требуется для устранения циклических
зависимостей между пространствами имен XML. Абстрактные классы также созданы для определения
групп подстановок для тех классов, которые используются или могут использоваться реализациями XML-
схем других моделей ИСО. Абстрактные классы для связи между пространствами имен упакованы в один
пакет. Измененная модель UML называется моделью реализации, и XML-схема была автоматически сге
нерирована из этой модели реализации в соответствии с определенными правилами (см. [5] и [3]).
8.3 Подход к реализации для разделения XML-пакетов
8.3.1 Общие положения
Подход к реализации для разделения XML-пакетов использует абстрактные классы в значениях
свойств, для которых требуются элементы из импортированных пространств имен. Документы обмена
импортируют базовую схему, пакет абстрактного класса (который не изменяется между версиями) и
схему, которая реализует конкретный элемент в группе подстановки для абстрактного элемента. Но вые
версии конкретного пространства имен могут получать новые определения элементов из этого аб
страктного класса, что позволяет использовать новую модель путем импорта нового пространства имен в
экземпляры документов. Это не требует изменений в реализации базовой схемы, что более подробно
объясняется в настоящем пункте.
Ассоциации между классами UML могут быть смоделированы как значения атрибутов или концы
ассоциаций. Подход реализации необходим в тех случаях, когда необязательный атрибут или ассо
циация имеет тип свойства, который является классом из пакета, отличного от пакета, содержащего
элемент. Экземпляры документов XML следует проверять с/без импорта пространства имен, которое
реализует необязательный класс типа свойства. Это достигается путем использования абстрактного
класса для типа значения свойства в схеме для родительского элемента (MD_Metadata на рисунке 2) и
конкретной заменой этого абстрактного класса в схеме для элемента-потомка (LI_Lineage на рисун ке 2),
который обеспечивает фактическую реализацию класса значения свойства.
Шаблон более подробно показан на рисунке 3; реализация XML-схемы представлена в приме
рах 1—3. Класс MD_Metadata входит в пространство имен базы метаданных (mdb), которое импор
тирует абстрактный класс _Lineagelnformation из пространства имен общих классов метаданных
(тсс). Пространство имен тсс включено во все классы соответствия. Конкретной реализацией класса
_Lineagelnformation является класс LI_Lineage, определенный в пространстве имен метаданных о
про исхождении ресурса (mrl). Соответствующие экземпляры документов не должны импортировать
про странство имен mrl, если они фактически не включают информацию о происхождении.
Пространство имен метаданных о происхождении ресурса (mrl) не должно импортировать
пространство имен базы метаданных (mdb) для проверки, что позволяет использовать его в качестве
автономного модуля в дру гой прикладной схеме, которая может связать происхождение с каким-либо
элементом модели.
23