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

А какой смысл в actors без вариантов использования?
А те предложения, которые вы записали возможных main use cases, почему вы считаете, что это ВИ? Что вы понимаете под ВИ?

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

Я понимаю под main use cases, те "варианты использования" которые бы описывали сценарий и без которых выполнение сценария не возможна. То есть в моем случае это выдача карты, механизм контроля доступа и отправка отчета для анализа. Если я как то понял не правильно поправьте меня.

Сейчас попробую накидать диаграмму

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

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

Я понимаю под main use cases, те "варианты использования" которые бы описывали сценарий и без которых выполнение сценария не возможна.

Под main use cases видимо подразумеваются наиболее часто используемые. Возможно есть какие-то более чёткие критерии отделения "main" от "не main". Я бы уточнил у преподавателя.

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

Я бы выделил следующие ВИ:
1. Открыть проход
2. Ведение свайп-карт (CRUD)
3. Ведение считывателей (CRUD)
4. Рассылка отчёта

Сейчас попробую накидать диаграмму

Возникли следующие комментарии:
1. См. список ВИ выше.
2. Не нужно выделять два разных ВИ с разными именами ("create swipe card")
3. Не нужно выделять Student Service Center и HR. На самом деле это одна и та же роль типа "Администратор". Если правами доступа будет управлять кто-то другой типа начальника охраны, то нужна отдельная роль.
4. Первичных экторов принято указывать слева от ВИ, а вторичны справа.
5. Неверное использование "extend" ("формирование отчёта" не расширяет функционал "получить доступ") и "include" (Нельзя использовать функциональную декомпозицию).
6. CardReader и DataBase это не экторы, а часть системы. Их нужно удалить.
7. Нового и старого сотрудника/ученика выделять не нужно. Они будут отличаться только наличием свайп-карты, а роль одна и та же.
8. Зачем разделять сотрудников и учеников? Они будут как-то по разному взаимодействовать с системой?
9. Сотрудники/ученики не будут взаимодействовать с системой при получении/замене свайп-карты. Они будут взаимодействовать только с администратором.

Если позволите... С точки зрения практики, это разумный, дельный совет.
С формальной точки зрения можно указать пример, когда два фрагмента будут неэквивалентны.
...
В случае не исключающих друг друга сторожевых условий guard1 и guard2 в 1-м фрагменте можем получить два параллельных потока, если условия истинны одновременно. Во втором фрагменте в тех же условиях будет единственный поток -- либо верхний, либо нижний, выбранный случайным образом.
Первому фрагменту полностью эквивалентен 3-й:
...

Все верно. Нужно изобразить параллельные потоки - формулируем неисключающие условия.  Нужно "один из" - взаимоисключающие.

И еще одно замечание в кучу к тому что написал Сергей.
 "Время" -это тоже не эктор.

DEEPshadow, начать можно с определения границ системы (экторов), а потом уже для каждого эктора определить какие услуги они будут получать от системы. Но в общем случае позже может найтись новый ВИ, который сложно будет отнести к существующим экторам. Тогда придётся вводить нового эктора.
Под main use cases видимо подразумеваются наиболее часто используемые. Возможно есть какие-то более чёткие критерии отделения "main" от "не main". Я бы уточнил у преподавателя.

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

Тогда, если я всех студентов и работников отнесу в actors Member и департаменты по выдачи под Administrator то получу такую диаграмму.
Только теперь с вашими замечаниями я не могу понять как построить для прохода. Получается так же member будет участвовать в этом и мы используем просто ВИ открыть доступ?

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

Я бы выделил следующие ВИ:
1. Открыть проход
2. Ведение свайп-карт (CRUD)
3. Ведение считывателей (CRUD)
4. Рассылка отчёта

По поводу the main use cases это нужно перечислить основные, по моему мнению, ВИ которые должны быть отражены в диаграмме. Такой вот ответ от препода)

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

А выделил я старые и новые сотрудники/ученики, так как опять же мы так делаем на практике.

Сотрудник/ученик будет участвовать только в одном системном ВИ. Чем будет отличаться выполнение этого ВИ для старого и нового? Если ничем, то не нужно разделять роли.

Приведу пример use case для тренажерного зала. где actor может быть и почтовый сервер, время и тп.

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

По поводу the main use cases это нужно перечислить основные, по моему мнению, ВИ которые должны быть отражены в диаграмме. Такой вот ответ от препода)

"Основные" - расплывчатое понятие. Насколько ВИ должны быть "основными" чтобы заслужить право отображаться на диаграмме? А про остальные ВИ можно совсем забыть и не реализовывать их в системе?

2. swipe card я отобразил на диаграмме

будет не только создание, но и удаление, изменение прав доступа, просмотр информаци,  печать карт при создании. Предлагаю погуглить "CRUD Use Case". И еще что такое Join the NU и для чего оно? В ведении карт будет участвовать только администратор. Ученик/сотрудник в, это время будет стоять рядом и курить.

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

Первичным эктором будет время, а вторичным либо почтовый сервер, либо роль пользователя. По тому же принципу что я описал выше. Делать include ВИ стоит делать только если это упрощает модель. Здесь, по моему include неуместен.

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

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

Насколько ВИ должны быть "основными" чтобы заслужить право отображаться на диаграмме?

Такой ответ чтобы не подсказывать, если выбрал не все основные ВИ то и получу меньшее количество баллов)

будет не только создание, но и удаление, изменение прав доступа, просмотр информаци,  печать карт при создании. Предлагаю погуглить "CRUD Use Case".

Хорошо, спасибо учту.

И еще что такое Join the NU и для чего оно?

Это я взял из сценария, описание того что студент/сотрудник поступили на учебу/работу.

Первичным эктором будет время, а вторичным либо почтовый сервер, либо роль пользователя. По тому же принципу что я описал выше. Делать include ВИ стоит делать только если это упрощает модель. Здесь, по моему include неуместен.В ходе эксплуатации системы необходимо будет задавать атрибуты помещения, связанные с правами доступа, указанными в описании? Возможно нужно будет подключать/отключать контроль доступа в определенные зоны типа дня открытых дверей и прочего. Тогда нужен соответствующий ВИ.

Попробую рассмотреть с этой точки, но в сценарии нет информации о подключении или отключении КД в зоны. Сказано только что есть такие зоны, и я думаю, эту зону просто и надо описать.

Это я взял из сценария, описание того что студент/сотрудник поступили на учебу/работу.

Судя по описанию нет каких-либо сценариев при поступлении на работу/учёбу, кроме выдачи карты, подлежащих автоматизации.Поэтому такого сценария в системе быть не должно.

Попробую рассмотреть с этой точки, но в сценарии нет информации о подключении или отключении КД в зоны. Сказано только что есть такие зоны, и я думаю, эту зону просто и надо описать.

Можно и не рассматривать такой ВИ, но нужно подумать над тем как заказчик будет добавлять новый зоны и редактировать параметры прав доступа типа "наличие конфиденциальной информации" и "признак публичной зоны" (библиотека и т.п.). То есть нужно понимать что в описании может не быть чего-то, что заказчик на самом деле ожидает от системы. Может быть нужно спросить у преподавателя.

Ещё комментарии по диаграмме:
1. Из описания я понял что наша система не будет никак автоматизировать процесс анализа отчёта, поэтому ВИ "Анализ отчёта" не нужен. Или я ошибаюсь?
2. Имя ВИ обязательно должно начинаться с глагола (Swipe card reader).
3. На диаграмме не может присутствовать ВИ, который не связан ни с одним эктором (Swipe card reader).
4. Include наиболее полезно использовать когда один и тот же ВИ должен включаться в несколько других ВИ или должен повторяться в одном и том же ВИ несколько раз. В других случаях include я стараюсь не использовать.
5. Лучше уточнить название "Server".

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

Судя по описанию нет каких-либо сценариев при поступлении на работу/учёбу, кроме выдачи карты, подлежащих автоматизации.Поэтому такого сценария в системе быть не должно.

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

Можно и не рассматривать такой ВИ, но нужно подумать над тем как заказчик будет добавлять новый зоны и редактировать параметры прав доступа типа "наличие конфиденциальной информации" и "признак публичной зоны" (библиотека и т.п.). То есть нужно понимать что в описании может не быть чего-то, что заказчик на самом деле ожидает от системы. Может быть нужно спросить у преподавателя.

Это уточню

Ещё комментарии по диаграмме:
1. Из описания я понял что наша система не будет никак автоматизировать процесс анализа отчёта, поэтому ВИ "Анализ отчёта" не нужен. Или я ошибаюсь?

Опять же, нужно описать все из сценария, поэтому он нужен

2. Имя ВИ обязательно должно начинаться с глагола (Swipe card reader).
3. На диаграмме не может присутствовать ВИ, который не связан ни с одним эктором (Swipe card reader).

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

4. Include наиболее полезно использовать когда один и тот же ВИ должен включаться в несколько других ВИ или должен повторяться в одном и том же ВИ несколько раз. В других случаях include я стараюсь не использовать.

пока оставлю так, если смогу понять как их можно разбить без include то конечно попробую

5. Лучше уточнить название "Server".

Думаю назвать тогда Access Control Server, все таки инфа хранится в БД

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

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

Опять же, нужно описать все из сценария, поэтому он нужен

В описании сказано что отчет отправляется для анализа, но не указано что система должна как-то помогать проанализировать отчет. Поэтому ВИ не нужен.

пока оставлю так, если смогу понять как их можно разбить без include то конечно попробую

Почему так сильно хочется разбить? Какую пользу это принесет?

Думаю назвать тогда Access Control Server, все таки инфа хранится в БД

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