Диаграмма последовательности UML для отправки формы php

Я пытаюсь создать две UML-диаграммы над процессом отправки приложения php (до / после изменения дизайна). Я понимаю, что мой UML стал очень ржавым, и я сомневаюсь, что мои диаграммы верны, хотя я думаю, что это визуально описывает процесс очень хорошо.

Первый (до того как я сменил дизайн).

1. Пользователь заходит на страницу CMS (manage.php)
2. Manage.php начинает сборку html, для этого требуются некоторые данные из базы данных.
3. Через 5-10 секунд CMS готова и отображается как HTML для пользователя.
4. Пользователь выбрал некоторую страницу, содержащую форму для редактирования (есть несколько страниц, каждая из которых имеет свою форму, которая редактирует разные вещи).
5. Пользователь редактирует / изменяет форму. (все формы были загружены с текущими настройками на шаге 2)
6. Пользователь нажимает кнопку отправки. Все данные формы отправляются в processor.php и страница cms умирает ?? (форма обновляет страницу).
7. Пользователи проверены с некоторыми материалами сеанса (Facebook SDK) возвращает успех.
8. Процессор определяет действие (какие из форм были отредактированы).
9. Процессор проверяет полученные данные, (все было в порядке) возвращает успех.
10. Процессор отправляет операцию CRUD в БД. Успех!
11. Процессор устанавливает несколько заголовков и дает ответ клиенту.
12. CMS перезагружает все и получает новые данные из базы данных.
13. По окончании загрузки пользователь снова получает html-страницу.

Как я могу показать, что CMS и ее JS умирает? (красный X) и как я могу показать, что он снова создан (синий ->) ??

Изменение в дизайне

Поскольку этот дизайн был плохим, я решил изменить его. Вместо отправки формы и перезагрузки всей CMS каждый раз, когда редактировалась небольшая форма. Я решил представить изменения асинхронно с jQuery-запросом ajax. Страница CMS никогда не обновляется, и процесс «сохранения» теперь выполняется со световой скоростью вместо 5-10 секунд.

1. Пользователь заходит на страницу CMS (manage.php)
2. Manage.php начинает сборку html, для этого требуются некоторые данные из базы данных.
3. Появляется экран загрузки (как можно раньше)
4. Через 5-10 секунд CMS готова и отображается как HTML для пользователя.
5. Пользователь выбрал страницу, содержащую форму для редактирования ….
6. Пользователь редактирует / изменяет форму ….
7. Пользователь нажимает кнопку сохранения и запускает функцию.
8. Данные формы собираются и присваиваются переменной.
9. Перед выполнением запроса ajax кнопка становится оранжевой, сигнализируя о том, что она еще не прочитана. это также отключено.
10. Запрос Ajax сделан.
11. Пользователи проверены … успех.
12. Процессор определяет действие ….
13. Процессор проверяет полученные данные …. успех.
14. Процессор отправляет операцию CRUD в БД. Успех!
15. Процессор устанавливает статус 200 и выдает ответ клиенту.
16. Функции ajax вызывают функцию success (), которая поворачивает зеленую кнопку, сигнализируя о том, что теперь это сделано.

Процесс проверки такой же. Но остальное новое, и я также не уверен, что это правильно. И то, и другое кажется мне логичным, но мой логический смысл редко является правильным решением, особенно когда речь идет о UML.