Использован кадр из мультфильма «Падал прошлогодний снег…». Шедевр! Между прочим, рейтинг на «Кинопоиске» почти 9!
Больше года назад я опубликовала на хабре статьи «Один день из жизни белки» или от моделирования процессов к проектированию автоматизированной системы учёта материальных ценностей «Белка-1.0» (часть 1 и часть 2) об использовании «сказочного» подхода при обучении нотации UML.
Попробуем «разложить» всё те же бессмертные строчки на исполняемые процессы BPMN.
Итак, автоматизируем процессы учёта материальных ценностей — проект «Белка-2.0.BPMN»
Напомню, чтобы не переключаться на хабре на предыдущую статью или не искать строчки в «Сказке о царе Салтане…» (хотя, если появилось желание перечитать что-то из произведений Александра Сергеевича, не сдерживайте себя! Пушкин – и правда – наше ВСЁ!)
Автоматизировать мы собираемся деятельность по учёту материальных ценностей, которая возникает вот в этих процессах.
…
Остров на море лежит, (E1, E2)
Град на острове стоит (E3, E1)
С златоглавыми церквами, (E4)
С теремами да садами; (E5, E6)
Ель растет перед дворцом, (E7, E8)
А под ней хрустальный дом; (E9)
Белка там живет ручная, (A1)
Да затейница какая! (A1)
Белка песенки поет, (P1, A1)
Да орешки всё грызет, (P2)
А орешки не простые, (C1)
Всё скорлупки золотые, (C2)
Ядра чистый изумруд; (C3)
Слуги белку стерегут, (P3, A2)
Служат ей прислугой разной (P4)
И приставлен дьяк приказный (A3)
Строгий счет орехам весть; (P5, C1)
Отдает ей войско честь; (P6, A4)
Из скорлупок льют монету, (P7, C2, C4)
Да пускают в ход по свету; (P8)
Девки сыплют изумруд (P9, A5, C3)
В кладовые, да под спуд; (E10, E11)
…
(А.С.Пушкина «Сказка о царе Салтане, о сыне его славном и могучем богатыре князе Гвидоне Салтановиче и о прекрасной царевне Лебеди», работа над сказкой начата предположительно в 1822 г., впервые сказка была напечатана Пушкиным в сборнике «Стихотворения А. Пушкина» (ч. III, 1832, стр. 130—181) — 10 лет от замысла до публикации, между прочим!)
Напомню и про коды, которые написаны справа от строк. «A» (от «Actor») означает, что в строке содержится информация об участнике процесса. «C» (от «Class») – информация об объектах классов, которые обрабатываются в ходе выполнения процессов. «E» (от «Environment») – информация об объектах классов, которые характеризуют окружающую среду выполнения процессов. «P» (от «Process») – информация о самих процессах.
Переписывать всю нотацию BPMN и правила её применения в данной статье не стану — вы легко сможете найти необходимую информацию на официальном ресурсе здесь [1] или в Whitepapers, например, здесь [2]. Буду только давать краткую справку для тех элементов, которые придётся использовать.
В качестве инструмента моделирования и исполнения процессов будем использовать Camunda Open Source Modeler [3] и Camunda Open Source Community Platform [4].
Создадим диаграмму взаимодействия процессов – просто добавим новую диаграмму BPMN в Camunda Modeler.
Начнём с Белки. Добавим пул процесса и назовём его «Один день из жизни Белки».
В свойствах процесса укажем, что он является исполняемым — флаг «Executable» (хотя это почти лишнее, т.к. этот процесс целиком будет состоять из «ручных» задач, а это значит, что мы определяем задачи, которые являются внешними по отношению к движку BPM, и такие задачи обрабатываются как сквозное действие).
На рисунке ниже «1» – это имя пула процесса.
Под цифрой «2» стартовое событие (StartEvent) процесса и начальная задача – утром наша Белка выходит из домика, эта задача в строках стихотворения отсутствует, но мы эту задачу добавляем, чтобы явно обозначить задачу предварительного характера, выполняемую в начале дня.
«3» — это блок из двух «ручных» задач (Manual Tasks) Белки («песенки поёт» и «орешки грызёт»), выполняемых параллельно. Параллельность выполнения этих задач показана с помощью двух параллельных шлюзов (Parallel Gateway): для ветвления в начале и соединения в конце блока.
«4» — завершающая задача Белки («идёт отдыхать»), как и начальная задача, завершающая поддерживает наше желание показать целиком день из жизни Белки.
«Сокращенный» вариант будет выглядеть так.
Несколько замечаний по применению типов задач и маркеров.
Задачи позволяют моделировать реальную работу, выполняемую в процессе. В Camunda поддерживаются различные типы задач, но мы в этом примере рассмотрим только Ручные (обозначение «1» на рисунке выше), Пользовательские и Сервисные задачи (два последних типа немного подробнее разберём далее).
В дополнение к различным типам задач мы можем пометить задачи как циклы, множественные экземпляры или компенсации – это маркеры. Маркеры можно комбинировать с типами задач. Из маркеров в нашем примере будем использовать только «повторение» (обозначение «2» на рисунке). Однако, отметим, что наш инструмент пока не поддерживает выполнение этого маркера, для «ручных» задач это не принципиально, а для других типов задач эту «неприятность» можно обойти явным моделированием цикла (мы вернёмся к обсуждению этого момента позже).
Цветом на схеме будем выделять задачи, которые явно есть в нашем описании процессов – в стихотворных строчках.
Для именования задач в целях максимального соответствия исходному «сказочному» описанию процессов будем все задачи именовать с использованием сказуемого и дополнения: «песенки поёт», «орешки грызёт» и т.д.
Итак, мы добавили пул процесса. Пока мы этого не сделали, наша диаграмма была просто процессом. А как только был добавлен пул, наша диаграмма автоматически стала диаграммой взаимодействия процессов (Collaboration). Добавим в документацию описание наших взаимодействующих процессов.
Продолжим моделирование.
А дальше у нас Слуги: «Слуги белку стерегут, Служат ей прислугой разной». Поставим эти «ручные» задачи параллельно и сделаем их цикличными.
Обязанность учёта материальных ценностей возложена на Дьяка приказного, поэтому «Один день из жизни Дьяка» наиболее интересный для нас процесс. Выполним моделирование. Явно выделим ручные задачи, в которых передаем материальные объекты, и пользовательские задачи, в которых автоматизирована деятельность по учёту материальных ценностей. Добавим подпроцессы (цифра «1» на схеме ниже), которые включают связанные ручные и пользовательские задачи. Подпроцессы отмечены как циклические, задачи в этих подпроцессах действительно могут выполняться в цикле: накопились ядра – передал на хранение. В конце процесса добавим сервисную задачу по формированию сводного отчёта за день (цифра «2» на схеме ниже).
И немного крупнее.
Продолжим моделирование — на очереди один день из жизни Войска. Здесь появится еще один новый элемент — вызов внешнего процесса, Call Activity — выделен жирной рамкой. Мы просто предполагаем, что у Войска есть еще много другой работы.
Следующие два фрагмента — это модели процессов в рамках одного дня из жизни Литейщиков и Казначейства.
И в заключении — один день из жизни Девок.
В целом взаимодействие процессов будет выглядеть примерно так.
Для того, чтобы наши процессы можно было исполнять с использование BPM-движка Camunda, нам необходимо сделать некоторые дополнительные настройки.
Прежде всего — не забыть у исполняемых процессов в свойствах «включить» флаг «Executable».
Настроим свойства пользовательской задачи «строгий счёт орехам ведёт (получает орехи со склада)»: по умолчанию задача будет назначаться пользователю diak (это наш Дьяк приказный, далее мы настроим пользователей для наших исполняемых процессов в веб-приложении Admin BPM-платформы Camunda), который будет вводить информацию об орехах полученным со склада в поля формы.
Назначим поля ввода для формы: Дата, ФИО учётчика (Дьяка), Количество орехов.
Далее нам нужно настроить остальные пользовательские задачи, добавив назначаемого для исполнения задачи пользователя (это будет «diak») и задав поля формы для ввода необходимой информации (предлагаю вам немного пофантазировать).
Итак, почти всё готово! Во 2-ой части статьи мы запустим на исполнение наши «сказочные» процессы на BPM-платформе Camunda. Продолжение следует…
Список источников
1. BPMN Specification. [Электронный ресурс] Режим доступа: Интернет: www.omg.org/spec/BPMN/2.0.2/PDF
2. BPMN Whitepapers. [Электронный ресурс] Режим доступа: Интернет: www.omg.org/news/whitepapers/Business_Process_Model_and_Notation.pdf
3. Camunda Open Source Modeler. [Электронный ресурс] Режим доступа: Интернет: camunda.com/download/modeler
4. Camunda Open Source Community Platform. [Электронный ресурс] Режим доступа: Интернет: camunda.com/download
badmilkman
Отличная подача материала, но он некорректен.
1. Создание процесса должно начинаться указанием цели, которую необходимо достигнуть этим процессом.
В сказке, написанной в позапрошлом веке, она обозначена — добыча драгоценных камней и металлов.
2. Затем должны быть обозначены его входы и выходы.
В сказке: Вход — орешки. Выход — золото и изумруды.
3. И уже затем исполнители и их действия с взаимосвязями.
4. Также важно посчитать себестоимость исполнения экземпляра процесса — вполне может оказаться что добытого золота и драгоценных камней не хватает на оплату работы девок, охраны и дъяка.
Если пропускать пункты 1, 2 и 4, линейные аналитики начинают строить воздушные замки, мало применимые в реальной жизни.
krasni Автор
Спасибо за комментарий!
Мы пока зафиксировали наши наблюдения за процессом — провели «предпроектное обследование»:)
Но Вы правы безусловно! Цель, входы, выходы и оценка эффективности процессов — важнейшие составляющие! Добавлю про них во вторую часть.
badmilkman
Даже на обследовании необходимо выявлять цель и границы существующего процесса. Вполне возможно субъективные, и в общих чертах. Они потребуются уже в 1-м раунде управления(«оптимизации») связанными процессами.
Бонусом, это поможет выявить осознанность действий участников процесса.