ГОСТ Р 10.0.03-2019/ИСО 29481-1:2016
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Система стандартов информационного моделирования зданий и сооружений
ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ В СТРОИТЕЛЬСТВЕ
Справочник по обмену информацией
Часть 1
Методология и формат
System of standards on information modeling of buildings and structures. Building information models. Information delivery manual. Part 1. Methodology and format
ОКС 91.010.01
35.240.67
35.240.01
Дата введения 2019-09-01
Предисловие
1 ПОДГОТОВЛЕН Ассоциацией организаций по развитию технологий информационного моделирования в строительстве и ЖКХ (БИМ-Ассоциация) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Проектным техническим комитетом по стандартизации ПТК 705 "Технологии информационного моделирования на всех этапах жизненного цикла объектов капитального строительства и недвижимости"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 5 июня 2019 г. N 279-ст
4 Настоящий стандарт идентичен международному стандарту ИСО 29481-1:2016* "Информационное моделирование в строительстве. Справочник по обмену информацией. Часть 1. Методология и формат" (ISO 29481-1:2016 "Building information models - Information delivery manual - Part 1: Methodology and format", IDT).
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
5 ВЗАМЕН ГОСТ Р 57310-2016 (ИСО 29481-1:2010)
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
Информационное моделирование объектов строительства представляет собой цифровую технологию описания и представления информации, необходимой для планирования, проектирования, строительства и управления построенными объектами. В последнее время этот подход к моделированию стал значительно расширяться, охватывая все аспекты городской среды, включая гражданскую инфраструктуру, коммунальные услуги и общественные пространства. В совокупности все это называется строительными процессами. Такой подход к управлению информацией объединяет разнородные наборы сведений, используемых в течение всего жизненного цикла строящегося объекта, в единую информационную среду, уменьшая и зачастую даже исключая необходимость использования многих видов бумажной документации, традиционно используемых в настоящее время.
Этот подход называют информационным моделированием объектов строительства (BIM). Название отражает его первоначальное применение в архитектуре, однако это же сокращение используется для обозначения результата данного процесса, т.е. самой информационной модели объекта строительства (BIM).
Хотя основное внимание в описанных выше строительных процессах обращено на физическую структуру строящегося объекта, технология BIM также повышает эффективность управления пространством зданий, городских кварталов и - в еще более широких масштабах - городов, инфраструктурных сетей и объектов коммунального хозяйства. Описанные выше случаи называются "применениями".
Справочник по обмену информацией способствует наиболее эффективному применению BIM. Если требуемая для поддержки строительного процесса или какого-либо другого варианта использования информация доступна в формате BIM, а ее качество является удовлетворительным, то сам процесс значительно улучшается.
Для этого необходимо единое понимание всех процессов на протяжении развития всего жизненного цикла объекта, включая информацию, требуемую для осуществления этого процесса и являющуюся его результатом. Это относится к любой деятельности, приводящей к обмену информацией, даже если она не относится непосредственно к BIM (например, процесс обсуждения календарного плана или договорного соглашения).
В настоящем стандарте излагается методология составления комплексного справочного документа, описывающего все процессы и данные, необходимые для реализации развития и управления уже построенным объектом. В нем описывается, как находить и описывать нужные процессы, необходимую для их выполнения информацию и результаты. Также в настоящем стандарте кратко описывается, как эту информацию можно детализировать для поддержки решений, предоставляемых разработчиками программного обеспечения для ее повторного использования, и адаптировать для удовлетворения национальных, местных и проектных нужд.
Таким образом, настоящий стандарт представляет собой основу для надежного обмена информацией и ее совместного использования, гарантирующую, что пользователи получат точную и полную информацию для выполнения ими своих профессиональных обязанностей. Разработка настоящего стандарта обусловлена потребностью участников процесса в надежном обмене информацией.
1 Область применения
В настоящем стандарте описываются методология, связывающая выполняемые в ходе строительства бизнес-процессы со спецификацией информации, требуемой этими процессами, и способ сопоставления и описания информационных процессов на протяжении всего жизненного цикла объектов строительства.
Настоящий стандарт предназначен облегчить интероперабельность программных средств, используемых на всех этапах жизненного цикла строительных объектов, включая постановку задач, проектирование, разработку документации, строительство, эксплуатацию, техническое обслуживание и снос. Он также способствует переводу взаимодействия между акторами процесса строительства на платформу цифровых информационных технологий и обеспечивает основу для точного, надежного, повторяемого и высококачественного обмена информацией.
2 Нормативные ссылки
В настоящем стандарте использована нормативная ссылка на следующий международный стандарт:
ISO 6707-1, Buildings and civil engineering works - Vocabulary - Part 1: General terms (Здания и сооружения. Словарь. Часть 1. Общие термины)
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 актор (actor): Лицо, организация или организационная единица (отдел, команда и т.д.), участвующие в строительном процессе.
3.2 технологии информационного моделирования (зданий и сооружений): Деятельность по созданию, управлению и хранению электронной информации о зданиях и сооружениях на всех или отдельных стадиях их жизненного цикла, результатом которой является создание информационной модели здания или сооружения.
Примечание - Термин "технологии информационного моделирования" равнозначен англоязычному термину "Building Information Modeling" (BIM) и может использоваться в национальных стандартах, документах по стандартизации и любых других нормативных и нормативно-технических документах в качестве аббревиатуры "ТИМ".
3.3 программное обеспечение BIM (BIM software application): Программное обеспечение, используемое для создания, модификации, анализа, управления, публикации, совместного использования, завершения или выполнения иных действий с элементами BIM.
3.4 бизнес-требование (business requirement): Требование, описывающее в терминах деловой среды, что необходимо предоставить или выполнить.
3.5 информационное ограничение (information constraint): Положение, формально определяющее или ограничивающее сферу действия информации ввиду какого-либо аспекта деловой деятельности, правило, в соответствии с которым действует организация, а также политика или решение, оказывающие влияние на процесс.
3.6 класс (class): Тип или набор предметов, обладающих общими свойствами.
3.7 объект строительства (construction works): Все, что построено или является результатом строительства.
Примечание - Данным термином может обозначаться здание, часть инфраструктуры (часть инфраструктуры - дорога, мост, трубопровод и т.д.) или элемент ландшафта, а также совокупность этих элементов, формирующих городской район, университетский городок или другое учреждение.
3.8 строительный процесс (construction process): Процесс, использующий строительные ресурсы для достижения результатов строительства.
Примечание - Строительный процесс может подразделяться на составляющие его процессы.
3.9 требование к обмену информацией (exchange requirement; ER): Конкретный набор информационных единиц, которыми необходимо обмениваться для соблюдения определенного бизнес-требования на определенных стадиях или этапах процесса.
3.10 справочник по обмену информацией (information delivery manual; IDM): Документация, фиксирующая бизнес-процесс и дающая подробное описание информации, которую на определенном этапе проекта должен предоставить пользователь, выполняющий определенную роль.
Примечание - Данную документацию называют также "спецификацией обмена информацией" (IDM - сокр. от англ. information delivery specifcation).
3.11 компоненты IDM (IDM components): Базовые элементы, формирующие IDM: карты взаимодействия (транзакций), карты процессов и требования к обмену информацией.
3.12 информационная единица (information unit): Отдельный информационный элемент, такой как идентификатор окна или высота помещения.
3.13 карта взаимодействия (interaction map): Представление ролей и транзакций, имеющих отношение к конкретной цели.
3.14 инфраструктура взаимодействия (interaction framework): Формальное описание элементов взаимодействия, включая определение ролей, транзакций, сообщений в транзакциях и элементов данных в сообщениях.
3.15 модель (model): Представление системы, позволяющее исследовать ее свойства.
3.16 определение модельного вида (model view definition; MVD): Спецификация, устанавливающая техническое описание процесса реализации IDM для разработчиков программного обеспечения.
Примечание - Спецификация MVD (Model View Definition - Определение модельного вида) установлена в качестве спецификации международной некоммерческой организации buildingSMART International.
3.17 объект (object): Часть реального или воображаемого мира.
Примечание - Объект - это умственная или физическая сущность, на которую направлена мысль, чувство или действие.
3.18 технологическая карта (process map, PM): Представление характеристик процесса, соответствующего поставленной цели, в виде карты.
3.19 роль (role): Функции, выполняемые актором в определенный момент времени.
Примечание - Роль актора определяется не столько его профессией или родом занятий, сколько действием и результатом.
3.20 транзакция (transaction): Коммуникационное событие, осуществляющее взаимосвязь между двумя ролями.
3.21 карта транзакции (transaction map): Представление набора сообщений, которыми обмениваются участвующие роли с определенной целью.
4 Справочник по обмену информацией
4.1 Общие положения
В этом разделе описывается ряд понятий и принципов, применяемых при разработке IDM.
4.2 Аудитория настоящего стандарта
Настоящий стандарт предназначен, прежде всего, для разработчиков IDM, создающих карты взаимодействия, технологические карты, требования к обмену информацией и информационные ограничения на основании сведений, полученных от конечных пользователей и поставщиков программного обеспечения.
Помимо этого, у пользователей конкретных IDM могут появиться потребности в разработке новых IDM, что также включит их в аудиторию настоящего стандарта. К ним относятся:
- профессиональные разработчики IDM и поставщики ПО;
- пользователи информации, то есть руководители и конечные пользователи, занимающиеся наполнением IDM и пользующиеся ими.
Настоящий стандарт предназначен также для тех, кто использует разрабатываемую на основе настоящего стандарта документацию с учетом конкретного бизнес-процесса и подробных спецификаций информации, которую лица, выполняющие ту или иную определенную роль, должны предоставлять на определенном этапе проекта. К ним относятся:
- менеджер проекта, ответственный за организацию бизнес-процесса и обеспечивающий надлежащее управление обменом информацией;
- менеджер BIM, принимающий все необходимые меры для соблюдения требования об обмене информацией;
- клиент, инициирующий (разрабатывающий) IDM и включающий его в договор;
- подрядчик или консультант, использующий IDM для принятия необходимых мер для соответствия требованиям к бизнес-процессу и требованиям по обмену информацией;
- бизнес-менеджер, использующий IDM в качестве шаблона или стандарта для применения в проектах в рамках своей организации;
- строительная организация, использующая IDM для особого типа проектов в качестве шаблона или стандарта для применения в конкретной области специализации.
4.3 Бизнес-контекст
На рисунке 1 показан пример бизнес-контекста, требующего IDM: клиент (роль 1) привлекает консультанта (роль 2) для оказания некоторой услуги. В таком сценарии необходимо понять и формализовать как общие, так и договорные аспекты их взаимоотношений, а также способ передачи информации в этом контексте. IDM описывает требования к информации, относящиеся ко всем транзакциям (в обоих направлениях), связанным с этими отношениями. Некоторая часть этой информации будет храниться в BIM, в то время как другая может поступать от любого участника или из внешнего источника.
|
Рисунок 1 - Пример простого бизнес-контекста, требующего IDM
Первым шагом в разработке IDM является изучение природы или контекста обмена информацией. Есть два способа такого рассмотрения, каждый из которых связан с соответствующей методологией.
Технологические карты наиболее полезны в контекстах, уделяющих основное внимание самим бизнес-процессам (определяемым действиями, выполняемыми акторами с ролями), которые необходимо соблюдать для оказания услуги или создания конечного изделия (например, проекта). В этом случае IDM концентрируется на информации, связанной с бизнес-требованиями.
Карты взаимодействия/транзакций наиболее полезны для бизнес-процессов, в которых основное внимание уделяется взаимодействию между акторами, выполняющими роль оказания услуги или поставки изделий, а ключевой задачей является обеспечение согласованных коммуникационных протоколов для достижения целей проекта. В этом случае IDM нацеливается на информацию, связанную с транзакциями.
Эти подходы являются взаимно дополняющими и более подробно объясняются в последующих разделах. В рамках конкретного бизнес-контекста может быть целесообразным использовать обе методологии: составлять технологические карты для уточнения деталей транзакции, идентифицированной в задаче сопоставления взаимодействия, тогда как карта взаимодействия может использоваться для строгого понимания информационной транзакции, определенной в карте процесса.
4.4 Полная схема
Когда требования к информации удовлетворяются BIM, полная информационная схема, охватывающая всю информацию, необходимую всем акторам строительного процесса, будет большой и всеобъемлющей. Такая схема имеет важное значение для определения всех потребностей в информации о проекте для всех бизнес-процессов на всех этапах жизненного цикла. Однако информация при реализации проекта обычно передается не в таких больших объемах.
4.5 Разделение полной схемы для обеспечения соблюдения требований
Более привычным является обмен информацией по определенной теме и с определенным уровнем детализации, определяемым этапом жизненного цикла. Это может быть отдельный бизнес-процесс, относящийся к определенному этапу жизненного цикла проекта, но, как правило, он состоит из информационных единиц, которые могут иметь отношение к нескольким этапам жизненного цикла или бизнес-процессам. Это обычно называют представлением модели, и речь идет о том, какие компоненты информационной схемы должны использоваться для удовлетворения требований.
4.6 Поддержка процесса информационного моделирования объектов строительства
Элементы общей информационной схемы используются в информационной модели объекта строительства (см. рисунок 2). Для отдельно взятого бизнес-процесса требуются только определенные классы информации. Из каждого класса выделяются несколько объектов, причем каждый объект имеет идентичность (определяется уникальным идентификатором) и состояние (определяемое значениями, присвоенными каждому атрибуту объекта). Классы, поддерживающие бизнес-процесс, образуют уникальную и идентифицируемую стандартную схему или представление модели.
|
Рисунок 2 - Поддержка процесса BIM
4.7 Поддержка бизнес-процесса
Для этого необходимо установить набор информации, обмен которой требуется для поддержки конкретного бизнес-процесса или взаимодействия на соответствующих этапах жизненного цикла (в рамках бизнес-процесса). Такой набор информации называется требованием к обмену.
Требование к обмену представляет собой описание передаваемой информации в нетехнических терминах. Требование к обмену может поддерживать передачу информации объекта, обеспечивающей строительство и управление проектом, или поддерживать передачу информации по контролю за выполнением проекта.
4.8 Поддержка программного решения
Для перехода от определенного требования к обмену к программной реализации, которую предоставляет поставщик решения, необходима разработка определения модельного вида (MVD).
4.9 Характерное содержимое IDM
Характерное содержимое IDM должно:
- описывать потребность в обмене информацией в бизнес-контексте;
- определять акторов, отправляющих и получающих информацию;
- определять, уточнять и описывать информацию, обмен которой требуется для соблюдения требований во всем бизнес-контексте;
- обеспечивать применимость и понятность форм представления определений, спецификаций и описаний;
- создавать подробные спецификации информации, фиксируемой в требованиях к обмену, для облегчения разработки программных приложений BIM, что позволит
- применять полученные спецификации информации к местным методам работы.
Указания по определению содержимого IDM и выбору подхода к его разработке приводятся в приложении А.
5 Инфраструктура IDM
5.1 Общие положения
Каждое руководство по обмену информацией содержит (рисунок 3):
- карту взаимодействия/транзакции и/или технологическую карту;
- одно или несколько требований к обмену информацией.
Карта взаимодействия определяет задействованные роли и транзакции между ними. Для каждой определенной транзакции одна роль является инициатором, а другая - исполнителем. Соответствующая карта транзакции определяет сообщения в транзакции и правила, которые применяются к последовательности выполнения.
Технологическая карта выделяет для каждой роли свою "полосу движения" в виде "дорожки" и определяет в ней соответствующую последовательность действий, которые должны выполняться этой ролью. Выполняемые разными ролями действия могут иметь отношения, для которых требуется обмен информацией в форме сообщения. Такие сообщения соответствуют сообщению в транзакции, отображаемой на карте транзакции.
|
Рисунок 3 - Базовая инфраструктура IDM
Некоторые сообщения могут содержать пакет информации в формате BIM, что приводит к необходимости определить требование к обмену.
Требование к обмену содержит исчерпывающее описание информации, которая должна быть включена в модель BIM, связанную с сообщением, передаваемым между ролями. Оно включает определения требований к информации, в том числе ссылки на объекты библиотек, где это уместно, а также описание необходимости, рекомендации по использованию и любые ограничения информации, которые могут применяться.
Техническая реализация требования к обмену выполняется через определение представления модели. Техническая реализация карты взаимодействия/транзакции предоставляется в инфраструктуре взаимодействия.
5.2 Базовая инфраструктура
5.2.1 Общие положения
Каждый компонент IDM (технологическая карта процесса, карта взаимодействия/транзакции или требование к обмену) должен содержать заголовок и общие сведения о компоненте согласно нижеприведенным требованиям.
5.2.2 Информация заголовка компонента IDM
Каждый компонент IDM должен включать по меньшей мере следующую административную информацию:
- имя или название, соответствующие правилам наименования, приведенным в таблице 1;
- уникальный идентификатор;
- этап проекта, поддерживаемый компонентом;
- журнал изменений, фиксирующий создание компонента и все вносимые в него изменения с указанием автора и даты.
Таблица 1 - Правила именования
N | Правило именования |
1 | Каждый компонент IDM должен иметь имя |
2 | Первая часть каждого имени - это префикс: |
3 | Имя, данное каждому компоненту IDM, является императивом, состоящим из двух частей: |
4 | Все распознаваемые слова в имени разделяются символом подчеркивания "_" |
5 | Компоненты IDM могут иметь дополнительные квалифицирующие параметры. Эти параметры выражаются в виде списка, помещенного в круглых скобках, например (a, b, c, d) |
Этап проекта определяется этапом жизненного цикла объекта строительства. Справка по этапам жизненного цикла приведена в приложении C.
При передаче каждой информационной единицы может быть целесообразной ссылка на требование к обмену соответствующей информацией.
5.2.3 Общие сведения о компонентах IDM
Каждый компонент IDM должен начинаться с краткого простого описания содержимого, случаев использования, целей и области применимости, которым должен отвечать компонент, или с описания, какая информация о конкретном предмете или бизнес-требовании должна участвовать в обмене.
Примеры упрощенных компонентов IDM приведены в приложении B.
5.3 Карта взаимодействия/транзакции
Целью карты взаимодействия является указание соответствующих ролей и транзакций с определенной целью, как правило, при коллективном выполнении задачи проекта. IDM различает роль, делающую запрос (инициатор) и роль, выполняющую этот запрос (исполнитель). Если между двумя ролями возникает такая связь, она называется транзакцией.
Рекомендованный подход для подготовки карты взаимодействия формулируется согласно модели CRISP (Dietz, J.L.G.: Enterprise Ontology, Springer, 2006).
В карту взаимодействия должны быть включены все транзакции, необходимые для обработки требуемых вкладов соответствующих ролей в процесс BIM. У каждой транзакции в карте взаимодействия есть уникальный идентификатор и имя.
Карта транзакции - это представление сообщений, которыми могут обмениваться задействованные роли в конкретной транзакции, включая ограничения на последовательность. Для подготовки карты транзакции рекомендуется подход UML (Unified Modeling Language - диаграмма последовательности).
Обмен сообщениями осуществляется с определенной целью (например, при запросе на внесение изменений или передачу пакета информации). Сообщение представляет собой заполненную информационную модель, содержащую данные, относящиеся к процессу. Сообщение может иметь одно или несколько вложений.
С помощью транзакций определяются требования к деловому сотрудничеству и взаимодействию, позволяющие контролировать вклад соответствующих ролей в BIM. С этой целью в конкретных транзакциях в качестве вложений к определенным сообщениям могут добавляться следующие компоненты:
- требование к обмену;
- информационный пакет (набор данных объекта, представляющий фактически предоставляемую информацию, удовлетворяющую требованиям к обмену);
- окно авторизации: в ходе транзакции исполнительная роль (исполнитель) может получать доступ к программным приложениям BIM. Окно авторизации описывает, какую информацию в этой транзакции роль может читать или изменять.
5.4 Технологические карты
Цель технологической карты заключается в описании потока действий в рамках конкретного бизнес-процесса; ролей, исполняемых его акторами, и информации, которая для этого процесса требуется, используется или создается.
Для представления технологических карт рекомендуется использовать подход BPMN (Business Process Modelling Notation, "Нотация для моделирования бизнес-процессов"). Дополнительные сведения о BPMN приведены в приложении D.
Технологическая карта в составе IDM:
- устанавливает границы для объема информации, содержащейся в процессе,
- устанавливает действия, выполняемые в рамках процесса, и
- показывает логическую последовательность этих действий.
Фактическая информация, находящаяся в пределах границ процесса, определяется содержимым требований к обмену, указанным в процессе.
Технологическая карта включает следующую административную информацию:
- требования к обмену, лежащие в пределах границ процесса;
- обзор, который дает полное описание общего процесса.
Диаграммы могут использоваться для иллюстрации отдельных пунктов в обзоре.
5.5 Требования к обмену информацией
5.5.1 Общие положения
Требование к обмену определяет информацию, которой необходимо обменяться для соблюдения конкретного бизнес-процесса на определенном этапе проекта. Оно предназначено для представления описания информации в нетехнических терминах. Требование к обмену должно быть понятно конечным пользователям (архитектору, инженеру, конструктору и т.д.). Требования к обмену используются для создания определения модельного вида (MVD), представляющего собой техническую спецификацию, применяемую при разработке программного обеспечения и описанную в 5.6.3.
Требование к обмену представляет собой связь между процессом и данными. Оно описывает набор информации из процесса, который был выполнен актором в роли инициатора, чтобы активировать последующий процесс, который должен быть выполнен другим актором в роли исполнителя. Требование к обмену должно быть определено с четким пониманием информационных потребностей последующего актора.
5.5.2 Информационные единицы
Требуемая информация предоставляется набором информационных единиц. Информационная единица обычно относится к одному типу информации или концепции, представляющей интерес. Информационная единица может состоять из одной сущности, например, "проект" и "стена", или из сущности и ее атрибута, например, "имя проекта" и "длина стены".
Сначала определяются предусловия для требования к обмену. Предусловие - требование к обмену, которое должно было быть выполнено до исполнения текущего требования к обмену.
Далее должны быть указаны информационные единицы, обеспечивающие следующее:
- описание информационной единицы: описание должно быть максимально точным и достаточно однозначным, чтобы MVD-моделлеры не путали их с другими понятиями;
- информацию, предназначенную для обмена, чтобы положения, относящиеся к этой информационной единице, были соблюдены. Сюда относятся специальные положения, предложения или правила, связанные с данной информацией.
5.5.3 Информационные ограничения
Информационные ограничения определяют тип данных информационной единицы, а также контекст, правила и ограничения использования указанной информационной единицы. Ниже представлены несколько примеров типа данных и правил.
Типы данных: текст, целое число, номер, 2D-графика, 3D-модель и т.д.
Контекст, правила и ограничения использования:
- у стола должно быть не менее трех ножек;
- сборное железобетонное изделие должно иметь не менее трех идентификаторов: марку изделия (производственный серийный номер), маркировочный номер (проектный номер) и идентификатор местоположения монтажа;
- площадь комнаты не может быть меньше 0 м;
- для доставки обычным грузовиком максимальный размер панели не должен превышать 14 м.
5.6 Техническая реализация
5.6.1 Общие положения
Настоящий стандарт посвящен подготовке единого языкового описания требований к информации о бизнес-процессах, главным образом относящейся к процессам, включающим в себя обмен данными в формате BIM. Эти информационные спецификации могут использоваться в качестве основы для автоматизированных процессов с использованием программных приложений, называемых в настоящем стандарте техническими реализациями.
В этом разделе описаны принципы и область действия доступных технических реализаций, каждая из которых является темой отдельной части в этой серии стандартов.
5.6.2 Реализация метаданных
Главным назначением всех технических реализаций является преобразование спецификаций в машиночитаемую форму, содержащую необходимые для автоматизированного процесса ключевые метаданные (заголовок, общие сведения, классификацию).
5.6.3 Инфраструктура взаимодействия
Инфраструктура взаимодействия - это формальное описание элементов взаимодействия, включая определение ролей, транзакций, сообщений в транзакции, последовательности сообщений и элементов данных в сообщениях. Методология разработки инфраструктуры взаимодействия и ее формата включена в ИСО 29481-2 [1].
5.6.4 Определение модельного вида (MVD)
MVD (Model view definition) определяет модель данных или подмножество существующей модели данных, необходимые для соблюдения одного или нескольких конкретных требований к обмену данными (рисунок 4). MVD используются в разработке программного обеспечения и должны иметь машиночитаемое представление. Определение модельного вида (MVD), относящееся к одному справочнику по передаче информации (IDM, Information Delivery Manual), может использоваться для фильтрации информации в программных средствах для конкретного требования к обмену информацией. Если информационные ограничения добавляются к MVD, то эта комбинация может использоваться в целях валидации данных. В программных продуктах, поддерживающих несколько требований к обмену, могут быть реализованы объединенные MVD, ссылающиеся на несколько IDM. Объединенные MVD часто используются в сертификации программных продуктов, но проверка данных всегда должна выполняться для каждого отдельного MVD.
|
Рисунок 4 - Связь между IDM и MVD
Приложение A
(справочное)
Процесс разработки IDM
А.1 Внесение предложения о разработке IDM
А.1.1 Общие сведения
Внесение предложения о разработке IDM - это предварительный этап, который задает необходимые условия для выполнения работы. На данном этапе:
- определяется область действия;
- устанавливается подход к разработке;
- определяются ресурсы;
- устанавливается план проекта.
А.1.2 Определение области действия
Область действия должна устанавливать границы для работы, которая должна быть выполнена, и предоставлять непрерывно действующую ссылку, позволяющую убедиться, что рабочие границы не выходят за точку, в которой запланированный или доступный ресурс перестает быть достаточным.
При подготовке необходимо ответить на следующие вопросы:
- Каковы бизнес-потребности в обмене информацией?
- Кто может описать эти потребности?
- Кто будет акторами, каковы их роли и интересы?
- Как может быть подготовлен и осуществлен обмен информацией?
- Будут ли существующие соглашения, контрактные условия, стандарты и т.д. поддерживать обмен информацией? Подготовка заканчивается оценкой возможности достижения указанной области действия и критериев успеха. В случае положительной оценки может быть инициирована фактическая разработка IDM. Если оценка окажется негативной, можно принять решение: пересмотреть сценарий использования бизнес-процесса или остановить разработку.
Необходимо предоставить обзор существующих ресурсов наряду с любыми необходимыми ИТ-ресурсами. Обзор может показать, что цели могут быть достигнуты, что в свою очередь позволяет включить разработку IDM.
Обзор может продемонстрировать, что бизнес-цели не могут быть достигнуты. В этом случае следует пересмотреть цели в соответствии с доступными и возможно новыми заданными ИТ-ресурсами. В противном случае акторы могут отказаться от разработки IDM.
Должны быть описаны вопросы обмена практической и правовой информацией, чтобы было ясно, кто что делает и кто за что отвечает. Условия соглашений и договорные условия могут препятствовать достижению определенных ранее целей и выполнению условий, необходимых для успешного завершения проекта. Возможно, цели могут быть пересмотрены, чтобы они соответствовали соглашениям и стандартным условиям.
А.1.3 Выработка подхода к разработке IDM
Выбранный подход к разработке определяется объемом информации, программным обеспечением и другими имеющимися требованиями к обмену. Возможные подходы описаны в А.2.1.
А.1.4 Выявление ресурсов
Ресурсы - это люди, которым необходимо участвовать в разработке IDM. Ресурсы должны быть правильно сбалансированы между управлением проектами, разработкой компонентов IDM и отраслевыми знаниями, чтобы можно было осуществлять руководство как разработкой компонентов, так и разработкой программных решений. Баланс требуемых ресурсов будет зависеть от выбранного пути разработки.
А.1.5 План работы
План работы устанавливает период, в течение которого должна происходить разработка, определяет задачи, которые необходимо выполнить, назначает доступные ресурсы и задает требуемые результаты.
А.2 Разработка IDM
А.2.1 Общие сведения
Существует три подхода к разработке IDM:
- выявление процесса;
- настройка информационных ограничений;
- воспроизведение недокументированного изделия.
А.2.2 Выявление процесса
А.2.2.1 Общие сведения
Выявление процесса - это традиционный подход, используемый при разработке IDM. Он предполагает, что не существует программного обеспечения, с помощью которого могут быть получены требования, или других требований к обмену, которые могут быть настроены.
Этот подход к разработке описан ниже в виде линейной последовательности. На практике можно ожидать наличия обратной связи между этапами разработки и циклическими изменениями.
А.2.2.2 Процесс выявления
Существуют две альтернативные предлагаемые методологии: составление технологической карты и составление карты взаимодействий. Необходимо принять решение о наиболее применимом подходе для данного бизнес-контекста.
Процесс выявления предусматривает работу главным образом с отраслевыми экспертами и поставщиками специализированных информационных систем в строительстве для определения установленной области действия, технологической карты или инфраструктуры взаимодействия.
Для достижения удовлетворительного результата этого процесса обычно требуется несколько циклов разработки и проверки. После этого технологическая карта или инфраструктура взаимодействия может описывать имеющийся опыт или предложения по улучшению такового. В рамках разработки необходимо принять решение - создать процесс "как есть" или процесс "как должно быть".
Технологические карты и карты взаимодействий будут определять "пакеты" данных, которые должны участвовать в обмене в разных точках бизнес-процесса. Они представляют собой требования к обмену.
А.2.2.3 Создание требования к обмену
Затем должны быть созданы требования к обмену. По возможности в них должны повторно использоваться ресурсы существующих требований к обмену.
А.2.3 Настройка информационных ограничений
А.2.3.1 Определение информационных ограничений
Необходимо определить набор информационных ограничений, применение которых может потребоваться для дальнейшего конфигурирования существующего (или вновь определенного) требования к обмену. Они могут использоваться для управления свойствами, которые должны быть заданы, или значениями, которые должны быть присвоены.
А.2.3.2 Локализация информационных ограничений
Локализация информационных ограничений предполагает, что требование к обмену существует для требуемой цели, но не отвечает потребностям использования в конкретном местоположении. Местоположение может быть местом (страной, областью и т.п.), рабочим проектом или инфраструктурой, согласованной между участниками проекта.
Информационные ограничения применяются к отдельным единицам информации в контексте требования к обмену, чтобы сделать их применимыми в конкретном местоположении. Для одной и той же информационной единицы могут существовать другие информационные ограничения, применяемые в контексте другого требования к обмену или применяемые для другого местоположения.
А.2.4 Обратное проектирование
А.2.4.1 Общие сведения
Обратное проектирование (воспроизведение недокументированного изделия) предполагает, что уже существует программное обеспечение, дающее возможность импортировать информацию, необходимую для выполнения целевой задачи, но конкретные элементы информации задокументированы неточно. Этот процесс не подходит для идентификации требования к информации при экспорте данных, поскольку могут существовать различные сценарии использования информации при экспорте данных. Следовательно, требование к информации для экспорта данных должно задаваться с учетом потребностей принимающего приложения. Типичный способ выполнения такого обратного проектирования - это определение каждого шага в программном средстве для достижения целевого результата и последующая работа по данному сценарию с целью идентификации и задания отдельных элементов данных, требующихся от изначального программного приложения.
А.2.4.2 Определение сценария
Следует определить в программном приложении каждый шаг, необходимый для достижения целевого результата, как сценарий. Сценарий может быть определен как технологическая карта или как подробное текстовое описание, которое может использоваться как обзорное описание требования к обмену.
А.2.4.3 Идентификация требуемых данных
Необходимо отработать сценарий, который был определен, в программном приложении и указать все данные, требуемые для достижения целевого результата. Для каждого требуемого элемента данных следует проверить, должен ли элемент быть получен из других программных приложений. Если это так, он должен быть включен в требования к обмену для импорта данных.
А.2.4.4 Создание требования к обмену
Следует создать требование к обмену, используя заданный сценарий в качестве обзорного раздела, и добавить идентифицированные данные в технический раздел. Сценарий можно также задать в виде технологической карты.
А.2.4.5 Определение информационных ограничений
Необходимо определить набор информационных ограничений, применение которых может потребоваться для дальнейшего конфигурирования существующих требований к обмену. Они могут использоваться для управления свойствами, которые должны быть заданы, или значениями, которые должны быть присвоены.
А.2.4.6 Процесс захвата
Так как одно или несколько требований к обмену можно получить из программных приложений путем обратного проектирования, они могут быть включены в технологическую карту или карту взаимодействия.
А.2.5 Реализация и использование IDM
После завершения подготовки и реализации IDM может быть начат процесс обмена информацией. Перед отправкой и при получении данных наборы данных подвергаются проверке на полноту и непротиворечивость.
После того, как акторы получили достаточный опыт обмена информацией, может быть произведена оценка. Оценка охватывает подготовку, а также вопросы разработки и практического внедрения IDM.
Если задействованные акторы желают осуществить сертификацию программного обеспечения в соответствии с разработанным IDM, то должны быть предприняты определенные действия. Во время процесса сертификации программных продуктов необходимо продемонстрировать, что они могут экспортировать и импортировать данные в соответствии с требованиями к обмену информацией. С целью обеспечения его надежности процесс сертификации должен контролироваться независимой организацией. Для подачи поставщиками программного обеспечения заявки на сертификацию должно быть подготовлено экономическое обоснование, поскольку стоимость собственно подготовки и сертификации может быть высока.
Приложение B
(справочное)
Примеры упрощенных компонентов IDM
В.1 Примеры бизнес-контекста
Представленные ниже примеры даны для иллюстрации каждого из компонентов IDM на примере простой бизнес-ситуации, в которой клиент привлекает группу консультантов для выполнения задания на проектирование. Задача состоит в том, чтобы определить структуру строительных объектов. Результат описывается с помощью трехмерных ограничивающих блоков. Фактический справочник по обмену информацией представляет собой набор ограничивающих блоков и оценку стоимости.
Этот пример был значительно упрощен и не предназначен для отражения реального применения.
В.2 Технологическая карта
Название: pm_29481_sample Идентификационное обозначение: pm_29481_sample_1 Этап проекта: Определение практической реализуемости
|
Рисунок В.1 - Технологическая карта
В.3 Карта взаимодействия
Название: im_29481_sample
Идентификационное обозначение: im_29481_sample_1
Этап проекта: Определение практической реализуемости
|
Рисунок B.2 - Карта взаимодействия
В.4 Карта транзакции
Название: tm_29481_sample
Идентификационное обозначение: tm_29481_sample_1
Этап проекта: Определение практической реализуемости
|
Рисунок B.3 - Карта транзакции
В.5 Требование к обмену
Название: er_29481_sample
Идентификационное обозначение: er_29481_sample_1
Этап проекта: Определение практической реализуемости
Указания
Это требование к обмену применяется к получению трехмерных блоков, представляющих минимальный или наименьший ограничивающий блок строительных объектов.
Каждый экземпляр строительного объекта требует наличия ограничивающего блока.
Каждый ограничивающий блок ссылается на заданную центральную проектную ориентацию.
Описание потребности
Требуемая информация будет использоваться для технико-экономического обоснования физической планировки здания.
Информационные единицы
Таблица B.1 - Информационные единицы
Тип объекта
| Определение | Пример и дополнительные объяснения | Обяза- | Дополни- | ||
Строительный объект | Спроектированный, построенный, установленный и т.д. объект для выполнения определенной функции, служащий какой-то цели или оказывающий услугу | Транспортная инфраструктура; образовательные учреждения; новый исследовательский центр | ||||
3D-модель | Трехмерный ограничивающий блок | Минимальный или наименьший ограничивающий блок, или прямоугольная оболочка - это термин, используемый в геометрии, плоскости которого параллельны осям системы координат | ||||
Идентификация | Краткое имя, используемое для справочных целей | X | ||||
Описание | Необязательное описание, предназначенное для обмена информативными комментариями | X | ||||
Длина | Длина ограничивающего блока | Измеренная длина, например в мм | X | |||
Ширина | Ширина ограничивающего блока | Измеренная ширина, например в мм | X | |||
Высота | Высота ограничивающего блока | Измеренная высота, например в мм | X | |||
Местоположение | Местоположение ограничивающего блока в системе координат | Вектор и направление вращения от начала координат к точке вставки ограничивающего блока | X | |||
Требования к библиотеке
Все типы объектов, концепции свойств и свойства должны быть структурированы в соответствии с содержимым библиотеки типов объектов, которые будут предоставлены клиентом.
Информационные ограничения
Все информационные ограничения, определенные в библиотеке типов объектов, должны соблюдаться. Метаданные должны предоставляться в соответствии с форматом набора метаданных Дублинское ядро.
Требования к формату
Информационные единицы должны передаваться в формате XML; все единицы могут быть упакованы в один файл.
Информационные единицы передаются в виде вложения к сообщению в транзакции.
Метаданные передаются через сообщение в транзакции.
Приложение C
(справочное)
Справка по этапам жизненного цикла объекта строительства
С.1 Стандартные этапы жизненного цикла
Требования к обмену относятся к конкретным этапам проекта. Для согласованности этапы жизненного цикла всегда должны определяться на общей основе. Основной ссылкой для определения этапов жизненного цикла является ИСО 22263, в котором определены следующие основные этапы:
- предпроектная подготовка;
- техническое задание;
- проектирование;
- строительство;
- обслуживание;
- снос.
В настоящем стандарте основные этапы, идентифицированные в ИСО 22263, раскладываются далее на полноценный набор этапов разработки технологических карт и требований к обмену информацией. В таблице ниже приведен пример декомпозиции этапов жизненного цикла со ссылками на названия этапов в ИСО 22263.
Таблица C.1 - Этапы жизненного цикла по ИСО 22263
ИСО 22263 | Стандартный этап | Стандартное название | Стандартное определение |
Предварительные этапы жизненного цикла | |||
Предпроектная подготовка | 0 | Требования к портфолио | Определение задач для проекта, обеспечивающих удовлетворение бизнес-потребностей клиента |
Техническое задание | 1 | Концепция реализации проекта | Выявление потенциальных решений задач проекта и планирование их технико-экономических обоснований |
2 | Определение практической реализуемости | Оценка практической реализуемости вариантов, отобранных на этапе 1, и принятие решения о том, для каких из них следует провести более глубокое определение практической реализуемости | |
3 | Детальное определение практической реализуемости | Получение утверждения на финансирование | |
Предстроительные этапы | |||
Проектирование | 4 | Эскиз концептуального проекта | Определение основных элементов проекта на основе представленных вариантов |
5 | Полноценный концептуальный проект | Концептуальный проект и практические результаты, готовые для утверждения детального плана | |
6 | Координация проекта (и снабжения) | Устранение всех основных проблемных аспектов элементов проекта для того, чтоб проект мог продвигаться дальше. | |
Этапы строительства | |||
Строительство | 7 | Производственная информация | Завершение оформления всех практических результатов и переход к строительству |
8 | Строительство | Строительство объекта, удовлетворяющего всем требованиям клиента. | |
Этапы после окончания строительства | |||
Обслуживание | 9 | Обслуживание и эксплуатация | Эффективное и экономичное обслуживание и эксплуатация |
Снос | 10 | Утилизация | Вывод из эксплуатации, демонтаж и утилизация компонентов проекта и самого проекта в соответствии с правилами охраны окружающей среды и здоровья/безопасности |
С.2 Локальные этапы жизненного цикла
Стадии жизненного цикла обычно определяются в соответствии с локальными протоколами процессов. Это означает, что идентификация этапов жизненного цикла в одном месте будет отличаться от идентификации этапов жизненного цикла в другом месте.
Пример - разработка проекта в Великобритании часто организуется в соответствии с Планом работы RIBA, а в Германии - в соответствии с протоколом HOAI.
Этапы жизненного цикла в рамках стандартного требования к обмену информацией могут быть адаптированы для отражения особенностей местной практики в локализованном требовании к обмену информацией. Это значит, что стандартную таблицу можно заменить локально установленной таблицей. Требования к обмену могут быть определены в соответствии с этим локальным протоколом.
В тех случаях, когда используются локальные протоколы, необходимо поддерживать соответствие между этапами локального протокола и этапами, предусмотренными настоящим стандартом. При установлении соответствия можно применять один из следующих способов: либо
- в локальном протоколе один стандартный этап разделяется на несколько этапов, либо
- в нем несколько стандартных этапов объединяются в локальном протоколе.
Стандартные этапы и этапы, предусмотренные локальными протоколами, должны всегда соответствовать границам, так чтобы между ними существовало соотношение 1:1, 1:многим или многие:1. Этапы жизненного цикла не должны пересекать границы, то есть, этап по локальному протоколу не должен начинаться частично через один стандартный этап и заканчиваться частично через другой стандартный этап.
Приложение D
(справочное)
Использование в IDM методов BPMN
D.1 Общие сведения
Для разработки технологических карт IDM рекомендует (но не обязывает) использовать приведенную ниже нотацию моделирования бизнес-процессов (BPMN) (рисунок D.1). В таблице D.1 перечислены определения рекомендуемых символов BPMN, взятых из спецификации BPMN группой управления объектами (OMG).
|
Рисунок D.1 - Рекомендуемое подмножество символов BPMN для разработки технологической карты
Примечание - Источник: Lee, G., et al. (2013). "Extended Process to Product Modeling (xPPM) for integrated and seamless IDM and MVD development." Advanced Engineering Informatics 27(4): 636-651
Таблица D.1 - Определения рекомендуемого подмножества символов BPMN
Элемент | Определение |
Действие (задача) | Задача - это неделимое действие, включенное в процесс. Задача используется в тех случаях, когда работа в процессе не разбивается на более мелкий уровень детализации |
Подпроцесс | Подпроцесс - это сложное действие, включенное в процесс или график. Он имеет составную структуру и может быть разбит на элементы с более глубокой степенью детализации (процесс или график) через набор вспомогательных действий |
Подпроцесс (развернутый) | Подпроцесс развернут так, что видны составляющие его процессы. Важно, что последовательность входящих в него частей не может пересекать границы подпроцесса |
Подпроцесс (свернутый) | Элементы такого подпроцесса не видны на диаграмме. Знак "плюс" в середине нижней части блока означает, что действие является подпроцессом, в котором определены более низкие уровни детализации |
Начальное событие | Начальное событие указывает, где начнется процесс. Начальные события могут запускаться только триггером |
Промежуточное событие | Промежуточное событие указывает на нечто, происходящее в какой-либо точке между началом и концом процесса. Промежуточные события могут получать и генерировать триггеры |
Конечное событие | Конечное событие указывает на точку, в которой процесс завершается. Конечные события могут только выдавать результат |
Начальное событие (сообщение) | От участника поступает сообщение, запускающее процесс. |
Промежуточное событие (сообщение/получение) | Промежуточное событие "сообщение" может использоваться для отправки или получения сообщения. Когда оно используется для "перехвата" сообщения, маркер события должен быть пустым. Это приводит к продолжению процесса, если ожидалось сообщение, или изменяет поток обработки исключений |
Промежуточное событие (сообщение/отправка) | Промежуточное событие "сообщение" может использоваться для отправки или получения сообщения. При использовании для "отправки" сообщения маркер события должен быть заполнен (см. верхнюю цифру справа). Это приводит к продолжению процесса, если ожидалось сообщение, или изменяет поток обработки исключений |
Конечное событие (сообщение) | Этот тип окончания указывает на то, что при завершении процесса участнику отправляется сообщение |
Промежуточное событие (связь/получение) | Сопряженные события связи также могут использоваться для "внестраничной связи" для печати процесса, представленного на нескольких страницах. Они также могут использоваться как общие объекты перехода ("go to") на уровне процесса. Может быть только одно целевое событие связи. При использовании для "получения" из исходной ссылки маркер события будет заполненным. При использовании для "отправки" на целевую ссылку, маркер события будет заполненным |
Промежуточное событие (ссылка/отправка) | |
Шлюз | Шлюз используется для управления расхождением и схождением потоков последовательностей в процессе и в гибком графике организации работы. Таким образом, он будет определять разветвление, раздваивание, слияние и объединение путей. Внутренние маркеры будут обозначать тип управления поведением |
Шлюз (эксклюзивный) | [XOR] - при разделении направляет поток последовательности событий только по одной из исходящих ветвей. При слиянии шлюз ожидает завершения потока по одной входящей ветви перед запуском исходящего потока |
Шлюз (параллельный) | [And] - при использовании для разделения потока последовательности одновременно активируются все исходящие ветви. При слиянии параллельных ветвей шлюз ожидает завершения потоков по всем входящим ветвям перед запуском исходящего потока |
Шлюз (инклюзивный) | [Or] - при разделении активируются одна или несколько ветвей. Все потоки по активным входящим ветвям должны быть завершены перед слиянием |
Поток последовательности событий (обычный или неконтролируемый) | Поток последовательности событий используется, чтобы показать порядок, в котором будут выполняться действия в процессе и в гибком графике организации работы |
Поток сообщений | Поток сообщений используется для отображения потока сообщений между двумя участниками, которые готовы отправлять и принимать их. Поток сообщений соединяет две разных диаграммы деятельности. Они соединяют либо со всей диаграммой деятельности, либо с объектами потока событий в пределах диаграммы. Они не должны соединять два объекта в пределах одной диаграммы |
Сопоставление | Сопоставление используется для связывания информации и артефактов с объектами потока. С объектами потока и потоком можно связывать текстовые и графические объекты, не принадлежащие потоку |
Сопоставление данных | Сопоставление данных используется для перемещения данных между объектами данных, свойствами и входными или выходными результатами действий и процессов. Сопоставление данных можно визуально представлять на диаграмме с помощью соединительной линии, отображающей сопоставление |
Диаграмма деятельности | Диаграмма деятельности - это графическое представление деятельности участника в совместной работе. |
Дорожка | Дорожка является подразделом процесса (часто внутри диаграммы) и простирается на всю длину процесса по вертикали или горизонтали. |
Объект данных | Объекты данных предоставляют информацию о том, какие действия требуют выполнения и/или что они производят. |
Группа | Группа не является действием или объектом потока, поэтому не может присоединяться к потокам последовательности или потокам сообщений. Кроме того, группы не ограничены диаграммами и дорожками |
Текстовое примечание | Текстовые аннотации - это механизм для инструмента моделирования, позволяющий предоставлять дополнительную информацию читателю диаграммы BPMN. Объект текстового примечания может быть связан с конкретным объектом на диаграмме линией сопоставления, но не влияет на поток событий процесса |
В следующих разделах представлены наборы общих принципов и правил из Спецификации BPMN OMG ниже. Примеры и подробные сведения можно найти по следующим ссылкам:
- Business Process Modelling Notation (BPMN), OMG, 2013, доступно по адресу:
< http://www.omg. org/bpmn/>.
- Silver, B., BPMN Method and Style: A levels-based methodology for BPM process modelling and improvement using BPMN 2.0, 2011, Cody-Cassidy Press.
D.2 Спецификация процессов и потоков
В технологическую карту должны быть включены все диаграммы и поддиаграммы, созданные для описания процесса. Все процессы в технологической карте должны иметь уникальный идентификатор и имя.
Каждый процесс в карте процесса описывается так подробно, как требуется. Целью является описание назначения процесса для пользователя. Ниже перечислены правила, указанные в спецификации BPMN, связанные с потоками и событиями процесса.
Поток процесса
Рекомендуется выбирать направление потоков последовательности либо слева направо, либо сверху вниз, а затем направлять потоки сообщений под углом 90° к потокам последовательности.
Поток процесса содержится в пределах диаграммы деятельности и не может пересекать ее границ.
Взаимодействие между диаграммами отображается через потоки сообщений.
Если на диаграмме был развернут подпроцесс, объекты внутри подпроцесса не могут связываться с объектами вне подпроцесса.
Соединения потоков последовательностей
Соединяющий объект, который показывает порядок выполнения действий в процессе, представлен сплошной графической линией.
У каждого потока имеется только один источник и только одна цель.
Поток последовательности событий может пересекать границы между дорожками, но не может пересекать границ диаграммы деятельности.
Источником и целью могут быть только действия, шлюзы и события. Артефакт не должен быть ни источником, ни целью потока последовательности.
Соединение потока сообщений
Поток сообщений соединяет две разных диаграммы деятельности. Они соединяют либо со всей диаграммой деятельности, либо с объектами потока событий в пределах диаграммы.
Сообщение не должно соединять два объекта в пределах одной диаграммы деятельности.
Поток сообщений не может соединять объекты, которые находятся в одной диаграмме.
Взаимодействие между диаграммами отображается через потоки сообщений.
Источником или целью потока сообщений могут быть только диаграммы деятельности, участники, действия и события. Артефакт не должен быть ни источником, ни целью потока сообщений.
Сопоставления и сопоставления данных
С объектами потока и потоком можно связывать текстовые и графические объекты, не принадлежащие потоку.
Сопоставление используется для связывания определенного пользователем текста (аннотации) с объектом потока событий.
При сопоставлении данных используется та же нотация, как и при прямом сопоставлении.
Сопоставление данных используют для перемещения данных между объектами данных, свойствами или входными и выходными результатами действий и процессов.
Объекты данных могут быть непосредственно связаны с соединительным элементом потока последовательности.
Действия определяют два набора сопоставления данных, тогда как события определяют только один.
D.3 Спецификация событий
Событие указывает состояние действия. Тремя основными событиями являются начальные, промежуточные и конечные события.
Начальные и конечные события
Экземпляр процесса реализуется, когда происходит одно из начальных для него событий.
Для завершения экземпляра процесса все маркеры в этом экземпляре должны достичь конечного узла, т.е. узла без исходящих потоков последовательности. Если маркер достигает события "прекратить процесс", весь процесс аномально завершается.
Использование стартовых и конечных событий является независимым для каждого уровня диаграммы.
Если имеется стартовое событие, то должно быть по крайней мере одно конечное событие. Если имеется конечное событие, то должно быть по крайней мере одно стартовое событие.
Если стартовое событие не используется, то неявное стартовое событие для процесса не должно иметь триггер.
Если процесс является сложным и/или стартовые условия не являются очевидными, рекомендуется использовать стартовое событие.
Если конечное событие не используется, то у неявного конечного события для процесса должен отсутствовать результат.
Процесс не должен заканчиваться до завершения всех параллельных путей.
D.4 Спецификация объектов данных
Объект данных - это именованный набор данных. Он может быть набором данных, доступных из внешнего источника (например, библиотечные данные), или может представлять данные, которые экспортируются из действия, чтобы сделать возможным выполнение других действий (например, требование обмена).
Объекты данных, которые не являются требованиями обмена, должны иметь имя, показывающее их предназначение, и описание, характеризующее их предназначение и содержимое. Ниже перечислены правила, указанные в спецификации BPMN, связанные с объектами данных.
Объекты данных
Элементы объекта данных должны содержаться в элементах процесса или подпроцесса.
Сопоставления данных всегда содержатся в других элементах, которые определяют, когда эти сопоставления данных должны осуществляться.
Объект данных не должен быть ни источником, ни целью потоков последовательности и потоков сообщений.
Объекты данных могут быть непосредственно сопоставлены с соединительным элементом потока последовательности.
D.5 Спецификация требований обмена в карте процесса
Требование обмена в моделях BPMN представляется с помощью объекта данных в карте процесса. Требования обмена должны содержать:
- имя, показывающее их предназначение, которое удовлетворяет правилам наименования IDM;
- описание, которое характеризует предназначение и содержимое в отдельном документе требования обмена.
Приложение ДА
(справочное)
Сведения о соответствии ссылочных международных стандартов национальным стандартам
Таблица ДА.1
Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
ISO 6707-1 | NEQ | ГОСТ Р 58033-2017 "Здания и сооружения. Словарь. Часть 1. Общие термины" |
Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта: | ||
Библиография
[1] ISO 29481-2, Building information models - Information delivery manual - Part 2: Interaction framework
УДК 004.9:006.354 | ОКС 91.010.01 | |
35.240.67 | ||
35.240.01 | ||
Ключевые слова: система стандартов, информационное моделирование, здания и сооружения, строительство, справочник, обмен информацией, методология, формат | ||
Электронный текст документа
и сверен по:
, 2019
