Диаграмма последовательности UML: пример с наличием
Диаграмма последовательности UML: пример каталога игр с тремя участниками и двумя ответами. Разбираю сообщения, alt и предлагаю запрос для проверки в LibraChat.
А
Андрей
Преподаватель, научный редактор
6 мин чтения
«А куда поставить результат — отдельным столбцом?» В этом вопросе обычно прячется полезная путаница. Слова «каталог», «наличие» и «результат» можно поставить в ряд, но они ещё не называют трёх участников общения. Наличие может быть значением, а результат — тем, что один участник сообщает другому.
Для запроса «диаграмма последовательности uml пример» разберу учебный каталог настольных игр. В нём три участника и два возможных ответа пользователю. Покажу текстовую запись PlantUML и способ прочитать одну выбранную ветвь, не превращая альтернативы в действия подряд.
Диаграмма последовательности UML: пример с тремя участниками
Условный пользователь открывает карточку игры. Каталог запрашивает сведения у сервиса наличия. Тот возвращает признак доступности, после чего каталог показывает соответствующее сообщение пользователю. Покупку, оплату и доставку в этот сценарий не добавляю: они требуют других условий.
Сначала я подписываю участников. В UML линия жизни относится к отдельному участнику взаимодействия. Для выбранной модели роли такие:
Участник · Его роль в нашем примере · Что не следует путать с ним
Пользователь — Запрашивает карточку и получает ответ — Текст сообщения на экране
Каталог — Обращается за наличием и показывает результат — Название очередного этапа
Сервис наличия — Возвращает сведения о доступности игры — Само значение «да» или «нет»
Сервис здесь выделен сознательно как отдельный участник модели. Это не утверждение об устройстве любого настоящего магазина. Если в твоей системе сведения получает другой компонент, сначала опиши его роль. Название столбца должно соответствовать выбранному взаимодействию.
Мне помогает простой вопрос: кто кому что передаёт? В ответе нужны отправитель, получатель и содержание. «Наличие» само по себе не объясняет ни отправителя, ни получателя. А фраза «Каталог запрашивает наличие у сервиса» уже позволяет провести конкретное сообщение.
Ещё до стрелок я уточняю, какую игру проверяем. Дадим ей условное обозначение И-17. Вопрос каталога и ответ сервиса должны относиться к ней же. Если в пересказе незаметно появилась другая игра, верное количество участников не спасает модель. Поэтому при чтении сохраняю предмет запроса, а не только имена отправителя и получателя.
Текстовая запись одного сценария
Ниже — авторский исходник для PlantUML. Названия участников даны по-русски, короткие имена `User`, `Catalog` и `Stock` нужны для обращения к ним в строках сообщений.
```plantuml
@startuml
actor "Пользователь" as User
participant "Каталог" as Catalog
participant "Сервис наличия" as Stock
User -> Catalog: Открыть карточку игры И-17
Catalog -> Stock: Проверить наличие И-17
Stock --> Catalog: Доступность: да или нет
alt Доступность = да
Catalog --> User: Показать: игра доступна
else Доступность = нет
Catalog --> User: Показать: игра недоступна
end
@enduml
```
Объявления в начале задают участников. Строки со стрелками задают сообщения. В этой записи запросы обозначены сплошными стрелками, ответы — пунктирными. Такой рисунок стрелок помогает читать пример, но подпись и направление всё равно нужно проверять по смыслу.
И-17 — метка нашей учебной игры, а не установленный формат настоящего API. Для конкретной системы состав передаваемых сведений задаётся её требованиями. Здесь достаточно проследить, что проверяли и какой ответ показали, без выдуманных полей промышленного сервиса.
Верхние три сообщения общие для двух результатов. Пользователь обращается к каталогу, каталог — к сервису, сервис возвращает сведения. Затем выбирается соответствующая ветвь. Слово `alt` открывает альтернативы, `else` отделяет другой вариант, `end` завершает этот блок.
Здесь условия взаимоисключающие: один заданный признак не может одновременно иметь значения «да» и «нет». Сбой сервиса, неизвестное состояние и отсутствие ответа отдельно не моделируются. Если они нужны задаче, придётся расширить сценарий, а не назвать эти случаи уже разобранными.
Пять стрелок на записи, четыре сообщения в проходе
На исходнике видны пять строк сообщений: три общих и два альтернативных ответа. Но один выбранный проход использует четыре. После ответа сервиса каталог показывает либо доступность, либо недоступность. Обе надписи не обязаны последовательно появляться у пользователя.
Я проверяю отрицательный случай так:
Пользователь запрашивает карточку.
Каталог спрашивает о наличии игры.
Сервис возвращает значение «нет».
Каталог сообщает пользователю, что игра недоступна.
На этом проход заканчивается. Если после четвёртого пункта я ещё дописал сообщение «игра доступна», значит, прочитал альтернативы как продолжение одной цепочки. Исправлять нужно выбранный путь чтения или условия, а не добавлять ещё одного участника с именем «Результат».
Положительную ветвь проверяю отдельно. Первые два обращения те же, но сервис возвращает «да», и пользователь получает другой ответ. Это небольшая учебная модель. Она объясняет различие путей, а не доказывает корректность правил наличия в реальном каталоге.
Расстояние между сообщениями не равно секундам
На схеме можно оставить больше места между стрелками ради читаемости. Из этого нельзя заключить, что проверка заняла дольше. В нашем условии нет измерений и требований к задержке. Поэтому числа секунд я сюда не добавляю.
Для выбранного примера важна зависимость: каталог использует полученный признак, чтобы выбрать сообщение пользователю. В более сложных взаимодействиях UML различает разные способы задания порядка, включая параллельные фрагменты. Любую диаграмму последовательности нельзя автоматически считать одной полной шкалой времени.
Если поменять местами линии жизни Catalog и Stock, запрос о наличии всё равно должен идти от каталога к сервису, а ответ — обратно. Проверь стрелки по этим двум ролям. Так можно отличить смену раскладки от ошибки во взаимодействии.
Диаграмма последовательности UML: пример для обсуждения в чате
Открой чат LibraChat и предложи проверить свой вариант. Я бы начал с такого задания:
Разбираем учебный запрос «диаграмма последовательности uml пример». Участники: пользователь, каталог, сервис наличия. Пользователь открывает карточку игры; каталог спрашивает сервис; сервис возвращает «да» или «нет»; каталог показывает один соответствующий ответ. Проверь, не потерялся ли получатель сообщения и не выполняются ли обе ветви подряд. Сначала перечисли вопросы и возможные противоречия. Не добавляй оплату, доставку и измеренное время ответа.
В ответе я искал бы конкретное место: какая стрелка имеет неверного получателя или какое условие допускает лишний путь. Общая похвала модели мало помогает разобраться. Если предлагается новая ветвь, нужно понять, из какого требования она появилась и входит ли в выбранные границы.
Текстовый разбор не заменяет проверки обозначений по требованиям твоего задания. Для других видов связей посмотри материал о построении схем. Когда определишь дальнейшую задачу в чате, можно сверить условия работы LibraChat. Здесь мы обсуждаем модель, а не обещаем готовую картинку от выбранного инструмента.
Перед приёмкой я оставляю три вопроса:
У каждого сообщения есть понятные отправитель и получатель?
Каждый выбранный результат доходит до пользователя?
Условия соответствуют двум заданным значениям, а лишние сценарии не объявлены проверенными?
Возьми ветвь «нет» и проследи её до последней стрелки. Если понятно, кто узнал об отсутствии игры и от кого, основная связь в этом примере сохранена. Слову «результат» отдельный столбец для этого не понадобился.
