Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Ukridge от 04 Августа 2016, 17:03:58
-
Предположим, существует некий бизнес-процесс, запускающийся по рабочим дням в 16:00 ("забрать документы из офиса A, привезти в офис B и пустить в обработку").
Этот процесс нужно отобразить на activity-диаграмме "регистрация клиента". Т.е. клиент приходит в офис "А" (в любое время), заполняет там документы, потом ждёт результата их обработки, после 16:00 (уже вне офиса).
Как отобразить запуск бизнес-процесса в 16:00?
Учитывая, что он существует независимо от прихода/неприхода клиента в офис A, неправильно, ИМХО, рисовать вход в сигнал "16:00" от форка от initial.
Второй initial, похоже, тоже рисовать неверно.
Подскажите, pls
-
Было бы проще использовать для этого нотацию BPMN, но в вашем случае можно передать разными способами, явно через decision node или guard condition на переходе, или использовать event action http://www.uml-diagrams.org/activity-diagrams-actions.html
-
По сути у Вас два независимых процесса - заполнение документов клиентом в офисе А и обработка их в офисе B. Каждый из этих процессов имеет свое инициирующее событие (приход клиента в первом и 16:00 во втором), количество экземпляров первого процесса будет соответствовать количеству клиентов, во втором он строго раз в день. Все что эти процессы связывает - накопленные до 16:00 документы.
Какова цель отобразить оба процесса на одной диаграмме?
-
Цели две:
- Проанализировать процесс, ничего не упустив
- Наглядно показать бизнесу, что происходит с документами. И при этом не хочется нарушать нотацию.
Galogen, я не очень понимаю, как тут поможет decision, если decision (без форков) подразумевает последовательное выполнение.
В моем же случае есть параллельная ветка исполнения, инициируемая по некоему сигналу ("будильник").
-
Цели две:
- Проанализировать процесс, ничего не упустив
- Наглядно показать бизнесу, что происходит с документами. И при этом не хочется нарушать нотацию.
С такими целями лучше использовать Bpmn. Там для описания межпроцессных взаимодействий есть все - и оркестровки, и хореографии.
Если критична диаграмма активности, можно попробовать в качестве инициирующего события взять начало рабочего дня, оформление документов описать как loop по клиентам, с прерыванием в 16:00 на пересылку документов и на конец рабочего дня.
Ну или описать оркестровку в стиле bpmn - два процесса, каждый со своим инициирующим и финальным событием,с непересекающимися потоками управления и object flow через хранилище документов
-
Нашел пример с независимыми потоками управления
http://dit.isuct.ru/ivt/books/CASE/case11/ch19.htm
Рисунок 19.9
Один поток по отгрузке товара, второй по взаиморасчетам.
-
Еще пример по накоплению объектов в datastorage
http://it-gost.ru/articles/view_articles/96
-
Рисунок 19.9 из книжки про старый UML и на нём недостаёт одной стрелки, а другая нарисована сплошной вместо пунктирной.
Примеры по второй ссылке также не удачны (ЦБ с одним входным потоком и одним выходным; отсутствие select-а на потоке, идущем из datastore в "Обработать заказ").
-
Рисунок 19.9 из книжки про старый UML и на нём недостаёт одной стрелки, а другая нарисована сплошной вместо пунктирной.
Примеры по второй ссылке также не удачны (ЦБ с одним входным потоком и одним выходным; отсутствие select-а на потоке, идущем из datastore в "Обработать заказ").
А правильные то примеры с двумя асинхронными процессами встречаются? С удовольствием бы глянул. А то я похоже выразительные возможности диаграммы активности недооценивал
-
А правильные то примеры с двумя асинхронными процессами встречаются? С удовольствием бы глянул. А то я похоже выразительные возможности диаграммы активности недооценивал
Конечно, проще искать ошибки, чем предложить что-то конструктивное. Если уточните, что нужно, попробую представить. В каком-то смысле, для асинхронных процессов достаточно диаграммы с форком.
-
Конечно, проще искать ошибки, чем предложить что-то конструктивное. Если уточните, что нужно, попробую представить. В каком-то смысле, для асинхронных процессов достаточно диаграммы с форком.
Во вложении набросал пример процесса в bpmn с паттерном "Папочки" (участники процесса взаимодействуют, помещая и забирая документы из соответствующих папочек) и попробовал построить эквивалентную ДА.
Смущает то, что в BPMN есть конструкция pool - процесс или внешняя сущность. В UML такой конструкции нет, поэтому непонятно насколько корректна такая ДА
1) Три потока , у каждого свое инициирующее событие и свой финал потока. Общего финального события нет.
2) Поскольку токены по каждому потоку гуляют независимо нет необходимости описывать циклы
-
... непонятно насколько корректна такая ДА
С точки зрения стандарта UML 2.5, если каждый из 3 процессов стартует из своего начального узла (initial node), то в рамках моделируемой деятельности "процесс клиента", "процесс перемещения" и "процесс обработки" отработает по одному разу. Т. е., скорее всего, в "процессе клиента" должен быть цикл, иначе в течение выполнения всей большой деятельности клиент будет лишь один (не более одного) и datastore не понадобится для его единственной заявки.
-
С точки зрения стандарта UML 2.5, если каждый из 3 процессов стартует из своего начального узла (initial node), то в рамках моделируемой деятельности "процесс клиента", "процесс перемещения" и "процесс обработки" отработает по одному разу. Т. е., скорее всего, в "процессе клиента" должен быть цикл, иначе в течение выполнения всей большой деятельности клиент будет лишь один (не более одного) и datastore не понадобится для его единственной заявки.
Эх. Если нужен цикл, значит нужно придумывать, когда его начинать, а когда заканчивать. В случае с bpmn об этом можно не думать - событие прихода клиента поступает извне, а заявка начинает обрабатываться в соответствии с работой некоторого планировщика ( он в этом описании неважен, а потому и не отражен).
Если определить за initial node по процессам приема и обработки заявок начало рабочего дня, то надо будет думать как отражать незавершенное производство - заявки, принятые после 16:00 в первом процессе, и необработанные на начало дня заявки в третьем. А это диаграмму перегрузит. То есть такую ДА хорошо бы дополнить диаграммой последовательности или диаграммой состояний, чтобы понять процесс в разрезе заявки.
То есть заменяем одну диаграмму bpmn двумя uml
-
Эх. Если нужен цикл, значит нужно придумывать, когда его начинать, а когда заканчивать.
А если посмотреть в сторону паттернов сети Петри, вернее оценочных сетей Петри. Ведь ДА в uml 2.0 в основе имеет сеть Петри с позициями вершинами и позициями переходами с разметкой. Разметка - это заявка (нашей СМО) следовательно нужно сделать:
- генератор заявок
- движение заявки по логике процесса
- аккумулятор заявок (под заявками считать метки)
Если не ошибаюсь паттерны для СМО через сети ПЕтри есть тут http://smart-torrent.org/sapr-programmi/gultyaev-vizualnoe-modelirovanie-srede-matlab-t81138.html
-
А если посмотреть в сторону паттернов сети Петри, вернее оценочных сетей Петри. Ведь ДА в uml 2.0 в основе имеет сеть Петри с позициями вершинами и позициями переходами с разметкой. Разметка - это заявка (нашей СМО) следовательно нужно сделать:
- генератор заявок
- движение заявки по логике процесса
- аккумулятор заявок (под заявками считать метки)
Если не ошибаюсь паттерны для СМО через сети ПЕтри есть тут http://smart-torrent.org/sapr-programmi/gultyaev-vizualnoe-modelirovanie-srede-matlab-t81138.html
Спасибо за подсказку. Покопался еще и нашел шаблон прямо в uml (во вложении)
Но не могу сказать, что сразу понятно, как таким шаблоном пользоваться для поточного описания БП.
Все таки в bpmn шаблоны СМО присутствуют в коробке, и в том же bizagi если процесс построен правильно, иммитационную модель можно сразу же запустить.
-
Эх. Если нужен цикл, значит нужно придумывать, когда его начинать, а когда заканчивать.
"Accept-флажок" внутри деятельности может не иметь входящих потоков. Т. е. initial node для "процесса клиента" заводить не обязательно. Если нужно учитывать время приёма заявки, можно завести [decision node и] сторожевое условие.
-
"Accept-флажок" внутри деятельности может не иметь входящих потоков. Т. е. initial node для "процесса клиента" заводить не обязательно. Если нужно учитывать время приёма заявки, можно завести [decision node и] сторожевое условие.
Прошу прощения, не уловил :(
Если несложно, не могли бы вы изобразить графически:
1) Процесс клиента : инициируется каждым приходом клиента. Заявка помещается в очередь для перемещения со статусом необработано
2) Процесс перемещения: все заявки из очереди для перемещения переносятся в очередь для обработки
3) Процесс обработки: из очереди берется необработанная заявка в порядке ее поступления и обрабатывается. После обработки меняется ее статус
Во вложении я изобразил свое видение, но боюсь оно некорректное.
Насколько Loop эквивалентен pool в bpmn?
-
Замечание о необязательности initial node оказалось невполне уместно. ;D Без него не получится сделать цикл. Примерный вид диаграммы во вложении.
Loop на диаграммах деятельности, как мне кажется, нужен лишь в тех случаях, когда планируется генерировать структурированный код по диаграмме. Сделать кодогенератор, который породит код "без goto" по диаграмме из вложения не так просто, как генератор по loop. BPMN не знаю, поэтому не комментирую.
-
Коллеги, спасибо всем за ответы! Есть над чем подумать.
Пока всё-таки выходит, что BPMN предпочтительней.
-
Замечание о необязательности initial node оказалось невполне уместно. ;D Без него не получится сделать цикл. Примерный вид диаграммы во вложении.
Спасибо большое!
Вопрос по диаграмме из примера по третьему процессу :
Как реализуется цикличность обработки каждой заявки?
-
Пока всё-таки выходит, что BPMN предпочтительней.
Для описаний бизнес-процессов безусловно. Для описания и даже для исполнения сложных межпроцессных взаимодействий (bpms, bpel) тоже. Но bpmn - это чисто процессная нотация - в ней нет средств описания данных, их можно приводить только как артефакты.
У UML преимущество в универсальности и разнообразии форматов. В рамках UML можно описать концептуальную модель предметной области в виде диаграммы классов, а потом эти же сущности использовать в поведенческих диаграммах.
То есть если нужно разобраться с БП, то лучше BPMN придумать что-либо сложно, но если нужно спроектировать приложение, то нужен UML.
-
Вот и хотелось всё нарисовать в UML, дабы не плодить сущности без необходимости.
Преимущества поддержки одной диаграммы вместо двух (да ещё в разных нотациях) очевидны.
-
Как реализуется цикличность обработки каждой заявки?
Сначала скажу, что моя версия диаграммы лишь демонстрировала, как я представляю себе цикличность "процесса клиента". Она полна недостатков. Например, можно составить вариант с одним, а не двумя datastore. Есть и другие пробелы.
Теперь по Вашему вопросу:
Никак. Перемещение заявок съедает все предлагаемые ему объектные токены и токен управления и разом их переваривает, выдавая на выход кучу токенов перемещённых заявок. Если важно/нужно, чтобы заявки перемещались по одной, то нужен явный цикл (похожий на клиентский). То же самое справедливо для "обработать заявки".
-
Еще раз спасибо за предложенное решение
Если важно/нужно, чтобы заявки перемещались по одной, то нужен явный цикл (похожий на клиентский). То же самое справедливо для "обработать заявки".
А если перемещаются заявки чохом, а затем докладываются в общую папку для индивидуальной обработки?
Если мы сделаем в третьем процессе цикл goto с join аналогичный первому, будет ли это означать, что индивидуальные токены заявок восстановлен из общей кучи, куда их сунули при перемещении?
.
-
Если мы сделаем в третьем процессе цикл goto с join аналогичный первому, будет ли это означать, что индивидуальные токены заявок восстановлен из общей кучи, куда их сунули при перемещении?
Это возможно, но при этом на поток данных из второго datastore надо вешать select, определяющий в каком порядке выбираются заявки из общей кучи. Вместо цикла можно было бы задействовать <<iterative>> expansion region, если бы я знал как набор токенов-заявок превратить в один токен-коллекцию-заявок.