Ассоциация в диаграмме вариантов использования

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

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

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


use-case uml staruml
person BlackZero    schedule 21.10.2017    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

Первую выбросьте и никогда больше не делайте свои диаграммы UC таким образом ;-)

person Ister    schedule 21.10.2017
comment
Проголосовал за ваш ответ. Я просто добавил некоторые аспекты в свой. - person qwerty_so; 21.10.2017
comment
Мы согласны с тем, что вход в систему не добавляет большой ценности для бизнеса, но обычно безопасность является важной темой, и нам нужно иметь возможность отслеживать, что пользователь делает в системе, и в любом случае он ничего не может сделать, если он не подключен. И наш клиент хочет видеть, что разработанная система является защищенной и что пользователь должен быть подключен. По всем этим причинам обычно мы оставляем Логин в качестве варианта использования. - person granier; 22.10.2017

arrow_upward
0
arrow_downward

Ни один из них не является правильным, поскольку Login не является вариантом использования. Он не имеет добавленной стоимости. А вариант использования показывает именно ту добавленную стоимость, которую рассматриваемая система принесет одному из ее участников. Сделайте 2-й снимок и выбросьте Login, и я скажу "ОК".

Вы можете показать, что требуется вход в систему, прикрепив к UC ограничение, говорящее { actor must be logged on}. Или, если всем UC требуется логин, прикрепите его к актеру, например { all/UC x, y need a login}.

Кроме того, большинство людей ошибочно воспринимают использование extend/include. Они используют его для функциональной декомпозиции, что совершенно неправильно. Лучше всего просто избегать их и придерживаться простых ассоциаций человека с мыльными палочками.

person qwerty_so    schedule 21.10.2017