Сервер как субъект в диаграмме вариантов использования для мобильного приложения
================================================================================

Я разработал приложение для Android, которое взаимодействует с сервером. Через приложение пользователь аутентифицируется в системе, на которой работает сервер, и после того, как сервер сможет отправить информацию в мое приложение.

Я делаю диаграмму вариантов использования (UML) для своего приложения, но я не уверен, должен ли я представлять сервер как субъект (внешний) или опустить его на диаграмме ... Я нов в UML, так что определения немного смущают меня в данный момент ...

Кто-нибудь может мне с этим помочь?

(Извините, если это не то место, где можно задавать подобные вопросы).

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

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

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

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

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

НТН.



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