А каков смысл использовать UML в данном случае? Из данной блок-схемы всё становится ясно и без UML. По крайней мере, я так вижу.
На самом деле сама блок-схема оформлена не совсем корректно:
- нет терминальных точек начало-конец (что например происходит после "отказ в продаже билета")
- в блоке решения совмещено и действие и обработка условия ("выбор рейса") собственно сначала должно быть действие действие "выбор рейса", а потом уже блок проверяющий условия по результатам выбора
- если способ оплаты без наличный то происходит выдача реквизитов для оплаты и сразу "оформлен и продан билет", а что оплачивать в этом случае не нужно? Если оплата наличными то где действие по приему денег, а это тоже может быть отдельный выделенный процесс, который выполняется другим актером
- блоки "действий" сочетают в себе также обозначение состояния - "оформлен и продан билет". Действие должно обозначаться - "оформление и продажа билета".
А UML и диаграмма деятельности могут помочь в том чтобы четко разделить действия "пользователя" и "системы".
"Хочу построить диаграмму продажи и бронирования и подачи предварительной заявки на билет (отложенная покупка)"
Вообще пока автору нужно четко определиться с целью и задачей. Для чего предназначена диаграмма, какой процесс она должна отражать? Какая цель разработки данной диаграммы? Для чего она предназначена?
Дополнительно рекомендовал бы на диаграмму добавлять элементы "артефактов" - билет, бланк заявки и т.п. (для блок смех есть соответсвующие элементы)
Я бы рекомендовал автору использовать даже не диаграммы деятельности UML, а посмотреть в сторону нотации eEPC диаграммы в ARIS (тем более что появился бесплатный Aris Express). Там более строгие требования к оформлению и он больше приспособлен именно к описанию БП, дает более четкое понимание какие действия к какому результату приводят (например каждое действие должно переходить в событие).