Я тоже предвзят, поскольку являюсь основным автором StonePath.
Я разработал приложения для рабочего процесса для Государственного департамента США, Женевского центра по гуманитарному разминированию, нескольких клиентов из состояния 500 и совсем недавно для системы государственных школ Вашингтона, округ Колумбия. Каждый раз, когда я видел «механизм рабочего процесса», который пытался быть единственным эталоном для бизнес-процессов, я видел, как организация борется сама с собой, пытаясь обойти этот инструмент. Это может быть связано с тем, что эти решения всегда основывались на поставщиках / продуктах, а затем заканчивались тактической командой `` консультантов '', постоянно поддерживающей приложение ... но из-за этого я склонен реагировать негативно, когда слышу Преимущества инструментов, основанных на процессах, которые обещают «централизовать определения рабочих процессов в одном месте и сделать их повторяемыми».
Тем не менее, мне очень нравится Ruote - я слежу за этим проектом в течение некоторого времени, и если мне понадобится такое решение, это будет следующий инструмент, который я захочу попробовать. StonePath имеет совсем другое предназначение, чем ruote - там, где Ruote полезен для Ruby в целом, StonePath нацелен на Rails, веб-фреймворк, написанный на Ruby. Если Ruote посвящен долгоживущим бизнес-процессам и связанным с ними определениям, StonePath занимается управлением рабочим процессом и постановкой задач на основе состояния. Честно говоря, я думаю, что различие со стороны может быть неуловимым - во многих случаях одни и те же виды бизнес-процессов могут быть представлены в любом случае - хотя модель, основанная на состоянии и задачах, имеет тенденцию соответствовать моей ментальной модели.
Позвольте мне описать основные моменты рабочего процесса на основе состояний. Короче говоря, представьте себе рабочий процесс, вращающийся вокруг обработки чего-то вроде ипотечной ссуды или продления паспорта. По мере того как документ перемещается «по офису», он перемещается из штата в штат. Представьте, что вы отвечаете за документ, и ваш босс каждые несколько часов спрашивает вас об обновлении статуса и хочет получить краткий ответ ... вы бы сказали что-то вроде «Это во вводе данных» ... «Мы проверяем учетные данные заявителя сейчас "..." мы ожидаем проверки качества "..." Готово "... и так далее. Это состояния в рабочем процессе на основе состояний. Мы переходим из состояния в состояние с помощью переходов, таких как «одобрить», «применить», «откат», «отклонить» и т. Д. Это, как правило, глаголы действия. Подобные вещи все время моделируются в программном обеспечении как конечный автомат. .
Следующая часть рабочего процесса на основе состояния / задачи - это создание задач. Задача - это единица работы, обычно со сроком выполнения и инструкциями по обработке, которая связывает рабочий элемент (например, заявку на ссуду или обновление паспорта) с пользователем «в ящике». Задачи могут выполняться параллельно друг с другом или последовательно, и мы можем создавать задачи автоматически, когда мы входим в состояния, создавать задачи вручную, когда люди понимают, что работа должна быть выполнена, и требовать, чтобы задачи были завершены, прежде чем мы сможем перейти в новое состояние. Такое поведение не является обязательным и является частью определения рабочего процесса.
Кроличья нора может идти намного глубже, и я написал об этом статью для № 4 журнала PragPub, журнала Pragmatic Programmer's Magazine. Перейдите по ссылке выше, чтобы получить обновленный PDF-файл этой статьи.
Работая с StonePath последние несколько месяцев, я обнаружил, что модель на основе состояний очень хорошо отображается на спокойные веб-архитектуры - в частности, задачи и переходы между состояниями хорошо отображаются как вложенные ресурсы. Ожидайте, что в будущем я буду писать по этому поводу.
person
Community
schedule
03.03.2010
