Доброго времени суток   
Сделал диаграмму деятельности для Варианта использования "Оформление заказа" в интернет-магазине.
Делал я ее по спецификации диаграммы вариантов использования.
Подскажите, пожалуйста, нормальная ли она, а то по смыслу она мне кажется похожей на диаграмму последовательностей уже.
И если все же верно, то нужно ли из спецификации брать в эту диаграмму альтернативные потоки?

Первое формальное отличие диаграммы последовательности в том, что в ней есть временная ось ("линии жизни"), по которой нельзя двигаться назад. Эта диаграмма кажется вам похожей на диаграмму последовательности только потому, что в ней нет ни одного цикла.
(В принципе, на диаграмме последовательности можно изображать циклы как вложенную диаграмму, но лучше не надо. Пример здесь: http://www.ibm.com/developerworks/rational/library/content/RationalEdge/feb04/3101_figure10.html )
Второе формальное отличие в том, что на линии жизни объекта не должно быть действий, которые объект не выполняет. То есть вам нужно было бы нарисовать две разных диаграммы последовательности для случаев "клиент выбирает удалить товар" и "клиент выбирает оформить заказ".

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

Даниил,

1. первая точка принятия решения ведет к одному и тому же действию, какой смысл в разделение веток?
2. в "отображение  содержимого корзины и стоимости" входит 3 стрелки, это не очень верно, поскольку, чтобы решить сливаются ли три разных параллельных потока или это просто передача управления из разных мест можно понять, только просмотрев всю диаграмму. Т.е. было бы полезно разместить тут merge - пр и этом алгоритмически там цикл, пока происходит редактирование корзины (удаление товаров из корзины) - пересчитывать отображеие содержимого корзины и стоимости.
3. около начального псевдосостояния я бы поместил текст предусловия
4. около конечный псведостостояний я бы разместил текст постусловий
5. Отмена выполнения заказа может возникнуть сразу как только вы начали оформлять заказ

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

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

1. Перенес условие после опции "оформить заказ" к клиенту. Думаю так верно. На форме отображается выбор, например "Я уже совершал покупки" и "Это моя первая покупка". Соответственно исходя из выборка клиента будет отображена определенная форма.
2. На две части все поделено потому как отображается запрос клиента и ответ системы и наоборот. Не знаю честно говоря как объединить это в одно действие, а было бы не плохо, а то диаграмма уж очень большая становится.

Даниил,

1. первая точка принятия решения ведет к одному и тому же действию, какой смысл в разделение веток?
2. в "отображение  содержимого корзины и стоимости" входит 3 стрелки, это не очень верно, поскольку, чтобы решить сливаются ли три разных параллельных потока или это просто передача управления из разных мест можно понять, только просмотрев всю диаграмму. Т.е. было бы полезно разместить тут merge - пр и этом алгоритмически там цикл, пока происходит редактирование корзины (удаление товаров из корзины) - пересчитывать отображеие содержимого корзины и стоимости.
3. около начального псевдосостояния я бы поместил текст предусловия
4. около конечный псведостостояний я бы разместил текст постусловий
5. Отмена выполнения заказа может возникнуть сразу как только вы начали оформлять заказ

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

1. Случайно не в то действие стрелку выбора направил. Исправил теперь. Спасибо за внимательность.
2. Merge это я так понимаю слияние ? Оно в MS Visio выглядит так же как и "выбор решения". Единственное, что у него наверное будет один выход а входов несколько, обратное действие то есть "решению". Только вот в нем только 4 точки куда можно сделать вход/выход, а что если у меня больше входов будет?
3,4. Сделал комментарии.
5. Да, отмена заказа по сути в любое время может быть. Я решил на диаграмме ее изобразить только один раз в самом конце, иначе целая куча еще будет стрелок и "решений".

Вот исправленный вариант.

Попробовал со слиянием.
Прошу еще раз посмотреть, оценить правильность.

Попробовал со слиянием.
Прошу еще раз посмотреть, оценить правильность.

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

1. Зачем вообще понадобилась дорожка "Клиент"?
Активности типа "Ввод данных для регистрации" и "Отображение формы регистрации" я бы объединил во что-то типа "Ввод регистрационных данных в форму регистрации".
Насколько я вижу, все активности на диаграмме сейчас образуют такие пары. Т.е. никакого дополнительного смысла от такого разделения не проявляется. Диаграмма упростилась бы.

Если уж и делать дорожки, то по формам это было бы понятнее. Т.е. будет дорожка "Магазин", "Корзина", "Оформление заказа", "Авторизация", "Регистрация".

2. "Заказ отправлен на исполнение" звучит как состояние, а не как активность. Нужно по другому назвать.

3. В алгоритме пропущено много веток. Что например будет, если клиент не успешно авторизовался?

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

Что значит более явно выделить условный выбор?
По факту клиент возвращается в корзину ,если отменяет оформление, ведь он может отменить для корректировки заказа.

1. Зачем вообще понадобилась дорожка "Клиент"?
Активности типа "Ввод данных для регистрации" и "Отображение формы регистрации" я бы объединил во что-то типа "Ввод регистрационных данных в форму регистрации".
Насколько я вижу, все активности на диаграмме сейчас образуют такие пары. Т.е. никакого дополнительного смысла от такого разделения не проявляется. Диаграмма упростилась бы.

Если уж и делать дорожки, то по формам это было бы понятнее. Т.е. будет дорожка "Магазин", "Корзина", "Оформление заказа", "Авторизация", "Регистрация".

2. "Заказ отправлен на исполнение" звучит как состояние, а не как активность. Нужно по другому назвать.

3. В алгоритме пропущено много веток. Что например будет, если клиент не успешно авторизовался?

1. На дорожки разделил, чтобы было видно работу клиента и системы. Как сделать одной дорожкой, не могу представить себе, если честно (
2. Назову "Отправка заказа на исполнение".
3. Да, ветки пропущены, это альтернативные потоки...если каждый учесть то места не хватит...нужно тогда как-то диаграмму разделить.

Что значит более явно выделить условный выбор?
По факту клиент возвращается в корзину ,если отменяет оформление, ведь он может отменить для корректировки заказа.

вертикально и с двумя левыми и правыми ветками.

Что значит по факту? по какому факту, вы требования описывает или то как сейчас работает система? если как сейчас - это одно, если придумываем, то это может быть навязыванием решения. кмк

вертикально и с двумя левыми и правыми ветками.

Что значит по факту? по какому факту, вы требования описывает или то как сейчас работает система? если как сейчас - это одно, если придумываем, то это может быть навязыванием решения. кмк

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

Попробовал со слиянием.
Прошу еще раз посмотреть, оценить правильность.

На диаграмме есть лишний поток управления от "удалить товар" к "оформлению заказа".
Пока клиент не зарегался / не авторизовался, не ясно как определить были ли у него раньше покупки или нет. Разумно предложить клиенту авторизоваться либо зарегаться и после его выбора выводить нужную форму.
Не вижу смысла сначала вводить адрес доставки, а затем выбирать её способ. Например, если способ = самовывоз, может не понадобится вводить адрес. Вероятно, следует поменять местами, либо объединить.
У диаграммы лишь одни финальный узел, т. е. у ВИ лишь один возможный исход -- успешное оформление заказа. Заказ нельзя отменить, авторизация всегда успешна, регистрация всегда успешна. Разумно показать на диаграмме неуспешные завершения и альтернативные потоки, ведущие к ним.
Нигде нет сторожа, проверяющего, что заказ оформляется по непустой (после удалений товаров) корзине. Аналогично, нет сторожа для удалений из пустой корзины.

На диаграмме есть лишний поток управления от "удалить товар" к "оформлению заказа".
Пока клиент не зарегался / не авторизовался, не ясно как определить были ли у него раньше покупки или нет. Разумно предложить клиенту авторизоваться либо зарегаться и после его выбора выводить нужную форму.
Не вижу смысла сначала вводить адрес доставки, а затем выбирать её способ. Например, если способ = самовывоз, может не понадобится вводить адрес. Вероятно, следует поменять местами, либо объединить.
У диаграммы лишь одни финальный узел, т. е. у ВИ лишь один возможный исход -- успешное оформление заказа. Заказ нельзя отменить, авторизация всегда успешна, регистрация всегда успешна. Разумно показать на диаграмме неуспешные завершения и альтернативные потоки, ведущие к ним.
Нигде нет сторожа, проверяющего, что заказ оформляется по непустой (после удалений товаров) корзине. Аналогично, нет сторожа для удалений из пустой корзины.

1. Лишний поток убрал, не заметил сразу, спасибо.
2. Клиент сам определяет были у него покупки или нет. На форме "оформление заказ" будет такой выбор. Далее клиент один из вариантов выбирает и т.д.
3. Доставка. Сначала ввод адреса, потому что исходя из адреса будет выдаваться способ доставки. Например если по такому-то адресу нет курьерской доставки, на форме она и не появится. Если наоборот сделать, то после того как клиент ввел адрес, а на него нет курьерской доставки, выдавать ошибку и возвращать к выбору доставки.
Если смотреть, как я сделал, сначала адрес, а потом способ доставки, то даже при самовывозе, адрес моно просто не учитывать потом, а внести его в базу как и контактные данные, вдруг клиент потом решит еще раз заказать и не самовывозом, а тут раз и все автоматом заносится.
4. Альтернативные потоки я сделаю чуть позже, я про них помню )) Сейчас пока преподаватель принял как есть (не думаю что он вообще проверял что-то). А вот когда буду пояснительную записку писать, обязательно учту альтернативные потоки.
Кстати вопрос по альтернативным потокам: отказаться от оформления заказа можно в любой точке в момент его оформления, получается будет много много стрелок к возврату в корзину...