Диаграмма последовательности — UML 2.0 — объектно-ориентированный (базовый)

Я изучаю UML и сосредоточился на проекте, похожем на Netflix, на котором можно попрактиковаться.

Я пытаюсь создать простую диаграмму последовательности для «потокового фильма», состоящую только из классов сущностей (поэтому игнорируются такие объекты, как пользовательский интерфейс, сервер и база данных).

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

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

И это диаграмма последовательности для «потокового фильма», с которой мне нужна помощь:

введите здесь описание изображения

Как лучше всего построить эту диаграмму последовательности, сохранив ее при этом относительно простой?

Заранее спасибо.


person AKL012    schedule 31.03.2018    source источник
comment
Что является лучшим способом, просто основано на мнении. Это зависит от вашей аудитории.   -  person qwerty_so    schedule 31.03.2018


Ответы (1)


Я не могу дать вам «лучший способ», но я могу прокомментировать то, что я вижу на ваших прилагаемых диаграммах. Может быть, вы можете использовать это, чтобы уточнить вопросы, которые являются более конкретными.

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

Вверху ваша диаграмма классов выглядит гораздо более полной и понятной. Я могу комментировать здесь только выбор дизайна, а не семантику/синтаксис UML. Я буду рад ответить на любые ваши конкретные вопросы по этому поводу, но, поскольку это мнение, я не буду публиковать мысли в настоящее время.

person muszeo    schedule 04.04.2018