Pull to refresh

Comments 8

Я бы рекомендовал начинать такую статью не с «выбираем событийную нотацию и начинаем моделировать», а «определяемся с целями моделирования, в зависимости от целей выбираем устраивающую нас нотацию и т.д.»
мне кажется, статья больше относится к хабу IT-стандарты чем к GTD
В предложенной нотации отсутствует такой важный элемент, как подпроцессы. Без группировки элементов любая схема быстро становится нечитаемой.
Я думаю, в роли подпроцесса может выступать элемент «функция». Которую можно рассматривать как единое целое, а можно разложить на более мелкие составляющие на отдельном или на том же листе.

Мне вот интересно, а кто-нибудь вообще вчитывался в эту статью?

Это общее правило: с событием не связывается ни один элемент, кроме функции

Чуть дальше идёт схема, где с событием связан логический элемент, а не функция.
Не понял.

правило, которому нужно придерживаться на 100%: логические решения могут приниматься только при выполнении функции

Дальше в тексте есть пример применения логического решения после события, а не функции.
Не понял.

Логический элемент «И». Когда для выполнения функции требуется одновременное выполнение нескольких событий:

А если события выполняются не одновременно, а последовательно? (Подсказка - надо рассматривать не время, а факт выполнения. Аналитик не должен такие понятия путать)
Очень интересные формулировки логики в статье, не находите?

Логический элемент «ИЛИ». Соединение элементов, если одно из событий может вызвать выполнение функции:

А может и не вызвать, что ли?

В общем, устал я это читать. Думал быстренько понять про EPC, а тут такое...

1) ну, я так понимаю, логический элемент - это элемент связи, а не блок - поэтому на него правило не распространяется

2) если быть строгими да - тут автор загнался, потому что видимо имел ввиду "логические решения" как результат принятия решения при возникновении какого-то события и хотел сказать, что должно быть описание этого действия по принятию решения в виде функции... а потом приводит пример логического оператора в том виде, для которого он предназначался создателями нотации - для обозначения условий маршрутизации при выполнении процесса. Грубо говоря, все эти операторы изначально можно было бы заменить на точки соединения, но потом возникла потребность объяснять, что вот здесь нужно, чтобы сигнал пришел по всем входящим в нее стрелкам, и только потом пошел дальше (И), либо достаточно одной стрелки (ИЛИ), либо если пришло по одной, то по другим уже сигнал игнорится (Искл.ИЛИ)... и также с ветвлениями сигнала - либо он уходит по всем направлениям, либо по любому из (в т.ч. всем сразу), либо по только одному и по второму тогда не пойдет

3) согласен, тут ошибка терминологии - имеется ввиду не одновременное, а обоюдное, либо обязательное появление сигналов по обоим стрелкам. В общем огрехи русского языка К слову - вот все эти логические семафоры очень тяжело воспринимаются представителями бизнеса - что в EPC, что в BPMN - потому что вот нужно иметь опыт в чтении схем, чтобы понять, что И будет означать, что исполнитель сидит и ждет, пока по всем стрелочкам к нему не прилетит.

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

P.S.: а стоило ли читать / изучать стандарт из 90-х, если уже во всю шагает BPMN ? Может быть еще и IDEF применять ? :-)
Но, на всякий случай - ссылочка на сравнение стандартов:
https://systems.education/bpmn_epc_dmn

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

а стоило ли читать / изучать стандарт из 90-х

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

За ссылку на сравнение спасибо, посмотрю

Sign up to leave a comment.

Articles