Товары в корзине: 0 шт Оформить заказ
Стр. 1 

171 страница

1299.00 ₽

Купить ПНСТ 173-2016 — бумажный документ с голограммой и синими печатями. подробнее

Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль"

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

 Скачать PDF

Идентичен PAS 19450:2015

Оглавление

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

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

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

4 Условные обозначения

5 Соответствие настоящему стандарту

6 Принципы и концепции OPM-методологии

     6.1 Принципы OPM-моделирования

     6.2 Основные понятия OPM-методологии

7 ОРМ-синтаксис и семантика сущностей

     7.1 Объекты

     7.2 Процессы

     7.3 OPM-сущности

8 Анализ синтаксиса и семантики ОРМ-связей

     8.1 Обзор процедурных связей

     8.2 Операционная семантика и поток команд управления исполнением

9 Процедурные связи

     9.1 Преобразующие связи

     9.2 Разрешающие связи

     9.3 Определяющие состояние преобразующие связи

     9.4 Определяющие состояние разрешающие связи

     9.5 Управляющие связи

10 Структурные связи

     10.1 Виды структурных связей

     10.2 Тегированная структурная связь

     10.3 Фундаментальные структурные взаимосвязи

     10.4 Определяющая состояние характеристическая реляционная связь

11 Мощности отношений (связей)

     11.1 Кратность объектов в структурных и процедурных связях

     11.2 Выражения для кратности объекта и ограничений

     11.3 Значение атрибута и кратные ограничения

12 Логические операторы AND, XOR и OR

     12.1 Логические процедурные связи типа AND

     12.2 Логические процедурные связи типа XOR и OR

     12.3 Расходящиеся и сходящиеся XOR- и OR-связи

     12.4 Определяющие состояние веерные XOR- и OR-связи

     12.5 Модифицирующие управление веерные связи

     12.6 Определяющие состояние и модифицирующие управление веерные связи

     12.7 Вероятности связей и вероятностные веерные связи

13 Путь выполнения и метки путей

14 Управление контекстом с использованием OPM-методологии

     14.1 Разработка структурной диаграммы

     14.2 Достижение надлежащего понимания модели

Приложение А (обязательное) Формальный OPL-синтаксис в расширенной форме Бэкуса — Наура (EBNF)

Приложение B (справочное) Руководство по применению OPM-методологии

Приложение C (справочное) OPM-моделирование с помощью OPD-диаграмм

Приложение D (справочное) Динамические свойства и моделирование в OPM-методологии

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

 
Дата введения01.06.2017
Добавлен в базу05.05.2017
Завершение срока действия01.06.2019
Актуализация01.01.2021

Этот документ находится в:

Организации:

05.12.2016УтвержденФедеральное агентство по техническому регулированию и метрологии95-пнст
РазработанООО НИИ Интерэкомс
ИзданСтандартинформ2017 г.

Automation systems and integration. Object-process methodology

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

пнет

173—

2016/

PAS 19450: 2015

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

ПРЕДВАРИТЕЛЬНЫЙ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ

Объектно-процессуальная методология

(PAS 19450:2015, ЮТ)

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

Москва

Стандартинформ

2017

Предисловие

1    ПОДГОТОВЛЕН ООО «НИИ экономики связи и информатики «Интерэкомс» (ООО «НИИ «Интер-экомс») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент»

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

4    Настоящий стандарт идентичен международному документу PAS 19450:2015 «Системы промышленной автоматизации и интеграция. Объектно-процессуальная методология» (PAS 19450:2015 «Automation systems and integration — Object-Process Methodology». IDT)

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

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандаргпа. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за девять месяцев до истечения срока его действия, разработчику настоящего стандарта по адресу 123423, г Москва, уп. Народного Ополчения, д. 32 ив Федеральное агентство по техническому регулированию и метрологии по адресу: 109074. г. Москва. Китайгородский проезд, д. 7, стр. 1.

В случае отмены наспюящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты» и журнале «Вестник Федерального агентства по техническому регулированию и метрологии». Уведомление будет размещено также на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ. 2017

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

ПНСТ 173—2016

3.63 уточнение (refinement): <модель> Детализация, которая позволяет увеличивать степень подробности и соответствующую полноту (3.8) модели.

3 64 объект типа resultee (resultee): Объект типа transformee (3.78). который приводит к реализации процесса (3.58).

3.65 заинтересованная сторона (stakeholder): <ОРМ> Индивидуум, организация или группа людей, которая имеет собственные интересы или может затрагиваться системой, разрабатываемой, разработанной или развернутой.

3 66 объект с внутренним состоянием (stateful object): Объект (3.39), обладающий определенными состояниями (3.69).

3 67 объект без внутреннего состояния (stateless object): Объект (3.39). не обладающий определенными состояниями (3.69).

3 68 состояние (state): <объект> Возможная ситуация или положение объекта (3.39).

Примечание — В объектно-процессуальной методологии (3 43) не существует понятия состояние процесса (358): например, «начальное», «действующее» или «конечное» состояние (в рамках существующей модели) Вместо этого объектно-процессуальная методология определяет и моделирует такие подпроцессы, как запуск, обработка или окончание См также обсуждение метамодели для объектно-процессуальной методологии в приложении С

3 69 состояние (state): <система> «Мгновенный снимок» модели системы, сделанный в определенный момент времени и показывающий все существующие экземпляры объекта (3.39), текущие состояния каждого экземпляра объекта с внутренним состоянием (3.66) и экземпляры процесса (3.58) вместе со значениями соответствующих истекших времен с момента выполнения этого «снимка».

3.70    выражение состояния (state expression): Уточнение (3.63), включающее в себя выявление соответствующего подмножества из множества состояний (3.69) объектов (3.39).

3.71    подавление состояния (state suppression): Абстракция (3.1). включающая в себя сокрытие соответствующего подмножества из множества состояний (3.69) объектов (3.39).

3.72    структурная связь (structural link): Графическое обозначение структурного соотношения (3.73) в объектно-процессуальной методологии (3.43).

3.73    структурное соотношение (structural relation): Функционально инвариантная связь или связь между сущностями.

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

3.74    структура (structure): <ОРМ> Совокупность объектов (3.39) в модели объектно-процессуальной методологии (3.43) и невременных отношений (или связей между ними).

3.75    системная диаграмма (System Diagram: SD): Объектно-процессуальная диаграмма (3.41) с единственным системным процессом (3.58). указывающим на системную функцию (3.23) и объекты (3.39). соединенные с данной функцией для отображения общего контекста (3.11) для анализа системы верхнего уровня.

Примечание — Системная диаграмма является корнем древа OPD-процесса (3 45) и не имеет степени детализации вне общего контекста, т е отсутствует детализированный объект refmee (3 62) Любая объектно-процессуальная диаграмма, кроме системной диаграммы, является узлом на древе OPD-процесса. обусловленным уточнением (3.63).

3.76    сущность (thing): <ОРМ> Объект (3.39) или процесс (3.58).

3.77    преобразование (transformation): Создание (формирование, построение) или потребление (удаление, уничтожение) объекта (3.39) или изменение состояния (3.69) объекта.

Примечание — Преобразование может выполнять только процесс (3 58).

3.78    объект типа transformee (transformee): Объект (3.39), который позволяет преобразовывать (создавать, потреблять или воздействовать) процесс (3.58).

3.79    преобразующая связь (transforming link): Связь, указывающая на потребление, воздействие или взаимодействие.

3.80    разворачивание (unfolding): Уточнение (3.63). которое позволяет дополнительно детализировать сущность типа refmee (3.62). а также включать другие сущности (3.76) и связи (3.36) между ними.

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

5

Примечание 2 — Разворачивание в основном применяют к объектам (3.39) для раскрытия информации о разворачиваемом объекте

3.81    значение (value): <атрибут> Состояние (3.69) атрибута (3.4).

3.82    значение (value): «функциональный Выигрыш, измеряемый в затратах, который данная функция (3.23) обеспечивает для системы.

3.83    сущность типа whole (whole): Комплексная сущность (3.76). состоящая из двух или более частей, каждая из которых имеет такую же устойчивость (3.50), как и совокупность частей вместе.

4 Условные обозначения


6


Object


| Object |


I Object i



ППИР>^


Объект (object)

Физический объект (physical object)

Объект внешней среды (environmental object)

Процесс (process)

Физический процесс (physical process)

Процесс внешней среды (environmental process)

Состояние (state)

Агрегация — является частью (aggregation-participation) Представление-характеризация (exhibition-characterization) Обобщение-специализация (generalization-specialization)

Классификация-инстанцирование (classification-instantiation)

Однонаправленная тегированная структурная связь (unidirectional tagged structural link)

Двунаправленная тегированная структурная связь (bidirectional tagged structural link) Агентская связь (agent link)

Инструментальная связь (instrument link)

Взаимодействующая связь (effect link)

Потребительская связь (consumption link)

Результирующая связь (result link)


ПНСТ 173—2016


Пара входных-выходных связей (input-output link pair) Инструментальная ситуационная связь (instrument event link) Потребительская ситуационная связь (consumption event link) Инструментальная условная связь (instrumental condition link) Потребительская условная связь (consumption condition link) Инициализирующая связь (invocation link) Самоинициализирующаяся связь (self-invocation link)

“Ж

Ь*

ь*

У-*

ь*

V

)-*<

)—#(

Передержанная исключающая связь (over-time exception link)

Недодержанная исключающая связь (under-time exception link)

5    Соответствие настоящему стандарту

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

a)    При частичном (символическом) соответствии ОРМ-методологии следует использовать ее лингвистическую часть, а именно ОРМ-семантику и синтаксис:

1)    используя только ОРМ-символы, определенные в разделе 4. и со смыслом, указанным в настоящем стандарте;

2)    используя только ОРМ-элементы, определенные в разделах 7—12. со смыслом и положениями. указанными в настоящем стандарте.

b)    Полное соответствие ОРМ-методологии должно требовать:

1)    соответствия с а);

2)    соответствия подхода и схемы моделирующих систем с ОРМ-методологией. как это определено в разделах 6—14.

c)    Соответствие с требованиями к разработчику инструментария требует:

1)    соответствия с а);

2)    обеспечения выполнения Ь) — пользователи должны руководствоваться и придерживаться Ь) на основе формальной трактовки а);

3)    поддержки OPL-языка в соответствии с определениями расширенной формы Бэкуса — Наура (EBNF). указанными в приложении А.

6    Принципы и концепции ОРМ-методологии

6.1    Принципы ОРМ-моделирования

6.1.1    Моделирование как деятельность, способствующая достижению целей

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

7

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

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

6.1.2    Унификация функций, структуры и модели поведения

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

В ОРМ-модели поведения системы, называемой ее динамикой, должны отражаться механизмы, которые стечением времени могут воздействовать на системы для преобразования объектов системы, т. е. объектов, которые являются внутренними по отношению к системе, и/или объектов окружающей среды, т. е. объектов, которые в последнем случае являются внешними по отношению к системе.

Сочетание структуры системы и ее поведения позволяет системе выполнять функцию, которая должна придавать системе (функциональную) ценность (по крайней мере одной из заинтересованных сторон, которая является потребителем системы). ОРМ-модель интегрирует функциональные (утилитарные). структурные (статические) и поведенческие (динамические) аспекты системы в единую унифицированную модель. Поддерживая внимание с точки зрения общей системной функции, эта унификация «структура-поведение» дает единую согласованную систему критериев для понимания системы интересов и повышения ее интуитивного понимания (при соблюдении формального синтаксиса).

6.1.3    Определение функциональной ценности

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

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

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

6.1.4    Связь между функциональностью и поведением модели

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

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

8

ПНСТ 173—2016

Соответствующие конструкции системы — это мосты и паромы. Хотя функция и первичный процесс — River Crossing (Переправа через реку) — одинаковы для обеих конструкций, тем не менее они резко различаются по своей структуре и модели поведения.

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

6.1.5    Установка границ системы

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

6.1.6    Ясность и полнота компромиссных решений

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

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

6.2 Основные понятия ОРМ-методологии

6.2.1    Бимодальное представление

ОРМ-модель должна быть бимодальной (двухуровневой), выражая семантически эквивалентные графические и текстовые представления. Каждая графическая диаграмма ОРМ-модели (т. е. OPD-диаграмма) должна иметь эквивалентный ОРМ-текстовый раздел, состоящий из одного или нескольких ОРМ-лредложений на OPL-языке.

Примечание 1 — Бимодальное графически-текстовое представление ОРМ-модели способствует привлечению нетехнических заинтересованных сторон к выявлению требований и начальному концептуальному моделированию системы на стадии ее разработки Это позволяет привлекать заинтересованные стороны к активному участию в разработках и обнаруживать ошибки вскоре после их непреднамеренного появления Бимодальное представление также помогает начинающим пользователям ОРМ-методологии оперативно знакомиться с семантикой графического ОРМ-метода при проверке текста и связанной с ним графикой

Примечание 2 — В приложении А определен OPL-синтаксис, использующий допущения ИСО/МЭК14977.

Примечание 3 — Для большинства OPD-рисунков настоящего стандарта соответствующий раздел OPL-предложений сопровождается графической ОРО-диаграммой

6.2.2    Элементы моделирования в ОРМ-методологии

Элементы как основные композиционные блоки любой системы, смоделированные в ОРМ-методологии. должны быть двух видов: сущностей и связей. Элементы моделирования объекта и процесса определяют эти сущности в контексте модели. Моделируемые элементы связи должны определять ассоциации между сущностями в контексте модели. Объекты должны быть как без внутреннего состояния, так и с внутренним состоянием, а связи должны быть либо процедурными, либо структурными. На рисунке 1 представлен общий обзор ОРМ-метамодели.

9

ОРМ Element — ОРМ-элемемт; ОРМ Link — ОРМ саязь ОРМ Thing — ОРМ-сущмость connects — соединяет; Structural Link — структурная связь. Process — процесс; Object — объект, Procedural Link — процедурная связь

Рисунок 1 — Общая структура ОРМ метамодели

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

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

6.2.3    ОРМ-сущности: объекты и процессы

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

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

Примечание — Процессы проверки для определения того, какие подпроцессы действуют на момент проверки, позволяют выявлять состояние процесса ОРМ-методология не определяет в явном виде модель состояния процесса (см метамодель процесса в приложении С).

6.2.4    ОРМ-связи: процедурные и структурные

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

10

ПНСТ 173—2016

Содержание

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

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

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

4    Условные обозначения................................................................6

5    Соответствие настоящему стандарту....................................................7

6    Принципы и концепции ОРМ-методологии................................................7

6.1    Принципы ОРМ-моделирования.....................................................7

6.2    Основные понятия ОРМ-методологии................................................9

7    ОРМ-синтаксис и семантика сущностей.................................................12

7.1    Объекты........................................................................12

7.2    Процессы.......................................................................12

7.3    ОРМ-сущности..................................................................13

8    Анализ синтаксиса и семантики ОРМ-связей.............................................16

8.1    Обзор процедурных связей........................................................16

8.2    Операционная семантика и поток команд управления исполнением......................17

9    Процедурные связи..................................................................18

9.1    Преобразующие связи............................................................18

9.2    Разрешающие связи..............................................................20

9.3    Определяющие состояние преобразующие связи......................................23

9.4    Определяющие состояние разрешающие связи.......................................28

9.5    Управляющие связи..............................................................30

10    Структурные связи..................................................................46

10.1    Виды структурных связей........................................................46

10.2    Тегированная структурная связь...................................................46

10.3    Фундаментальные структурные взаимосвязи........................................48

10.4    Определяющая состояние характеристическая реляционная связь......................59

11    Мощности отношений (связей)........................................................64

11.1 Кратность объектов в структурных и процедурных связях..............................64

11.2 Выражения для кратности объекта и ограничений....................................66

11.3    Значение атрибута и кратные ограничения..........................................69

12    Логические операторы AND. XOR и OR.................................................69

12.1    Логические процедурные связи типа AND...........................................69

12.2    Логические процедурные связи типа XOR и OR......................................71

12.3    Расходящиеся и сходящиеся XOR- и OR-связи.......................................72

12.4    Определяющие состояние веерные XOR- и OR-связи.................................74

12.5    Модифицирующие управление веерные связи.......................................75

12.6    Определяющие состояние и модифицирующие управление веерные связи...............75

12.7    Вероятности связей и вероятностные веерные связи..................................77

13    Путь выполнения и метки путей.......................................................79

14    Управление контекстом с использованием ОРМ-методологии..............................81

14.1    Разработка структурной диаграммы................................................81

14.2    Достижение надлежащего понимания модели........................................81

III

ПНСТ 173—2016

Приложение А (обязательное) Формальный OPL-синтаксис в расширенной форме

Бэкуса — Наура (EBNF)..................................................101

Приложение В (справочное) Руководство по применению ОРМ-методологии...................116

Приложение С (справочное) ОРМ-моделирование с помощью OPD-диаграмм..................119

Приложение D (справочное) Динамические свойства и моделирование в ОРМ-методологии......156

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

IV

ПНСТ 173—2016

Введение

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

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

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

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

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

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

Настоящий стандарт устанавливает требования к представлению нормативного текста, который должен соответствовать расширенной спецификации в форме Бэкуса — Наура (EBNF) для синтаксиса языка. В разделах 6—13 все элементы представлены лишь с минимальным упоминанием методологических аспектов: в разделе 14 представлены способы управления контекстом, связанные с масштабированием (in-zooming) и развертыванием (unfolding).

В настоящем стандарте используется ряд соглашений (общепризнанных подходов) относительно представления ОРМ-методологии. В частности, жирный шрифт типа Arial в тексте и жирный курсив шрифта типа Arial в подписях к рисункам, в таблицах и заголовках предназначен для наименований меток ОРМ-обьектов. процессов, состояний и тэгов связей. Ключевые слова OPL-языка выделяются обычным шрифтом типа Arial с запятыми и периодически — жирным шрифтом типа Arial. Большинство диаграмм содержат как графические изображения OPD-диаграмм. так и текстовые эквиваленты OPL-языка. Поскольку они относятся к спецификациям языка, существенно использовать точные определения терминов; некоторые общеупотребительные термины могут иметь особый смысл при использовании ОРМ-методологии. В разделе В.6 поясняются другие соглашения, принимаемые при использовании ОРМ-методологии.

В приложении А представлен формальный синтаксис OPL-языка. представленный в расширенной форме Бэкуса — Наура (EBNF).

В приложении В содержатся соглашения и шаблоны, обычно используемые в приложениях ОРМ-методологии.

В приложении С рассмотрены различные аспекты ОРМ-методологии в качестве ее моделей.

В приложении D обобщены динамические и (имитационные) возможности моделирования ОРМ-методологии.

VI

ПНСТ 173—2016/ PAS 19450:2015

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

СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ Объектно-процессуальная методология

Automation systems and integration Object-process methodology

Срок действия прсдстандарта — с 2017—06—01

по 2019—06—01

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

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

Хотя в настоящем стандарте приведен ряд поясняющих примеров использования ОРМ-методологии. в ней не предпринимались попытки полного описания всевозможных применений данной методологии.

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

В настоящем стандарте нормативные ссылки отсутствуют.

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

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

3.1    абстракция (abstraction): Уменьшение степени детализации и модельной полноты системы (3.8) для достижения лучшего понимания.

3.2    объекты, подвергаемые влиянию (изменениям) со стороны процесса (affectee): Объект типа transformee (3.78). который зависит от возникновения процесса (3.58), т. е. от изменения его состояния (3.69).

Примечание — Объектом типа affectee может быть только объект с внутренним состоянием (366) Объект без внутреннего состояния (3 67) может только создаваться или использоваться, но не подвергаться изменениям его состояния

3.3    агент (agent): Реализатор (3.17), которым могут быть человек или группа людей.

3 4 атрибут (attribute): Объект (3.39), который характеризует любую сущность (3.76), кроме самого себя

3.5 поведение (behaviour): Преобразование (3.77) объектов (3.39) в результате применения модели ОРМ-методопогии (см. 3.43). содержащей совокупность сущностей (3.76) и связей (3.36) объектов в модели.

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

3.6    бенефициар (beneficiary): <система> Заинтересованная сторона (3.65), которая получает функциональную выгоду (3.82) от работы системы (3 46).

3.7    класс (class): Совокупность сущностей (3.76) с одними и теми же значениями устойчивости (3.50), отличительными свойствами и установленными ценностями, а также с одним и тем же набором признаков (особенностей) (3.21) и состояний (3.69).

3.8    полнота (completeness): <модель системы» Степень, в которой все детали системы раскрываются в модели.

3.9    условная связь (condition link): Процедурная связь (3.56) от объекта (3.39) или состояния объекта (3.69) к процессу (3 58). обозначающая процедурное ограничение.

3.10    объекты, потребляемые процессом (consumee): Объект типа transformee (3.78). который при возникновении процесса (3.58) потребляется или исключается.

3.11    контекст (context): <модель> Часть модели ОРМ-методологии (3.43). представленная в виде OPD-диаграммы (3.41) процесса и соответствующего текста на OPL-языке (3.42).

3.12    управляющая связь (control link): Процедурная связь (3.56) с дополнительной семантикой управления.

3.13    модификатор управления (control modifier): Символ, дополняющий связь (3.36) для введения в нее управляющей семантики и выполнения управляющей связи (3.12).

Примечание — Модификаторы управления — это буквы е- для события (3.18). или буквы ’с‘ — для условия

3.14    дискриминирующий атрибут (discriminating attribute): Атрибут (3.4), чьи различные значения (3.81) определяют соответствующие специализированные взаимоотношения.

3.15    эффект, воздействие (effect): Изменение состояния (3.69) объекта (3.39) или значения (3.81) атрибута (3.4).

Примечание — Термин «эффект» применяется только к объектам, имеющим внутреннее состояние

(366)

3.16    элемент (element): Сущность (3.76) или связь (3.36).

3.17    реализатор, средство реализации (enabler): <процесс> Объект (3.39), который создает возможности для процесса (3.58), но не способен преобразовывать его.

3.18    событие (event): <ОРМ> Момент создания (или появления) объекта (3.39). или момент перехода объекта в определенное состояние (3 69). или момент инициализации оценки процесса (3.58) при установке предварительных условий (3.53).

3.19    событийная связь (event link): Управляющая связь (3.12). обозначающая событие (3.18). происходящее с объектом (3.39) или с состоянием (3.69) процесса (3.58).

3.20    экспонент (exhibitor): Сущность (3.76). которая представляет признак (или характеризуется особенностью (3.21)) с помощью связи типа «представление-характеризация».

3.21    признак, особенность (feature): Атрибут (3 4) или операция (3.46).

3.22    сворачивание (folding): Способ абстракции (обобщения) (3.1). реализуемый путем скрытия сущностей типа refiiteables (3.61) развернутого объекта типа геГтее (3.62).

Примечание 1 — Четырьмя видами свернутых сущностей типа геЬпеаЫез являются части (свернутые части), признаки (3 21) (свернутые признаки), специализации (свернутые специализации) и экземпляры (3 28) (свернутые экземпляры).

Примечание 2 — Свертывание в основном применяют к объектам (3 39) Что касается процесса, то его подпроцессы не упорядочены, что является достаточным для моделирования асинхронных систем, в которых временной порядок процессов не определен

Примечание 3 — Противоположным термину «сворачивание» является термин «разворачивание» (3.80)

3 23 функция (function): Процесс (3.58), который приносит бенефициару (3.6) функциональную выгоду (3.82).

3 24 объект типа general (general): <ОРМ> Сущность типа refmeable (3.61) со своими специализациями.

3.25    информационный (informatical): Термин, относящийся, например, к данным, информации, знаниям (или к информатике).

3.26    наследование (inheritance): Закрепление элементов (3.16) объекта типа general (3.24) в ОРМ-методологии (3.43) за их специализациями.

2

ПНСТ 173—2016

3.27    входная связь (input link): Связь (3.36) между состоянием источника (3.69) (поступающего на вход) объекта (3.39) и преобразующим процессом (3.58).

3.28    экземпляр (instance): <модель> Экземпляр объекта (3.39) или процесса (3.58), который является объектом типа refitiee (3.62) в связи типа «классификация-инстанцирование».

3.29    экземпляр (instance): <операционное> Экземпляр объекта (3.39) или процесса (3.58), который является фактической, однозначно идентифицируемой сущностью (3.76) и который существует во время функционирования модели (3.46), например, во время моделирования или при ее реализации.

Примечание — Экземпляр процесса можно идентифицировать по действующим экземплярам набора существующих объектов (3 32) во время возникновения и начала процесса и появления конечных временных меток

3.30    инструментальное средство (instrument): Средство реализации (3.17). не являющееся человеком.

3.31    инициализация (invocation): <процесс> Активация одного процесса (3.58) с помощью другого процесса.

3.32    набор существующих объектов (involved object set): Совокупность из набора предварительно обработанных объектов (3.54) и набора апостериорно обработанных объектов (3.52).

3.33    детализированный контекст (in-zoom context): Сущности (3.76) и связи (3.36) в пределах сущности, находящейся в детализированном состоянии.

3 34 детализация (in-zooming): <объект> Разворачиваемая (3.80) часть объекта (3.39). которая указывает на пространственное упорядочение составных объектов.

3.35    детализация (in-zooming): <процесс> Разворачиваемая (3.80) часть процесса (3.58). которая указывает на временное частичное упорядочение составных процессов.

3.36    связь (link): Графическое выражение структурного соотношения (3.73) или процедурного соотношения (3.57) между двумя сущностями (3.76) ОРМ-методопогии (3.43).

3.37    метамодель (metamodel): Модель языка моделирования (или его часть).

3.38    факт модели (model fact): Установленное соотношение между двумя сущностями (3.76) в ОРМ-методопогии (3.43) или двумя состояниями (3.69) в модели ОРМ-методологии.

3.39    объект (object): <ОРМ> Элемент (3.16) модели, характеризующий сущность (3.76). которая должна или может существовать физически или информационно (3.25).

3 40 класс объектов (object class): Совокупность объектов (3.39). имеющих одну и ту же структуру (3.74) и алгоритм преобразования (3.77).

3.41 объектно-процессуальная диаграмма, OPD-диаграмма (Object-Process Diagram; OPD): Графическое представление модели (или части модели) в объектно-процессуальной методологии (3.43), в которой объекты (3.39) и процессы (3.58) в рассматриваемой области представляются среди объектов и процессов вместе со структурными связями (3.72) и процедурными связями (3.56).

3 42 объектно-процессуальный язык, OPL-язык (Object-Process Language; OPL): Разновидность английского естественного языка, который текстуально характеризует модель объектно-процессуальной методологии (3.43). как объектно-процессуальная диаграмма (3.42) характеризует ее графически.

3.43 объектно-процессуальная методология (Object-Process Methodology; ОРМ): Формальный язык и метод определения сложных, многопрофильных систем с помощью единственной функциональной структурной поведенческой унифицированной модели, которая использует бимодальное графиче-ски-текстовое представление объектов (3.39) в системе и их преобразование (3.77) или их использование в процессах (3.58).

3 44 древо OPD-объектов (OPD object tree): Древовидный граф, чьим корнем является объект (3.39). детализируемый посредством уточнения (3.63).

3.45 древо OPD-процессов (OPD process tree): Древовидный граф, корнем которого является системная диаграмма (3.75). а каждый узел представляет собой объектно-процессуальную диаграмму (3.42). получаемую путем детализации (3.35) процесса (3.58). приведенного на его предшествующей OPD-диаграмме (или системной диаграмме), и в каждой из которых ребра графа направляются от уточненного процесса на родительской OPD-диаграмме к аналогичному процессу на дочерней OPD-диаграмме.

Примечание — Уточнение модели объектно-процессуальной методологии (343). как правило, происходит путем декомпозиции процесса посредством его детализации, поэтому древо OPD-процессов служит в качестве основного средства навигации по ОРМ-модели

3

3.46    операция (operation): Процесс (3.58), который выполняет сущность (3.76). характеризующая любую другую сущность, кроме самой себя.

3.47    выходная связь (output link): Связь (3.36) между преобразующим процессом (3.58) и выходным (целевым) состоянием (3.69) объекта (3.39).

3 48 обобщение (out-zooming): <объект> Операция, обратная детализации (3.34) объекта (3.39).

3 49 обобщение (out-zooming): <процесс> Операция, обратная детализации (3.35) процесса (3.58).

3 50 устойчивость (perseverance): Свойство (3.60) сущности (3.76). которое может быть статическим. определяющим объект (3.39), или динамическим, определяющим процесс (3 58).

3.51    постусловие (postcondition): <лроцесс> Условие, которое является результатом успешного выполнения процесса (3.58).

3.52    набор апостериорно обработанных объектов (postprocess object set): Совокупность объектов (3.39). оставшихся или появившихся в результате завершения процесса (3.58).

Примечание — Набор апостериорно обработанных объектов может содержать объекты, обладающие внутренними состояниями (3.66). в которых специфические состояния (3.69) будут возникать в результате выполнения процесса

3.53    предварительное условие (precondition): <процесс> условие, необходимое для запуска процесса (3.58).

3 54 набор предварительно обработанных объектов (preprocess object set): Совокупность объектов (3.39). предназначенных для их оценки до начала процесса (3.58).

Примечание — Набор предварительно обработанных объектов может вклкнатьв себя структурированные объекты (3 66), для которых конкретные состояния (3 69) необходимы в случае реализации какого-либо процесса

3.55 исходный смысл (primary essence): <система> Смысл большинства сущностей (3.76) в системе. который может быть либо информационным (3.25). либо физическим.

3 56 процедурная связь (procedural link): Графическое обозначение процедурного отношения (3.57) в ОРМ-методологии (3.43).

3.57    процедурное отношение (procedural relation): Соединение или связь между объектом (3.39) или состоянием объекта (3.69) и процессом (3.58).

Примечание 1 — Процедурные отношения определяют, как система действует, выполняя свою функцию (3.23) и обозначая зависящую от времени или условную инициализацию процессов, которые преобразуют объекты

Примечание 2 — Инициализация (3 31) или исключающая связь (3 36) означают временный объект в потоке сигналов управления между двумя процессами

3.58    процесс (process): Преобразование (3.77) в системе одного или нескольких объектов (3.39).

3.59    класс процесса (process class): Шаблон для процессов (3.58). которые выполняют преобразование (3.77) одного и того же объекта (3.39) в соответствии с шаблоном.

3.60    свойство (property): Моделирующая аннотация, общая для всех элеменлюв (3.16) определенного вида, которая служит для различения этого элемента

Примечание 1— Мощность ограничений, метки путей и теги структурной связи (3 72) часто являются аннотациями свойств

Примечание 2 — В отличие от атрибута (3 4) значение свойства не может изменяться в процессе моделирования или оперативной реализации Каждый вид элемента обладает собственным набором свойств

Примечание 3 — Свойство является атрибутом элемента в мета-модели (3 37) ОРМ-методологии

(343)

3 61 сущность типа refineable (имя существительное) (refineable): <ОРМ> Сущность (3.76), поддающаяся детализации (3.63), которая может быть сущностью типа whole (3.83), экспонентом (3.20). сущностью типа general (3.24) или классом (3.7).

3 62 сущность типа refinee (refinee): Сущность (объект) (3.76). детализирующая сущность типа refineable (3.61). которая может быть частью, признаком (3.21). специализацией или экземпляром (3.29).

Примечание — Каждый из четырех видов объектов типа refinees имеет соответствующую сущность типа refineable (типа «часть-целое», «признак-представитель», «детализация-обобщение», «экземпляр-класс»),

4