ГОСТ Р ИСО 19440-2010 Интеграция предприятия. Конструкции для моделирования предприятий

ГОСТ Р ИСО 19440-2010

Группа Т58

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

ИНТЕГРАЦИЯ ПРЕДПРИЯТИЯ

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

Enterprise integration. Constructs for enterprise modelling

ОКС 25.040.40

Дата введения 2011-09-01

Предисловие

1 ПОДГОТОВЛЕН Научно-техническим центром ИНТЕК на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО 19440:2007* "Интеграция предприятия. Конструкции для моделирования предприятий" (ISO 19440:2007 "Enterprise integration - Constructs for enterprise modelling").

________________

* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .

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

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012** (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

Введение

0.1 Основные сведения

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

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

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

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

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

- поддержку управления изменениями;

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

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

В приложении В приведено обоснование целесообразности моделирования предприятий на базе конструкций, изложены основные сведения, а также указаны области моделей предприятия, в рамках которых функционирует настоящий стандарт (см. ИСО 19349). Описание трех измерений этой схемы приведены в 0.2, 0.3 и 0.4.

В настоящем стандарте использованы результаты работ целевой группы IFAC/IFIP по интегрированию предприятий, консорциума CIMOSA и научно-исследовательского проекта ATHENA.

0.2 Измерение представлений модели предприятия

В ИСО 19439 и ИСО 15704 представления модели предприятия (далее - представления модели) используются для обеспечения селективного восприятия предприятия, которое особо выделяет какой-либо аспект рассматриваемого предмета и игнорирует другие. В частности в данных стандартах приведены четыре представления модели предприятия (функциональное, информационное, ресурсное, организационное), которые должны рассматриваться в структуре, архитектуре или методологии, для обеспечения возможности моделирования основных аспектов деятельности предприятия. Кроме того, в соответствии с ИСО 15704:2000, приложение А, пункт А.3.1.5.3.2 "при необходимости другие представления могут быть определены и поддержаны техническими средствами", например экономические представления, представления решений, представления цели и представления реализации. В этом случае конструкции, установленные в настоящем стандарте, могут быть дополнены атрибутами, обеспечивающими поддержку этих представлений, или может быть необходимо выбрать новые представления. Следовательно спецификации конструкций языка моделирования должны отражать их предназначенное использование и отображение в одном или нескольких конкретных представлениях. Для обеспечения совместимости экземпляров конструкций, которые могут появиться более чем в одном представлении, необходимо использовать автоматизированные средства.

0.3 Измерение фазы модели предприятия

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

0.4 Измерение универсальности

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

Сноска в тексте стандарта, выделенная курсивом*, приведена для уточнения текста оригинала.

________________

* В бумажном оригинале обозначения и номера стандартов и нормативных документов приводятся обычным шрифтом, кроме отмеченного в разделе "Предисловие" знаком "**". - .

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

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

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

Примечание - Компьютерное моделирование предприятий может предшествовать компьютерной интеграции или взаимодействию "человек - система".

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

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

_______________

* Таблицу соответствия национальных стандартов международным см. по ссылке. - .

ИСО/МЭК 14977 Информационные технологии. Синтаксический метаязык. Расширенный BNF (ISO/IEC 14977, Information technology - Syntactic metalanguage - Extended BNF)

________________

ИСО/МЭК 14977 доступен для бесплатного скачивания в сети Интернет по адресу: http://isotc.iso.org/livelink/livelink/fetch/2000/2489/lttf_Home/PubliclyAvailableStandards.htm.

ИСО 19439:2006 Интеграция предприятия. Основы моделирования предприятия (ISO 19439:2006, Entreprise integration - Framework for enterprise modelling)

3 Термины, определения и сокращения

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

В настоящем стандарте использованы термины, установленные в ИСО/МЭК 15288:2002, ИСО 15531-1:2004, ИСО 15704:2000 и ИСО 19439:2006, а также следующие термины с соответствующими определениями.

Примечание - Наименования терминов, описывающих конструкции, в тексте настоящего стандарта начинаются с прописной буквы, чтобы читателю было легче отличать их от случаев общего применения этих же терминов, особенно чтобы отличать конструкции "Возможности", "Домен", "Деятельность предприятия", "Событие" и "Ресурсы" от терминов "возможности", "домен" (или "домен предприятия"), "деятельность предприятия", "событие" и "ресурсы" общего применения. Более подробная информация приведена в разделе 6.

3.1.1 агрегирование (aggregation): Процесс или результат объединения конструкций языка моделирования и других компонентов модели в единое целое.

Примечание 1 - Конструкции языка моделирования и другие компоненты модели могут быть агрегированы в более чем один объект.

Примечание 2 - Атрибут "Часть (чего-либо)" и атрибут "Состоит_из" используют во взаимосвязях агрегации, описанных в разделе 5.

[ИСО 19439:2006]

3.1.2 атрибут (attribute): Единица информации, обозначающая свойство объекта.

[ИСО 15704:2000]

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

3.1.4 бизнес-процесс (business process): Конструкция, представляющая собой частично упорядоченный набор бизнес-процессов и/или видов деятельности предприятия, которые могут быть осуществлены для реализации одной или более задач предприятия с целью достижения желаемого конечного результата.

3.1.5 способность (capability): Качество, характеризующее способность осуществлять данный вид деятельности.

[ИСО 15531-1:2004]

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

Примечание - Возможности могут быть агрегированы.

3.1.7 класс (class): Абстракция, представляющая и инкапсулирующая свойства, взаимосвязи и поведение, которые выделяют набор однородных явлений.

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

3.1.8 классификация (classification): Процесс выстраивания абстракций в структуру, организованную в соответствии с их отличительными свойствами, взаимосвязями и поведением.

3.1.9 компонент (component): Общая сущность, являющаяся или способная стать частью большего целого.

[ИСО 19439:2006]

3.1.10 компонент (component): Сущность системы с дискретной структурой в рамках системы, взаимодействующей с другими компонентами системы, дополняя тем самым систему свойствами и характеристиками.

[ИСО/МЭК 15288:2002]

3.1.11 определение концепции (concept definition): Фаза модели предприятия, определяющая бизнес-концепции домена предприятия, который следует использовать для решения бизнес-задач предприятия и его функционирования, включая необходимый ввод и вывод домена предприятия.

[ИСО 19439:2006]

3.1.12 ограничение (constraint): Препятствие, предельное ограничение или условие, накладываемое на систему, которое возникает внутри или вне рассматриваемой системы.

[ИСО 19439:2006]

3.1.13 язык моделирования на базе конструкции (construct-based modelling language): Набор конструкций и правил, используемых для адекватных группировок, определяющих синтаксис языка моделирования.

3.1.14 метка конструкции (construct label): Строка с литералом, обозначающим тип конструкции, определенная для каждого шаблона конструкции.

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

3.1.16 декларативное правило (declarative rule): Набор задач и ограничений в комбинации с невычислительным набором условий.

Примечание - Декларативные правила могут быть установлены в доменах бизнес-процессов.

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

Примечание - Терминология, используемая для описания аспектов Центра принятия решений, установлена в ИСО 15704:2000/дополнение 1:2005, приложение С, в котором понятие временной горизонт определено как "часть будущего, учтенного при принятии решения, например горизонт составляет шесть месяцев, когда принимают решение о временном интервале в шесть месяцев", а плановый период - как "время с момента принятия решения до момента его пересмотра".

3.1.18 определение прекращения использования (decommission definition): Фаза модели предприятия, определяющая конечное состояние вышедшей из употребления системы, всех ее компонентов для конкретного домена предприятия и процессов, использованных для проведения ликвидации, обеспечивая тем самым повторное применение или реализацию этих компонентов.

[ИСО 19439:2006]

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

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

[ИСО 19439:2006]

3.1.21 домен (domain): Конструкция, представляющая часть моделируемого предприятия, обеспечивающая идентификацию соответствующей информации.

3.1.22 идентификация домена (domain identification): Фаза модели предприятия, идентифицирующая домен предприятия, моделируемый в отношении его бизнес-задач, входов и выходов домена предприятия, включая их соответствующие происхождения и назначения.

[ИСО 19439:2006]

3.1.23 операция в домене (domain operation): Фаза модели предприятия, охватывающая практическое применение модели домена.

[ИСО 19439:2006]

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

[ИСО 19439:2006]

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

3.1.26 домен предприятия (enterprise domain): Часть предприятия, соответствующая определенному набору бизнес-задач и ограничений, при которых должна быть создана модель предприятия.

Примечание - В настоящем стандарте вместо термина "домен предприятия" используется термин "домен" в тех случаях, когда он используется в качестве уточнения таких терминов, как "фаза идентификации домена" и "модель домена". Другие случаи применения термина "домен" соответствуют его словарному значению.

3.1.27 модель предприятия (enterprise model): Абстракция, отображающая объекты предприятия, их взаимосвязи, декомпозицию и детализацию до степени, необходимой для передачи информации о том, что предприятие намерено осуществить и как оно функционирует.

[ИСО 19439:2006]

3.1.28 фаза модели предприятия (enterprise model phase): Фаза жизненного цикла в модели предприятия.

[ИСО 19439:2006]

3.1.29 представление модели предприятия (enterprise model view): Селективное восприятие или отображение модели предприятия, выделяющее некоторые конкретные аспекты и игнорирующее другие.

[ИСО 19439:2006]

3.1.30 объект предприятия (enterprise object): Конструкция, отображающая единицу информации предприятия и описывающая обобщенную, реальную или абстрактную сущность, которую можно осмыслить как целое.

Примечание 1 - Применение термина "объект предприятия" ограничивается ситуациями, когда релевантными являются только информационные аспекты рассматриваемой сущности.

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

[ИСО 19439:2006]

3.1.31 представление объекта предприятия (enterprise object view): Конструкция, отображающая совокупность атрибутов объекта предприятия для некоторой конкретной цели.

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

3.1.32 сущность (entity): Что-либо конкретное или абстрактное в рассматриваемом домене.

[ИСО 19439:2006]

3.1.33 событие (event): Конструкция, отображающая ожидаемый или неожиданный факт, указывающий на изменение состояния предприятия или его окружения.

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

3.1.34 функциональное представление (function view): Представление модели предприятия, которое обеспечивает возможность отображения и модификации процессов предприятия, их функциональных возможностей, поведения, входов и выходов.

[ИСО 19439:2006]

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

Примечание - Характеристика функционального объекта отражает его способность принимать, обрабатывать, хранить и пересылать информацию.

3.1.36 функциональная категория (functional category): Группировка сущностей, обеспечивающих выражение общей цели или возможностей.

3.1.37 функциональная операция (functional operation): Базовая единица работы и нижний уровень неоднородности в представлении функции.

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

3.1.38 обобщение (generalization): Особое понятие, измененное для получения чего-либо более общего, использования или цели, либо действие по изменению деталей или исключения их из особого понятия для получения его обобщения.

Примечание - Понятия обобщение и специализация имеют противоположный смысл.

[ИСО 19439:2006]

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

[ИСО 19439:2006]

3.1.40 описание исполнения (implementation description): Фаза модели предприятия, обеспечивающая описание конечного набора процессов, ресурсов и правил, выполняемых для достижения требуемых эксплуатационных характеристик, необходимых для выполнения Бизнес-процессов и Видов деятельности предприятия, указанных на фазе проектирования схемы.

[ИСО 19439:2006]

3.1.41 компонент информационных технологий (information technology component): Компонент, необходимый для выполнения одной или нескольких операций по сбору, обработке, распространению, хранению или проверке данных для конструкций Деятельность предприятия.

[ИСО 19439:2006]

3.1.42 информационное представление (information view): Представление модели предприятия, обеспечивающее возможность отображения и модификации информации предприятия в соответствии с функциональным представлением.

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

[ИСО 19439:2006]

3.1.43 создание экземпляров (instantiation): Создание экземпляров конструкций языка моделирования или частичных моделей и возможное присвоение значений некоторым или всем атрибутам.

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

[ИСО 19439:2006]

3.1.44 интеграция (integration): Обеспечение взаимодействия между объектами предприятия, необходимое для достижения определенной цели в определенной ограниченной среде.

Примечание - Интеграция является результатом использования этого метода интегрирования*.

________________

* В оригинале ИСО 19440 использован термин "INTEGRATE" (интегрировать) вместо "integration".

3.1.45 правило целостности (integrity rule): Утверждение на фазе определения требований, касающееся ограничений информации для обеспечения соответствия реальной действительности.

Примечание - Правило целостности используют для определения ограничений к атрибутам объектов предприятия.

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

[ИСО 19439:2006]

3.1.47 фаза жизненного цикла (life cycle phase): Этап разработки жизненного цикла объекта.

[ИСО 19439:2006]

3.1.48 компонент технологии производства (manufacturing technology component): Компонент, необходимый для выполнения одной или нескольких операций по управлению, перегруппировке, транспортированию, хранению или проверке сырьевых материалов, деталей, узлов, сборочных узлов и конечных продуктов.

[ИСО 19439:2006]

3.1.49 модель (model): Абстрактное описание реальности в любой форме (включая математическую, физическую, фигуральную, графическую или дескриптивную), отображающее некоторые аспекты этой реальности.

[ИСО 19439:2006]

3.1.50 конструкция языка моделирования (modelling language construct): Текстовая или графическая часть языка моделирования, созданная для упорядоченного представления различной информации об общих свойствах и элементах совокупности объектов предприятия.

[ИСО 19439:2006]

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

[ИСО 19439:2006]

3.1.52 наступление события (occurrence): Единственная фактическая реализация конструкции языка моделирования, представляющая конкретную сущность реального мира в момент обработки модели.

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

3.1.54 заказ (order): Конструкции языка моделирования, являющиеся специализацией конструкции Объект предприятия, представляющей информацию для планирования и контроля бизнес-процессов на предприятии.

Примечание - Заказ может быть отображен объектным представлением, связанным с событием.

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

3.1.56 организационная единица (organizational unit): Конструкция, отображающая объект организационной структуры предприятия, описанный с помощью атрибутов организации и ссылок на организационные сущности как нижнего, так и высшего уровня.

Примечание - Примерами Организационной единицы являются отдел и отделение.

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

[ИСО 19439:2006]

3.1.58 частичный уровень (partial level): Совокупность частичных моделей.

[ИСО 19439:2006]

3.1.59 частичная модель (partial model): Модель, используемая в качестве эталонной в конкретном типе сегмента промышленности или промышленной деятельности.

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

[ИСО 19439:2006]

3.1.60 конкретный уровень (particular level): Уровень, на котором модель описывают для конкретного специфического домена предприятия.

[ИСО 19439:2006]

3.1.61 детализация (particularization): Процесс специализации и конкретизации, с помощью которого конкретные компоненты модели могут быть получены из более общих.

[ИСО 19439:2006]

3.1.62 показатель результатов деятельности (performance indicator): Мера или критерий, с помощью которых оценивают достижение цели.

3.1.63 персональный профиль (person profile): Конструкция, представляющая набор персональных навыков и обязанностей, требуемых Организационной единицей и/или Деятельностью предприятия и обеспечиваемых человеком.

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

3.1.64 обрабатываемая модель (processable model): Модель, имеющая характерный синтаксис и семантику, которая может быть обработана на компьютере (анализ, моделирование или выполнение программы).

3.1.65 продукт (product): Конструкция, являющаяся специализацией конструкции Объект предприятия, которая отображает желаемый выход (результат) или побочный продукт Бизнес-процессов предприятия.

3.1.66 взаимосвязь (relationship): Связь между двумя или более объектами, имеющая важное значение для достижения конкретной цели.

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

[ИСО 19439:2006]

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

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

[ИСО 19439:2006]

3.1.69 ресурсы (resource): Конструкция, являющаяся специализацией конструкции Объект предприятия, представляющая возможности предприятия, обеспечивающие осуществление Деятельности предприятия.

Примечание - Конструкция Ресурсы не включает в себя людские ресурсы.

3.1.70 представление ресурсов (resource view): Представление модели предприятия, обеспечивающее возможность отображения и модификации ресурсов предприятия и персонала.

Примечание 1 - Представление ресурсов имеет структуру, содержащую Объекты предприятия, представляющие набор ресурсов и групп людей, необходимых для выполнения операций.

[ИСО 19439:2006]

3.1.71 специализация (specialization): Общее понятие, измененное для получения чего-то более определенного для конкретного использования или цели, либо акт добавления или изменения деталей общего понятия для получения его специализации.

Примечание 1 - Понятия Специализация и Обобщение имеют противоположный смысл.

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

[ИСО 19439:2006]

3.1.72 система (system): Совокупность объектов реального мира, организованная с определенной целью.

[ИСО 19439:2006]

3.1.73 предметная область (universe of discourse): Совокупность сущностей, которые неизменно были или всегда будут в выбранной части реального мира или гипотетического изучаемого мира, описываемого с помощью моделей.

3.2 Сокращения

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

ATHENA - перспективные технологии, обеспечивающие совместимость гетерогенных сетей предприятий и их применение;

CIM - компьютеризированное производство;

GRAI - графы взаимосвязанных результатов и действий;

IFAC - Международная федерация по автоматическому управлению;

IFIP - Международная федерация по обработке информации;

ODP - открытая распределенная обработка данных;

POP - Процесс - Организация - Продукт;

PSL - язык спецификации процессов;

XML - расширяемый язык разметки.

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

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

Примечание 1 - Конструкции, определенные в настоящем стандарте, приведены в разделе 6. Каждая конструкция представляет собой элемент языка моделирования, синтаксис и семантика которого как можно более точно определены для проверки на соответствие согласно разделу 7.

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

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

Примечание 2 - EXPRESS по [1] , PSL по [9] и сети Петри по [8] являются языками, имеющими одно представление, в то время как Язык предприятия ODP по [4], ATHENA POP по [10] и настоящий стандарт охватывают многопроекционную систему моделирования предприятия. Сети Петри используют в качестве объекта общее моделирование дискретных систем событий, включая системы производства. PSL является нейтральным языком для определения информации о процессе производства. EXPRESS - это абстрактный язык (с синтаксисом и семантикой) для моделирования совокупности объектов и их атрибутов данных. Сети Петри, PSL и EXPRESS являются формальными языками, исполняемыми на компьютере, в то время как Язык предприятия ODP и конструкции настоящего стандарта таковыми не являются. ODP по [4], POP по [10] и настоящий стандарт не имеют одинаковых представлений (в настоящем стандарте - представлений модели) и охвата. В POP и настоящем стандарте применяется подход более акцентированного процессно-ориентированного моделирования, нацеленный на мониторинг операционного процесса и использование модели управления. В противоположность этому, ODP имеет больший охват с пятью представлениями (Предприятие, Информация, Вычисление, Инжиниринг и Технология). Представление Предприятие в ODP больше всего подходит для целей настоящего стандарта, поэтому основное внимание уделяется таким концепциям на уровне предприятия, как цель, область применения и стратегия системы.

Моделирование предприятия поддерживается конструкциями языка моделирования на всех фазах модели предприятия следующим образом:

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

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

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

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

- на фазе описания исполнения - описание Бизнес-процессов, включая все их компоненты, представляют так, как они выполняются в реальной системе (с точки зрения как бизнеса, так и ИКТ) таким образом, чтобы показать, что модели описания достаточно для использования в работе предприятия для поддержки принятия решений, мониторинга и контроля Бизнес-процессов. Модель исполнения должна также допускать обработку. На этом этапе конструкции должны представлять собой аппаратурную/программную платформу или выбранную технологию при условии совместимости с конструкциями спецификации схемы;

- на фазе операций в домене - путем использования разрешенной модели для операционных целей, таких как поддержка принятия решений, мониторинг и контроль;

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

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

Примечание 3 - Примеры применения языка моделирования на основе ODP и работы ATHENA по POP приведены в приложении D.

5 Отображения, взаимосвязи, роли и дополнительные концепции

5.1 Диапазон отображения

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

________________

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

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

Отображение осуществляют следующими четырьмя способами:

- отображение с помощью общей структуры конструкций, описанных в 5.2;

- отображение взаимосвязей между вышеуказанными конструкциями языка моделирования (см. приложение С);

________________

В приложении С приведена поясняющая метамодель UML (унифицированного языка моделирования).

- отображение с помощью шаблонов с целью включения атрибутов в общий формат (см. раздел 6);

- отображение динамического поведения по поведенческим правилам (см. 6.3.5 и приложение А).

5.2 Общая структура и шаблон для конструкций языка моделирования

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

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

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

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

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

1) метка конструкции (текстовая строка, обозначающая тип конструкции);

2) идентификатор (текстовая строка, уникальная для каждого случая конструкции языка моделирования в пределах модели);

3) имя (наименование экземпляра конструкции языка моделирования);

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

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

b) Часть "Содержание" с конкретными атрибутами, являющимися специальными для каждой конструкции и описание которых следует из определения конкретной конструкции языка моделирования. Затем раздел "Содержание" преобразуют в два новых раздела следующим образом:

1) дескриптивы, содержащие описательные атрибуты и охватывающие:

- описание с идентификацией конструкции в текстовой форме,

- предопределенные атрибуты конструкции,

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

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

2) взаимосвязи (см. 5.4), содержащие атрибуты взаимосвязей и включающие в себя:

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

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

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

- взаимосвязи "Состоит из", отображающие взаимосвязи между этим экземпляром конструкции и его составляющими, и

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

________________

Считают, что "Часть чего-либо" (Part_of) и "Состоит из" (Consists_of) являются дополнительными взаимосвязями, которые в зависимости от целей разработчика могут использоваться как самостоятельно, так и совместно.

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

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

________________

Контроль версии существенным образом влияет на конструкцию и работу моделей.

Примечание 1 - В моделях, приведенных в приложении С, взаимосвязи "Часть_(чего-либо)" и "Состоит_из" показаны однозначно, а не как агрегации UML. Ассоциации UML используют с целью показать Операционные и Ассоциативные взаимосвязи, а обобщения UML применяют для того, чтобы показать взаимосвязи "Специализация_(чего-либо)".

Примечание 2 - Обеспечение совместимости взаимосвязей "Часть_(чего-либо)" и "Состоит_из" при их одновременном использовании и дескриптивов Ограничения и Целостность обуславливается разработкой программного обеспечения для средств технической поддержки.

5.3 Отображение атрибутов

Каждый атрибут определяется именем и предопределенным типом данных (номерами, литералами, строками и т.д.).

Примечание 1 - Типу данных может соответствовать диапазон допустимых или фактических значений, таких как единичный идентификатор (id=4711), диапазон значений [диаметр (10±0,05) мм] или список значений (желтый, красный или зеленый цвет).

Примечание 2 - В качестве средства отображения атрибутов и связанных с ними определений типов данных, выражений и заявлений в конструкциях могут быть использованы схемы XML по [13], [14], [15] или EXPRESS по [1].

5.4 Отображение взаимосвязей

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

Пример 1 - Взаимосвязями между сущностями могут быть взаимосвязи между деталью и станком, который применяется для ее изготовления, или между рабочим и заказом, выполнение которого ему поручено, например "Изготовлено с помощью" (Produced_by) (деталь, машина), "Работает_в" (Works_at) (рабочий, заказ). Такие взаимосвязи отображают с помощью заданий в виде входов и выходов Видов деятельности предприятия.

Пример 2 - Примерами взаимосвязей между конструкциями являются взаимосвязи между Доменом и его Бизнес-процессами или между Бизнес-процессом и его подпроцессами и видами деятельности.

Концепция взаимосвязи, определенной пользователем, зависит от концепции Объекта Предприятие, приведенной в 6.6, и от сущностей модели, полученных из Объекта предприятия. Определенную пользователем взаимосвязь используют для описания взаимосвязей, зависящих от домена, в том виде, в котором ее воспринимают и определяют пользователи, и, следовательно, для описания того, как данные взаимосвязи группируют структурные поведенческие конструкции с точки зрения их использования на предприятии. Определяемые пользователем взаимосвязи могут быть представлены списками "Связанные с" (Related_to) для Объектов предприятия, Продуктов, Заказов и Представлений Объекта в экземплярах Объекта предприятия или дополнительными атрибутами.

5.5 Специализации

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

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

- добавления нового атрибута взаимосвязи "Специализация чего-либо" (Specialization_of) на соответствующей фазе(ах) модели,

- установления соответствующих значений для атрибута "Специализация (чего-либо)" (Specialization_of) и внесения этих значений в перечень конструкции, специализацией которой он является,

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

- добавления дополнительных атрибутов и присвоения им имен, уникальных для моделей.

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

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

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

5.6 Роли

В Оксфордском словаре английского языка по [16] приведено определение роли как "типичной или характерной функции, выполняемой кем-либо или чем-либо". Одна и та же сущность может играть разные роли в разных контекстах (которые могут совпадать во времени и по месту) и в разные моменты в пределах ее жизненного цикла. Такое разнообразие роли особенно справедливо для следующих примеров сущностей:

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

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

- для ИТ ресурсов компьютерное приложение может быть в свою очередь клиентом другого приложения и серверной частью отдельного приложения.

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

a) роль людей при поддержке Организационной единицы представляется в Личностном профиле и Организационной роли, последняя из которых фиксирует различные требуемые обязанности и способности (навыки) и позволяет согласовывать их с теми, которые предусмотрены в Личностном профиле и которые требуются для выполнения задач (функциональных операций), поставленных перед человеком;

b) роль людей при поддержке Деятельности предприятия представляется в Операционной роли и Личностном профиле, в первой из которых фиксируются требуемые операционные способности (навыки) и обеспечивается согласование этих способностей с теми, которые обеспечиваются Личностным профилем;

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

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

5.7 Дополнительные концепции

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

- поведенческое правило (см. 6.3.5);

- ограничение;

- декларативное правило;

- функциональная операция (см. 6.4.5);

- правило целостности;

- задача и

- показатель результативности.

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

6 Конструкции языка моделирования

6.1 Краткий обзор конструкций

6.1.1 Конструкции языка моделирования и области их применения

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

- связанные с функцией и процессом: Домен, Бизнес-процесс, Деятельность предприятия, Событие;

- связанные с информацией: Объект предприятия, Представление объекта предприятия, Заказ, Продукт;

- связанные с ресурсами: Возможности, Операционная роль, Ресурсы, Функциональная сущность и

- связанные с организацией: Персональный профиль, Организационная роль, Организационная единица и Центр принятия решений.

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

Примечание 2 - Примеры применения конструкций на основе концепций моделирования на языке UML приведены в приложении С, отношения к метамодели моделирования концепций по ИСО/МЭК 15414 и разработанным в Европейском проекте ATHENA приведены в приложении Д.

6.1.2 Цель и применимость

Настоящий пункт распространяется на определение, описание и создание шаблонов, предназначенных для базовых конструкций языка моделирования, формирующих язык моделирования, с помощью которого может быть создан широкий спектр моделей предприятия на базе Бизнес-процессов. Каждый шаблон включает в себя атрибуты, установленные в настоящем стандарте. Для удовлетворения конкретных потребностей пользователя с помощью соответствующих расширений для шаблона допускается также применять и другие атрибуты (см. 5.2 и 5.5). В разделе Е.4 приложения Е приведен пример обработки заказа и продемонстрирован способ использования шаблонов при разработке модели предприятия.

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

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

- начать с Домена (диапазон и граница модели);

- добавить функциональные возможности с точки зрения Бизнес-процессов, Видов деятельности предприятия и Событий;

- добавить отображение информации с точки зрения Объекта предприятия и Объектного представления и специализации Продукта и Заказа;

- предусмотреть обеспечение Ресурсами, Возможностями и наличие Функциональной сущности;

- рассмотреть организационные и ролевые вопросы, связанные с Организационной единицей, Центром принятия решений, Персональным профилем, Операционной ролью и Организационной ролью.

6.1.3 Нотация, применяемая для описания содержания шаблона

Атрибуты описывают в комбинации с обозначениями и текстовыми описаниями.

Нотация, используемая для целей данного раздела, заключается в том, что обозначения заключают в угловые скобки <and> и они либо не требуют объяснений (например, <integer>), либо разъяснения приводят в сопроводительном тексте (например, <item>, где элемент является ...). Литералы верхнего регистра обозначают как DM, ВР, EV, NIL, PHYSICAL (физический) и т.д. Литеральные символы :, /, (and) обозначают ":", "/", "("and")" соответственно. Если для обозначения может быть использовано более одного выбора, каждая комбинация должна быть отделена от другой символом | (читать как или), например <а> | <b> | <с>. Квадратные скобки [ and ] используют в качестве контейнера для группировки одного или более элементов, как в [<duration> <qual>] для атрибута DURATION (продолжительность) Деятельности предприятия.

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

Непустой список для <item> с соответствующим разделителем записывают комбинацией [<item>]+, в то время как аналогичный, возможно, пустой список записывают комбинацией [<item>]. В пределах обозначения списка <item> он может быть далее разложен в виде [<id> <multiplicity>]+ или [<measure> | <metric>]

Примечание - Более формальный синтаксис для списков должен иметь следующий вид:

- список = непустой список | возможно пустой список;

- непустой список = элемент данных | элемент данных, разделитель, непустой список; (* для удобства используют сокращенный вариант (или сокращенную запись) [<item>]+ *);

- разделитель = ";"; (* вместо точки с запятой можно использовать любой эквивалентный знак разделения записей *);

- возможно пустой список = NIL (нуль) | непустой список; (* для удобства применяют сокращенную запись [<item>] *).

________________

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

Пример - Для шаблона Домена Уполномоченный проектировщик со значениями Организационной роли и возможно также Организационной единицы допускается использовать выражение [[<identifier> "/" <name>][NIL\":"<identifier> "/"<nате>]].

Для шаблона Возможности запись data_store; id_1006453 является правильной для нотации "[<id>]+, где <id> является одной из записей <identifier> | <nате> экземпляров Возможностей" (NIL в этом случае не используют).

Для шаблона Деятельность предприятия запись NIL или max_load (макс_нагрузка) = 10 кг; max_temp(макс_темп)=100С является правильной для записи ограничения "[<constraint>], накладываемого на экземпляр Деятельности предприятия".

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

ЕО: Характер Объекта ФИЗИЧЕСКИЙ | ИНФОРМАЦИОННЫЙ

СА: Возможности и атрибуты возможности

СА: Включенные Возможности [<Capability instance>]

СА: Относящиеся к функции [<capability attribute>]

СА: Относящиеся к Сущности [capability attribute>]

6.2 Домен

6.2.1 Цель

Домен отображает границы и содержание предприятия или части предприятия, для которой должна быть разработана модель.

6.2.2 Описание

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

6.2.3 Применение

Конструкцию Домен используют на всех фазах моделирования. Шаблон данной конструкции позволяет:

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

b) представлять его в форме, понятной как для людей, так и для компьютера.

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

6.2.4 Шаблон конструкции Домена

________________

Установленные цели определены в Бизнес-процессах, Видах деятельности предприятия, а также в Центрах принятия решений; при этом должна быть гарантирована согласованность (последовательность).

Здесь и в следующих шаблонах <origin> обозначает Домен, Бизнес-процесс или Деятельность Предприятия, то есть источник входного параметра. В случае, когда <origin> является внешним Доменом, указывают только имя домена, а его содержание не определяют.

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

Здесь и в следующих шаблонах <destination> обозначает Домен, Бизнес-процесс или Деятельность Предприятия, означающие получение выходных данных.

Обеспечение совместимости указанных Бизнес-процессов с атрибутом Бизнес-процесса "Where_used" обуславливается разработкой модели с помощью средств технической поддержки и сопровождением.

6.3 Бизнес-процесс

6.3.1 Цель

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

6.3.2 Описание

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

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

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

________________

В отличие от Деятельности предприятия шаблон для Бизнес-процесса не имеет статуса окончания. О завершении процесса сигнализирует действие FINISH поведенческого правила и возможное исключение.

6.3.3 Применение

Конструкцию Бизнес-процесс используют на всех фазах моделирования. Шаблон данной конструкции позволяет:

a) фиксировать всю связанную с процессом информацию, основанную на модели планирования и поддержки принятия решения и мониторинга и управления операционными процессами, а также

b) представлять ее в форме, понятной как для людей, так и для компьютера.

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

6.3.4 Шаблон конструкции для Бизнес-процесса

________________

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

Обеспечение совместимости Событий, указанных в перечне как Входы и Выходы, с атрибутами События "Generated_by" обуславливается разработкой модели с помощью средств технической поддержки и сопровождения.

6.3.5 Поведенческие правила

6.3.5.1 Цель

Цель поведенческих правил заключается в том, чтобы

a) обозначить начало основного Бизнес-процесса и

b) описать взаимосвязи в логическом упорядочении составляющих Бизнес-процессов и/или Видов Деятельности предприятия.

6.3.5.2 Описание

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

Примечание - Настоящий стандарт не распространяется на подробное описание внутренней Деятельности предприятия (упорядочение набора функциональных операций), которая относится к вопросу внедрения.

Логическое упорядочение может быть более или менее детерминированным и соответствовать:

- хорошо структурированным процессам, т.е. процессам, для которых ожидаемый результат известен и последовательность составляющих Бизнес-процессов и/или Деятельностей предприятия полностью определена (и при необходимости детерминирована);

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

- плохо структурированным процессам, т.е. процессам, для которых ни результат, ни последовательность составляющих Бизнес-процессов и/или Деятельностей предприятия полностью не известны (не детерминированы).

6.3.5.3 Применение

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

a) фиксирования всех условий, которые контролируют упорядочение и динамическое поведение Бизнес-процессов, и

b) отображения данных условий в форме, понятной как для людей, так и для компьютера.

6.4 Деятельность предприятия

6.4.1 Цель

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

6.4.2 Описание

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

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

6.4.3 Применение

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

a) реализации установленных функциональных возможностей и

b) планировании на базе модели и поддержке на базе модели решения, мониторинга и управления операционными процессами.

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

Требуемые возможности Деятельности предприятия должны соответствовать Возможностям Ресурсов, которые должны быть представлены.

6.4.4 Шаблон конструкции для Деятельности предприятия

________________

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

Способ, которым функциональные операции, требуемые Деятельностью предприятия, согласуются с Функциональными сущностями, которые могут их выполнять, является вопросом внедрения, не входящим в область применения настоящего стандарта.

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

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

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

6.4.5 Функциональная операция

6.4.5.1 Цель

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

6.4.5.2 Описание

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

6.4.5.3 Применение

Концепцию функциональной операции используют на фазе спецификации схемы и следующих фазах.

Примечание 1 - Поток управления подзадачами, называемый поведением деятельности, может быть определен в алгоритме, который описывает входные/выходные условия для последовательного управления Функциональными сущностями, связанными с осуществлением Деятельности предприятия. Настоящий стандарт не устанавливает требований к данному алгоритму.

________________

В отличие от Бизнес-процессов, поведение которых устанавливается поведенческими правилами согласно 6.3.3.

Примечание 2 - Настоящий стандарт не устанавливает требований к языку и форме алгоритма потока управления.

6.5 Событие

6.5.1 Цель

Целью конструкции Событие является фиксирование причины, происхождения и назначения события.

6.5.2 Описание

Событие представляет начало изменения состояния на предприятии или его окружения, используемого для инициации выполнения одного или более процессов, активирует Бизнес-процессы и/или Деятельности предприятия путем обработки набора поведенческих правил, ассоциированных с Бизнес-процессом (см. также 6.3.5).

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

6.5.3 Применение

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

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

Пример - Событие: поступление заказа клиента (информация о заказе).

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

6.5.4 Шаблон конструкции для События

________________

В отношении Бизнес-процессов Приоритет используют во время запуска с целью выбора, какой Бизнес-процесс или Деятельность предприятия инициировать в первую очередь, когда происходят почти одновременные События.

Совместимость атрибутов Генерировано посредством Домена для События Происхождение/Назначение и Вход/Выход для Бизнес-процессов и Деятельности предприятия должно быть обеспечено в процессе разработки модели с помощью средств технической поддержки и сопровождения.

6.6 Объект предприятия

6.6.1 Цель

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

6.6.2 Описание

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

6.6.3 Применение

Конструкцию Объект предприятия используют на всех фазах моделирования. Шаблон данной конструкции позволяет:

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

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

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

6.6.4 Шаблон конструкции для Объекта предприятия

_________________

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

Данный Объект предприятия наследует все дескриптивы и взаимосвязи обобщения(ий).

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

6.7 Представление объекта предприятия (объектное представление)

6.7.1 Цель

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

6.7.2 Описание

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

________________

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

6.7.3 Применение

Конструкцию Представление объекта используют на всех фазах моделирования. Шаблон данной конструкции позволяет:

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

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

Примечание - Вместо термина "Представление объекта предприятия" обычно используют "Представление объекта" или "Объектное представление" (при работе с автоматизированными средствами моделирования).

6.7.4 Шаблон конструкции Представление объекта

6.8 Продукт

6.8.1 Цель

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

6.8.2 Описание

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

С помощью конкретизации и специализации атрибутов определяют подклассы Продукта для выполнения специфических требований определенной отрасли промышленности или конкретного предприятия. Сложные структуры продукта представляют взаимосвязями "Часть чего-либо" (Part-of) между четко различимыми подклассами Продукта.

6.8.3 Применение

Конструкцию Продукт используют на всех фазах моделирования. Шаблон данной конструкции позволяет:

a) фиксировать всю относящуюся к продукту информацию, существенную для стратегического планирования и поддержки решения, мониторинга и управления операционными процессами, и

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

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

6.8.4 Шаблон конструкции Продукт

________________

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

6.9 Заказ

6.9.1 Цель

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

6.9.2 Описание

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

6.9.3 Применение

Конструкцию Заказ используют на всех фазах моделирования. Шаблон данной конструкции позволяет:

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

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

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

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

Примечание - Ассоциация Заказа с Событием отображается Представлением объекта согласно Е.4.2.1 и Е.4.2.5 приложения Е.

6.9.4 Шаблон конструкции Заказ

________________

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

6.10 Ресурсы

6.10.1 Цель

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

6.10.2 Описание

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

- предусмотренные операционные роли и

- предусмотренные возможности.

________________

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

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

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

6.10.3 Применение

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

a) фиксировать всю относящуюся к ресурсам информацию, существенную для планирования и поддержки решения, мониторинга и управления операционными процессами, и

b) представлять в форме, понятной как для людей, так и для компьютера.

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

6.10.4 Шаблон конструкции Ресурсы

________________

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

6.11 Способность

6.11.1 Цель

Способность представляет элементы как способностей, требуемых Деятельностью предприятия (см. 6.4), так и предусмотренных Ресурсами (см. 6.10).

6.11.2 Описание

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

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

Пример - Максимальные/минимальные размеры детали, которые можно обрабатывать, степень точности или повторяемость и т.д.

6.11.3 Применение

Конструкцию Способность используют на фазе определения требований и следующих фазах. Шаблон данной конструкции позволяет:

a) фиксировать всю относящуюся к Деятельности предприятия и Ресурсам информацию, существенную для планирования и поддержки решения, мониторинга и управления операционными процессами, и

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

Способность, необходимая для Деятельности предприятия, фиксируется с помощью предусмотренной Способности ресурсов.

6.11.4 Шаблон конструкции Способность

6.12 Функциональная сущность

6.12.1 Цель

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

6.12.2 Описание

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

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

6.12.3 Применение

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

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

b) представлять в форме, понятной как для людей, так и для компьютера.

6.12.4 Шаблон для конструкции Функциональная сущность

6.13 Организационная единица

6.13.1 Цель

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

6.13.2 Описание

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

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

6.13.3 Применение

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

Примечание 1 - Организационные области, представляемые Организационной единицей, могут иметь разные размеры (например, целое предприятие, отдел, отделение или бригада).

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

6.13.4 Шаблон конструкции Организационная единица

________________

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

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

6.14 Центр принятия решений

6.14.1 Цель

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

6.14.2 Описание

Центры принятия решений представляют структуру решений предприятия. Структуру решений определяют тогда, когда известен набор центров принятия решений и определены их взаимосвязи.

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

Примечание - Подробный контекст (содержание) Центра принятия решений приведен в ИСО 15704:2000 / дополнение 1:2005, приложение С.

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

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

6.14.3 Применение

Конструкцию Центр принятия решений используют на фазе определения концепции и следующих фазах. Шаблон данной конструкции позволяет:

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

b) представлять вышеуказанную конструкцию в форме, понятной как для людей, так и для компьютера.

6.14.4 Шаблон конструкции Центр принятия решений

6.15 Личностный профиль

6.15.1 Цель

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

6.15.2 Описание

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

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

6.15.3 Применение

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

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

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

6.15.4 Шаблон конструкции Личностный профиль

_________________

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

6.16 Организационная роль

6.16.1 Цель

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

6.16.2 Описание

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

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

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

6.16.3 Применение

Конструкцию Организационная роль используют на фазе определения требований и следующих фазах. Шаблон данной конструкции позволяет:

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

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

Шаблон идентифицирует все Организационные единицы, для которых требуется Организационная роль.

6.16.4 Шаблон конструкции Организационная роль

6.17 Операционная роль

6.17.1 Цель

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

6.17.2 Описание

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

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

6.17.3 Применение

Конструкцию Операционная роль используют на этапе определения требований и следующих фазах. Шаблон данной конструкции позволяет:

a) фиксировать всю относящуюся к операционной задаче информацию, существенную для выполнения операционных процессов, и

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

Шаблон устанавливает все Действия предприятия, для которых требуется эта Операционная роль.

6.17.4 Шаблон конструкции Операционная роль

7 Принципы соответствия

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

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

Модель соответствует требованиям настоящего стандарта, если она является:

a) действующей конструкцией языка моделирования, который соответствует требованиям настоящего стандарта, или

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

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

Приложение А
(обязательное)

Поведенческие правила. Подробное описание и синтаксис

А.1 Текстовое описание

А.1.1 Краткий обзор

В настоящем приложении приведены примеры поведенческих правил, указанных в 6.3.5. Формальный синтаксис, используемый для поведенческих правил, приведен в А.2. Слова и словосочетания, выделенные курсивом, являются обозначениями, объяснения которых приведены в тексте. Служебные слова выделены прописными буквами.

________________

Служебными ключевыми словами в этом приложении являются AND, ANY, ASYNCHRONOUS, DO, ES, EXCEPTION, FINISH, FROM, GENERATE, OR, REPEAT, RUN-TIME CHOICE, SELECT, START, SYNCHRONOUS, TIMES, UNTIL, UNORDERED, WHEN и XOR. Они могут быть заменены любыми эквивалентными терминами при условии, что они будут понятны читающему документ человеку.

Поведенческие правила определяют в общем виде следующим образом: WHEN condition DO action, где:

a) знак ";" обозначает окончание поведенческого правила;

b) condition (условие) представляет собой одно или более из следующих условий:

1) осуществление одного или более назначенных событий согласно А.1.2.1, которые включают в себя нормальные события, отображенные экземплярами События, события START для Бизнес-процессов и исключения;

2) окончание одного или более Бизнес-процессов или одного или более Видов деятельности предприятия (каждый из которых должен иметь конечный статус или определенной их комбинации, которая была предварительно инициирована как следствие действия поведенческих правил Бизнес-процесса, содержащего эти правила (см. А.1.2.2);

3) многокомпонентное условие, состоящее:

i) из двух или более условий, разделенных служебным словом AND (и); в этом случае многокомпонентное условие определяют как наступившее, если выполняются все условия, либо

ii) из двух или более условий, разделенных служебным словом OR (или); в этом случае многокомпонентное условие определяют как наступившее, если выполняется любое из условий.

________________

Бизнес-процесс не имеет конечного статуса.

В случае, когда в одном многокомпонентном условии используются оба разделителя AND и OR, при группировании условий используют круглые скобки "("и")" или эквивалентные группирующие символы для устранения многозначности.

Пример - Условие START AND (EV1 OR EV2) наступает, если происходит START и либо наступает событие EV1, либо EV2, в то время как условие (START AND EV1) OR EV2 наступает, если наступают START и EV1 или наступает EV2;

c) action (действие) - представляет собой одно или более из следующих альтернатив:

1) инициировать один или более Бизнес-процессов и/или Видов деятельности предприятия (см. А.1.3.1) ;

2) завершить Бизнес-процесс с или без инициирования особой ситуации (см. А.1.3.2);

3) генерировать Событие (см. А.1.3.3);

4) повторить конкретное действие (цикл) (см. А.1.3.4);

5) multi-part action (многокомпонентное действие), описание которого приведено далее.

________________

Синтаксис не препятствует описанию бесконечных циклов как в Бизнес-процессе ВР-А, который включает в себя поведенческое правило WHEN START DO ВР-А или WHEN START DO ВР-В, в то время как ВР-В (или другой Бизнес-процесс, вызванный прямо или косвенно с помощью ВР-В) также содержит правило WHEN START DO ВР-А. Реализации могут устанавливать ограничения, например такие, при которых ни один Бизнес-процесс не может инициировать себя или Бизнес-процесс, который инициирует этот же Бизнес-процесс прямо или косвенно. Настоящий стандарт не распространяется на данные ограничения.

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

Многокомпонентное действие представлено в виде перечня действий, разделенных запятыми, которому, при необходимости инициации более одного Бизнес-процесса или Деятельности предприятия, предшествует служебное слово (указывающее либо на наличие модальности "и" [см. А.1.3.1, перечисление b)], либо на наличие модальности "или" [см. А.1.3.1, перечисление с)]), обозначающее ограничения их параллельного инициирования (см. А.1.3.1). Запятые могут быть заменены семантически эквивалентными служебными словами AND (для модальности "и") или XOR (для модальности "или").

В настоящем приложении Бизнес-процессы (ВР) и Виды деятельности предприятия (ЕА) имеют общее обозначение ВРЕА с экземплярами ВРЕА1, ВРЕА2 и т.д.

Примечание 1 - Поскольку Поведенческие правила встроены в Бизнес-процесс как атрибут набора поведенческих правил, они не имеют ассоциативного идентификатора.

Примечание 2 - Два типа условий и четыре типа действий вместе с уточняющими "и" и "или" могут быть использованы в определенных комбинациях для представления различных схем упорядочивающих взаимосвязей между Бизнес-процессами или Видами деятельности предприятия, либо их комбинаций (синхронный/асинхронный, коэффициент разветвления по выходу/коэффициент объединения по входу и т.д.). Примеры схем и комбинаций и соответствующие условия и действия для них приведены в таблице А.1. Допускается использовать другие типы схем и комбинаций, условий или действий.

Таблица А.1 - Примеры схем поведенческих правил с соответствующими условиями и действиями

А.1.2 Условия

А.1.2.1 Event (событие)

Event condition (условие события) представляет собой один из двух типов условий, используемых в поведенческих правилах. Появление обозначенного экземпляра события отображается именем события или идентификатором. Условиями события являются следующие:

a) normal events: нормальные события, генерируемые во время нормальной операции Бизнес-процесса или Деятельности предприятия и отображаемые конструкцией Событие;

b) start: начало (пуск), инициация Бизнес-процесса, обозначаемая служебным словом START. Данное условие используют, например, для запуска и подготовительных действий в рамках каждого Бизнес-процесса. Если набор поведенческих правил содержит более одного поведенческого правила, то сначала оценивают правила, содержащие условие START, в порядке их определения, а затем все другие правила в порядке их определения.

Примечание - START может быть сгруппировано с одним или более нормальными событиями в поведенческом правиле. В этом случае поведенческое правило не будет иметь эффекта (подготовительные действия не произойдут), если только не произойдет событие START и все намеченные события;

c) exceptions: особые ситуации, сгенерированные в результате прекращения (аномального завершения) ранее инициированного Бизнес-процесса или Деятельности предприятия либо с помощью специального внешнего механизма, например контрольного таймера, имеющего обозначение в соответствии с именем особой ситуации, которые бывают следующих видов:

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

Примечание - Служебное слово EXCEPTION является необязательным;

2) значение по умолчанию (default), если генерируется особая ситуация любого типа, которая не была обозначена иным способом и представлена с помощью EXCEPTION ANY.

А.1.2.2 Action completion (завершение действия)

Action completion является одним из двух видов условий, используемых в поведенческих правилах. Его появление означает завершение одного или более назначенных Бизнес-процессов и/или Видов деятельности предприятия (каждый из последних имеет соответствующий конечный статус). В тех случаях, когда Бизнес-процесс или Деятельность предприятия были инициированы несколько раз с помощью действия "цикл" согласно А.1.3.4, только последнее завершение следует считать завершением действия. Завершение действия имеет четыре формы:

a) on-status condition (условие "в состоянии"): инициирование действия, зависящего от сравнения конечного статуса Деятельности предприятия с указанным значением и представляемого с помощью одного из следующих вариантов:

ES(EAx) = status value (значение состояния)

ES(EAx) < status value

ES(EAx) > status value

ES(EAx) <> status value

где EAx - указанная Деятельность предприятия, ES(EAx) - конечный статус ЕАх; status value (значение состояния) - любая постоянная или выражение, которое можно оценить и проверить на такие условия, как равно, меньше чем, больше чем или не равно конечному статусу.

b) on-completion condition (условие "по завершении"): инициируемое действие после того, как завершен Бизнес-процесс или Деятельность предприятия (для последнего случая - независимо от предусмотренного конечного статуса отсутствует сравнение on-status, которое имеет истинное значение), представленное в виде:

FINISH(BPx) or ES(EAx)=ANY

c) AND-completion condition: условие "И, конъюнкция - завершение" - все Бизнес-процессы и/или Виды деятельности предприятия из списка завершены и представлены в виде:

completion condition ВРЕА1 AND completion condition BPEA2... AND completion condition BPEAn,

где каждая запись completion condition BPEAi является либо условием "on-status" либо условием "on-completion" согласно перечислениям а) и b).

d) OR-completion condition: условие "ИЛИ, дизъюнкция - завершение" - по крайней мере один Бизнес- процесс и/или Вид деятельности предприятия из списка завершен и представлен в виде:

completion condition ВРЕА1 OR completion condition BPEA2... OR completion condition BPEAn,

где каждая запись completion condition BPEAi является либо условием "on-status", либо условием "on-completion" согласно перечислениям а) и b).

А.1.3 Действия

А.1.3.1 Initiate action (действие "инициировать")

Действие "инициировать" означает, что один или более Бизнес-процессов и/или Видов деятельности предприятия должны быть инициированы при возникновении условия в соответствии с А.1.2. Действие "инициировать" моделирует тот факт, что Бизнес-процесс или Деятельность предприятия могут быть инициированы только по завершении предшествующего действия (см. А.1.2.2) или при возникновении события "начало" (start event) (см. А.1.2.1, перечисление b) для Бизнес-процессов), или при возникновении нормального события (см. А.1.2.1, перечисление а)), или особой ситуации (см. А.1.2.1, перечисление с)).

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

Действие "инициировать" (Initiate action) имеет три формы:

a) single action (одиночное действие): одиночный указанный Бизнес-процесс (или Деятельность предприятия) инициирован и представлен своим именем как в поведенческом правиле

WHEN START DO prepare_Workstation;

b) AND-branching (AND-ветвление) - разрешение на активацию Бизнес-процесса и/или Вида деятельности одного составного последователя (преемника) одним предшественником или более. Очередность активации преемника определяется записью с использованием "и", которая может быть синхронной (все начинается в то же самое время), асинхронной (активируется параллельно, но, возможно, происходит в разные моменты времени) или неупорядоченной (очередность активации неизвестна и будет определена во время выполнения и, возможно, подвергаться временным ограничениям). Действие для AND process-branching (AND процесс-ветвление) представляют в виде:

and modality ВРЕА1, ВРЕА2,..., BPEAn,

где and modality (модальность "и") - одно из следующих:

SYNCHRONOUS (синхронный) или

ASYNCHRONOUS (асинхронный), или

UNORDERED (неупорядоченный).

Запятые в перечне ВРЕА могут быть заменены служебным словом AND.

c) XOR-branching (XOR-ветвление): позволяет одному или более предшественникам осуществлять активацию Бизнес-процесса или Вида деятельности одного преемника (последователя). Выбор активации преемника определяется записью exclusive or modality (эксклюзив или модальность), что может осуществляться ситуационно (индексировано или определено по значению времени выполнения для некоторых переменных) или может быть выбрано во время выполнения (определяться по решению, принятому во время выполнения). Действие XOR-процесс-ветвление (XOR-process-branching) представляют в виде:

эксклюзив или модальность ВРЕМ, ВРЕА2,..., ВРЕАn,

где эксклюзив или модальность:

SELECT jth item FROM (используют для выбора BPEAi с помощью значения времени выполнения для j) или

RUN-TIME CHOICE (используют для выбора решения о времени выполнения).

Запятые в перечне ВРЕА могут быть заменены служебным словом XOR.

А.1.3.2 Complete action (действие "завершить")

Действие "завершить" запускается с помощью любого условия в соответствии с А.1.2 и завершает Бизнес-процесс. Данное действие имеет следующие формы:

a) нормальное завершение (normal completion): Бизнес-процесс завершается как обычно, что отображается ключевым словом FINISH (конец);

b) особое прекращение (exception termination): Бизнес-процесс генерирует особую ситуацию (обычно в результате назначенного условия или условия особой ситуации по умолчанию), после чего прекращается. Это отображается следующим образом:

GENERATE exception name (имя особой ситуации) AND FINISH.

А.1.3.3 Generate event action (действие "генерировать событие")

Действие "генерировать событие" позволяет Бизнес-процессу генерировать экземпляр События, что представляют следующим образом:

GENERATE event name.

А.1.3.4 Loop action (действие "цикл")

Действие "цикл" означает повторяющуюся инициацию какого-либо действия. Действие "цикл" имеет две формы:

а) повторить условно (repeat conditionally) - проверяемое условие оценивают после каждого повторения действия. Если условие истинное, действие повторяют, затем условие проверяют снова. Условное выполнение цикла может быть представлено следующим образом:

REPEAT action UNTIL test condition,

где действие является либо действием "инициировать" (единичным действием, AND-ветвлением или XOR-ветвлением), либо действием последующего цикла, а проверяемое условие (test condition) представляет собой завершение действия согласно А.1.2.2.

Примечание - Выражение REPEAT ЕАх UNTIL ES (ЕАх)=ANY семантически эквивалентно "ЕАх";

b) повторить итеративно (repeat iteratively) - данный цикл обеспечивает фиксированное число повторений данного действия и представляется посредством

REPEAT action loop count TIMES,

где действие является либо действием "инициировать" (единичным действием, AND-ветвлением или XOR-ветвлением), либо действием последующего цикла, а счетчик цикла (loop count) является выражением, которое проводит оценку до положительного целого, которое определяет число повторений, или, если такую оценку не проводят, действие не инициируется.

А.2 Формальный синтаксис в eBNF

В следующем синтаксисе используется нотация eBNF согласно ИСО/МЭК 14977. Обычный символ, представляющий каждый оператор из Extended BNF и его подразумеваемый приоритет (высший приоритет на верху), имеет следующий вид:

Примечание - Знак пробела, заключенный в кавычки, означает, что требуется литеральный пробел, в противном случае пробелы и концы строк (так называемое "белое место") не имеют значения. Мета-идентификатор может быть расположен в правиле как слева, так и справа, позволяя тем самым выполнять рекурсию.

Пример - list = item \ item AND list;

(* использует рекурсию для генерации непустой последовательности элемента item, item AND item, item AND item AND item, etc. *)

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

Обоснование

В.1 Краткая история вопроса

Работу по стандартизации в области передовых технологий в Европе выполняет технический комитет CEN/ ТС310 "Передовые технологии производства". Рабочая группа CEN/TC310 WG1 "Архитектура систем" (далее - ТС 310 WG1 (ТК 310/РГ 1)) данного комитета занимается вопросами стандартизации в области архитектуры систем CIM. Данная работа является основой для разработки стандартов CEN и ИСО в этой области.

В 1990 г. рабочая группа CEN/CENELEC WG-ARC, которая была до создания рабочей группы ТС 310 WG1, завершила разработку стандарта ENV 40003, который позднее был пересмотрен и издан в качестве стандарта ИСО 19439. В этом стандарте изложен основополагающий принцип идентификации и согласования общих концептуальных конструкций, необходимых для компьютерного моделирования предприятий с акцентом на дискретное производство деталей.

В 1992 г. WG-ARC завершила работу над "Оценкой конструкций для функционального представления" в соответствии с ENV 40003, и эта оценка была опубликована в CEN/CENELEC в виде Технического отчета R-IT-06. Оценка показала, что ни одна инициатива, содержащаяся во всех требуемых методах, конструкциях, семантике и представлении, не была востребована, вследствие чего от участников проектов, активно разрабатываемых в этой области, потребовалась дополнительная работа, которая была выполнена (см. [11] и [12]). В настоящем стандарте эта работа учтена, но основным документом по принципам работы и применяемой терминологии остается ИСО 19439.

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

В.2 Основа для моделирования предприятия по ИСО 19439

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

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

- измерение, касающееся разработки и эволюции самой модели предприятия, от идентификации моделируемого домена предприятия и заявления о требованиях до разрабатываемой модели и внесения последующих усовершенствований. Это измерение фазы модели предприятия;

- измерение, касающееся структуры и поведения модели, для представления ключевых аспектов предприятия. Это измерение представления модели предприятия;

- измерение, касающееся специализации моделей и компонентов модели от общего к частному. Это измерение универсальности.

В.3 Подход к моделированию предприятия

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

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

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

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

а) как открытого набора согласованных Бизнес-процессов, направленных на достижение целей и решение задач предприятия, и

b) как интеграции Функциональных сущностей (компьютера, персонала и применений), в которых Объекты предприятия используются для выполнения технологических операций Бизнес-процессов.

Данный подход соответствует структуре, приведенной в ИСО 19439, в котором:

- функциональное представление отображает Бизнес-процессы, соответствующие Виды деятельности предприятия и необходимые инициирующие События;

- функциональное представление отображает Объекты предприятия в соответствии с функциональным представлением;

- ресурсное представление отображает Функциональные сущности как активные Ресурсы, Возможности, Личностные (персональные) профили и ассоциативные Роли;

- организационное представление рассматривает Бизнес-процессы, Объекты предприятия и Функциональные сущности через призму ответственности и полномочий, определенных как Организационные единицы и Организационные роли.

В.4 Как конструкции поддерживают данный поход

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

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

________________

В ИСО 19439 данные структуры определены как частичные (частные) модели.

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

Конструкции для моделирования предприятия приведены в пункте 3.1 и разделах 4, 5 и 6 настоящего стандарта.

В.5 Преимущества использования конструкций

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

- планирование бизнеса (идентификация домена, определение концепции, определение требований) для принятия решения и представления требований для бизнеса и, следовательно, необходимого направление развития;

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

- установка и проверка (внедрение) для большей надежности и сокращения временной шкалы;

- операции (работа в домене) при возникновении проблем или внесении необходимых изменений, чтобы быстрее разбираться в ситуации и улучшать связи с разработчиками и специалистами по комплексным системам;

- вывод из эксплуатации (определение вывода из эксплуатации) операционной системы домена в конце срока ее эксплуатации.

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

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

________________

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

a) пользователей приложений;

b) архитекторов приложений;

c) специалистов по распространению информации;

d) документоведов систем;

e) ИКТ вендоров;

f) разработчиков модели (инженеров-системотехников, инженеров-консультантов, специалистов по комплексным системам);

g) разработчиков стратегии производственной технологии и ИКТ;

h) специалистов по реинжинирингу;

i) исследователей;

j) поставщиков программного обеспечения;

k) разработчиков стандартов.

Конструкции могут оказать помощь специалистам в следующем:

- при разработке методов и средств моделирования, которые могут быть использованы производственным персоналом, а не специалистами по ИКТ;

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

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

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

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

Краткий обзор конструкций языка моделирования и взаимосвязей

С.1 Метамодель

Введение

Целью данной концептуальной модели является представление взаимосвязей и атрибутов конструкций, описанных в разделе 6 настоящего стандарта. Метамодель формализуется с использованием нотаций диаграммы классов UML, но необходимо учитывать, что она не предназначена для использования в качестве основы разработанных экземпляров или отправной точки для разработки технических средств. За некоторыми исключениям она не указывает отличительные признаки модели по фазе, а также то, как их предполагается использовать. Эта информация приведена в разделах 4, 5 и 6 настоящего стандарта.

Из-за сложности приведенная далее модель представлена в виде различных стадий:

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

b) диаграмма, обеспечивающая высокоуровневое представление всех 16 конструкций;

c) диаграмма, представляющая конструкции и взаимосвязи, используемые при моделировании бизнес-функций;

d) диаграмма, представляющая конструкции и взаимосвязи, используемые при моделировании бизнес-информации;

e) диаграмма, представляющая конструкции и взаимосвязи, используемые при моделировании бизнес-ресурсов;

f) диаграмма, представляющая конструкции и взаимосвязи, используемые при моделировании бизнес-организации.

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

Рисунки С.3, С.4, С.5 и С.6 подготовлены на основе шаблонов конструкции, приведенных в разделе 6 настоящего стандарта, и иллюстрируют взаимосвязи между рассматриваемыми концепциями. Следует подчеркнуть, что эти диаграммы являются иллюстративными - сами шаблоны представляют собой окончательный (и нормативный) текст. Шаблоны генерируют путем размещения концепций, расположенных в центре относительно представления, в середине диаграммы (например, Бизнес-процесс, Деятельность предприятия и Функциональная сущность для функционального представления, Объект предприятия для информационного представления и т.д.). Затем добавляют конструкции, имеющие отношения к прямой ассоциации или специализации, в качестве дополнительных концепций (например, ограничения, правила целостности) и сами взаимосвязи. Затем к каждой конструкции добавляют атрибуты, если только эти атрибуты не соответствуют ассоциации (в этом случае ассоциацию помечают соответствующим образом) либо обобщению или специализации. Ассоциации, помеченные стрелкой, должны читаться в направлении стрелки. Метки в конце некоторых ассоциаций, указывают на роль, которую играют соответствующие конструкции в конкретной ассоциации.

________________

В противоположность этому, в приложении Е приведены случаи разработки модели на примере ИСО 19439.

Некоторые ассоциации унаследованы через специализацию, например, в разделе С.4 Продукт как специализация Объекта предприятия наследует ассоциацию с дополнительной концепцией ограничение и может быть отображен Объектными представлениями.

Примечание - В зависимости от целей моделирования конструкции часто применяют для некоторых представлений модели и аспектных моделей, представленных в перечислениях с)-f), и примерами, приведенными в приложении Е. Для любой конкретной модели предприятия разработчик должен решить заранее, какие конструкции должны присутствовать в каком представлении модели предприятия.

Эти диаграммы содержат абстрактные классы (помеченные <<abstract>>), которые введены исключительно для этой метамодели UML и не используются в других пунктах.

С.2 Шаблон для конструкций языка моделирования

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

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

Взаимосвязи между этими частями шаблона показаны на рисунке С.1.

Рисунок С.1 - Составляющие шаблона конструкции

Полный комплект конструкций языка моделирования (без ассоциаций) подробно определен в разделе 6 и показан на рисунке С.2.

Рисунок С.2 - Набор конструкций (ассоциации не указаны)

С.3 Метамодель функциональных аспектов

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

Рисунок С.3 - Функциональные аспекты

С.4 Метамодель информационных аспектов со специализациями

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

Рисунок С.4 - Информационные аспекты

С.5 Метамодель ресурсных аспектов

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

Примечание - Каждая Функциональная сущность выполняет Функциональную операцию.

Рисунок С.5 - Ресурсные аспекты

С.6 Метамодель организационных/решенческих аспектов

Организационные роли и Организационные единицы/Центры принятия решений управляют разными конструкциями согласно рисунку C.6. Следует обратить внимание на то, что ассоциация "OU resp for" (Организационная единица, отвечающая за) включает в себя ответственность Организационной единицы за другие Организационные единицы (как следующая из конструкции модели предприятия) и, аналогично этому, ассоциация "DC decisions apply to" (решения Центра принятия решений применимы к) включает в себя решения Центра принятия решений, применимые к другим Центрам принятия решений.

Рисунок С.6 - Организационные/решенческие аспекты

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

Возможность применения настоящего стандарта в других проектах

D.1 Введение

Настоящее приложение распространяется на область применения настоящего стандарта путем отнесения модельных конструкций, установленных в настоящем стандарте, к двум видам работ - в области стандартизации и в области научных исследований в Европе. В разделе D.2 приведено сравнение с приведенным в ИСО/МЭК 15414 [4] языком для открытой распределенной обработки данных ODP для предприятия, а в разделе D.3 настоящего стандарта - с первыми опубликованными результатами осуществляемого в настоящее время европейского научно-исследовательского проекта ATHENA, относящегося к языку POP* [10].

D.2 Метамодель конструкций, связанных с ИСО/МЭК 15414

D.2.1 Введение в ODP и сравнение

В дополнение к метамодели, приведенной в приложении С, в настоящем разделе приведено сравнение конструкций языка моделирования, описанных в разделе 6 настоящего стандарта, с работой ИСО/МЭК JTC1/SC7/WG19 по языку предприятия "Открытая распределенная обработка данных (ODP)" согласно [4]. Эта работа раскрывает пять представлений (предприятие, информация, вычисления, инжиниринг, технология) и соответствующие ИСО/МЭК 10746 языки с целью:

- усовершенствовать и расширить язык предприятия, определенный в ИСО/МЭК 10746, с целью подробного изложения представлений предприятия в системе ODP;

- пояснить соответствие спецификаций представлений предприятия в системе ODP с другими спецификациями представлений этой системы и

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

"Язык предприятия ODP вводит усовершенствования ... [концепций в других стандартах]... дополнительные специфические концепции представлений и директивные правила структурирования для спецификаций предприятия ... [создавая таким образом]... общий язык (набор терминов и правил структурирования), который следует использовать при подготовке спецификации предприятия, фиксирующей цель, область применения и политику для ODP системы".

__________________

Эти задачи и текст см. ИСО/МЭК 15414:2006, раздел 0.2.

Вышеприведенная цитата соотносит конструкции языка моделирования, представленные в настоящем стандарте, с метамоделью системных концепций, определенных в ИСО/МЭК 15414, путем сравнения терминов, используемых в этих стандартах. Соответствующие термины и определения, применяемые в данных стандартах, приведены в таблице соответствия D.1. В таблицу включены также некоторые используемые в данном сравнении термины, определения которых приведены в том или другом стандарте.

__________________

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

D.2.2 Метамодель ODP

На рисунке D.1 представлены системные концепции, соответствующие установленным в ИСО/МЭК 15414.

Рисунок D.1 - Метамодель семейства ODP и концепции поведения

D.2.3 Связанная с ODP метамодель для настоящего стандарта

Рисунок D.2 практически аналогичен рисунку D.1 кроме того, что некоторые системные принципы ODP переименованы с использованием соответствующих терминов, определенных в настоящем стандарте. Соответствие использования концепций языка ODP настоящему стандарту указано в надписях на рисунке. Девять концепций языка ODP используют в метамодели конструкций языка моделирования и дополнительных концепциях. В трех из них использован тот же термин, а в шести остальных концепциях имена изменены с использованием терминов, определенных в настоящем стандарте. Шесть системных концепций в соответствующей метамодели конструкций языка моделирования по настоящему стандарту напрямую не используются, хотя позже термин Роль будет интерпретирован как применимый к людям.

Две концепции на рисунке D.3 (Цель и Поведенческое правило) определены не как конструкции моделирования, а как атрибуты нескольких конструкций и как дополнительные концепции соответственно.

Рисунок D.2 - Метамодель семейства ODP и поведенческие концепции, соответствующие настоящему стандарту

Девять конструкций языка моделирования в метамодели Языка предприятия ODP не определены. Одна из них (Заказ) является специализацией конструкции Объект предприятия и поэтому относится к концепциям ODP. Следующие три (Личностный (персональный) профиль, Организационная роль и Операционная роль) являются специализациями концепции Роли в ODP. Остальные пять конструкций (Способность, Центр принятия решений, Домен, Представление объекта предприятия и Событие) в метамодели ODP отсутствуют. Однако три из них (Способность, Центр принятия решений и Представление объекта предприятия) могут быть отнесены к концепциям Языка предприятия ODP, таким как Ресурсы/Действующее лицо, Сообщество и Объект предприятия.

Рисунок D.3 аналогичен рисунку D.2, но адаптирован так, чтобы в большей степени соответствовать метамодели конструкции языка моделирования (см. приложение С), и представляет, как Роль интерпретируется для выражения связи Человека с Деятельностью предприятия и Организационной единицей, а также как Функциональная категория преобразуется в специализированную поддержку Ресурсов для Деятельности предприятия.

Рисунок D.3 - Частичная метамодель, соответствующая настоящему стандарту, адаптированная к ИСО/МЭК 15414

D.2.4 Сравнение определений

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

D.3 Метамодель конструкций, относящихся к языку моделирования ATHENA - POP*

D.3.1 ATHENA - Ведение и сравнение

В настоящем разделе приведено сравнение конструкций языка моделирования, приведенных в разделе 6 настоящего стандарта, с работой по проекту ATHENA: язык POP* (Процесс - Организация - Продукт... [10]. Проект ATHENA "Перспективные технологии для обеспечения совместимости гетерогенных сетей предприятий и их применение" является интегрированным проектом, финансируемым Европейской комиссией, для поддержки стратегической задачи "Сетевой бизнес и правительство", изложенной в рабочей программе IST 2003-2004 в рамках FP6 (шестой рамочной программы; РП 6). Комплекс этих работ (см. А.1.3) направлен на разработку основных элементов методологии моделирования для сбора данных по совместному проектированию и управлению предприятиями и решения проблемы интероперабельности между моделями предприятия и инструментами моделирования (на высшем уровне абстракции) путем создания механизма отображения.

_________________

Работа представлена на сайте: http://www.athena-ip.org/.

Окончательный вариант методологии ATHENA POP*, обеспечивающей создание набора базовых конструкций моделирования для поддержки обмена моделями между сотрудничающими предприятиями, приведен в [10]. Этой работе в значительной мере способствуют уже существующие инициативы и стандарты, из которых основными являются процессно-ориентированные BPDM, UEML1.0 и ИСО 19440. Хотя присутствует некоторое дублирование мотивировки и области применения между POP* и упомянутыми инициативами, цель ATHENA заключается в том, чтобы в POP* использовался комплексный подход, охватывающий все соответствующие аспекты (сотрудничающих) предприятий, даже если в нем выделяются процессно-ориентированные аспекты. Кроме того, язык POP* должен быть частью большего целого, создавая методологии и платформы для поддержки моделирования, создания, управления и функционирования сотрудничающих предприятий.

В настоящем разделе, как и в разделе D.2, конструкции языка моделирования, представленные в настоящем стандарте, связаны с метамоделью концепций, определенных для POP* в проекте ATHENA, а термины, используемые в данных работах, соотносятся друг с другом. ATHENA определяет для своего языка POP* многочисленную мета-архитектуру согласно ODP. На рисунке D.4 указано, что POP* измерения моделирования, такие как Процесс или Продукт, заимствованы из ядра POP*, которое определяет общие типы объектов на основе архитектуры знаний предприятия (ЕКА), представляющего эту метамодель.

Рисунок D.4 - Архитектура ATHENA POP*

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

D.3.2 Метамодель ATHENA POP*

Метамодель измерения процесса приведена на рисунке D.5. Стереотипы с префиксом eka, такие как <<eka Object>>, заимствованы из архитектуры знаний предприятия POP*.

Примечание - Рисунки D.5, D.6, D.7, D.8 и D.9 созданы на основе проекта ATHENA, а терминология и использование прописных букв соответствуют целям (данного) проекта (например, Организационная единица, вместо Организационная Единица).

Рисунок D.5 - Метамодель POP*: измерение процесса

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

Таблица D.2 - Атрибуты процесса

На рисунках D.6, D.7, D.8 и D.9 приведены примеры других измерений, которые были учтены при разработке консолидированной частичной метамодели POP* (см. рисунок D.10).

Рисунок D.6 - Метамодель POP*: измерение организации

Рисунок D.7 - Метамодель POP*: измерение продукта

Рисунок D.8 - Метамодель POP*: измерение решения

Рисунок D.9 - Метамодель POP*: измерение системы

На рисунке D.10 представлена консолидированная метамодель, построенная на основе пяти метамоделей, соответствующих измерениям: Процесс, Продукт, Организация, Решение и Системы.

Рисунок D.10 - Частичная метамодель для ATHENA POP* (адаптированная на основе четырех отдельных метамоделей POP*)

D.3.3 Связанная с POP* метамодель, соответствующая настоящему стандарту

На рисунке D.11 рисунки D.6-D.10 представлены в таком виде, чтобы насколько это возможно заменить эквивалентные конструкции на конструкции, описанные в настоящем стандарте, с изменениями, где это необходимо. Использование концепций POP* в настоящем стандарте указано в наименованиях на этом рисунке. В этой метамодели использованы двенадцать концепций POP*, четыре из которых переименованы. Настоящий стандарт не распространяется на восемь концепций POP* в соответствующей метамодели для конструкций языка моделирования.

Четыре концепции на рисунке D.5 (Человек, Поведенческое правило, Ввод, Вывод) определены не как конструкции моделирования, а как базовая концепция, дополнительная концепция и атрибуты нескольких конструкций соответственно.

Рисунок D.11 - Частичная метамодель для ATHENA POP*, соответствующая требованиям настоящего стандарта

Восемь конструкций языка моделирования по настоящему стандарту не определены напрямую в частичной метамодели POP*, изображенной на рисунке D.11. Две конструкции (Продукт, Заказ) являются типами Объекта предприятия, Функциональная сущность представляет собой специализацию Ресурсов, а Деятельность предприятия - тип Бизнес-процесса. Конструкция Объектного представления в значительной степени эквивалентна вводам и выводам процесса POP*. Домен - это концепция, которую в селективных метамоделях POP* не используют. Остальные две конструкции (Личностный профиль, Операционная роль) рассматривают как специализацию Роли POP* и Роли ресурсов.

На рисунке D.12 приведен рисунок D.11, адаптированный в целях большего согласования с метамоделью конструкции языка моделирования по настоящему стандарту. В частности, конструкция Операционная роль отображает поддержку (со стороны человека) Деятельности предприятия, и в настоящем стандарте, то как человек более тесно ассоциирован с Личностным профилем и, следовательно, с Организационной и Операционной ролями.

Рисунок D.12 - Частичная метамодель по настоящему стандарту, адаптированная к метамодели ATHENA POP*

D.3.4 Сравнение определений

В таблицах D.3-D.6 приведены термины, применяемые в ATHENA POP* и настоящем стандарте, которые организованы по четырем рассматриваемым измерениям POP*. Термины, соответствующие более чем одному измерению, приведены один раз.

Таблица D.3 - Перечень конструкций по настоящему стандарту и соответствующих им терминов на основе измерений общей концепции POP*, имеющих отношение к настоящему стандарту

Таблица D.4 - Перечень конструкций по настоящему стандарту и соответствующих им терминов на основе измерений процесса POP*, имеющих отношение к настоящему стандарту

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

Таблица D.6 - Перечень конструкций по настоящему стандарту и соответствующих им терминов на основе измерений решения POP*, связанных с настоящим стандартом

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

Примеры применения конструкций и дополнительных концепций

Е.1 Цель данного приложения

В разделе Е.2 указано, как следует использовать каждую конструкцию языка моделирования на разных этапах моделирования. В разделе Е.3 указано, в каких шаблонах конструкции по разделу 6 используют каждую дополнительную концепцию, а в разделе Е.4 указаны способы использования шаблонов при разработке модели. В настоящем приложении приведены примеры описаний каждой конструкции по разделу 6 и моделей UML, соответствующих приведенным в приложении С с дополнительными пояснениями.

Е.2 Конструкции языка моделирования, используемые на разных этапах моделирования

Типичными случаями применения конструкций, идентификация которых зависит от этапов моделирования, являются следующие:

- идентификация домена:

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

- определение концепции:

- Домен, (Бизнес-процесс, Объект предприятия, Событие, Представление объекта, Организационная единица), Центр принятия решений;

- определение требования:

- Домен, Бизнес-процесс, Деятельность предприятия, Способность (требуемая), Объект предприятия и Представление объекта, Организационная единица, требуемая Организационная роль, требуемая Операционная роль, Центр принятия решений;

- спецификация схемы:

- Домен, Бизнес-процесс, Деятельность предприятия, Событие, Объект предприятия, Продукт, Заказ и Представление объекта, Ресурсы, Функциональная сущность, Способность (предоставленная), Организационная единица, предоставленная Организационная роль, предоставленная Операционная роль, Личностный профиль, Центр принятия решений;

- описание внедрения:

- все вышеуказанное для фиксирования любых отклонений компонентов внедренной системы от технических условий на проектирование;

- операция в домене:

- конкретная модель для поддержки решения на основе модели и операционный мониторинг и управление;

- определение прекращения использования:

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

________________

Для идентификации домена на этой фазе идентификации концепции требуется только идентификация домена.

На этом этапе определения требований дополнительная информация не требуется.

На этом этапе спецификации схемы дополнительная информация не требуется.

Е.3 Дополнительные концепции и их применение

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

Поведенческие правила используют для установления логического упорядочения Бизнес-процесса с точки зрения составляющих видов деятельности, инициируемых событий и характеристик активности. Данные правила указаны в 6.3.5 и приложении А. В разделе 6 поведенческие правила указаны в шаблонах в рамках Бизнес-процесса (набора поведенческих правил). Поведенческие правила не имеют ассоциированного идентификатора.

Ограничения являются частью текста или предикатами первого порядка, указывающими на ограничение, предел или условие, устанавливаемое для большинства конструкций. Ограничения используют в следующих шаблонах: Домен, Бизнес-процесс, Деятельность предприятия, Объект предприятия, Представление объекта, Продукт, Заказ, Ресурсы, Способность, Функциональная сущность и Центр принятия решений, а также в рамках декларативных правил, определенных правилами целостности применительно к Объектам предприятия. Ограничения определяются правилами, относящимися к взаимосвязям, в случае их применения для взаимосвязей и транзакций (см. 5.5). Ограничения могут иметь ассоциативный идентификатор.

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

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

Правила целостности применяют к Объекту предприятия, Представлению объекта, Продукту, Заказу, Ресурсам, Способности и Функциональной сущности на этапе определения требований для того, чтобы сделать заявления о наличии информации и ее соответствии реальной действительности. Данные заявления интерпретируют на последних этапах моделирования предприятия как ограничения к информации. Правило целостности имеет ассоциативное имя и/или идентификатор.

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

Показатели результативности являются частями текста, в которых установлены критерии или исходные параметры, предназначенные для оценки выполнения задач. Данные показатели используют в Домене, Бизнес-процессе и Деятельности предприятия.

Е.4 Использование шаблонов при разработке модели

Е.4.1 Пример

Следующий пример обработки заказа на производственном предприятии приведен в ИСО 19439:2006, приложение В, раздел В.3. В настоящем стандарте пример дополнен с целью демонстрации использования шаблонов при моделировании предприятия.

Данный пример представлен на рисунке Е.1, показывающем сущности предприятия в виде диаграммы "сущность - связь", соответствующей концепции представления для четырех представлений, определенных в настоящем стандарте: представление функции, информации, ресурсов и организации (дополнительная информация об отдельных представлениях приведена на рисунках Е.2-Е.5).

Рисунок Е.1 - Представление модели для обработки заказа

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

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

Представление организации отображает связи между различными организационными сущностями на предприятии и устанавливает их обязанности. Эти обязанности могут находиться на разных уровнях организации и обычно выполняются членами сущности организации, уполномоченной принимать решения. Этот аспект принятия решения рассмотрен в концепции GRAI [12] относительно центров принятия решений. Установление временных горизонтов разных центров принятия решений определяет аспект планирования при принятии решения. Содержание разных представлений и соответствующих шаблонов описаны в следующих разделах и сведены в две таблицы с кратким изложением.

Е.4.2 Представление функции

Е.4.2.1 Разработка представления функции

На рисунке Е.2 подробно показано представление функции, указанной в примере, приведенном выше. Два из трех идентифицированных доменов (Заказчик и Поставщик) имеют Входы (Заказчик/Заказ, Поставщик/Детали) и Выходы (Заказчик/Продукт и Счет-фактура, Поставщик/Заказ и Оплата) в/из собственного предприятия домена, который состоит из двух процессов (Администрация и Производство), идентифицированных в представлении функции на рисунке Е.2. Обработку домена начинает событие EV-1 Поступление заказа от клиента, которое ассоциировало сам заказ в форме Объектного представления OV-1 и которое начинает ВР-1/Администрация (см. Шаблон события далее).

Рисунок Е.2 - Представление функции для обработки заказа

Декомпозиция ВР-2 Производство приводит к образованию сети четырех видов деятельности предприятия, показанных на рисунке Е.2 в центре. В нижней части рисунка Е.2 указаны связи в направлении объектов представления информации и ресурсов, которые идентифицируют входы и выходы деятельности предприятия ЕА4. Не показаны связи в направлении представления организации через обязанности или идентификацию организационных аспектов (цеха, рассматриваемого как комбинацию Отделения и Центра принятия решений). В следующих примерах шаблонов отражены четыре конструкции: Домен, Бизнес-процесс, Деятельность предприятия и Событие, которые являются релевантными для представления функции.

Е.4.2.2 Пример шаблона конструкции Домен

________________

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

Здесь и далее в тексте TBD означает, что требуется дополнительная информация, которая не приведена в примере.

Е.4.2.3 Пример шаблона конструкции Бизнес-процесс

________________

ES является сокращенным обозначением Конечного Статуса/Ending Status.

Е.4.2.4 Пример шаблона конструкции Деятельность предприятия

Е.4.2.5 Пример шаблона конструкции Событие

Е.4.3 Представление информации

Е.4.3.1 Разработка информационного представления

На рисунке Е.3 указаны связи между информационным и функциональным представлением для сборочных работ только с учетом связи для входов (Детали и Покупные детали) и выходов (Продукт) функции.

Вся информация, которая используется и выдается Деятельностью предприятия как Объектного представления, является или становится частью родственных Объектов предприятия. Детали и Продукт (изделие) указаны в информационном представлении как объекты. Для функционального представления использованы только проекции этих объектов, называемые Представлениями объекта (CIMOSA [11]), которые отбирают ограниченный набор информации об объекте. В соответствии с рисунком Е.1 Объект предприятия Часть является частью Объекта предприятия Продукт. Для остальной части информационного представления на рисунке Е.3 указаны только составные объекты и их связи.

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

Информационное представление может быть использовано двумя разными способами, которые указаны на рисунке Е.3 стрелками в двух направлениях.

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

b) Объектные представления отбирают из заранее определенных Объектов предприятия.

Опция b) является предпочтительным способом обеспечения согласованности модели предприятия и базы знаний предприятия.

Рисунок Е.3 - Представление информации для обработки заказа

Е.4.3.2 Пример шаблона конструкции Объект предприятия

Е.4.3.3 Пример шаблона конструкции Представление объекта

Е.4.3.4 Пример шаблона конструкции Продукт

Е.4.3.5 Пример шаблона конструкции Заказ

Е.4.4 Представление ресурсов

Е.4.4.1 Разработка ресурсного представления

На рисунке Е.4 указаны связи между ресурсным и функциональным представлением с использованием только ресурсов сборочных работ. В этом случае применяют концепцию Представлений объекта. В соответствии с рисунком Е.1 Объект ресурса Сборочная станция, также как другие ресурсы оборудования, является частью Объекта ресурсов Цех. Оператор, участвующий в сборочной операции, представлен Личностным профилем Оператор. На рисунке Е.1 не указаны Функциональная сущность Обращение, которая состоит из Оператора, указанного на рисунке Е.4, и робота.

Рисунок Е.4 - Представление ресурсов для обработки заказа

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

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

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

b) Проекции объекта отбирают из предопределенных Объектов предприятия.

Опция b) является предпочтительным способом обеспечения согласованности модели предприятия и базы знаний предприятия.

Е.4.4.2 Пример шаблона конструкции Ресурс

Е.4.4.3 Пример шаблона конструкции Возможность

Е.4.4.4 Пример шаблона конструкции Функциональная категория

Е.4.5 Представление организации

Е.4.5.1 Разработка организационного представления

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

Рисунок Е.5 - Представление организации для обработки заказа

В нижнем правом углу рисунка Е.5 GRAI используется для отображения связей между разными центрами принятия решений (указаны стрелками). Центры принятия решений расположены в определенном порядке в сетке в соответствии с длительностью горизонтов планирования и связанными с ними сроками пересмотра решений.

Е.4.5.2 Пример шаблона конструкции Организационная единица

Е.4.5.3 Пример шаблона конструкции Центр принятия решений

Е.4.5.4 Пример шаблона конструкции Личностной профиль

Е.4.5.5 Пример шаблона конструкции Организационная роль

Е.4.5.6 Пример шаблона конструкции Операционная роль

Е.5 Использование шаблона. Пример краткого изложения содержания

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

Таблица Е.1 - Пример использования конструкций языка моделирования и их шаблонов