Модель деятельности проектируемой системы
Диаграммы деятельности обеспечивают еще один способ моделирования потока событий. С помощью текстового описания можно рассказать о потоке, но трудно будет понять логику событий в сложных и запутанных потоках с множеством альтернативных ветвей.
Диаграммы деятельности создаются также на разных этапах жизненного цикла системы для отражения последовательности выполнения операций.
В рамках данной работы рассмотрим лишь некоторые из прецедентов модели нашей проектируемой системы.
Диаграмма деятельности прецедента Авторизация (см. рис. 2). В данном процессе принимают участие непосредственно сам актёр, система, представленная сайтом, и база данных. Процесс авторизации актёра на сайте можно описать следующим образом.
Сперва актёр открывает сайт и, нажав кнопку "Войти", открывает диалоговое окно авторизации. Система (сайт) предлагает ему ввести логин и пароль от своего аккаунта. Актёр вводит свои данные, и если они верные, то система предоставляет актёру доступ к своему аккаунту и актёр может перейти к каталогу услуг. Если же хотя бы одно из значений пары логин-пароль введено неверно, сайт выводит сообщение о неверности введённых данных и предлагает восстановить пароль. Пользователь восстанавливает пароль и проходит процесс авторизации заново.
Рисунок 2 – Диаграмма деятельности прецедента Авторизация
Следующий прецедент – прецедент Просмотр вариантов услуги (см. рис. 3). Процесс деятельности данного прецедента выглядит так.
Пользователь открывает каталог услуг, а система показывает ему этот каталог. Затем пользователь выбирает необходимую ему услугу. После этого сайт отрывает список районов города – пользователь должен выбрать тот район, в котором он проживает или находится в данный момент. Если пользователь находится/проживает не в городе, а в пригородной части (микрорайоны), то в таком случае он нажимает на кнопку "Я из пригорода". После этого пользователь выбирает из списка предложенных адресов тот, по которому он сейчас находится. Также он может ввести свой адрес вручную. Затем система отправляет запрос в базу данных, чтобы проверить адрес на существование. Если адрес верный, то сайт отображает его на карте, иначе выводит сообщение о том, что такого адреса не существует – после чего пользователь снова может выбрать район города и пройти процедуру ввода адреса ещё раз. В случае верности адреса, сайт предлагает выбрать необходимую специальность, отвечающую его запросам по болезни. Если такая специальность находится, то пользователь её выбирает. Если же такой специальности нет, то сайт высвечивает соответствующее сообщение. После этого пользователь может ещё раз просмотреть список доступных специальностей.
Рисунок 3 – Диаграмма деятельности прецедента Просмотр вариантов услуги.
Далее перейдём к прецеденту Добавление информации о записи (см. рис. 4).
После того, как пользователь выбрал район и специальность, сайт предлагает ему список врачей по выбранной специальности. Сайт отправляет запрос в базу данных на предоставление списка действующий врачей. База данных предоставляет системе список действующих врачей и сайт отображает этот список. Пользователь выбирает нужного врача, после чего система отправляет запрос в базу данных на предоставление информации о расписании выбранного врача. База данных предоставляет системе такую информацию, а сайт, в свою очередь, отображает актуальное расписание. В конце, пользователь выбирает день. Если в это день у врача есть окно, то кнопка с этим днём активна. В противном случае, кнопка не активна.
Рисунок 4 – Диаграмма деятельности прецедента Добавление информации о записи
Теперь построим диаграмму деятельности для прецедента Получение уведомлений (см. рис. 5). Данный прецедент можно описать так.
Оператор открывает раздел уведомлений. Если никаких уведомлений нет, то рядом с иконкой этого блока пусто, в противном случае появляется значок с числом, соответствующим количеству уведомлений. Если уведомления есть, то система отправляет запрос в базу данных для получения информации об этих уведомлениях. База данных передаёт эту информацию системе, и сайт высвечивает всю информацию. Далее оператор выбирает один из трёх вариантов действия: Оформить запрос как заявку, Закрыть или Удалить. В первом случае оператору открывается окно оформления заявки. где он проходит процесс оформления. Во втором случае оператор удаляет уведомление. Если он хочет, то может закрыть окно уведомлений. Любое из трёх действий – Удаление, Оформление и Закрытие – приводит к концу деятельности прецедента Получение уведомлений. Если уведомлений нет, оператор так же может открыть блок уведомлений и закрыть его.
Рисунок 5 – Диаграмма деятельности прецедента Получение уведомлений