Комментарии 2
Вы описали пример, который в каждой книге по BPMN присутствует. Но не используя Rule Task где как рад таки он и нужен - в месте, где используется score или решение, основанное на матрице решений. Новичкам я посоветовал бы не вашу статью, а именно книгу. У вас это как-то сложновато описано. Хотя, кто знает - может быть найдётся свой читатель.
Спасибо за эту статью и ссылки на стандарт OMG.
В своей практике применяю таблицы решений достаточно часто. Поделюсь в этом комментарии отработанной на многих проектах техникой:
1. Если валидатор проверяет 1, 2 или 3 атомарных бинарных условий - таблица решений не нужна, так как пространство состояний не превосходит 2^3 = 8 и легко перечисляется непосредственно.
2. Если условий 3, 4 и среди них есть небинарные, имеет смысл уже браться за Excel (или иную таблицу) и строить таблицу решений.
3. Если условий 5 и более, то не важно, бинарные они или нет - таблицу решений делать обязательно.
4. В процессе построения таблицы решений всегда следует проводить 2 этапа:
а) формальный - просто выписываем все пространство состояний;
б) кластеризация и отбрасывание "невозможных" по бизнесу случаев (например, если поле "Серия паспорта" обязательно для заполнения, и передается от подсистемы, дающей гарантию на его заполнение - все кейсы с пустым значением этого поля можно помечать как невалидные).
При этом на шаге б) значения не стоит выкидывать совсем, лучше их помечать каким-либо цветом или зачеркнутым шрифтом. Потом соответствующие колонки (строчки) можно скрыть.
Почему сразу не начать с п. б)? В некоторых случаях так делать можно, но есть риск механических ошибок. Поэтому лучше все же сохранить историю построения таблицы.
Один из самых успешных случаев применения описанной техники - организация тестирования функционала на основании таблицы решений, в которой пространство возможных состояний составляло более 530 кейсов. Это позволило за 2 недели выявить, и оперативно ликвидировать ошибки, которые до того тянулись из релиза в релиз.
Так что подтверждаю, таблицы решений - мощный и нужный инструмент.
Делаем качественные требования с помощью Таблиц принятия решений