Мне трудно понять, как будет работать конкретный сценарий:
У меня есть сервер базы данных, веб-сервер и пользователь.
Когда пользователь регистрирует службу, созданную на веб-сервере, веб-сервер затем переходит к серверу базы данных и возвращается на веб-сервер для регистрации деталей.
Как бы я на самом деле это проиллюстрировал.
Я создал трех Актеров; Пользователь, веб-сервер, сервер базы данных.
В качестве примечания я прочитал много онлайн-ресурсов, а также книгу по UML.
Заранее спасибо.
Являются ли серверы БД/веб-серверы частью внедряемой вами системы? Если это так, они вам не нужны как Актеры. На диаграммах UC должны отображаться только действующие лица, выходящие за рамки вашей системы.
Таким образом, в этом случае вам нужен только один Актер (Пользователь). Вариант использования должен описывать цель с точки зрения пользователя (например, «Купить виджет»).
Вы можете показать серверы на диаграмме, показывающей, как реализован UC — обычно это диаграмма последовательности или диаграмма действий. Хотя я обычно ожидаю увидеть логические сущности (классы) вместо физических серверов.
чт.
Я согласен с последним утверждением maple_shaft. UC высокого уровня (вариант использования) — это средство сбора требований.
Req'ts — это «что» системы. Что должна делать система. Что нужно сделать пользователю. Какое взаимодействие нужно пользователю от системы.
Захватывая системные компоненты в своем UC, вы вводите в него «как», а это неуместно для UC. Вы не хотите, чтобы ваш вариант использования говорил, как система что-то выполнит, поскольку это решение о реализации.
Короче говоря, я не согласен с тем, что вы действительно хотите создать диаграмму вариантов использования. Это больше похоже на диаграмму компонентов.
Диаграммы вариантов использования должны представлять пользовательский поток и нетехнический поток с точки зрения пользователя, а не демонстрировать базовую архитектурную структуру.
