Итак, рассмотрев вновь задание сделал следующую диаграмму.

Формальный недочёт -- если следовать стандарту UML2 узел Access Deny будет пытаться синхронизировать свои входящие потоки. Т. е. он сработает лишь тогда, когда курсор управления сверху и курсор управления слева дождутся друг друга. Что, наверно, никогда не наступит. Входящие потоки следует логически объединить перед этим узлом.
Второе замечание по стилю. Не обязательно писать у "ромба" условие, а затем выводить лишь два потока: "да"-поток и "нет"-поток. Из узла логического разветвления Вы можете вывести сколько угодно потоков и приписать им сторожевые условия.
Пример:

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

Дело в том что мы еще не прошли дуги, лекции построены на базе книжки System analyst and Design with UML (Alan Dennis) 4 издание. И в книге кучу примеров с огромным количеством ромбов, поэтому и на практике делали эти задания с таким же количеством)

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

Хорошо, переделаю с вашими замечаниями.

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

Дело в том что мы еще не прошли дуги, лекции построены на базе книжки System analyst and Design with UML (Alan Dennis) 4 издание.

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

И в книге кучу примеров с огромным количеством ромбов, поэтому и на практике делали эти задания с таким же количеством)

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

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

Отправку отчета и запись тогда отложу на попозже.

Запись результата попытки прохода должна быть.

Вот переделал диаграмму по последним замечаниям и по предоставленному примеру.

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

1. Отправка отчета Вам не нужна, это другой процесс.
2. Эстетика. Ромб под проверкой прав опустить на уровень двух следующих и сменить точки входа стрелок в левый ромб.  Модель получится симметричной.

Что такое "Save data"? Почему недостаточно "Record"?

2. Эстетика. Ромб под проверкой прав опустить на уровень двух следующих и сменить точки входа стрелок в левый ромб.

Сделано.

Что такое "Save data"? Почему недостаточно "Record"?

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

1. Отправка отчета Вам не нужна, это другой процесс.

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

Вот такой сейчас вариант

Вот такой сейчас вариант

Осталось уязвимое место. Ветка "полного доступа" отрабатывает до проверки прав. Это не есть хорошо. Пожалуй, будет достаточно первую активность назвать не "Use..." а "Read...". Тогда можно будет сказать: мы при чтении определили ее тип, и вип-уборщиков пропускаем без дальнейших проверок.

лекции построены на базе книжки Systems analysis and Design with UML (Alan Dennis) 4 издание

Благодарю за ссылку, полистал. Действительно, авторы предлагают свою методику, в которой рисование диаграмм вариантов использования и описание ВИ относят к анализу. До этого я знал, что есть анжеро-судженский ООАП, теперь буду знать, что и в Индиане прогресс не стоит на месте.)

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

Виктор, простите, может я такой же идиот из Индианы, но в чем проблема отнесении ВИ и ДВИ к стадии анализа?

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

Наверное, Вы правы, но если я не ошибаюсь эстетика и прагматика спецификации UML2 предполагает использование decision и merge node для разделения и слияния потоков управления, типа в одну activity или action две стрелки входить не должны. Прагматика насколько я понимаю проистекает из того, что теперь понимается под диаграммой деятельности, а именно сеть Петри, а не вырожденная диаграмма состояний.
Но, могу заблуждаться.

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

Конечно, я не знаю, что Вам преподают и как, но есть такой довольно распространенный подход.
1. Изучив предметную область, построить диаграмму деятельности для описания бизнес-процесса (типично используют диаграммы BPMN)
2. Этапы такого бизнес-процесса выделяются и определяются как варианты использований
3. Совокупность вариантов использований и акторов, им соответствующих, образуют диаграммы ВИ
4. Каждый ВИ специфицируется до основного и альтернативных потоков
5. Для каждого ВИ возможно строится диаграмма классов, участников данного ВИ (обычно такие классы делать на сущностные, граничные и управляющие)
6. Частные диаграммы классов объединяются и образуют общую диаграмму классов
и т.п.

Может что-то подобное и в вашем случае?

Виктор, простите, может я такой же идиот из Индианы, но в чем проблема отнесении ВИ и ДВИ к стадии анализа?

Я никого не считаю идиотами, без шуток. Книга Коберна "Writing Effective Use Cases" на русский переведена как " Современные методы описания функциональных требований к системам". В рамках RUP и Open UP написание сценариев ВИ и составление диаграммы ВИ отнесены к процессу определения требований. В рамках Agile UP сценарии ВИ и диаграммы ВИ являются частью модели требований. Поэтому я привык соотносить ВИ и их диаграммы, и диаграммы деятельности, моделирующие ВИ, с требованиями, а не с анализом. В ходе анализа привычно выполнять реализацию ВИ, уточнять их описания. Сценарии и диаграмма ВИ + диаграммы деятельности для ВИ (в некотором, возможно не финальном своём состоянии) являются входными рабочими продуктами для процесса анализа.
Понятно, что ВИ, точнее бизнес-ВИ (бизнес-процессы) относятся  к бизнес-моделированию. И Вы, конечно, правы, что сначала может быть составлена диаграмма деятельности, моделирующая бизнес-процесс, а затем диаграмма ВИ системы и их описания.
По привычке я счёл, что в задании требуется составить диаграмму деятельности для ВИ системы, а не для предприятия. Книгу просматривал бегло и, возможно, поторопился с выводами.

Пожалуй, будет достаточно первую активность назвать не "Use..." а "Read...". Тогда можно будет сказать: мы при чтении определили ее тип, и вип-уборщиков пропускаем без дальнейших проверок.

Что если просто добавить действие чтение после использования?
Вот так:

Что если просто добавить действие чтение после использования?
Вот так:

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

В этом случае активность "Cheking" переместится на место "Read" и назовется "Authorize", а на выходе будет один ромб с тремя исходящими стрелками, две из которых уйдут в "Пропустить". Две - только если мы хотим для чего-то выделить карты с ограниченным доступом (например, если вскоре собираемся добавить туда какой-то специфический процесс). Иначе хватило бы и одной.

Наверное, Вы правы, но если я не ошибаюсь эстетика и прагматика спецификации UML2 предполагает использование decision и merge node для разделения и слияния потоков управления, типа в одну activity или action две стрелки входить не должны. Прагматика насколько я понимаю проистекает из того, что теперь понимается под диаграммой деятельности, а именно сеть Петри, а не вырожденная диаграмма состояний.
Но, могу заблуждаться.

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

Я никого не считаю идиотами, без шуток.

Виктор, простите мой моветон. Конечно, это просто оборот речи, некая эмоциональная краска.

Книга Коберна "Writing Effective Use Cases" на русский переведена как " Современные методы описания функциональных требований к системам". В рамках RUP и Open UP написание сценариев ВИ и составление диаграммы ВИ отнесены к процессу определения требований. В рамках Agile UP сценарии ВИ и диаграммы ВИ являются частью модели требований. Поэтому я привык соотносить ВИ и их диаграммы, и диаграммы деятельности, моделирующие ВИ, с требованиями, а не с анализом. В ходе анализа привычно выполнять реализацию ВИ, уточнять их описания. Сценарии и диаграмма ВИ + диаграммы деятельности для ВИ (в некотором, возможно не финальном своём состоянии) являются входными рабочими продуктами для процесса анализа.

Опять же, может я не прав (да и обсуждение темы оффтоп для данного треда), но разве сбор и описание требований не являются частью анализа - аналитической деятельности? Или Вы здесь вкладываете совершенно определенный смысл - создание аналитической модели и именно в контексте ООАД?

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

На самом деле не утверждаю, что это обычный путь. Хотя некоторые так делают, я бы остановился на уровне просто БП, без перехода на бизнес-ВИ.

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

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