Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Курсач.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
1.84 Mб
Скачать

1. Общий раздел

1.1 Анализ требований и определение спецификаций на программный продукт

Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование.

Целью курсового проекта является разработка модели «Системы заказов и учёта услуг в автосервисе». В соответствии с данной целью необходимо разработать модель приложения, работающее на операционной система Windows, и предоставляющее возможность организовать процесс работы автосервиса.

Разработанное приложение должно удовлетворять следующим функциональным требованиям:

  • Предоставление телефона, адреса и режима работы о автосервисе;

  • Просмотр услуг по обслуживанию тормозов, шин и доп. комплектующих, предоставляемые автосервисом;

  • Возможность записаться на обслуживание автомобиля исходя из предоставленных услуг;

  • Возможность записаться на ремонт автомобиля исходя из предоставленных услуг;

  • Сортировка цен по возрастанию и убыванию;

  • Фильтрация цен в определённом диапазоне;

  • Разделение прав доступа между обычным пользователем и администратором;

Предоставление ведения учёта заказанных услуг клиентов и работ автосервиса с помощью web-страницы;

Разработанное приложение должно удовлетворять следующим нефункциональным требованиям:

  • Минимально возможное время отклика работы системы;

  • Интуитивно-понятный интерфейс.

Система должна выводить результаты выполнения фрагментов кода, реализующих основные функции, в виде отформатированных HTML-страниц или информационных сообщений.

На основе данных функциональных и нефункциональных требований была составлена спецификация на данный программный продукт.

Спецификация требований программного обеспечения — законченное описание поведения программы, которую требуется разработать. Включает ряд пользовательских сценариев (use cases), которые описывают все варианты взаимодействия между пользователями и программным обеспечением. Спецификация также должна содержать нефункциональные требования, которые описывают ограничения на дизайн или реализацию.

2.Специальный раздел

2.1 Проектирование базового алгоритма решения

2.1.1 Анализ процесса обработки информации выбор структуры данных для её хранения.

Данная система построена на архитектуре клиент – сервер. Данная архитектура – это вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами. Фактически клиент и сервер — это программное обеспечение. Обычно эти программы расположены на разных вычислительных машинах и взаимодействуют между собой через вычислительную сеть посредством сетевых протоколов, но они могут быть расположены также и на одной машине.

Базовый алгоритм решения задачи состоит в последовательной реализации системой следующих функций:

  • Просмотр ранее добавленных данных в базу;

  • Добавление данных в систему;

  • Изменение данных в системе;

  • Удаление данных из системы.

  • Ведение учёта услуг и работ в данном автосервисе;

  • Просмотр и заказ услуги, представленные системой.

Основными входными данными системы являются такие данные как (цена услуги для российских авто, цена услуги для зарубежных авто, наименование услуги, а также фамилия, имя отчество, телефон и описание заказа).

Хранение данных осуществляется в реляционной базе данных autoserv состоящей из таблиц: brake, clients, electrician, engine, tire, user.

Рисунок 1 – Структура таблиц базы данных «autoserv»

Таблица brake предназначена для хранения услуг по обслуживанию тормозов и содержит следующие поля:

  • Id_brake(номер услуги)

  • work (наименование работ)

  • priceRUS (цена для отечественных автомобилей)

  • priceEN (цена для зарубежных автомобилей)

Таблица engine предназначена для хранения услуг по обслуживанию двигателя и содержит следующие поля:

  • Id_engine (номер услуги)

  • work (наименование работ)

  • priceRUS (цена для отечественных автомобилей)

  • priceEN (цена для зарубежных автомобилей)

Таблица electrician предназначена для хранения услуг по обслуживанию дополнительного оборудования и содержит следующие поля:

  • Id_ electrician (номер услуги)

  • work (наименование работ)

  • priceRUS (цена для отечественных автомобилей)

  • priceEN (цена для зарубежных автомобилей)

Таблица tire предназначена для хранения услуг по обслуживанию шин и содержит следующие поля:

  • Id_tire(номер услуги) ;

  • work (наименование работ) ;

  • R1314(цена услуги для радиуса шин 13-14) ;

  • R15(цена услуги для радиуса шин 15) ;

  • R16(цена услуги для радиуса шин 16) ;

  • R17(цена услуги для радиуса шин 17) ;

  • R4*4 (цена услуги для радиуса шин 4*4).

Таблица user предназначена для хранения логина и пароля администратора или персонала и содержит следующие поля:

  • Id( порядковый номер)

  • login (логин администратора или персонала)

  • password (пароль администратора или персонала)

Таблица сclients предназначена для хранения клиентов, которые записались на обслуживание в данный автосервис и содержит следующие поля:

  • client_id(номер клиента);

  • name1 (фамилия клиента);

  • name2 (имя клиента);

  • name3 (отчество клиента);

  • telefon( контактный телефон клиента);

  • orders (заказа клиента).

Данная система позволит найти и заказать необходимую услугу, вести учёт всех ранее заказанных услуг, а также позволит проводить различные операции с данными.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]