ГОСТ Р 55345-2012/ISO/TS 18876-2:2003. Национальный стандарт Российской Федерации. Системы промышленной автоматизации и интеграция. Интеграция промышленных данных для их обмена, обеспечения доступа и коллективного использования. Часть 2. Интеграция и методология отображения
(утв. и введен в действие Приказом Росстандарта от 29.11.2012 № 1706-ст)
Примечание
Документ введен в действие с 01.01.2014.
Утвержден и введен в действие
Приказом Федерального агентства
по техническому регулированию
и метрологии
от 29 ноября 2012 г. № 1706-ст
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ
ИНТЕГРАЦИЯ ПРОМЫШЛЕННЫХ ДАННЫХ ДЛЯ ИХ ОБМЕНА,
ОБЕСПЕЧЕНИЯ ДОСТУПА И КОЛЛЕКТИВНОГО ИСПОЛЬЗОВАНИЯ
ИНТЕГРАЦИЯ И МЕТОДОЛОГИЯ ОТОБРАЖЕНИЯ
Industrial automation systems and integration. Integration
of industrial data for exchange, access and sharing.
Part 2. Integration and mapping methodology
35.240.50
Дата введения 1 января 2014 года
Предисловие
1 ПОДГОТОВЛЕН Автономной некоммерческой организацией «Международная академия менеджмента и качества бизнеса» на основе собственного перевода на русский язык англоязычной версии документа, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 ноября 2012 г. № 1706-ст
4 Настоящий стандарт идентичен международному документу ИСО/ТС 18876-2:2003 «Системы промышленной автоматизации и интеграция. Интеграция промышленных данных для их обмена, обеспечения доступа и коллективного использования. Часть 2. Интеграция и методология отображения» (ISO/TS 18876-2:2003 «Industrial automation systems and integration — Integration of industrial data for exchange, access and sharing — Part 2: Integration and mapping methodology», IDT).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
0.1 Обзор комплекса стандартов ИСО 18876
Комплекс стандартов ИСО 18876 определяет технические требования, архитектуру и методологию для интеграции данных промышленных предприятий с целью обмена, организации доступа к данным и их совместного использования. Область применения настоящего комплекса распространяется на:
- совместное использование данных и их интеграцию;
- технические требования к процессам сопоставления моделей, заложенных в основе промышленных систем;
- трансформацию данных.
0.2 Структура настоящего стандарта
Настоящий стандарт организован следующим образом:
- в разделе 1 определяются цели и область применения настоящего стандарта;
- в разделе 2 указываются ссылочные стандарты по тематике;
- в разделе 3 приводятся термины и определения, используемые в настоящем стандарте;
- в разделе 4 приводятся сценарии использования методов, определенных в настоящем стандарте;
- в разделе 5 устанавливаются методы интеграции моделей приложений с использованием модели действий, приведенной в приложении B;
Методы, установленные в разделе 5, независимы от языка моделирования, языка отображения, и конкретных моделей интеграции. В приложении C приведен список вопросов, который может быть использован для проверки того факта, были ли пройдены в процессе интеграции и отображения все необходимые этапы.
0.3 Целевая аудитория
Настоящий стандарт предназначен для специалистов по моделированию, аналитиков, системных интеграторов и разработчиков информационных систем, которым необходимо интегрировать модели приложений в различные системы и/или функции предприятия. Раздел «Введение» настоящего стандарта предназначен для технических директоров, в чью компетенцию входит интеграция проектов с помощью методов, установленных в настоящем стандарте.
0.4 Допущения
Настоящий стандарт содержит требования и положения, которым необходимо следовать для соответствия настоящему стандарту. Данные положения выделены в настоящем стандарте соответствующими словами «должен» и «не должен». Настоящий стандарт также включает положения, которые при определенных условиях можно рассматривать как удовлетворяющие требованиям и использовать в качестве рекомендаций. Дополнительные материалы, иллюстрирующие положения настоящего стандарта, представлены в качестве заметок, примеров и приведены в приложениях B, C и D.
1 Область применения
Настоящий стандарт определяет архитектуру, методологию и другие спецификации для интеграции промышленных данных с целью их обмена, организации доступа и коллективного использования. Настоящий стандарт распространяется на:
- интеграцию данных, которые могут быть: - взяты из различных источников для различного контекста модели, - описаны различными моделями, - определены на различных языках моделирования;
- коллективное использование данных различными приложениями с помощью архитектуры системы интеграции;
- разрешение конфликтов между моделями, разработанными с различными целями;
- транслирование данных из одной системы кодирования в другую;
- транслирование модели с одного языка моделирования на другой.
В настоящем стандарте устанавливаются следующие методы:
- оценки и выбора модели интеграции, которая может интегрировать две и более модели приложений;
- создания моделей приложений, являющихся ограниченными подмножествами модели интеграции для удовлетворения особых требований области приложений, обеспечивающих обмен данными, их коллективное использование;
- создания спецификаций взаимных отображений моделей приложений и модели интеграции.
Настоящий стандарт также распространяется на:
- методы создания и расширения модели интеграции, не зависящие от языка моделирования;
- методы интеграции моделей приложений с моделью интеграции;
- метод отображения моделей приложений на модель интеграции, не зависящий от языка отображения;
- критерии выбора языка моделирования и языка отображения, используемые указанными методами интеграции и отображения.
Настоящий стандарт не распространяется на:
- структуру и содержание частных моделей интеграции;
- метод создания и расширения частных моделей интеграции;
- метод отображения моделей приложений на частные модели интеграции.
Примечание — Особые методы, используемые для взаимных отображений частных моделей приложений и модели интеграции, зависят от используемых парадигм моделирования, структуры и содержания модели.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных — последнее издание (включая все изменения).
ISO/IEC 8824-1:1998 <1>, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation [Информационные технологии. Абстрактный синтаксис. Система обозначений. Версия 1 (ASN.1). Спецификация базовой системы обозначений]
<1> Заменен на ISO/IEC 8824-1:2015.
ISO 10303-1:1994, Industrial automation systems and integration — Product data representation and exchange — Part 1: Overview and fundamental principles (Системы промышленной автоматизации и интеграция. Представление данных о продукции и обмен данными. Часть 1. Обзор и основные принципы)
ISO/TS 18876-1:2003, Industrial automation systems and integration — Integration of industrial data for exchange, access and sharing — Part 1: Architecture overview and description (Системы промышленной автоматизации и интеграция. Интеграция промышленных данных для обмена, организации доступа и распределения. Часть 1. Обзор и описание архитектуры)
Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3 Термины, определения и аббревиатуры
3.1 Термины и определения
В настоящем стандарте используются термины с соответствующими определениями, приведенные в ИСО 10303-1 и ИСО/ТС 18876-1.
Примечание 1 — Определения, скопированные дословно из других стандартов, сопровождаются соответствующими ссылками на стандарты в квадратных скобках, например [ИСО 10303-1]. В указанных случаях определения, данные в ссылочных документах, являются нормативными. Их повторение здесь имеет справочный характер. В случае каких-либо несоответствий определения из ссылочного документа имеют преимущество. За определениями могут идти примечания, поэтому определения из других стандартов оказываются адаптированными. Данные ниже определения являются нормативными для настоящего стандарта.
3.1.1 модель приложения; МП (application model; AM): Модель, содержащая информацию, используемую для некоторой частной цели.
Примечание 1 — Некоторые модели приложений также являются моделями интеграции (см. раздел 3.1.15).
Примечание 2 — Модель приложения не обязательно является моделью данных. Это может быть модель некоторого другого сорта, например логически обоснованная модель.
3.1.2 класс (class): Категория или раздел сущности.
Примечание — Существует несколько способов определения класса. Данное определение должно быть максимально широким, даже шире определения, данного в ИСО 15926-2.
Пример — Насос, электростанция, инженер, фантастический космический корабль — примеры классов.
3.1.3 понятие (concept): Внутреннее понятие (концепция) некоторой сущности, общее понимание или идея некоторой сущности.
3.1.4 конструктив; логическая структура (construct): Представление понятия с помощью некоторой формальной системы обозначений.
Примечание — Конструктив может быть частью модели данных или моделью данных в целом.
3.1.5 данные (data): Представление информации формальным способом для связи, интерпретации, а также для переработки ее компьютером или человеком.
3.1.6 модель данных (data model): Набор конструктивов, обеспечивающих определение, структуру и формат данных; этот набор может быть физическим или абстрактным в зависимости от выбора регистрирующей среды.
3.1.7 производное понятие (derived concept): Понятие модели интеграции, определяемое через примитивные понятия.
3.1.8 преобразование кодирования (encoding transformation): Преобразование способа представления элементов данных на компьютере.
Пример — Преобразование данных, представленных на языке EXPRESS, из файла, соответствующего ИСО 10303-21, в документ XML.
3.1.9 расширение (extension): Процесс или результат добавления понятий в модель интеграции для увеличения области ее применения без изменения ранее представленных понятий.
3.1.10 фундаментальное понятие (foundation concept): Примитивное понятие, определяющее общее базовое представление о модели интеграции.
Примечание — Моделей интеграции может быть несколько. Каждая модель имеет свою собственную парадигму моделирования, характеризуемую примитивными понятиями, которые она содержит.
Пример — Понятие класса и понятие индивидуальности — фундаментальные понятия общей модели интеграции.
3.1.11 общее понятие (general concept): Примитивное понятие, имеющее очень широкую область применения, но являющееся специализацией некоторого фундаментального понятия.
Примечание — Понятие может рассматриваться как фундаментальное понятие одной общностью пользователей и как общее понятие — другой общностью пользователей.
3.1.12 индивидуальность (individual): Сущность, существующая в пространстве и времени.
Примечание — Данное понятие включает сущности, фактически существующие сейчас или существовавшие ранее, а также сущности, которые, возможно, существовали в прошлом, возможно, существуют в настоящем или, возможно, будут существовать в будущем.
Пример — Насос с серийным № ABC123, электростанция Battersea, сэр Joseph Whitworth (изобретатель трубной резьбы), космический корабль Enterprise — примеры индивидуальностей.
3.1.13 информация (information): Факты, понятия и инструкции.
3.1.14 интеграция (integration): Действие, которое создает, модифицирует или расширяет модель интеграции.
3.1.15 модель интеграции; МИ (integration model; IM): Модель приложения, задающая информацию, представленную двумя или несколькими моделями приложений.
Примечание — Модель приложения становится моделью интеграции в зависимости от роли, которую она играет по отношению к одной или нескольким моделям приложений.
3.1.16 отображение (mapping): Установление соответствия элементов одной модели элементам другой модели, имеющим тот же смысл.
Примечание 1 — Отображение может быть односторонним или двухсторонним (взаимным).
Примечание 2 — Отображение — это результат применения спецификации отображения к частной модели.
3.1.17 спецификация отображения (mapping specification): Определение преобразований, необходимых для приема информации в соответствии с одной моделью данных и представления некоторой информации в соответствии с другой моделью данных.
Примечание 1 — Спецификация отображения может включать преобразования структуры данных, преобразования значений данных, преобразования кодирования данных и преобразования терминологии.
Примечание 2 — Спецификации отображений могут быть процедурными, декларативными, а также их комбинацией.
3.1.18 модель (model): Ограниченное информационное представление объекта моделирования, удовлетворяющего условиям достижения некоторой цели.
Примечание — Модель может быть просто набором данных, может быть моделью данных, может принимать другую форму. Приложение D содержит замечания о соотношениях между моделями, данными и моделями данных.
3.1.19 контекст модели (model context): Набор ограничений, устанавливающих предел возможности добавления новых элементов модели без изменения каких-либо имеющихся деклараций.
Примечание 1 — Контекст модели — это класс всех ее возможных расширений.
Примечание 2 — Понятие «контекст модели» — более общее, чем понятие «контекст приложения», определенное в ИСО 10303-1.
3.1.20 область применения модели (model scope): Диапазон информации, который может быть описан моделью приложения.
3.1.21 примитивное понятие (primitive concept): Понятие модели интеграции, не полностью определенное терминами других понятий.
3.1.22 структурное преобразование (structural transformation): Тип спецификации отображения, являющегося преобразованием структуры данных.
Примечание — Изменение структуры может быть следствием перестановки атрибутов, разделения атрибутов по типам данных сущностей, а также следствием создания новых атрибутов.
3.1.23 терминологические преобразования (terminology transformation): Преобразование термина, используемого для ссылки на сущность.
Примечание — Данное преобразование может иметь место между синонимами одного языка или между различными языками.
3.1.24 преобразование (transformation): Изменение формы.
3.2 Аббревиатуры
В настоящем стандарте используются следующие аббревиатуры:
МП — модель приложения (AM; Application model).
Примечание — В ИСО 10303 аббревиатура МП используется также для понятия «модуль приложения». Понятия «модель приложения» и «модуль приложения» — разные вещи.
МИ — модель интеграции (IM; Integration model).
4 Сценарии использования
Методология, определенная в настоящем стандарте, удовлетворяет требованиям использования следующих сценариев:
- интеграция двух или нескольких существующих моделей приложений (см. 4.1);
- интеграция одной или нескольких существующих моделей приложений с существующей моделью интеграции (см. 4.2);
- определение модели приложения и ее отображение на модель интеграции (см. 4.3);
- интеграция модели приложения с несколькими моделями интеграции (см. 4.4);
- улучшение модели интеграции (см. 4.5).
4.1 Интеграция моделей приложений
Настоящий компонент методологии интегрирует две и более моделей приложений путем создания модели интеграции, способной представить все понятия и ограничения моделей приложений. Такая модель интеграции поддерживает передачу данных между приложениями и пользователями, использующими данные модели приложений.
Настоящее требование и его решение показаны на рисунке 1.
Рисунок 1 — Создание модели интеграции, интегрирующей две модели приложений
Входные данные для указанного действия:
- две и более моделей приложений;
- парадигма моделирования и принципы, выбранные для создания модели интеграции.
Примечание — Использование указанных принципов является важным критерием при определении будущей степени расширяемости и повторного использования модели интеграции.
Выходные данные для указанного действия:
- модель интеграции, представляющая понятия и ограничения входных данных моделей приложений;
- спецификации отображений, представляющих соотношения между конструктивами каждой модели приложений и соответствующих подмножеств модели интеграции.
Спецификации отображений включают любые ограничения, используемые для моделей приложений. Подмножество модели интеграции, соответствующее каждой модели приложения, включает понятия, не являющиеся явными в модели приложения. Они обнаруживаются во время процесса интеграции.
4.2 Интеграция модели приложения с моделью интеграции
Указанный компонент методологии интегрирует одну или несколько моделей приложений и существующую модель интеграции. Цели настоящего действия:
- интеграция моделей приложений;
- улучшение качества моделей приложений путем представления их понятий и ограничений в более согласованной и расширенной форме (структуре);
- расширение области применения модели интеграции.
Содержание и результаты настоящего действия зависят от содержания модели интеграции и содержания интегрируемых моделей приложений. Настоящий подраздел описывает сценарии, по которым контекст интегрируемых моделей приложений является подмножеством контекста модели интеграции.
Примечание 1 — См. 4.5 для описания сценария, по которому контекст интегрируемых моделей приложений не является подмножеством контекста модели интеграции. Соотношение между областью применения и контекстом различных моделей определено в ИСО/ТС 18876-1:2003, пункт 5.1.2.
Указанное условие и решение показаны на рисунке 2.
Рисунок 2 — Интеграция модели приложений с существующей моделью интеграции
Входные данные для указанного действия:
- существующая модель интеграции;
- одна или несколько моделей приложений, интегрированных с моделью интеграции, включая спецификации отображений, соотносимые с каждой моделью приложений для соответствующего подмножества модели интеграции;
- парадигма моделирования и принципы, используемые для создания модели интеграции и определяющие порядок расширения модели интеграции для удовлетворения требованиям модели приложения.
Выходные данные указанного действия:
- расширенная модель интеграции (если входная модель интеграции не точно удовлетворяет требованиям моделей приложений).
Примечание 2 — Расширения модели интеграции не приводят к изменениям объектов и соотношений входной модели интеграции. Область применения модели интеграции при этом увеличивается. Контекст модели не может быть увеличен без удаления ограничений. Удаление ограничений приводит к изменению существующей модели интеграции, поэтому данное изменение не будет расширением;
- спецификация отображения, представляющая соотношения между конструктивами моделей приложений и соответствующих подмножеств расширенной модели интеграции;
- улучшения моделей приложений (при необходимости).
4.3 Определение модели приложения и ее отображение на модель интеграции
Настоящий компонент методологии создает модель приложения вместе с ее отображением на модель интеграции. Цель настоящего действия — использование модели интеграции для интеграции приложений (общности пользователей), имеющих общие информационные требования.
Данное требование и его решение показаны на рисунке 3 ниже.
Рисунок 3 — Создание модели приложения и ее отображение на модель интеграции
Входные данные для указанного действия:
- результаты интервью пользователя;
- существующие модели интеграции;
- парадигма моделирования и принципы, используемые для создания модели интеграции и определяющие порядок расширения модели интеграции для удовлетворения установленных информационных требований.
Выходные данные указанного действия:
- расширенная модель интеграции (если входная модель интеграции неточно удовлетворяет установленным информационным требованиям);
- модель приложения, удовлетворяющая установленным информационным требованиям и отображаемая на модель интеграции.
Примечание — Модель приложения может использовать структуру и/или терминологию модели интеграции. Если она использует и то и другое, то она идентична подмножеству модели интеграции, и их взаимное отображение тривиально;
- спецификация отображения, представляющая соотношения между конструктивами моделей приложений и соответствующим подмножеством расширенной модели интеграции.
4.4 Интеграция модели приложения с двумя и более моделями интеграции
Модель приложения не обязательно интегрируется только с одной моделью интеграции. На рисунке 4 показано, что модель приложения может быть интегрирована с двумя и более различными моделями интеграции.
Рисунок 4 — Интеграция модели приложения с несколькими моделями интеграции
Входные данные для указанного действия:
- одна или несколько моделей приложений;
- две и более моделей интеграции, интегрируемых с моделями приложений;
- парадигма моделирования и принципы, используемые для создания моделей интеграции.
Для интегрирования моделей приложений с двумя и более моделями интеграции должны быть удовлетворены следующие условия:
- контекст модели приложения должен быть подмножеством контекста каждой модели интеграции;
- область применения модели приложения должна быть подмножеством области применения каждой модели интеграции, которая может быть расширена для удовлетворения установленных требований.
Интегрирование с каждой моделью интеграции зависит от принципов и парадигмы моделирования, используемой для развития и расширения данной модели интеграции.
Выходные данные указанного действия:
- расширенная модель интеграции (если одна или несколько входных моделей интеграции неточно удовлетворяют требованиям модели приложения);
- спецификации отображений, представляющие соотношения между конструктивами модели приложения и соответствующими подмножествами каждой модели интеграции;
- улучшения модели приложения (при необходимости).
4.5 Улучшение модели интеграции
Настоящий аспект методологии создает новую модель интеграции в случае, когда существующая модель интеграции не удовлетворяет требованиям модели приложения и не может быть расширена для выполнения данного требования. Такая ситуация возникает, если контекст модели интеграции недостаточно широк для удовлетворения потребностей интегрируемых моделей приложений. Указанная недостаточность проявляется как ограничение структуры модели интеграции, не используемой для одной или нескольких интегрируемых моделей приложений.
Указанное требование и его решение показано на рисунке 5.
Рисунок 5 — Улучшение модели интеграции
Входные данные для указанного действия:
- существующая модель интеграции;
- одна или несколько моделей приложений, интегрированных с моделью интеграции, включая спецификации отображений, соотносящих каждую модель приложения с соответствующим подмножеством модели интеграции;
- одна или несколько последующих интегрируемых моделей приложений, чьи требования не могут быть удовлетворены с помощью существующих моделей интеграции.
Выходные данные указанного действия:
- новая модель интеграции, имеющая более широкий контекст, чем исходная модель интеграции.
Примечание — Новая модель интеграции может быть разработана на основе более общей парадигмы моделирования, чем та, что была использована для исходной модели интеграции.
Пример — Если модель интеграции обеспечивает моментальный снимок текущего состояния окружающей среды, то изменения парадигмы моделирования обязательны, если она должна поддерживать утверждения о прошлом и/или будущем;
- спецификации отображений, представляющие соотношения между конструктивами каждой модели приложения и соответствующими подмножествами новой модели интеграции.
Сценарий, указанный на рисунке 5, приводит к созданию спецификации отображения исходной модели интеграции на новую модель интеграции. Это означает, что для передачи данных из модели приложения AM1 (Application Model) в модель приложения AMn необходимо рассмотреть три отображения:
1) отображение AM1 на исходную модель интеграции;
2) отображение исходной модели интеграции на новую модель интеграции и
3) отображение AMn на новую модель интеграции.
Технические и экономические соображения приводят к альтернативному подходу, показанному на рисунке 6. Здесь спецификации взаимных отображений определены для исходных интегрируемых моделей приложений AM1 и AM2 и новой модели интеграции. Такой подход уменьшает количество рассматриваемых спецификаций для парных комбинаций моделей приложений за счет дополнительного анализа и выполняемых отображений.
Рисунок 6 — Альтернативные отображения для улучшенной модели интеграции
5 Методы интеграции моделей приложений
В настоящем разделе представлены методы интеграции моделей приложений. Интеграция производится в четыре этапа:
1) анализ модели приложения, выполнение других информационных требований;
2) расширение модели интеграции (при необходимости);
3) идентификация подмножества модели интеграции, соответствующей модели приложения;
4) определение взаимных отображений модели приложения и идентифицированного подмножества модели интеграции.
Каждый этап характеризуется обязательными предварительными условиями, описанием используемого метода, а также условиями окончания, определяющими успешность применения метода.
Примечание — Модель действия для процесса интеграции показана в приложении B.
5.1 Анализ требований
Цель настоящего действия — идентифицировать модель интеграции для интегрирования рассматриваемых моделей приложений, а также установить порядок представления понятий моделей приложений по отношению к понятиям выбранной модели интеграции.
5.1.1 Предварительные условия
5.1.1.1 Модель приложения
Для анализа моделей приложений используются следующие предварительные условия:
- доступность определений, диаграмм и других спецификаций, описывающих рассматриваемую модель приложения;
- доступность примеров выборки данных, иллюстрирующих использование модели приложения;
- доступность консультации эксперта в области применения и получения информации о порядке использования модели в различных практических случаях.
Примечание — Дополнительная информация, получаемая от эксперта в области применения, часто необходима для полного понимания контекста модели приложения, а также для того, чтобы удостовериться, что указанная неявная информация реально представлена в модели интеграции (в спецификации отображения модели приложения).
5.1.1.2 Язык моделирования
Никакие особые предварительные условия не нужны для языков моделирования, используемых для описания моделей приложений. Документация, описывающая модели приложений, должна описывать все принятые допущения, практический опыт и другую полезную информацию, характеризующую способ представления модели на языке моделирования.
Примечание 1 — Даже в случае крайней необходимости указанная информация может быть недоступна для некоторых моделей приложений. Поэтому исследователь должен иметь опыт практического использования языков моделирования.
Примечание 2 — Если конкретные практические рекомендации отсутствуют, то не следует считать, что язык моделирования используется корректно для описания модели приложения.
5.1.2 Описание метода
Методы, используемые для анализа требований:
- анализ понятий модели приложения.
5.1.2.1 Выбор модели интеграции
В принципе возможно создание модели интеграции, интегрирующей две и более модели интеграции (см. 4.1). Более общим требованием является интеграция одной или нескольких моделей приложений с существующими моделями интеграции (см. 4.2). Для выбора соответствующей модели интеграции используются следующие критерии:
- выбранная модель интеграции должна иметь контекст, включающий контекст интегрируемых моделей приложений.
Примечание 1 — Если контекст модели приложения не полностью содержится в контексте модели интеграции, то данная модель интеграции не может интегрировать все понятия, представленные в моделях приложений, без внесения изменений в модель интеграции.
Примечание 2 — В приложении D.2 даны замечания, которые рекомендуется принимать во внимание при определении контекста модели приложения;
- если доступны несколько моделей интеграции с подходящим контекстом, то выбранные модели интеграции должны иметь ближайшую (перекрывающую) область применения для интегрируемых моделей приложений. Если имеется несколько интегрируемых моделей приложений, то рассматриваемая область применения модели является объединением областей применения моделей приложений.
Примечание 3 — Выбор модели интеграции, область применения которой перекрывает область применения интегрируемой модели приложений, может упростить процесс интеграции и снизить потребность в расширении модели интеграции.
Примечание 4 — Имеющийся опыт анализа моделей приложений, уже интегрированных с некоторой моделью интеграции, и составления ассоциированных спецификаций отображений можно использовать для определения перекрытий области применения модели. Аналогично опыт анализа производных понятий, явно представленных в модели интеграции, можно использовать для определения перекрытия области применения модели.
5.1.2.2 Анализ понятий модели приложения
Порядок выполнения анализа иллюстрируется на рисунке 7.
Рисунок 7 — Анализ модели приложения
Содержание данных соотношений значительно изменяется в зависимости от содержания используемой модели. Некоторые или все типы следующих соотношений могут быть опознаны в процессе анализа:
- синонимы: одинаковые понятия существуют в моделях приложений и модели интеграции, при этом одна или несколько моделей используют различные названия понятий;
- омонимы: понятия существуют внутри одной или нескольких моделей приложений и модели интеграции, они имеют одинаковые названия, но различный смысл;
- идентичные понятия: одинаковые понятия существуют в модели приложения и модели интеграции, они имеют тот же смысл, ту же структуру и те же ограничения в обоих случаях;
- совместимые понятия: одинаковые понятия существуют в модели приложения и в модели интеграции, имеют тот же смысл, но различную структуру и непротиворечивые ограничения;
- несовместимые понятия: одинаковые понятия существуют в модели приложения и в модели интеграции, имеют тот же смысл, но различную структуру и противоречивые ограничения;
- комплексные понятия (в модели приложения): группа, состоящая из одного или нескольких понятий модели приложения, соответствует одному или нескольким понятиям модели интеграции.
Пример 1 — Модель приложения включает понятие «red car (красный автомобиль)» и отображается на модель интеграции, представляющую отдельные понятия «red (красный)» и «car (автомобиль)». Понятие модели приложения представляется комбинацией двух понятий модели интеграции.
Пример 2 — Модель приложения включает тип данных сущности, называемой product (продукт), которая может представлять либо индивидуальные изделия (идентифицированные по серийному N), либо класс изделий (идентифицированный по № детали). Если указанные сущности опознаны как отдельные понятия модели интеграции (physical_object или class_of_physical_object), то элементы сущности product модели приложения могут соответствовать элементам обоих понятий модели интеграции;
- расчлененные понятия (в модели приложения): два и более понятий модели приложения соответствуют одному общему понятию модели интеграции.
Пример 3 — Модель приложения содержит типы данных сущностей, называемых customer (заказчик) и supplier (поставщик). Данные сущности могут соответствовать общему типу данных некоторой сущности модели интеграции, называемой organization (организация).
Наконец, понятие модели приложения может не иметь эквивалента внутри модели интеграции. В таком случае необходимо разрабатывать расширения модели интеграции, чтобы можно было с семантической точностью идентифицировать эквивалентность некоторого подмножества модели интеграции и модели приложения.
5.1.3 Условия окончания
Окончание процесса анализа модели приложения должно удовлетворять следующим условиям:
- либо выбирается существующая модель интеграции, либо устанавливается, что ни одна из существующих моделей интеграции не может удовлетворить требованиям моделей приложений;
- если выбрана существующая модель приложения, то начальная оценка данной модели определяет возможность ее использования:
- как основы для новой модели интеграции;
- во втором и третьем вышеуказанных случаях идентифицируются несоответствия (пустоты), обнаруженные в модели интеграции;
- семантические соотношения, обнаруженные между понятиями модели приложения и модели интеграции, регистрируются.
5.2 Определение и расширение модели интеграции
Если в процессе анализа (см. 5.1) установлено, что одно или несколько понятий, представленных в модели приложения, не имеют точного эквивалента в модели интеграции, то последний должен быть расширен перед разделением на подмножества, и должно быть выполнено отображение.
Примечание — Диаграммы данного подраздела показывают только одну модель приложения и ее соотношение с моделью интеграции. Простота только способствует ясности. Принято, что модель интеграции существует и интегрирует две и более модели приложений.
5.2.1 Предварительные условия
5.2.1.1 Модель интеграции
Характеристики модели интеграции описаны в ИСО/ТС 18876-1:2003, пункт 5.1.2. Следующие предварительные условия относятся к выбранной модели интеграции:
- доступность определений, диаграмм и других спецификаций, описывающих модель интеграции;
- доступность примеров моделей приложений, интегрированных с моделью интеграции, и ассоциированных спецификаций отображений;
- исследователь, использующий интеграцию, должен быть знаком с данной моделью интеграции и с правилами ее применения для интеграции моделей приложений;
- доступность компьютерных инструментов, представляющих модель интеграции и поддерживающих процесс создания спецификаций отображений.
5.2.1.2 Язык моделирования
Требования к языку моделирования:
- язык моделирования должен иметь возможность представлять оба класса, а также элементы одной модели.
Примечание — Язык EXPRESS (см. ИСО 10303-11) главным образом представляет классы (как типы данных сущностей). Следовательно, модели интеграции, определяющие порядок использования языка EXPRESS, требуют добавочных спецификаций для представлений своих элементов, например механизмов кодирования (ИСО 10303-21, ИСО/ТС 10303-28), других представлений элементов (ИСО 10303-12), а также констант языка EXPRESS;
- язык моделирования должен полностью поддерживать принципы и парадигму моделирования, используемые для модели интеграции.
Пример — Если модель интеграции включает понятие класса как элемента другого класса, то язык моделирования должен иметь возможность представления указанного соотношения между конструктивами, представляющими классы;
- язык моделирования должен определять спецификации отображений или должен иметь вспомогательный язык отображения.
5.2.2 Описание метода
Настоящий компонент методологии может применяться для создания новой модели интеграции или для расширения существующей модели интеграции.
5.2.2.1 Создание новой модели интеграции
Эта ситуация проиллюстрирована на рисунке 8.
Рисунок 8 — Создание новой модели интеграции
Метод, используемый для создания модели интеграции, может зависеть от:
- парадигмы моделирования и принципов, используемых для развития и расширения модели;
- языка моделирования, в котором модель определена;
- области применения модели и контекста интегрируемой модели приложения.
Модель интеграции, определенная с помощью языка «сущность-соотношение» и парадигмы, может включать типы данных сущностей, представляющих классы, имеющиеся в интегрированных моделях приложений, а также может включать элементы сущностей, представляющих классы или индивидуальности, присутствующие в интегрируемых моделях приложений.
Модель интеграции, определенная с помощью логически обоснованного языка первого порядка и парадигмы, должна включать конструктивы, представляющие классы и индивидуальности, имеющиеся в интегрируемых моделях приложений.
Примечание — Модели соотношений между сущностями и логически обоснованный язык первого порядка — не единственные возможности для определения модели интеграции.
5.2.2.2 Расширение существующей модели интеграции
Данное действие показано на рисунке 9.
Рисунок 9 — Расширение модели интеграции
Данный метод, используемый для расширения модели интеграции, может зависеть от:
- структуры и семантики существующей модели интеграции;
- парадигмы моделирования и принципов, используемых для ее развития и расширения;
- языка моделирования, с использованием которого данная модель определена.
В зависимости от указанных соотношений расширение модели интеграции может иметь одну или несколько следующих характеристик. Для варианта модели типа «сущность-соотношение» это:
- создание дополнительных типов сущностей как специализаций существующих типов сущностей указанной модели интеграции;
- создание дополнительных соотношений модели интеграции;
- создание дополнительных ссылочных элементов внутри модели интеграции.
Для логически обоснованной модели:
- создание дополнительных конструктивов внутри модели интеграции.
Данные расширения не должны изменять существующие классы модели интеграции, так как это может нарушить работу существующих взаимных отображений модели интеграции и моделей приложений.
Если необходима разработка новой модели интеграции для удовлетворения требований интегрируемых моделей приложений, то также необходима разработка спецификации взаимного отображения исходной модели интеграции и новой модели интеграции.
5.2.2.3 Создание новой модели интеграции из существующей модели интеграции
Если существующая модель интеграции не удовлетворяет требованиям интегрируемых моделей приложений, то новая модель интеграции может быть получена путем модификации существующей модели интеграции.
Примечание — Модификацию модели интеграции следует отличать от расширения модели интеграции.
Методы, описанные в 5.2.2.1 и 5.2.2.2, используются для формулировки следующих дополнительных ограничений:
- исходную модель интеграции следует рассматривать как дополнительную модель приложения; она отображается на новую модель интеграции или
- каждая модель приложения, интегрированная с помощью исходной модели интеграции, должна быть интегрирована с помощью новой модели интеграции.
5.2.3 Условия окончания
По окончании процесса определения (расширения) модели интеграции необходимо удовлетворение следующих условий (условий окончания):
- область применения модели интеграции должна полностью покрывать область применения интегрируемых моделей приложений;
- все пустоты имеющейся модели интеграции на этапе анализа требований (см. 5.1) должны быть заполнены расширениями модели интеграции;
- семантические соотношения, имеющиеся между понятиями моделей приложений и понятиями модели интеграции, должны быть отражены в документации.
Примечание — Может оказаться невозможным проверить удовлетворение условиям окончания до момента создания спецификаций отображений интегрируемых моделей приложений.
5.3 Идентификация подмножества модели интеграции
Цель настоящего действия — идентифицировать подмножество модели интеграции, которое точно соответствует рассматриваемой модели приложения. Для получения взаимных отображений модели интеграции и нескольких интегрируемых моделей приложений необходимо обеспечить идентичность всех особых подмножеств моделей приложений в среде интеграции. В свою очередь, среда интеграции должна обеспечивать возможность регистрации идентифицированных подмножеств.
Пример — Если модель интеграции и рассматриваемые модели приложений определены на языке EXPRESS, то указанное подмножество модели интеграции может быть декларировано с помощью утверждений интерфейса в декларации представления (отображения) EXPRESS-X, определяющего спецификацию отображения на модель приложения.
Указанное действие показано на рисунке 10.
Рисунок 10 — Идентификация подмножества модели интеграции
В большинстве случаев выбор подмножества и выполнение отображений производятся путем итераций. При этом подмножество модели интеграции не может быть полностью определено, пока не будут отображены все конструктивы указанной модели приложения.
5.4 Взаимное отображение модели приложения и идентифицированного подмножества модели интеграции
Цель настоящего действия — задокументировать в электронном виде все соотношения между конструктивами модели приложения и соответствующим подмножеством модели интеграции.
Спецификации отображений задают преобразования, определяющие порядок представления элементов одной модели в качестве элементов другой модели. Спецификации отображений используются двумя способами в соответствии с нижеследующим.
Спецификации отображений могут описывать преобразования отображений между подмножеством модели интеграции и ранее созданной моделью приложения, данные которой существуют отдельно от данных модели интеграции. В данном случае спецификация отображения описывает преобразования, определяющие образ элементов одной модели, имеющий тот же смысл, что и образ элементов другой модели.
Спецификация отображения может описывать преобразования взаимного отображения подмножества модели интеграции и модели приложения, используемого как представление приложения. В данном случае спецификация отображения описывает порядок создания элементов представления приложения из элементов модели интеграции.
Если спецификации отображений созданы во время процесса интеграции, то новые понятия (ограничения) не должны быть представлены в спецификации отображения. Спецификации отображений ограничены преобразованиями структуры, терминологии и кодирования.
Примечание — Спецификация отображения, определенная декларативно, представляет собой двухстороннее отображение. Спецификация отображения, определенная процедурно (полностью или частично), представляет собой два отдельных односторонних отображения.
5.4.1 Предварительные условия
5.4.1.1 Языки отображений
Выбор языка отображения зависит от содержания создаваемых спецификаций отображений. Одно и то же отображение может быть описано несколькими спецификациями, причем каждая спецификация адресуется только к одной части (одному этапу) отображения. Различные языки отображений могут быть использованы для указанных различных частей общей спецификации отображения.
Примечание 1 — Некорректный выбор языка отображения может привести к возникновению пределов применения отображаемой модели.
Языки отображений должны обеспечивать следующие возможности:
- задание отображений, основанных на типах данных.
Примечание 2 — Спецификация отображения, соотносящего один тип данных с другим типом данных, — это запись, констатирующая, что каждый элемент одного типа данных отображается на соответствующий элемент другого типа данных;
- задание отображений одного типа данных на другой тип данных, задание отображений одного типа данных на комбинацию типов данных, задание отображений комбинации типов данных на один тип данных и задание отображений одной комбинации типов данных на другую комбинацию типов данных.
Примечание 3 — Спецификации отображений, использующие комбинации типов данных, часто требуют вопросительного утверждения (выражения) для определения диапазона элементов, для которого данное отображение является корректным;
- идентификация набора отображаемых элементов.
Примечание 4 — Наборы элементов могут быть основаны на типах данных, значениях атрибутов, диапазонах значений, соотношениях, путях ссылок, а также любых комбинациях указанных объектов;
- задание отображений, ассоциирующих некоторый тип данных одной модели приложения с указанным элементом (набором элементов) другой модели приложения.
Пример 1 — Тип данных сущности pump (насос) некоторой модели приложения может отображаться на элемент более общего типа данных сущности class_of_physical_object (класс физического объекта) модели интеграции, причем названием элемента может быть только pump;
- задание взаимных преобразований значений данных.
Пример 2 — Тип данных сущности person (лицо) с однозначным атрибутом name (имя) может отображаться на тип данных сущности с двумя атрибутами first_name (первое имя) и last_name (второе имя). Преобразование второй модели на первую модель представляет собой сцепку значений атрибутов. Преобразование в другую сторону требует синтаксического разбора значения атрибута источника.
Пример 3 — Различные модели могут использовать различные единицы измерения для представления физических величин, например длина или масса;
- спецификация отображений, основанных на параметризуемых повторяющихся образах.
Пример 4 — В примере 1 ассоциация названия с классом модели интеграции может использовать родственные элементы нескольких различных типов данных сущностей. Путем идентификации настоящей комбинации как примера другого отображения данная спецификация отображения может быть упрощена и сделана более согласованной;
- определение переменных внутри пространства названий каждой модели, являющейся частью отображения.
5.4.2 Описание метода
Выполнение анализа (см. 5.1) и выбор подмножества (см. 5.2.3) устанавливают спецификацию данных (подмножество модели интеграции), семантически эквивалентную модели приложения. Данное подмножество модели интеграции в общем случае будет отличаться от модели приложения по структуре и/или терминологии. Выполнение данного отображения, таким образом, устанавливает и описывает преобразования данных, соответствующие подмножеству модели интеграции, которое, в свою очередь, соответствует каждой модели приложения (и наоборот). Выполнение данного отображения показано на рисунке 11.
Рисунок 11 — Взаимное отображение модели приложения и подмножества модели интеграции
Результатом настоящего действия является отображение, которое характеризует:
- соответствие каждого конструктива рассматриваемой модели приложения конструктиву идентифицированного подмножества модели интеграции;
- соответствие каждого конструктива подмножества модели интеграции конструктиву идентифицированного подмножества модели приложения.
Для компонентов отображения используются следующие ограничения:
- каждый конструктив модели приложения должен соответствовать одному или нескольким конструктивам подмножества модели интеграции;
- каждое ограничение модели приложения должно соответствовать одному или нескольким ограничениям модели интеграции (отображения).
Взаимное отображение модели интеграции и каждой интегрированной модели приложения должно быть зарегистрировано как часть среды интеграции.
5.4.3 Условия окончания
Суммарное действие, заключающееся в интеграции модели приложения, закончено, если следующие спецификации выполнены и инициированы:
- спецификация подмножества модели интеграции, точно соответствующего семантике модели приложения;
- спецификация отображения, определяющего взаимное преобразование модели приложения и идентифицированного подмножества модели интеграции.
РЕГИСТРАЦИЯ ИНФОРМАЦИОННОГО ОБЪЕКТА
С целью однозначной идентификации информационного объекта в открытой системе настоящему стандарту присвоен следующий идентификатор объекта:
{iso standart 18876 part {2} version {1}}
Смысл данного идентификатора определен в ИСО/МЭК 8824-1 и описан в ИСО 10303-1.
Настоящее приложение описывает процесс интеграции, используя модель выполняемого действия. Указанная модель действия использует методику IDEF0 [10]. Она представлена набором рисунков, отражающих диаграммы действия, наборы определений указанных действий и двухсторонние потоки информации.
Примечание 1 — Для простоты представления элементов диаграммы стандарта по методике IDEF0 для моделей приложений и моделей интеграции используются английские аббревиатуры AM и IM соответственно.
Примечание 2 — Порядок расположения стрелок на диаграмме IDEF0 не означает, что какие-то элементы диаграммы имеют преимущество.
B.1 Интеграция моделей приложений (A-0)
Диаграмма контекста описания процесса интеграции показана на рисунке B.1.
Рисунок B.1 — Интеграция модели приложения (A-0)
Определения действий и потоков информации, показанных на рисунке B.1.
B.1.1 Эксперт по области приложения
Люди, знающие процессы и информацию, поддерживаемую моделью (механизмом) приложения.
См. 3.1.1 (входные данные).
Примечание — Модель приложения должна содержать утверждение об области ее применения.
B.1.3 Рассматриваемая модель интеграции
Модель интеграции, чей контекст перекрывает контекст интегрируемой модели приложения (входные данные).
Примечание — Модель интеграции должна содержать утверждение об области ее применения.
B.1.4 Информационные требования
Модели, документы, выборочные данные, диаграммы и другие описания информации, используемые внутри особой области приложения (контроль).
B.1.5 Интеграция моделей приложений
Для интеграции моделей приложений применяются методы, указанные в настоящем стандарте. Данные методы предназначены для представления понятий, структуры, терминологии и ограничений модели приложения, сформулированных в терминах модели интеграции (A0).
B.1.6 Спецификация отображения
См. 3.1.17 (выходные данные).
B.1.7 Парадигма моделирования и принципы
Правила, руководящие указания и практические рекомендации, используемые для интеграции и моделирования действий (контроль).
B.1.8 Эксперт по моделированию/интеграции
Люди, имеющие знания и опыт в области разработки и использования моделей интеграции и создания спецификаций (механизма) взаимных отображений моделей приложений и моделей интеграции.
B.1.9 Инструмент моделирования/интеграции
Программное обеспечение и другие инструменты, используемые для создания, корректировки и публикации моделей, спецификаций отображений и прочих спецификаций.
B.1.10 Модифицированная модель приложения
Пересмотренное представление информации, используемое внутри особой области приложения (выходные данные).
Примечание — Некоторые сценарии препятствуют модификации модели приложения. Например, если указанная модель приложения используется одним или несколькими приложениями системы, то может оказаться некорректным изменять ее в процессе интеграции.
B.1.11 Выбранная/обновленная модель интеграции
Модель интеграции, выбранная для интеграции одной или нескольких моделей приложений; модель интеграции может быть расширена как часть процесса интеграции (выходные данные).
B.2 Интеграция модели приложения (A0)
Структура указанного действия показана на рисунке B.2.
Рисунок B.2 — Интеграция модели приложения (A0)
Пересмотр модели приложения и/или других источников информации, содержащих требования к одной или нескольким областям приложений, с целью выбора (создания) подходящей модели интеграции, перекрывающей требуемый контекст модели и область применения модели (A1).
B.2.2 Эксперт по области приложения
См. B.1.1 (механизм для A1).
B.2.3 Контекст приложения модели
Контекст (см. 3.1.19) модели приложения (выходные данные A1; контроль A3 и A4).
См. 3.1.1 (входные данные A1).
B.2.5 Рассматриваемая модель интеграции
См. B.1.3 (входные данные A1).
B.2.6 Создание/расширение модели интеграции
Разработка модели интеграции, перекрывающей область применения модели и контекст интегрируемой модели приложения, а также расширение существующей модели интеграции для удовлетворения указанным требованиям (A2).
B.2.7 Отображение высокого уровня
Исходные взаимные отображения понятий моделей приложений и понятий модели интеграции (выходные данные A1, контроль A2 и A3).
B.2.8 Идентификация подмножества модели интеграции
Выбор конструктивов модели интеграции, удовлетворяющих требованиям понятий и ограничений моделей приложений (A3).
B.2.9 Информационные требования
См. B.1.4 (контроль A1).
Данные модели интеграции, полученные в процессе интеграции и отображения (выходные данные A3 и A4; контроль A2).
B.2.11 Пустоты модели интеграции
Понятия, присутствующие в модели приложения, но отсутствующие в модели интеграции, с которой интегрируется данная модель приложения (выходные данные A1, контроль A2).
B.2.12 Создание спецификации отображения
Определение порядка отображения элементов одной модели на элементы другой модели (A4).
B.2.13 Спецификация отображения
См. 3.1.17 (выходные данные A4).
B.2.14 Модифицированная модель приложения
См. B.1.10 (выходные данные A1, контроль A3 и A4).
B.2.15 Выбранная модель интеграции
Модель интеграции, выбранная для интеграции одной или нескольких моделей приложений, а также расширенная ее версия, способная выполнить указанную интеграцию (выходные данные A1, входные данные A2).
B.2.16 Выбранная/обновленная модель интеграции
См. B.1.10 (выходные данные A2, контроль A3).
Структура данного действия показана на рисунке B.3.
Рисунок B.3 — Анализ требований (A1)
B.3.1 Дополнительные понятия модели приложения
Понятия области применения и контекста модели приложения, обнаруженные в результате анализа существующей модели приложения и дополнительных информационных требований (выходные данные A12, контроль A13).
Понимание понятий, представленных моделью приложения, основанное на знании других моделей приложений и существующих моделей интеграции (выходные данные A11, контроль A12 и A13).
B.3.3 Эксперт по области приложения
См. B.1.1 (механизм A11 и A12).
B.3.4 Контекст приложения модели
См. B.2.3 (выходные данные A12, контроль A14).
См. B.1.2 (входные данные A11).
B.3.6 Рассматриваемая модель интеграции
См. B.1.3 (входные данные A14).
B.3.7 Отображение высокого уровня
См. B.2.7 (выходные данные A15).
B.3.8 Идентификация неявных требований
Отыскание и документальное оформление требований области применения и контекста модели приложения, не представленных явно конструктивами данной модели приложения (A12).
B.3.9 Идентификация соответствия модели интеграции
Установление взаимных отображений высокого уровня для понятий модели приложения и для выбранной модели интеграции (A15).
B.3.10 Информационные требования
См. B.1.4 (контроль A12).
B.3.11 Пустоты модели интеграции
См. B.2.11 (выходные данные A15).
B.3.12 Парадигма моделирования и принципы
См. B.1.7 (контроль A13).
B.3.13 Модификация модели приложения
Пересмотр структуры и содержания модели приложения для увеличения ее качества и степени соответствия установленным требованиям (A13).
B.3.14 Пересмотр понятий модели приложения
Получение доступа к понятиям модели приложения для полного понимания природы рассматриваемой области в процессе интеграции (A11).
B.3.15 Выбор модели интеграции
Идентификация модели интеграции, контекст которой перекрывает интегрируемую модель приложения (A14).
Примечание — Для обеспечения повторного использования модели интеграции необходимо рассматривать более широкий ее контекст, чем контекст, определяемый интегрируемой моделью приложения.
B.3.16 Выбранная модель интеграции
См. B.2.14 (выходные данные A14, контроль A15).
B.3.17 Модифицированная модель приложения
См. B.1.10 (выходные данные A13, контроль A14 и A15).
B.4 Создание/расширение модели интеграции (A2)
Структура настоящего действия показана на рисунке B.4.
Рисунок B.4 — Создание/расширение модели интеграции (A2)
B.4.1 Близкие понятия модели интеграции
Понятия, представленные конструктивами выбранной модели интеграции; их смысл близок, но не идентичен идентифицированным пустотам (выходные данные A21, контроль A22).
Пример — Конструктив модели интеграции, представляющий обобщение понятия, необходимого для особой модели приложения, является близким понятием модели интеграции.
B.4.2 Создание дополнительных конструктивов модели интеграции
Разработка новых конструктивов, расширяющих модель интеграции для заполнения идентифицированных пустот (A22).
B.4.3 Эквивалентные понятия модели интеграции
Существующие понятия модели интеграции, чей смысл и ограничения точно совпадают с понятиями, ранее идентифицированными как пустоты (выходные данные A21, контроль A23).
Примечание — Такая эквивалентность может быть обнаружена в результате установления различий представления или терминологии модели.
B.4.4 Идентификация отображаемых понятий модели интеграции
Отыскание понятий модели интеграции, чей смысл и ограничения перекрывают понятия идентифицированных пустот (A21).
См. B.2.10 (контроль A21, выходные данные A23).
B.4.6 Пустоты модели интеграции
См. B.2.11 (контроль A21).
B.4.7 Новые конструктивы модели интеграции
Расширения модели интеграции (выходные данные A23, контроль A24).
B.4.8 Выбранная модель интеграции
См. B.2.14 (входные данные A21 и A24).
B.4.9 Выбранная/обновленная модель интеграции
См. B.1.10 (выходные данные A24).
B.4.10 Обновление модели интеграции
Пересмотр определений, диаграмм и других спецификаций, описывающих модели интеграции, созданные эффективными методами в соответствии с нормативной документацией.
B.5 Отображение модели приложения на подмножество модели интеграции (A4)
Структура настоящего действия показана на рисунке B.5.
Рисунок B.5 — Отображение модели приложения на подмножество модели интеграции (A4)
Данные интеграции, полученные на основе оценки преобразований кодирования (выходные данные A43).
B.5.2 Спецификация отображения кодирования
Спецификации взаимных отображений кодирования модели приложения и соответствующего подмножества модели интеграции (выходные данные A43).
B.5.3 Установление спецификации отображений кодирования
Идентификация спецификаций взаимных отображений кодирования модели приложения и соответствующего подмножества модели интеграции (A43).
B.5.4 Установление спецификации структурного отображения
Идентификация спецификаций взаимных отображений структуры модели приложения и структуры подмножества модели интеграции (A41).
B.5.5 Установление спецификации отображения терминологии
Идентификация спецификаций взаимных отображений терминологии модели приложения и терминологии подмножества модели интеграции (A42).
См. B.2.10 (выходные данные A41, A42 и A43).
B.5.7 Спецификация отображения
См. B.1.6 (выходные данные A41, A42 и A43).
B.5.8 Спецификация структурного отображения
Спецификация взаимных отображений структуры модели приложения и структуры подмножества модели интеграции (выходные данные A41).
B.5.9 Данные структурного отображения
Данные интеграции, полученные на основе оценки структурных преобразований (выходные данные A41).
Данные интеграции, полученные на основе оценки преобразований терминологии (выходные данные A42).
B.5.11 Спецификация отображения терминологии
Спецификация взаимных отображений терминологии модели приложения и терминологии подмножества модели интеграции (выходные данные A42).
ПЕРЕЧЕНЬ ОПЦИЙ ПРОЦЕССА ИНТЕГРАЦИИ И ОТОБРАЖЕНИЯ
Настоящий перечень опций может быть использован для пересмотра выполнения следующих этапов процесса интеграции и отображения.
Модель приложения (см. 5.1.1.1)
Язык моделирования, используемый для модели приложения (см. 5.1.1.2)
Выбор модели интеграции (см. 5.1.2.1)
| 5 | ☐ ☐ ☐ | Контекст выбранной модели интеграции (см. 3.1.19) включает контекст интегрируемой модели приложения |
|---|---|---|
| 6 | ☐ ☐ ☐ | Если рассматриваются несколько моделей интеграции, то выбранная модель интеграции имеет область применения (см. 3.1.20), расположенную ближе всего или перекрывающую область применения интегрируемой модели приложения |
Анализ понятий модели приложения (см. 5.1.2.2)
| 7 | ☐ ☐ ☐ | Все возможные неявные понятия обнаружены и зарегистрированы |
|---|
Необходимо ответить на все следующие вопросы по каждому понятию, представленному в модели приложения
Выходные данные анализа (см. 5.1.3)
Модель интеграции (см. 5.2.1.1)
Язык моделирования (см. 5.2.1.2)
Создание новой модели интеграции (см. 5.2.2.1)
Для модели интеграции типа «сущность-соотношение»:
| 35 | ☐ ☐ ☐ | Интегрированные понятия указаны как классы модели интеграции или как ссылочные элементы внутри модели интеграции |
|---|
Для логически обоснованной модели интеграции:
| 36 | ☐ ☐ ☐ | Интегрированные понятия указаны как конструктивы внутри модели интеграции |
|---|
Расширение существующей модели интеграции (см. 5.2.2.2)
Для модели интеграции типа «сущность-соотношение»:
| 41 | ☐ ☐ ☐ | Расширения указаны как специализации существующих классов модели интеграции или как дополнительные ссылочные элементы внутри модели интеграции |
|---|
Для логически обоснованной модели интеграции:
| 42 | ☐ ☐ ☐ | Расширения указаны как дополнительные конструктивы внутри модели интеграции |
|---|
Создание модели интеграции из существующей модели интеграции (см. 5.2.2.3)
Для модели интеграции типа «сущность-соотношение»:
| 47 | ☐ ☐ ☐ | Интегрированные понятия указаны как классы модели интеграции или как ссылочные элементы внутри модели интеграции |
|---|
Для логически обоснованной модели интеграции:
| 48 | ☐ ☐ ☐ | Интегрированные понятия указаны как конструктивы внутри модели интеграции |
|---|
C.3 Идентификация подмножества модели интеграции
Результаты идентификации подмножества (см. 5.3)
| 49 | ☐ ☐ ☐ | Подмножество модели интеграции, точно соответствующее модели приложения, идентифицировано |
|---|---|---|
| 50 | ☐ ☐ ☐ | Идентичность подмножества модели интеграции зарегистрирована как часть модели интеграции |
C.4 Взаимное отображение модели приложения и идентифицированного подмножества модели интеграции
Язык отображения (см. 5.4.1.1)
Результат выполнения отображения (см. 5.4.2)
Выходные данные отображения (см. 5.4.3)
D.1 Модели, данные и модели данных
Замечания по модели (включая модели данных) дифференцируют по содержанию и представлению. Для физической модели все ясно: очень легко отличить пластиковую модель Эйфелевой башни, выполненную в масштабе 1:1000, от реальной Эйфелевой башни, находящейся в Париже. Имеются четкие отличия характеристик модели и того, что она представляет.
Для модели данных найти четкие отличия гораздо труднее: модель и соответствующий предмет имеют много общих характеристик. Рисунок D.1 иллюстрирует соотношения между моделью данных и соответствующим предметом.
Рисунок D.1 — Соотношение между моделью и предметом
Рисунок D.1 иллюстрирует очень простую модель данных: предметом является памятник архитектуры. Рассматриваемым объектом моделей данного типа (т.е. областью применения модели или предметной областью базы данных) являются индивидуальности (например, Эйфелева башня, Empire State Building в Нью-Йорке, пирамиды Гиза, мемориал принца Альберта и т.п.), которые являются компонентами класса, называемого «памятники архитектуры». Данная модель включает декларацию типа данных на языке EXPRESS (ИСО 10303-11); идентификатором указанного типа данных является monument. Тип данных сущности представляет (заменяет) класс «monument». Он позволяет компьютерным системам накапливать или обменивать информацию (как значения данных) о памятниках архитектуры. В данном случае рассматриваемая информация представлена атрибутами типа данных (т.е. названием памятника архитектуры и указанием места его расположения).
Так же как и при представлении класса «monument», тип данных сущности monument уже сам является классом. Его компонентами являются значения данных (элемент), соответствующие структуре определенных декларацией типа данных сущности. Элементы типов данных, определенные на языке программирования EXPRESS, кодируются по ИСО 10303-21 — последовательностью символов, начиная с «#100» (см. рисунок D.1). Указанный элемент является компонентом класса, заданного типом данных «monument» (структура данных соответствует декларации типа данных сущности, значения данных соответствуют типу данных и удовлетворяют ограничениям, декларированным для его атрибутов), и представляет индивидуальность (Эйфелеву башню), являющуюся компонентом класса «monument», представленного его типом данных. Указанную вторую связь можно частично вывести из следующих утверждений:
- #100 — это компонент класса «monument» (элемент типа данных);
- тип данных «monument» представляет (заменяет) класс «monument»;
- Эйфелева башня является компонентом класса «monument».
Последняя часть указанной связи, где символ #100 представляет Эйфелеву башню, а не какой-либо другой компонент класса «monument», зависит от возможностей интерпретатора значений данных (человека или компьютера) поставить в соответствие характерную последовательность «Эйфелева башня» и «Париж» реальному памятнику архитектуры в столице Франции.
Примечание — В случае, рассмотренном на рисунке D.1, значения данных (элементы) могут также представлять классы, если модель данных содержит типы данных, представляющие классы, чьи компоненты сами являются классами. Например, тип данных сущности class на языке EXPRESS может быть определен для представления класса, чьи компоненты являются (всеми) другими классами. Если декларация типа данных имеет вид:
| ENTITY class; name: STRING; END_ENTITY; |
|---|
то элемент, закодированный в виде:
представляет класс «monument». Возможно, это тот же класс, что был представлен типом данных сущности monument во фрагменте модели на рисунке D.1.
В настоящем стандарте термин «понятие» используется для ссылки на классы и на другие идеи, которые являются предметами (данными) модели. Термин «конструктив» используется для ссылки на элементы (данные) модели, представляющей или заменяющей понятие.
D.2 Контекст модели приложения
Контекст модели — это набор ограничений, устанавливающих предел расширения области применения модели без изменения существующих деклараций. Эти ограничения включают:
Примечание — Типографское соглашение, используемое в настоящем приложении: названия классов взяты в кавычки (например, «...»), названия типов данных выделены жирным шрифтом;
- понятия, которые частично используются моделью, но не представлены в ней явно;
- наследственные ограничения структуры модели.
Следующие методики могут быть использованы для обнаружения контекста модели приложения:
- действия, создающие или использующие данные, могут быть определены посредством анализа одной или нескольких подходящих моделей действия. Цель и представление каждой модели действия следует принимать во внимание, особенно в случае рассмотрения потоков информации, являющихся входными или выходными данными основного действия, описанного моделью действия.
Пример 1 — Модель действия с основным действием «process order (технологический заказ)» имеет входные данные с названием «purchase order (заказ на приобретение)». Представление модели действия производится менеджером предприятия — поставщика деталей. Ни модель действия, ни интегрируемая модель данных приложения не указывают явно, что заказ на приобретение дан конкретному предприятию — поставщику деталей. Это и есть ограничение, наложенное на модель приложения, так как передать заказ на приобретение какому-либо другому предприятию нельзя;
- ответственность организации за производство и контроль каждого элемента данных модели приложения должна быть установлена и приниматься во внимание.
Пример 2 — Идентификатор, название и описания элементов часто являются уникальными для одной организации, однако они могут повторяться, если организаций несколько. Модель приложения может устанавливать, что некоторый атрибут, например, «N детали» является уникальным. Анализ модели приложения должен определять организацию, задающую степень такой уникальности;
- другие сущности, являющиеся внешними по отношению к анализируемой модели приложения, но оказывающими влияние на корректность или применимость данных, должны быть также заданы и приниматься во внимание.
Пример 3 — Примеры таких внешних сущностей: физическое местонахождение, интервал времени, официальный орган регистрации.
| Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
| ISO/IEC 8824-1:1998 | IDT | ГОСТ Р ИСО/МЭК 8824-1:2001 «Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации» |
| ISO 10303-1:1994 | IDT | ГОСТ Р ИСО 10303-1:1999 «Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 1. Общие представления и основополагающие принципы» |
| ISO/TS 18876-1:2003 | - | <*> |
| <*> Соответствующий национальный стандарт отсутствует. До его принятия рекомендуется использовать перевод на русский язык данного международного стандарта. Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: - IDT — идентичные стандарты. | ||
БИБЛИОГРАФИЯ
| УДК 658.52.011.56:006.354 | ОКС 25.040.40 35.240.50 |
| Ключевые слова: автоматизированные промышленные системы, интеграция, жизненный цикл систем, управление производством | |