В чем же сходство?

В использовании одних и тех же элементов – ролей/акторов, дорожек и действий.

Смотря на такую диаграмму сразу хочется прочитать надписи на стрелках.

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

Вообще imho чем меньше текста на диаграмме, тем лучше.
 
Кстати, в учебниках по банковскому делу для таких описаний используют подобие Collaboration Diagram - на мой взгляд, худшей из всех диаграмм в истории UML. Примерно как на картинке. Очень жалко бедных студентов, которые по таким картинкам пытаются разобраться.

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

Вообще imho чем меньше текста на диаграмме, тем лучше.
 
Кстати, в учебниках по банковскому делу для таких описаний используют подобие Collaboration Diagram - на мой взгляд, худшей из всех диаграмм в истории UML. Примерно как на картинке. Очень жалко бедных студентов, которые по таким картинкам пытаются разобраться.

И всё же для меня остаётся непонятным, зачем использовать для целей указания последовательности действий Sequence вместо Activity diagram. Тем более что Activity больше похожа на обычую схему алгоритма и ветвления на Activity изображаются более лаконично и наглядно. Это более знакомо и привычно. Как студентам/выпускникам тех. вузов, так и тем, кто уже "вырос".  А в случае применения sequence мы изобретаем новую нестандартную диаграмму, хотя есть стандартизованные аналоги.

И всё же для меня остаётся непонятным, зачем использовать для целей указания последовательности действий Sequence вместо Activity diagram. Тем более что Activity больше похожа на обычую схему алгоритма и ветвления на Activity изображаются более лаконично и наглядно. Это более знакомо и привычно. Как студентам/выпускникам тех. вузов, так и тем, кто уже "вырос". 

В данном случае, как я понял из исходного поста, важно в первую очередь показать порядок действия нескольких пользователей и систем. Для этого лучше всего использовать дорожки.

Activity Diagram, корни которой лежат в блок-схеме алгоритма, лучше всего подходит для показа последовательности действий "в одном потоке". Хотя её тоже можно нарезать на столбцы, как на приведенном рисунке, но в этом случае получается примерно то же самое, что я предлагаю. При этом столбцы  содержат больше визуального мусора.

А в случае применения sequence мы изобретаем новую нестандартную диаграмму, хотя есть стандартизованные аналоги.

Что значит "стандартизованные"? Если речь об UML, то в нём слишком много элементов, причём назначение некоторых трудно понять, специально не изучая язык. Если нельзя исходить из того, что все, кто будет пользоваться диаграммой, знакомы с UML, то нужно использовать самые простые и интуитивно понятные элементы. "Дорожки" imho являются как раз таким элементом.

Вот пожалуйста

Спасибо! Перерисовал, получается примерно так.

В данном случае присутствует роль, не выполняющая никаких действий. При этом она является неотъемлемой частью диаграммы, которая как раз и призвана продемонстрировать, что инкассовые поручения выполняются без участия владельца счёта, и повлиять на этот процесс он никак не может.

Хотя её тоже можно нарезать на столбцы, как на приведенном рисунке, но в этом случае получается примерно то же самое, что я предлагаю. При этом столбцы  содержат больше визуального мусора.

По-моему весь этот "визуальный мусор" наоборот акцентирует внимание на сути процесса, а также более привычен как тем, кто знает UML, так и тем, кто не знает UML, но знаком с блок-схемами алгоритмов. Сейчас мы можем скатиться к спору о вкусах:)

Что значит "стандартизованные"? Если речь об UML, то в нём слишком много элементов, причём назначение некоторых трудно понять, специально не изучая язык. Если нельзя исходить из того, что все, кто будет пользоваться диаграммой, знакомы с UML, то нужно использовать самые простые и интуитивно понятные элементы. "Дорожки" imho являются как раз таким элементом.

Если говорить о тех, кто ни разу не видел UML и блок-схемы алгоритмов, тогда я, возможно, согласился бы. Но таких, по моему опыту, мало. Всем остальным привычнее будет Activity диаграмма. Тем более что видов элементов Activity диаграмм очень немного. "Дорожки", как Вы сказали, также могут применяться с Activity диаграммой.

Гриша, но если построить активити диаграмму не как алгоритм, а как сценарий (который ты изображаешь малопонятной на мой взгляд диаграммой последовательности с придуманными от себя элементами), то вообще не понятно зачем ты завел речь о диаграмме последовательности.

Впрочем понятность или непонятность вещь субъективная и для ее оценки требуется научное исследование: описание небольшой задачи, изображение ее в виде разных диаграмм, формирование репрезентативной экспертной группы, проведение эксперимента оценивания: путем выбора лучшей диаграммы на взгляд эксперта; путем независимого оценивания уровня понятности каждой диаграммы отдельно

Гриша, но если построить активити диаграмму не как алгоритм, а как сценарий (который ты изображаешь малопонятной на мой взгляд диаграммой последовательности с придуманными от себя элементами), то вообще не понятно зачем ты завел речь о диаграмме последовательности.

А что, действительно получилось малопонятно? А чего, на твой взгляд, не хватает, чтобы было понятнее?

Речь о "диаграмме последовательности" я завёл только потому, что другого общепринятого названия для диаграммы с дорожками я пока не знаю. Хотя это название imho крайне неудачно (в UML вообще проблема с интуитивно понятными названиями диаграмм).

А чего, на твой взгляд, не хватает, чтобы было понятнее?

Григорий,

Изобразите пожалуйста пару гейтов "и/или" в Вашем варианте.

Давайте предположим, что "Снять деньги со счёта" не получилось по причине недостатка средств.
А потом ещё изобразим реакцию Получателя на отказ.

Интерес не праздный.
У меня реально ступор с этой диаграммой и именно из-за гейтов.

В скрепке - схема, которая реально лучше смотрелась бы на диаграмме последовательностей, но я пока не нашёл честного способа разделить потоки на условиях

Ну или вот ещё пример (скрепка).

Схема чисто саннидэй. По хорошему, нужно отобразить на ней проверки и ответы статусами "упешно/нет", но ни Sparx ни StarUml не предлагают готовых элементов "ветвление" для этой диаграммы (панель на скрине).

Какой тут бест-практис то ? ))

Ну или вот ещё пример (скрепка).

Схема чисто саннидэй. По хорошему, нужно отобразить на ней проверки и ответы статусами "упешно/нет", но ни Sparx ни StarUml не предлагают готовых элементов "ветвление" для этой диаграммы (панель на скрине).

Какой тут бест-практис то ? ))

Начал отвечать на предыдущий пост и тоже столкнулся с тем, что самые удобные редакторы не позволяют положить ромбик выбора на дорожку. Значит, опять буду рисовать в paint (На самом деле, в OpenOffice Impress)

Я подробно отвечу на предыдущий вопрос позже, а пока просто приложу ещё одну картинку.

Ну или вот ещё пример (скрепка).

Схема чисто саннидэй. По хорошему, нужно отобразить на ней проверки и ответы статусами "упешно/нет", но ни Sparx ни StarUml не предлагают готовых элементов "ветвление" для этой диаграммы (панель на скрине).

Какой тут бест-практис то ? ))

Андрей, на диаграмме последовательности да ветвления может использоваться элемент типа fragment, но от этого диаграмма, на мой взгляд, не становится более применимой для отображения потоков действий. Если бы я не знал Григория, то взглянув на диаграмму без дополнительных пояснений в первую очередь заподозрил бы незнание UML. А так это похоже на попытку изобрести свою нотацию с использованием элементов UML sequence diagram.

Андрей, на диаграмме последовательности да ветвления может использоваться элемент типа fragment, но от этого диаграмма, на мой взгляд, не становится более применимой для отображения потоков действий. Если бы я не знал Григория, то взглянув на диаграмму без дополнительных пояснений в первую очередь заподозрил бы незнание UML. А так это похоже на попытку изобрести свою нотацию с использованием элементов UML sequence diagram.

Это действительно попытка описать (не изобрести) простую нотацию. Причём довольно серьёзная, я эту нотацию скоро опубликую. Я считаю, что большинство концепций UML невозможно понять, не имея опыта программирования. Аналитику для общения с непрограммистами нужно что-то значительно более простое и интуитивно понятное. Вся мощь UML в большинстве случаев не нужна на уровнях более абстрактных, чем программный код и внутренняя архитектура программ.

Я только не согласен с тем, чтобы считать отдельные элементы неотъемлемой принадлежностью UML. UML возник не на пустом месте, а вобрал в себя множество давно существующих подходов и нотаций. А то, что сейчас любую диаграмму в первую очередь оценивают с точки зрения UML, я считаю проблемой. Да, в UML "всё есть". Но часто нам нужен только маленький кусочек того, что там есть, а приходится изучать всё - например, чтобы использовать инструменты, ориентированные на UML, как в нашем случае с EA (хочешь добавить элемент из другой диаграммы, а инструмент по умолчанию этого не позволяет).

Кстати, в lucidchart можно на дорожки класть любые элементы - там это очень удобно сделано.

А так это похоже на попытку изобрести свою нотацию с использованием элементов UML sequence diagram.

Это действительно попытка описать (не изобрести) простую нотацию.

Изобретение собственных нотаций - это вообще вполне нормальная практика на мой взгляд. Просто потому что универсальной нотации нет, а сколько людей- столько и остального.
Особенно это касается случаев устойчивых отношений бизнес-заказчиков и ИТ (характерно для "внутренних" ИТ-отделов и "старых добрых незаменимых" вендоров).
У меня у самого есть достаточно функциональный Набор элементов Visio (составлен из ряда стандартных и собственных иконок путём скрещивания правил BPMN и Функциональной блок-схемы с применением положительных свойств EPC).
Набор включает в себя:
Собственно элементы блок-схемы Visio
Элементы BPMN (гейты, старты, стопы с расширяющими иконками)
Иконки пользователей (одиночных и группы)
Иконки группы "компьютеры"
Иконки группы "транспорт"
Иконки документов (офис и прочее)
Хороший набор, позволяющий очень быстро набросать схему процесса для формального утверждения с пользователями, не искушенными в IDEF UML EPC BPM (далее по списку) и передачи в разработку с комментариями простым текстом.
Для небольших локальных задач - идеальная штука, а готовой нотации, включающей в себя все достоинства других, нет и не будет. Потому что сколько людей - столько и достоинств.

Но в данном конкретном случае я готов бодаться довольно долго.
Задача находится на уровне BPMN, ну или Activity-диаграммы UML. Там просто всё для этого есть.
Поэтому попытки изобрести некую новую сущность безусловно любопытны, но не более.
Повторюсь. В рамках данного конкретного вопроса.