2. Клиент сам определяет были у него покупки или нет. На форме "оформление заказ" будет такой выбор. Далее клиент один из вариантов выбирает и т.д.

Соответствующие действия клиента есть только в Вашем тексте, их нет на диаграмме.

3. Доставка. Сначала ввод адреса, потому что исходя из адреса будет выдаваться способ доставки. Например если по такому-то адресу нет курьерской доставки, на форме она и не появится. Если наоборот сделать, то после того как клиент ввел адрес, а на него нет курьерской доставки, выдавать ошибку и возвращать к выбору доставки.
Если смотреть, как я сделал, сначала адрес, а потом способ доставки, то даже при самовывозе, адрес моно просто не учитывать потом, а внести его в базу как и контактные данные, вдруг клиент потом решит еще раз заказать и не самовывозом, а тут раз и все автоматом заносится.

Дело Ваше.

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

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

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

В языке есть средства, чтобы обойтись одной стрелкой.

Приветствую участников форума!

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

Вот сам юз кейс:

UC -  3. Оформление заказа.
ОДЛ: авторизованный пользователь.
Уровень: пользовательский.

Основное направление:

Оформление с оплатой наличными
1.   ОДЛ отдает команду оформить заказ.
2.   Система отображает форму оформления заказа (рис. 1) и запрашивает данные:  адрес доставки и способ доставки (самовывоз или курьер).
3.   ОДЛ вводит данные.
4.   Система отображает итоговую сумму заказа c  учетом выбранного способа доставки.
5.   Система предлагает выбрать способ оплаты: картой или наличными курьеру.
6.   ОДЛ выбирает оплату наличными.
7.   ОДЛ подтверждает оформление заказа.
8.   Система отправляет заказ на выполнение (UC -5).

Альтернативное направление:

Оформление с оплатой картой

6. ОДЛ выбирает оплату картой
7. Выполняется оплата картой  (UC -4).
8. Переход на шаг 7 основного направления.

Этот юз кейс в контексте других - в прикрепленном файле.  Диаграмма ниже:

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

Тут только нужно очень аккуратно работать с предусловиями и постусловиями. Т.е. например вы завершаете основной сценарий переходом к UC5, но по идее к чему приводит UC3?

Что будет по завершению UC3, проблемах в UC5, может быть UC5 исполнен отдельно?

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

Тут только нужно очень аккуратно работать с предусловиями и постусловиями. Т.е. например вы завершаете основной сценарий переходом к UC5, но по идее к чему приводит UC3?

Что будет по завершению UC3, проблемах в UC5, может быть UC5 исполнен отдельно?

Я начал делать с диаграммы вариантов использования. К базовым ВИ напиал спецификации. И по ВИ "Оформление заказа" теперь делаю диаграмму деятельностей.
Я в начале темы написал, что делаю по спецификации данную диаграмму, а не просто из головы.
Единственное, что сюда не выложил ее.

Я в начале темы написал, что делаю по спецификации данную диаграмму, а не просто из головы.
Единственное, что сюда не выложил ее.

Ну для нас-то ее нет, потому мы и обсуждаем только результат.

Конструктивная критика приветствуется. 

Не уверен, что критикую конструктивно, но всё же:
Авторизация не имеет неуспешного окончания из-за чего может зацикливаться.
Оплата картой предполагает ещё одно действующее лицо, шаги которого отсутствуют.
Выделять ВИ, в котором только шаги системы, вряд ли разумно.

Продолжение...
Я изменил диаграмму.
1) Как адекватно прописать альтернативные потоки на ввод корректных данных? В спецификации у меня на ввод имени, телефона и почты отдельные альтернативные потоки. На диаграмме их также отдельно указывать или можно просто написать проверка ввода данных?
2)

В языке есть средства, чтобы обойтись одной стрелкой.

Я так понял что пунктиром обводятся все действия, к которым есть общий альтернативный поток и отдельно этот альтернативный поток для них прописывается. Только я в visio не нашел таких объектов ((
Поэтому пока нет на диаграмме альтернативного потока "отмена заказа".
3) Может ли быть на диаграмме два окончания? Сейчас у меня одно окончание - это оформление заказа. А второе может быть как раз "отмена заказа", так как пользователь отменяет заказ путем перехода на любую страницу сайта (в корзину, в каталог, на главную и т.д.) При этом товары в корзине конечно останутся и пользователь зайдя в корзину может начать заново оформление заказа, но это уже совсем другая история =)
4) Во вложении диаграмма и ниже спецификация.

ID: 2.
ВИ: Оформление заказа.
Краткое описание: Оформление заказа на покупку товара в интернет-магазине.
Основное действующее лицо: Клиент.
Второстепенные действующие лица: нет.
Предусловия:
В корзине клиента присутствуют товары.
Постусловия:
1.   Система автоматизации торговли получила заказ.
2.   Клиент зарегистрирован в системе.
3.   Система отправила клиенту письмо с информацией о его заказе.
Основной поток:
1.   ВИ начинается, когда клиент входит в виртуальную корзину.
2.   Система отображает содержимое виртуальной корзины клиента и стоимость.
3.   Если клиент выбирает опцию «Удалить товар».
3.1. Система удаляет отмеченные товары из корзины.
3.2. Система пересчитывает стоимость содержимого корзины.
4.   Клиент выбирает опцию «Оформить заказ»
5.   Система отображает форму оформления заказа.
6.   Если клиент авторизирован в системе.
6.1. Система заполняет поля с контактными данными клиента из БД.
7.   Если клиент не авторизирован.
7.2. Клиент осуществляет ввод необходимых контактных данных.
8.   Клиент вводит адрес доставки и выбирает способ доставки.
9.   Клиент подтверждает оформление заказа.
10.   Система отправляет заказ на исполнение.

Альтернативные потоки:
10.1. Клиент ввел имя короче 2-х символов.
10.1.1. Система сообщает пользователю, что необходимо ввести имя не короче 2-х символов.
10.2. Клиент ввел не корректный e-mail.
10.2.1. Система сообщает пользователю, что адрес электронной почты должен содержать символ “@”.
10.3. Клиент ввел уже зарегистрированный e-mail.
10.3.1. Система сообщает клиенту, что пользователь с таким e-mail уже зарегистрирован в системе, и предлагает пройти процедуру авторизации.
10.4. Клиент ввел не корректный номер телефона.
10.4.1. Система сообщает пользователю, что необходимо ввести номер телефона по маске ввода.
10.5. Возврат к пункту 6.
10.6 Клиент отменяет заказ.
10.6.1. Происходит переход на страницу, выбранную клиентом.
 

Продолжение...
Я изменил диаграмму.
1) Как адекватно прописать альтернативные потоки на ввод корректных данных? В спецификации у меня на ввод имени, телефона и почты отдельные альтернативные потоки. На диаграмме их также отдельно указывать или можно просто написать проверка ввода данных?

Можно декомпозировать деятельность на отдельной диаграмме, где прописать все условия детально

7.   Если клиент не авторизирован.
7.2. Клиент осуществляет ввод необходимых контактных данных.

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

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

Клиент может и не авторизироваться для оформления заказа.
пункт 7.2 подразумевает не ввод данных для авторизации, а ввод контактных данных (им, телефон, почта) для оформления заказа и последующей регистрации.

Клиент может и не авторизироваться для оформления заказа.
пункт 7.2 подразумевает не ввод данных для авторизации, а ввод контактных данных (им, телефон, почта) для оформления заказа и последующей регистрации.

Согласно Вашей диаграмме ВИ (прежней её версии) авторизация обязательно происходила при оформлении заказа (связь включения между ВИ). Вместо 3-х тем, каждая из которых про отдельный тип диаграмм, удобнее было бы иметь одну тему по всей Вашей модели. Диаграммы и описания (части модели) должны подходить друг к другу, иначе целостной модели не получится. Отвечать, Вам отслеживая изменения в одной модели, разбросанные по трём темам, затруднительно.

Согласно Вашей диаграмме ВИ (прежней её версии) авторизация обязательно происходила при оформлении заказа (связь включения между ВИ). Вместо 3-х тем, каждая из которых про отдельный тип диаграмм, удобнее было бы иметь одну тему по всей Вашей модели. Диаграммы и описания (части модели) должны подходить друг к другу, иначе целостной модели не получится. Отвечать, Вам отслеживая изменения в одной модели, разбросанные по трём темам, затруднительно.

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

Просьба проверить верно ли сделал отмену заказа.
Альтернативные потоки объединил одним действием.

Просьба проверить верно ли сделал отмену заказа.
Альтернативные потоки объединил одним действием.

ОТмена заказа не должна висеть в воздухе - укажите финальное состояние или состояние завершения потока

ОТмена заказа не должна висеть в воздухе - укажите финальное состояние или состояние завершения потока

Вот тут просьба помочь.
Ведь у меня отмена заказа, это не кнопка "Отменить". Это значит что из любого места во время оформления заказа, клиент может уйти из оформления в корзину для изменения товаров, на главную, в каталог, в личный кабинет, ну или нажать на красный крестик у браузера.
Получается, что тут разные конечные состояния.
По-крайней мере можно выделить 2:
 1) переход в корзину, это можно прямо стрелкой показать на диаграмме в деятельность "отображение содержимого корзины".
2) переход на любую из страниц.

Хотя в общем-то можно и одним - переход на любую из страниц.