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

Да, потеря карты происходит за рамками рассматриваемой системы

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

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

По этому "Доступ в кабинет" - это вариант использования, а "использование карт ридера" - уже нет.

Тогда что мне еще нужно добавить в use case diagram? Мне она кажется какой то незаконченной

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

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

Выходит так (решил все таки добавить экторов для ясности)

кстати, пока занимаюсь use case specification, хотелось услышать мнение о class diagram

Народ, опомнитесь! Что ж вы делаете с бедным студентом!? =)

Итак, начну с общего - модель всегда должна соответствовать цели ее создания. Цель, если я правильно ее понимаю, продемонстрировать знание нотации UML и понимание ее роли при проектировании ПО.


Исходя из данной цели, предлагаю пройтись по заданию:

1. Создать activity diagram для описания что произойдет когда кто нибудь попробует получить доступ к одной из зон школы, которая оснащена свайп карт ридером.

Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:

• Субъект, пытающийся получить доступ
• Карт ридер
• Система
• Дверь (турникет и т.п.)

Соответственно необходимо создать 4 дорожки, в которой описать действия каждого из акторов данного кейса в четком следовании нотации UML.

Начало Activity диаграммы во вложении. Можно дополнить дополнительными проверками, например если у нас турникет а не дверь - можно зафиксировать факт прохода, и дополнить проверку доступа нашим знанием о местоположении субхекта (осуществлял он ранее проход или нет - например по своей карте пытается провести в закрытую зону еще несколько человек, а регистрация более 3 входов и выходов в течении 5 минут может быть поводом об оперативном информировании службы безопасности) - тут уже можно фантазировать, поскольку данные моменты не оговорены в задании.

2. Предоставить use case model для NSAC системы описываемой сценарии из 1 сообщения.
  а. Определить main use cases
  b. Предоставить use case diagram. Она должна включать систему, actors, use cases а так же внутренние и внешние связи (include, extend), так же как и use case and/or actor generalisation в вашей диаграмме.
  с. Разработать use case спецификации описывающий процесс когда свайп карта была создана для нового сотрудника, который устроился в школу. Если ваша диаграмма содержит больше чем 1 use case для достижения требуемого, тогда опишите для всех их. Это означает, что вы должны описать внешние и внутренние use cases.

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

Тут необходимо подчеркнуть, что UML - язык очень формальный. Если чего-то не указано на диаграмме, то в контексте диаграммы этого просто не существует.

3. Разработайте class diagram для вашей системы. Включая атрибуты, операторы, ассоциации, множественность (miltiplicities).

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

По текущей диаграмме очень много замечаний. Советую вслух проговорить все что описано на диаграмме, с учетом формальности языка. Например 2 класса сверху слева: У каждой персоны может быть 1 карта. У каждой карты есть от 1 до бесконечности владельцев (бред!).

Не забудь о том, что записи можно изменять, а не только создавать и удалять. Добавь CRUD для карт. Точка доступа это сама дверь или карт ридер?? Где логи? Слишком мудришь с сотрудниками и студентами (пытаешься сразу объять необъятное), лучше оставить только класс Persona, и перенести в нее атрибут privilege level - сотрудник, школьник и т.п.

Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:

• Субъект, пытающийся получить доступ
• Карт ридер
• Система
• Дверь (турникет и т.п.)

Tinner,

• Считыватель карт это не эктор, т.е. не элемент требований, а компонент реализации (часть системы), который должен образоваться по результатам проектирования системы или как ограничение на реализацию.
• Система не является эктором. Эктор по определению это тот, кто находится за пределами Системы и взаимодействует с ней
• Дверь (турникет и т.п.) это тоже не эктор. Дверь это не унаследованная система, с которой наша Система может обмениваться информацией.

Тут могу посоветовать выписать все сущности из задания и довести до минимализма (в буквальном смысле перечитать задание и подчеркнуть все существительные) и исходить из этого.

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

Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:

• Субъект, пытающийся получить доступ
• Карт ридер
• Система
• Дверь (турникет и т.п.)

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

• Считыватель карт это не эктор, т.е. не элемент требований, а компонент реализации (часть системы), который должен образоваться по результатам проектирования системы или как ограничение на реализацию.
• Система не является эктором. Эктор по определению это тот, кто находится за пределами Системы и взаимодействует с ней
• Дверь (турникет и т.п.) это тоже не эктор. Дверь это не унаследованная система, с которой наша Система может обмениваться информацией.

В задании четко поставлена задача - описать процесс получения доступа в виде активити диаграммы. У приведенных мной сущностей есть состояния действий, которые можно отобразить на диаграмме. Тогда почему, в данном контексте нельзя на диаграмме отобразить их на отдельных дорожках?
Напоминаю:
 - Конечная цель - не создать модель всей системы в целом (кроме определения main use cases), а выполнить конкретные задания курсового.
 - Детализация может быть разной в разных диаграммах, в зависимости от цели создания конкретной модели.
 - UML - не язык сбора и фиксирования требований, а язык моделирования, а модель может отражать часть требований к системе, но никак не наоброт.
 - Главная цель UML (то, во что она со временем вылилась, и единственная реальная, которую я встречал в жизни) - это обеспечение одинакового понимания задачи всей командой проекта. Соответственно, отойдя от Коберна и компании, которые используют лишь малую часть UML в очень ускоспециализированном контексте, прошу указать мне, чем мое предложение по реализации Активити диаграммы плохо?
Прошу поправить меня, если я не прав, заранее спасибо.

По текущей диаграмме очень много замечаний. Советую вслух проговорить все что описано на диаграмме, с учетом формальности языка. Например 2 класса сверху слева: У каждой персоны может быть 1 карта. У каждой карты есть от 1 до бесконечности владельцев (бред!).
Не забудь о том, что записи можно изменять, а не только создавать и удалять. Добавь CRUD для карт. Точка доступа это сама дверь или карт ридер?? Где логи? Слишком мудришь с сотрудниками и студентами (пытаешься сразу объять необъятное), лучше оставить только класс Persona, и перенести в нее атрибут privilege level - сотрудник, школьник и т.п.

Я хотел написать что у каждой персоны есть 0 или 1 карта, видимо не правильно отобразил.
AccessPoint это сама дверь, т.е это parent class и из него уже идут sub classes door and gates
Опять же, мудрю с классом Person потому что препод хочет увидеть как мы используем parent class и дочерние классы, поэтому его так и отобразил.
Да, сейчас тогда карт ридер добавлю и запись событий
CRUD как я понял нужно просто добавить в operations класса Card?

Начало Activity диаграммы во вложении

Немного не понял что делает ромб слева, под Прикладыванием карты. Обычно же либо объединение либо decision mode, а у вас как то 2 в 1.
В принципе все доп действия можно оставить за рамками системы, как я у препода узнавал про изменение прав доступа к зона в use cases и она сказала не делать это, считать это все установлено за пределами нашей системы. В этом случае и ваша и моя activity diagram должны подходить под задание

Вопрос на засыпку: я правильно понимаю из диаграммы, что HR и Security не являются сотрудниками школы, и доступ им никуда не нужен?

Тут я немного напутал, HR и Student Service Center - actors, они скорее всего являются сотрудниками школы и доступ им нужен, но это не описывается в сценарии. Я думаю в моем случае это просто место, где получают карты

Сейчас опять наверное скажете, что зря я добавил Эктора Аналитика=) Но при написании specification понял что он мне нужен, чтобы был весь процесс куда идет отчет и для чего.


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

Сейчас опять наверное скажете, что зря я добавил Эктора Аналитика=) Но при написании specification понял что он мне нужен, чтобы был весь процесс куда идет отчет и для чего.

Конечно зря:)
Судя по постановке задания, отчеты отправляются в какие-то там другие отделы. Их анализ не происходит в рассматриваемой системе, так что и юз кейс "Analyze report data" и эктор "Analyst" лишние.
Как я понимаю есть желание упомянуть систему в которую уходят отчеты. В таком случае надо во вторичных экторах добавить эту систему, назвать можно как угодно, но это будет именно система (а не прямо в мозг аналитику отправляешь:)) и связать ее с юз кейсом "Send Report to departments"

Как я понимаю есть желание упомянуть систему в которую уходят отчеты. В таком случае надо во вторичных экторах добавить эту систему, назвать можно как угодно, но это будет именно система (а не прямо в мозг аналитику отправляешь:)) и связать ее с юз кейсом "Send Report to departments"

Да, просто при use case specification получается не полная картина без того куда и зачем отправляется отчет. Хорошо, подумаю как систему назвать. В голове только 2 вещи вертятся, это почтовый эктор(Если считать что отправка отчета идет по почте) или так и назвать Система анализа данных.

Что думаете по поводу class diagram? правильно ли я связал cardReader и AccessPoint? или нужно еще с чем то связать?
Спасибо за помощь!

-