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

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

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

С.1 Общие положения

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

- ролей,

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

- сообщений в транзакциях,

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

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

С.2 Роли и транзакции

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

Роли:

- CR1: Client; (клиент)

- R1: Project leading; (управление проектом)

- R2: System engineering; (системное проектирование)

- R3: 3D engineering; (проектирование трехмерных моделей)

- R4: Cost engineering (стоимостное проектирование).

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

Таблица С.1 - Таблица ролей в транзакциях для упрощенного конструкторского бюро

Тип транзакции	Инициирующая роль	Исполняющая роль
Т1 Разработка проекта	CR1 Клиент	R1 Управление проектом
Т2 Разработка спецификации системы	R1 Управление проектом	R2 Системное проектирование
Т3 Разработка трехмерной модели	R1 Управление проектом	R3 Проектирование трехмерных моделей
Т4 Разработка сметы	R1 Управление проектом	R4 Стоимостное проектирование

Рисунок С.1 - Карта взаимодействия, определяющая соответствующие типы ролей и типы транзакций

С.2.1 RoleType

Роли определены в структуре как 'RoleTypes'. Каждый RoleType может быть определен следующими терминами:

- идентификатор (идентификация roleType),

- [Должен иметь допустимое значение идентификатора XML (квалифицированное имя). Существует несколько ограничений: * должно быть уникальным в модели, * некоторые символы не разрешены ('/', '$', '#', '@', ...), * без пробелов, * не должно начинаться с цифры]

- описание (спецификация roleType),

- ответственности (область действия, задача, задача поддержки и обратная связь),

- метаданные (последнее изменение, справочная информация и т.д.).

Следующие четыре роли данного примера определены в структуре (см. приведенный ниже пример в представлении XML):

С.3 Сообщение в транзакции

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

С.3.1 TransactionType

Транзакции определяются в структуре как 'TransactionTypes'. Каждый TransactionType может быть определен следующими терминами:

- идентификатор (идентификация TransactionType),

- описание (спецификация TransactionType),

- метаданные (результат применения TransactionType, справочная информация и т.д.),

- типы RoleType, которые включены в TransactionType.

Следующие четыре типа TransactionType в данном примере изображены в приведенном ниже представлении XML:

- Т1: Обмен проектом;

- Т2: Обмен системной спецификацией;

- Т3: Обмен 3D-моделью;

- Т4: Обмен расчетом стоимости.

IDM выделяет роль, делающую запрос (инициатор), и роль, обеспечивающую осуществление этого запроса (исполнитель). В каждой транзакции может быть только одна инициирующая роль и одна исполняющая роль. Например, тип TransactionType, имеющий значение 'Т3 Deliver 3D model' (Обмен 3D-моделью), может быть инициирован только ролью R1 Project leading (Управление проектом) и выполнен инженером - разработчиком трехмерных моделей в роли R3.

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

С.3.2 TransactionPhaseType

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

В данном примере определены следующие типы TransactionPhaseType, соотносящиеся с рисунком 2 в разделе 3:

- желательный результат;

- результат запрошен;

- результат обещан;

- результат получен;

- результат объявлен;

- результат принят.

В приведенном ниже примере показано определение TransactionPhaseType в представлении XML:

С.3.3 MessageType

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

В каждом сообщении имеются группы сегментов (составных элементов). Эти составные элементы определяются типами ComplexElementType. В каждом сегменте может находиться совокупность составных элементов и/или одиночных элементов. Одиночные элементы определяются типами SimpleElementType.

В приведенном ниже примере показано определение типов MessageType в представлении XML, изображенное графически на рисунке 5 в разделе 3:

- запрос 3D-модели;

- задание выполнено, запрос одобрения;

- запрос корректировок;

- задание утверждено;

- задание не утверждено.

MessageType также используется для идентификации сообщений в транзакции. Отношение между messageType и transactionType определяется в другом типе: MessageInTransactionType.

С.3.4 MessageInTransactionType

Транзакция содержит набор сообщений, обмен которыми выполняется для какой-либо цели. Определения MessageInTransactionType обеспечивают связывание MessageTypes с TransactionTypes. Один и тот же тип MessageType может быть связан со всеми определенными типами TransactionType. Также можно связать один и тот же MessageType более одного раза (даже неограниченное число раз) с тем же самым TransactionType.

Каждый MessageInTransactionType может быть определен следующими терминами:

- идентификатор (идентификация MessageInTransactionType),

- направление сообщения, которое должно быть отправлено (от инициатора к исполнителю = true; от исполнителя к инициатору = false),

- метаданные MessageInTransactionType,

- ссылка на тип MessageType (положение которого определено в типе MessageInTransactionType),

- ссылка на тип (или типы) TransactionType для связывания с типами MessageType, на которые дана ссылка,

- ссылка на TransactionPhase (фазу), в состояние которой переходит процесс (после отправки MessageType в типе TransactionType, как это было определено типом MessageInTransactionType),

- ссылка на тип GroupType.

В приведенном ниже примере показано определение в представлении XML двух типов MessageInTransactionType из примера запроса трехмерной модели. Пример будет понятен, если ознакомиться с рисунком 5 (в ISO 29481-2 IDM, часть 2 Карта взаимодействия; глава 3).

Приведенный ниже пример в представлении XML показывает, что TransactionType Т3 запускается с помощью MessageType 'Запроса трехмерной модели'. Это первое сообщение в транзакции, поскольку не существует предыдущих типов MessageInTransactionType, определенных в MessageInTranactionType 'MessageInTransaction1'. Направление MessageInTransaction1 указано как "от инициатора к исполнителю" (значение = true).

Второй тип MessageInTransactionType, определенный как 'MessageInTransaction2', ссылается на тип MessageType 'Задание выполнено, запрос одобрения'. Рисунок 5 показывает, что это сообщение должно следовать за двумя предыдущими сообщениями:

- Запроса трехмерной модели;

- Запрос корректировок.

Эти два предыдущих сообщения определены как типы MessageInTransactionType (номер 1 и номер 3) в MessageInTransactionType2. Направление MessageInTransaction2 указано как "от исполнителя к инициатору" (значение = false).

С.3.5 AppendixTypes

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

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

В приведенном ниже представлении XML показано определение AppendixType. Метаданные определяются типами SimpleElementType в ComplexElementType 'AppendixComplexElement'.

C.3.6 Ограничение содержимого сообщений

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

- структурировать типы MessageType;

- ограничить входные данные содержимого.

Определение MessageType уже содержит составные элементы сообщения. Эти составные элементы определены как типы ComplexElementType.

Типы ComplexElementType состоят из типов SimpleElementType (или, возможно, также из других типов ComplexElementType). Типы SimpleElementType связываются с типами UserDefinedType для определения ограничений входных данных содержимого. Эта структура графически изображена ниже.

Рисунок С.2 - Компоненты моделирования сообщения

С.3.7 Типы ComplexElementType

Определения ComplexElementType обеспечивают:

- ограничение информационных элементов компонентов,

- используемых механизмами иерархия определений типов (в XML) для получения сложного типа из другого простого или сложного типа,

- определения вклада в проверку соответствия схемы документу (post-schema-validation infoset) для элементов,

- ограничения возможности получения дополнительных типов из заданных сложных типов,

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

Если обратиться к приведенному примеру использования MessageType 'Запрос трехмерной модели', связанного с транзакцией Т3 (Запрос трехмерной модели), этот MessageType содержит следующие типы ComplexElementType:

- resultRequestedComplexElement;

- workIdentificationComplexElement;

- workSpecificationComplexElement;

- remarksComplexElement;

- deadlineComplexElement.

Тип ComplexElementType 'WorkSpecification' показан ниже в представлении XML. ComplexElementType определяет его идентификацию, ссылку на простые элементы, которые передают содержимое в ComplexElementType, и его метаданные.

В XML-представлении для ComplexElementType 'WorkSpecificationComplexElement' показано, что ComplexElementType содержит два типа SimpleElementType:

- ScopeOfWork;

- CostEstimation.

C.3.8 Типы SimpleElementType

Определения типа SimpleElementType обеспечивают:

- определение его идентификации,

- задание 'пространства значений' и ограничений входных данных.

В приведенном ниже представлении XML показано определение одного типа SimpleElementType: CostEstimation. Этот тип SimpleElementType является частью типа ComplexElementType 'WorkSpecificationComplexElementType' (из предыдущего примера).

C.3.9 Типы UserDefinedType

Типы UserDefinedType используются для определения ограничений для входных данных содержимого (путем определения типов dataType). Все возможные ограничения XML разрешено использовать для определения типов UserDefinedType в структуре взаимодействия. В данном примере использованы только типы данных 'STRING' и 'EURO'.

В приведенном ниже примере показано в представлении XML определение типа UserDefinedType, обеспечивающего:

- идентификацию,

- метаданные,

- baseType,

- ограничение XSD (для более конкретного определения ограничения или для определения типов перечислений).

С.3.10 Заключение

Были определены все типы ElementType, достаточные для создания структуры взаимодействия. Для проверки правильности необходимо проверить соответствие структуры ее схеме XSD. Следующим шагом должно быть продвижение структуры взаимодействия для получения схемы взаимодействия. Эти действия описаны в подразделе 4.8.