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

Правило Rule

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

Абстрактный корень всех ограничений UAF. Потомки идут по доменам: OperationalConstraint, ServiceConstraint, ResourceConstraint, StrategicConstraint и ограничение безопасности. Разряд правила задаётся перечислением RuleKind с восемью значениями — StructuralAssertion, ActionAssertion, Derivation, Contract, Constraint, Guidance, SecurityPolicy, Caveat, — и это стоит знать: под словом ограничение в UAF прячутся и договор, и руководящее указание, и политика безопасности, и оговорка. Родитель один, MeasurableElement, поэтому правило измеримо. В аспекте Constraints сетки UAF правила стоят рядом с измерениями, задающими требования к производительности. Показывается в трёх видах ограничений — операционном, сервисном и ресурсном. Ошибка — заводить Rule напрямую: он абстрактен, и правило всегда принадлежит домену, чей предмет оно ограничивает.

Примеры

Определение с примером

Карточка говорит «An abstract type for all types of constraint (i.e. an OperationalConstraint could detail the rules of accountancy best practice).» Пример показывает, что правило может быть внешним по отношению к архитектуре — отраслевой практикой.

UAF DMM 1.3, разд. 9.1.1, пакет Constraints — Description карточки Rule

Восемь разрядов правила

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

UAF DMM 1.3, разд. 9.1.3, рис. 9-89 — StrategicConstraint и перечисление RuleKind

Что говорит про правила сетка

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

UAF DMM 1.3, разд. 7.1 — таблица определений аспектов, строка Constraints