Сценарий

Определение

👉

Сценарий — это последовательность операций.

Сценарий представлен отдельным объектом, который получает на вход фабрику операций. Подобно операции сценарий не имеет императивного интерфейса, т.к. не предоставляет доступа к своему состоянию и не имеет каких-либо методов в интерфейсе, кроме метода launch. Метод launch принимает на вход параметры, описывающие контекст запуска (переменные и/или ключевые сервисы), а также замыкание onFinish. Таким образом, сценарий похож на обычную функцию: принимает параметры на вход и возвращает результат.

💡

Основное отличие сценария от операции в том, что у операции нет доступа к фабрике операций и она не может обращаться к другим операциям.

Сценарий обладает собственным жизненным циклом, т.е. может быть запущен на выполнение и оставаться в памяти, даже если вызывающая область видимости уже удалена (асинхронный режим). Сценарий обязательно завершается вызовом коллбека/замыкания onFinish, переданного ему при запуске. Так гарантируется однозначность выполнения сценария и обеспечивается механизм его удаления. Инициализация сценария выполняется в фабрике сценариев, а запуск – в точке обращения к фабрике. Доступ к фабрике сценариев есть только у некоторых ключевых сервисов, для которых запуск сценариев и обработка результатов их выполнения — это основная зона ответственности.

В ходе выполнения сценарий обращается к фабрике операций для создания операций, после чего снабжает каждую операцию необходимым контекстом и запускает ее на выполнение. Сценарий ожидает завершения текущей операции, обрабатывает результат, после чего переходит к следующей. Также сценарий может обратиться к какому-либо ключевому сервису напрямую, не прибегая к созданию отдельной операции (например, к сервису обработки ошибок). Через прямое обращение к ключевым сервисам реализуется обмен данными между сценариями, а также иницируется запуск других сценариев. Доступ к фабрике сценариев есть только у ключевых сервисов, поэтому сценарий запускать другие сценарии не может.

Если бизнес-требования выражены в виде User Stories, то соответствие требований имеющейся реализации можно проверить, изучая именно код сценарив. Каждая User Story будет выражена в коде одним или несколькими сценариями. Таким образом, сценарии формируют каркас приложения и содержат высокоуровневую бизнес-логику.

Графическое представление

Каждый сценарий может быть описан диаграммой операций.

👉

Диаграмма операций — это диаграмма деятельности, узлами управления которой являются операции.

💡

Каждая операция сценария описывается собственной диаграммой сообщений, поэтому вся логика сценария целиком в терминах UML может быть представлена диаграммой обзора взаимодействия.

Совокупность всех сценариев в приложении может быть представлена диаграммой прецедентов. Бытует мнение, что эта диаграмма бесполезна в виду своей тривиальности. В случае ROSS картина меняется: каждый прецедент на диаграмме — это сценарий, т.е. сущность, имеющая непосредственное отображение в код. Кроме того, диаграмма выявляет «источники изменений» или «источники событий» в приложении. На диаграмме они отображены как акторы. Например, в мобильном приложении очевидным актором является пользователь, а менее очевидным может быть сервис сетевого слоя, который при получении 401-й ошибки от бекенда обязан инициировать процесс логаута. Таким образом, процесс логаута фактически инициирует сервер, а не пользователь.

Диаграмма прецедентов для приложения по управлению заказами.

Обмен данными между сценариями

Обмен данными между сценариями выполняется исключительно через ключевые сервисы. Как и операция, сценарий может возвращать результат выполнения в метод в onFinish, но обрабатывать этот результат все равно будет ключевой сервис, в котором сценарий был запущен.

💡

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

Операция Роутер