Начните  с главного. Какие есть Акторы и какие у них цели относительно системы? Клиент, Администратор, Контент-менеджер?

Чего хочет клиент от системы? "Посмотреть товары в магазине" и "Оформить заказ"?. Чего хочет Администратор - "Управлять каталогом". Чего хочет контент-менеджер? Предположим "Редактировать описание товара".
Нарисуйте эти UC. В принципе, диаграмма готова. С ней всё нормально. Можно писать сами тексты UC.

Если хотите дать понять преподавателю, что освоили связь "включает", то
можно добавить Аутентификацию\Регистрацию как включённый UC для "Оформления заказа", "Управления каталогом", "Редактировать описание товара". "Редактировать описание" можно считать включённым кейсом для "Управление каталогом", а можно не считать - зависит от вашей бизнес-логики.
С этой диаграммой тоже всё ОК.

Вся путаница - от смешения UC разных уровней детальности в одной диаграмме.
Начните писать тексты UC и всё станет на свои места.

Правильно ли я понимаю, что отношение "расширения" используется тогда, когда один ВИ уже где-то используется, и в то же время при определенных условиях может использоваться еще в одном ВИ ?

Не совсем так.

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

С отношением расширения, вам пока лучше не связываться. Кажется Коберн, говорил что один раз только в жизни им пользовался на реальном проекте. Оно не сложнее включения, просто ваша задача решается и без него. Если есть очень большое желание - Авторизацию\Регистрацию можно описать как расширение для кейса "Оформить заказ".

Как-то так тогда получается (просто брал удаление, изменение и добавление). Правда у меня теперь "поиск" включается в "управление каталогом" однако, например, для добавления товара в каталог, поиск совершенно не нужен. Криво значит (

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

Надеюсь, не страшно то, что я объединил таки регистрацию и аутентификацию...

Не совсем так.

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

С отношением расширения, вам пока лучше не связываться. Кажется Коберн, говорил что один раз только в жизни им пользовался на реальном проекте. Оно не сложнее включения, просто ваша задача решается и без него. Если есть очень большое желание - Авторизацию\Регистрацию можно описать как расширение для кейса "Оформить заказ".

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

Как-то так тогда получается (просто брал удаление, изменение и добавление). Правда у меня теперь "поиск" включается в "управление каталогом" однако, например, для добавления товара в каталог, поиск совершенно не нужен. Криво значит (

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

Надеюсь, не страшно то, что я объединил таки регистрацию и аутентификацию...

Диаграмма -ОК. Если бы был преподом - меня бы устроило.
В "Управлении каталогом" у вас спрятано и "добавление" и "удаление" и "правка". Т.к. удалению и правке поиск нужен, то стрелочка к поиску - ОК.

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

Конечно входит, еще ночь впереди, буду писать теперь и их тоже)) А потом и другими диаграммами займусь.
Спасибо большое за помощь, многое разъяснили.

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

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

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

Диаграмма -ОК. Если бы был преподом - меня бы устроило.

А меня как реального препода эта диаграмма не устраивает по очень многим параметрам.

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

Далее должно следовать специфицирование ВИ и их анализ из которого, если будет так необходимо можно будь получить диаграмму, которую  Даниил представил.

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

- ровно эти же рассуждения приведут меня и по ВИ оформление заказа, при этом если включение ВИ поиск заказа выглядит разумным, то ВИ А/Р явно нет.

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

Эдуард, спасибо за участие в топике.

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

Если я правильно вас понял- то вы за то чтобы вернуть на диаграмму UC "Добавить товар", "Изменить товар", "Удалить товар".
Здесь, мне кажется, ситуация из разряда "на вкус и цвет".  Думаю, в контексте учебного проекта, эти UC отлично упаковываются в большой UC "Управление каталогом".
Впрочем, если описание задачи из начального поста топика - это и именно та формулировка, которую дал Даниилу преподаватель, то этот преподаватель, возможно, в итоге ожидает увидеть картинку по принципу "по одному UC на каждый глагол из описания". Тогда надо добавлять ещё и другие UC типа "выбрать товар в корзину", "просмотреть каталог товаров" может даже "войти в корзину". И тогда стоит вернуть "Добавить", "Удалить", "Изменить".
Но это только гипотеза и начал я бы всё-таки с самого минимума UC. Мельчить - плохо (насколько я помню Коберна, он примерно то же самое говорил).

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

Если я правильно понял, то вы клоните к тому, что <<include>> надо менять на <<extend>>, т.к. включённые UC выполняются всегда, а ту же авторизацию надо выполнять не всегда. 
Здесь я с вами не соглашусь. UC - это не один сценарий, а взаимосвязанная группа сценариев. Да включённые UC всегда выполняются, но только для тех сценариев из группы, в которые они включены. Например: при управлении каталогом текст UC можно сформулировать так, что авторизация будет входить не в базовый сценарий, а в альтернативный (и следовательно не будет выполняться при каждой активизации UC).
Даже погуглил на эту тему: http://www.batimes.com/articles/putting-the-inclusion-use-case-in-focus.html.

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

Соглашусь. Текст объединённого UC для Авторизации и Регистрации будет уродливым. Это была плохая идея с моей стороны.

Если я правильно вас понял- то вы за то чтобы вернуть на диаграмму UC "Добавить товар", "Изменить товар", "Удалить товар".
Здесь, мне кажется, ситуация из разряда "на вкус и цвет".  Думаю, в контексте учебного проекта, эти UC отлично упаковываются в большой UC "Управление каталогом".

Нет, нет. Вы меня не правильно поняли. Я вовсе за это не ратую. Использования шаблона CRUDL вполне себе оправдано для подобных UC, связанных общими предусловиями и постусловиями.

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

Если я правильно понял, то вы клоните к тому, что <<include>> надо менять на <<extend>>, т.к. включённые UC выполняются всегда, а ту же авторизацию надо выполнять не всегда. 
Здесь я с вами не соглашусь. UC - это не один сценарий, а взаимосвязанная группа сценариев. Да включённые UC всегда выполняются, но только для тех сценариев из группы, в которые они включены. Например: при управлении каталогом текст UC можно сформулировать так, что авторизация будет входить не в базовый сценарий, а в альтернативный (и следовательно не будет выполняться при каждой активизации UC).
Даже погуглил на эту тему: http://www.batimes.com/articles/putting-the-inclusion-use-case-in-focus.html.

Нет я даже не обсуждаю, нужно ли использовать include или extend. Я подвергаю сомнению вообще использование этих отношений на данном этапе. Они могут появится впоследствии и могут быть вполне уместны. Но только из анализа текстовых спецификаций. Когда будет понятно, что можно и целесообразно вычленить в некий общий абстрактный UC с повторяющейся последовательностью для нескольких UCs или подключаемых при особых условиях (расширениях). А краткие кусочки текста, которые записываются в овальчики, слишком малы и неопределенны для взвешенного принятия решения.

Здесь я с вами не соглашусь. UC - это не один сценарий, а взаимосвязанная группа сценариев. Да включённые UC всегда выполняются, но только для тех сценариев из группы, в которые они включены. Например: при управлении каталогом текст UC можно сформулировать так, что авторизация будет входить не в базовый сценарий, а в альтернативный (и следовательно не будет выполняться при каждой активизации UC).

Видите сколько неопределенности и интерпретации не поддержанной какими-либо спецфикациями или описаниями таких сценариев

Даниил, а вы уже перечитали топики
http://www.uml2.ru/forum/index.php?topic=286
http://www.uml2.ru/forum/index.php?topic=1112
http://www.uml2.ru/forum/index.php?topic=1277
http://www.uml2.ru/forum/index.php?topic=5955
http://www.uml2.ru/forum/index.php?topic=6159
?

За ссылку спасибо.

Мои извинения за долгое отсутствие, и спасибо за помощь.
Ранее сдал преподавателю предыдущую диаграмму на преддипломную практику, по-моему он даже не смотрел ее...
Теперь продолжаю ту же тему на диплом, на защите думаю смотреть все же будут мои диаграммы.
Помимо тех ВИ, что были, у меня добавился ВИ "управление заказами".

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

- ровно эти же рассуждения приведут меня и по ВИ оформление заказа, при этом если включение ВИ поиск заказа выглядит разумным, то ВИ А/Р явно нет.

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

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

Так выглядит спецификация.
Правда пока только на 3 ВИ.

ID: 1.
ВИ: Поиск товара.
Краткое описание: Система выполняет поиск в каталоге товаров по заданным администратором или клиентом критериям.
Основные действующие лица: Клиент, Администратор
Второстепенные действующие лица:  Нет.
Предусловия: Нет.
Постусловия: Система нашла товары по заданным критериям и вывела результаты на экран.
Основной поток:
1.   ВИ начинается, когда клиент/администратор переходит в каталог товаров.
2.   Система выводит на экран общий список товаров и список критериев поиска.
3.   клиент/администратор вводит необходимые для поиска товара критерии.
4.   Система выполняет поиск товаров, соответствующих заданным критериям.
5.   Для каждого найденного товара система выводит изображение, наименование и стоимость товара.
6.   Если клиент/администратор запрашивает полную информацию о выбранном товаре.
6.1. Система выводи на экран все характеристики соответствующего товара.

Альтернативные потоки:
4.1. Системе не удалось найти товары.
4.2. Система сообщает пользователю, что товары с заданными характеристиками найти не удалось.

ID: 2.
ВИ: Оформление заказа.
Краткое описание: Оформление заказа на покупку товара в интернет-магазине.
Основное действующее лицо: Клиент.
Второстепенные действующие лица: Система автоматизации торговли.
Предусловия:
В корзине клиента присутствуют товары.
Постусловия:
1.   Система автоматизации торговли получила заказ.
2.   Клиент зарегистрирован в системе.
3.   Система отправила клиенту письмо с информацией о его заказе.
Основной поток:
1.   ВИ начинается, когда клиент входит в виртуальную корзину.
2.   Система отображает содержимое виртуальной корзины клиента.
3.   Система отображает стоимость заказа.
4.   Если клиент выбирает опцию «Удалить товар».
5.1. Система удаляет отмеченные товары из корзины.
5.2. Система пересчитывает стоимость содержимого корзины.
5.   Клиент выбирает опцию «Оформить заказ»
6.   Система отображает форму оформления заказа.
7.   Если клиент ранее совершал покупки и зарегистрирован в ситеме.
7.1. Система предлагает клиенту ввести его адрес электронной почты и пароль.
7.2. Клиент вводит свой адрес электронной почты и пароль.
8.   Если клиент не совершал покупок в магазине и не зарегистрирован.
8.1. Система предлагает клиенту ввести контактные данные.
8.2. Клиент осуществляет ввод необходимых контактных данных.
9.   Система предлагает клиенту ввести адрес доставки.
10.   Клиент вводит адрес доставки.
11.   Система предлагает клиенту выбрать вариант доставки.
12.   Клиент выбирает вариант доставки.
13.   Система производит пересчет стоимости заказа с учетом стоимости доставки.
14.   Система запрашивает у клиента подтверждение оформления заказа.
15.   Клиент подтверждает оформление заказа.
16.   Система отправляет заказ на исполнение.

Альтернативные потоки:
7.2.1. Клиент ввел неверный адрес или пароль.
7.2.2. Система сообщает пользователю, что введенный адрес или пароль неверный.
7.2.3. Происходит возврат к пункту 7.1.
8.2.1. Клиент ввел некорректные данные.
8.2.2. Система сообщает пользователю, что введенные данные не корректны.
8.2.3. Возврат к пункту 8.1.
15.1 Клиент отменяет заказ.
15.2. Происходит возврат в виртуальную корзину клиента.


ID: 3.
ВИ: Управление каталогом.
Краткое описание: Администратор осуществляет управление каталогом товаров (добавление, изменение, удаление товаров).
Основное действующее лицо: Администратор сайта.
Второстепенные действующие лица: Система управления каталогом товаров.
Предусловия:
Администратор прошел авторизацию в системе управления каталогом товаров. Для изменения или удаления товар найден.
Постусловия:
Система внесла изменения, добавила или удалила товар.

Основной поток:
1.   Если Администратор выбрал опцию «Добавить товар».
1.1.   Система отображает на экране форму для ввода характеристик нового товара и добавления изображения.
1.2.   Администратор вводит характеристики товара.
1.3.   Администратор подтверждает добавление нового товара.
2.   Если Администратор выбрал опцию «Изменить товар».
2.1.   Система отображает на экране форму с характеристиками товара.
2.2.   Администратор вносит изменения в характеристики товара.
2.3.   Администратор подтверждает внесение изменений в характеристики товара.
3.   Если Администратор выбрал опцию «Удалить товар».
3.1.   Система запрашивает подтверждение удаления товара.
3.2.   Администратор подтверждает удаление товара.

Альтернативные потоки:
1.3.1.   Администратор отменил добавление товара.
1.3.2.   Система осуществила переход к основному списку товаров.
2.3.1.   Администратор отменил внесение изменений в характеристики товара.
2.3.2.   Система осуществила переход к основному списку товаров.
3.2.1.   Администратор отменил удаление товара.
3.2.2.   Система осуществила переход к основному списку товаров.