Диаграмма. ПР1.Диаграммы вариантов использования. Построение диаграммы вариантов использования (use case diagramm)
 Скачать 1.32 Mb.
|
|
Практическая работа №1. Тема: Построение диаграммы вариантов использования (use case diagramm) Задание: Разработать диаграмму вариантов использования для информационной системы: Пользователь устанавливает приложение и регистрируется, указав ФИО и лицевой счёт, пароль. Так же пользователь может прикрепить данные банковской карты для быстрой оплаты, но не обязательно. Работа возможна только для авторизованного пользователя. Пользователь может оплатить услуги за электроэнергию, введя показания индивидуального прибора учёта. При введении показаний пользователь может запросить отчёт по оплате своего лицевого счёта, указав период для отчёта. Если карта не "привязана" к аккаунту, то пользователь вводит данные банковской карты и подтверждает оплату. Если карта "привязана", пользователь подтверждает оплату. После оплаты приложение генерирует квитанцию об оплате, которую пользователь может скачать. При закрытии приложения квитанция не сохраняется. Ход выполнения работы Диаграмму будем создавать в Microsoft Visio (если установлен на компьютере) или в он-лайн редакторе диаграмм (например, здесь https://online.visual-paradigm.com). 1.Если работаете в Microsoft Visio: Создаёте новый документ и открываете Дополнительные фигуры -> Программы и базы данных -> Программное обеспечение -> Сценарии выполнения UML 2.Если работаете в он-лайн редакторе: Открываете ресурс https://online.visual-paradigm.com и выбираете пункт меню: Explore — Dagram Creator Откроется страница: Пролистайте страницу Выберите элемент Use Case Diagram После должно открыться рабочее окно (может с примером) Создайте новый документ командой File — Greate New В открывшемся окне и снова выбираете тип диаграммы Use Case Diagram. Если в числе популярных тип не указан, тогда ищите его в разделе Diagram. Должно открыться рабочее окно: Объекты, которые можно использовать при построении диаграммы, расположены слева ------------------------------------------------------------------------ Построение диаграммы Порядок построения диаграммы: определяем актёров определяем варианты использования определяем виды взаимодействия строим диаграмму Область построения диаграммы Объекты, используемый при построении диаграммы ПРИМЕР. Мобильное приложение Рассматриваемый пример диаграммы создан в он-лайн редакторе. 1. Рисуем прямоугольник подсистемы: 2. Определяем актёров В нашей системе это обычный пользователь и авторизованный пользователь. Рисуем их рядом с нашей подсистемой, причём учитываем, что авторизованный пользователь наследует (обобщает) свойства обычного пользователя (может прикрепить карту) и рисуем связь "обобщение": 3. Определение вариантов использования Обратите внимание: связи между актёрами и прецедентами прямые и рисуются без всяких стрелок o установка приложения - такой вариант использования есть в описании предметной области, но т.к. он не относится к подсистеме, то его рисуем за пределами подсистемы o у обычного пользователя есть только один вариант использования: регистрация Но при регистрации возникают дополнительные действия (прецеденты): ввод ФИО, лицевого счёта и пароля, и не обязательный ввод данных карты. Для обязательных прецедентов используется отношение включения, для не обязательных - расширения o оплата услуг авторизованным пользователем. Причём пользователь должен внести показания прибора учета. И может запросить отчет с возможным выбором периода После ввода показаний прибора учёта пользователь должен подтвердить оплату (обязательное действие, поэтому делаем включение). Если карта не была привязана в личном кабинете, то добавляем через включение действие ввод данных карты. Visio не полностью реализует стандарт UML - для альтернативных действий там есть специальные формы прецедентов. Но можно альтернативность прецедента акцентировать надписью на стрелке (тип ассоциации и так понятен по направлению стрелки) После подтверждения оплаты система генерирует квитанцию (делает это всегда, поэтому включение). Действия пользователя в этом случае не описаны, но т.к. сказано, что система не хранит квитанции, то напрашивается расширение для сохранения квитанции o после всего вспомнили, что обычному пользователю для превращения в авторизованного нужно авторизоваться и, хотя этого нет в описании предметной области, добавляем этот прецедент: Итоговый вариант диаграммы прецедентов: Задания для самостоятельной работы Задание 1. Программа для фитнес-центра по распределению фитнес – расписания и контроля его соблюдения. Предполагается, что в системе фитнес центра будет 3 роли пользователей: клиенты, тренеры, администраторы. Авторизация в системе производится по телефону и паролю. Клиенты могут зарегистрироваться в системе, указав ФИО, телефон, пароль, дату рождения, фото профиля, пол. Администраторы – пользователи с уже заполненным профилем. Они могут добавлять новых тренеров и записывать их на различные курсы обучения с целью поддержки и улучшения их профессиональной квалификации. Постоянным клиентам администраторы могут предоставлять скидки на тренировки. Любой клиент после авторизации может выбрать себе тренера (если у него нет такового). В этом случае клиент видит список тренеров с именем, фото, полом, стажем работы и списком достижений. Клиент может отправить заявку любому из тренеров, написав при этом цель, которую он хочет достигнуть при тренировках. Тренер после авторизации видит новые заявки от клиентов и их количество (если таковые имеются). Тренер может принять заявку или отклонить. В случае отказа, тренер должен указать причину. В случае подтверждения заявки тренер должен выставить план индивидуальных занятий для клиента. Выбрав из списка клиентов без плана тренировок, тренер видит цель клиента, его возраст и планирует даты тренировочного цикла. Для индивидуальных занятий тренер может выбрать упражнения, указывая при этом его вид (приседания, отжимания и т.д.), частоту выполнения (сколько раз в неделю), число подходов и число повторений в каждом подходе. Клиент, отправивший заявку, но не получивший ответа, видит список своих заявок с результатами (в том числе с указанием причины при отказе) и количеством дней ожидания ответа. Получив план тренировок, клиент видит экран с 2 вкладками: план тренировок (дата- список упражнений через запятую) и сегодняшний перечень индивидуальных занятий. Для последней выводится список: вид упражнения, количество повторов и Checkbox, позволяющий отметить выполнения, упражнения. Несмотря на это, упражнение не будет засчитано системой до тех пор, пока клиент не укажет показатель своего пульса во время выполнения упражнения. Сверху выводится сегодняшний прогресс (по количеству выполненных упражнений) в процентах с графическим отображением. Тренер также может посмотреть список своих текущих клиентов с указанием у каждого: проценты выполнения всего цикла тренировок (зависит от длительности цикла) и процента выполненных упражнений (т.к. некоторые упражнения могут быть пропущены). По каждому клиенту выводится средний показатель пульса во время выполнения упражнений. Задание 2. Создайте диаграмму прецедентов для информационной системы: 1. Автосервис 2. Автостоянка Автосалон 3. Бассейн 4. Библиотека 5. Интернет-магазин 6. Обработки заказов (кафе) 7. Оптовый склад 8. Организация спортивных соревнований 9. Поликлиника 10. Расчет заработной платы 11. Театр 12. Учёт успеваемости студентов |