Некоторая помощь в диаграмме варианта использования с Visual Paradigm

Я моделирую вариант использования в UML с помощью Visual Paradigm CE, но у меня есть несколько сомнений относительно моей модели. Взгляните на картинку ниже:

введите здесь описание изображения

Вот правила, которые я пытаюсь представить с помощью этой модели:

  • Существует 3 типа пользователей: Superadmin, Admin и Executive.
  • Существует функция под названием: Пользователь-администратор.
  • Пользователь-администратор разделен на 4 основных действия: создание, чтение, обновление и удаление.
  • Суперадмин имеет всю власть (может делать что угодно), в то время как у администратора есть только несколько разрешений (в данном случае «Создать пользователя»).
  • Исполнитель может выполнять только несколько действий в системе: Создать пользователя и Удалить пользователя.

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

Обновление: на основе ответа @thomas-kilian я сделал следующие две диаграммы:

включение CRUD в UC администратора пользователя расширяет CRUD от пользователя-администратора UC


actor use-case uml visual-paradigm
person ReynierPM    schedule 22.01.2016    source источник
comment
В большинстве случаев вы можете объединить все сценарии CRUD в один вариант использования, например «Управление пользователями». Я бы не стал моделировать эти требования безопасности низкого уровня на уровне варианта использования.   -  person Geert Bellekens    schedule 22.01.2016
comment
@GeertBellekens да, но тогда у меня могут возникнуть проблемы с описанием UC, поскольку он должен иметь несколько действий, и я совсем не понимаю, как добиться этого описания.   -  person ReynierPM    schedule 22.01.2016
comment
Используйте сценарии вариантов использования для описания различных случаев.   -  person Geert Bellekens    schedule 22.01.2016

Ответы (2)


arrow_upward
2
arrow_downward

Вам действительно нужен вариант использования «Пользователь-администратор»? Возможно, вам подойдет следующая схема:

введите здесь описание изображения

Если у вас действительно есть поведение в «Пользователь-администратор», не содержащееся в других вариантах использования, вы можете сохранить его, но я бы использовал согласованное соглашение об именах, например. глагол + существительное и, таким образом, переименовать «Пользователь-администратор» в «Администрирование пользователей».

Возможна схема 1. В этом случае SuperAdmin может получить доступ к функции «Создать пользователя» как напрямую (унаследованной от администратора), так и через пользователя-администратора. По-видимому, у пользователя-администратора есть несколько альтернативных потоков. Создать пользователя можно в одном альтернативном потоке, Обновить пользователя в другом и т. д. Это нормально.

Схема 2 также возможна. В этом случае SuperAdmin может получить доступ к функции «Создать пользователя» только через пользователя-администратора.

Схема 3 возможна, но сложна. Актеры «Администратор» и «Руководитель» связаны с так называемыми «расширенными вариантами использования» «Создать пользователя» и «Удалить пользователя». Расширенный вариант использования обычно определяет только фрагмент варианта использования, который должен быть вставлен в определенную точку расширенного варианта использования (пользователь-администратор). Но поскольку субъекты Admin и Executive непосредственно выполняют варианты использования Create User и Delete User, эти варианты использования должны описывать полные потоки событий. Если вам удастся определить потоки событий расширяющих вариантов использования таким образом, чтобы они подходили как для прямого выполнения, так и для вставки в точки расширения внутри пользователя-администратора варианта использования, тогда все в порядке.

person www.admiraalit.nl    schedule 22.01.2016
comment
Спасибо за совет по соглашению об именах. Я использую их в качестве примеров (не будут использоваться на реальной диаграмме). Смотрите, основная проблема, с которой я сталкиваюсь, заключается в том, что я работаю в веб-приложении. Приложение будет иметь две основные области: frontend и backend. На данный момент у него будет пять основных ролей: ROLE_SUPER_ADMIN, ROLE_ADMIN, ROLE_EXECUTIVE и еще две. Эти роли будут иметь доступ к серверной части, но не ко всем областям, поэтому мне нужно нарисовать это на диаграмме, чтобы я мог обсудить это с остальной командой. Итак, как бы вы это смоделировали? - person ReynierPM; 23.01.2016
comment
Я добавил диаграмму в свой ответ, чтобы показать, как я буду ее моделировать. - person www.admiraalit.nl; 25.01.2016
comment
Отлично, мне нравится ваш подход, и теперь я буду использовать его в отношении инструмента для создания диаграмм. Я использую Visual Paradigm 13.0 CE, у меня много UC, есть ли способ разделить эти UC по их функциональным возможностям? Например, одна основная диаграмма с надписью «Администрирование пользователя», а затем при нажатии переходит к расширенному представлению этого случая, содержащему диаграмму, подобную вашей? Есть идеи по этому поводу? Взгляните на это, тогда вы поймете, о чем я говорю. - person ReynierPM; 26.01.2016
comment
Вы можете создать диаграмму пакета, содержащую символ пакета с надписью «Управление пользователями», и при открытии пакета показать диаграмму вариантов использования. Я не знаю, возможно ли это в Visual Paradigm. Если вам нужна дополнительная информация, задайте новый вопрос. - person www.admiraalit.nl; 26.01.2016

arrow_upward
0
arrow_downward

В основном это зависит от того, кого вы спрашиваете. Итак, вот мои 5 центов:

  • Избегайте включения/расширения, поскольку они являются признаком функциональной декомпозиции (если вообще: расширение на вашей диаграмме неверно)
  • CRUD UC всегда находятся на грани. В этом случае я бы не пытался вводить Admin User, поскольку он не кажется действительным UC, в то время как части CRUD являются.
  • Поскольку вы подключили актеров, суперадмин может делать все, что угодно, но админ может только создавать. Это не кажется логичным. Если у вас есть обобщенный актор, он наследует весь доступ к UC общего. Означает: вам не нужно повторять подключения к UC (если вы не добавите некоторые ограничения).
person qwerty_so    schedule 22.01.2016
comment
Хорошо, взгляните на редактирование, которое я сделал в ОП, и на основе того, что является правильным представлением? Или снова дайте мне еще 5 центов :p lol - person ReynierPM; 22.01.2016
comment
Ну, вы перепутали продлёнку, но не обратили внимания на то, что я сказал. Включаемый вариант — полная ерунда :-p . Означает, что пользователь-администратор будет участвовать во всех шагах CRUD. - person qwerty_so; 23.01.2016
comment
Я думаю, что спецификация UML оставляет место для интерпретации, что включенный вариант использования может быть включен в альтернативный поток и, следовательно, не будет выполняться в каждом сценарии. - person www.admiraalit.nl; 23.01.2016
comment
@www.admiraalit.nl Смотрите мой первый пункт. I/E - это две очень плохие концепции в UML, и они проистекают из технического/функционального подхода, который ввели некоторые ребята, в основном с техническим образованием. Они злые (!) и причинят вред и смятение. Я никогда не видел случая, когда они действительно нужны. - person qwerty_so; 23.01.2016
comment
@www.admiraalit.nl И нет: в спецификации UML указано, что отношение Include указывает, что вариант использования содержит поведение, определенное в другом варианте использования. - person qwerty_so; 23.01.2016
comment
@ThomasKilian: я думаю, что включение полезно. Основное использование отношения «Включить» — повторное использование общих частей. В этом случае повторного использования нет, но, тем не менее, включение здесь не вредно. Альтернативой может быть: один вариант использования с несколькими альтернативными потоками. Но нет большой разницы между одним вариантом использования с 4 потоками и 4 отдельными вариантами использования, если каждый вариант использования дает наблюдаемый результат, представляющий ценность для субъекта. - person www.admiraalit.nl; 23.01.2016
comment
@ThomasKilian: О спецификации UML: да, но что означает «содержит»? Я думаю, что если включенный вариант использования включен в альтернативный поток, то поведение включающего варианта использования содержит поведение включенного варианта использования (хотя и не во всех возможных сценариях). - person www.admiraalit.nl; 23.01.2016
comment
@www.admiraalit.nl Если вы повторно используете UC, то он не будет представлять какую-то индивидуальную добавленную стоимость. Итак, еще раз: включить неправильно. Мы, скорее всего, не будем уточнять это в комментариях. Мне потребовалось много лет, чтобы по-настоящему понять это. Биттнер/Спенс очень и очень помогли. - person qwerty_so; 24.01.2016
comment
@ThomasKilian: Я надеюсь, что вам понадобится меньше времени, чтобы действительно действительно понять это :-) Каждый из пяти вариантов использования в этом примере добавляет ценность актеру, даже те, которые используются повторно. - person www.admiraalit.nl; 25.01.2016
comment
@www.admiraalit.nl Вы имеете в виду пользователя с правами администратора. да. Очень ценно. - person qwerty_so; 25.01.2016