Comments 9
Поразительно, про КорсАкова. Вопрос и про примерные годы жизни «пионера применения перфорированных карт в информатике» поставил коллег в тупик.
А какие-то примеры интерфейсов настройки правил можете привести? Был опыт разработки дисконтных систем, которые решают очень похожие задачи. Сделать простой понятный и удобный интерфейс настройки оказалось самой большой проблемой. Наиболее тяжелыми и бесплодными были попытки объединить в интерфейсе правила начисления скидок и бонусов хоть какой-то общей логикой.
Наиболее распространенные интерфейсы для создания правил:
— Таблицы. Сначала идут колонки, в которых перечисляются входные параметры, а затем соответствующие им выводы.
— Естественный текст «если, то» с использованием подготовленного разработчиками словаря предметной области. Например, «Если приобретается больше 10 билетов и срок покупки более чем за 20 дней, то скидка составляет 10%».
— Традиционные блок-схемы. В них задаются комбинации условий и действий по каждому из сработавших условий. В качестве действий могут выступать другие правила. Таким образом, элементарные правила могут быть скомбинированы в сколько угодно сложные.
В качестве иллюстрации:
— Таблицы. Сначала идут колонки, в которых перечисляются входные параметры, а затем соответствующие им выводы.
— Естественный текст «если, то» с использованием подготовленного разработчиками словаря предметной области. Например, «Если приобретается больше 10 билетов и срок покупки более чем за 20 дней, то скидка составляет 10%».
— Традиционные блок-схемы. В них задаются комбинации условий и действий по каждому из сработавших условий. В качестве действий могут выступать другие правила. Таким образом, элементарные правила могут быть скомбинированы в сколько угодно сложные.
В качестве иллюстрации:
Кстати, по опыту разработки тех же дисконтных систем, конечные пользователи разделились в своих желаниях на два лагеря:
Первые хотели чтобы можно было все мышкой настроить, и так чтобы было понятно далекому от IT человеку.
Вторая часть твердо стояла на том, что лучший способ сделать самые изощренные сценарии — это скрипты.
Первые хотели чтобы можно было все мышкой настроить, и так чтобы было понятно далекому от IT человеку.
Вторая часть твердо стояла на том, что лучший способ сделать самые изощренные сценарии — это скрипты.
А не бывало таких ситуаций, что за годы работы будет сгенерировано такое количество правил и действий, что разобраться что в итоге получается будет очень сложно? Т.е. проблема будет сродни тому же развесистому коду.
Можно ли как-то структурировать большие сценарии чтобы четко понимать — ага, этот блок уже актуален, мы его выкинем, а все остальное будет работать как и прежде.
Можно ли как-то структурировать большие сценарии чтобы четко понимать — ага, этот блок уже актуален, мы его выкинем, а все остальное будет работать как и прежде.
Да, безусловно, можно суметь за несколько лет довести и правила до нечитаемого состояния.
Поэтому нужно структурировать и периодически выкидывать неактуальное. Плюс есть штатная возможность версионирования набора правил. Мы можем указать, что новая версия правил действует с определенной даты в будущем, а пока действует старая. Это позволяет переходить с версии на версию без нагромождения лишних ветвлений в правилах.
Поэтому нужно структурировать и периодически выкидывать неактуальное. Плюс есть штатная возможность версионирования набора правил. Мы можем указать, что новая версия правил действует с определенной даты в будущем, а пока действует старая. Это позволяет переходить с версии на версию без нагромождения лишних ветвлений в правилах.
Спасибо за интересную тему для изучения! Очень вовремя.
Sign up to leave a comment.
BRMS 150 лет назад и сегодня: репозитории правил принятия решений