Короче
Это (почти) действительная диаграмма вариантов использования. Но это не делает их хорошими вариантами использования . Но в конце концов важно, будет ли это полезно для вас.
Подробнее
Является ли он формально правильным в соответствии с UML?
UML зависит от значений c и определяет U C на странице 637 спецификаций (выделите мной):
UseCase - это разновидность класса BehavioredClassifier, который представляет собой объявление набора предлагаемых поведений. Каждый UseCase определяет некоторое поведение, которое субъект может выполнять в сотрудничестве с одним или несколькими Актерами . Сценарии использования определяют предлагаемое поведение субъекта без ссылки на его внутреннюю структуру. Такое поведение, включающее взаимодействия между Актерами и субъектом, может привести к изменениям состояния субъекта и взаимодействия с его окружением.
Давайте проверим действительность вашего U C с учетом этого определения:
Start game, move paddle, restart game и exit game - это варианты поведения, которые игра (субъект) предлагает в сотрудничестве с игроком (актером). ). Это действительный U C согласно UML. Ball falls, hit all bricks, hit brick и display score - это более сомнительные варианты поведения: они не требуют сотрудничества или взаимодействия с игроком. Тем не менее, вы можете возразить, что это имеет смысл только в том случае, если пользователь наблюдает за этим поведением, поэтому есть взаимодействие с игроком. Таким образом, можно утверждать, что они также действительны U C в отношении определения UML. Add score кажется чисто внутренним поведением, которое выполняется без участия пользователя и даже не наблюдается пользователем. Это не будет действительным U C. Однако метки могут вводить в заблуждение: если Display score будет означать окончательный счет за окончание игры, а Add score будет означать обновление счета на экране, можно снова утверждать, что это действительный U C.
Использование расширения (необязательно) и включения (systemati c) также кажется правильным.
Это хороший U C?
Хотя UML не зависит от значений c, многие авторы определяют вариант использования более амбициозно. В частности Ивар Якобсон , изобретатель варианта использования определяет его как :
Вариант использования - это все способы использования системы для достичь определенной цели для конкретного пользователя . В совокупности набор всех вариантов использования дает вам все полезных способов использования системы и иллюстрирует значение , которое она предоставит.
Согласно этому определению, здесь есть только один единственный вариант использования:
Play a game: это цель пользователя, которая приносит ему / ей ценность.
Все остальные элементы являются лишь способами использования системы для достижения этой цели. Таким образом, они относятся к одному варианту использования. Подход состоит в том, чтобы представить их как детали описания варианта использования:
Один из подходящих способов - показать их с точки зрения намерения в существенном варианте использования . Этот подход был изобретен Константином и Локвудом в 1999 году. Он используется по центру и оставляет полную гибкость в отношении последовательности действий в пользовательском интерфейсе.
Другой современный способ - это Use-Case 2.0 , изобретенный Иваром Якобсоном в 2011 году. Эти детали будут показаны как фрагменты вариантов использования в очень похожей форме. Кстати, чем пользовательские истории.