Верна ли моя диаграмма вариантов использования? Об обобщении вариантов использования

Изменить:

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

конечный вариант использования

Это моя диаграмма вариантов использования View Repository в системе управления исходным кодом.

Эта система является частью системы управления проектами.

Просмотреть схему вариантов использования репозитория

Система аналогична GitHub, пользователь может выбрать проект.

И он отобразит список репозиториев для проекта.

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

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

Правильно ли мое использование обобщения вариантов использования?

Ниже приведен вариант использования предыдущей версии, я узнал, что использование диаграммы вариантов использования для моделирования процесса неверно (Seidl et al., 2015, стр. 37).

Неверный вариант использования

  1. Зайдл, М., Хьюмер, К., Каппель, Г., и Шольц, М. (2015). UML @ Classroom: введение в объектно-ориентированное моделирование. Чам: Springer International Publishing.

generalization uml use-case-diagram
person wei    schedule 17.07.2019    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Хорошо, позвольте мне задать вопрос: можете ли вы абстрагироваться от добавленной стоимости? Единственный случай, когда это верно, называется франшиза. Итак, что вы сделали, так это ввели новый абстрактный кружок, чтобы соединить три конкретных варианта использования с вашим актером, вместо того, чтобы соединять конкретные кружки напрямую. Зачем? Где добавленная стоимость для «Просмотреть репозиторий»?

Для абстрактного актера все аналогично. Нет необходимости делать User абстрактным, так как он уже абстрактный. Все актеры обозначают роли, а не реальные вещи. Вы можете просто убрать ключевое слово abstract, и это не изменит семантику.

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

Как всегда, я рекомендую прочитать Bittner/Spence о вариантах использования.

person qwerty_so    schedule 17.07.2019
comment
Я слишком много думал, а решение оказалось таким простым. Вы также правы насчет функциональной декомпозиции, я уже сделал это, например, создал пузырь для ввода имени. Спасибо за помощь. - person wei; 17.07.2019

arrow_upward
0
arrow_downward

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

person Syauqi Haris    schedule 08.07.2020