Хочу привлечь посетителей форума к данной проблеме.

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

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

ИМХО Д Последовательности можно использовать на 4ех уровнях абстракции:
1. Взаимодействие между Бизнес актерами
2. Взаимодействие между Пользователями и Системой
3. Взаимодействие между компонентами или пользовательскими классами (VoPC)
4. Взаимодействие между классами приложения

Да, я чаще использую 2 и 3.

Спасибо за feedback. Ну кто еще откликнется кроме активистов:)

ИМХО Д Последовательности можно использовать на 4ех уровнях абстракции:
1. Взаимодействие между Бизнес актерами

Мне кажется для этого больше подойдет диаграмма деятельности с разделами. Хотя возможно и так. Интересно было бы вглянуть на образцы таких диаграмм

2. Взаимодействие между Пользователями и Системой

Это имеется в виду предложения Крэга Лармана о системных диаграммах последовательности, где есть два актора пользователь или кто-то внешний и собственно ее величество Система Черный Ящик?

3. Взаимодействие между компонентами или пользовательскими классами (VoPC)

Это я так понимаю классический путь использования?

4. Взаимодействие между классами приложения

Чеи 4 отличается от 3?

Процесс.
Абсолютно любой процесс, в котором участвует больше одного объекта.
Я их использую чаще всего из всех динамических диаграмм.

Очень интересно

Исключения: процессы с ветвлениями (уже обсуждалось). Можно показать только одну ветку.

А какже фреймы? Да и старые средства UML 1.x?

Однако хочу отметить, что, задавая вопрос, я имел в виду немного другое. Вернее получил пока ответ о том где или когда.

А вот как правильно. Поясню.

Есть набор вариантов использования, есть концептуальная диаграмма классов (домайн), есть какие-то дополнительные артефакты.

Приступаем к анализу. Делаем реализацию вариантов использования.
RUP советует сделать VOPC (view only participiant classes). А перед этим создать три пакета: Boundary, Controller, Entity.
По мере анализа в эти пакеты и на VOPC добавляются классы. Сначала классы-сущности из предметки. Далее как минимум один граничный класс на каждую коммуникацию между актором и ВИ. И как минимум один подходящий по названию управляющий класс - один на ВИ как минимум.
Далее строим диаграмму последовательности - размещая линии жизни из VOPC и читая описание ВИ, рисуем сообщения между объектами.

Далее когда переходим к проектированию сообщения преобразуем в методы.

Вероятно есть и иные пути. Тот же Дуг Розенберг особо не рекомендует использовать контроллеры.

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

Спасибо. И Предлагаю примеры, больше и разных. Я готовлю

Диаграмма последовательности описывает протокол взаимодействия. Ключевое слово - протокол.

Кстати Bas, во взаимодействии участвуют не действующие лица, компоненты и пр., а их экземпляры. Например, как заметила ida - объекты, т.е. экземпляры классов.

если такие примеры интересны - могу поискать. их много.

Публикуйте, конечно интересно.

Рисовать картинки для пояснения мысли можно разными способами. В том числе и ДП. Однако меня интересует не вопрос рисования картинки, а способ создания с помощью подобных диаграмм скажем так профессионального ПО.

Преимущества ОО парадигмы не возникают от того рисуем мы ДП или нет. Не возникают они и от того, что мы используем ОО подход и широко говорим об этом. Чтобы преимущества проявились их нужно продумывать и придумывать заранее.

Хотелось бы разобраться в этом самому и параллельно дать полезную информацию другим

Диаграмма последовательности описывает протокол взаимодействия. Ключевое слово - протокол.

Я знаю, ты любишь это слово. Можно ли попросить объяснить, что вкладывается в это понятие? Можно ли к примеру считать протоколом вариант использования?

Мне кажется для этого больше подойдет диаграмма деятельности с разделами. Хотя возможно и так. Интересно было бы вглянуть на образцы таких диаграмм

Можно так (ДП) и так (ДД). Саша Котельников рассказывал помнится, что он рисовал с помощью ДП регламенты в ЕА, а потом генерил текстовый вариант.

Это имеется в виду предложения Крэга Лармана о системных диаграммах последовательности, где есть два актора пользователь или кто-то внешний и собственно ее величество Система Черный Ящик?

Крега не помню, но думаю он тоже самое имел в виду.

Это я так понимаю классический путь использования?

Классика? У нас есть уже и "классический путь использования"? Мне казалось, что все лепят на ЮМЛ что могут ...

Чеи 4 отличается от 3?

А тем, что VoPC ( кстати пишется вроде так - View of Participant Classes) это не всегда классы приложения, например, тот же контрол может преобразовываться в несколько Классов приложения.

Протокол - ЗАРАНЕЕ определенная последовательность сообщений, которая может быть зафиксирована в модели, например, на диаграмме последовательности.

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

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

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

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

Да, еще хотел уточнить Иду про альтернативные потоки, их действительно трудно показывать на ДП, но можно делать две ДП, на одной из которых показывают Основной поток событий, а на второй альтернативный или исключение. Особенно это актуально для детализации СВИ (VoPC), когда мы хотим показать основной поток событий и альтернативный\исключение.
К сожалению, в это случае приходится повторять ДП основного потока для исключения, но по дрогу сделать нельзя. Или я не умею?

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

К сожалению, в это случае приходится повторять ДП основного потока для исключения, но по дрогу сделать нельзя. Или я не умею?

Можно нарисовать ДП, а потом на нее ссылаться в другой ДП. Встроенная ДП рисуется как рамка с тегом ref.

Денис,

А можешь выложить пример ДП где внутри (где-то по середине процесса\протокола) есть встроенная ДП

Денис,
А можешь выложить пример ДП где внутри (где-то по середине процесса\протокола) есть встроенная ДП

http://blog.it-konsulting.spb.ru/?p=249

Очень интересный результат. 4 участника дискуссии. Один из, которых специалист по UML. Трое скорее любители. Больше участников нет.

Или остальные прекрасно понимаю как и зачем использовать ДП, либо совершенно не понимают что это такое?

Что-то мне подсказывает, что последняя группа, вероятнее.

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

Не могу научить использовать это студентов. Ловлю часто себя на мысли, что и сам не использую ЭТО. Поскольку другие подходы быстрее и очевиднее.

Как я понимаю ДП:
1. средство визуализации (детализации) реализации ВИ
2. средство определения операций классов
3. средство анализа для уточнения классов, их структуры, взаимодействия
4. средство распеределения обязанностей согласно некоторым заданным принципам = например GRASP

Что непонятно:
1. как увязать сообщение с событиями (событиями интерфейсов, событиями классов)
2. как объяснить народу зачем нужен класс-сущность (если к примеру можно просто сделать запрос в БД, ну и т.п.)
3. можно ли. али таки нельзя посылать сообщения от классов-форм классам-сущностям

Вопрос к Денису Иванову:
Ты сказал что между ДП и Диаграммой деятельностью - много общего (ну или много отображаемое на ДП, можно отобразить на ДД без потери смысла - так я понял? ) Нельзя пример?

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

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

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

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

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