4. Рассылка отчета тоже добавил, но! какого actor мне надо использовать? Поэтому я вновь использовал время как эктора

Того эктора, который осуществляет рассылку. Т.е. систему которая это делает.

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

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

Коллеги, выскажете своё мнение, следует ли выделять роли грузчик, уборщик? Если нет, в каком случае вы бы выделили такие роли?

Имхо их надо выделять, только если у них есть уникальные ВИ, отличающие их от других. Но т.к. таковых я тут не вижу, то и выделять их не надо.

Того эктора, который осуществляет рассылку. Т.е. систему которая это делает.

Рассылку осуществляет наша система, но она не является эктором

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

Авторы книг расходятся во мнениях. Некоторые говорят что можно использовать эктора время (таймер), другие говорят что в качестве эктора надо применять того на ком будет лежать ответственность за инициацию ВИ. К примеру админ, который должен следить за тем чтобы отчёты сформировались и разослались правильно и вовремя. Такой подход используется, к примеру, в модели классического кейса "Payroll System" фирмы Rational.

Приведу ещё одну ссылку:)

5. если запуск по расписанию -> автоматически, т.е. по событию времени, таким образом это будет актор Время или Таймер.

Может это поможет в дискуссии.
Рекомендации по написанию спецификаций вариантов использования. Это выжимка из книги, авторы которой весьма известные в западных кругах тренеры.

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

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

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

вот таким образом я изобразил сценарий через use case diagram а так же параллельно начал делать class diagram (use case specification пока пропустил, до того момента как с use case diagram разберусь)
В class diagram пока думаю как отразить время работы или может как то по другому это все надо отобразить?

Спасибо за советы, но меня смущает что препод просит описывать сценарий а не систему в use case diagram.

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

вот таким образом я изобразил сценарий через use case diagram а так же параллельно начал делать class diagram (use case specification пока пропустил, до того момента как с use case diagram разберусь)
В class diagram пока думаю как отразить время работы или может как то по другому это все надо отобразить?

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

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

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

отношения между use case, вот в них не уверен. Особено в той части где идет проверка. Как отобразить закрытый доступ или открытый?
Вроде теперь все мои мысли должны быть вам понятны.

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

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

Сервер. С этим пока еще думаю, просто в голову пока не пришло как назвать но смысл эктора ясен.

Смысл непонятен. В описании нет информации о том что мы должны использовать какой-то унаследованный сервер. Поэтому такого эктора быть не должно. Это часть самой системы.

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

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

Управляет процессом не время, а например планировщик.

Планировщик мне нравится гораздо больше. Сразу понятно на кого смотреть при разборе ВИ:)

вот таким образом я изобразил сценарий через use case diagram

Сценарий - это одно действие от начала и до конца, по шагам. Т.е. или проход по карте или получение карты или отправка отчета. Но что-то одно.
А у вас все сразу.

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

Но как Сергей написал выше, если преподаватель "так видит", то что поделаешь:)

Может и я не понял его) просто эти размышления я получил после примеров что другие делают.
Хорошо, тогда соглашусь с вами и попробую сделать нормальную систему. Единственное что время может быть эктором в моем случае) седня перечитаю еще раз все ваши замечания и попробую сделать use case именно по системе. Спасибо за понимание.
Так же бы хотел услышать замечания по class diagram, сразу скажу что нужно отразить только entity class, т.е я не залезал в стереотипы.

Теперь я вроде бы разобрался) use case зависит от того что я выбрал main use cases. Поэтому у всех они не похожи и я подумал о сценарии. Тогда начнем с чистого листа и сначала мне нужно выбрать main use cases. Их выбор ниче не ограничен, можно выбрать что угодно из сценария. В моем случае это access control. Тогда подумаю сейчас что же выбрать из ваших замечаний

Вот что осталось из того что было.
main use cases:
Generate swipe card
Open access to zone
using swipe card reader

Я уже немного запутался, направьте меня на путь истинный)

Мне кажется уже лучше:)
Выкинули систему отчетов, схема стала легче.
Однако есть следующие замечания:
1. Теряюсь в догадках, что такое "Swipe card transaction"? И почему каждый раз при его использовании должны выпускать новую карту?
2. Почему вариант использования "Incorrect entry" расширяет неясный  "Swipe card transaction"? В то время как сам вход происходит в другом варианте использования.
3. И вообще, что это за вариант использованя "Incorrect entry"? В чем его польза для клиента? Такие вещи как успех/неуспех отображаются в сценарии, а не в ДВИ.
3. Я бы заменил "Manage swipe card" на "swipe card CRUD" без инклюдов. Потому что по текущей схеме, получается, что при управлении картами, нужно будет и обновлять информацию и удалять карту и делать новую одновременно.

ЗЫ: К диаграмме классов тоже можно придраться, но предлагаю сначала разобраться с ДВИ:)

1. Теряюсь в догадках, что такое "Swipe card transaction"? И почему каждый раз при его использовании должны выпускать новую карту?

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

В итоге, вот что получилось. Но из выбранных мною main use cases, я потерял using swipe card reader. Или это не нужно отображать?

В диаграмме вариантов использования в посте от 11 Ноября 2013, 21:39:19 неправильно обозначены отношения генерализации между акторами: вместо отношения генерализации обозначено отношение ассоциации.

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