Диаграммы последовательностей для операций проектных классов
Диаграмма последовательностей отображает взаимодействие объектов в динамике.
В UML взаимодействие объектов понимается как обмен информацией между ними. При этом информация принимает вид сообщений. Кроме того, что сообщение несет какую-то информацию, оно некоторым образом также влияет на получателя. В этом плане UML полностью соответствует основным принципам ООП, в соответствии с которыми информационное взаимодействие между объектами сводится к отправке и приему сообщений.
Диаграмма последовательностей относится к диаграммам взаимодействия UML, описывающим поведенческие аспекты системы, но рассматривает взаимодействие объектов во времени. Другими словами, диаграмма последовательностей отображает временные особенности передачи и приема сообщений объектами.
Диаграммы последовательностей можно использовать для уточнения диаграмм прецедентов, более детального описания логики сценариев использования. Это отличное средство документирования проекта с точки зрения сценариев использования! Диаграммы последовательностей обычно содержат объекты, которые взаимодействуют в рамках сценария, сообщения, которыми они обмениваются, и возвращаемые результаты, связанные с сообщениями. Впрочем, часто возвращаемые результаты обозначают лишь в том случае, если это не очевидно из контекста [4].
Были спроектированы диаграммы последовательностей для нескольких вариантов использования. На рис. 3.3 представлена диаграмма последовательности для операции проектного класса «Добавить аренду».
|
|
|
Рис. 3.3 Диаграмма последовательностей для операции проектного класса «Добавить аренду»
Для операции проектного класса «Добавить аренду» пользователю необходимо открыть главную страницу веб-приложения, с которой мы переходим на страницу каталога, выбрать понравившуюся машину, которая перенаправит его на страничку, непосредственно отображающую информацию об авто, где можно нажать кнопку арендовать авто. После нажатия на кнопку выведется сообщение об успешно начатой аренде. Кнопка «Арендовать», располагается под описанием машины на странице.
Рис. 3.4 Диаграмма последовательностей для операции проектного класса «Добавление автомобиля»
Сценарий описываемой последовательности сообщений между объектами программной системы начинается с того момента, когда авторизированный пользователь зашел на главную страницу веб-приложения, после которой он переходит в свой профиль, там он выбирает пункт «Добавить авто», вводит соответствующие данные и сохраняет их. После чего выводится сообщение об успешном добавлении нового автомобиля.
|
|
|
На рис. 3.5 изображена диаграмма последовательности для операции проектного класса «Авторизация пользователя».
Рис. 3.5 Диаграмма последовательностей для операции проектного класса «Авторизация пользователя»
Для операции проектного класса «Авторизация пользователя» пользователю необходимо открыть главную страницу веб-приложения, на которой нужно нажать на кнопку авторизации. После вывода формы авторизации, нам необходимо заполнить необходимые поля. Если данные были введены корректно, вы войдем в систему. После авторизации имя нашего аккаунта отобразится в нижнем левом углу и появится кнопка выхода из учетной записи.
На рис. 3.6 изображена диаграмма последовательности для варианта использования «Смена пароля».
Рис. 3.6 Диаграмма последовательностей для операции проектного класса «Смена пароля»
Для операции проектного класса «Смена пароля» пользователю необходимо открыть страницу своего профиля, на которой есть кнопка смены пароля. Для смены пароля необходимо ввести старый пароль и два раза новый. После удачной смены пароля выведется сообщение об успешной операции.
На рис. 3.7 изображена диаграмма последовательности для варианта использования «Поиск авто».
|
|
|
Рис. 3.7 Диаграмма последовательностей для операции проектного класса «Поиск авто»
Для операции проектного класса «Поиск авто» необходимо пользователю открыть страницу поиска авто с главной страницы. После ввода параметров поиска и нажатия на соответствующую кнопку, нам выведется список в соответствии с заданными параметрами.
Рис. 3.8 Диаграмма последовательностей для варианта использования «Оставить отзыв»
Для варианта использования «Оставить отзыв» необходимо пользователю открыть страницу арендованных авто с главной страницы. После ввода оценки, текстового отзыва и нажатия на соответствующую кнопку, отзыв сохраняется и становится доступен для просмотра другим пользователям.
РЕАЛИЗАЦИЯ
Тестирование
Тестирование проводится с целью обеспечить качество разрабатываемого программного продукта. Стандарт ISO-8402, посвященный описанию систем обеспечения качества программного обеспечения, под качеством понимает "совокупность характеристик программного продукта, относящихся к его способности удовлетворять установленные и предполагаемые потребности клиента". Основным параметром качества программы является надёжность. Надёжность определяется как вероятность его работы без отказов в течении определённого периода времени, рассчитанная с учётом стоимости для пользователя каждого отказа. Отказ программного обеспечения – это проявление ошибки в нём. Отсюда тестирование ПО – это процесс выполнения программы с целью обнаружения в ней ошибок. "Удачным" тестом является такой, на котором выполнение программы завершилось с ошибкой. Напротив, "неудачным" называется тест, не позволивший выявить ошибку в программе. Основные принципы организации тестирования:
|
|
|
1. Необходимой частью каждого теста должно являться описание ожидаемых результатов работы программы;
2. Программе не должна тестироваться её автором;
3. Организация – разработчик программного обеспечения не должна "единолично " его тестировать;
4. Необходимо подбирать тесты не только для правильных (предусмотренных) входных данных, но и для неправильных (непредусмотренных);
5. При анализе результатов каждого теста необходимо проверять, не делает ли программа того, что она не должна делать;
6. "Принцип скопления ошибок" – вероятность наличия не обнаруженных ошибок в некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части;
Процесс тестирования состоит из трёх этапов:
1. Проектирование тестов.
2. Исполнение тестов.
3. Анализ полученных результатов. [5]
Модульные тесты
Каждая сложная программная система состоит из отдельных частей – модулей, выполняющих ту или иную функцию в составе системы. Для того, чтобы удостовериться в корректной работе системы в целом, необходимо вначале протестировать каждый модуль системы в отдельности. В случае возникновения проблем это позволит проще выявить модули, вызвавшие проблему, и устранить соответствующие дефекты в них. Такое тестирование модулей по отдельности получило называние модульного тестирования (unit testing).
Для каждого модуля, подвергаемого тестированию, разрабатывается тестовое окружение, включающее в себя драйвер и заглушки, готовятся тест-требования и тест-планы, описывающие конкретные тестовые примеры.
Основная цель модульного тестирования – удостовериться в соответствии требованиям каждого отдельного модуля системы перед тем, как будет произведена его интеграция в состав системы. Для создания unit-теста используется класс TestCase, от которого наследуются все созданные разработчиком классы с тестами.
В силу того, что модули, подвергаемые тестированию, обычно невелики по размеру, модульное тестирование считается наиболее простым (хотя и достаточно трудоемким) этапом тестирования системы. Однако, несмотря на внешнюю простоту, с модульным тестированием связано две проблемы. [6]
1. Проверка создания объекта аренды
Class RentTest(TestCase):
def test_rent_created(self):
user1 = CustomUser.objects.create(
password='123',
email='blabla@mail.ru',
)
mark1 = CarMark.objects.create(name='Toyota')
model = CarModel.objects.create(name='testmodel', mark=mark1)
car = Car.objects.create(
price=23.00,
model=model,
year=1990,
user=user1,
)
rent = Rent.objects.create(
renter=user1,
car=car,
end_date=date(2015, 12, 30),
)
self.assertEqual(rent, Rent.objects.get(renter=user1, car=car))
Данный тест проверяет возможность создания аренды. В качестве обязательных аргументов аренда принимает, арендатора и машину.
2. Проверка свойства, задающего дату истечения заказа:
def test_car_belongs_to_user(self):
user1 = CustomUser.objects.create(
password='123',
email='blabla@mail.ru',
)
mark1 = CarMark.objects.create(name='Toyota')
model = CarModel.objects.create(name='testmodel', mark=mark1)
car = Car.objects.create(
price=23.00,
model=model,
year=1990,
user=user1,
)
self.assertEqual(car, Car.objects.get(user=user1))
Данный тест проверяет, принадлежит ли машина объекту юзер.
3.Проверка статуса аренды:
def test_rent_status(self):
user1 = CustomUser.objects.create(
password='123',
email='blabla@mail.ru',
)
mark1 = CarMark.objects.create(name='Toyota')
model = CarModel.objects.create(name='testmodel', mark=mark1)
car = Car.objects.create(
price=23.00,
model=model,
year=1990,
user=user1,
)
rent = Rent.objects.create(
renter=user1,
car=car,
end_date=date(2015, 12, 30),
)
self.assertEqual(rent.status, Rent.STATUS_UNSET)
В ходе выполнения данного теста проверяется поле status аренды. Если оно равно Rent.STATUS_UNSET, то метод работает правильно.
4. Проверка получения названия модели:
def test_model_str(self):
mark = CarMark.objects.create(name='supermark')
model = CarModel.objects.create(name='supermodel', mark=mark)
self.assertEqual(
model.__str__(),
'supermodel', "Incorrect name of model" )
Если названия марки и модели совпадают с указанными, то метод работает правильно, иначе выводится сообщение об ошибке.
Интеграционные тесты
Интеграционное тестирование – одна из фаз тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.
Интеграционное тестирование в качестве входных данных использует модули, над которыми было проведено модульное тестирование, группирует их в более крупные множества, выполняет тесты, определённые в плане тестирования для этих множеств, и представляет их в качестве выходных данных и входных для последующего системного тестирования.
Целью интеграционного тестирования является проверка соответствия проектируемых единиц функциональным, приёмным и требованиям надежности. Тестирование этих проектируемых единиц – объединения, множества или группы модулей – выполняется через их интерфейс, с использованием тестирования «чёрного ящика» [7].
Дата добавления: 2019-03-09; просмотров: 518; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!