Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - olgako

Страницы: 1
1
Выход из цикла по таймеру следует изображать как intermediate event на границе подпроцесса - в этом случае таймер сработает как прерывание подпроцесса. На Вашей диаграмме таймер никак с выходом из цикла не связан. То, что нарисовано, читается как "после выхода из подпроцесса ждать вечера пятницы, после чего завершить процесс". Чем обеспечивается выход из цикла, из этой диаграммы не ясно.

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

Что касается заявок, то из Вашего объяснения не совсем понятно, что является показателем / триггером того, что заявка последняя. В предположении, что это выясняется в процессе обработки последней заявки, я бы сделала так:
Подпроцесс я бы избразила как один зацикленный экземпляр: ждем прихода заявки - обрабатываем - проверяем, что не последняя - в начало. Если последняя, то конец подпроцесса. Исходящая стрелка от границы подпроцесса (normal flow) - это будет поток по завершению подпроцесса в связи с тем, что заявка последняя. Выход по таймеру изображаем как intermediate event на границе подпроцесса. От него своя исходящая стрелка (exception flow). Если продолжение в обоих случаях одинаково, что стрелки normal flow и exception flow объединяем.

2
UML SysML и пр. / Re: Кому, зачем и когда нужен UML
« : 03 Октября 2008, 10:37:44 »
В Google по ключевым словам "BPMN activity". Например, вот: http://www.sql.ru/forum/actualthread.aspx?tid=252943

3
Есть полезный документ, где внятно и довольно полно описаны возможности EA по управлению требованиями и конфигурацией. В частности, темы 1. и 2. раскрыты в подробностях.
http://www.sparxsystems.com/downloads/whitepapers/Requirements_Management_in_Enterprise_Architect.pdf

4
Ну да, действительно - другое. In/OutMessage - это сообщения, циркулирующие в message flow. Я Ваш вопрос про входы-выходы поняла так, что требуется специфицировать входы-выходы для Activity и Sub-process элементов процесса. Т.е. (1) не для всего процесса (2) в sequence flow. Если так, то это Input/OutputSets - без вариантов.
In/OutMessage и должен быть один по нотации, да еще не для любого типа активности. А если message flow отсутствует, т.е., например, у Вас весь процесс в одном pool нарисован, то никаких In/OutMessage быть не должно.

5
Формально, входные-выходные данные процесса по BPMN - это коллекции элементов типа Artifact, которые задаются тегами InputSets / OutputSets соответственно. У меня сейчас под рукой нет EA, так что я не помню, поддерживаются ли там такие тэги, но, по-моему они там недореализованы, а именно: теги-то есть, но элементы модели к ним привязать нельзя. Я, впрочем, могу ошибаться - поробуйте. Я не пользовалась ими по простой причине: передо мной стояла цель получить визуальную репрезентацию процессов для обсуждения их с бизнес-пользователями. В EA теги на диаграмму не вытащить, во всяком случае штатными средствами я не смогла, т.е. на автомате связности модель-диаграмма не достичь.
С перегруженностью диаграммы бороться, как мне видится, можно только одним способом - не показывать потоки данных на BPMN диаграмме. Вместо этого:
1. Иметь их только в свойствах процесса - если получится то, что я написала выше.
2. Если все же хочется видеть потоки данных, то сделать отдельную диаграмму потоков данных. Процессы на ней могут быть представлены теми же элементами модели, что на диаграмме BPMN - это EA сможет. DFD специально под это заточена, на ней можно и кусочки данных показывать, т.к. их визуальная репрезентация - это надписи на стрелках, а не прямоугольники, как в BPMN. В EA начиная с какого-то билда есть DFD, но у меня вот, например, более старая версия, так что я изображала DFD с помощью элементов Activity diagram. Кусочки данных в модели представлены как Information object, их можно привязать к flow, на диаграмме это - текст на стрелке. Выглядит вполне приемлемо.

С InMessage / OutMessage история примерно такая же, как с Input/OutputSets. В этом случае в EA точно можно создать message, как элемент модели ну и прописать его в тег, как полагается по спеке BPMN.

6
Да, с точки зрения нотации BPMN, можно привязать Data object к sequence flow или message flow, если выход одной активности является входом другой.
EA этого не умеет. Поэтому в EA, если все же хочется иметь кусочек данных как элемент модели, а не просто как название стрелки на диаграмме, то направленные ассоциации - единственный вариант, который я нашла. И - да, если пытаться аккуратно показать все документы или, тем более - значимые кусочки данных, то диаграмма тут же становится нечитаемой.
Про генерацию доки я не очень поняла: чем Вы ее генерите и с какой целью? Если цель моделирования - получить картинки, которые могут служить подмогой при разговоре с пользователями об их бизнес-процессах, то, на мой взгляд, правильно то решение, которое делает диаграмму легко читаемой. Если же речь о BPM, то тогда все сложнее. Но в этом случае правила игры должны формально определяться инструментом, который предполагается использовать.

7
По спецификации в этом случае следует использовать Data object c направленной ассоциацией: 9.7.2, Figure 9.36

8
Если у вас исполнитель и руководитель - это разные pools, то предыдущий фрагмент - это то, что будет в pool'е руководителя. А последовательность действий исполнителя будет выглядеть подобно фрагменту в спецификации BPMN, иллюстрирующему использование Exception Flow (п. 10.2.2, рис. 10.54).

Страницы: 1