ГОСТ Р ИСО/МЭК 15414-2017. Национальный стандарт Российской Федерации. Информационные технологии. Открытая распределенная обработка. Эталонная модель. Язык описания предприятия

(утв. и введен в действие Приказом Росстандарта от 22.02.2017 № 67-ст)

1 января 2018 года

Предисловие

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

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

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

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 15414:2015 «Информационные технологии. Открытая распределенная обработка. Эталонная модель. Язык описания предприятия» (ISO/IEC 15414:2015 «Information technology — Open distributed processing — Reference model — Enterprise language», IDT).

ИСО/МЭК 15414 подготовлен Совместным техническим комитетом 1 ИСО/МЭК при участии ПК 7 в сотрудничестве с ITU-T. Идентичный текст опубликован под маркировкой ITU-T X.911 (09/2014). Отдельные части этого документа могут быть защищены патентным правом.

Сведения о соответствии ссылочных международных стандартов национальным стандартам Российской Федерации приведены в дополнительном приложении ДА

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

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

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

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

0.1 Эталонная модель открытой распределенной обработки RM-ODP

RM-ODP включает в себя:

• ITU-T X.901|ИСО/МЭК 10746-1. Обзор: содержит обоснования к применению ODP, приводится общий обзор, обоснование и толкование ключевых понятий и схем архитектуры ODP. Приводятся разъяснения для пользователей по вопросам интерпретации и применения на практике RM-ODP, включая авторов стандартов и разработчиков систем ODP. Раздел содержит описание классификации требуемых областей, подлежащих стандартизации, с использованием контрольных точек для устранения несоответствий, определенных в ITU-T X.903|ИСО/МЭК 10746-3. Часть 1 носит справочный характер.
• ITU-T X.902|ИСО/МЭК 10746-2. Основы: содержит определения основных понятий и описание аналитической структуры объекта для перевода в нормализованное состояние (произвольных) распределенных обрабатывающих систем. Вводятся принципы соответствия стандартам ODP и способы их применения. Приводимый уровень детализации является достаточным для поддержки ITU-T X.903|ИСО/МЭК 10746-3 и устанавливает требования к новым методам спецификации. Часть 2 носит обязательный характер.
• ITU-T X.903|ИСО/МЭК 10746-3. Архитектура: вводятся спецификации требуемых характеристик, которые квалифицируют распределенную обработку данных, как открытую. Это ограничения, которым должны соответствовать стандарты ODP. Используются дескриптивные (описательные) методы, приведенные в ITU-T X.902|ИСО/МЭК 10746-2. Часть 3 носит обязательный характер.
• ITU-T X.904|ИСО/МЭК 10746-4. Архитектурная семантика: приводится формализованное описание основных понятий процесса моделирования ODP, определенных в ITU-T X.902|ИСО/МЭК 10746-2 (разделы 8 и 9). Формализация достигается путем интерпретации каждого понятия в терминах конструктов одного или нескольких стандартизированных методов формального описания. Часть 4 носит обязательный характер.
• ITU-T X.911|ISO/IEC 15414. Язык описания (дескриптор) предприятия: Рекомендации|Международный стандарт 0.2

Обзор и рекомендации к применению

Часть 3. Эталонная модель ITU-T X.903|ИСО/МЭК 10746-3 определяет основу для спецификации систем ODP, включающую:

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

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

Цель настоящего стандарта направлена на:

• усовершенствование и расширение рабочего языка, определенного в ITU-T X.903|ИСО/МЭК 10746-3, для более полного определения смысловых диспозиций предприятия в системе ODP.
• приведение привязки спецификаций смысловых диспозиций предприятия в системе ODP в соответствии с другими техническими требованиями к конкретным смысловым диспозициям.
• гарантирование того, что рабочий язык при совместном использовании с другими языками описания смысловых диспозиций подходит для спецификации конкретной архитектуры приложения и отвечает специфическим потребностям производства.

Настоящий стандарт опирается на понятия, взятые из ITU-T X.902|ИСО/МЭК 10746-2 и X.903|ИСО/МЭК 10746-3, и правила структурирования, приведенные в ITU-T X.903|ИСО/МЭК 10746-3 (раздел 5). Стандарт вводит уточнения и изменения понятий, дополнительные смысло-ориентированные концепты и предписываемые правила структурирования спецификаций для наиболее полного учета технических требований предприятия. Дополнительные смысло-ориентированные концепты определены в ITU-T X.902|ИСО/МЭК 10746-2 и X.903|ИСО/МЭК 10746-3.

Настоящий стандарт устанавливает общий язык (набор условий и правил структурирования) для применения при подготовке спецификации предприятия с учетом целей, назначения и стратегий управления с точки зрения требований системы ODP. Спецификация предприятия — часть спецификации системы ODP по смысловым диспозициям, установленным ITU-T X.903|ИСО/МЭК 10746-3. Спецификация системы ODP позволяет описать:

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

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

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

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

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

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

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

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

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

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

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

Настоящий стандарт предусматривает наличие:

a) языка предприятия, включающего понятия, структуры и правила разработки, представления и обоснование спецификации системы ODP с предпринимательской точки зрения (как определено в ITU-T X.903|ИСО/МЭК 10746-3);

b) правил, устанавливающих соответствие между языком предприятия и на других языках смысловых диспозиций (определенных в ITU-T X.903|ИСО/МЭК 10746-3) для обеспечения общей согласованности спецификации.

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

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

Как указано в ITU-T X.903|ИСО/МЭК 10746-3 (раздел 5), спецификация смысловой диспозиции предприятия определяет цели, назначение и стратегии управления системы ODP.

Настоящий стандарт представляет собой уточнение и расширение ITU-T X.903|ИСО/МЭК 10746-3 (разделы 5 и 10), но не заменяет их.

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

В настоящем стандарте использованы нормативные ссылки на следующие стандарты (см. 2.1 и 2.2). На момент публикации указанные издания были действительны. Все рекомендации и стандарты подлежат возможному пересмотру, и сторонам соглашений, основанных на настоящем стандарте, предлагается изучить возможность применения последнего издания Рекомендаций и стандартов, перечисленных ниже. Члены МЭК (IEC) и ИСО (ISO) ведут перечни действующих международных стандартов. Бюро стандартизации электросвязи МСЭ (ITU) ведет список действующих в настоящее время Рекомендаций МСЭ-Т (ITU-T).

2.1 Типовые рекомендации ITU-T|международные стандарты

Рекомендация ITU-T X.902 (2009)|ИСО/МЭК 10746-2:2010 Information technology — Open Distributed Processing — Reference Model: Foundations (Информационные технологии. Открытая распределенная обработка. Эталонная модель: основы)

Рекомендация ITU-T X.903 (2009)|ИСО/МЭК 10746-3:2010 Information technology — Open Distributed Processing — Reference Model: Architecture (Информационные технологии. Открытая распределенная обработка. Эталонная модель: архитектура)

Рекомендация ITU-T X.904 (1997)|ИСО/МЭК 10746-4:1998 Information technology — Open Distributed Processing — Reference Model: Architectural semantics (Информационные технологии. Открытая распределенная обработка. Эталонная модель: Семантика архитектуры)

Рекомендация ITU-T X.906 (1997)|ИСО/МЭК 19793:2012 Information technology — Open distributed processing — Use of UML for ODP system specifications (Информационные технологии. Открытая распределенная обработка. Использование UML для спецификации ODP)

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

ISO/IEC 19505-2:2012 Information Technology — Object Management Group Unified Modelling Language (OMG UML) — Part 2: Superstructure (Информационные технологии. Унифицированный язык моделирования. Группы управления объектами (OMG UML). Часть 2: Надстройка)

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

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

3.1 Термины стандартов ODP

3.1.1 Основные термины для моделирования

Настоящий стандарт использует следующие термины, как это определено в ITU-T X.902|ИСО/МЭК 10746-2.

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

3.1.2 Языковые определения смысловой диспозиции

В настоящем стандарте применены термины по ITU-T X.903|ИСО/МЭК 10746-3.

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

4 Сокращения

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

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

эталонная модель RM-ODP открытой распределенной обработки (ITU-T X.901 к X.904|ИСО/МЭК 10746 Части 1 — 4).

5 Соглашения

Настоящий стандарт содержит ссылки на части 2 и 3 RM-ODP и на обязательный текст настоящего стандарта. Каждая ссылка имеет одну из этих форм:

• [часть, 2-n.n] — ссылка на пункт n.n Части 2 RM-ODP: Основы ITU-T X.902|ИСО/МЭК 10746-2;
• [часть, 3-n.n] — ссылка на пункт n.n Части 3 RM-ODP: Архитектура ITU-T X.903|ИСО/МЭК 10746-3;
• [n.n] — ссылка на пункт n.n настоящего стандарта.

Например, [часть 2-9.4] — ссылка на часть 2 эталонной модели, ITU-T X.902|ИСО/МЭК 10746-2, пункт 9.4 и [6.5] - ссылка на 6.5 этой рекомендации|международный стандарт. Эти ссылки приведены для удобства пользователя.

Настоящий стандарт также содержит некоторый текст, который является модификацией текста части 3 эталонной модели ITU-T X.903|ИСО/МЭК 10746-3. Такой текст отмечен ссылкой: [см. также 3-5]. Модификации являются полномочными (валидными) вариантами по отношению к дескриптору (языку) предприятия.

6 Понятия

Понятие дескриптора (языка) предприятия, определенного в настоящем стандарте, включает в себя:

• понятия, определенные в ITU-T X.902|ИСО/МЭК 10746-2 (пункты 3.1.1 и 3.1.2) и в ITU-T X.903|ИСО/МЭК 10746-3;
• понятия, определенные в настоящем пункте.

Группировка в подпункты и заголовки подпунктов настоящего пункта носят справочный характер.

6.1 Системные понятия

6.1.1 Назначение

Поведение, которое система, как ожидается, продемонстрирует.

6.1.2 Область применения (спецификации)

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

6.2 Понятия сообщества

6.2.1 Цель ()

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

Примечания

1 Достижение всех целей — не одномоментный процесс.

2 В тексте ITU-T X.903|ИСО/МЭК 10746-3 [часть 3-5] термины «цель» и «задача» синонимичны. В языке (дескрипторе) предприятия акцентированы термин «целевая задача» и «необходимость выражения цели в измеримых понятиях».

6.2.2 Объект сообщества

Сложный объект предприятия, который представляет собой сообщество. Компоненты объекта сообщества — объекты представленного сообщества.

6.3 Понятия поведения

6.3.1 Активный объект предприятия

Объект предприятия, который соответствует выполняемой роли. Другими словами, это объект предприятия, который может быть вовлечен в некоторое поведение.

Примечание — Поведение активных объектов предприятия ограничено понятиями нормативной модальности («запрещено», «разрешено», «предписывается») и понятиями ответственности, определенными в 6.4 и 6.6. Нормативные символы формальной логики, определенные в 6.4, не являются самостоятельно активными объектами предприятия.

6.3.2 Актор (связанный с действием)

Роль (относительно действия), в которой объект предприятия, исполняющий ее, действует. Этот объект можно назвать актором.

Примечание - Представляет интерес, какой актор инициирует это действие.

6.3.3 Артефакт (связанный с действием)

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

Примечания

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

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

6.3.4 Ресурс (связанный с действием)

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

Примечания

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

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

6.3.5 Роль интерфейса

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

6.3.6 Процесс

Последовательность шагов, установленных предписанным способом.

Примечания

1 Предписанный способ может быть представлен частично установленной последовательностью шагов.

2 Понятия структуры деятельности, установленные в ITU-T X.902|ИСО/МЭК 10746-2 (пункт 13.1), могут быть применены в случае замены «шага» для «действия» и «процесса» для «деятельности» при определении структуры процесса.

3 Процесс может иметь многократные конечные точки.

4 Спецификация предприятия может определять типы и шаблоны процесса.

5 Процесс — абстрактное представление «поведения», и ему могут быть назначены любые «задачи» (цели), определенные для этого поведения.

6 Спецификация процесса может быть представлена спецификацией документооборота.

6.3.7 Шаг

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

6.3.8 Нарушение

Поведение вопреки требуемому правилу.

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

6.4 Нормативные понятия

6.4.1 Нормативный маркер

Объект предприятия, который отражает ограничение на способность активного объекта предприятия, содержащего его, на выполнение определенных действий. Активному объекту предприятия присвоен ряд нормативных маркеров, управляющих порождением обусловленных действий в пределах его поведения. Эти символы — «запрещено», «разрешено», «предписывается». Нормативный маркер не является самостоятельным активным объектом предприятия; он содержится у активного объекта предприятия.

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

6.4.2 Символическая группа

Группа символов, которая может быть объявлена как целая.

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

6.4.3 Предписание (обременение)

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

6.4.4 Запрещение

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

6.4.5 Разрешение

Нормативный маркер, заключающий в капсулу заявление (закрепляющий) «разрешения» по активному объекту предприятия, таким образом, изменяя способность активного предприятия при выполнении соответствующих обусловленных действий в рамках своего поведения.

6.4.6 Условное действие

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

6.4.7 Речевой акт

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

Примечания

1 Совокупность действий, за которые стороны ответственны, — это речевые акты, например предписания и обязательства.

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

6.5 Стратегические понятия

6.5.1 Стратегия

Ограничение, накладываемое на системную спецификацию, предписанную в период разработки и относящееся впоследствии к оригинальному проекту, допускающее изменения по составу на временно́м отрезке и оказывающее влияние на управление системой при изменяющихся обстоятельствах. Стратегия выражается в форме правил, которые, в свою очередь, состоят из нескольких подправил. Стратегия вводится в спецификацию как стратегическая декларация. Для любой точки временно́й оси задается особая стратегическая значимость, которая регулируется совокупностью стратегических установок, которые до возникновения необходимости содержатся в заданном стратегическом конверте [см. 2-11.2.8 к 2-11.2.12].

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

6.5.2 Поведение под влиянием (изменение абстрактного шаблона класса «поведение»)

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

6.6 Понятия ответственности

6.6.1 Сторона

Объект предприятия — это физическое или юридическое лицо, которое имеет некоторые права, полномочия и обязанности.

Примечания

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

2 Стороны ответственны за свои действия и действия их агентов.

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

6.6.2 Обязательство

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

Примечания

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

2 Факт наличия обязательства у объекта предприятия отражается во взаимосвязи с наличием предписания по этому обязательству.

6.6.3 Предписание

Действие, которое устанавливает правило.

6.6.4 Разрешение

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

Примечания

1 В отличие от разрешения авторизация — это расширение возможностей.

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

6.6.5 Декларация

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

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

6.6.6 Делегирование ответственности

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

Примечание - Делегирование, назначенное в определенный момент, позже может быть отменено.

6.6.7 Оценка

Действие, которое оценивает стоимость (ценность, в широком смысле) какой-либо сущности.

Примечания

1 Например, действие, которым система ODP назначает относительный статус действию, согласно оценке системы.

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

6.6.8 Актор

Активный объект предприятия, которому было делегировано право на выполнение действия (разрешение, ответственность, предоставление обслуживания и т.д.) и который действует в интересах стороны (в осуществлении разрешения, исполнении ответственности, предоставлении услуги и т.д.).

Примечания

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

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

3 Спецификация может заявить, что в ее начальном состоянии активный объект предприятия — агент стороны.

6.6.9 Доверитель (принципал)

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

7 Правила структурирования

В настоящем разделе уточняются и дополняются правила структурирования, установленные в ITU-T X.903|ИСО/МЭК 10746-3 (пункт 5.2) и рассматриваемые применительно к понятиям сообщества, объектов предприятия, целей, шаблонов поведения и организационной деятельности. Определяются правила структурирования для понятий ответственности, определенных в 6.6. Используются понятия, определенные в ITU-T X.902|ИСО/МЭК 10746-2 (пункт 5.1), ITU-T X.903|ИСО/МЭК 10746-3 и в разделе 6.

7.1 Общее описание структуры спецификации предприятий

Спецификация предприятия системы ODP — это описание системы и связанные с ней части среды деятельности. Спецификация предприятия ориентирована на назначение и стратегии, которые применимы для предприятия в контексте среды деятельности.

Примечания

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

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

Фундаментальным понятием структурирования, что касается технических требований предприятия, является понятие сообщества. Сообщество — это конфигурация объектов предприятия, которая описывает совокупность субъектов, представляющих собой набор «сущностей» (например, люди, системы обработки информации, ресурсы различных видов и коллекции их), сформированных для достижения целей. Поведение субъектов определяется соглашением, управляющим их коллективным поведением. Назначение действий объектам предприятия, которые включены в сообщество, осуществляется в соответствии с ролевым участием (см. 7.8.1 и 7.8.2.).

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

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

Примечание 3 — Эта минимальная спецификация предприятия описывает цель и назначение системы ODP; это описание необходимо для полноты спецификации предприятия.

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

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

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

Примечание 5 — Это может представлять собой, например, объединение предприятий.

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

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

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

7.2 Содержание спецификации предприятия

Спецификация предприятия структурируется в терминах описания ее элементов, как это установлено в 7.1, и иных понятий, определенных в разделе 6, а также с учетом корреляций между ними.

Для каждого из этих элементов, в зависимости от выбора спецификатора и требуемого уровня детализации, спецификация предприятия определяет:

• характеристики элемента или
• тип или типы элементов, или
• шаблон элемента.

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

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

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

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

Примечания

1 Никакие рекомендации не могут ограничивать преимущественных предпочтений относительно способа моделирования для любого уровня проектирования: от нисходящего до восходящего. И при этом нет рекомендаций относительно порядка формирования спецификаций по областям деятельности.

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

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

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

7.3 Правила формализованного описания сообществ

7.3.1 Сообщество

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

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

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

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

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

Коллективное поведение сообщества определяется с точки зрения одного или более элементов:

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

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

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

Сообщество далее определено:

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

Примечания

1 Типы сообществ или шаблоны описания сообществ могут использоваться в спецификации сообщества.

2 Типы сообществ могут стать связанными в процессе обработки.

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

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

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

7.3.2 Взаимоотношения между сообществами

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

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

Сообщества могут осуществлять взаимодействие следующими способами:

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

Примечания

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

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

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

Следующие инварианты регулируют поведение объектов и сообществ:

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

Примечания

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

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

7.4 Правила формализованного описания объектов предприятия

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

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

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

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

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

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

Примечания

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

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

7.5 Общие типы сообществ

Двумя общими типами для описания сообщества являются:

• - область (домен);
• - федерация (объединение).

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

7.5.1 - тип области сообщества

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

7.5.2 - тип домена федерации (объединения)

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

7.6 Жизненный цикл сообщества

7.6.1 Установление (учреждение) сообщества

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

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

7.6.2 Политика назначения

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

Примечания

1 Роль, выполняемая объектом в его взаимосвязи с другими объектами, не является примером способа установления взаимосвязей.

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

Члены сообщества могут быть отобраны согласно требованиям стратегии назначения для того сообщества.

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

7.6.3 Внесение изменений в определение сообщества

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

Изменения, которые следует учитывать, включают в себя:

• дополнение, изменение и удаление стратегий или правил;
• дополнение, изменение и удаление ролей;
• дополнение и удаление объектов предприятия;
• дополнение, изменение и удаление процессов или шагов.

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

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

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

7.6.4 Ликвидация сообщества

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

Примечания

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

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

7.7 Правила формализации целей

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

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

Цель системы ODP в целом выражена как одна или несколько целей (или подцелей) сообщества или набора сообществ, в рамках которых система ODP реализует роли. Если система ODP самостоятельно смоделирована как сообщество, то цель системы — цель этого сообщества.

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

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

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

Примечание - Спецификация предприятия может обеспечить механизм обнаружения конфликта интересов и разрешения этих конфликтов.

7.8 Правила формализации шаблонов поведения

7.8.1 Роли и процессы

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

Примечания

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

2 Часть 2 эталонной модели предлагает концепцию деятельности [Часть 2-8.6]. А также предлагает концепцию формализации структуры деятельности [Часть 2-13.1], включая цепи, шаги, разветвление действий, сочетание действий и порождение действий. Они могут быть использованы для структурирования шаблонов поведения сообщества.

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

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

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

Процессы подразделяют поведение сообщества на шаги.

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

7.8.2 Правила формализации ролей

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

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

Примечание 1 — Если термин « объект» используется в спецификации предприятия, где - роль, то это должно интерпретироваться как значение «объекта предприятия, выполняющего роль, ». Там, где объект предприятия выполняет многочисленные роли, имена могут быть связаны.

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

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

Примечание 2 — Примерами такой спецификации может быть модель членов какого-либо комитета или модель клиентов какой-либо службы.

Объект предприятия, назначенный на роль, должен иметь тип, поведение которого совместимо с этой ролью, в противном случае спецификация должна содержать механизмы, чтобы определить и разрешить любые несовместимости [Часть 2-9.4].

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

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

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

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

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

7.8.3 Интерфейсные роли и взаимодействия между сообществами

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

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

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

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

7.8.4 Объекты предприятия и действия

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

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

Примечания

1 Для каждого действия есть, по крайней мере, один участвующий объект предприятия. Если два или более объектов предприятия участвуют в действии, то это взаимодействие. Если только один объект предприятия участвует в действии, это может быть взаимодействие, если объект взаимодействует сам с собой. [Часть 2-8.3]

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

3 В этом пункте понятие роли используется в контексте сообщества, в котором определена эта роль. Таким образом, роль объекта — это идентификатор для некоторого поведения, которое объект демонстрирует в этом сообществе. При определенных обстоятельствах поведение, которое назначено объекту, выступает как определенное действие, и в этом случае роль считается явно указанной.

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

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

7.8.5 Правила формализации процесса

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

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

Спецификация процесса должна включать в себя обязательное правило его инициирования и завершения.

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

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

7.8.6 Нарушения в поведении

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

Примечания

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

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

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

7.8.7 Правила назначения нормативных маркеров

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

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

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

Примечания

1 Набор символов, принадлежащих рассматриваемым объектам, определяет, может ли речевой акт иметь место и каковы его последствия. Например:

• необходимость для объекта иметь «разрешение», прежде чем будет совершено речевое действие;
• наличие «запрета» может препятствовать объекту в совершении речевого действия даже при том, что действие было бы иначе разрешено, учитывая роль объекта;
• «обязательство», назначенное объекту, может быть снято в результате выполнения речевого акта объектом; Выполнение делегированного речевого акта может передать группу нормативных маркеров (например, обязательство и разрешение) объекту, которому делегирована ответственность.

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

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

4 Эти правила могут быть смоделированы различными способами. Один из подходов по формализации спецификации приведен в приложении C.

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

Примечания

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

6 Если активный объект, с которым связан нормативный маркер, является объектом сообщества, то активному объекту может быть назначена определенная роль сообщества в пределах действия объекта сообщества. Когда эта роль выполнена объектом предприятия, маркер может быть клонирован, и копия связана с выполнившим эту роль объектом. Первоначальный маркер переводится в состояние ожидания. Если роль не исполняется, первоначальный маркер возвращается в активное состояние. Маркер, связанный с исполняющим роль объектом, удаляется, если взаимодействие первоначального маркера с объектом сообщества нарушено по какой-либо причине.

7.8.8 Спецификация обязательств, разрешений, запретов и авторизаций

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

7.8.8.1 Обязательство

Обязательство моделируется как нормативный маркер «обязательство» и определяется как:

• свод правил, которые описывают «обязательство»;
• определенное поведение, которое нормируется этим сводом правил;
• роль или роли, задействованные в этом поведении, которые нормируются сводом правил;
• подмножество этого поведения, которое требуется осуществить;
• опционально, объект или объекты, которые могут выполнить задействованные роли.

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

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

Постоянно действующее обязательство является обязательством, которое всегда осуществляется.

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

7.8.8.2 Разрешение

Разрешение моделируется как нормативный маркер «разрешение» и определяется как:

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

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

Примечания

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

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

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

7.8.8.3 Запрет

Запрет моделируется как нормативный маркер «запрещено» и определяется как:

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

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

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

7.8.8.4 Авторизация

Авторизация моделируется как комбинация нормативных символов «разрешения» и «обязательства». На основании разрешения активный агент предприятия, действуя как авторизированный (уполномоченный) агент, имеет обязательство действовать как уполномоченный агент, снимая все ограничения, которые могли бы препятствовать исполнению полномочий. Уполномоченный агент определяется как:

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

Обременение полномочиями устанавливается:

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

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

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

7.9 Правила формализации стратегий

7.9.1 Спецификация стратегии

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

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

Спецификация стратегии включает в себя:

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

Степень охвата и глубина охвата формализации стратегии в спецификации могут определяться делегированием одного объекта предприятия другому.

Примечания

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

2 Для установленного стратегического конверта только одна стратегическая стоимость (стоимостное выражение стратегии) находится в актуальном состоянии в конкретный момент времени. Эта стратегическая стоимость может быть отобрана из ряда величин стоимости, определенных в стратегическом конверте, или это может быть объявлено на стратегическом языке (в терминах описания стратегии), совместимом с ограничениями в стратегическом конверте.

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

4 Стратегии могут охватывать, например, правила о:

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

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

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

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

Объект предприятия должен соответствовать стратегиям каждого сообщества, в котором участвует.

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

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

7.9.2 Стратегии для федерации (объединения)

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

Примечания

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

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

3 Примерами случаев конфликта стратегий являются:

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

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

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

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

7.9.3 Поведение урегулирования стратегий

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

Примечания

1 Поведение может включать в себя ограничения на изменение этой стратегии.

2 Не существует никакого поведения для изменения стратегии (то есть, стратегия не изменяется во время жизненного цикла сообщества).

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

7.9.4 Обеспечение соблюдения стратегии

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

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

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

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

7.10 Правила определения ответственности

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

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

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

7.10.1 Правила делегирования политик

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

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

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

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

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

7.10.2 Правила выполнения авторизации

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

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

7.10.3 Правила наложения обязательств

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

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

7.10.4 Правила декларирования

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

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

7.10.5 Правила предписания

Действие активного объекта предприятия станет предписанием, только когда данный объект:

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

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

8 Соответствие, полнота и область применения

8.1 Соответствие

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

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

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

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

8.2 Полнота

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

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

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

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

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

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

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

9 Адекватность (приемлемость) языка описания предприятия

Спецификация предприятия, совместимая с настоящим стандартом, должна использовать понятия, определенные в ITU-T X.903|ИСО/МЭК 10746-3 (раздел 6 и пункт 5.1), а также понятия, определенные в ITU-T X.902|ИСО/МЭК 10746-2, при условии соблюдения статьи 7, и понятий в ITU-T X.903|ИСО/МЭК 10746-3 (пункт 5.2).

Могут также использоваться понятия из других языков моделирования. При их использовании такая спецификация должна включать или ссылаться на определения каждого такого понятия, установленного в ITU-T X.902|ИСО/МЭК 10746-2 (раздел 6) или в ITU-T X.903|ИСО/МЭК 10746-3 (пункт 5.1), и использовать описания взаимосвязей этих понятий, определенных в разделе 6.

10 Соответствие (согласованность) и контрольные точки

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

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

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

Для установления согласованности спецификации предприятия системный провайдер должен установить пункты соответствия (проводок) и как параметры соответствия в этих пунктах могут быть интерпретированы, чтобы соответствовать понятиям предприятия. С этой информацией контроллер системы имеет возможность определять в процессе мониторинга, ведет ли система себя правильно. В системе ODP соответствие определяется на основе объявления (установления) контрольных точек, соответствующих инженерным критериям [ITU-T X.903|ИСО/МЭК 10746-3 (разделы 5 — 7)]. И исполнитель, осуществляющий внедрение спецификации предприятия, должен увязать технические ориентиры (цели) для установления взаимосоответствия понятиям предприятия.

11 Правила непротиворечивости

Данный раздел является продолжением ITU-T X.903|ISO/IEC 10746-3 (раздел 10) и определяет семантические проводки спецификации предприятия.

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

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

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

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

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

Существуют два вида требований, относящихся к проводкам:

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

Минимальное требование для обеспечения согласованности в наборе спецификаций в системе ODP — это то, что они отражают проводки, определенные в эталонной модели [Часть 3-10], заданные в этом документе, и те, которые определены в самой спецификации.

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

11.2 Предприятие и информационные проводки для спецификаций

11.2.1 Понятия, связанные с проводками

Понятия, связанные с описанием предприятия:

• сообщество;
• объект предприятия;
• деятельность предприятия;
• роль;
• стратегия;
• нормативный маркер.

Понятия, связанные с информационным обменом:

• информационный объект;
• динамическая схема;
• статическая схема;
• инвариантная (регулярная, постоянная, устойчивая) схема.

11.2.2 Необходимые проводки

Необходимые проводки не определены.

11.2.3 Требуемые операторы (утверждения) проводок

Спецификатор должен предоставить:

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

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

11.3 Предприятие и вычислительные проводки для спецификаций

11.3.1 Понятия, связанные с проводками

Понятия, связанные с описанием предприятия:

• объект предприятия;
• роль;
• проводки предприятия;
• стратегия;
• нормативный маркер.

Понятия, связанные с вычислениями:

• объект вычисления;
• поведение вычисления;
• объект привязки для вычисления;
• вычислительный интерфейс;
• операция;
• поток.

11.3.2 Необходимые проводки

Необходимые проводки не определены.

11.3.3 Требуемые операторы вычислений

Спецификатор должен предоставить:

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

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

11.4 Предприятие и проводки для инженерных спецификаций

11.4.1 Понятия, связанные проводками

Понятия, связанные с описанием предприятия:

• поведение;
• объект предприятия;
• взаимодействие;
• стратегия;
• роль.

Понятия, связанные с инженерными объектами:

• связующий элемент;
• капсула;
• канал;
• группа;
• переключатель;
• узел;
• ядро;
• объект протокола;
• «заглушка».

11.4.2 Необходимые проводки

Необходимые проводки не определены.

11.4.3 Требуемые операторы проводки

Спецификатор должен предоставить:

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

Примечания

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

2 Использование технических типов каналов и «заглушек», связующих элементов или объектов протокола могут быть ограничены стратегией предприятия.

11.5 Предприятие и проводки для технологических спецификаций

Согласно ITU-T X.902)|ИСО/МЭК 10746-2 (подраздел 15.5) и ITU-T X.903)|ИСО/МЭК 10746-3 (подраздел 5.3) для достижения соответствия исполнитель обеспечивает последовательность интерпретаций, которая позволяет контролировать поведение в контрольных точках, установленное в терминах описания предприятий. Одновременно могут быть установлены проводки между стратегией предприятия и технологическими смысловыми диспозициями, ориентированными на использование конкретных технологий, при отсутствии необходимых проводок и объявлений о проводках.

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

(обязательное)

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

Примечания

1 Обозначения, используемые в этой модели, взяты из UML ИСО/МЭК 19505-2:2012.

2 Взаимосвязь (проводка) по соглашению трактуется как: «Каждый (или экземпляр) <класса X> <глагольной фраза или предикат> <количество элементов> <Класс Y>», где предикат описывает роль, которую играет в его отношениях с , и помещается в качестве RoleEndName на конец проводки (в соответствии с правилами UML нотации в ИСО/МЭК 19505-2). Например, на рисунке A.1 проводка, которую «Система ODP» имеет с «назначением», может трактоваться, как: «Каждой системе ODP задано ожидаемое поведение, определенное только для одного назначения». Выбор «каждого» или «экземпляра» будет зависеть от количеств элементов ассоциации.

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

Диаграммы, представляющие эту модель, представлены ниже в нескольких больших рубриках (разделах), охватывающих понятия из раздела 6, а именно:

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

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

В двух частях настоящего приложения приводятся действующие примеры. Данные примеры демонстрируют вариативность в использовании понятий и структурирующих правил, определяющих систему ODP с учетом смысловой диспозиции предприятия [Части 3-4.1].

Объяснения приведены для следующих понятий:

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

В настоящем приложении термины, которые относятся к понятиям, принадлежащим языку спецификации, языку описания предприятия RM-ODP, выделяются курсивом; термины, относящиеся к понятиям, которые принадлежат к сути дискурса (то есть то, что требует уточнения) [часть 2-6] не выделены шрифтом: имена, используемые в спецификации RM-ODP — MS Reference Sans Serif. В некоторых случаях термин, который относится к понятию языка предприятия, также иногда используется в настоящем приложении в его обычном смысле. Когда такой термин используется в обычном смысле, он отображается обычным шрифтом, а не курсивом.

B.1 Первый пример — спецификация предприятия системы электронной коммерции

Первый пример — спецификация предприятия системы электронной коммерции, управляемой e.com, продавцом виджетов.

B.1.1 Спецификация [часть 3-4.2.2]

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

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

B.1.2 Назначение [6.1.2]

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

B.1.3 Система [часть 2-6.5]

Система электронной коммерции, представленная объектом — электронной системой, включает в себя подсистему закупок, подсистему доставки и подсистему администрирования. Такой объект устанавливается в спецификации трех систем: purchasingSubsystem, shippingSubsystem и administrationSubsystem.

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

B.1.4 Назначение [6.1.1]

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

B.1.5 Сообщество [часть 3-5.1.1]

Система электронной коммерции e.com взаимодействует с людьми и другими автоматизированными системами. Когда операция этой электронной коммерческой системы определена в соответствии со смысловой диспозицией предприятия, тогда система и контекст, в котором это работает, определяются как сообщество. Такое сообщество называется электронным сообществом e-commerceCommunity.

В спецификации смысловой диспозиции предприятия системы ODP система электронной коммерции e.com представлена как объект в электронном сообществе e-commerceCommunity. Объект, системный объект электронной коммерции, кратко называется электронной системой (e-system).

Пользователи и автоматизированные системы также устанавливаются как объекты в электронном сообществе e-commerceCommunity.

Система электронной коммерции состоит из составляющих. Чтобы показать взаимодействия составляющих, спецификация описывает электронное сообщество e-commerceCommunity более подробно с помощью электронной системы e-commerce, структурированной на несколько объектов, представляющих ее части.

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

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

B.1.5.1 Объект предприятия [часть 3-4.2.2]

Основными объектами предприятия в спецификации предприятия на e.com являются заказчик, поставщик и виджет.

B.1.5.2 Цель [6.2.1]

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

B.1.5.3 Контракт [часть 2-11.2.1]

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

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

B.1.5.4 Роль [часть 2-9.17]

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

Данная спецификация определяет роли клиента и e.comManager. Поскольку в e.com приветствуется совмещение ролей сотрудников и клиентов, один и тот же объект, представляя менеджера e.com, может выполнить и роли клиента и e.comManager.

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

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

В действии клиента, покупающего фиолетовый виджет, электронный системный объект и потребительский объект являются акторами; объект, представляющий фиолетовый виджет, является артефактом и shippingSubsystem — и актор, и ресурс [представленный в действии объектом сообщества (составным элементом этой подсистемы), который несет ответственность за поставку продукта на более поздней стадии].

B.1.5.5 Роль интерфейса [6.3.5 и 7.8.3]

В спецификации электронная система e-system — это сложный объект. Некоторые компоненты электронной системы выполняют роли в сообществе inventoryMaintenance. Это сообщество взаимодействует с объектами supplierSystem (объекты, выполняющие роль supplierSystem) вне сообщества inventoryMaintenance. Сообщество inventoryMaintenance осуществляет интерфейсные роли. Объекты этого сообщества, которые взаимодействуют с объектами supplierSystem, также выполняют интерфейсные роли.

B.1.5.6 Создание сообщества [7.6.1]

Спецификация данного электронного сообщества e-commerceCommunity включает в себя функцию поведения для создания сообщества типа justInTimeCommunity («одномоментное создание сообщества») с объектом — поставщиком, являющимся поставщиком виджета, который соглашается вести учет виджетов продаваемых e.com и поставить их на склады e.com в соответствии с указаниями по инвентаризации объекта технического обслуживания или объекта inventoryMaintenance. Когда поставщик соглашается сделать это, новое сообщество считается установленным, включая объект поставщика и объект inventoryMaintenance.

B.1.5.7 Стратегия назначения [7.6.2]

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

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

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

B.1.5.8 Отношения между сообществами [7.3.2, 7.8.3]

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

Спецификация предприятия включает в себя описание сообщества, связанное с каждой из подсистем электронной системы с их собственной целью, политикой и т.д. Таким образом, есть сообщество закупок purchasingCommunity, сообщество доставки shippingCommunity, сообщества складского хранения warehouseCommunity и сообщество (бухгалтерского) учета accountingCommunity. Каждая из этих подсистем представляет собой конфигурацию объектов (частей этой подсистемы); каждый из этих объектов исполняет одну или более ролей в соответствующем сообществе. Когда объект исполняет роль в подсистеме warehouseCommunity («товарный склад сообщества»), а именно объект inventoryMaintenance («инвентаризация технического обслуживания»), тогда он взаимодействует с объектом, выполняющим роль supplyPlanning («плановые поставки») в подсистеме purchasingCommunity, посредством предоставления информации для использования в покупательских виджетах, чтобы решать задачу пополнения запасов инвентаря, — это называется взаимодействием между подсистемами warehouseCommunity и purchasingCommunity.

Когда объект действует в роли inventoryMaintenance («инвентаризация технического обслуживания») в warehouseCommunity («товарный склад сообщества») и этот же объект также исполняет роль assetReporter («учет активов») в сообществе учета accountingCommunity, предоставляя информацию для использования в ежедневном бухгалтерском учете активов, который тот объект получает, исполняя роль inventoryMaintenance («инвентаризация технического обслуживания»), тогда это и есть взаимодействие между warehouseCommunity («товарный склад сообщества») и accountingCommunity.

Электронная система e-system может содержать объект, предназначение которого контролировать деловую активность, имеющую место в сообществе e-commerceCommunity. Этот объект может обработать данные, которые он собирает, и предоставить отчет о предпочтительном рейтинге поставщика и рейтинге активного покупателя. Есть также и подсистема ratingServiceCommunity («служба оценки»). Этими двумя сообществами управляют независимо, но имеет место обмен информацией. С этой целью сообщество e-commerceCommunity определяет интерфейсную роль, выполняемую объектом-наблюдателем, который обеспечивает локальное ранжирование информации и получает информацию по всей совокупности ранжирования. Сообщество ratingServiceCommunity определяет интерфейсную роль, выполняемую объектом в этом сообществе, которое получает данные о ранжировании по данной компании и предоставляет информацию по всей совокупности ранжирования. Эти две интерфейсных роли позволяют реализовать взаимодействие между сообществами.

Электронная система e-system (как объект сообщества) обязана следовать правилам сообщества supplyCommunity.

В дополнение к необходимости следовать собственной отдельной стратегии (правилам сообщества) все объекты сообщества, представляющие различные подсистемы электронной системы e-system (purchasingCommunity, shippingCommunity, warehouseCommunity и т.д.), обязаны следовать стратегии электронной системы e-system.

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

Объект-наблюдатель следует стратегии сообщества e-commerceCommunity и стратегии сообщества информационного обмена, состоящего из монитора (наблюдателя) и объекта в интерфейсной роли сообщества ratingServiceCommunity.

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

B.1.5.9 Область [часть 2-10.3]

Части системы электронной коммерции the e-commerce system находятся под контролем сервиса e.com. Другие области (домены) этой системы включают в себя:

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

B.1.5.10 Федерация [часть 3-5.1.2]

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

Объекты сообщества e-commerceCommunity не все действуют под общим управлением. Системы поставщика находятся под административным контролем каждого из поставщиков. Есть несколько непосредственно видимых «областей», например e.com домен и домен пользователя IT систем. В пределах самой электронной системы есть также области, которые управляются отдельно. Все объекты в электронной системе расположены в отдельном домене securityDomain с доменом назначения параметров безопасности для взаимосвязей (проводок) subjectToSecurityPolicySetBy и управляющим объектом securitySubsystem. Объекты же подсистем purchasingSubsystem и shippingSubsystem размещены в домене управления стратегиями вместе с доменом присвоения параметров отношений setsPoliciesFor и доменом управления объектом fulfillmentDivisionExecutive, в то время как объекты securitySubsystem размещены в различных доменах стратегий с управляющим объектом CIO.

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

B.1.6 Поведение [часть 2-8.7]

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

B.1.6.1 Действие [часть 2-8.3]

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

B.1.6.2 Процесс [6.3.6]

Спецификация сообщества inventoryMaintenance включает в себя спецификацию процесса reorderProcess. Этот процесс задействует объекты orderPlacer (размещение инвентаря), ресивер (приемка инвентаря) и inventoryKeeper (журнал инвентаризации), а также инициирует роль поставщика. Один шаг в этом процессе — действие, в рамках которого orderPlacer размещает заказ. Процесс размещения заказа продолжается таким же образом для любого объекта supplierSystem при выполнении роли поставщика.

Для обработки товаров при завершении процедуры их получения в спецификацию для роли сообщества inventoryMaintenance включена спецификация процесса receivingProcess. Этот процесс реализует разветвляющееся действие. После разветвления в одной цепи inventoryKeeper регулирует инвентарь, в другой цепи orderPlacer регулирует выдачу заказов. Шаги этих двух цепей выполняются как совместное действие; и это сопровождается шагами, завершающими процесс receivingProcess.

B.1.6.3 Нарушение [6.3.8 и 7.8.6]

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

Например, заказ принят до 16:00 часов, но заказанные виджеты, которые находятся в запасе (на складе), но не намечены для отгрузки во время принятия этого заказа, не являются намеченными для отгрузки в тот же самый день. Такое поведение подсистемы shippingSubsystem является нарушением правила, упомянутого в B.1.7.3 (далее по тексту), которое обязывает shippingSubsystem намечать такие поставки в тот же день.

B.1.7 Обязательные понятия

B.1.7.1 Обязательные маркеры

Многие примеры, приведенные выше, включают в себя действия, которые присвоены маркерам разрешения, запрета или обязательства. Например, действие orderWidget (заказ виджета) включает в себя и разрешения, и обязательства; так определено, чтобы быть речевым актом, и электронный системный объект должен получить нормативный маркер разрешения, прежде чем он сможет участвовать в действии в роли приемщика заказов (orderTaker). Выполнение действия приводит к созданию деонтического маркера обременения, выражающего обязательство поставить фиолетовый виджет. Первоначально это осуществляется объектом в роли orderTaker, но он может быть передан как форме последующего делегирования подсистеме shippingSubsystem. Другое обременение в форме обязательства по осуществлению платежа создается действием объекта-поставщика.

B.1.7.2 Разрешение [6.6, 7.8.8.4]

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

B.1.7.3 Обязательство [часть 2-11.2.4]

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

B.1.7.4 Разрешение [часть 2-11.2.5]

Спецификация предприятия включает в себя правила о том, что определенные подсистемы могут установить связь с объектами вне домена безопасности e.com. Эти правила суть разрешения и представляются в форме деонтического маркера разрешения.

Спецификация предприятия предопределяет, что объекты в роли orderPlacer (размещение заказа) имеют разрешение установить связь с объектами вне домена безопасности e.com. Объект в роли orderPlacer инициирует установление связи с объектом, представляющим конкретного поставщика. Подсистема безопасности securitySubsystem препятствует установлению этой коммуникации по причине наличия временного специального запрета, представленного как нормативный маркер запрещения (эмбарго) на основании наличия связи (проводки) с этим объектом-поставщиком supplierSystem, потому что в этот момент есть признаки постороннего управления, что инициирует отказ в обслуживании на e.com. Этот случай не является нарушением разрешения для объекта orderPlacer.

B.1.7.5 Запрет [часть 2-11.2.6]

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

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

B.1.8 Стратегия [часть 2-11.2.8, 6.5]

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

B.1.9 Ответственность [6.6 и 7.10]

Если клиент совершает покупку в системе электронной коммерции, то это устанавливается в спецификации предприятия как действие объекта, представляющего этого клиента.

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

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

B.1.9.1 Сторона [6.6.1 и 7.10.1]

Объекты, представляющие людей, и объекты, представляющие e.com и другие фирмы, являются сторонами.

B.1.9.2 Обязательство [6.6.2 и 7.10.3]

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

B.1.9.3 Декларация [6.6.5 и 7.10.4]

У системы e.com есть соглашение с клиентами, которое обеспечивает что, если заказ отменен в течение 24 ч после запланированной даты отправки, у e.com есть право на пополнение запасов в размере 5% суммы счета-фактуры для отмененного заказа.

Система электронной коммерции запрограммирована, чтобы выставлять эту претензию автоматически в отношении клиента, у которого есть дебиторская задолженность перед e.com с задержкой по оплате в более чем 60 дней. Отмена заказа фирмой F устанавливается в спецификации как последовательность действий, отменить, объектом, фирма F, связь с другим объектом, заказ. Действие электронной системы, формирующее запрос на пополнение запасов, когда заказ отменен фирмой F, называется декларацией. Это действие устанавливает исполнительский порядок в среде электронной системы: фирма F обязана покрыть расходы e.com.

B.1.9.4 Делегирование и авторизация [6.6.4, 6.6.6, 7.10.1 и 7.10.2]

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

B.1.9.5 Агент и руководитель (принципал) [6.6.8, 6.6.9 и 7.10]

В спецификации предприятия e.com представлен как объект. Лицо, действующее в качестве главного финансового директора (CFO) из e.com, устанавливает для системы электронной коммерции цены на компьютерные системы клиентов (в том числе веб-браузеров и систем закупок), эти цены определяются финансовым директором и вводятся в систему электронной коммерции e-commerce system.

Это урегулирование предлагаемых цен представлено как действие стороны — финансового директора CFO. CFO может делегировать системе электронной коммерции разрешение на установку цены в вечернее время и выходные дни. Финансовый директор может также делегировать разрешение системе делегировать это разрешение независимому агенту в рамках объединенной службы ценоопределения в определенных случаях. Электронная система выступает в качестве агента финансового директора, и финансовый директор — в качестве руководителя (принципала) электронной системы. Авторизация pricingServiceP (объединенная служба ценоопределения) в системе e-system делегирует статус агента финансового директора CFO, а финансовый директор становится принципалом pricingServiceP. По представлению CFO соответствующие разрешения, запреты и обременения клонируются и передаются агенту pricingServiceP как часть делегированного речевого акта.

В другой спецификации предприятия e.com может исполнять роль агента, который делегирует электронной системе e-system разрешение на установление цены в вечернее время и выходные дни. Агент e.com может также делегировать разрешение на последующее делегирование этого разрешения службе pricingServiceP. В этом случае e-system — агент e.com, e.com — принципал электронной системы e-system. Если эти полномочия делегированы электронной системой службе pricingServiceP, то pricingServiceP — агент e.com, e.com — принципал pricingServiceP.

В ином случае другая система ODP предоставляет службу электронной коммерции e-commerce service, которую поставщик сервиса приложений предлагает другим фирмам. Каждая фирма, использующая эту систему, определяется в спецификации этой системы как объект в ролевой фирме.

Спецификация предприятия этой системы электронной коммерции e-commerce service предоставляет инструменты для делегирования разрешения по установлению цен. Если e.com использует эту услугу, во время работы этой системы объект (e.com), исполняя роль фирмы, может делегировать полномочия по установлению цены объекту pricingManager (роль объекта, представляющего лицо в фирме, имеющее разрешение, устанавливать цены). В вопросе установления цен объект pricingManager является агентом e.com.

Если pricingService изменяет offeringPrice, это действие — модель того, что происходит в мире электронной коммерции. То, что происходит, есть новый статус системы: e.com формирует предложение о продаже по измененной цене.

В полностью автоматической системе электронной коммерции e-commerce system спецификация предприятия обеспечивает такое поведение, когда регистрация измененного ценового объекта агентом e.com (например, pricingService) формирует предложение e.com о продаже по обозначенной цене. В этом случае влияние действий со стороны pricingService на изменение цены заключается в следующем: агент e.com делает предложение и стремится продать по цене, указанной для клиента, принявшего это предложение, прежде чем оно будет снято. (Это — пример спецификации для ситуации в торговом мире, точно ее отображающий: воздействие проводки общих расценок на услуги по изменению цены заключается в следующем: e.com делает предложение и стремится продать по цене клиенту, принявшему ценовое предложение прежде, чем предложение будет изъято).

Это предложение (регистрация измененного ценового объекта) является действием агента e.com, за которое e.com несет ответственность. В этом случае действие — это обязательство, поскольку агент e.com обязан продать по этой цене, если предложение принято.

Так как система электронной коммерции — полностью автоматическая система, работающая в Интернете, принятие предложения продать будет передано системе электронной коммерции с использованием программного обеспечения по Интернету, возможно, через веб-браузер. В спецификации предприятия, которая включает в себя клиентов и их системы, WebBrowser — агент объекта в роли клиента, который представляет интересы клиента (веб-браузер действует в интересах клиента, отправляя сообщение о заказе, когда пользователь нажимает на кнопку «Купить»).

Части системы ODP могут быть определены тем же самым способом. В пределах pricingService объект, priceSelector, может делегировать текущий анализ рынка одному или другому marketAnalysisSubsystem в зависимости от типа продукта.

B.1.9.6 Оценка [6.6.7 и 7.10]

Для пополнения инвентаря система электронной коммерции готовит запросы о предложениях и передает их поставщикам виджета. Когда предложения получены, агент по закупкам e-com определяет, какое(ие) предложение(ия) принять. Решение учитывает стоимость каждой заявки, подготовленной системой электронной коммерции. Система электронной коммерции назначает относительный статус каждой заявке согласно алгоритму, который проводит оценку ценности этого предложения, используя не только цену, но также и предлагаемые сроки поставки, записи о предыдущих своевременных поставках и отчеты актов осмотра качества виджетов этого поставщика. Данное назначение статуса — это оценка заявки электронной системой.

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

B.1.9.7 Предписание [6.6.3 и 7.10.5]

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

B.2 Второй пример — Спецификация библиотеки

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

Этот пример основан на описании университетской библиотеки, на инструкциях, которые управляют процессом заимствования книг в библиотеке. Вместо общей и абстрактной систем это пример, основанный на правилах, определенных для библиотеки Темплман в Университете Кента в Кентербери; система, которая ранее использовалась различными авторами для иллюстрирования некоторых понятий ODP. Правила, которые управляют процессом заимствования этой библиотечной системы, следующие:

• права брать книги даны всему преподавательскому составу и аспирантам, и студентам бакалавриата университета;
• есть предписанные сроки для получения книг и ограничения по количеству экземпляров, которые можно брать отдельному лицу в любой момент времени. Эти ограничения следующие:
• студенты могут взять восемь книг. Они не могут брать периодические издания. Книги могут быть взяты на четыре недели;
• аспиранты могут взять 16 книг или периодические издания. Периодические издания могут быть взяты на одну неделю. Книги могут быть взяты на 1 месяц;
• преподавательский состав может брать 24 книги или периодические издания. Периодические издания могут быть взяты на одну неделю. Книги могут быть взяты максимум на 1 год;
• взятые книги должны быть возвращены в заданное время в указанную дату;
• заемщики, которые не возвращают взятые издания вовремя, могут быть оштрафованы соразмерно ставкам, определенным для отдельных изданий, на момент возврата печатного издания в библиотеку;
• отказ заплатить штраф может привести к приостановке библиотекарем права получения книг.

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

B.2.1 Спецификация предприятия

Четыре ключевых понятия языка описания предприятия следующие: система, назначение, спецификация предприятия и область применения. Следующие моменты в настоящем пункте описывают эти четыре понятия. B.2.2, B.2.3 содержат описание элементов, которые составляют спецификацию предприятия системы: сообщества и поведение. В B.2.4 вводятся нормативные понятия, и B.2.5 связан со стратегиями. B.2.6 концентрируется на понятиях ответственности.

B.2.1.1 Система

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

B.2.1.2 Назначение [6.1.1]

Назначение библиотечной системы описывается через ожидаемое поведение, т.е. способ, который, как предполагается, работает, с точки зрения ролей (см. пункт B.2.2.4) или процессов (B.2.3.2), или обеих составляющих, с точки зрения стратегий (B.2.5) и их отношений. Все эти элементы описаны ниже.

B.2.1.3 Спецификация предприятия [часть 3-4.2.2]

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

B.2.1.4 Назначение

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

B.2.2 Сообщество

B.2.2.1 Сообщество [часть 3-5.1.1]

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

B.2.2.2 Цель [6.2.1]

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

B.2.2.3 Контракт [часть 2-11.2.1]

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

B.2.2.4 Роль [часть 2-9.17]

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

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

B.2.2.5 Объект предприятия

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

Библиотека может также быть представлена как объект; например, это может резюмироваться как объект сообщества, который может исполнить роль в другом сообществе (см. B.2.2.8).

B.2.2.6 Жизненный цикл сообщества [7.6]

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

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

B.2.2.7 Правила назначения [7.6.2]

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

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

B.2.2.8 Отношения между сообществами

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

Примеры:

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

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

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

3 Объект выполняет роли в двух сообществах. До сих пор мы рассматривали библиотеку в изоляции, но на практике она тесно связана с университетом, который обслуживает. В университетском сообществе мы находим такие роли, как студент, исследователь, преподаватель, директор департамента headOfDepartment, помощник supportStaffMember и т.д. Эти роли исполняются объектами, представляющими лиц, чьи объекты могут в некоторый момент также исполнить роль пользователя в сообществе libraryCommunity. Таким образом, тот же самый объект предприятия (в этом случае, представляя человека) может выполнять роли в различных сообществах. Чтобы исполнить роль пользователя библиотеки, объект предприятия должен исполнять соответствующую роль в университете.

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

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

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

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

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

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

B.2.3 Поведение

B.2.3.1 Действие

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

• пользователь получает экземпляр с разрешения библиотекаря;
• пользователь возвращает взятый экземпляр библиотекарю;
• библиотекарь штрафует пользователя;
• оштрафованный пользователь платит свой штраф библиотекарю;
• библиотекарь временно блокирует доступ пользователя в случае опоздания с оплатой штрафа.

B.2.3.2 Процесс и шаг [6.3.6 и 6.3.7]

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

• пользователь получает экземпляр;
• до истечения срока пользователь возвращает взятый экземпляр.

Этот процесс определяет заказ, шаги которого должны быть выполнены и привести к цели системы библиотеки: «чтобы разделить коллекцию печатных экземпляров среди членов университета».

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

B.2.3.3 Объект Предприятия и действие

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

B.2.3.4 Роль Интерфейса

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

B.2.4 Нормативные понятия

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

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

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

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

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

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

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

2. студенту запрещено брать периодические издания (журналы);

3. любому пользователю разрешают взять экземпляр издания на установленный период времени. Период зависит от типа пользователя и вида взятого экземпляра издания;

4. любой заемщик обязан возвратить взятые им экземпляры до истечения срока;

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

6. любой оштрафованный пользователь обязан заплатить штраф;

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

Примечания

1 В этих правилах есть некоторые неуказанные детали, например, когда действия после нарушения выполнены (что может быть выражено как «может привести к» в правиле 7), или точная сумма штрафов. Правило 7 также уполномочивает библиотекаря приостанавливать запоздалого плательщика, но не определяет момент действия; библиотекарь не может отстранить пользователя окончательно (или действие приостановки не может быть отсрочено без срока давности). Это вопрос дальнейшей доработки этой спецификации, чтобы доопределить оставшиеся открытыми детали.

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

B.2.5 Стратегия [часть 2-11.2.8 и 6.5]

Первые три правила, приведенные выше, с большой вероятностью подвергнутся изменениям по решению управления библиотекой, поэтому они определены как стратегия. Первое, например, является декларацией стратегии установления пределов на заимствование. Она определяет как нарушенное поведение действия по заимствованию, которое проверяется на соответствие трем числовым ограничениям и является стратегической стоимостью для этой стратегии. Стоимости могут быть изменены стратегическим поведением урегулирования setBorrowingLimits, выполненным библиотекарем. Однако стратегический набор значений должен быть совместим со стратегическим конвертом в декларации, которая определяет то, что новая стоимость должна быть множеством трех неотрицательных целых чисел. Аналогично правило 2 определяет стратегию периодичности заимствований, правило 3 - стратегию продолжительности заимствований.

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

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

B.2.6 Ответственность [6.6 и 7.10]

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

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

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

B.2.6.1 Сторона [6.6.1 и 7.10]

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

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

B.2.6.2 Обязательство [6.6.2 и 7.10.3]

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

B.2.6.3 Декларация [6.6.5 и 7.10.4]

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

B.2.6.4 Делегирование и авторизация [6.6.4, 6.6.6, 7.10.1 и 7.10.2]

Пользователь может делегировать другому человеку право возвратить одолженную книгу.

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

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

B.2.6.5 Агент и руководитель (принципал) [6.6.8, 6.6.9 и 7.10]

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

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

B.2.6.6 Предписание [6.6.3 и 7.10.5]

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

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

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

• не находятся в противоречии с существующими правилами;
• предложены членами библиотеки;
• приняты на годовом собрании библиотеки большинством голосов.

Действие представления нового правила является предписанием.

(справочное)

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

C.1 Семантика для основного поведения

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

a) совокупность государств S;

b) совокупность действий A;

c) совокупность отношений перехода T_{a} \in S \cdot S , одно соотношение для каждого a \in A ;

d) начальное состояние S_{o} \in S .

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

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

C.2 Структуры (фреймы) и маркировки

Модель Kripke реализует более общий поход для выражения свойств совокупности приемлемых поведений. Основные компоненты модели:

a) совокупность сообществ W, описанных в терминах произвольного множества логических переменных;

b) отношение достижимости R на совокупности членов W, которое является бинарным отношением, указывающим, может ли одно сообщество быть получено из другого (т.е. преобразоваться в иную совокупность);

c) отношение соответствия между членами W и паттерны намеченного поведения.

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

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

C.3 Вычисление полезности допустимых планов действий

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

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

C.4 Использование утилиты приоритизации возможных поведений

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

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

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

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ISO/IEC 10746-2:2010	-	<*>
ISO/IEC 10746-3:2010	-	<*>
ISO/IEC 10746-4:1998	-	<*>
ISO/IEC 19793:2012	-	<*>
ISO/IEC 19505-2:2012	-	<*>
<*> Соответствующий национальный стандарт отсутствует.

---