DMN Документация

DMN Онлайн симулятор

Обучение с помощью Doing: вы можете использовать наш бесплатный онлайн-симулятор для создания таблиц решений DMN, которые вы создаете.

Почему я должен заботиться о DMN?

Модель принятия решений и нотация (DMN) является отраслевым стандартом для моделирования и принятия решений, которые определяются бизнес правила.

DMN опубликован в 2015 году и в настоящее время очень быстро принят. Вот причины:

Стандартные

DMN не принадлежит определенному предприятию, а учреждению ( OMG ), который уже установлен другими мировыми стандартами, например, BPMN и UML. Стандарт DMN поддерживается несколькими программными продуктами; вы менее зависимы от каких-либо конкретных продуктов поставщика.

Прямые

В DMN решения могут быть смоделированы и выполнены с использованием одного и того же языка. Бизнес-аналитики могут моделировать правила, которые приводят к решение в легко читаемых таблицах, и эти таблицы могут быть выполнены непосредственно механизмом принятия решений (например, Camunda). Это минимизирует риск недоразумений между бизнес-аналитиками и разработчиками и даже позволяет быстро изменять в производстве.

Экспертные

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

Этот учебник содержит краткое введение в DMN, как он определен в версии 1.1.

Простая таблица решений

Мы должны начать наш учебник DMN с довольно простой таблицы решений:

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

Давайте рассмотрим элементы в этом примере:

• В верхнем левом углу мы находим имя этой таблицы решений: «Блюдо»
• Ниже «U», который обозначает уникальный и представляет собой определенную политику хита для этой таблицы решений. Это означает, что, когда решение должно быть принято, только один из приведенных ниже строк может быть правдой. В этом случае нынешний сезон может быть только осенью, зимой, весной или летом. У нас не может быть двух сезонов одновременно, даже если лето кровоточит в этом году.
• Столбцы зеленого цвета относятся к возможностям ввода . В этом примере есть только один входной столбец, потому что мы только заинтересованные в текущем сезоне. Эта ячейка с текстом «Сезон» определяет это. В DMN это ярлык для выражение . Само выражение в этом примере скрыто для простоты, но будут раскрыты позже в этом уроке. Ячейки ниже (называемые вводными данными ) относятся к возможным условиям относительно ввода. Эти условия заключаются в кавычки (например, «Лето»), что связано с тем, что мы технически сравниваем Строковые значения.
• Для каждой возможной входной записи (т. Е. Названия текущего сезона) мы определяем соответствующую запись в ячейке рядом с ней. Вот как мы выражаем это, исходя из сезона, мы желаем определенного блюда. Опять же, мы должны использовать кавычки (например, «Стейк»), потому что технически мы присваиваем значения String.
• Определение, что согласно входной записи, которая является истинной (или комбинацией истинных входных записей), должна применяться конкретная выходная запись, это правило . Каждое правило определяется в строке таблицы ниже заголовка таблицы и имеет номер, который вы можете найти в ячейках слева.
• И последнее, но не менее важное: вы можете аннотировать свои правила в столбце справа. Эти аннотации имеются только для ради объяснения, и будет проигнорирован механизмом принятия решения.

Достаточно просто, не так ли? Конечно, DMN больше, но основные принципы действительно очень просты.

Сочетание условий

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

В этом случае мы можем рассмотреть гостей, которые являются вегетарианцами. Независимо от сезона, мы не можем обслуживать их каким-либо мясом. К счастью, у нас всегда есть макароны. Объединив два входных столбца «Сезон» и «Вегетарианские гости», мы убедились, что первые четыре правила может оценить только истину, если гости не являются вегетарианцами. Правило № 5 имеет «-» во входной записи, которая проверяет сезон, и это означает, что это может быть любой сезон, пока гости - вегетарианцы, они получат макароны.

Как вы можете видеть, комбинация входных записей в правиле (т. Е. Строка таблицы) всегда следует логике И : «Если это падение и мои гости не являются вегетарианцами, я буду служить спаррибам ".

Представляем FEEL

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

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

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

Чтобы получить первую идею, ознакомьтесь с приведенным ниже примером:

Первое, что вы заметите, - это две дополнительные строки с серыми ячейками. Эти строки описывают технические детали, которые решение для принятия решения. Первый содержит выражения, которые - в этом случае - просто ссылайтесь на имена переменных, а именно на сезон, guestCount и желательно. Второй указывает двигателю тип соответствующего результата выражения, в этом случае string и integer.

В первых примерах эти строки были скрыты, чтобы не подавить вас прямо вверх. Но на самом деле эти типы важно, потому что они определяют, какие выражения FEEL доступны для входных записей.

Давайте посмотрим на каждое правило, то есть на каждую строку:

1. Если это падение, и вы ожидаете до 8 гостей, вы будете готовить спарибер.
2. Если это зима, и вы ожидаете до 8 гостей, вы будете обслуживать их roastbeef.
3. Если это весна, и вы ожидаете до 4 гостей, вы побалуете их очень хорошим сухим бифштексом.
4. Если это весна, и вы ожидаете от 5 до 8 гостей, вы подадите им обычный стейк.
5. Если это осень, зима или весна, и вы ожидаете более 8 гостей, вы отправитесь на тушение.
6. Если это лето, там будет легкий салат и, конечно, хороший стейк, несмотря ни на что. Ура!

Как вы, наверное, уже догадались, это только верхушка айсберга. Существует гораздо больше, что вы можете выразить в решении DMN таблиц, как мы опишем в Справочная документация по DMN.

Процессы DMN и BPMN

Возможно, вы думаете:

Эй, почему я должен использовать DMN в любом случае, я могу выразить эти правила с помощью BPMN шлюзы!

Если мы выражаем приведенный выше пример в BPMN, это выглядит так:

Скорбь очевидна: для BPMN, особенно когда есть несколько условий рассматривать. Диаграмма становится сложной и трудно поддерживать.

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

Во время моделирования, а также выполнения мы можем связать задачу «Решить блюдо» с таблицей решений DMN, которая будет выполнена, когда решение должно и результат затем определит дальнейший расход в BPMN.

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

Это слишком легко, не так ли? Но в этом случае это действительно подходящий шаблон.

Сочетание BPMN с DMN - очень разумный подход. К сожалению, он еще не стандартизирован OMG. Это означает, что ссылка из бизнес-правила BPMN на решение DMN всегда зависит от поставщика.

Как Camunda связывает BPMN с DMN.

DMN and CMMN Cases

BPMN отлично подходит для процессов, которые структурированы, но не для меньших структурных действий. Именно здесь начинается CMMN. Опять же, имеет смысл объединить этот стандарт OMG с DMN. Например, например:

Подготовка хорошего ужина с друзьями - это свое собственное искусство, которое требует реального работника.

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

Вы можете заметить, что политика удаления в этом примере не является «уникальной», а «первой» (помечена как «F»). Это означает, что механизм принятия решения оценит правила и остановит оценивая, как только он нашел правило, которое применяется. В этом случае это имеет смысл, поскольку применяются правила 2 и 3, если они холоднее, чем 20 ° C и проницаемость дождя составляет 50% или выше. Поэтому установка политики ударов на «уникальную» не была бы правильной.

Как и в случае BPMN, OMG еще не стандартизировал способ объединения CMMN и DMN. Таким образом, пример в этом руководстве основанный на проприетарном расширении, которое предлагает Camunda.

Схемы требований принятия решений

Если вы хотите обсудить и проанализировать комплексные решения, которые могут состоять из других решений, диаграмм требований принятия решений (DRD) может быть полезно. Это довольно простая нотация, определенная в стандарте DMN, которая в основном

• Решения : действие определения выходного значения из числа входных значений с использованием логического определения. Эта логика решения это то, что вы можете выразить в таблицах решений.
• Входные данные : входные данные, которые вы «подаете» в логику принятия решения, чтобы определить выходное значение.
• Отношения между решениями : вы можете подключать решения со стрелками и, следовательно, указать, какой выход решения будет рассматриваться как вход для другого решения.

В нотации DRD есть еще несколько символов, однако наиболее важными из них являются три. Мы должны посмотреть на пример:

Предположим, что для нашего обеда нам также необходимо решить, какие напитки мы хотим обслуживать. Это решение должно основываться на блюдо, которое мы приготовим, а также рассмотрим детей. Таблица решений может выглядеть так:

Вы заметите, что эта таблица имеет «С» в верхнем левом углу, а не «U», который вы видели в предыдущих примерах. C означает Собрать , что является другой политикой хита , и это означает, что может быть истинным несколько правил, что приведет к списку выходных значений.

Например, если у нас будут спарерибы, а наши гости придут с детьми, мы будем обслуживать воду, яблочный сок и знаменитый Aecht Schlenkerla Rauchbier.

Очевидно, нам нужно определить блюдо, которое мы приготовим, прежде чем мы сможем решить, какие напитки. И это отношение - это то, что вы можете описать в DRD, как в этом примере: