При разработке диаграммы вариантов использования мы сталкиваемся с проблемой, в которой участвуют три участника: посетитель, клиент и администратор. У каждого свои уникальные роли, но мы должны точно отразить их взаимодействие и отношения. Точнее, Клиент резервирует парковочные места, а Администратор их удаляет, и нам необходимо четко разграничить эти возможности, сохраняя при этом наглядность схемы.
Как мы можем эффективно смоделировать эти различные функциональные возможности и обеспечить краткое и понятное представление?
Я попытался смоделировать взаимодействие между тремя участниками и их уникальные функциональные возможности на диаграмме вариантов использования. Я ожидал найти ясный и краткий способ представления их отношений и действий, особенно для резервирования и удаления парковочных мест, сохраняя при этом простоту диаграммы.
Эта диаграмма теряет лаконичность, поскольку она определяется пользовательским интерфейсом, а не целями субъекта.
То, что клиент сначала ищет машиноместа, потом видит детали, потом резервирует место — это моделирование пользовательского интерфейса или рабочего процесса. Это не является целью диаграмм вариантов использования, и их можно лучше смоделировать с помощью других методов (например, диаграммы деятельности). варианты использования не должны иметь какого-либо последовательного порядка, и «extend»
не должен использоваться для обозначения того, что одна функциональность вызывается из другой.
Более того, обобщение следует использовать только тогда, когда специализированный вариант использования может в любой момент заменить более общий. Его нельзя использовать для разложения функциональности на более мелкие части, как вы это сделали здесь.
Варианты использования должны быть сосредоточены на ключевых целях участников и взаимосвязи между этими целями, независимо от будущей реализации.
Я отредактировал заголовок, чтобы сделать его более понятным и помочь людям с похожими проблемами легче его найти. Надеюсь, это нормально для тебя