Подскажите начинающему аналитику, прочитавшему умную книжку, но ничего не понимающему на практике:
Диаграммы последовательностей и действий используются для разных целей или они взаимозаменяемые?
Если нет, то для каких задач больше подходит диаграмма последовательностей и для каких диаграмма действий.

Спасибо!

Прагматика использования естественно разная. Однако одну и ту же информацию можно изобразить на этих диаграммах. Но не следует я думаю смешивать семантику.

ДД - это дань блок-схемам, семантика - сети Петри. Идеально подходить для описания алгоритмов (например реализаций операций), но не только. Но никак не приближает к объектной реализации

ДП - диаграмма взаимодействия, показывает последовательность (протокол) взаимодействия объектов и естественно приближает нас максимально к объектной реализации

Большое спасибо за ответ.
Я понял следующее:
1. Чисто теоретически, любой процесс или операция могут быть изображены и с помощью ДП и с помощью ДА.
2. ДП более ОО. Линии жизни, по сути, это аналитические классы. Из ДП гораздо проще будет построить проектную модель, т.к. классы и их взаимодействие уже подробно описаны.

2. ДП более ОО. Линии жизни, по сути, это аналитические классы. Из ДП гораздо проще будет построить проектную модель, т.к. классы и их взаимодействие уже подробно описаны.

Линия жизни - вовсе не аналитический класс, а именно линия жизни, т.е. некая продолжительность существования конкретного объекта. Не класса - класс - это спецификация, тип, он существовать не может. Его реальное воплощение - это объекты.
В целом да, более того ДП заточена на выявление операций класса и кроме того показывает фрагменты поведения при взаимодействии наиболее явным для ООП образом

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

Давно дело было. Может быть это уже не интересно. Но я хотел бы добавить к выступлениям предыдущих ораторов еще один аспект.
Можно вполне выкинуть из названия темы "vs":

Хотя в UML2 диаграмма последовательности существенно расширена и ее уже никак нельзя назвать диаграммой сценариев (сценарий ифов иметь не может, это детерминированная последовательность), но все же описание логики процесса очень перегружает. Для машины - это не препятствие (различного рода преобразования MDA, в том числе кодогенерация). Но для человека - это кошмар!

В UML2 есть новая диаграмма. Я перевел ее название как "диаграмма обзора взаимодействий". Как на английском - не помню. Может быть я ошибаюсь, мне кажется, что ни в одном из инструментов моделирования она "впрямую" не реализована. Я упоминаний не встречал.

Что я делаю для борьбы со сложностью (на Rational Software Architect):
- верхний уровень процесса я представляю в виде диаграммы деятельности, узлы которой - вызываемые поведения
- вызываемые поведения, в зависимости от сложности, раскрываю с помощью деятельностей или взаимодействий
- двойной щелчок по узлу диаграммы деятельности "проваливает" в диаграмму, которая описывает соответствующую вызываемую деятельность или взаимодействие.
Очень удобно.

Должен заметить еще, что диаграмма деятельности в UML2 существенно приблизилась к ОО: потоки (разделы) представляют экземпляры классов. Вопрос выбора - скорее вопрос традиций.
Общепринято, что чем ближе к коду, тем проще выглядит диаграмма последовательности (за счет декомпозиции процессов на верхних уровнях).

http://lnew.ucoz.ru

Одно и то же поведение может быть описано разными диаграммами. В зависимости от используемой диаграммы будут визуализированы разные аспекты этого поведения. Диаграмма последовательности визуализирует взаимодействие в рамках описываемого поведения, при чём выражает его в виде обменов сообщениями. Диаграмма деятельности визуализирует потоки управления и/или данных в рамках описываемого поведения, выражая их в виде действий и управления. Получается что два типа диаграмм дают два вида проекций. Разные проекции одного и того же поведения могут быть схожи до такой степени, что по потокам управления можно догадаться и/или "прочесть между строк" о том, каким будет взаимодействие. В другую сторону это тоже может быть справедливо. Но это не всегда так. Проекции могут существенно расходится.
Алгоритм, реализация операции могут быть описаны в обеих проекциях.
Выбор типа диаграммы определяется задачей, но это не задача, сформулированная так: "смоделировать алгоритм / операцию / что-то ещё". Это задача в формулировке которой указано, какой аспект важен: передача управления и/или данных между отдельными шагами или обмен сообщениями между объектами.