По нему можно быстро идентифицировать к какому типу относится конкретное Бизнес правило, и затем в книге найти способ его реализации.
Бизнес Правила(БП) можно разделить:
- Правила отвечающие состояниям системы
- Правила отвечающие за изменение сотояний системы
- Правила Авторизации
- автоматические тригеры, запускающие определенные действия при изменении состояния системы.
UML концепции БП:
- Инварианты - ограничения определяющие систему в стабильных состояниях. Обычно включаются в UML модель классов
- Предусловия - условия которые должны быть выполнены, для возможности перехода из одного состояния системы в другое. Обычно описываются в use-case диаграммах
- Постусловия - условия которые должны быть выполнены после перехода системы в новое состояние. Обычно описываются в use-case диаграммах
автоматические действия не являются бизнес правилами.
В книге рассмотрены такие БП:
- Constraint - ограничения на состояние системы и на переход из одного состояния в другое
- Change Event - определяют действия запускаемые при определенных условиях. (Пример: при определенном условии напечатать отчет или послать имеил)
- Authorization - ограничения связанные с авторизацией
Constraint rules:
Описывают ограничения на состояние системы и на переход из одного состояния в другое. Соответствуют UML инвариантам и UML пред условиям.
Constraint rules делят по обьектам к которым они относятся:
- Attribute - правило для конкретного атрибута одного обьекта
- Instance - правило для нескольких атрибутов одного обьекта
- Entity - правило для нескольких обьектов одного типа ентити
- MultyEntity - правило для более одного обьекта разных типов сущностей
Attribute:
- Attribute properties - ограничивает состояние атрибута:
- Type - ограничение по типу атрибута (Пример: Departament должен быть Numeric)
- Mandatory - определяет является ли атрибут обязательным
- Updateble - определяет можно ли атрибут менять (Пример: OrderLine нельзя назначить другому Order (OrderLine.OrderId not Updateble)
- Domain - позволяет задать свой тип даных для атрибута (Пример: Поле YesNo может принимать значения либо "Y", либо "N")
- Validation:
- Compare (Пример: Зарплата сотрудника должна быть больше 0)
- List (Пример: состояние сотрудника должно быть одним из списка "S" (Single), "M" (Married), "D" (Divorced), "W" (Widowed) или null)
- Renge (Пример: бюджет должен находится в пределах от 10 000 до 100 000)
- Length (Пример: Код страны должен состоять из 2-х символов)
- Regular (Пример: Почтовый код должен иметь формат **-**)
- Method (Пример: состояние сотрудника может меняться только по правилам: divorced, widowed -> married; married -> divorced, widowed; null -> any value; any value -> null)
Instance:
- Instance Validator - реализуется с помощью метода в классе ентити или с помощью отдельного класа. (Пример1 : Рабочий который числится как "SALESMAN" обязательно должен иметь заполненное поле с комиссией) (Пример2: Нельзя изменять Rate, Role или PercentageAllocated для ProjectAssignment если он активен. (Закройте активный ProjectAssignment и создайте новый) (Пример3: Дата начала должна быть меньше даты конца)
- Delete Rules - запрещает удалять запись при определенных условиях (пример: Вы не можете удалять Заказ после доставки)
Entity:
- Unique Identifier - параметр среди всех обьектов данного типа ентити должен быть уникальным (Пример: название департамента должно быть уникально)
- Collection, no parent - ограничение относится к коллекции обьектов но не к родителю этой коллекции (Пример: В системе не может быть больше 20 департаментов)
- Other Entity - все остальные ограничения относящиеся к набору обьектов одного типа ентити
Multi Entity
- Association - описывает как классы ентити зависят друг от друга (Пример: каждый OrderLine должен иметь один и только один order) (Пример2: каждый сотрудник работает только в одном департаменте)
- Collection within Master(Parent) - ограничение касается коллекции и ее родителя (Пример: в департаменте должно быть не более одного работника-клерка)
- Simple Multi Entity - включают правила которые связаны с различными типами ентити, но которые применяются только к одному енити. (пример: вы не можете создать проектное задание потому что проект закрыт (дата проекта в прошлом))
- Complex Multi Entity - правила которые затрагивают много ентити и относятся также ко многим ентити.(пример: начальная дата проектного задания, должна попадать в диапазон даты начала и конца проекта)
Change Event rules:
Автоматические действия срабатываемые при изменении состояния системы
DML (Data Manipulation) - означают события связанные с операциями Create, Update, Delete
Change Event rules делят:
- Change Event rules with DML - связаные с опреацыями Create, Update, Delete
- Change Event rules without DML - не связаные с опреацыями Create, Update, Delete
Change Event rules with DML
- Default - Правила описывают какое значение должно принять поле в случае операции Create
- Literal (Пример: По умолчанию после создания записи поле count должно содержать значение 1)
- Calculated (Пример: При создании записи генерить Id на основании последовательности из БД)
- Change History Rules - запись в обьект информации о том когда и кем он был создан или модифицирован
- Other Derivaion Rules - При создании или изменении обьекта пересчитать значение атрибута (Пример: при записи переcчитывать значение totalPrice)
- Cascade Delete Rules - Удаление потомков при удалении родителя
- Other - все остальные правила не вошедшие в описанные выше случаи. (Пример1: Если изменилась дата начала проекта, то нужно изменить все даты начала проектных задач, которые получаются раньше новой даты начала проекта) (Пример2: если изменилось значение зарплаты или комиссии сотрудника, записать соответствующее сообщение в журнал)
Change Event rules without DML
Автоматический триггер отслеживающий изменение системы не связанное с опреациями Create, Update, Delete (Пример: послать email сообщение менеджеру когда изменится дата окончания проектной задачи
