ГОСТ Р 10.0.04-2019 Система стандартов информационного моделирования зданий и сооружений. Информационное моделирование в строительстве. Справочник по обмену информацией. Часть 2. Структура взаимодействия

>

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОСТР

10.0.04—

2019/

ИСО 29481-2:2012

Система стандартов информационного моделирования зданий и сооружений

ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ В СТРОИТЕЛЬСТВЕ

Справочник по обмену информацией

Часть 2

Структура взаимодействия

(ISO 29481-2:2012, Building information models — Information delivery manual — Part 2: Interaction framework,

IDT)

Издание официальное

Москва Стандартинформ 2019

Предисловие

  • 1 ПОДГОТОВЛЕН Ассоциацией организаций по развитию технологий информационного моделирования в строительстве и ЖКХ (БИМ-Ассоциация) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

  • 2 ВНЕСЕН Проектным техническим комитетом по стандартизации ПТК 70S «Технологии информационного моделирования на всех этапах жизненного цикла объектов капитального строительства и недвижимости»

  • 3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 5 июня 2019 г. № 280-ст

  • 4 Настоящий стандарт идентичен международному стандарту ИСО 29481-2:2012 «Информационное моделирование в строительстве. Справочник по обмену информацией. Часть 2. Структура взаимодействия» (ISO 29481-2:2012 «Building information models — Information delivery manual — Part 2: Interaction framework». IDT).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5—2012 (пункт 3.5).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА

  • 5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. МН62-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© ISO. 2012 — Все права сохраняются © Стандартинформ. оформление. 2019

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

Содержание

  • 1 Область применения

  • 2 Нормативные ссылки

  • 3 Термины и определения

  • 4 Основные принципы

    • 4.1 Общие положения

    • 4.2 BIMmIDM

    • 4.3 Компоненты IDM

    • 4.4 Основные принципы деловой коммуникации

    • 4.5 Карта взаимодействия

    • 4.6 Сообщения в транзакции

    • 4.7 Структура взаимодействия

    • 4.8 Поддержка программных решений

  • 5 Формат структуры взаимодействия

    • 5.1 Введение

    • 5.2 Типы информации в схеме структуры взаимодействия

Приложение А (обязательное) Определение схемы структуры взаимодействия

Приложение В (обязательное) Определение шаблонов

Приложение С (справочное) Пример карты взаимодействия для упрощенного конструкторского бюро

Приложение D (справочное) Основные идеи алгоритма промотора

Приложение ДА (справочное) Сведения о соответствии ссылочных международных

стандартов национальным стандартам

Библиография

Введение

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

Справочник по обмену информацией (IDM) значительно способствует наиболее эффективному применению информационной модели здания (BIM). Быстрый доступ к необходимой информации хорошего качества значительно улучшает строительный процесс. Для этого требуется единое понимание строительных процессов и информации, необходимой для их выполнения.

В настоящем стандарте основное внимание уделяется аспектам строительного процесса, относящимся к задачам управления участниками процесса и координации их действий. Координация, в свою очередь, зависит от коммуникации, которая должна быть хорошо структурированной, понятной, исчерпывающей и оперативной. Благодаря акценту на координацию и взаимодействие настоящий стандарт естественным образом дополняет такие стандарты моделирования зданий, как ИСО 10303-239 и ИСО 16739-1:2018.

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

Разработка настоящего стандарта вызвана потребностью участников процесса в надежности при обмене информацией. Она основывается главным образом на стандарте Нидерландов VISI. разработанном в 2003 году.

ГОСТ Р 10.0.04—2019/ИСО 29481-2:2012

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ Система стандартов информационного моделирования зданий и сооружений ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ В СТРОИТЕЛЬСТВЕ

Справочник по обмену информацией

Часть 2

Структура взаимодействия

System of standards on information modeling of buddings and structures. Building information models. Information delivery manual. Part 2. Interaction framework

Дата введения — 2019—09—01

1 Область применения

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

В настоящем стандарте приведены:

• методология, описывающая структуру взаимодействия.

-соответствующий способ сопоставления обязанностей и взаимодействий, создающих контекст процесса для потока информации,

— формат, в котором должна описываться структура взаимодействия.

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

2 Нормативные ссылки

8 настоящем стандарте использована нормативная ссылка на следующий стандарт:

ISO 29481-1. Building information models — Information delivery manual — Part 1: Methodology and format (Информационное моделирование в строительстве. Справочник по обмену информацией. Часть 1. Методология и формат)

3 Термины и определения

8 настоящем стандарте применены следующие термины с соответствующими определениями:

  • 3.1 справочник по обмену информацией (Information Delivery Manual. IDM): Документация, описывающая бизнес-процесс и содержащая подробное описание информации, которую на определенном этапе проекта должен предоставить пользователь, выполняющий определенную роль.

  • 3.2 структура взаимодействия (interaction framework): Формальное описание элементов взаимодействия. включая определение ролей, транзакций, сообщений в транзакциях и элементов данных в сообщениях.

  • 3.3 схема структуры взаимодействия (interaction framework schema): Формальное описание правил, которым должна подчиняться структура взаимодействия.

  • 3.4 схема взаимодействия (interaction schema): Формальное описание правил, которым должны соответствовать отправленные и полученные сообщения.

Издание официальное

  • 3.5 промотор (promotor): Алгоритм, генерирующий схему взаимодействия из структуры взаимо* действия, схемы структуры взаимодействия и файла шаблонов в качестве входных данных.

  • 3.6 файл шаблонов (templates file): Файл, содержащий несколько независимых от структуры взаимодействия шаблонов для формирования схемы взаимодействия.

  • 3.7 VISI: Аббревиатура, обозначающая стандарт Нидерландов по взаимодействию между участниками в строительных проектах.

Примечание — VISI означает « Voorwaarden scheppen vooc Invoeren Standaardisatie ICT tn de Infrastructuur-seclor», что переводится хак «Создание условий для стандартизации ИКТ-технологий в строительной отрасли».

4 Основные принципы

  • 4.1 Общие положения

Настоящий раздел выделяет и объясняет основные понятия, на которых основан настоящий стандарт.

  • 4.2 BIM и IDM

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

В настоящем стандарте излагается метод разработки справочника по обмену информацией. Приведенная в ИСО 29461-1:2016 методология IDM должна использоваться для всех упоминаний о разработке и использовании ЮМ.

  • 4.3 Компоненты ЮМ

Методология и компоненты IDM описаны в ИСО 29481-1:2016. В указанном стандарте схематически показано, что представляют собой различные компоненты IDM и как они связаны между собой.

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

Карт» вмшодайствня

Тсхмопотмскм карте

ч

н————

4

Дослиим «формации

Рисунок 1 — Зоны ЮМ

С точки зрения пользовательских требований к этим зонам относятся:

  • — карты взаимодействия, описывающие роли и взаимодействия между ними;

  • — технологические карты, описывающие общий процесс, в котором происходит обмен информацией:

  • — доставка информации, описывающая потребности в обмене информацией:

  • — ссылочные процессы (хранимые описания операций обмена информацией);

  • — график проекта (реализации процессов в контексте проекта).

С точки зрения технических решений выделяют следующие зоны:

  • — бизнес-объекты, включающие перечень требований к обмену информацией;

  • — спецификация информации, описывающая схему, лежащую в основе обмена информацией;

  • — информационная модель здания.

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

  • 4.4 Основные принципы деловой коммуникации

После запроса клиента или заказчика предоставить продукт или оказать услугу возникает цепочка действий, совместный результат которых заключается в предоставлении продукта или услуги. Такая цепочка действий называется бизнес-процессом. Речь идет, в частности, о первичном биэнес-лроцессе. поскольку он инициируется извне.

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

Рисунок 2 — Шаблон транзакции (Dietz J.L.G.. 2006 (1))

На рисунке 2 представлена простейшая форма шаблона транзакции. Шаблон показывает, что достижение какого-либо нового результата (возьмем в качестве «желаемого результата», например, предоставление некоего документа) начинается с запроса этого результата лицом, действующим в роли заказчика, улица, действующего в роли исполнителя. Это действие переводит процесс в состояние «результат запрошен». Далее исполнитель отвечает на запрос, пообещав предоставить желаемый результат, тем самым переводя процесс в состояние «результат обещан». Таким образом, у исполнителя появляется задача: он должен выполнить обещание, фактически подготовив документ и приняв решение предоставить его заказчику. При передаче документа заказчику исполнитель сообщает, что его обещание выполнено. Заказчик отвечает путем приемки полученного результата. Это действие завершает транзакцию.

В бизнес-процессе зачастую участвует множество акторов. Их поведение зависит от их роли в конкретном процессе. Роли/акторы взаимодействуют с другими ролями/акторами путем осуществления транзакций. Удобным представлением взаимодействия между ролями/акторами является карта взаимодействия.

  • 4.5 Карта взаимодействия

Карта взаимодействия определяет соответствующие типы ролей и транзакций для определенного процесса. IDM выделяет роль, делающую запрос (инициатор), и роль, отвечающую на этот запрос (исполнитель). 8 каждой транзакции может быть только одна инициирующая роль и одна исполняющая. На рисунке 3 показаны компоненты карты взаимодействия.

Примечание — Система обозначений на карте взаимодействия основана на строительной модели, описанной в публикации профессора Яна Л.Г. Дитца. Она отличается от системы обозначений BPMN и используется для создания максимально простых карт. Также она включает концепцию «транзакции», отсутствующую в BPMN.

«i

CRj

Тип роли Rj

Тип групповой роли <5^

Пинии*, ввлют» «■мэдвйстемв

ItaiTpMuwNlj

Село» смницивтсрсм

Cork» с макпвпжюм

Рисунок 3 — Компоненты карты взаимодействия

Преимущество карты взаимодействия заключается в том. что она фокусируется на интерфейсах между ролями, скрывая при этом сложность конкретного процесса в области ролей и подробности взаимодействия между этими ролями. Использование абстрактных ролей позволяет применять карту взаимодействия в самых разных случаях. Карта взаимодействия — это ценный инструмент для анализа и определения основных элементов бизнес-процесса. На рисунке 4 показан упрощенный пример карты взаимодействия конструкторского бюро.

Кднструкгорою» бюро

Рисунок 4 — Пример карты взаимодействия

В карту взаимодействия должны быть включены все транзакции, необходимые для обработки требуемых вкладов соответствующих ролей в процесс В!М. У всех ролей и транзакций в карте взаимодействия должны быть уникальный идентификатор и имя. Нумерация при этом произвольная.

Название роли определяется основным действием, выполняемым ролью, что делает акцент на вкладе определенной роли в В!М. Составная роль — это роль, которая может состоять из нескольких ролей, состав которых неизвестен или не имеет особого значения.

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

Таблица 1 — Упрощенная таблица транзакций конструкторского бюро

Результат транзакции

Тип транзакции

Разработан проект

Т1. разработка проекта

Разработана спецификация системы

Т2. разработка спецификации системы

Разработана трехмерная модель

ТЗ. разработка трехмерной модели

Разработана смета

Т4, разработка сметы

  • 4.6 Сообщения е транзакции

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

В качестве примера транзакции можно привести обработку запроса трехмерной модели. На рисунке 5 показаны сообщения в транзакции в форме диаграммы последовательности в обозначении UML. Транзакция может быть инициирована только руководителем проекта R1 с помощью сообщения «Запрос трехмерной модели». Инженер — разработчик трехмерных моделей (роль R3) может направить в ответ сообщение «Задание выполнено, запрашивается утверждение выполнения». После отправки сообщения «Выполнение задания утверждено» (или «Выполнение задания не утверждено») транзакция будет завершена.

Транзакция: Т5-запрос трекыодной модели

Рисунок 5 — Пример сообщений в транзакции

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

  • 4.7 Структура взаимодействия

Для выдачи указаний процессу и передачи информации элементы взаимодействия необходимо описать упорядоченным образом. Такое упорядоченное описание носит название структуры взаимо-действия. Структура взаимодействия включает.

  • — определение соответствующих ролей.

-транзакции,

  • — сообщения в транзакции.

  • * порядок сообщений в транзакции,

  • * элементы данных в сообщениях.

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

Пример — Структура взаимодействия может включать атрибут CostEstimation в качестве экземпляра SimpieElementTyp. который будет использоваться в качестве обязательного элемента для определенного сообщения. Она также может включать ограничение для формата атрибута CostEstimation (например, только евро с двумя десятичными знаками).

  • 4.8 Поддержка программных решений

    • 4.8.1 Обзор

Следующим шагом является поддержка структуры взаимодействия с программными решениями в следующих целях:

. поддержка редактирования структуры взаимодействия.

  • — гарантия полноты и обоснованности структуры взаимодействия.

  • — поддержка портативности структуры взаимодействия.

. продержка работы информационных систем.

  • — поддержка коммуникационной интероперабельности.

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

На рисунке 8 показано, как осуществляется поддержка программных решений. В следующих разделах приводится пояснение.

  • 4.8.2 Поддержка структуры взаимодействия

Чтобы обеспечить портативность структуры взаимодействия, необходимо четко обозначить, каким правилам она должна соответствовать. Эти правила должны быть включены в схему структуры взаимодействия. которая записывается в XSD-файл схемы. Структура взаимодействия включает в себя экземпляры классов, определенных в схеме, и записывается в XML-файл.

Пример — Сжема структуры взаимодействия определяет, какие определения атрибутов (SimpleElementType) и ограничений на атрибуты (UserdefinedType) вы можете включить в структуру взаимодействия.

В разделе 5 приведено описание схемы структуры взаимодействия и доступных классов.

Каждая структура взаимодействия должна соответствовать схеме структуры взаимодействия.

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

  • 4.8.3 Промотор

Как только действительная структура взаимодействия станет доступной, ее можно будет интерпретировать с помощью подходящей информационной системы. Затем эта система сможет поддерживать коммуникации в соответствии с параметрами, заданными в структуре взаимодействия. И наконец, желательно, чтобы имелась возможность проводить валидацию принимаемых и отправляемых сообщений, что осуществляется с помощью схемы взаимодействия.

Схема взаимодействия генерируется с помощью общего алгоритма, называемого «промотор». Промотор «продвигает» экземпляры XML в классы XSD. 8 качестве входных данных используются:

— структура взаимодействия (XML),

* схема структуры взаимодействия (XSD).

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

На выходе получаем схему взаимодействия в виде XSD-файла.

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

8 приложении В описываются шаблоны, содержащиеся в XSD-файле.

8 приложении D описываются принципы работы промотора.

Рисунок 6 — Схема поддержки программных решений

  • 4.8.4 Поддержка обмена информацией

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

  • 4.8.5 Техническая реализация обмена информацией

Чтобы обеспечить техническую сторону обмена сообщениями с вложениями между информационными системами, должны быть предусмотрены указания по его реализации. Они должны охватывать следующее:

— протокол обмена информацией.

  • • архитектуру/сервер обмена информацией.

. шифрование.

  • • вызов SOAP-функции.

Указания по реализации не входят в область рассмотрения настоящего стандарта.

5 Формат структуры взаимодействия

  • 5.1 Введение

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

В подразделе 5.2 представлен обзор классов информации, которые могут встречаться в структуре взаимодействия и определены в схеме структуры взаимодействия. Поскольку структура взаимодействия определена в XML, используется термин «тип», а не «класс». В приложении А приведено полное описание схемы структуры взаимодействия. В приложении В приведен пример экземпляра структуры взаимодействия.

  • 5.2 Типы информации е схеме структуры взаимодействия

    • 5.2.1 Введение

Схема заполняется рядом классов или типов. В этом разделе приводится краткое описание до-ступных типов в схеме структуры взаимодействия. В приложении А содержится полное описание схемы структуры взаимодействия в XML. Структура взаимодействия создается из экземпляров этих типов и имеет заголовок, который указывает на схему с определенными доступными типами.

  • 5.2.2 AppendixType

AppendixType — это определение, которое определяет структуру элементов, относящихся к метаданным. Экземпляр AppendixType используется для определения определенных типов файлов или документов, которые могут быть частью отправляемых/лолучаемых сообщений. Структура элементов, связанных с экземпляром AppendixType. представляет определенные метаданные, которые необходимы для определенного типа файла или документа.

  • 5.2.3 ComplexElementType

ComplexElementType содержит набор SimpleElementTypes. Каждый тип SimpleElementType встречается ровно столько раз, сколько встречается элемент, к которому он относится.

  • 5.2.4 Elementcondition

Экземпляр Elementcondition описывает поведение значений элементов в последовательности сообщений. Например, когда экземпляр типа Elementcondition создается со значением FIXEO. это указывает на то. что элементы в последовательности сообщений должны колироваться в случаях, когда доступен один и тот же элемент и его значение не может быть изменено. ElementCondition может ссылаться на различные уровни в структуре. Он может быть напрямую связан с SimpleElement, но также можно связать ElementCondition с ComplexElement или MessagelnTransactionType. В этом случае Elementcondition является действительным для всех элементов, которые являются частью структуры/ набора элементов связанных типов.

  • 5.2.5 GroupType

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

  • 5.2.6 MessageType

Тил MessageType используется для определения содержимого сообщения. Элементы, которые являются частью сообщения, в свою очередь группируются в один или несколько экземпляров ComplexElementType.

  • 5.2.7 MessagelnTransactionType

MessagelnTransactionType (MITT) представляет собой определение, используемое для связывания экземпляров типа MessageType с экземплярами типа TransactionType. Проще говоря, один и тот же тип сообщения может встречаться в данном типе транзакции чаще, чем один раз. и наоборот. Можно связать несколько экземпляров MessageType с одним экземпляром TransactionType и один экземпляр MessageType с несколькими экземплярами TransactionType. Кроме того. MITT дает возможность изменить направление действия от исполнителя к инициатору. Также он предусматривает возможность отслеживания того, блокируется ли лоток сообщений открытыми вторичными транзакциями или нет.

  • 5.2.8 OrganisatlonType

Определение конкретной группы организаций. В общем случае в структуре доступен как минимум один экземпляр с конкретной причиной для определения структуры элементов организации.

  • 5.2.9 PorsonType

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

  • 5.2.10 ProjectType

Определение типа проекта. Говоря в общем, в структуре доступен как минимум один экземпляр с конкретной причиной для определения структуры элементов, определяющих проект.

  • 5.2.11 RoleType

Определение роли. Экземпляры типа RoleType необходимы для создания TransactionType в структуре.

  • 5.2.12 SimpleElementType

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

  • 5.2.13 TransactionPhaseType

Определение, которое может использоваться для определения экземпляра, описывающего этап транзакции. Например, экземпляр TransactionPhaseType может соответствовать этапам «запрошен результат» или «в ожидании».

  • 5.2.14 TransactionType

Определение транзакции. В экземпляре транзакции определяются роли инициатора и исполнителя.

  • 5.2.15 userDefinedType

Тил UserDefinedType используется для определения типов данных (например, строки) и ограничений XSD. Например, с помощью экземпляра UserDefinedType можно определить минимальную длину строки.

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

Рисунок 7 — Типы и ссылки схемы структуры взаимодействия

Приложение А

(обязательное)

Определение схемы структуры взаимодействия

А.1 Введение

Структура взаимодействия должна соответствовать правилам, которые включены в схему структуры взаимодействия. В настоящем приложении определение схемы структуры взаимодействия привадится 8 формате EXPRESS и в формате XSO. Кроме того, приведены описания типов элементов, атрибутов, элементов и ссылок.

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

А.2 Определение схемы структуры взаимодействия (формат EXPRESS)1)

SCHEMA ISO 29481_Part_2A;

ENTITY ProjedType; — Определение конкретной группы проектов. Обычно в структуре взаимодействия будет присутствовать только один экземпляр. определяющий структуру элементов, которые будут предоставляться в каждом экземпляре проекта.

namespace: STRING; description: STRING;

startDate: DATETIME;

endDate: DATETIME;

state: STRING:

dateLaMu: DATETIME;

userLaMu: STRING:

language: OPTIONAL STRING: category: OPTIONAL STRING; helpinfo: OPTIONAL STRING;

oode: OPTIONAL STRING;

complexEJements: OPTIONAL SET [0:?] OF ComptexElementType;

END_ENTITY:

ENTITY PersonType; — Определение конкретной группы лиц. Обычно в структуре взаимодействия будет присутствовать только один экземпляр, определяющий структуру элементов, которые будут предоставляться 8 каждом экземпляре лица.

description: STRING;

startDate: DATETIME;

endDate: DATETIME;

state: STRING;

dateLaMu: DATETIME;

userLaMu: STRING;

language: OPTIONAL STRING: category: OPTIONAL STRING;

helpinfo: OPTIONAL STRING;

oode: OPTIONAL STRING:

complexElements: OPTIONAL SET [0:?] OF ComplexElementType;

END.ENTITY;

ENTITY OrganisationType; — Определение конкретной группы организаций. Обычно в структуре взаимодействия присутствует только один экземпляр. определяющий структуру элементов, которые должны предоставляться в каждом экземпляре организации.

description: STRING;

startDate: DATETIME;

endDate: DATETIME;

state: STRING;

dateLaMu: DATETIME:

userLaMu: STRING;

language: OPTIONAL STRING;

category; OPTIONAL STRING;

hetplnfo: OPTIONAL STRING;

В настоящем стандарте приводится полное описание схемы структуры взаимодействия, представленное в ИСО 29481-2:2012.

code: OPTIONAL STRING;

complexElements: OPTIONAL SET [0:?] OF ComplexElementType:

END.ENTITY;

ENTITY AppendixType; —AppendixType содержит определение дополнения. Какие элементы данных должны записываться с помощью дополнения, можно указать в разделе составного элемента.

description: STRING;

slartDate: DATETIME;

endDate: DATETIME;

slate: STRING;

dateLaMu; DATETIME;

userLaMu: STRING:

language; OPTIONAL STRING; category; OPTIONAL STRING; belplnfo: OPTIONAL STRING: code: OPTIONAL STRING; complexElements: OPTIONAL SET [0:?] OF ComplexElementType: END_ENTITY;

ENTITY ComplexElementType; — ComplexElementType содержит набор SimpleElementTypes. Каждый заявленный тип SimpleEtementType входит ровно столько раз. сколько он упоминается.

description: STRING;

starlDate: DATETIME;

endDate: DATETIME;

state: STRING;

dateLaMu: DATETIME;

userLaMu: STRING:

language; OPTIONAL STRING; category; OPTIONAL STRING; belplnfo: OPTIONAL STRING: complexElements: OPTIONAL SET (0:?] OF ComplexElementType; simpleElements; OPTIONAL SET (0:?] OF SimpleElementType: END_ENTITY:

ENTITY MessageType; — Определение типа сообщения (MessageType). которое указывает структуру сообщения и какой набор типов SimpleElementType (через ComplexElementType) оно может сопровождать.

description: STRING;

slartDate: DATETIME;

endDate: DATETIME:

slate: STRING;

dateLaMu: DATETIME;

userLaMu: STRING:

language; OPTIONAL STRING; category; OPTIONAL STRING; belplnfo: OPTIONAL STRING: code: OPTIONAL STRING;

complexElements: OPTIONAL SET [0:?] OF ComplexElementType:

appendixTypes: OPTIONAL SET [1:?] OF AppendixType;

END.ENTITY;

ENTITY Elementcondition; — Условие SimpleElementType а том виде, как оно используется в конкретном MessageType.

description: STRING:

condition: STRING;

belplnfo: OPTIONAL STRING;

complexElement OPTIONAL ComplexElementType:

simpleElemertt: OPTIONAL SimpleElementType: messagelnTransaclion: OPTIONAL MessagelnTransactionType;

END.ENTITY:

ENTITY SimpleElementType: — Определение типа простого элемента (SimpleElementType). Этот тип элемента указывает свойство, которое может встречаться в различных структурах объекта, например в MessageType (см. также AppendixType. ProjectType. PersonType и OrganisationType). SimpleElementType всегда является вложенным в ComplexElementType.

description: STRING;

interfaceType: STRING:

state: STRING;

dateLaMu: DATETIME;

userLaMu: STRING;

language: OPTIONAL STRING;

category: OPTIONAL STRING;

helpinfo: OPTIONAL STRING;

valueList OPTIONAL STRING;

userDefinedType: UserDefinedType;

END.ENTITY;

ENTITY UserDefinedType; — Спецификация типа данных (для использования в SimpleElementType). Этот тип данных формирует заполняемые области 8 конечном сообщении; например, нидерландский почтовый индекс всегда начинается с четырех цифр, за которыми следуют две буквы.

description: STRING;

state: STRING;

dateLaMu: DATETIME;

userLaMu: STRING;

baseType: STRING;

xsdRestriction: OPTIONAL STRING;

language: OPTIONAL STRING;

helpinfo: OPTIONAL STRING;

END.ENTITY;

ENTITY MessagelnTransactionType; — Образец типа MessageType в типе TransactionType. относящийся к конкретному типу группы (GroupType).

requiredNotify: INTEGER;

dateLaMu: DATETIME.

userLaMu: STRING;

received: BOOLEAN;

send: BOOLEAN:

state: STRING;

initiatorToExecutor: OPTIONAL BOOLEAN;

openSecondaryTransactionsAllowed: OPTIONAL BOOLEAN;

firslMessage; OPTIONAL BOOLEAN;

message: MessageType:

previous: OPTIONAL SET [0:?] OF MessagelnTransactionType;

transaction: TransactionType:

transactionPhase: OPTIONAL TransactionPhaseType:

group: GroupType:

appendixTypes: OPTIONAL SET (t:?] OF AppendixType;

END.ENTITY;

ENTITY TransactionPhaseType; — Определение фазы, относящейся к транзакции.

Примеры: «назначение принято» или «часть результата получена», description: STRING;

startDale: DATETIME:

endDate: DATETIME;

state: STRING:

dateLaMu: DATETIME;

userLaMu: STRING;

language: OPTIONAL STRING: category: OPTIONAL STRING.

helpinfo: OPTIONAL STRING;

code: OPTIONAL STRING;

END.ENTITY;

ENTITY TransactionType: — Определение типа транзакции. Тип транзакции может ссыпаться на другие типы транзакции. Транзакцию будет инициировать лицо, принадлежащее к организации, выполняющей определенную роль. На этом уровне должен быть заявлен тип роли инициатора (введенный в действие активированной схемой). Это же верно для исполнителя.

description: STRING:

startDale: DATETIME:

endDate: DATETIME;

state: STRING:

dateLaMu: DATETIME;

userLaMu: STRING;

language: OPTIONAL STRING;

category. OPTIONAL STRING;

belplnfo: OPTIONAL STRING;

code; OPTIONAL STRING;

result: OPTIONAL STRING;

subTransactions: OPTIONAL SET [1:?] OF TransactionType;

initiator. RoieType;

executor; RoleType:

appendixTypes: OPTIONAL SET [1:?] OF AppendixType;

END.ENTITY:

ENTITY RoleType; — Определение конкретного типа роли, description; STRING;

startDate: DATETIME;

endDate: DATETIME;

state: STRING;

dateLaMu;DATETIME;

userLaMu: STRING;

language: OPTIONAL STRING; category; OPTIONAL STRING; helpinfo: OPTIONAL STRING: code; OPTIONAL STRING.

responsibilitySoope: OPTIONAL STRING; responsibitityTask: OPTIONAL STRING; responsibrlitySupportTask: OPTIONAL STRING: responsibiiityFeedback: OPTIONAL STRING;

END_ENTITY:

ENTITY GroupType: — Определение группы для сохранения дополнений, отправленных с сообщением в транзакции.

description: STRING;

startDate: DATETIME;

endDate: DATETIME;

state: STRING:

dateLaMu; DATETIME;

userLaMu: STRING;

language; OPTIONAL STRING; category; OPTIONAL STRING; belplnfo: OPTIONAL STRING: END.ENTITY;

END SCHEMA:

А.З Определение схемы структуры взаимодействия (формат XSD)

<?xml version=»l.0″ encoding = «UTF-8»? >

<xsd:schema targetNamespace-«http://www. ISO 29481_Part_2A.com/schemas» xmlns:iso29481p2a = «http://www.IS029481_Part_2A.com/schemas» xmlns:xsd — «http://www.w3.org/2001/XMLSchema»

elementFormDefault • «qualified» >

<!- объявление корневого элемента (для SCHEMA определений) -<xsd:element name-«IS0 29481_Part_2A» >

<xsd:complexType>

<xsd:choice maxOccurse«unbounded» >

<xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element </xsd:choice>

ref=»iso29481p2a:AppendixType»/ > ref=»iso29481p2a:ComplexElementType»/ > ref=»iso29481p2a:Elementcondition»/ > ref«»iso29481p2a:GroupType»/ > ref»»iso29481p2a:MessageInTransactionType»/ refe«iso294 81p2a:MessageType»/ > ref=»iso29481p2a:OrganisationType»/ > ref=»iso29481p2a:PersonType»/ > ref=»iso29481p2a:?rojectType»/ > ref-«iso29481p2a:RoleType»/ > refe«iso29481p2a:SimpleElementType»/ > ref«»iso29481p2a:TransactionPhaseType»/ > ref=»iso294Blp2a:TransactionType»/ > ref=»iso29481p2a:UserDefinedType»/ >

</xsd:complexType> </xsd:element> <!- объявление элемента (для ENTITY определений) — <xsd:element name=»AppendixType» type = «iso294Blp2a:AppendixTypeType» >

<xsd:annotation>

<xsd:documentation>TMn AppendixType содержит определение приложения. Какие элементы данных должны быть записаны в приложении, можно указать в разделе сложный элемент.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name=»ComplexElementType»

type = «iso294Blp2a:ComplexElementTypeType» >

<xsd:annotation>

<xsd:documentation>CnoxHMft тип элемента ComplexElementType содержит набор простых типов элементов SimpleElementTypes. Каждый, из описанных SimpleElementType встречается ровно столько раз, сколько указано.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name-«ElementCondition» type » «iso29481p2a:ElementConditionType» >

<xsd:annotation>

<xsd:documentation>ycnoBne SimpleElementType, используемое в определенном MessageType.</xsd:documentation

</xsd:annotation>

</xsd:element>

<xsd:element name=»GroupType» type = z‘iso29481p2a:GroupTypeType» > <xsd:annotation?

<xsd:documentat1оп>0пределение группы для хранения приложений, отправленных с сообщением в транзакции.</xsd:documentation?

</xsd:annotation?

</xsd:element?

<xsd:element name=»MessagelnTransactionType» type = «iso29481p2a:MessagelnTransactionTypeType» >

<xsd:annotation?

<xsd:documentation>Bo3HMKHOseHne MessageType в TransactionType, связанного с определенным типом группы (GroupType).</xsd:documentation? </xsd:annotation?

</xsd:element?

<xsd:element name=»MessageType» type « «iso2948Lp2a:MessageTypeType» > <xsd:annotation?

<xsd:documentation?OnpefleneHHe типа сообщения (MessageType), указывающее структуру сообщения и какой набор SimpleElementType (через ComplexElementType) оно может сопровождать.</xsd:documentation?

</xsd:annotation?

</xsd:element?

<xsd:element name-«OrganisationType» type ■ «iso29481p2a:OrganisationTypeType» ?

<xsd:annotation?

<xsd:documentation>OnpeaeJieHMe конкретной группы организаций. Как правило, только один экземпляр будет присутствовать в структуре взаимодействия, определяющей структуру элементов, которые должен представлять каждый экземпляр организации.</xsd:documentation?

</xsd:annotation?

</xsd:element?

<xsd:element name=»PersonType» type = «iso29481p2a:PersonTypeType» ? <xsd:annotation?

<xsd: documentations-определение конкретной группы людей. Как правило, только один экземпляр будет присутствовать в структуре взаимодействия, определяющей структуру элементов, которые должен представлять каждый экземпляр человека.</xsd:documentation?

</xsd:annotation?

</xsd:element?

<xsd:element name=»ProjectType» type = «iso29481p2a:ProjectTypeType» ? <xsd:annotation?

<xsd:documentation?OnpefleneHne конкретной группы проектов. Как правило, только один экземпляр будет присутствовать в структуре взаимодействия, определяющей структуру элементов, которые должен представлять каждый экземпляр проекта.</xsd:documentation?

</xsd:annotation?

</xsd:element?

<xsd:element name«»RoleType» type • «iso29481p2a:RoleTypeType» ?

<xsd:annotation?

<xsd:documentation?OnpefleneHHe конкретного типа роли.</xsd:documentation?

</xsd:annotation?

</xsd:element?

<xsd:element name-«SimpleElementType» type a «iso29481p2a:SimpleElementTypeType» ?

<xsd:annotation> <xsd:documentation>OnpeneneHne простого типа элемента (SimpleElementType). Этот тип элемента определяет свойство, которое может встречаться в различных структурах объектов, например, в MessageType (см. Также AppendixType, ProjectType, PersonType и OrganisationType). SimpleElementType всегда встроен в ComplexElementType.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name=»TransactionPhaseType» type = «iso29481p2a:TransactionPhaseTypeType» >

<xsd:annotation>

<xsd:documentation>OnpefleneHMe фазы, связанной с транзакцией. Примерами являются «принятое назначение’* или «полученная часть результата”.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name»»TransactionType» type — «iso29481p2a:TransactionTypeType» >

<xsd:annotation>

<xsd:documentation>OnpefleneHHe типа транзакции. Тип транзакции может вновь ссылаться на другие типы транзакций. Инициатором сделки является лицо, принадлежащее к организации, выполняющей определенную роль, на этом уровне должен быть указан тип роли инициатора (продвинутая схема будет применять это). То же самое относится и к исполнителю. </xsd: documentation

</xsd: annotation

</xsd:element>

<xsd:element name=»UserDefinedType» type = «iso29481p2a:UserDefinedTypeType» >

<xsd:annotation>

<xsd:docurnentation>Cneun4>MKauHfl типа данных (для использования в SimpleElementType).</xsd:documentation>

</xsd:annotation>

</xsd:element>

<!- объявления ссылок на элементы (для ENTITY определений) — <xsd:element name=»AppendixTypeRef»

type = «iso29481p2a:AppendixTypeTypeRef»/ >

<xsd:element name=»ComplexElementTypeRef» type « «iso29481p2a:ComplexElementTypeTypeRef»/ >

<xsd:element name-«ElementConditionRef»

type » «iso29481p2a:ElementConditionTypeRef»/ >

<xsd:element names«GroupTypeRef»

type = «iso29481p2a:GroupTypeTypeRef»/ >

<xsd:element name=»MessageInTransactionTypeRef» type = «iso29481p2a:MessageInTransactionTypeTypeRef»/ >

<xsd:element name»»Mes3ageTypeRef»

type • «iso29481p2a:MessageTypeTypeRef»Z >

<xsd:element name-«OrganisationTypeRef» type « «iso29481p2a:OrganisationTypeTypeRef»/ >

<xsd:element name=»PersonTypeRef» type = «iso29481p2a:PersonTypeTypeRef»/ >

<xsd:element name-«ProjectTypeRef» type ■ «iso29481p2a:ProjectTypeTypeRef»/ >

<xsd:element name=»RoleTypeRef»

type = «iso29491p2a:RoleTypeTypeRef»/ >

<xsd:element name=»SimpleElementTypeRef»

type • «iso29481p2a:SimpleElementTypeTypeRef»/ >

<xsd:elementname-«TransactionPhaseTypeRef»type • «iso29481p2a:Transact ionPhaseTypeTypeRef»/ >

<xsd:element namee«TransactionTypeRef»

type = «iso29481p2a:TransactionTypeTypeRef»/ >

<xsd:element name=»(JserDefinedTypeRef»

type = «iso29481p2a:UserDefinedTypeTypeRef»/ >

<!- объявление ссылок на сложные элементы (для ENTITY определений}-» <xsd:complexType name=»AppendixTypeType» >

<xsd:complexContent>

<xsd:extension basea‘»iso29481p2a:elementType» >

<xsd:sequence>

<xsd:element name=»description» type = «xsd:string»/

<xsd:element name=»startDate» type = «xsd:dateTime»/

<xsd:element name=»endDate» type = «xsd:dateTime»/ >

<xsd:element name-«state» type « «xsd:string»/ >

<xsd:element name-«dateLaMu» type • «xsd:dateTime»/ >

<xsd:eiement name=»userLaMu» type e «xsd:string»/ >

<xsd:element name=»language» type * «xsd:string»

minOccurs = «0»/ >

<xsd:element name=»category» type = «xsd:string»

minOccurs = «0»/ >

<xsd:element name«»helplnfo» type « «xsd:string»

minOccurs — «0»/ >

<xsd:element name_«code» type • «xsd:string»

minOccurs » «0»/ >

<xsd:element namea«complexElements» minOccurs e «0» >

<xsd:complexType>

<xsd:choice maxOccurs=»unbounded» >

<xsd:element ref=»iso29481p2a:ComplexElementType»/ > <xsd:element

ref-«iso294 8lp2a:ComplexElementTypeRef»/ >

</xsd:choice>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name=»ComplexElementTypeType» >

<xsd:complexContent> <xsd:extension bases«iso29481p2a:elementType» > <xsd:sequence>

<xsd:element name=»description» type = «xsd:string»/ > <xsd:element name=»startDate» type = «xsd:dateTime»/ > <xsd:element name=»endDate» type = «xsd:dateTime»/ > <xsd:element name»»state» type « «xsd:string»/ > <xsd:element name-«dateLaMu» type • «xsd:dateTime»/ >

<xsd:element name«»userLaMu» type — «xsd:string»/ >

<xsd:element name-«language» type • «xsd:string» minOccurs = «0»/ >

<xsd:element name=»category» type = «xsd:string» minOccurs = «0»/ >

<xsd:element name=»helplnfo» type = «xsd:string» minOccurs = «0»/ >

<xsd:element name-«complexElements» minOccurs — «0» > <xsd:compiexType>

<xsd:choice maxOccurs=»unbounded» >

<xsd:element ref=»iso29481p2a:ComplexElementType»/ > <xsd:element ref=»iso29481p2a:ComplexElementTypeRef»/ >

</xsd:choice>

</xsd:complexType>

</xsd:element>

<xsd:element name=»simpleElements» minOccurs = «O» >

<xsd:complexType>

<xsd:choice maxOccurs«»unbounded» >

<xsd:element ref-«iso29481p2a:SimpleElementType»/ > <xsd:element ref=»iso29481p2a:SimpleElementTypeRef»/ >

</xsd:choice>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name=»ElementConditionType» >

<xsd:complexContent> <xsd:extension base=»iso29481p2a:elementType» > <xsd:sequence>

<xsd:element name-«description» type • «xsdsstring»/ >

<xsd:element namee«condition» type = «xsd:string»/ >

<xsd:element name=»helplnfo» type = «xsd:string» minOccurs = «0»/ >

<xsd:element name=»complexElement» minOccurs = «0» >

<xsd:complexType>

<xsd:choice>

<xsd:element ref=»iso29481p2a:ComplexElementType»/ > <xsd:element ref=»iso29481p2a:ComplexElementTypeRef»/ >

</xsd:choice>

</xsd:complexType>

</xsd:element>

<xsd:element name-«simpleElement» minOccurs — «0» >

<xsd:complexType>

<xsd:choice>

<xsd:element ref=»iso29481p2a:SimpleElementType»/ > <xsd:element

ref«»iso29481p2a:SimpleElementTypeRef»/ >

</xsd:choice>

</xsd:complexType»

</xsd:element>

<xsd:element name“»messageInTransaction» <xsd:complexType>

<xsd:choice»

<xsd:element ref=»iso29481p2a:MessageInTransactionType»/ >

<xsd:element ref=»iso29481p2a:MessageInTransactionTypeRef»/ > </xsd:choice>

</xsd:complexType»

</xsd:element» </xsd:sequence» </xsd:extension» </xsd:complexcontent» </xsd:complexType» <xsd:complexType name=»GroupTypeType» > <xsd:complexcontent»

<xsd:extension base-«iso29481p2a:elementType» <xsd:sequence>

<xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element minOccurs = «0»/ >

<xsd:element minOccurs = «0»/ >

<xsd:element «0»/ »

name-«description» type name=»startDate» type = name=»endDate» type name=»state» type = name«»dateLaMu» name-«userLaMu» name*»language»

type type type

minOccurs

minOccurs

«0» >

• «xsd:string»/ «xsd:dateTime»/ = «xsd:dateTime»/ > «xsd:string»/ >

• «xsd:dateTime»/ >

  • — «xsd:string»/ >

  • — «xsd:string»

name=»category»

name«»helplnfo»

type =

type =

«xsd:string»

«xsd:string»

</xsd:sequence»

</xsd:extension»

</xsd:complexcontent»

</xsd:complexType»

<xsd:complexType name=»MessagelnTransactionTypeType» >

<xsd:complexcontent» <xsd:extension base-«iso29481p2a:elementType» > <xsd:sequence>

<xsd:element name=»requiredNotify» type — «xsd:integer»/ >

<xsd:element name=»dateLaMu» type = «xsdrdateTime»/ > <xsd:element name=»userLaMu» type = «xsd:string»/ > <xsd:element name=»received» type = «xsd:boolean»/ > <xsd:element name«»send» type » «xsd:boolean»/ > <xsd:element name-estate» type — «xsd:string»/ > <xsd:element name=»initiatorToExecutor» type = «xsd:boolean» minOccurs = «0»/ »

<xsd:element name=»openSecondaryTransactionsAllowed» type = «xsd:boolean» minOccurs = «0»/ >

<xsd:element name-«!irstMessage» type • «xsd:boolean» minOccurs • «0»/ >

<xsd:element name=»message» >

<xsd:complexType>

<xsd:choice>

<xsd:element ref»»iso29481p2a:MessageType»/ > <xsd:element ref»»iso29481p2a:MessageTypeRef»/ > </xsd:choice>

</xsd:complexType>

</xsd:element>

<xsd:element name=»previous» minOccurs = «0» >

<xsd:complexType>

<xsd:choice maxOccurs=»unbounded» >

<xsd:element ref“»iso29481p2a:MessageInTransactionType»/ >

<xsd:element ref=»iso29481p2a:MessageInTransactionTypeRef»/ > </xsd:choice>

</xsd:complexType>

</xsd:element>

<xsd:element name«»transaction» >

<xsd:complexType>

<xsd:choice>

<xsd:element ref=»iso29481p2a:TransactionType»/ > <xsd:element ref=»iso29481p2a:TransactionTypeRef»/ > </xsd:choice>

</xsd:complexType>

</xsd:element> <xsd:element name-«transactionPhase» minOccurs — «0» > <xsd:complexType>

<xsd:choice>

<xsd:element ref=»iso29481p2a:TransactionPhaseType»/ >

<xsd:element ref=»iso29481p2a:TransactionPhaseTypeRef»/ > </xsd:choice>

</xsd:complexType>

</xsd:element>

<xsd:element namee«group» >

<xsd:complexType>

<xsd:choice>

<xsd:element ref=»iso29481p2a:GroupType»/ > <xsd:element ref=»iso29481p2a:GroupTypeRef»Z > </xsd:choice>

</xsd:complexType> <Zxsd:element> <xsd:element name»»appendixTypes» minOccurs • «0» > <xsd:complexType>

<xsd:choice maxOccurs=»unbounded» >

<xsd:element ref=»iso29481p2a:AppendixType»Z > <xsd:element ref»»iso29481p2a:AppendixTypeRef»Z > </xsd:choice>

</xsd:complexType>

</xsd:element>

<Zxsd:sequence>

</xsd:exten$ion>

</xsd:complexContent>

</xsd: complexType> <xsd:complexType name=»MessageTypeType» >

<xsd:complexContent> <xsd:extension base=»iso29481p2a:elementType» > <xsd:sequence>

<xsd:element

name-«description» type

• «xsd:string»/ >

<xsd:element

name-«startDate

» type —

1 «xsd:dateTime»/ >

<xsd:element

name=»endDate»

type = «

xsd:dateTime»/ >

<xsd:element

name=»state» type = «xsd:string»/ >

<xsd:element

name=»dateLaMu»

type =

«xsd:dateTime»/ >

<xsd:element

name=»userLaMu»

type =

«xsd:string»/ >

<xsd:element

name»»language»

type »

«xsd:string»

minOccurs • «0»/ >

<xsd:element

name«category»

type —

«xsd:string»

minOccurs — «0»/ >

<xsd:element

name=»helplnfo»

type =

«xsd:string»

minOccurs = «0»/ >

<xsd:element

name=»code» type = «xsd:string»

minOccurs = «0»/ >

<xsd:element

name-«complexElements»

minOccurs — «0» >

<xsd:complexType>

<xsd:choice maxOccurs=»unbounded» >

<xsd:element ref=»iso29481p2a:ComplexElementType»/ > <xsd:element

ref=»iso29481p2a:ComplexElementTypeRef»/ >

</xsd:choice>

</xsd:complexType>

</xsd:element>

<xsd:element name=»appendixTypes» minOccurs = «0» > <xsd:complexType>

<xsd:choice maxOccurs=»unbounded» >

<xsd:element ref=»iso29481p2a:AppendixType»/ > <xsd:element ref=»iso29481p2a:AppendixTypeRef»/ > </xsd:choice>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name-«OrganisationTypeType» >

<xsd:complexContent>

<xsd:extension base«iso29481p2a:elementType» >

<xsd:sequence>

<xsd:element name=»description» type = «xsd:string»/ > <xsd:element narae=»startDate» type = «xsd:dateTime»/ > <xsd:element name=»endDate» type = «xsd:dateTime»Z > <xsd:element name»»state» type » «xsd:string»/ > <xsd:element name-«dateLaMu» type • «xsd:dateTime»/ > <xsd:element name“»userLaMu» type — «xsd:string»/ > <xsd:element names«language» type a «xsd:string» minOccurs = «0»/ >

minOccurs

minOccurs

minOccurs

<xsd:element

— «0»/ >

<xsd:element

= «0»/ >

<xsd:element

= «0»/ >

<xsd:element

name=»category» type = «xsd:string»

namea«helplnfo» type • «xsd:string»

namee«code» type = «xsd:string»

narae=»complexElements» minOccurs = «0» >

<xsd:complexType>

<xsd:choice maxOccurs-«unbounded» >

<xsd:element refa«iso29481p2a:ComplexElementType»/ > <xsd:element

ref=«iso29481p2a:ComplexElementTypeRef»/ > </xsd:choice>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:coraplexType narae=»PersonTypeType» >

<xsd:complexContent>

<xsd:extension base-«iso29481p2a:elementType» >

<xsd:sequence>

<xsd:element

<xsd:element

<xsd:element

<xsd:element

<xsd:element

<xsd:element

<xsd:element minOccurs • «0»/ >

<xsd:element minOccurs = «0»/ >

<xsd:element minOccurs = «0»/ >

<xsd:element minOccurs • «0»/ >

<xsd:element

namea«description» type • «xsd:string»/ > name=»startDate» type = «xsd:dateTime»/ > name=»endDate» type = «xsd:dateTime»/ > name=»state» type = «xsd:string»/ > name»»dateLaMu» name-«userLaMu» name-«language»

type = «xsdrdateTime»/ > type • «xsd:string»/ > type • «xsd:string»

name=»category»

name=»helplnfo»

type • «xsd:string»

type = «xsd:string»

name=»code» type • «xsd:string»

name-«complexElements» minOccurs

«О» >

<xsd:complexType>

<xsd:choice maxOccursa«unbounded» >

<xsd:element ref=«iso29481p2a:ComplexElementType»/ >

<xsd:element

ref=»iso29481p2a:ComplexElementTypeRef»/ > </xsd:choice>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name=»ProjectTypeType» >

<xsd:complexContent>

<xsd:extension basea«iso29481p2a:elementType» >

<xsd:sequence>

<xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element minOccurs « «0»/ >

<xsd:element «0»/ >

<xsd:element «0»/ >

<xsd:element

minOccurs

minOccurs

name=»namespace» type = «xsd:string»/ > name=»description» type = «xsd:string»/ > name=»startDate» type • «xsd:dateTime»/ > name-«endDate» type • «xsd:dateTime»Z > name-«state» type ■ «xsd:string»/ > name=»dateLaMu» name=»userLaMu» name=»language»

type a «xsd:dateTime»/ > type = «xsd:string»/ > type = «xsd:string»

name-«category»

name“»helplnfo»

type • «xsd:string»

type я «xsd:string»

name=»code» type = «xsd:string»

minOccurs = «0»/ >

<xsd:element

<xsd:complexType>

<xsd:choice roaxOccurs-«unbounded» >

<xsd:element ref=«iso29481p2a:ComplexElementType»/ > <xsd:element ref=»iso29481p2a:ComplexElementTypeRef»/ >

</xsd:choice> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name»»RoleTypeType» >

<xsd:complexContent>

<xsd:extension base-«iso29481p2a:elementType» >

<xsd:sequence>

<xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element minOccurs • «0»/ >

<xsd:element minOccurs = «0»/ >

<xsd:element

«0»/ >

<xsd:element «0»/ >

<xsd:element

name®»complexElements» minOccurs

«0» >

narae=»description» type я «xsd:string»/ > name=»startDate» type — «xsd:dateTime»/ > name=»endoate» type = «xsd:dateTime»/ > name«»state» type name»»dateLaMu» name“»userLaMu» namee«language»

«xsd:string»/ > type • «xsd:dateTime»/ > type • «xsd:string»/ > type • «xsd:string»

minOccurs

minOccurs

minOccurs = «0»/ >

<xsd:element minOccurs « «0»/ >

<xsd:element

name=»category»

name=»helplnfo»

type = «xsd:string»

type = «xsd:string»

name*»code» type • «xsd:string»

name=»responsibilityScope» type = «xsd:string»

narne=»responsibilityTask» type = «xsd:string»

type я «xsd:string» minOccurs

name»»responsibilitySupportTask» «0»/ >

<xsd:element name=»responsibilityFeedback» type • «xsd:string» minOccurs » «0»/ >

</xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name=»SimpleElementTypeType» > <xsd:complexContent>

<xsd:extension base»»iso29481p2a:elementType» >

<xsd:sequence>

<xsd:element

<xsd:element

<xsd:element

<xsd:element

<xsd:element

<xsd:element

— «0»/ >

<xsd:element

= «0»/ >

<xsd:element

= «0»/ >

<xsd:element

• «0»/ >

<xsd:element

minOccurs

minOccurs

minOccurs

minOccurs

namee«description» type ж «xsd:string»/ > name=»interfaceType» type = «xsd:string»/ > name=»state» type = «xsd:string»/ > name=»dateLaMu» name=»userbaMu» name»»language»

namee«category»

name=»helplnfo»

type = type = type —

type

type =

«xsd:dateTime»/ > «xsd:string»/ > «xsd:string»

«xsd:string»

«xsd:string»

name»»valueList» type « «xsd:string»

name~»userDefinedType» >

<xsd:complexType>

<xsd:choice>

<xsd:element ref=»iso29481p2a:UserDefinedType»/ > <xsd:element ref=»iso29481p2a:UserDefinedTypeRef»/ > </xsd:choice>

</xsd:complexType» </xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType> <xsd:complexType name=»TransactionPhaseTypeType» > <xsd:complexContent>

<xsd:extension base«»iso29481p2a:elementType» >

<xsd:sequence>

<xsd:element

<xsd:element

<xsd:element

<xsd:element

<xsd:element

<xsd:element

<xsd:element

«0»/ >

<xsd:element

«0»/ >

<xsd:element

«0’7 >

<xsd:element

«0’7 >

name-«description» type • «xsd:string»/ > name=»startDate» type = «xsd:dateTime»/ > name=»endDate» type = «xsd:dateTime»/ > name=»state» type = «xsd:string»/ > name=»dateLaMu» name=»userbaMu» name«»language»

minOccurs

minOccurs

minOccurs

minOccurs

names«category»

name=»helplnfo»

type = type = type =

type

type =

«xsd:dateTime»/ > «xsd:string»/ > «xsd:string»

«xsd:string»

«xsd:string»

name=»code» type = «xsd:string»

</xsd:sequence» </xsd:extension> </xsd:complexContent> </xsd:complexType» <xsd:complexType name=»TransactionTypelype» >

<xsd:complexcontent»

<xsd:extension base«»iso29481p2a:elementType» > <xsd:sequence> <xsd:element <xsd:eiement <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element minOccurs a «0»/ > <xsd:element minOccurs = «0»/ >

<xsd:element

minOccurs = «0»/ >

<xsd:element

«0»/ >

<xsd:element

minOccurs

namea«description» type a «xsd:string»/ > namea«startDate» type a «xsd:dateTime»/ > namea«endDate» type = «xsd:dateTime»/ > name=»state» type = «xsd:string»/ > name=»dateLaMu» name»»userLaMu» name-«language»

name=»category»

name=»helplnfo»

суре = type -type —

type =

type =

«xsd:datetime»/ > «xsd:string»/ > «xsd:string»

«xsd:string»

«xsd:string»

name=»code» type « «xsd:string»

namea«result» type • «xsd:string»

minOccurs = «0»/ > <xsd:element <xsd:complexType> <xsd:choice maxOccurs=»unbounded» >

namea«subTransactions» minOccurs = «0» >

<xsd:element refa«iso29481p2a:TransactionType»/ > <xsd:element refa«iso29481p2a:TransactionTypeRef»/ > </xsd:choice>

</xsd:complexType> </xsd:element> <xsd:eiement name=«initiator» >

<xsd:compiexType>

<xsd:choice»

<xsd:element refa«iso29481p2a:RoleType»/ > <xsd:element ref«»iso29481p2a:RoleTypeRef»/ > </xsd:choice»

</xsd:complexType»

</xsd:element»

<xsd:element name=»executor» >

<xsd:complexType»

<xsd:choice»

<xsd:element refa«iso29481p2a:RoleType»/ » <xsd:element ref-«iso29481p2a:RoleTypeRef»/ > </xsd:choice>

</xsd:complexType»

</xsd:element»

<xsd:element name=»appendixTypes» minOccurs = «0» > <xsd:complexType»

<xsd:choice maxOccurs=»unbounded» >

<xsd:element ref«»iso29481p2a:AppendixType»/ > <xsd:element refa«iso29481p2a:AppendixTypeRef»/ >

</xsd:choice»

</xsd:complexType>

</xsd:element»

</xsd:sequence» </xsd:extension» </xsd:complexcontent» </xsd:complexType> <xsd:complexType name=»UserDefinedTypeType» > <xsd:complexcontent»

<xsd:extension base-«iso29481p2a:elementType» > <xsd:sequence»

<xsd:element

<xsd:element <xsd:element <xsd:element <xsd:element <xsd:element

«0»/ > <xsd:element

«0»/ > <xsd:element

«0»/ >

name-«description» namea«state» type name=»dateLaMu» type = name=»userLaMu» type = name«»baseType» type = name-«xsdRestriction»

minOccurs

minOccurs

type — «xsd:string»/ > «xsd:string»/ > «xsd:dateTime»/ > «xsd:string»/ > «xsd:string»/ > type — «xsd:string» name-«language» type • «xsd:string»

name=»helplnfo» type = «xsd:string»

minOccurs =

</xsd:sequence» </xsd:extension»

</xsd:complexcontent»

</xsd:complexType»

<!- объявление ссылок на сложные элементы (для ENTITY определений) <xsd:complexType narae=»AppendixTypeTypeRef» >

<xsd:complexcontent»

<xsd:extension base=»iso29481p2a:elementTypeRef»/

</x sd:comp1e xCont ent > </xsd:complexType» <xsd:complexType name»»ComplexElementTypeTypeRef» >

<xsd:complexcontent»

<xsd:extension base=»iso29481p2a:elementTypeRef»/

</xsd:complexcontent»

</xsd:complexType»

<xsd:complexType name=»ElementConditionTypeRef» >

<xsd:complexcontent»

<xsd:extension base-«iso2948lp2a:elementTypeRef»/

</xsd:complexcontent»

</xsd:complexType»

<xsd:complexType name-«GroupTypeTypeRef» »

<xsd:complexcontent» <xsd:extension base=»iso29481p2a:elementTypeRef»/

</xsd:complexcontent»

</xsd:complexType»

<xsd:complexType name-«MessageInTransactionTypeTypeRef» >

<xsd:complexcontent»

<xsd:extension bases«iso29481p2a:elementTypeRef»/ > </xsd:complexcontent» </xsd:complexType» <xsd:complexType name-«MessageTypeTypeRef» >

<xsd:complexContent>

<xsd:extension basee«iso29481p2a:elementTypeRef»/ >

</xsd:complexContent>

</xsd:complexType> <xsd:complexType name=»OrganisationTypeTypeRef» >

<xsd:complexContent>

<xsd:extension basee«iso29481p2a:elementTypeRef»/ >

</xsd:complexContent>

</xsd:complexType> <xsd:complexType name=»PersonTypeTypeRef» >

<xsd:complexcontent> <xsd:extension base«»iso29481p2a:elementTypeRef»/ >

</xsd:complexContent>

</xsd:complexType> <xsd:complexType namee«₽rojectTypeTypeRef» >

<xsd:complexContent>

<xsd:extension base=»iso29401p2a:elementTypeRef»/ >

</xsd:complexContent>

</xsd:complexType> <xsd:complexType name«»RoleTypeTypeRef» >

<xsd;complexContent> <xsd:extension base=»iso29481p2a:elementTypeRef»/ >

</xsd:cornplexContent>

</xsd:complexType> <xsd:complexType name=»SimpleElementTypeTypeRef» >

<xsd:complexContent>

<xsd:extension base-«iso29481p2a:elementTypeRef»/ >

</xsd:complexContent>

</xsd:complexType> <xsd:complexType name=»TransactionPhaseTypeTypeRef» >

<xsd:complexcontent> <xsd:extension base=»iso29401p2a:elementTypeRef»/ >

</xsd:complexContent>

</xsd:complexType> <xsd:complexType nameB«TransactionTypeTypeRef» >

<xsd:complexContent> <xsd:extension base=»iso29481p2a:elementTypeRef»/ >

</xsd:complexContent>

</xsd:complexType> <xsd:complexType name=»UserDefinedTypeTypeRef» >

<xsd:complexcontent>

<xsd:extension basee«iso29481p2a:elementTypeRef»/ >

</xsd:complexContent>

</xsd:compiexType>

<!- группа объявлений (для SELECT определения типов данных) -•

<!- объявления типов перечислений {для ENUMERATION определения типов данных) —

<I- объявления простого типа (для TYPE заданных определений типов данных) —

<!- стандартные декларации, elementType, simpleType, logical (для каждой трансляции) —

<xsd:complexType name=»elementType» >

<xsd:attribute name=»id» type = «xsd:ID» use » «required»/ >

< /xsd: cornplexType>

<xsd:complexType name»»elementTypeRef» >

<xsd:attribute name=»idref» type = «xsd:IDREF» use = «required»/ > </xsd:complexType>

<xsd:simpleType name=»logical» > <xsd:restriction base=»xsd:string» >

<xsd:enumeration value«»true»/ >

<xsd:enumeration value-«false»/ >

<xsd:enumeration valuee«unknown»/ >

</xsd: restriction

</xsd:s impleType>

</xsd:schema>

A.4 Типы элемента

A.4.1 AppendixType

Атрибуты: id

Элементы: description. slartDate. endDate. state. dateLaMu. userLaMu. language, category, helpinfo, code Ссылки: comptexEtements

AppendixType содержит определение дополнения. Какие элементы данных должны записываться с помощью дополнения, можно указать в разделе составного элемента.

Пример —

<AppendixType id-«StandardAppendixType» >

<description>CTaHaapTHboi тип npwno»:eHMn</description> <startDate>2007-01-23T00:00:00Z</startDate> <endDate>2007-12-31T00:00:00Z</endDate>

<state>active</state>

<dateLaMu>2007-01-23T00:00:002</dateLaMu>

<userLaMu>bapa</userLaMu>

</AppendixType>

Примечание — Элемент appendixTypes. Ecm структура взаимодействия указывает много типов дополнений. пользователям может быть трудно выбрать подходящий тип дополнения. Эта ссылка позволяет выбирать из набора всех типов дополнений типы, действительные для конкретных транзакции или сообщения.

А.4.2 ComplexEtementType

Атрибуты: id

Элементы: description, slartDate. endDate. state. dateLaMu. userLaMu. language, category, helpinfo Ссылки: elements

ComplexElemenlType содержит набор SimpleElementTypes. Каждый заявленный тип SimpleElementType входит ровно столько раз. сколько он упоминается.

Пример —

«ComplexELementType id-«HenuItera» > <descript1оп>Пункт меню*/descript ion> <3tartDate>2007-01-23T00:00:002</startDate> <e.ndDate>2007-12-31T00:00:002</endDate> <state>active</state> <dateLaMu>2007-01-23T00:00:0OZ</dateLaMu> <userLaMu>bapa</usecLaMu>

«elements?

«SimpleElementTypeRef «SimpleElementTypeReC «SlmpleEiementTypeRef <SimpleElementTypeRer «/elements?

idre£-«Name»/ > 1агеС~»₽г1се*7 > ldrer-^Descrlption*’/ > idret-“Calorie3“/ >

</CotKplexELemencType>

А.4.3 Elementcondition

Атрибуты; id

Элементы: description. requiredNotify. minValue, maxValue, format, helpinfo

Ссылки: message, element

Условие SimpleElementType а том виде, как оно используется в конкретном MessageType.

Пример —

<Elerr>entConditlon ld-«Price restriction» >

<deseript 1оп>Миним&льная иена пункта uenKX/desc:ription>

«requiredNotify>D</requiredNotify>

<minValue>5.00</mlnValue>

<eletaent>

<SimpleElementType>UeH&</SimpleEleinentType>

</elernent>

<message>

<MessageTypeR*f idref~HProvideWithMenuMeasage»/ > </tnessage>

</EleE,.eneCondlti<>n>

A.4.4 GroupType

Атрибуты; id

Элементы; description, startDate. endDale. state. dateLaMu. userLaMu. language, category, helpinfo. Определение группы для сохранения дополнений, отправленных вместе с сообщением в транзакции.

Пример —

<GroupType id-«StandardGroupType» >

<descr1рс1оп>Стандар?ная rpynna</descrlptions <startDate>2007-12-20T00:00:00Z</startDate> <endDate>2008-12-31T00:00:00Z</endDate> <state>active</state>

<dateLaMu>2007-12-20T00:00:00Z</dateLaMu> <userLaMu>bapa</userLaMu>

</GroupType>

A.4.5 MessageType

Атрибуты; id

Элементы, description, startDate. endDate. state. dateLaMu. userLaMu. language, category, helpinfo, code Ссылки: complexEiements. appendixTypes

Определение типа сообщения (MessageType), которое указывает структуру сообщения и какой набор типа SimpleElementType (через ComptexElementType) оно может сопровождать.

Пример —

<МеззадеТуре id-^ProvideWithMenuMessage» > <description>Coo6eaeHKej содержащее меню.</description> <startDat*>2008-Ol-23TQ0:00:0OZ</startDate> <endDate>2008-12-31T00:00:00Z</endDate>

<state>actlve</state>

<dateLaMu>2008-01-23T00:00:002</dateLaMu> <userLaMu>bapa</userLaMu>

<coapiexEiements>

<CotnplexEl.ement.TypeRef idref-’ltenu»/ >

</coaplexElea®nts>

<appendlxTypes>

<AppendixTypeRef idref-’Menucard» / >

</appendixTypes> </MessageType>

Примечание — Элемент firstMessage. В общем случав транзакция будет запускаться лицом, выполняющим роль инициатора, с помощью типа сообщения, независимого от типа любого предыдущего сообщения. Однако этот принцип нельзя применять к транзакции, которая выполняется как подтранзакция 8 другой транзакции. Этот элемент явно заявляет, можно ли использовать тип сообщения для запуска новой транзакции.

А.4.6 MessagelnTransactionType

Атрибуты; id

Элементы: requiredNotify. dateLaMu. userLaMu. received, send, state. initiatorToExecutor. openSecondaryTrans actionsAllowed. firstMessage

Ссылки: message, previous. transaction. transacbonPhase. group, appendix Types

Образец типа MessageType 8 типе TransactionType. относящийся к конкретному типу группы (GroupType).

Пример —

«MessagelnTransactionType id»»MiTT_002*’ >

<requiredNoti£y»0</requiredNoti£y» <dateLaMu>20O8-Ol-23T0O:O0:00Z«/dateLaMu» «userLaMu»bapa«/userLaMu>

<received»true</received»

<send»true</send»

<state»actlve«/state» <initiatorToExecutor»faise</lnitiatorToExecutor> <openSecondaryTransactionsA31owed>true</openSecondaryTransactionsAllowed» <lir3tMe3sage>tdlee</firstMe38age>

«message»

«MesaageTypeRet idref-«ProvideWith»enuMessage~/ >

«/message»

«previous»

<MessageInTransactionTypeRe£ idrer-«MiTT_001»/ >

«/previous»

«transaction»

«TransactlonTypeRer idrer»»ObtalnMenuTransactlon*/ »

«/transaction»

«transactionPhase»

«TransactionPhaseTypeRef idref~»MenuDelivered~ »

«/transactionPhase»

«group»

«GroupTypeRef idre£«*StandardGroupType»/ >

«/group»

«append!хТурез»

«AppendixTypeRef ldrer«»»’Menucaxd’* / >

«/appendixTypes» «/MessagelnTransactionType»

A.4.7 OrganisationType

Атрибуты: td

Элементы: description. startDate. endDate. state. dateLaMu. userLaMu. language, category, helpinfo. code Ссылки: complexElements

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

Пример —

«OrganisationType id-”StandardOrganisationType» >

«descript1оп»Стандартный тип opi-aKH3auHH«/description> <startDate>2008-01-23TOO:QG:002</startDate> «endDate»2008-12-31T00:00:00Z«/endOate»

<state»active</state»

«dateLaMu>2008-01-23TOO:GG:0OZ</dateLaMu»

<userLaMu»bapa</userLaMu> «/OrganisationType»

A.4.8 PersonType

Атрибуты: id Элементы: description. startDate. endDate. state. dateLaMu. userLaMu. language, category, helpinfo, code Ссылки: complexElements

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

Пример —

«PersonType id-,’StandardPersonType» »

«description>CTaiutapTKMR тип физического Anua«/description» <3tartDate»200a-Gl-23T00:00:0GZ</startOate» <endOate»2008-12-31T0G:0O:00Z«/endOate»

<state»active</state»

«dateLat4u?2008-01-23ТОО:00:00Z«/daceLaMu?

«userLaMu?bapa«/user LaKu?

«/PersonType?

A.4.9 ProjectType Атрибуты; id Элементы: namespace, description. startDate. endDale. state. dateLaMu. userLaMu. language, category, helpinfo, code Ссылки: complexElements

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

Пример —

«ProjectType id»*Standard₽rojectType» > <namespace?http://www. ISO 294Bl_Part_2A.com/testproject«/namespace> «descript1оп?Стандартный тип npoeKTaK/description?

<startDate>20OB-Ol-23TO0:OO:0OZ</startDate> <endDate?2O0B-12-31T00:00:00Z</endDate> <state>actlve</state?

<dateLaMu>200B-OL-23TOO:00:O0Z«/dateLaMu>

<userLaKu>bapa</user LaMu>

«/Proj ectType ?

A.4.10 RoleType Атрибуты: id Элементы: description. startDate. endDate. state. dateLaMu, userLaMu. language, category, hefplnfo. code.

responsibilrtyFeedback. responstMityScope. responsibildySupportTask, responsibittyTask Определение конкретного типа роли.

Пример —

«RoleType id^walter» ? <Сезсг1рчоп?0гаеественньгй эа прием и раэме&ение saKasoec/description? <startDate?2008-05-04T00:00:00:00Z«/startDate? <endDate?2008-05-04T00:00:00.00Z«/endDate?

<state?actlve«/state? <dateLaMu?2008-05-04T00:00:00.00Z</dateLaMu> «user LaMu ?MMA«/user LaMu?

«language/?

«category/?

«helplnto/?

«code/?

«responsibilityScope/? «responsibilityTask/? «responsibilitySuppoztTask/? «responsibilityFeedback/?

«/RoleType?

A.4.11 SimpleElementType

Атрибуты: id

Элементы; description. intecfaceType. state. dateLaMu, userLaMu, language, category, belplnfo. valueUst Ссылки: composedOL userDefinedType

Определение типа простого элемента (SimpleElementType). Этот тип элемента указывает свойство, которое может встречаться в различных структурах объектов. HanpuMepeMessageType (см. также AppendixType. ProjectType. PersonType и OrganisationType). SimpleElementType всегда является вложенным в ComplexElementType.

Пример —

«SimpleElementType ld-^Kame» > <descrlptlon?HaSBaHne пункта ыенюк/description? «interfaceType/? <state?active«/state?

«dateLaMu?2008-01-23T00:00:0OZ«/dateLaMu? <userLaMu?bapac/userLaMu?

«userDefinedType? «UserDefinedTypeRef ldref»’,String’’/?

«/User DelinedType?

«/SimpleElementType?

А.4.12 TransactionPhaseType

Атрибуты, id

Элементы: description. startDate. endDate. state. dateLaMu, userLaMu. language, category, helpinfo, code Thedeftnitionofaphasereiated toatransaction. Примеры: «назначение принято» или «часть результата получена».

Пример —

«TransactionPhaseType id»»WaitingForMenu» *

«deset 1рИоп*Мемй запрошено, но еще не 4ocra&neHO</descrlption* <3tartDate*2008*-01-23T00:00:002</startOate*

<endOate*2008-12-31T0d:00:002</endDate> <state*active«/state*

<dateLaMu>2008-01-23TOO:00:002</dateLaMu>

<userLaMu>bapa</userLaMu>

«/Transact i л.seType*

A.4.13 Transact ionType

Атрибуты: id

Элементы: description. startDate. endDate. state. dateLaMu. userLaMu, language, category, helpinfo. code, result Ссылки: initiator, executor, subTransactions

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

Пример —

«TransactionType id-’,MenuObtainingTransaction** >

«descript1оп*Транзакции для получения нужого ыенй«/безсг1р11оп* <startDate>2008-01-23T00:00:002</startOate>

<endDate*2aO8-12-31TOO:00:002</end0ate*

<state*active«/state* <dateLaMu*2008-01-23TOO:O0:0OZ«/dateLaMu* <userLaMu*bapa«/userLdMu*

«initiator*

«RoleTypeRef ldrer-‘’Заказчик*/ >

«/initiator*

«executor*

«RoleTypeRef 1Дге£-“,Соерудник»/ *

«/executor* «/TransactionType*

A.4.14 UserDefinedType

Атрибуты: #id

Элементы: description, state. dateLaMu. userLaMu. baseType. xsdRestriclton. language, helpinfo

Спецификация типа данных (для использования в SimpleElemenlType). Этот тип данных инкапсулирует заполняемые области в конечном сообщении.

Пример —

«UserDefinedType id-HString** >

«descr1р11оп*Стандартная CTpoxa«/description*

<state*active«/state* <dateLdMu*2001-12-20TOO:00:OOZ«/dateLaMu* <userLaMu*bapa</usetLaMu>

<baseType*STRING</baseType*

«xsdRestriction/* «/UserDefinedType*

A.5 Атрибуты

A.5.1 id

Уникальное «краткое» имя образца. После продвижения это имя будет именем объекта.

Пример —

Объект структуры

«OrganisationType id-«TNO Building and Construction** *

«descr1рт1оп>Атрибуты органкзаиик«/йезсгiption*

<startOate>2007-12-12T00:00:002«/startDate> «endDate*9999-12~31TOO:00:OOZ«/endDate*

<stdte>active</state>

<dateLaMu>2007-12-12T00:00:00Z</dateLaKu>

<userLaMu>test(OAnage(nent</userLaMu>

<ienguage>NL</languages

ccacegory>S</category>

<helplnfoshttp://…/</help!nfo>

<code>DEFAULT</codes

</OrganisatlonTypes

Message object

«nawesTNO Building & Construction</naoe>

<statesactive</state> <dateLaMu>2007-12-02T00:00:00Z</dateLaMu>

<userLaMuSFecer Bonsna</userLaKu>

«/organisations

A.6 Элементы

A.6.1 baseType

Содержит базовый тип типа SimpleElementType.

Пример —

<SiwpieEieraentrype id-«Height» >

cusec DeiinedT ype >

«UserDetinedType id-«…» >

< bas eTypesINTEGER*/bas eTypes

«/UserDefi.nedTypes

«/User DeiinedTypes

c/SimpleBiementTypes

Здесь Height в типе SimpleEtementType всегда содержит целое число (возможно, с ограничением; xsdRestriction).

А.6.2 category

Категория, связанная с этим объектом (необязательное значение).

А.6.3 code

Согласованный код структуры взаимодействия для этого объекта.

Пример —

<… id-«.. .* >

ЕЛИ 33156

</…>

А.6.4 dateLaMu

Дата и время последнего изменения этого объекта.

Пример —

<… id-«…» >

<dateLaMu>2007-12-02T00:00:00Z«/dateLaMu>

</…>

A.6.5 description

Описание объекта.

Пример —

«… id«»Ooorleat» >

«descriptionsCeaoptca плоской двери.«/descriptions

</…>

А.6.6 endDate

Дата и время окончания срока действия этого объекта.

Пример —

<… Id-«…» > <endOate*2007-02-03T0O:00:C>0Z</en<lDate>

</…*

А.6.7 firstMessage

Необязательное Булево значение, показывающее, разрешается ли использовать этот объект типа

MessagelnTransaclionType как стартовое сообщение для новой транзакции. Значение по умолчанию — false.

Пример —

«HessagelnTransactionType Id-«…» >

«firs tMessage>true</first Message*

«/MessagelnTransactlonType*

A.6.8 format

Разметка элемента (необязательная).

A.6.9 helpinfo

URL-адрес или URI-код ссылки на дополнительную информацию об этом объекте.

Пример —

«… id-«.>

«helpInfo*http://www.ISO 29481_Part_2A.com/helpInfo_obJect0001.html «/helplnfo*

</…>

A.6.10 initiatorToExecutor

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

Пример —

«HessagelnTransactionType id-«…” >

<initiatorToExecutor*false«/initiatorToExecutor*

«message*

«MessageType id-‘*TenderAcceptance» >

«/MessageType*

«/message*

«transaction*

«TransactionType ld-^TenderTraject» *

«initiator*

«RoleType id-«Per£ormer» >

«/RoleType*

«/initiator*

«executor*

«RoleType id-«Client” *

«/RoleType*

«/executor*

«/TransactionType*

«/transaction*

«HessagelnTransactionType id-”…» *

Предполагается, что сообщение TenderAcceptance будет отправлено от клиента (исполнитель транзакции) исполнителю работ (инициатор).

А.6.11 interfaceType

Интерфейс типа или представление этого SimpleElementType для конкретного сообщения.

А.6.12 language

Язык для использования после продвижения объекта.

Пример —

<… id-«..>

<language>NL</language>

</…>

А.6.13 namespace

Имя целевого пространства имен для идентификации сообщений, принадлежащих этой структуре взаимодействия.

Пример —

<ProjectType id-«…» ?

<nas>espace>htt.p://www. visi.nl/teatraamxer!«/naa>espace>

</₽roJectType>

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

А.6.14 openSecondaryTransactlonsAllowed

Необязательное логическое значение, которое позволяет продолжить основную транзакцию, даже если завершены не все подчиненные транзакции. Значение TRUE интерпретируется как сигнал, разрешающий продолжение (шлюз OR). Значение FALSE интерпретируется как сигнал, запрещающий продолжение, пока не будут завершены все подчиненные транзакции (шлюз AND). Если элемент openSecondaryTransactionsAllowed не указан, его значение интерпретируется как TRUE.

А.6.15 received

Логическое значение, показывающее, что предыдущее сообщение получено.

А.6.16 requiredNotify

С этим элементом не связана никакая семантика.

А.6.17 responsibilityFeedback

Ожидаемая обратная связь в направлении к другим ролям (необязательная строка).

А.6.18 responsibilityscope

Область дейсгвия/рамки определенных отношений ответственности роли (необязательная строка).

А.6.19 responsibilrtySupportTask

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

А.6.20 responsibilityTask

Задачи, возникающие из-за отношений ответственности данной роли (необязательная строка).

А.6.21 result

Ожидаемый результат выполнения транзакции.

A.6.22send

Логическое значение, показывающее, было ли отправлено сообщение.

А.6.23 startDate

Дата и время начала срока действия объекта.

Пример —

<… id-«.>

<StartDate>2007-02-03TO0:00:O02</startDate>

</…>

А.6.24 state

Состояние видимости объекта, возможные значения;

Пример —

<… id-«…» >

<state>active</state»

</…»

и

<… id-«.. >

<state»passive</state»

</…»

А.6.25 userLaMu

Пользователь послщнето изменения объекта.

Пример —

<… id-”…» >

<userLdMu»Peter Bonsma</userLaMu»

</…»

А.6.26 valueList

Разделяемый то«ой с запятой список значений, которые может принимать образец на уровне сообщения. Исходно этот элемент предназначался для поддержки перечислений. Сейчас эго реализуется с помощью типа элемента UserDefviedType и элемента xsdReslncbon. Значения перечисления задаются 8 xsdReslriction. С этим элементом больше не связывается никакая семантика.

Пример —

<SimpleElementType id-”…” >

<valueLlst»Groen;Rood;Oker GeeK/valueLlst»

</Simple£lementType>

A.6.27 xsdRestriction

Этот элемент указывает ограничение, которое будет выполняться на уровне сообщения в тиле SimpleElemenlType этого типа UserDefinedType.

А.7 Ссылки

А.7.1 appendixTypes

Набор доступных для выбора типов дополнения.

А.7.2 complexElements

Ссылка на набор типов SimpteElecnentType {ообрашых a ComplexElementType).

Пример —

<… ld-’Abc” >

«complexElements»

<CoaplexEleo>entType ld»»Elew>entsSetl*■ >

«elements»

«SimpleElementType id-«Element_A” >

«/SimpleElementType»

«SimpleElementType id-HElement_B” >

«/SimpleElementType»

«/elements»

«/ComplexElementType» «ComplexElementType id-”ElementsSet2” >

«/ComplexElementType»

«ComplexElementType id-«ELementsSet3” >

«/ComplexElementType»

«/comp1exElemen ts»

«/…»

На уровне сообщения это конкретизируется в:

«Abe id-«>

«eletnentsSetl»

«ElementsSetl»

<Element_A»…</Element_A»

<Element_B>…</Element_B>

«/ElementsSetl»

«ElementsSetl»

<Element_A>…</Element_A»

<Element_B»…«/Element_B»

«/ElementsSetl»

c/elementsSetl»

<eleraentsSet2»

«ElementsSet2>

</ElementsSet2>

<ElementsSet2»

«/Eleme.ntsSet2»

<ZelementsSet2»

«elemencsSet3»

<ElementsSet3>

«/ElementsSet3»

<ElementsSet3>

</ElementsSet3>

c/elementsSet3»

«/…»

A.7.3 cocnposedOf

Тил SimpleElementType может состоять из набора типов SimpleElementType (собранных в тиле ComplexElementType).

Пример —

«SimpleElementType id-«Doorleaf» »

«composedOf»

«ComplexElementType id^’Messurement» >

«elements»

«SimpleElementType id~~Hei<jht~ »

«/SimpleElementType»

«SimpleElementType id-^Width* »

«/SimpleElementType»

«SimpleElementType id«wThickness» »

«/SimpleElementType»

«/elements»

«/ComplexElementType»

«ComplexElementType id~“Material-selection» »

«elements»

«SimpleElementType id-«Type-of-wood” >

«/SimpleElementType»

«/elements»

«/CoeiplexElementType»

«/composedOC»

«/SimpleElementType»

На уровне сообщения эго конкретизируется в:

«Doorleaf»

«Measurement id»»___“ >

«Height»___«/Height»

«Width»…«/Width»

«Thickness»___«/Thickness»

«/Measurement»

«Material-selection id-«…* »

«Туре-of-wood»…</Type-of-wood>

«/Material-selection»

«/Doorleaf»

A.7.4 element

Состояние для типа SimpleEtementType. который будет использоваться в тиле MessageType.

Пример —

«Elementcondition id-«…” >

<minValue>2000«/minValue»

«element»

«SimpleElementTypeRef idref-”Doorhelght~ >

«/element»

«message»

«MessageType id-”M~ >

«complexEiements»

«ComplexElemen tType»

«elements»

«SiapieElementType id-“Dooxheight” »

«/SimpleElementType»

«/elements»

«/ComplexElementType»

«/complexEiements»

«/MessageType»

«/message»

«/Elementcondition»

В этом примере показано, что в типе MessageType со значением М объект Doorhetght должен иметь значение не меньше 2000. хотя это не применяется на уровне тина SimpleEtementType.

А.7.5 elements

Набор типов SimpleEtementType. доступный внутри типа ComplexEtemectlType.

Пример —

«ComplexElementType id-”Door» >

«elements»

«SimpleElementType ld-”Doarleaf” »

«/SimpleElementType»

«SimpleElementType id-”Fastenings” »

«/SimpleElementType*

«SimpleElementType id-«UpperWindow» *

«/SimpleElementType*

«/elements*

«/CocipiexEleoentType

На уровне сообщения это конкретизируется в:

«… id-«…» >

«door*

«Door*

«OoorleaC*…«/Doorleaf*

«Fastenings*…«/Fastenings*

«UpperWindow*…«/UpperWindow*

«/Door*

«door*

«Doorleaf*…«/Doorleaf*

«Fastenings*…«/Fastenings* «UpperWindow*…«/UpperWindow* «/Door*

«/door*

«/…*

Обязательным является то. что все элементы точно указываются только один раз. У этих дверей всегда имеется верхнее окно. Число дверей не ограничено.

А.7.6 executor

Роль исполняющий’ (RoleType). связанная с конкретной транзакцией.

Пример —

«TransactionType id-«TenderTraject» *

«executor*

«RoleType id-«Client” >

«/RoleType*

«/executor*

«/TransactionType*

A.7.7 group

Тил GroupType. связанный с сообщением в пределах конкретной транзакции.

Пример —

«MessageZnTransactionType id-«___» >

«message*

«МеззадеТуре id-«M» >

«/МеззадеТуре*

«/message*

«group*

«GroupType id-«G» >

«/GroupType*

«/group*

«transaction*

«TransactionType id-«T» *

«/TransactionType*

«/transaction*

«/MessageInTransactionType*

Сообщение М в транзакции Т принадлежит к группе G (может существовать несколько сообщений М в транзакции Т. принадлежащих к той же самой или другой группе).

А.7.8 Initiator

Роль ‘инициирующий’ (RoleType). принадлежащая к конкретной транзакции.

Пример —

«TransactionType id»»TenderTraject» >

«initiator?

«RoleType ld-«Performer» ?

«/RoleType?

«/initiator?

«/Т ra nsactiопТуре>

A.7.9 message

Сообщение в MessagelnTransadionType.

Пример —

«MessageTnTransactionType id»»___» >

«message?

«MessageType id-«___» ?

«/MessageType?

«/message?

«/MessagelnTransactionType

A.7.10 previous

Тип MessagelnTransadionType может обеспечивать принудительное выполнение предыдущего сообщения в конкретной транзакции (этот предыдущий тип MessagelnTransadionType не должен принадлежать к тому же самому типу TransactionType).

Пример —

«MessagelnTransactionType id»HH >

«previous?

«MessagelnTransactionType id»»…» ?

«message?

«MessageType id»»Tender» >

«/MessageType?

«/message?

«/MessagelnTransactionType?

«/previous?

«message?

«MessageType id»»TenderAcceptance» ?

«/MessageType?

«/message?

</MessageinTransactionType?8ubTransactions

Транзакции, которые могут выполняться в данной транзакции.

Пример —

«TransactionType id»»AcquireWork” ?

«eubTransactions?

«TransactionType id»»AcquisitionTrack» ?

</TransactionType>

«TransactionType Id-^TenderTrack» >

</TransactionType>

</subTransactlons>

</TransactionType>

TnoTransacbonType co значением AcquireWorkcoctovn из типовТгаггеасбопТуре co значениями AcquisibonTrack и TemferTraject.

A.7.11 simpleElements

Набор простых типов элементов, принадлежащих к дажому сложному типу элементов.

Пример —

«CocnplexElementType id-«Docr~ >

<sitnpleEletnents>

«SimpleElementType id~»Doorleaf» >

</Slmple£lementType>

«SirapleElementType ld-”HingesAndLocks» >

</SinpleEleinentType>

«SimpleElementType id-«UpperWindow» >

</Simple£lementType>

</slmpleElements>

</CoenpiexEleoentType>

На уровне сообщения это мош привести к следующему результату.

с… id-«..>

<door>

<Door>

«DoorleaO…«/DoorleaO

« HingesAndLocks >…</ HingesAndLocks >

  • < Upperwindow >…«/ Upperwindow >

</Door>

<Door>

  • < Doorleat >…<? Doorleat >

« HingesAndLocks >…</ HingesAndLocks >

  • < Upperwindow >…</ UpperWindow >

</Door>

</door>

</…>

A.7.12 subTransactions

Транзакции, которые могут быть запущены из данной транзакции.

Пример —

«TransactlonType ld-«AcqulsitlonO£Work» >

<subTransactions>

«TransactlonType id-“AcquieitionTraject*’ >

«/TransactlonType»

«TransactlonType ld-«TenderTraject» >

«/TransactlonType»

«/subTransactions»

«/TransactlonType»

А.7.13 transaction

Транзакция в типе MessageinTransactionType.

Пример —

«MessageinTransactionType id»»…» »

«transaction»

«TransactionType id»’*…»‘ >

«/TransactionType»

«/transaction»

«/MessageinTransactionType»

A.7.14 transactionPhase

Объект TransactionPhase для комгретного типа MessageType а конкретном типе TransactionType.

Пример —

«MessageinTransactionType id»»…” >

«message»

«MessageType id-»М” >

«/MessageType»

«/message»

«transaction»

«TransactionType id»”T» »

«/TransactionType»

«/transaction»

«transactionPhase»

«TransaccionPhaseType id»»TP» »

«/TransactionPhaeeType»

«/transactionPhase»

«/MessageinTransactionType»

Где тип MessageType. имеющий значение M внутри конкретного типа TransactionType. имеющего значение Т, определяет тип TransactionPhaseType. имеющий значение ТР.

А.7.15 userDefinedType

Ссылка на тип UserDefinedType. который задает формат типа SimpleElementType.

Пример —

«SirnpleEleraentType id»»Height» »

«userDefinedType»

«UserDefinedType id»»…» >

«baseType»iHTEGERc/baseType»

«/UserDefinedType»

«/UserDefinedType» «/SimpleElementType»

Тип SimpleElementType Height задает формат Integer для каждого образца (возможно, с ограничением в виде xsdRestriction).

Приложение В

(обязательное)

Определение шаблонов

В.1 Введение

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

В.2 Определение шаблонов1*

SCHEMA ISO 29481_Part_2B;

ENTITY GroupTemplate:

name: STRING;

description: STRING:

cneationDate: DATETIME:

startDate: DATETIME;

endDate: DATETIME:

state: STRING;

dateLaMu: DATETIME:

userLaMu; STRING;

versionNo: STRING;

transaction: Transaction Template:

END. ENTITY;

ENTITY AppendixGroup;

state: STRING:

dateLaMu: DATETIME;

userLaMu: STRING:

group: GroupTemplate:

END. ENTITY;

ENTITY AppendixTemplate;

name: STRING;

fileLocation: STRING;

fileType: STRING;

fileVersion: STRING:

documentldentification; STRING;

documentversion; STRING: documentReference: STRING; objectCode: OPTIONAL STRING; startDate: DATETIME;

endDate: DATETIME;

state: STRING:

dateLaMu: DATETIME;

userLaMu: STRING;

language: OPTIONAL STRING;

message: MessageTemptate: appendixGroup: AppendixGroup;

template: ComplexElementTemplate:

END.ENTITY;

ENTITY MessageTemptate:

identification: STRING;

dateSend: DATETIME;

dateRead: DATETIME;

state: STRING:

dateLaMu: DATETIME;

userLaMu: STRING;

initiatingTransactionMessagelD: OPTIONAL STRING: initiatorToExecutor; BOOLEAN;

1> В настоящем стандарте приводится определение шаблоне», представленное в ИСО 29481-2.

messagelnTransaction: MessagelnTransactionTemplate; transaction: TransactionTemplate.

template: ComplexElemenlTemplate; END.ENTITY;

ENTITY MessagelnTransactionTemplate; identification: STRING: dateSend: DATETIME: dateRead: DATETIME;

state: STRING;

dateLaMu: DATETIME; userLaMu: STRING; END.ENTITY;

ENTITY TransactionTemplate; number: INTEGER;

name: STRING: description: STRING; startDate: DATETIME; endDate: DATETIME; state: STRING;

dateLaMu: DATETIME; userLaMu: STRING; result OPTIONAL STRING; initiator: PersonlnRole; executor: PersonlnRole; project: ProjectTypelnstance; END.ENTITY;

ENTITY TransactionPhaseTemplate; name: STRING;

description: STRING; dateReached: DATETIME; state: STRING;

dateLaMu: DATETIME; userLaMu: STRING; transaction: TransactionTemplate; END_ENT1TY: ENTITY PersonTemplate; userName: STRING;

name: STRING; state: STRING;

dateLaMu: DATETIME. userLaMu: STRING; template: ComplexElementTemplate; END.ENTITY: ENTITY OrganisationTemplate; name: STRING;

abbreviation: STRING;

state: STRING;

dateLaMu: DATETIME; userLaMu: STRING; contactperson: PersonTemplate; template: ComplexElemenlTemplate; END.ENTITY:

ENTITY PersonlnRole; stale: STRING;

dateLaMu: DATETIME; userLaMu: STRING: successor: OPTIONAL PersonlnRole; substituting: OPTIONAL PersonlnRole; contactperson: PersonTemplate; organization: OrganisationTemplate; role: RoieTemplate;

END.ENTITY:

ENTITY RoleTemplate;

name; STRING;

description: STRING;

slate: STRING;

datelaMu: DATETIME;

userLaMu: STRING;

category: OPTIONAL STRING;

END.ENTITY:

ENTITY ProjectTypelnstance;

name: STRING;

description: STRING;

startDate: DATETIME;

endDate: DATETIME;

state: STRING;

datelaMu: DATETIME;

userLaMu: STRING;

template: ComptexElementTemplate;

END.ENTITY;

ENTITY ComplexEtementTemplate;

template: SimpleElementVirtual;

END.ENTITY; END.SCHEMA;

8.3 Шаблоны

B.3.1 AppendixGroup

Атрибуты: id

Элементы: state. datelaMu. userLaMu

Ссылки: group

Таблица отображения для отношений n:m между дополнениями и группами

Пример — на уровне сообщения:

<AppendixGioup id-«AppendixGroup_l» >

<state>act Lve</state?

<dateLaMu>2DO6-02-O4T00 rOOt00Z<ZdateLaMu> <userLaKu>bapa</usez LaNu>

<gtOup>

<StandardGroupType id-«…» >

</StandatdGroupType>

</group>

</Арре nd i xGroup>

Ассоциированная часть структуры взаимодействия:

<GroupType ld-~StandardGroupType» >

cdescr 1рь1.оп>Стандартная rpynna</descrlotion? <startDate>2D07-12-2DT00:00:DDZ</startDate> <endDate?2DOB-12-31TOO:OD:OOZ</endDate?

<state?active</state? <daceLaMu>20D7-12-20TOD:00:ODZ</dateLaMu? <userLaMu?bapa</userLaKu?

</GroupType?

8.3.2 AppendixTemplate

Атрибуты: id

Элементы; name. fiieLocation. fileType, fileVersion. documenUdentification. documentversion. documentReference. objectCode. startDate. endDate. slate. dateLaMu. userLaMu. language

Ссылки: appendixGroup. message Регистрация присоединенных файлов.

Пример — на уровне сообщения:

<Appendix ld-^ExaspieDocuoent» >

<natne?Voorbeeld</nane? <nieLoeation?\\srv-bouw\₽ublic\project\does\t4Sword\</!ileLoeat ion?

<flleType»application/msword«/fileType»

<flleVersion»2007«/flleVersion»

<docufnentldentiticatlon»345899</document Identification»

«documentversion»l«/documentVersion»

<documentReCerence»FG783990«/documentReCerence>

<startDate»2008-02-04TOO:00:002«/startDate»

<endOate»2008-12-31T00:00:002</endDate>

<state»active«/state»

<dateLaMu»2008-02-04TOO:00:OOZ«/dateLaMu»

<userLaMu»bapa</userLaMu>

<languaqe»EN</language»

«appendixGroup»

«AppendixGroup id-«___» »

«/AppendixGroup»

«/AppendixGroup»

«/Appendix»

Ассоциированная часть структуры взаимодействия:

<deaceiption»CTaHsapTHOe определение приложения (без определенных пользователей полей да иных*/descr1р t ion»

<startOate>2008-02-04T00:00:002</startDate>

«endDate»2008-12-31TOO:00:002«/endDate>

<state>active«/state»

<dateLaMu»2008-02-04TOO:00:002«/dateLaMu»

<userbaMu»bapa«/userLaMu»

<languaqe»NL</language»

«/Append ixType»

В.3.3 ComplexEiementTemplate

Атрибуты: id

В.3.4 GroupTemplate

Атрибуты: id

Элементы: name, description. creationDate, slartDate. endDate. state. dateLaMu. userLaMu. versionNo Ссылки: transaction

Группирование дополнений сообщения для восстановления ассоциированных документов.

Пример — на уровне сообщения:

«StandardGroupType id-“MenuBackgrounds» »

<name»Menu ₽ictures«/name>

<description»Ha6op фоновых картинок для оформления MeHD«/description» <creationDate»2008-02-04T00:00:002</creation0ate» <startDate>2G08-02-O4T00:OO:O0Z</startDate» <endOate»2008-12-31T00:00:00Z«/endDate»

<state»«/state>

«dateLaHu»2008-02-04TOO:00:002</dateLaMu>

<userLaMu»bapa</userLaMu>

<versionNo»l</versionNO»

«transaction»

«MenuObtainingTransaction id-«___» »

«/MenuObtainingTransaction»

«/transaction»

«/StandardGroupType»

Ассоциированная часть структуры взаимодействия:

«GroupType id-«StandardGtoupType» »

«descr1рг1оп»Стандартная rpynna«/description»

<startOate»200?-12-2OT00:O0:00Z</startOate»

<endDate»2008-12-31T00:00:002«/endOate>

<state»active«/state»

«dateLaMu>2007-12-20TOO:00:002</dateLaMu>

<userLaMu»bapa«/userLaMu»

«/GroupType» «TransactionType id-«MenuObtalnlngTransactlon» >

«descr1р^оп»Транзакция для получения соответствующего ыенкх/descrlotion» «starcDate>2DDB-Dl-23TDD:00:DDZ</startDate>

«endDate»2DOB-12-31TDO:OD:OOZ«/endDate»

«state>active</state>

«daceLaMu>200B-01-23TOD:00:ODZ«/dateLaMu>

«userLaMu»bapa«/userLaMu>

«initiator»

«RoieTypeRef idref-«Consumer»/ >

«/initiator»

«executor»

«RoieTypeRef idref-‘Сотрудник»/ >

«/executor» «/TransactionType»

8.3.5 MessagelnTransactionTemplate

Атрибуты: id

Элементы: tdentification. dateSend. dateRead. slate. dateLaMu, userLaMu. initiatorToExecutor

Содержит фактическое значение MessagelnTransactionType в сообщении для извлечения состояния рабочего процесса транзакции.

0.3.6 Message Template

Атрибуты: id

Элементы: identification. dateSend. dateRead. state. dateLaMu. usertaMu, initiatingTransacbonMessagelD. initiatorToExecutor

Ссылки: transaction. messagelnTransaction. template

Экземпляр типа MessageType. Эта сущность осуществляет фактический обмен информацией между объектами Organisation Template (организациями).

Пример — на уровне сообщения:

«HandOutOCMenuMessage id-«a002~ >

<identification»id а002</identification» <dateSend»2008-01-23T00:00:00Z«/dateSend» «dateRead»2008-01-23T00:00:00Z</dateRead» <state»active«/state»

<dateLaMu»2008-01-23T00:00:00Z«/dateLaMu»

<userLaMu»bapa«/userLaMu> <initiatingTransactionMessageID»a009«/initiatingTransacticnMessageZD» «initiatorToExecutor>false</initiatorToExecutor»

«messagelnTransaction»

<MessageZnTransactionl2Ref idref-«BlT001″/ >

«/messagelnTransaction»

«transaction»

«MenuObtainingTransaction id-«___» »

«/MenuObtainingTransaction»

«/transaction»

«menu»

«Menu id-«…» »

«/Menu»

«Menu id-«…» »

«/Menu»

«/menu»

«/HandOutOCMenuMessage»

Ассоциированная часть структуры взаимодействия:

«TransactlonType id-^MenuObtainingTransaction» »

«description»TpaHsaKuuA для получения соответствукхаего менкх/description» <startbate»2008-01-23T00:00:00Z</startOate»

<endDate»2008-12-31TO():00:002</endDate>

<3tate»active«/state»

<dateLaMu>2O08-01-23TO0:00:OOZ«/dateLaMu»

<userLaMu»bapa«/userLaMu»

«initiator»

«RoieTypeRef idre£»»Consumer»/ >

«/initiator»

«executor»

«RoieTypeRef idref-‘Сотрудник»/ >

«/executor»

«/TransactionType» «MessageType id-«Hand0ut0fMenuMe3sage” >

<description»Coo6tueHuel содержащее меню.«/description» <startDate»2008-Ql-23TOQ:00:QOZ«/startDate> <endDaie»200a-12-31T00:00:00Z</endOate»

<state»active«/state»

<dateLaMu»2008-01-23TOO:00:00Z«/dateLaMu>

«userLaMu»bapa«/userLaMu»

«complexElements»

«CotsplexEle»entTypeRe£ idre£-«Menu»/ >

«/complexElements»

«/MessageType»

«ComplexElementType id»»Menu» >

<description»flocTynHbie пункты ыенкк/description»

<startDate»20O8-01-23TO0:00:00Z«/startOate»

<endOate»2008-12-31T00:00:00Z«/endDate»

<state»active</state»

<dateLaMu>2008-01-23TOO:00:00Z«/dateLaMu>

«userLaMu»bapa«/userLaMu>

«elements»

«SimpieElementTypeRef idre£-«MenuIteas»/ »

«/elements» «/CompiexElementType»

B.3.7 OrganisationTemplate

Атрибуты, id

Элементы: name, abbreviation, state. dateLaMu. usertaMu

Ссылки: contactPerson. template Организация, участвующая в проекте по инициализации или исполнению Transaction Template (транзакции).

Пример — на уровне сообщения:

«StandardOrganisationType id-«TNO“ >

<name»Netherlands organisation for Applied Scientific Research«name» <abbreviation»TNO«/abbreviation> <state»active«/state»

<dateLaMu»2008-01-23TOO:00:0OZ</dateLaMu>

<userLaMu»bapa«/userLaMu»

«contactPerson»

«StandardPersonType id-«___» »

«/StandardPersonType»

«/contactPerson»

«/StandardOrganisationType»

Ассоциированная часть структуры взаимодействия:

«PersonType id-«StandardPersonType» »

«descript1оп»Тил стандартного участника npouecca«/description> <startDate>2008-Gl-23T00:00:O0Z</startOate» <endOate»2O08-12-31T00:0O:00Z«/endDate»

<state»active</state»

<dateLaMu>2008-01-23TOO:00:0OZ«/dateLaMu>

«userLaMu>bapa</userLaMu>

«/PersonType? «OrganlsationType id’^tandardOrganisationType» ?

«description?THn стандартного подразделениж/description? «startDate>20OB-01-23T00:O0:0OZ«/startDate? «endDate>2O08-12-31T00:O0:00Z«/endDate?

<state>active«/state> «dateLaMu?2008-01-23T00:0D:00Z«/dateLaKu? «userLaMu?bapa</userLaMu>

«/OrganlsationType?

B.3.8 PersonlnRole

Атрибуты: id

Элементы: stale. dateLaMu, usertaMu

Ссылки: organization, contaclPerson. role, substituting, successor Пользователь, выполняющий определенную роль для некоторой организации.

Пример — на уровне сообщения:

«PersonlnRole ld-^JohnAsCustower» >

<state?active</state?

«dateLaMu?2DOB-01-23TOO:00:00Z</dateLaMu> «userLaMu>bapa«/userLaMu>

«contactperson?

«StandardPersonType id»»…» ?

«/StandardPersonType?

</con tact Pe r son >

«organisation?

«StandardOrganisationType id»»…» >

«/StandardOrganisationType?

«/organisation?

«role?

«Consumer idref»»…» >

«/Consumer?

«/role?

«/PersonlnRole?

Ассоциированная часть структуры взаимодействия:

«PersonType id»»StandardPersonType’’ ?

«descr1рс1оп?Тип стандартного участника npouecca«/description? «startDate>200B-Ol-23T00:O0:0OZ«/startDate? «endDate>2O0B-12-31T00:O0:00Z«/endDate?

«state?active«/state? «dateLaMu?2008-01-23T00:0D:00Z«/dateLaKu? «userLaMu?bapa</userLaMu?

«/PersonType?

«OrganlsationType id’^StandardOrganisationType» ?

«description?Tun стандартного подразделениж/description? «startDate>20OB-01-23T00:O0:0OZ</starLD8te? <endDate?2O06-12-31T00:00:OOZt/endDate?

<state?active«/state? «dateLaMu?20O8-01-23T00:OO:0OZ«/dateLaMu> <userLaMu?bapa</userLaMu?

«/OrganlsationType?

«RoleType id-^Consumer» ?

«description>noTpeOMTe/ib«/description? «startOate>200B-01-23T00:00:00Z«/startDate? «endDate?2O08-12-31T0O:00:0OZ«/endDate? <state>active«/state>

<dateLaMu>2008-01-23Т00:00:OOZ</dateLaMu>

<userLaMu>bapa</usecLaMu> </RoleType>

В.3.9 PersonTemplate

Атрибуты. id

Элементы: userName. name, state. dateLaMu. userLaMu

Лицо, участвующее в проекте путем выполнения некоторой роли или как контактное лицо в конкретной организации.

Пример — на уровне сообщения:

(StandardPersonType £d-»PBonstnA’ >

<userName>bapa<userName>

<name>Peter Bonsma<name>

<state>active</state>

<dateLaMu>2008-02-04700:00:OOZ</dateLaMu>

<userLaMu>bapa</userLaMu>

«/StandardPersonType»

Ассоциированная часть структуры взаимодействия:

(PersonType id*»’rStandaxdPersonType*r >

<description>Tn.n стандартного участника npouecca</description> <StartDate>2008-01-23TOO:00:002</startDate> <endDate>2008-12-31T00:00:00Z</endDate>

<state>active</state>

<dateLaMu»2008-01-23T00:00:00Z</dateLaMu>

«userLaHu»bapa</userLaMu»

«/PersonType»

B.3.10 ProjectTemplate

Атрибуты: id

Элементы: name, description. slartDate. endDate. state. dateLaMu. userLaMu Проект, который должен соответствовать этой структуре.

Пример — на уровне сообщения:

«StandardProjectType Ld»*ICM2* >

<name»The project IDM2</name>

«descript£оп>Формализаци« систематики IDM2<7description <startDate»2008-02-04T00:00:00Z«/startDate> «endDate>2008-12-31T00:00:00Z</endDate>

<state»active</state>

<dateLaMu>2O08-02-04T0O:00:0OZ«/dateLaMu>

<userLaMu»bapa</userLaMu»

«/StandardProjectType»

Ассоциированная часть структуры взаимодействия:

<ProjectType id»’,StandaxdPxojectType» >

<description>Tnn стандартного npoeKTa«/description> <startDate»20O8-02-04T00:0O:00Z</startDate> <endDate»2008-12-31T00:00:00Z«/endDate>

<state»active</state»

«da teLaMu»2008-02-04TOO:00:00Z(/dateLaMu»

<userLaMu»bapa</userLaMu> «/ProjectType»

B.3.11 RoleTemplate

Атрибуты: id

Элементы: name, description, state. dateLaMu. userLaMu. category

Роль, выполняемая от имени организации пользователем PersonTemplate (лицом).

Пример — на уровне сообщения.

(Consumer id-^Customer» >

<name»Role as customer«/name>

(descript£оп»Роль ь качестве xmeHTa</description>

<state>active«/state>

da teLaMu»2OO8-01-23T00:00:002</dateLaMu»

(userLeMu>bape</userLaMu>

</Consu»er>

Ассоциированная часть структуры взаимодействия.

<RoieType id-^Consutner» >

<descr1рс1ол>Потре0мтель</Девсгlptlon> <starLDate>20DB-Dl-23T0D:DO:DDZ</starLDate> <endDete>20063-12-31T00:00:00Z</endDete> <scate>active</state>

<dateLaMu>20D8-Dl-23TDD:00:ODZ</daLeLaMu>

<u se rLaMu>bape</user LaMu >

</RoleType>

B.3.12 TransactionPhaseTemplate

Атрибуты; id

Элементы: name, description, dateReached. slate. dateLaMu. userLaMu

Ссылки: transaction

Фактическая фаза транзакции.

Пример — на уровне сообщения:

<WaltForMenu id-~tp003″ >

<nane>___</name>

cdeserlptlon>Oasa транзакции …</descri.ptlon> <dateReached>2008-D2-D4TDD:00:00Z</dateReaohed> <state>aetlve</state>

«UteLaMu>20O6-02-O4T00:00:00|J </dateLaMu>

<userLaMu>bapa</userLaMu>

</WaltForMenu>

Ассоциированная часть структуры взаимодействия:

<Transsct£onType ld-^ObtalnMenuTransactlon» > <descr1рь1оп>Транзакция для получения соответстьухшего MftH»x/descrlptlon> <startDate>20OB-01-23TOO:OO:0OZ</startDate>

<endDate>200B-12-31TOD:00:00Z</endDete>

<state>active</stace>

<dateLaMu>200B-01-23T0O;00:00Z</dateLaKu> <userLaHu>bapa</userLaMu>

<inltlator>

<RoleTypeRef idre£-«Consumer»/ >

</inlclator>

<executor>

<RoleTypeRel Idref-** Employee’*/ >

</executor>

</TransactlonType>

<Transact£onPhase?ype id-‘-SfaitForMenu» >

<descri.ptlon>Mems запрошено, но еще не AaHO</descrlptlon> <startbate>200B-01-23TOO:00:0OZ</startbate>

<endDate>200B-12-31TOD:00:00Z</endDate>

<scate>active</state>

<dateLaMu>200B-01-23T0O:00:O0Z</dateLaMu> <userLaHu>bapa</userLaHu>

</TransactlonPhaseType>

B.3.13 TransactionTemplate

Атрибуты: id

Элементы: number, name, description, startDate. endDate, state. dateLaMu. userLaMu. result

Ссылки: initiator, executor

Транзакция, активирующая Message Templates (сообщения), которые должны участвовать в обмене для выполнения некоторых задач.

Пример — на уровне сообщения:

<ObtainMenuTransacti©n ld-«TheT£ansactlon» >

<number>001</number>

<narr>e>___</nst»e>

«description*___«/description*

«startDate»20Q8-01-23TQO:00:00Z«/startOate» «endDate»2008-01-23T00:00:00Z«/endOate> <state»active</state»

<dateLaMu»20O8-Ol-23T0O:O0:00Z«/dateLaMu»

«userLaMu»bapa«/userLaMu>

«initiator»

«PersonlnRoie id-«___» »

«/PersonlnRoie»

«/initiator»

«executor»

«PersonlnRoie >

«/PersonlnRoie»

«/executor»

«/ObtainMenuTransactlon»

Ассоциированная часть структуры взаимодействия:

«TransactlonType ld-«ObtainMenuTransaction” >

«description»Tpan3aKUK4 яля получения соответствующего ыенкх/description» <etartDate>2008-01-23T00:0O:00Z</startDate» <endDate»2a08-12-31TOO:Oa:OOZ«/endDate»

<state»active«/state»

<dateLaMu»20O8-Ol-23TOO:OO:00Z«/dateLaMu»

<userLaMu»bapa</userLaMu»

«initiator»

«RoleTypeRet ldref-«Consuo,erA7 >

«/initiator»

«executor»

«RoieTypeRef ldrer-»Сотрудник»/ >

«/executor»

«/TransactionType»

B.4 Атрибуты

B.4.1 Id

Идентифмсатор. Уникальный код для идентификации экземпляра объекта в сообщении.

Примечание — Значение идентификатора должно быть уникальным в XML-документе. Поэтому простой серийный номер уже будет удовлетворять этому условию. Следовательно, не существует убедительных причин для ограничения значений идентификаторов только глобальными уникальными идентификаторами (GUID) (хотя в большинстве реагмзаций действигегъно применяются глобагъные уникальные идентификаторы). Стандарт XML (http J www.w3.ocg/XMU) требует, чтобы идентификатор начинался с буквы или с символа *_*.

В.5 Элементы

В.5.1 Abbreviation

Сокращенное названия организации. Этот элемент будет использоваться в качестве префикса номера транзакции для идентификации транзакции.

Примечание — Элемент abbreviation (сокращение}. Элемент abbreviation содержит краткое название организации. Одно из его применений — пометить транзакции (в сочетании с порядковым номером), запущенные данной организацией, чтобы облегчить неформальную коммуникацию между пользователями-участниками.

В.5.2 category

Категория, позволяющая классифицировать данный экземпляр объекта.

Пример — на уровне сообщения:

«… id»»..>

«category»…«/category»

В.5.3 creationDate

Дата создания конкретного экземпляра объекта в данном сообщении.

Пример — на уровне сообщения:

<… id-*…* >

<creationDate>2007-12-03T00:00:00Z</creatlonDate>

</…>

В.5.4 dateLaMu

Дата последнего изменения.

Пример — на уровне сообщения:

«… id-~…» >

<dateLaMu>2007-12-03TDO:00:00Z</dateLaMu>

</…>

В.5.5 dateReached

Дата ’dateReached» — это атрибут дагь^времени элемента ’TransactionPhaseTemplale». Он представляет собой дату/еремя достижения конкретной фазы.

Пример — на уровне сообщения:

с… id-*…» >

<dateReached>2D0B-02-04T00:00:00Z</dateReached>

</…>

В.5.6 dateRead

Дата чтения данного сообщения.

Пример — на уровне сообщения:

«… id-*…» >

<dateRead>2007-l2-03TOO:00:0OZ</dateRead>

</…>

В.5.7 dateSend

Дата отправки данного сообщения.

Пример — на уровне сообщения:

<… id-*…» >

<daceSend>2007-12-03TOO:00:OOZ</daceSend>

</…>

  • 8.5.8 description

Описание данного экземпляра объекта.

Пример — на уровне сообщения:

<Pzojeciexecutot ld-*THO* >

<deacri.pti.on>.. .</description>

</Projectexecutor>

B.5.9 documentidentification

Уникальный номер документа или ссыгжа на документ или файл для идентификации документа.

Примечание — Настоящий стандарт предоставляет свободу в установлении различий между версиями документа и версиями файла (см. раздел В.5.13).

В.5.10 documentReference

Ссылка для идентификации файла или документа.

В.5.11 documentversion

Версия документа или файла.

В.5.12 endDate

Дата истечения срока действия конкретного экземпляра объекта в данном сообщении.

Пример — на уровне сообщения:

<… id-”…» ? <endDate?2007-12-03</endDate?

</…?

В.5.13 fileLocation

Местоположение файла, предпочтительно адрес в Интернете или путь к серверу общего доступа.

Пример — на уровне сообщения:

<… id-«…» ?

<lileLocation?\\sx v~path\Public\proJect-x\docs\</flleLocat ion?

</…?

Примечание — Настоящий стандарт предоставляет свободу в установлении различий между версиями документа и версиями файла (см. раздел В.5.9).

В.5.14 fileType

Тип файла, предпочтительно тип MIME (Multipurpose Internet МаН Extensions).

Пример — на уровне сообщения:

<… id-«…» ?

<flleType?text/plain</fileType?

</…>

В.5.15 fileVersion

Версия файла — возрастающее целое число или дата.

Пример — на уровне сообщения:

. id-«…» >

<ftleVersion?20071202</tileVersion?

</.. .>

В.5.16 identification

Ориентированная на пользователя идентификация данного сообщения.

Пример — на уровне сообщения:

<AssigntnentConfirmation id-«X» >

<identiflcation?This message contains the assignment X related to part ^/identification?

</AssignmentConfirraat ion?

B.5.17 initiatingTransactionMeesageK)

Ссылка на сообщение, принадлежащее к подчиненной транзакции, которая инициировала это сообщение.

В.5.18 initiatorToExecutor

Направление коммуникации данного конкретного сообщения.

Пример — на уровне сообщения:

<ExampleKessage id-«…» >

<initiatorToExecutor?false</initiatorToExecutor? transaction?

<ExampieTranaaction id-«…» ?

«initiator»

«PersonlnRole id-«A» >

«/PersonlnRoie»

«/initiator»

«executor»

«PersonlnRole id-«B» >

«/PersonlnRole»

«/executor»

«/ExampleTransaction»

«/transaction»

«/ExatnpleMessage»

В данном примере ExampleMessage будет передаваться от В (исполнитель) к А (инициатор).

В.5.19 language

Язык содержимого дополнения.

Пример — на уровне сообщения:

«… id-«…» >

«language»EN«/language»

</…»

8.5.20 name

Наименование (STRING)

В.5.21 number

Номер транзакции.

Примечание — Элемент number. Порядковый номер транзакции (см. также предыдущий элемент).

В.5.22 objectCode

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

В.5.23 result

Результат данной транзакции.

В.5.24 startDate

Начальная дата для конкретного экземпляра объекта в данном сообщении.

Пример — на уровне сообщения:

«… id-«..>

«StartDate>2007-12-03</startDate»

</…»

В.5.25 state

Текущее состояние данного экземпляра объекта.

Пример — на уровне сообщения:

«… id-«…» >

<state»active</state»

</…»

В.5.26 usertaMu

Пользователь, выполнивший последнее изменение

Примечание — Это не ссылка на создание экземпляра PersonTypelnstance.

Пример — на уровне сообщения:

«… id-«…» >

«userLaMu»Peter Bonsma«/usexLaKu»

В.5.27 userName

Инициалы пользователя, например, триграмма {комбинация из трех символов).

Пример — на уровне сообщения:

<.. . id-«…» >

<userNatne>BAP</userName»

«/…»

В.5.28 verstonNo

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

Пример — на уровне сообщения:

«… id-«…» >

<verslonNo»23</versionNo»

•••’…»

В.6 Ссылки

В.6.1 AppendixGroup

Подраздел для идентификации некоторого дополнения.

Пример — на уровне сообщения:

«Appendix id-«…” >

«append! xGroup» «AppendixGxoup id-«___» »

</Арре nd i xGroup»

«ZappendixGroup»

«ZAppendix»

Считается, что в ассоциированной структуре определен тип AppendixType. имеющий значение Appendix.

В.6.2 contactPerson

Лиио. связанное с объектом PersonlnRote или связанное с конкретной организацией.

Пример — на уровне сообщения:

«Organisation id-«…» >

«contactperson»

«Person id-«___» »

«/Person»

«/contactPerson»

«/organisation»

Считается, что вассоциированной структуре определен тип OrganisationType. имеющий значение Organization, и тип PersonType. имеющий значение Person.

В.6.3 Executor

Объект PersonlnRole. который будет действовать как исоолнигегь в этой транзакции.

В.6.4 Group

Общая группа для сборки набора дополнений.

Пример — на уровне сообщения:

«AppendixGroup id-”…» >

«group»

«Group id-«…» »

«/group»

«/group»

«/AppendixGroup»

Считается, что 8 ассоциированной структуре определен тип GroupType. имеющий значение Group.

В.6.5 Initiator

Объект PersonlnRole. который будет действовать как инициатор в згой транзакции.

В.б.в Message

Сообщение, содержащее конкретное дополнение.

Пример — на уровне сообщения:

«Appendix id-«___» ?

«message?

«Message id-”…» >

«/Message?

«/message?

«/Appendix?

Считается, что в ассоциированной структуре определен тип AppendixType. имеющий значение Appendix, и тип MessageType. имеющий значение Message.

  • 8.6.7 messagelnTransaction

Ссылка на положение этого сообщения в потоке транзакции.

  • 8.6.8 Organization

Организация, принадлежащая объекту PersonlnRole.

Пример — на уровне сообщения:

«PersonlnRole id-«…* ?

«organisation?

«Organisation id»»…” >

«/Organisation?

«/organisation?

«/PersonlnRole?

Считается, чтоеассоциированнойструктуре определен rnnOrganisationType. имеющий значение Organization.

  • 8.6.9 Role

Ссылка на роль, выполняемую от имени организации пользователем PersonTemplate (лицом).

  • 8.6.10 Substituting

Объект PersonlnRole. авторизованный для отправки сообщений от имени данного лица.

Примечание — Ссылка substituting. Ссылка на форыатъный объект PersonlnRole для данной транзакции. позволяющая действовать другому лицу в отсутствие тмца. реализующего формальный объект PersonlnRole. Оба лица должны ссылаться на один и тот же тип роли.

  • 8.6.11 Successor

Преемник другого лица в некоторой роли.

  • 8.6.12 Transaction

Транзакция, содержащая конкретную группу, фазу транзакции или конкретное сообщение.

Пример — на уровне сообщения:

«Message id-«…- >

«transaction?

«Transaction id-«…» >

«/Transaction?

«/transaction?

«/message?

Считается, что в ассоциированной структуре определен тип MessageType, имеющий значение Message, и тип Transaction Туре, имеющий значение Transaction.

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

Пример карты взаимодействия для упрощенного конструкторского бюро

С.1 Общие положения

В приведенном примере создания структуры взаимодействия область действия взаимодействия ограничена упрощенным взаимодействием в пределах конструкторского бюро (см. пример в разделе 4). Взаимодействие определяется в структуре путем объявления;

  • — ролей.

  • • транзакций.

  • • сообщений в транзакциях,

  • • порядка сообщений в транзакцюг,

  • — элементов данных в сообщениях.

С.2 Роли и транзакции

Для иллюстрации области действия для взаимодействия а данном примере действия коммуникации изображены на ‘карте взаимодействия*, отображающей роли, связанные с транзакциями.

Роли:

  • — CR1: Client; (клиент)

  • — R1: Project leading; (управление проектом)

  • • R2: System engineering; (системное проектирование)

  • — R3: 3D engineering; (проектирование трехмерных моделей)

  • • R4; Cost engineering (стоимостное проектирование).

Сводка взаимодействий приведена в таблице ролей в транзакциях.

Таблица С.1 — Таблица ролей в транзакциях для упрощенного конструкторского бюро

Тип транзакции

Инициирующая роль

Исполняющая роль

Т1 Разработка проекта

CR1 Клиент

R1 Управление проектом

Т2 Разработка спецификации системы

R1 Управление проектом

R2 Системное проектирование

ТЗ Разработка трехмерной модели

R1 Управление проектом

R3 Проектирование трехмерных моделей

Т4 Разработка сметы

R1 Управление проектом

R4 Стоимостное проектирование

Конструкторское бюро

Рисунок С.1 — Карта взаимодействия, определяющая соответствующие типы ролей и типы транзакций

С.2.1 RoleType

Роли определены в структуре как RoleTypes. Каждый RoleType может быть определен следующими терминами:

  • • идентификатор (идентификация roleType).

  • • (Должен иметь допустимое значение идентификатора XML (квалифицированное имя). Существует несколько ограничений: * должно быть уникальным в модели. * некоторые символы не разрешены $’. …). * без

пробелов. * не должно начинаться с цифры]

  • • описание (спецификация roleType),

  • • ответственности (область действия, задача, задача поддержки и обратная связь).

  • • метаданные (последнее изменение, справочная информация и т. д.).

Следующие четыре роли данного примера определены в структуре (см. приведенный ниже пример в представлении XML):

•RoleType id«CRl_ClAent*’ >

<descr iptlorrCRl: Клиент description»

<stdrtDate»2010-10-29T00:00:00.000*02:00</startDate»

<endDate»2099-10-2< ‘ •. и J: .ju. nuu• :OC</endDate>

<state»active-‘/state»

<dateLaMu»2010-10-29T00:00:00.000*02:00< ZdateLaMu»

«userLaHu>Ronald- /userLaMu>

<language»«/language»

<category»«/category>

<helplnfo»«/helplnlo>

<code»«/code»

«responslbilityScope>Hecee ответственность за реализацию проекта, выражаемую в терминах времени, качества и стоимости «/responsibilityscope»

cresponslbilityTaskx/responsibiiityTask»

<r esponsibl 11 tySupportTaskx/r esponsibi 11 tySuppor tTask» «responslbilityFeedbackx/xesponsibilityFeedback»

«/RoleType»

«RoleType id-«Rl_Project_Leading‘» >

<description»Rl: Управление проектом .description»

<startDate>2010-10-29T00:00:00.000+02:00</startDate>

<endDate?2099-10-29TO0:00:00.000*02:00</endDate?

<state>active-/state?

<dateLdMu>2010-10-29T00:00:00.000*02:00-/dateLaMu?

«user L.iMu>Ronald-;/user LaMu?

«language?</language?

<category?«/category?

<helplnfo?«/helplnfo?

<code?«/code?

«responsibilityScopeyflonxeH доставить проект в соответствии с требованиями к контракту «/responsibilityscope?

«responsibilityTask?«/responalbilityTask?

«responsibilitySupportTaakx/responsibilitySupportTask? <responsibilityFeedback?</responsLbilityFeedback?

«/RoleType?

«RoleType id»»R2_Systetn_Engineexlng» > <description>R2: Системное проектирование-/description? <startDate>2010-10-29T00:00:00.000+02:00</startDate?

«endDate?2099-10-2 9T00:00:00.000*02:00</endDa te?

«stat e>actlve- /state?

<dateLaMu>2010-10-29TOO:00:00.000*02:00- ZdateLaMu?

«user I.aMu>Ronald-;/user LaMu?

<language>«/language?

«categoryx/category?

<helpinfo?«/helplnfo?

«codex/code?

<responsibiiityScope?QojrKeM доставить спецификацию систеыы в соответствии с контрактными соглашениями*/responsibilityscope?

<responsibilityTask?c/responsibilityTask?

«responsibilitySupportTask?</responsibilitySupportTask? <responsibilityFeedback?c/responsibilltyFeedback?

«/RoleType?

«RoleType id-«R3_3D_Engineering” ?

<description?R3: Проектирование трехмерных моделей/description?

<startDate>2010-10-29T00:00:00.000+02:00«/startDate?

<endDate?2099-10-29TOO:00:00.000+02:00«/endDate?

«state-active-/state?

<datel.iMu>2010-10-29T00:00:00.000+02:00- /dateLaMu?

«userLaMu?Ronald</userLaMu?

«language?*/ language?

«categoryx/category?

<helplnfo?«/helplnfo?

<code?«/code?

<responsibilityScope?nonxeH доставить ЗО-модель в соответствии с контрактными соглашенмяии«/гевропх1Ь1lityScope?

«responsibilityTaskx/responsibilityTask? «responsibilitySupportTaskx/responsibilitySupportTask? <responsibilityFeedback?«/responsibilityFeedback?

«/RoleType?

«RoleType id-~R4_Cost_EngineerIng» ?

<description>R4: Стоимостное проектирование-/description?

«зtart0ate>2010-10-29T00:00:00.000+02:00*/startOate?

«endDate?2099-10-29T00:00:00.000+02:00</endDate>

<state>active- /state?

<dateL.iMu>2010-10-29T00:00:00.000+02:00* /dateLaMu?

«user LdM->Ronald< / user LaMu? <language?«/language? <category?</category? <helplnfo?</helplnfo?

<code?«/code?

<responsibilityScope?noj»cew доставить расчет стоимости в соответствии с контрактными соглашениями*/responsibi11tyScope?

<responsibilityTask?«/responsibilityTask?

«zesponsibilitySupportTaskx/xesponslbilitySupportTask»

<responsibilltyFeedback>«/responsibilityFeedback»

«/RoleType»

С.3 Сообщение в транзакции

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

С.3.1 TransactionType

Транзакции определяются е структуре как TransactionTypes’. Каждый TransactionType может быть определен следующими терминами:

  • • идентификатор (идентификация TransactionType).

  • • описание (спецификация TransactionType).

  • • метаданные (результат применения TransactionType. справочная информация и т. д.).

  • • типы RoieType. которые включены в TransactionType.

Следующие четыре типа TransactionType а данном примере изображены а приведенном ниже представлении XML:

— Т1: Обмен проектом:

  • • Т2: Обмен системной спецификацией:

  • • ТЗ: Обмен 30-моделью;

  • • Т4: Обмен расчетом стоимости.

«TransactionType id»~Tl~ »

«descrlptlon»Tl Доставка проекта «/description»

«startDate»2010-10-29T00:O0:00.000+02:00«/startDate> «endDate»2099-10-29TOO:00:00.000+02:00</endDate> «state»active«/state»

«dateLaMu>2010-10*-29TOO:00:00.000+02:00</dateLaMu>

«userLaHu»Ronald«/userLaMu>

«languagex/language»

«category»«/category>

<helplnfo>«/helplnfo> «codex/code>

<result»npoeKT доставлен*:/result»

«initiator»

«RoleTypeRef ldre£-«CRl_Client»/ »

«/initiator»

«executor»

«RoleTypeRef ldгef••*’Rl_Pгoject_l.eading,’/ »

«/executor»

«/TransactionType»

«TransactionType id-~T2″ >

«description»T2 Доставка спецификации системы«/Севсгiption» <startDate»2010-10-29T00:00:00.00D+02:00</startOate> «endDate»2099-10-29T0O:00:00.000+02:00«/endDate>

<state»active«/state>

«dateLaHu»2010-10-29TOD:00:00.000+02:00«/dateLaHu»

«usexLaMu»Ronald</userLaMu>

«languagex/language»

cca tego г у></саtego г у>

«helplnfo»«/helplnfo>

<code»«/code>

«гезиЮСпецификация системы доставлена</ге£иЮ

«initiator»

«RoleTypeRef idref-«Rl_Project_Leadlng»/ »

«/initiator»

«executor»

«RoleTypeRef ldre£-«R2_System_Engineering»/ »

«/executor»

«/TransactionType»

«TransactionType Ю-^ТЗ» »

«description»T3 Доставка 3P-MOAenn</description»

<startDate»2010-10-29T0O:O0:00.000+02:00«/startDate>

<endDate»2099-10-29TO0:00:00.000*02:00</end0ate>

<state>active«/state»

<dateLaMu»2010-10-29TOO:00:00.000+02:00«/dateLaMu>

<userLaMu>Ronald«/u3erLaMu>

«language»*/language» «category»«/category» «helplnfox/helplnto» «code»«/code»

«result»30-модель достаьлена«/гези11»

«initiator»

«Role Type Ref ldref~~Rl_Project_Leading»/ >

«/initiators

«executor»

«RoieTypeRef idre£’»»R3_3D_Engineering’*/ »

«/executors

«/TransactlonType> «TransactionType id-^T-l» »

«description»T4 Доставка расчета cTOKMOCTx</description» <3tartDate>2010-10-29TCQ:00:00.000+02:00«/startOates <endDate»2099-lQ-29TOO:00:00.000+02:00</end0ate»

«зtate>active«/3tate>

<daLeLaMu>2010-10-29TOO:00:00.000+02:00</dateLaMu»

«userLaMu>Ronald«/u3erLaMu>

«language»*/language» <categoryx/category> «helplnCox/helpInfo» <codex/code»

«гезиЮРасчет стоимости доставлен«/гези1с> «initiator»

«RoieTypeRef ldre£»“Rl_₽roject_Leading’’/ >

«/initiator»

«executor»

«RoieTypeRef idre£-»R4_Cost_Engineerlng»/ »

«/executor» «/TransactionType»

IDM выделяет роль, делающую запрос (инициатор), и роль, обеспечивающую осуществление этого запроса (исполнитель). В каждой транзакции может быть только одна инициирующая рогъ и одна исполняющая роль. Например. тип TransactionType, имеющий значение *ТЗ Deliver 3D model’ (Обмен 30-моделью). может быть инициирован только ролью R1 Project leading (Управление проектом) и выполнен инженером — разработчиком трехмерных моделей в роли R3.

С помощью транзакций передача информации осуществляется 8 контексте процесса.

С.3.2 TransactionPhaseType

С типами TransactionType могут быть связаны фазы, позволяющие определить состояние взаимодействия внутри транзакции. В сущности, типы TransactionPhaseType в TransactionType представляют собой массив транзакций. Определения TransactionPhaseType обеспечивают идентификацию типов TransactionPhaseType и некоторых метаданных. Число фаз и их описание не ограничены.

В данном примере определены следующие типы TransactionPhaseType. соотносящиеся с рисунком 2 в разделе 3:

  • • желательный результат;

  • • результат запрошен;

  • • результат обещан;

  • • результат получен;

  • • результат объявлен;

  • • результат принят.

В приведенном ниже примере показано определение TransactionPhaseType в представлении XML: «TransactionPhaseType id-«Deslred_Result» »

«deset;о:.>Желательный ревультат-/description»

<startDate>2010-10-01T00:00:00.000+02:00</starLDate» <endDate»2099-10-01T00:00:00.000+02:00</endDate> «stat tractive-;/state»

<dateLaMu»2010-10-01T00.-00:00.000+02:00«/dateLaMu>

<uy.erI.dM’4>Ronald</userLaMu»

elanguage?e/language?

<саtegoг у></саtegoг у >

<helplnfo?e/helplnfo? ecode?-e/code?

е/TransactlonPhaseType?

«TransactlonPhaseType -J-“Raault_Accepted» > «descr 1р^оп>Результат дримят-descriptlon? estartDate>2010-ll—04T00:00:00.000+01:00«/startDate? «endDate?2099-ll-04T0O:00:00.000+01:00</endDate? <sta tractive-/state?

<dateLaMu?2010-l 1-04T00:00:00.000+01:00</dateLa.4u? «user LaMu>Ronald- /usee LaMu?

clanguage?c/language? ccategory?«/categoxy?

<helplnfo?«/helplnro? ecode?-«/code>

«/TransactlonPhaseType? «TransactlonPhaseType i::-«Result_Produced» ?

«descriptie:; -Результат получен- /description? cstartDate?2010~10—01T00:00:00.000+02:00«/startDate> <endDate?2099-10-01T00:00:00.000*02:00«/endDate? estate>actlve</state?

edateLaMu?2010-10-01T00:00:00.000+02:00«/dateLaMu? «user LaMu?Ronald- /user LaMu?

clanguage?c/language? ecategory?«/category?

<helplnfo?«/helplnto?

<code?-</code>

«/TransactlonPhaseType? «TransactlonPhaseType id-“Reault_Proniieed“ ?

«descripti-. :; -Результат обежан-/description? <StartDate>2010-10-01T00:00:00.000*02:00</startDate> <endDate?2099-10-01T00:00:00.000*02:00</endDate? estate:-active-/state?

edateLaMu?2010-10-01T00:00:00.000+02:00«/dateLaMu? <userLaMu>Ronald/userLaMu?

eianguage?e/language? ecategory?e/categoxy? ehelplnfo>e/helplnto?

ecode?-e/code?

«/TransactlonPhaseType?

«TransactlonPhaseType ^f:-“Raeult_Requeeted» > «descriptie:; -Результат задрожав — description? estartDate>2010-10-01T00:00:00.000+02:00e/startDate> eendDate?2099-10-01T00:00:00.000*02:00e/endDate? estate>active-/state?

edateLaMu?2010-10-01T00:00:00.000+02:00e/dateLaMu? euser LaMu>Ronald- /userLaMu?

elanguage?e/language? ecategory?e/categoxy?

<helplnfo?«/helplnto? ecode?-e/code>

«/TransactlonPhaseType? «TransactlonPhaseType id-“Rasult_Stated’’ ?

«descript—:; -Результат объявлен— description? cstartDate?2010-ll-04T00:00:00.000+01:00e/startDate> eendDate?2099-il-04T00:00:00.000+01:00«/endDate? estate>actlve</state?

edateLaMu?2010-ll-04T00:00:00.000+01:00e/dateLaMu? euser LaMu?Ronald-. / use rLaMu?

elanguage?e/language? ecategory?e/categoxy?

«helplnfo*«/helpln£o* «code*-«/code* «/TransactionPhaseType*

C.3.3 MessageType

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

В каждом сообщении имеются группы сегментов (составных элементов). Эти составные элементы определяются типами ComptexElementType. В каждом сегменте может находиться совокупность составных элементов и/или одиночных элементов. Одиночные элементы определяются типами SimpleEtementType.

В приведенном ниже примере показано определение типов MessageType в представлении XML. изображенное графически на рисунке 5 8 разделе 3:

  • • запрос ЗО-модепи:

  • • задание выполнено, запрос одобрения;

  • • запрос корректировок:

  • • задание утверждено;

— задание не утверждено. «MessageType id-«Request_for_3D_model» > «description>3anpoc 30-модели</description* <8tartDate>2010-ll-04T00:00:00.000*01:00*/startDate* <endDate*2099-l1-04T0O:00:00.000*01:00</endDate* <etate>activ«-/state*

«dateLaMu*2010-ll-04TOO:00:00.000+01:00«/dateLaMu*

«user LaMi:—Ronald*’/user LaMu*

<language*</language* «categocyx/category* <helplnfo*«/helplnfo* <code*-«/code>

«complexElements* <Cc<nplexElee>entTypeRef «CocnplexEleoentTypeRef «CccnplexElementTypeRef «CocnplexEleoentTypeRei «CccnplexElementTypeRef «/complexElements*

idre£-«ReaultRequeetedCcag>lexElement»/ > idref-«WorkIdentiiicationComplexElement*’/ * idref-^WorkSpecificationComplexElement»/ > idrei«»RemarkeComplex£lement» * idreE-«I>eadlineCcnplaxElement» ‘ > «/MessageType*

«MessageType id«HWork_done_and_requesL_approval*’ *

«descripticr.-Задание выполнено, запрос одобрения «/description*

«зtartOate*2OlO-ll-O4T0O:00:00.000+01:00-;/s tar tDate*

<endDate*2O99-ll-04T00:00:00.000+01:00</endOate*

«statoactive/state* <dateLaMu>2010-ll-04T00:0O:00.000+01:0O«/dateLaMu> «user-Ronald*;/userLaMu*

«language*«/language* «categoryx/category* «helpInCox/helpInfo* «code*-</code*

«complexElements*

«ComplexElementTypeRef «ComplexElementTypeRet «ComplexElementTypeRef «ComplexElementTypeRef «ComplexElementTypeRef </complexElements*

idret-«Raqua8tApprovalCoaplexElement» > idref-«RaBark8CeeplajtEleaent» * idref~»DaadllfMCoaplax£lamant»‘ * idret-«WorkIdentificationCoag>lex£lement»/ * idref-«WorkSpecificationCc«g>lexElestent» / * «/MessageType*

«MessageType ld«-‘’Request_adjusttnents’* * «description-Запрос корректировок- .’description* <startDate*2010-ll-04T00:00:00.000+01:00-/startDate*

<endDate*2099-ll-04T00:00:00.000+01:00«/endDate*

«state>active-/state*

<dateLaMu*2010-ll-04T00:00:00.000+01:00«/dateLaMu*

«user L.iMu —Ronald*; /userLaMu*

«language»*/language»

<саtegoг уж/сеtegoг у >

«helplnfox/helplnfo»

«code»-«/code» «oomplexELetnents»

«ComplexEleme.ntTypeRef idref-«RequeetAdjusttaenteCo®plexEleeent’’/ >

«ComplexElementTypeRef ldref-«ReaarksCoepiexElet&ent»/ >

«ComplexElementTypeRef idref«-”DeadlineCotoplexElenent»‘/ >

«ComplexElementTypeRef idreta*»WorkIdentificationCotBplexEl«Bent»/ > «ComplexElementTypeRef ldref*»‘WorkSpecificationCotaplexSleMnt*’/ > «/complexElements»

«/MessageType»

«MessageType :J-“Work_approved» > «description -Задание утверждено’ description» <startDate>2010-ll-04T00:00:00.000+01:00</startDate» <endDate»2099-li-04T00:00:0O.00O+01:00«/endDate»

«state>active</state» <dateLaMu»2010-ll-04T00:00:0Q.000*Ol:00«/dateLaMu»

«userLaMu>Ronald</userLaMu» <language»«/language> «category»*/category» «helplnfox/helplnfo» <code»-«/code»

«coaplexEXements»

ldref «-«ApprovalCotsplexEletaent»/ > ldref-«RetaarksCotaplexEletaent»/ » idref**»’HorkIdentlficationCoaplexEleMnt»/ » idref-»NorkSpecificationCotaplexEieBMnt*’/ >

«ComplexElementTypeRef «CoouplexElementTypeRef «ComplexElementTypeRef «CoouplexElementTypeRef « / coenplexE Xeme n t s »

</Mess а деТуре»

«MessageType i<.:-«Work_not_approved’“ » «descriptiooSaAaune не утверждено-/description» <startDate»2010-ll-04T00:00:00.000+01:00«/startDate> <endOate»2099-ll-04T00:00:00.000*01:00</endDate»

«state>active-/state»

<dateLaMu»2010-li-04T00:00:00.000*01:00«/dateLaMu» «user LaMu>Ronald-•/userLaHu> «language»*/language» «categoryx/category» «helpln tox/helplnto» <code»-«/code>

< coaipie x Eleven t s »

ldref**»DleapprovalCoaplexElement»/ » idref*-«ReBarksCoffiplexEleakent»/ » ldref**»HorkIdentiflcationCotopl«xEleBaat»/ > idret»»WorkSpeciflcationCotBplexEleB*nt»/ >

«ComplexElementTypeRef «ComplexElementTypeRef «ComplexElementTypeRef «Comp lexElemen tT ypeRe f «/conplexElenents» «/MessageType»

MessageType также используется для идентификации сообщений в транзакции. Отношение между messageType и transaclionType определяется в другом типе: MessagelnTransactionType.

С.3.4 MessagelnTransactionType

Транзакция содержит набор сообщений, обмен которыми выполняется для какой-либо цели. Определения MessagelnTransactionType обеспечивают связывание MessageTypes с TransactionTypes. Один и тот же тип MessageType может быть связан со всеми определенными типами TransactionType. Также можно связать один и тот же MessageType более одного раза (даже неограниченное число раз) с тем же самым TransactionType.

Каждый MessagelnTransactionType может быть определен следующими терминами:

  • • идентификатор {идентификация MessagelnTransactionType).

  • • направление сообщения, которое должно быть отправлено {от инициатора к исполнителю = true: от исполнителя к инициатору = false),

  • • метаданные MessagelnTransactionType.

  • • ссылка на тип MessageType (положение которого определено в тиле MessagelnTransactionType),

  • • ссылка на тип (или илы) TransactionType для связывания с типами MessageType. на которые дана ссылка.

  • — ссылка на TransacbonPhase (фазу), в состояние которой переходит процесс (после отправки MessageType в типе TransacbonType. как это было определено типом MessagelnTransaclionType),

  • — ссылка на тип GroupType.

В приведенном ниже примере показано определение е представлении XML двух типов MessagelnTransactionType из примера запроса трехмерной модели. Пример будет понятен, если ознакомиться с рисунком 5 (в ISO 29481-2 IDM. масть 2 Карта взаимодействия; глава 3).

Приведенный ниже пример в представлении XML показывает, что TransacbonType ТЗ запускается с помощью MessageType ‘Запроса трехмерной модели’. Это первое сообщение в транзакции, поскотъку не существует предыдущих типов MessagelnTransactionType. определенных в MessagelnTranacbonType ‘MessagelnTransactionl’. Направление MessagelnTransactionl указано как ’от инициатора к исполнителю* (значение = true).

Второй тип MessagelnTransactionType. определенный как ‘MessagelnTransacbon2*. ссылается на тип MessageType ‘Задание выполнено, запрос одобрения*. Рисунок 5 показывает, что это сообщение должно следовать за двумя предыдущими сообщениями:

  • • Запроса трехмерной модели;

  • • Запрос корректировок.

Эти два предыдущих сообщения определены как типы MessagelnTransactionType (номер 1 и номер 3) в MessagelnTransacbonType2. Направление MessagetnTransaction2 указано как «от исполнителя к инициатору» (значение — false).

«MessagelnTransactionType Id-^MessagelnTransactiel» > <requiredNotify>0«/requlredNotify»

<dateLaMu>2010-l1-OSTOO:00:00.000+01:00«/dateLaMu>

«userL.iM’j ‘Ronald’.’/useeLaMu>

<received>0</received»

<send»0«/send>

<3tatex/state>

<init iatorToExecutor -‘true-‘ / initiatorToExecutor»

«message»

«MessageTypeRef idret-‘Request_for_3D_model»/ >

«/message»

«transaction»

«TransactionTypeRef idref-«T3″/ >

«/transaction»

«transactionPhase»

«TransactionPhaseTypeRef IdreC-«Rasult_Requested»/ >

</transactionphase»

«group»

«GroupTypeRef ldref-«StandardGroup»‘ » «/group»

«/MessagelnTransactionType» «MessagelnTransactionType ld~’rNaesagalaTsaneaetla2″ >

«requiredNotify»0</requiredNotifу» <dateLaMu>2010-ll-05T0O:00:00.000+01:00«/dateLaMu> «user LaM- -‘Ronald’- / userLaMu»

<received>0«/received»

<send»0«/send»

<state»</state»

<initiatorToExecutor»£alse-/initiatorToExecutor»

«message»

«MessageTypeRef idre£-«Work_done_and_request_approval“/ >

«/message» «previous» «MessagelnTransactionTypeRef idref^MessagelnTransactiel»/ » «MessagelnTransactionTypeRef idref~*’MaseageInTraneactie3″/ »

«/previous»

«transaction»

«TransactionTypeRef idref-«T3″/ »

«/transaction»

«transactionphase»

«TransactionPhaseTypeRef idref-«Rasult_Produced»/ >

</transactionphase»

«group»

«GroupTypeRef idref-«StandardGroup»/ » «/group»

«/MessagelnTransacclonType»

С.3.5 AppendixTypes

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

Определения AppendixType предназначены для ограничения информационных элементов компонентов, связанных с документами. путем добавления метаданных в документы, вложенные в сообщение.

В приведенном ниже представлении XML показано определение AppendixType. Метаданные определяются типами SimpleElemenlType в ComplexElementType AppendixComplexEtemenl’.

«AppendixType ld“»StandardAppendixType» >

«description’Стандартное дополнение’ »description?

«StartDate>2010-10-01T00:00:00.000*02:OO’/startDate?

<endPate?2099-10-01T00:00:00.000*02:00</endPate?

«state -active-/state?

«dateLaMu?2010-10-01T00:00:00.000+02:00</dateLaMu?

<userLaMu>Ronald’/user La Mu >

<language?«/language? <category?«/category? <help:n£o?«/helpXnto?

«compiexElenents?

«CosplexElementTypeRef Ldxef-«AppendixCoatpiexEieinent»? ?

«/coeplexElenents?

«/AppendixType?

C.3.6 Ограничение содержимого сообщений

Третьим и последним шагом определения структуры взаимодействия является определение компонентов в типах MessageType с целью:

  • • структурировать типы MessageType;

  • • ограничить входные данные содержимого.

Определение MessageType уже содержит составные элементы сообщения. Эти составные элементы определены как типы ComptexEtementType.

Тилы ComplexElementType состоят из типов SimpleElementType (или. возможно, также из других типов ComplexElementType). Типы SimpleElementType связываются с типами UserDefinedType для определения ограничений входных данных содержимого. Эта структура графически изображена ниже.

Рисунок С.2 — Компоненты моделирования сообщения

С.3.7 Типы ComplexElementType

Определения ComplexElementType обеспечивают:

  • • ограничение информационных элементов компонентов.

  • • используемых механизмами иерархия определений типов (в XML) для получения сложного типа из другого простого или сложного типа.

  • • определения вклада в проверку соответствия схем документу (post-schema-validabon infoset) для элементов.

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

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

Если обратиться к приведенному примеру использования MessageType ‘Запрос трехмерной моде-гы’. связанного с транзакцией ТЗ (Запрос трехмерной модели), этот MessageType содержит следующие т«1ы ComplexElementType:

  • • resultRequesledComplexElement;

  • • workldenttficationComplexElement:

  • • workSpecificationComplexElement

  • • remarksComplexElemenl;

  • • deadlineComplexElement.

Тип ComplexElementType ’WorkSpecificabon’ показан ниже в представлении XML. ComplexElementType определяет его идентификацию, ссыгжу на простые элементы, которые передают содержимое в ComplexElementType, и его метаданные.

В XML-представлении для ComplexElementType ‘WorkSpecificationComplexElement’ показано. что ComplexElementType содержит два типа SimpleElementType:

  • • ScopeOfWork:

— CostEstimation.

«ComplexElenentType id-^WorkSpeciHcatlonComplexEletnent» >

«descripti Спецификация задания-‘ -description*

<3tartDate>2010-10-01T00:00:00.000+02:00</starCDate*

<endDate*2099-10-01TOO:00:00.000+02:00«/endDate>

«state ;• active-* / state*

<dateLaMu*2010-10-01TOO:00:00.000*02:00</dateLaMu>

«user i-.iM — -Ronald*/userLaMu*

«language**/language*

<category*<7 category*

«helplnfox/helplnfo*

«aimpleElements*

«SimpleElementTypeReC idre£-«ScopeOfWork»/ *

<SiffipleEien>entTypeRef idref-«CostE8tination»/ *

</aimple£lements> «/ComplexEletnen tType*

С.3.8 Типы SimpleElementType

Определения типа SimpleElementType обеспечивают:

  • • определение его идентификации.

  • • задание ‘пространства значений’ и ограничений входных данных.

В приведенном ниже представлении XML показано определение одного типа SimpleElementType: CostEstimation. Этот тип SimpleElementType является частью типа ComplexElementType ‘WorkSpecificationComplex ElementType’ (из предыдущего примера).

«SinpleElementType id*-«CostEstimation*’ *

«description*0ueHxa стоимости*/descript ion*

«interfaceType/*

<3tate*active</state>

<dateLaMu*2010-12-10T12:36-.02.527+01:00«/dateLaMu>

«userLaMu*Ronald«/userLaMu*

«language/*

«category/*

«Ие1р1п£о*Имформация о затратах «/helpinfo*

«valueList/*

«UserDefinedType*

«UserDefinedTypeRef idre£-*’EURO*7 >

«/UserDefinedType* «/SimpleEletnentType*

С.3.9 Типы UserDefinedType

Типы UserDefinedType используются для определения ограничений для входных данных содержимого (путем определения типов datatype). Все возможные ограничения XML разрешено использовать для определения типов UserDefinedType в структуре взаимодействия. В данном примере использованы только типы данных ‘STRING’ и EURO’.

В приведенном ниже примере показано в представлении XML определение типа UserDefinedType. обеспечивающего:

  • • идентификацию.

  • • метаданные.

  • • baseType.

  • • ограничение XSD (для более конкретного определения ограничения или для определения типов перечислений).

— «UserDefinedType ld-«EUR0» *

«description*Euro- .-’description*

«stated-active-/state*

<datetaMu*2010-12-10T12:35:19.485+01:00«/dateLaMu*

«user LaMu -Ronald—/userLaMu*

•—b.is-.rType>DECIMXL—‘ .-’baseType*

«xsdRestrictionXxa:fractionDigita value«»2″/ > < /xsdRestriction >

(Ъе1рГп£о>Суы«лг h евро, указанные с двумя десятичными Знаками(/Ъе1р1п1о*

(/User DeJinedT уре>

— <UsexDefinedType Ld~»STRING» *

(description-CxpoxM символов’/description*

(state>active-/state*

(dateLaMu*2010-10-01T00:00:00</dateLaMu*

«user LaMii >Ronald- /user LaMu *

(baseType>STRING-;/baseType>

(xsdRestrlotion /*

(Language />

<heipInfo*Tnn данных String представляет строки символов в XML. ‘Пространство значений’ строки — это набор последовательностей символов конечной длины.(/heiplnto*

(/User DetinedType*

С.3.10 Заключение

Были определены все типы ElementType. достаточные для создания структуры взаимодействия. Для проверки правильности необходимо проверить соответствие структуры ее схеме XSD. Следующим шагом должно быть продвижение структуры взаимодействия для получения схемы взаимодействия. Эти действия описаны в подразделе 4.8.

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

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

D.1 Основные идеи алгоритма промотора

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

Базовый алгоритм инструмента промотор преобразовывает все элементы данных () «Туре» структуры взаимодействия (RoleType. TransactionType. MessageType. ComplexElementType. SimpieElementType и т. д.) в элементы сложных типов XSD. Конечно, необходимо руководствоваться определенными правилами, гарантирующими, что результирующая схема XSD представляет собой корректную схему XML. Например, значение атрибута ID элемента данных ‘Туре интерпретируется как наименование эквивалентного ему элемента сложного типа XSD. Следовательно. атрибут ID в структуре взаимодействия должен быть не чем-то. похожим на ID = «Rote003’. а более похожим на ID = ”Projecl_Manager*.

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

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

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

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДАЛ

Обозначение ссылочного международного стандарта

Степень соответствия

Обозначение м наименование соответствующего национального стандарта

ISO 29481-1

ЮТ

ПОСТ Р 10.0.03—2019/ИСО 29481-1:2016 «Система стандартов информационного моделирования зданий и сооружений. Информационное моделирование в строительстве. Справочник по обмену информацией. Часть 1. Методология и формат»

Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта:

• ЮТ — идентичньм стандарт.

Библиография

[1] Dietz J.L.G. (2006). Enterprise Ontology: Theory and Methodology. Springer, издание 1.240 c.. ISBN: 3540291695

УДК 004.9:006.354

ОКС 91.010.01

35.240.67

35.240.01

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

БЗ 6—2019/8

Редактор Л.В. Каретникова

Технический редактор В.Н. Прусакова Корректор М.И. Першина Компьютерная верстка Е.О. Асташина

Сдано в набор 06.06.2019. Подписано в печать 10.07.2019. Формат 60*84t’g. Гарнитура Ариал. Усл. леч. л. 6.84 Уч.-им. л. 8.00.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении оо ФГУП «СТАНДАРТИНФОРМ* . 117418 Москва. Нахимовский лр-г. д. 31. к. 2.

www.gosiinfo.ru info@goslinfa.ru

cepera

Эксперт по разрешительной и нормативной документации. Стандартизация и метрология.

Оцените автора
Комментарии читателей