UML&Enterprise Architect: проектируем целевой процесс при создании автоматизированной системы

ну т.е. в одной дорожке то что делает пользователь, в другой то, что делает система и т.п.?

Есть разные варианты нотаций. А есть нюансы EA в отображении диаграмм :)
И есть более удобные способы отображения процессов

Заметки по поводу использования Swimlanes — «Плавательных дорожек»

Для начала цитаты из документации UML и EA.

UML

Цитата:
15.6.4.1 Activity Partitions
An ActivityPartition is notated with two, usually parallel lines, either horizontal or vertical, and a name labeling the partition in a box at one end. Any ActivityNodes and ActivityEdges placed between these lines are considered to be contained within the partition. This notation for an ActivityPartition is colloquially known as a swimlane, as shown in Figure 15.66(a). Swimlanes can express hierarchical partitioning by representing the subpartitions as further partitioning of the superpartition, as illustrated in Figure 15.66(b). Diagrams can also be partitioned multidimensionally, as depicted in Figure 15.66©, where each «swim cell» is an intersection of multiple partitions.

Перевод цитаты:
15.6.4.1 Разделы диаграммы Activity
ActivityPartition обозначается двумя, обычно параллельными линиями, горизонтальными или вертикальными, и именем, обозначающим раздел в поле на одном конце. Любые моделирующие элементы ActivityNodes и ActivityEdges, размещенные между этими линиями, считаются содержащимися в этом разделе. Это обозначение для ActivityPartition, в просторечии известное как swimlane, как показано на рисунке 15.66(a). Плавательные дорожки могут выражать иерархическое разделение, представляя подразделы как дальнейшее разделение, как показано на рис.15.66(b). Диаграммы также могут быть разделены многомерно, как показано на рисунке 15.66 ©, где каждая «swim cell», «плавательная ячейка», является пересечением нескольких разделов.

И только в одном примечании в документации UML есть довольно явное указание на использование дорожек (п.15.2.5, стр.383):

Еще одна цитата:
NOTE. The swimlanes are an important feature for indicating senders and responders.

И ее перевод
ПРИМЕЧАНИЕ. Плавательные дорожки являются важной особенностью (возможностью/ характеристикой) [языка] для обозначения отправителей и получателей [сообщений/ информации/ потока управления].

ЕА

Цитата:
Swimlanes are vertical or horizontal bands in a diagram that divide the diagram into logical areas or partitions. You can apply them to all Enterprise Architect diagram types. Activities relating to particular entities within the model (such as the User, or the back end Repository) can be placed within the same Swimlane to indicate their association.

Перевод цитаты
«Плавательные дорожки» — это вертикальные или горизонтальные полосы на диаграмме, которые разделяют диаграмму на логические области или разделы. Их можно применить ко всем типам диаграмм Enterprise Architect. Действия, относящиеся к определенной сущности в модели (например, пользователь или серверное хранилище), могут быть помещены на одну и ту же дорожку, чтобы показать их связь с данной сущностью.

Смотрите, что получается: в документации ЕА приведен пример «специализации» дорожек – «Действия, закрепленные за сущностями». Но это только один из способов структурирования диаграммы! Мы не нарушим нотацию, если закрепим за дорожками другие «специализации», например, такие: «Входные и выходные артефакты», «Шаги процесса», «Участники процесса» и т.д.
Нет на этот счет запретов ни в языке, ни в инструменте! Попробуйте! А вдруг Вам тоже такой способ структурирования подойдет?
Диаграммы Activity в моих примерах используются для сбора информации о процессе, который мы будем автоматизировать и о котором мы, когда приступаем к работе, не очень много знаем (т.е. если Вы разрабатываете 1001-ую систему для данной предметной области, оно Вам, может, и не нужно, хотя и в этом случае — не факт). По отношению к процессу мы выступаем в роли сторонних наблюдателей, собираем информацию: кто и что делает, в какой последовательности, что использует для работы, какие документы использует, а какие «порождает», есть ли доп.правила, при этом стараемся сразу структурировать добытую информацию — раскладываем по полочкам — Swimlanes нам в помощь. Такое формализованное описание процесса поможет нам выявить требования к будущей системе.

Не пытаюсь никого «обратить в свою веру», но призываю не следовать слепо «догме», тем более, что судя по документации ее и нет вовсе:)

И еще маленький комментарий вот на это замечание:

Ведь на сколько я понимаю принцип дорожек именно в разделении границ между взаимодействующими сторонами, ну т.е. в одной дорожке то что делает пользователь, в другой то, что делает система и т.п.?

Ваше замечание как раз перекликается со 2-ой цитатой из документации UML (см.выше).
И такой подход к структурированию диаграммы Activity: «Действия пользователя», «Действия системы», — мы тоже периодически применяем в своих проектах, но уже на следующих этапах проектирования, когда описываем автоматизированные функции (как правило, это происходит на этапе эскизного или технического проекта).

P.S. Очень хотелось схулиганить и написать в заметке: «Вы просто поверьте, а поймете потом».:) Но взяла себя в руки и написала более серьезный обоснованный ответ.


P.P.S. Кажется, набирается материал на самостоятельную статью.:) Спасибо Вам!

Нет, без ТЗ никак, модель не может заменить ТЗ. На мой взгляд, модель позволяет систематизировать собранную информацию о том, что собираемся автоматизировать, и помогает написать адекватное ТЗ. Диаграммы, как правило, в ТЗ тоже приводим, а еще с помощью макросов, например, можно сгенерировать кое-какое дополнительное описание по модели. Можно, конечно, и просто текстовое описание процесса дать, но, по мне, так с помощью диаграмм нагляднее получается. Но это все безусловно дело вкуса и привычки. Если моделирование занимает много времени, ну, значит, или инструмент не тот выбрали, или методика хромает. У меня в статьях: и про «сказки», и про реальную жизнь, — предусматривается переход от шагов процесса к требованиям и функциям системы, при этом трассировка сама собой получается — всегда понятно, та или иная функция с чего вдруг «придумана». Но не могу сказать, что сначала модель, а только потом ТЗ. Модель начинаем разрабатывать до написания ТЗ, а потом продолжаем развивать, добавляя архитектурные аспекты. Резюмирую: модель и классическое ТЗ друг другу не противопоставляем, а стараемся взаимополезно сочетать.