Добрый день!
Делаю курсовую по UML и нужно чтобы кто то указал на ошибки, т.к показать не кому.
Итак сам сценарий: Школа (NS) хочет внедрить систему контроля доступа в некоторые зоны. Хотят использовать свайп карты для контроля доступа к определенным зонам(на дверях).
Как я написал, некоторые входы будут оснащены свайп карт ридером, и если имеется карта то можно получить доступ в эту зону к которой пользователь имеет доступ и соответственно получить доступ в помещение. Иначе двери закрыты и доступа не будет.
NS предоставляет карты с фотографией и уникальным номером для множества людей которым требуется доступ к определенным зонам. Этими людьми могут быть ученики, преподаватели, администрация, охрана, грузчики. Эти карты выдаются тогда, когда ученик/работник поступает/устраивается в школу. Карта имеет срок истечения. Если карта была утеряна, она заменяется новой. Карты для учеников выдают в Student Service Сentre. Все другие карты выдаются в отделе HR.
Школа открыта по будням с 8 до 22. Все зоны должны быть доступны для  грузчиков, уборщиков и охранникам в любое время. Тем не менее, другие держатели карт имеют доступ только с 8-22.
Некоторые из входов должны предоставлять доступ всем без исключения в течении рабочих часов. Примером такого доступа может быть главный вход или вход в библиотеку. Другие входа, с конфиденциальной информацией например, должны иметь ограничения для тех лиц кому дозволено заходить.
Использование свайп карт при входе в различные зоны записываются и на регулярной основе отправляются раз в месяц в отдел безопасности и в отдел обслуживания для различного анализа.



Итак пока вот сделал вот такую Activity Diagram (вложение)

Это диаграмма какого процесса?

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

Чтобы указывать на ошибки, надо видеть задание.

Задание «попытайтесь изобразить нечто, имеющее отношение к тексту с использованием нотации UML, да так, чтобы было весело»?

Добрый день!
Делаю курсовую по UML и нужно чтобы кто то указал на ошибки, т.к показать не кому.
...
Итак пока вот сделал вот такую Activity Diagram (вложение)

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

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

А пока данный рисунок выглядит как попытка впихнуть невпихуемое:)

...нужно чтобы кто то указал на ошибки, т.к показать не кому.

Ошибки в UML в данном случае несущественны. Проблема на уровне моделирования.

Как уже порекомендовали, нужно "пересчитать" процессы и отрисовать для них отдельные диаграммы.

На глаз, там как минимум:
- выдача новой карты;
- замена утерянной;
- авторизация и учет проходов;
- отчетность в отдел кадров.

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

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

А слона то и не приметил) Спасибо, как до софта доберусь - переделать попробую!
Задания следующие:
1. Создать activity diagram для описания что произойдет когда кто нибудь попробует получить доступ к одной из зон школы, которая оснащена свайп карт ридером.
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.
3. Разработайте class diagram для вашей системы. Включая атрибуты, операторы, ассоциации, множественность (miltiplicities).

А ну как турникет не провернется?

Простите, вопроса не понял. Можете перефразировать?

Простите, вопроса не понял. Можете перефразировать?

Что будет при параллельном выполнении задач "пропустить" и "отметить", если одна из них по каким-то причинам завершится неудачно? Отмечен, но не прошел? Прошел, но не отмечен?

Синхронизировать потоки после узла логического разветвления (верхняя линейка синхронизации) вряд ли удастся.
Концовка в правой части страдает симметричным недугом. Параллельные потоки объединяются логически перед финальным узлом. Это означает, что когда курсор управления минует левый поток, где Access, всё закончится, независимо от того, успели ли выполнить Record и Send a report.
Все мои замечания формального плана, т. к. неясно, что за сценарий Вы моделируете этой диаграммой.

Все мои замечания формального плана, т. к. неясно, что за сценарий Вы моделируете этой диаграммой.

Спасибо, сценарий описан в 1 сообщении.
Тогда попробую седня переделать все со всеми замечаниями.

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

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

описание сценария как последовательность шагов.

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

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

DEEPshadow, я считаю было бы правильно если бы вы временно забыли о существовании диаграмм и последовали совету коллег. Сценарий использования описывается в виде последовательности шагов. Сценарий описывает получение эктором какого-то одного полезного результата (услуги). Каждый шаг описывает либо воздействие эктора на систему, либо реакцию системы на это воздействие. Такая последовательность шагов описывается в документе, который называется use-case specification. В принципе не важно как документ будет называться. Можете назвать его по своему вкусу если название будет соответствовать содержимому документа.

Прошел, но не отмечен?

Выбор профессионала!:)

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

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

PS: И да, как уже многие говорили, составьте последовательность шагов по пунктам на бумажке. Сразу станет яснее что за чем следует и как работает.

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

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

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