Pull to refresh

Comments 9

Поразительно, про КорсАкова. Вопрос и про примерные годы жизни «пионера применения перфорированных карт в информатике» поставил коллег в тупик.
А какие-то примеры интерфейсов настройки правил можете привести? Был опыт разработки дисконтных систем, которые решают очень похожие задачи. Сделать простой понятный и удобный интерфейс настройки оказалось самой большой проблемой. Наиболее тяжелыми и бесплодными были попытки объединить в интерфейсе правила начисления скидок и бонусов хоть какой-то общей логикой.
Наиболее распространенные интерфейсы для создания правил:
— Таблицы. Сначала идут колонки, в которых перечисляются входные параметры, а затем соответствующие им выводы.
— Естественный текст «если, то» с использованием подготовленного разработчиками словаря предметной области. Например, «Если приобретается больше 10 билетов и срок покупки более чем за 20 дней, то скидка составляет 10%».
— Традиционные блок-схемы. В них задаются комбинации условий и действий по каждому из сработавших условий. В качестве действий могут выступать другие правила. Таким образом, элементарные правила могут быть скомбинированы в сколько угодно сложные.

В качестве иллюстрации:
Спасибо, аналогичные варианты рассматривали. А есть какая-то система разруливания противоречий или приоритетов между разными сценариями? И как она настраивается.
Вопрос разруливания противоречий и приоритетов решается также заданием соответствующих правил. Т.е. можно описать любую бизнес-логику определения приоритетов. Кстати, логические противоречия в правилах BRMS системы обычно ловят на этапе компиляции.
Кстати, по опыту разработки тех же дисконтных систем, конечные пользователи разделились в своих желаниях на два лагеря:
Первые хотели чтобы можно было все мышкой настроить, и так чтобы было понятно далекому от IT человеку.
Вторая часть твердо стояла на том, что лучший способ сделать самые изощренные сценарии — это скрипты.
А не бывало таких ситуаций, что за годы работы будет сгенерировано такое количество правил и действий, что разобраться что в итоге получается будет очень сложно? Т.е. проблема будет сродни тому же развесистому коду.
Можно ли как-то структурировать большие сценарии чтобы четко понимать — ага, этот блок уже актуален, мы его выкинем, а все остальное будет работать как и прежде.
Да, безусловно, можно суметь за несколько лет довести и правила до нечитаемого состояния.
Поэтому нужно структурировать и периодически выкидывать неактуальное. Плюс есть штатная возможность версионирования набора правил. Мы можем указать, что новая версия правил действует с определенной даты в будущем, а пока действует старая. Это позволяет переходить с версии на версию без нагромождения лишних ветвлений в правилах.
Спасибо за интересную тему для изучения! Очень вовремя.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
croc.ru
Employees
1,001–5,000 employees
Registered