Разработка модели требований. Мелконьянц_ИУ5-11М_ЛР4. Отчет по лабораторной работе 4 по дисциплине Технологии разработки программного обеспечения
 Скачать 0.83 Mb.
|
Факультет «Информатика и системы управления» Кафедра ИУ5 «Системы обработки информации и управления» Отчет по лабораторной работе №4 по дисциплине «Технологии разработки программного обеспечения» по теме «Разработка модели требований» Выполнил: студент группы № ИУ5-11М Мелконьянц А.Р. подпись, дата Проверила: Виноградова М.В. подпись, дата 2022 г. Цель работы Изучить унифицированный процесс разработки (RUP); Приобрести умения построения модели требований. Задание 1 Создать в среде моделирования UML новый проект типа UML Model (из шаблона). 2. На основе описания требований к СОИУ составить диаграмму(ы) прецедентов системы. Диаграмма прецедентов должна содержать: актеров, прецеденты системы, ассоциативные связи между актерами и прецедентами. 3. Составить для основных прецедентов их описания (предусловия, поток событий, постусловие). Составить для основных прецедентов диаграммы деятельности (на основе описания). 4. Уточнить диаграмму прецедентов, добавив связи типа < 5. Добавить к проекту модель предметной области. Составить в ней модель классов предметной области. 6 На основе описаний прецедентов и модели предметной области составить прототип пользовательского интерфейса (эскиз). Описание модели требований Определение функциональных требований В веб-сайте поиска пропавших домашних животных должны быть реализованы следующие функциональные требования: Возможность регистрации и авторизации физических и юридических лиц, а также гостевой доступ в систему; Возможность создания, редактирования, удаления и просмотра заявок о пропаже, находке и нахождении пропавшего питомца, а также просмотр контактной информации автора заявки; Пользователи должны иметь возможность создавать заявки; Если это заявка пользователя, то он должен иметь возможность ее редактировать и удалить; Пользователь должен иметь возможность посмотреть свою контактную информацию, отредактировать и поменять ее. Пользователь должен иметь возможность поиска заявок по одному или нескольким параметрам. Определение нефункциональных требований. В веб-сайте поиска пропавших домашних животных должны быть реализованы следующие нефункциональные требования: Система должна быть развернута на базе OS Windows; Система должна работать на 4-х ядрах процессора, 2 ГБ оперативной памяти, 256 ГБ постоянной памяти; База данных должна быть MS SQL; Интерфейс должен быть понятен пользователю. Диаграмма прецедентов В системе будет четыре актера – компания, авторизованный пользователь, неавторизованный пользователь и администратор. Компания, неавторизованный пользователь и авторизованный пользователь будет взаимодействовать с системой посредством регистрации и авторизации, а также через просмотр, создание, редактирование, удаление и поиск заявок. Так же будет возможность посмотреть и изменить свой профиль. Модератор будет иметь возможность посмотреть и заблокировать объявления Выявленные прецеденты: «Зарегистрироваться» – регистрация в системе. «Авторизоваться в системе» – авторизация в системе. «Войти в систему» – вход в систему. «Внести контактную информацию» – внесение контактной информации. «Редактировать контактную информацию» – редактирование контактной информации. «Создать заявку» – создание заявки. «Проверить информацию о зарегистрированных клиентах» – проверка информации о зарегистрированных клиентах. «Редактировать заявку» – редактирование заявки. «Удалить заявку» – удаление заявки. «Искать заявку» – поиск заявки. «Искать заявку компании» – поиск заявки компании.  Спецификация прецедентов Зарегистрироваться Предусловия: Пользователь должен зайти в систему. Главный поток Прецедент «Зарегистрироваться» начинается, когда пользовать нажимает на кнопку регистрации в системе. Система отображает форму для ввода имени, фамилии, отчества, адреса, телефона, почты, логина и пароля. После происходит отправка формы (Е-1, Е-2, Е-3, E-4, E-5, Е-6, E-7, E-8). Возврат к началу прецедента. Е-1: поле ввода имени осталось пустым. Пользователь может повторить ввод имени или прекратить прецедент. Е-2: поле ввода фамилии осталось пустым. Пользователь может повторить ввод фамилии или прекратить прецедент. Е-3: поле ввода отчества осталось пустым. Пользователь может повторить ввод отчества или прекратить прецедент. Е-4: поле ввода адреса осталось пустым. Пользователь может повторить ввод адреса или прекратить прецедент. E-5: поле ввода телефона осталось пустым. Пользователь может повторить ввод телефона или прекратить прецедент. E-6: поле ввода почты осталось пустым. Пользователь может повторить ввод почты или прекратить прецедент. E-7: поле ввода логина осталось пустым. Пользователь может повторить ввод логина или прекратить прецедент. E-8: поле ввода пароля осталось пустым. Пользователь может повторить ввод пароля или прекратить прецедент. Постусловия: В БД создана запись пользователя. Авторизоваться Предусловия: Пользователь должен пройти регистрацию; Пользователь должен зайти в систему. Главный поток: Прецедент «Авторизоваться» начинается, когда пользовать нажимает на кнопку авторизации, создания объявления на портале. Система отображает форму для ввода логина и пароля. После происходит отправка формы (E-1, E-2). Возврат к началу прецедента. E-1: введен неверный логин. Пользователь может повторить ввод логина или прекратить прецедент. E-2: введен неверный пароль. Пользователь может повторить ввод пароля или прекратить прецедент. Постусловие: В БД создана сессия пользователя; Создать заявку Предусловия: Пользователь должен пройти авторизацию; Пользовать должен зайти в систему. Главный поток: Прецедент «Создать заявку» начинается, когда пользователь нажимает на кнопку создать заявку в системе. Система отображает форму для ввода клички, вида, цвета, пола, даты и загрузки фотографии питомца. Пользователь заполняет поля формы и нажимает на кнопку «Создать», после этого происходит отправка формы на сервер. На сервере происходит валидация данных (E-1, E-2, E-3, E-4, E-5). E-1: проверка ввода клички. Если кличка длиннее 40 символов, то возвращаем пользователю ошибку «Слишком длинная кличка. Кличка должна быть меньше 40 символов». Пользователь может повторить ввод названия или прекратить прецедент. E-2: проверка ввода вида. Если вид длиннее 40 символов, то возвращаем пользователю ошибку «Слишком длинное название вида. Вид должен быть меньше 40 символов». Пользователь может повторить ввод описания или прекратить прецедент. E-3: проверка ввода цвета. Если цвет длиннее 40 символов, то возвращаем пользователю ошибку «Слишком длинное название цвета. Цвет должен быть меньше 40 символов». Пользователь может повторить ввод описания или прекратить прецедент. E-4: проверка ввода даты. Если дата является еще не произошедшей, то возвращаем пользователю ошибку «Дата не соответствует прошедшему времени. Дата должна иметь прошедшее или настоящее время». Пользователь может повторить выбор цены или прекратить прецедент. E-5: проверка фотографии. Если фотография больше 3 МБ, то возвращаем ошибку «Фотография не должна быть больше 3 МБ». Пользователь может повторить загрузку фотографии или прекратить прецедент. Если ошибок не было, то сохраняем данные в БД и выдаем пользователю уведомление, что заявка успешно создана. Постусловия:__В_БД_создана_запись_заявки.__Искать_заявку_Предусловия'>Постусловия: В БД создана запись заявки. Искать заявку Предусловия: Пользователь должен пройти авторизацию; В системе создана хотя бы 1 заявка; Пользовать должен зайти в систему. Главный поток: Прецедент «Искать заявку» начинается, когда пользовать заходит в систему. Система отображает форму для ввода клички, вида, цвета, пола, даты и загрузки фотографии питомца. Пользователь заполняет поля формы и нажимает на кнопку «Создать» Происходит запрос за данными объявления (E-1). Возврат к началу прецедента. E-1: отсутствие данных для поиска. Пользователь может заполнить поля для поиска заявки или прекратить прецедент. Постусловия: После система выводит подходящие заявки пользователю. Диаграмма деятельности Диаграмма активностей прецедента «Зарегистрироваться»  Диаграмма активностей прецедента «Авторизоваться»:  Диаграмма активностей прецедента «Создать заявку»:  Диаграмма активностей прецедента «Искать заявку»:  Диаграмма классов предметной области  Прототип пользовательского интерфейса Прототип авторизации:  Прототип регистрации:  Прототип просмотра заявки:  Прототип создания заявки  Вывод В результате проделанной работы произошло формирование функциональных и нефункциональных требований к системе, построение диаграммы прецедентов. На основе прецедентов написана спецификация и построены диаграммы активности. Так же была построена диаграмма классов и реализован прототип системы. Список литературы Методические указания к лабораторной работе; Каюмова А.М. Визуальное моделирование систем в StarUML; Новиков Ф.А. Анализ и проектирование на UML. |
