Есть ли языки/нотации для записи бизнес-логики?

Question

[WhoMe]

Например, в математике пишут "x + y < z" потому что это понимается проще чем
текст "сумма x и y меньше чем z".
Есть ли подобные нотации для записи требований?

Допустим есть некая система букинга отеля. И для нее хотим записать требование

"Скидка доступна если у пользователя подключен тарифный план Платина и срок его действия не закончен на дату бронирования."

Можно было бы записать как-то так:

Скидка "Платина" Доступна ЕСЛИ
(Тарифный план пользователя = Платина)
И (День окончания Бронирования <= День окончания срока действия тарифа).

Какую проблему решаю:
- Повысить читаемость требований
- Формализировать/Унифицировать запись
- Сделать возможным переиспользование требований (типа условия скидки, один раз определили и используем в других формулах)

Есть ли какие-то подобные системы записи?

Обн.
* Нет цели задокументировать абсолютно весь в проект в такой нотации.
* Мне это видится как такой DDD в псевдокоде, без привязки к инфраструктуре или языку программирования.
* Что-то похожее https://www.flexrule.com/business-rules

Comments

[Константин Нагибович]

Посмотрите в сторону BPMN.

[Василий Банников]

Хз есть ли такие в текстовом виде, но никто не может запретить сделать что-то подобное на основе уже существующего языка программирования или написать свой собственный язык (DSL)

[Владимир Куц]

Блок-схемы, мне кажется, - в таком случае более наглядны, чем набор подобного вида текстов, где после пары-тройки строк уже потеряешь цепь логики.
Ну а там гуглить - к примеру UML-диаграммы.

[Komrus]

Тут ещё вопрос применимости.
Описание бизнес-логики "просто на бюрократическом русском" может делать человек, хорошо разбирающийся в предметной области (бронирование отелей), но НЕ являющийся программистом (постановщик задачи).
Причём многие намётки на русском он может делать в процессе обсуждения с Заказчиком.

Потом дооформляя в длинные структурированные тексты.
(Нечто вроде "Пункт 2.2.1.3" :)

Нарисование блок-схем для ДЕЙСТВИТЕЛЬНО больших проектов улетит в некую простыню, выглядящую безумно круто... Но удобство её применимости и наличие персонала, способного с ней работать (как постановщиков, так и программистов) - вопрос очень дискуссионный.

[WhoMe]

Василий Банников, прежде чем писать собственный DSL как раз и хочется узнать, а что уже есть из доступного

[Василий Банников]

WhoMe, вопрос: а кто эти условия писать должен?

[Василий Банников]

Какую проблему решаю:
- Повысить читаемость требований
- Формализировать/Унифицировать запись
- Сделать возможным переиспользование требований (типа условия скидки, один раз определили и используем в других формулах)

А для чего тут нужна формализация / унификация?
Как ты видишь переиспользование?
Можно ли повысить читаемость без этого?
Кажется, что однозначную трактовку требований можно получить и без формального языка.

Тоесть условно:

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

В задачи добавить Definition of done вида "задача считается готовой к работе тогда и только тогда, когда все заинтересованные однозначно интерпретируют требования". Так со временем и так выработается такой язык, который будет более понятен для всех.

Если всё равно за реализацию этой скидки в системе будет ответственен разработчик, то нет смысла вводить формальный язык.

Формальный язык без средств для автоматической проверки - это всегда боль.
Сложные формальные языки и диаграммы - это двойне боль, так как нужно ещё всех научить их писать и читать.
Тот же уже упомянутый BPMN не является интуитивно-понятным и при этом большинство аналитиков, менеджеров, разработчиков его только в университете застали в лучшем случае.

Answer 1

[VoidVolker]

Диаграммы же. Смотрите в сторону с текстовой базой. Типа UML и прочее. Вот еще тоже неплохой онлайн инструмент для создания диаграмм из текстового описания: https://www.mermaidchart.com/landing (можно запустить локальный инстанс у себя).

UPD1:
Пример флоу-диаграммы русалки:

flowchart TD
    A[Полльзователь] --> B(Скидка)
    B --> C{Тариф - платина?}
    C -->|Да| D[15%]
    C -->|Нет| E[5%]

Картинка:

spoiler

UPD2: Можно взять что-то гибридное типа ЯП Дракон.

Comments

[WhoMe]

Немного не понял как диаграммой записать требование из вопроса.
Можно пример?

[VoidVolker]

flowchart TD
    A[Полльзователь] --> B(Скидка)
    B --> C{Тариф - платина?}
    C -->|Да| D[15%]
    C -->|Нет| E[5%]

Картинка:

spoiler

[WhoMe]

Понял. Т.е. по сути блок-схемы. Блок-схемы я люблю, но имхо в данном примере мне не видится упрощения, по крайней мере в том виде как это записывается в "русалке".

Мы когда программируем/читаем код, нам же не нужна блок-схема под каждой условие, они и текстом неплохо читаются.

[VoidVolker]

Ну, тут у вас вариантов немного: либо использовать полноценный ЯП и какой-то визуализатор логики кода, либо диаграммы, либо какой-то специализированный ЯП для описания логики, либо писать свой велосипед. Можно взять что-то гибридное типа ЯП Дракон.

[WhoMe]

Ух ты, ДРАКОН довольно интересная штука.
Автор делает упор на "читаемость" - то что нужно.
Почитал книжку автора ДРАКОНа "Как улучшить работу ума".
Нашел в главе 9, "Визуализация логических формул" как графически удобно представлять логические выражения.
А вот как в текстовом формате представлять увы не нашел.
Хоть в книжке и написано что существует эквивалентный текстовый синтаксис,
найти его описание мне не удалось. Похоже он еще в разработке. Жаль.

Но вообще довольно интересная штука, спасибо за наводку.

Answer 2

[alexalexes]

Похоже на попытку реализовать язык Prolog или его форк.
Любые попытки использовать это в документации приведет к тому, что нужно будет всем учиться читать такие записи, и техническому писателю учиться правильно формировать их без логических ошибок.
Лучше подобные фичи описывать как теоремы/гипотезы в математике:
1. Условие применимости фичи (область действия теоремы/гипотезы).
2. Суть фичи (формулировка теоремы).
3. Результат применения (что получаем).

Comments

[WhoMe]

Prolog это прям очень близкое к тому что хочется. Видимо потому что и там и у меня в примере описываются предикаты.
Но верифицировать требования автоматически пока цели не стоит. У меня поскромнее запросы).

Про теоремы/гипотезы интересно, почитаю.

[alexalexes]

Если вы хотите подобрать формальный язык, то придется пользоваться проверками, чтобы при внесении высказываний видеть противоречия.

Answer 3

[mayton2019]

"x + y < z"

То что вы хотите - это не язык бизнес-логики а обычная блок-схема алгоритма или
диаграмма использования.

Формализировать/Унифицировать запись

Вы должны задать себе вопрос для кого это делается. Кто будут те люди, которые обязаны
будут по должностной читать эти вещи. Соберите с них фидбеки. Я вообще не уверен
что у них с этим проблема. Может они вам скажут что им такое не надо и проблема в другом.

Посмотрите еще графический стандарт BPML (Business Process Modeling Language).
Посмотрите также обычные Activity Diagram, Use-Case Diagrams из рисовалок UML.

Comments

[WhoMe]

Это нужно мне как программисту. У меня с этим проблема и думаю что не у меня одного.
Ситуация: Вы приходите на проект, технический стек которого вам знаком.
С чем-то работали, что-то похожее. Это не проблема.
Но для вас это новый проект, вы не знаете бизнес-логики, вы не знаете как что должно работать. Это становиться узким местом в работе.

И вот задача приводит вас в метод на 6к (бывает больше) строк не лучшего кода в который нужно внести изменения. И вы бы могли его порефакторить если бы не одно НО - ни вы никто не знает сколько там логики и как оно должно работать. Потому что чел который придумал эту логику уже уволился/занят/забыл или туда уже столько раз вносили изменения что никто уже не в курсе всего.

Был реальный случай когда тестировщик нашел баг, аналитик подтвердил что это баг. Я начал копать и откопал целую подсистему про которую никто не вспомнил. В итоге это оказался не баг.

Хочется эту логику документировать, хотя бы для отдельных кусков системы.

[mayton2019]

WhoMe, да мне это хорошо знакомо. Почти на всех проектах. Ты приходишь с пустой головой.
По бизнесу ничего непонятно. И я обычно завожу для себя страничку в wiki или в confluence
(внутри-корпоративный ресурс всегда есть) и просто начинаю писать туда заметки как оно
работает.

Еще лучше - писать прямо в репозитарий проекта. Но это надо обсудить с коллегами. Обычно
не все разработчики любят такое дело. Проблема - в коде-ревью и в том что документация
остает от кода. Код - всегда несет правду. А документация просто намерения и то устаревшие.

Вообще если вы не работаете в аэрокосмосе - то вам придется смириться с мыслью что
такой покрывающей документации не будет нигде. Просто на ее разработку тоже никому
не дали время. И это - нормально. Это просто ваш локальный договорняк в бизнесом.
Бизнес - устраивает работающий код а не бумажки. Собственно код (фичи) является главным продуктом релиза.
И именно за него платят деньги. И это очень похоже на написание модульных тестов по коду.
Все понимают что тесты нужны но времени на них нету. И поэтому при разработке софта
- просто накидывайте +20% времени на тесты и документирование.

Кстати в некоторых случаях тщательно написанные тесты могут быть половиной документации.
Посмотрите в такие фреймворки как
- JBehave https://jbehave.org/

Они позволяют описывать сценарии тестирования на английском очень близко к сентенциям типа
Скидка "Платина" Доступна ЕСЛИ.

Answer 4

[Виталий Сергеев]

У нас для хранения бизнес-правил использовался BPML. Это XML-описание схемы процесса, которую можно представить визуально. То есть человекочитаемый формат тут — именно визуальная диаграмма, схема процесса. Для автоматизации же есть много клиентов и библиотек для работы с таким форматом.