Корпоративные архитектуры

Политика сервиса ServicePolicy

Простыми словами

ServicePolicy (политика сервиса) — ограничение, управляющее использованием одного или нескольких сервисов. Текст определения отличается от ServiceContract одной буквой в последнем слове, поэтому опираться надо на схему: политика связана с Service напрямую парой ролей policy и constrainedService, обе со звёздочкой, тогда как контракт крепится через кортеж GovernedBy. Смысл вида, где политика работает, стандарт формулирует конкретнее самого определения: Services Constraints задуман для традиционных текстовых политик сервиса, ограничивающих способ реализации спецификаций сервисов внутри ресурсов, а добавление параметрики SysML даёт вычислимый способ задавать политики. Отсюда и второй вид — Services Taxonomy, где политика стоит рядом с сервисом. Ошибка — писать в политику функциональные требования: для них есть Requirement и мотивационные элементы.

Примеры

Прямая связь с сервисом

На схеме от ServicePolicy к Service идут роли policy и constrainedService, обе с кратностью «много». Никакого промежуточного кортежа, в отличие от ServiceContract с его GovernedBy, здесь нет.

UAF DMM 1.3, разд. 9.1.5, рис. 9-144 — роли policy и constrainedService

От текста к вычислимому ограничению

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

UAF DMM 1.3, разд. 8.1.5 — определение вида Services Constraints

Ошибка в подписи к рисунку

Схема ServicePolicy подписана как рис. 9-144 ServiceFunctionAction — именем элемента из другого аспекта, чья настоящая схема имеет номер 9-138. Сама схема при этом верна: на ней ServicePolicy, Rule и Service.

UAF DMM 1.3, разд. 9.1.5 — подпись под схемой ServicePolicy и подпись рис. 9-138 у ServiceFunctionAction