Сервер как действующее лицо в диаграмме прецедентов для мобильного приложения

Во-первых, для кого схема? И что вы пытаетесь с ним общаться?

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

Ваш вопрос касается прежде всего технологии; единственный заметный вариант использования - «Аутентификация» для «Пользовательского» актера. Это не кажется особенно проницательным. Развивая этот ход мыслей, следующим вопросом будет: почему пользователь должен проходить аутентификацию? то есть что он/она может сделать после успешной аутентификации? И есть ли эти вещи в вашей системе? Соответственно, аутентификация обычно сопровождается набором сопутствующих UC: регистрация в первую очередь (например, установка имени, pwd, памятные данные), сброс/восстановление утерянного pwd и т. д.

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

Обратите внимание, что эти два понятия не являются взаимоисключающими: разработка решения естественным образом вытекает из потребностей пользователей. Так что может быть оба применимы. Все зависит от того, что вы хотите сообщить.

чт.

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