Форум Сообщества Аналитиков

×


Проектирование правил в Business Rules Management System(Прочитано 9365 раз)
Здравствуйте!
Есть потребность в создании системы, сохраняющей разнообразные бизнес-правила и использующей эти правила для пересылки сообщений.
Правила будут задаваться уже не разработчиками, а людьми, более знакомыми с бизнесом.
Можете подсказать, встречались ли вы в такими системами и есть ли примеры  удачного описания этих правил?
Сейчас думаем по какому пути идти: задавать правила текстом, для примера
if client.total_price > 1000
   send e-mail  to client(...)
Либо использовать графический редактор для построения блок-схем, но тут вопрос далеко не однозначный, так как произвольные блок-схемы не каждая система может обработать.
Посмотрел документы от OMG, но, хотелось бы реальных примеров.



Добрый вечер.

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

Почему отказались от использования обычного UI с привычными контролами? Пошаговый мастер, где можно задать условия рассылки (if client.total_price > 1000) и результаты (send e-mail  to client) простым выбором из готовых вариантов с полями ввода?



Да мы и не отказываемся от UI, просто хотим выбрать путь ;D. Контролы - это конечно хорошо, но, одна из распространенных BRMS-библиотек представляет собой текстовый язык (я имею в виду Drools). К тому же некоторые условия тяжело задать графически, особенно, если наложены определенные условия (пример: события должно произойти 5 раз и после этого еще проверить данные клиента в другой системе, после этого действие может продолжаться). Поэтому если переформулировать мой вопрос:
1) Если представлять данные графически, какой бы вы стандарт порекомендовали для определения диаграмм в BRMS системе.
2) Если у кого-нить есть примеры определения BRMS в других системах, то я был бы очень благодарен, если бы вы привели эти примеры.



Можно скомбинировать подход: Простые правила с помощью графики, сложные текстом. 80% условий будет простыми, для остальных 20% можно чела и в текст загнать...
Посмотрите, как сделана выборка по задачам в Жире
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



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

Удачного - в смысле, сдали систему и не пришлось прятаться от разгневанного Заказчика? :)
Примеры есть.

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

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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19