Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: Galogen от 02 Июня 2009, 13:05:41
-
Хочу привлечь посетителей форума к данной проблеме.
Диаграмма последовательностей одна из наиболее используемых диаграмм. Однако как, когда и почему следует использовать эту диаграмму далеко неясно.
Предлагаю обсудить правила использования таких диаграмм на живых примерах, и написать одну или несколько статей по этому поводу
-
ИМХО Д Последовательности можно использовать на 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. можно ли. али таки нельзя посылать сообщения от классов-форм классам-сущностям
Вопрос к Денису Иванову:
Ты сказал что между ДП и Диаграммой деятельностью - много общего (ну или много отображаемое на ДП, можно отобразить на ДД без потери смысла - так я понял? ) Нельзя пример?
-
Вот смотрите. У вас есть клиент, который шлет запрос на сервер. Имеем два экземпляра чего-либо (клиент и сервер) и посылаем между ними сообщения.
Клиент может либо получить ответ, либо вылететь по тайм-ауту, либо еще как-то. Все это - отдельные диаграммы последовательности.
Но на диаграмме последовательности нельзя нарисовать ситуацию, когда клиент вдруг начинает вести себя неадекватно. Например, посылать запросы не дождавшись ответа, т.е. совершать действия не предусмотренные протоколом.
Вернее сделать-то это можно, но количество неадекватных действий очень велико и показывать их нет смысла.
В нашей области (авторизация запросов по банковским картам) этот подход используется очень широко. Есть клиент (терминал) и сервер (авторизационный хост), который, в свою очередь, является клиентом другого сервера (платёжной системы). Авторизация представляет собой цепочку сообщений (запросов и ответов), инициируемых терминалом. При этом могут возникать разные ситуации - потери связи, таймауты ожидания, повторные сообщентия и т. п.
На каждый такой случай в спецификации протокола обмена рисуется отдельная диаграмма. Понятно, что абсолютно все случаи редусмотреть невозможно, но всегда есть набор, покрывающий по вероятности абсолютное большинство возможных ситуаций.
-
greesha, мне интересно посмотреть на вашу диаграмму последовательности, когда клиент посылает повторные сообщения, а особенно ситуацию, когда повторный запрос где-то там сталкивается с ответом на первый запрос.
Я бы так представил это. Есть ПРОТОКОЛ - конечный набор НЕЗАВИСИМЫХ хороших и плохих ситуаций, возникающих при взаимодействии нескольких элементов системы. Каждую такую ситуацию можно описать ДП. Некоторые ситуации можно описать и одной ДП, если они не сильно отличаются. Но в общем случае суперпозицию нескольких ситуаций нельзя описать ДП. Мы получим то, что вот тут изображали (http://www.uml2.ru/forum/index.php?topic=1281.msg14021#msg14021)
Эти суперпозиции конечно имеют место быть, но описываются они другими средствами. Например, задачу, которая поставлена в начале этого сообщения я могу решить только с помощью диаграмм деятельности или автомата.
-
Ты сказал что между ДП и Диаграммой деятельностью - много общего (ну или много отображаемое на ДП, можно отобразить на ДД без потери смысла - так я понял? ) Нельзя пример?
Это действительно можно сделать в большом количестве случаев. В основном за счет составных шагов взаимодействия.
Эдуард, давай так поступим. Ты даешь пример диаграммы деятельности или автомата, а я рисую диаграмму последовательности (или объясняю почему в данном конкретном случае этого нельзя сделать:) )
-
greesha, мне интересно посмотреть на вашу диаграмму последовательности, когда клиент посылает повторные сообщения, а особенно ситуацию, когда повторный запрос где-то там сталкивается с ответом на первый запрос.
Всё хорошее, что у меня есть, мы получили под NDA. А в том, что распространяется свободно, нет ничего достойного внимания.
Но одно могу сказать сразу: формально нотации UML эти диаграммы не соответствуют, хотя при желании их можно однозначно отобразить на "правильные" диаграммы последовательности.
Доберусь до работы - попробую найти что-нибудь несекретное.
-
Выглядит это примерно вот так.
-
Эдуард, давай так поступим. Ты даешь пример диаграммы деятельности или автомата, а я рисую диаграмму последовательности (или объясняю почему в данном конкретном случае этого нельзя сделать:) )
Давай наоборот? :)
Вот несколько примеров из книги UML2 и унифицированный процесс Джима Арлоу и Айла Нейштадта
-
Зачем нужны диаграммы последовательностей?
По материалам Факультета Прикладной математики (http://mosoi.mitme.ru/)
ДП создаются с тремя следующими целями.
Нужно наделить классы поведением. Классы были выделены во время робастного анализа. На этапе построения ДП контроллеры превращаются в методы классов. Однако не обязательно должно быть соответствие 1:1 между контроллерами и методами. Часто контроллер превращается в два или более метода. Также возможно, что контроллер станет управляющим классом.
Нужно подробно показать, как классы взаимодействуют между собой при выполнении сценария.
Нужно завершить распределение методов между классами. Во время робастного анализа должна была быть выявлена большая часть атрибутов классов и небольшая часть методов. Можно сказать, что мы применяем двухпроходный алгоритм. На этапе предварительного проектирования нужно было думать, в основном, о выделении атрибутов сущностей. При этом на вопрос «кто что с кем делает» ответ не давался. Второй проход как раз дает ответ на этот вопрос.
Замечание 1. Сообщения, методы, функции, глаголы и контроллеры – всё это по описывает одно и то же – поведение, которым вы наделяете класс. В этом как раз помогает диаграмма последовательностей.
Замечание 2. UML 2.0 позволяет изобразить на диаграмме последовательностей алгоритм полностью. Но этого не стоит делать, поскольку это отвлечет от основной цели, для которой мы применяем ДП. Поскольку нашей задачей является получение программного обеспечения на основе вариантов использования, то важно правильно наделить классы поведением. Следовательно, на диаграммах последовательностей должно быть видно, что эта задача решена правильно. Если вы сосредоточитесь на составлении алгоритма, то с большой вероятностью не решите задачу правильного распределения операций между классами.
Составим диаграмму последовательностей: 4 основных этапа (см. вложение)
-
Не будет ли точнее заменить "поведение класса" на "обязанности класса"? Также, мне кажется, что у диаграмм последовательности есть и другие назначения.