РАЗРАБОТКА ПРОГРАММЫ ДЛЯ АРЕНДЫ ТРАНСПОРТНЫХ СРЕДСТВ C#
Описание работы
Работа пользователя Anna123456
Тема дипломной работы — РАЗРАБОТКА ПРОГРАММЫ ДЛЯ АРЕНДЫ ТРАНСПОРТНЫХ СРЕДСТВ НА ЯЗЫКЕ C#. В наличии доклад, презентация, есть готовая программа. Дата защиты июнь 2021 г. Оценка "отлично".
ВВЕДЕНИЕ 5
ГЛАВА 1 ОСНОВНАЯ ЧАСТЬ 6
1.1 Язык программирования 6
1.2 Среда разработки 7
1.3 Методы реализации пользовательского
интерфейса Windows Forms 8
1.4 Система управления базами данных MS Access 9
1.5 Требования к пользовательским интерфейсам ………… 10
1.6 Обзор существующих программных продуктов 16
ГЛАВА 2 СПЕЦИАЛЬНАЯ ЧАСТЬ 16
2.1 Актуальность и цель работы 16
2.2 Описание области применения и исходных данных приложения 17
2.3 Разработка базы данных приложения 18
2.4 Проектирование структуры приложения 23
2.6 Графический интерфейс программы 24
2.7 Описание классов и методов приложения 32
2.8Описание SQL-запросов к базе данных 36
ГЛАВА 3 ЭКОНОМИЧЕСКАЯ ЧАСТЬ 43
ГЛАВА 4 ТЕХНИКА БЕЗОПАСНОСТИ 49
ЗАКЛЮЧЕНИЕ 64
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 65
ПРИЛОЖЕНИЕ А - Программный код приложения 66
2.1 Актуальность и цель работы
На сегодняшний день любая организация нуждается в своевременном доступе к информации. Ценность информации в современном мире очень высока. Базы данных обеспечивают надежное хранение информации, и своевременный доступ к ней. Практически любая современная организация нуждается в базе данных, удовлетворяющей те или иные потребности по хранению, управлению и администрированию данных. Использование баз данных становится неотъемлемой составляющей деловой деятельности современного человека и функционирования организаций. В нашем случае сотруднику проката автомобилей нужно быстро ознакомить клиента с тем, какие автомобили имеются в наличии и тарифами на них.
Актуальность данной работы состоит в существенном упрощение хранения и поиска информации, а также в значительной степени сократит время, затраченное на обработку запросов от клиентов и вероятность возникновения ошибок, которые могут встречаться в самых разных операциях.
Объектом исследования является служба проката автомобилей.
Предметом исследования является деятельность менеджера по прокату автомобилей.
Целью данной дипломной работы является закрепление профессиональных навыков по работе с MS Acces и и разработке графического интерфейса на языке с#.
Изучение организационной структуры проката автомобилей. Создание и ведение локальной базы данных, в том числе просмотр и дополнение базы данных. Создание и ведение справочников сотрудников, клиентов. Создание необходимых запросов.
При автоматизации рабочего места сотруднику больше не придется делать вручную большинство задач, которые до этого отнимали у него много времени. Всю основную работу будет выполнять разработанная система. Сотруднику необходимо будет только ввести информацию о клиентах, выполнить выбор автомобиля для определенного клиента.
Цель работы – разработка приложения, позволяющего вести базу данных клиентов службы аренды авто, арендовать автомобили, формировать списки автомобилей арендованных и доступных для аренды, списки клиентов арендовавших авто и просрочивших аренду. Рассчитывать стоимость аренды в соответствии с выбранным автомобилем.
Актуальность:
-Удобство работы сотрудников сервиса по аренде автомобилей;
-Уменьшаются затраты времени на заполнение документов;
-Удобный способ хранения всех необходимых данных и быстрый доступ к ним;
-Упрощение аренды авто для пользователей использующих сервис не первый раз.
2.2 Описание области применения и исходных данных приложения
Данное приложение предназначено для использования сотрудниками сервиса по аренде автомобилей в целях автоматизации аренды автомобилей, уменьшении затрат времени и удобства клиентов и мониторинга арендованных автомобилей, клиентов у которых в аренде находятся авто.
Процесс работы организации, занимающейся прокатом автомобилей следующий. Покупается автомобиль, марка, модель, цвет и мощность двигателя выбираются по простому критерию - каталог представляемый клиенту автомобилей должен быть всеобъемлющ. Потом они заносятся в базу и дальше в работу вступают - клиенты. Под контролем менеджеров происходит выбор автомобиля, определяются сроки аренды. Если автомобиль подходит к очередному ТО, либо если автомобилю требуется ремонт, то мастер ремонтного цеха снимает автомобиль из списка доступных для заказа, руководит обслуживанием транспортного средства, затем автомобиль восстанавливается в статус доступного к заказу.
Исходными данными для приложения являются:
-Автомобили доступные в аренду;
Приложение должно уметь работать с таблицами базы данных с информацией об автомобилях, клиентах, аренде. В программе должна присутствовать возможность регистрировать новых клиентов, формировать списки автомобилей арендованных и доступных для аренды, списки клиентов арендовавших авто и просрочивших аренду, рассчитывать стоимость аренды в соответствии с выбранным автомобилем.
Должна быть реализована функция добавления клиента, аренды, расчета стоимости аренды, формирование списка просроченной аренда, формирование списка арендаторов, автомобилей доступных для аренды и не доступных. Поиск автомобилей и клиентов.
2.3 Разработка базы данных приложения
Разработка базы данных состоит из концептуального, логического и физического проектирования.
Концептуальное проектирование - это процедура конструирования информационной модели, не зависящей от каких-либо физических условий реализации.
В ходе изучения предметной области выделены следующие сущности, представляющие информационное значение для задачи:
-Автомобили – информация обо всех автомобилях доступных в сервисе;
-Клиенты – информация о клиентах арендующих авто;
Концептуальное представление базы данных приведено на рисунке 2.1.
Рисунок 2.1 – Концептуальная модель базы данных
Логическое проектирование - это процесс конструирования общей информационной модели предприятия на основе отдельных моделей данных пользователей, которая является независимой от особенностей реально используемой СУБД и других физических условий [5, c.78].
Первым этапом логического проектирования
- Преобразование локальной концептуальной модели данных в локальную логическую модель. (Удаление связей, сложных связей, рекурсивных связей, связей с атрибутами, удаление множественных атрибутов.)
- Определение набора отношений исходя из структуры локальной логической модели данных.
-Проверка модели с помощью правил нормализации.
- Проверка модели в отношении транзакций пользователей.
- Создание диаграммы сущность-связь.
- Определение требований поддержки целостности данных. (Обязательные данные, ограничения для доменов атрибутов, целостность сущностей (PK не может быть NULL), требования данного предприятия (бизнес-правила)).
- Обсуждение разработанных локальных логических моделей данных с конечными пользователями.
Второй этап проектирования:
- Слияние локальных моделей в единую глобальную модель данных (анализ имен сущностей и связей ,PK).
- Проверка глобальной логической модели данных (нормализация и транзакции).
- Проверка возможностей расширения модели в будущем.
- Создание окончательного варианта диаграммы сущность-связь
- Обсуждение глобальной модели данных с пользователем.
Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - «клиент», «автомобиль», «аренда». Примеры взаимосвязей между понятиями - «клиент может быть в одном экземпляре», «клиент может арендовать несколько машин».
Логическое представление базы данных приведено на рисунке 2.2.
Рисунок 2.2 – Логическая модель базы данных
Физическое проектирование базы данных - процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах; на этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты.
Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего, необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных. [2]
Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных.
В случае реляционной модели данных под этим подразумевается следующее:
- Создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;
- Определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;
-Разработка средств защиты создаваемой системы.
Приступая к физическому проектированию, прежде всего, необходимо проанализировать и хорошо усвоить информацию об отношениях, собранную на этапе построения логической модели базы данных. Эта информация может содержаться в словаре данных и в определениях отношений, записанных на языке DBDL. Определение каждого выделенного в глобальной логической модели данных отношения включает следующие элементы: - имя отношения;
- Список простых атрибутов, заключенный в круглые скобки.
- Определение первичного ключа и (если таковые существуют) альтернативных (АК) и внешних (FK) ключей.
- Список производных атрибутов и описание способов их вычисления.
-Определение требований ссылочной целостности для любых внешних ключей.
Для каждого атрибута в словаре данных должна присутствовать следующая информация: - определение его домена, включающее указание типа данных, размерность внутреннего представления атрибута и любые требуемые ограничения на допустимые значения;
-Принимаемое по умолчанию значение атрибута (необязательно).
-Допустимость значения NULL для данного атрибута.
Физическое представление таблиц базы данных приведено на рисунках 2.3, 2.4, 2.5.
Рисунок 2.3 – Физическое представление таблицы «AVTOMOBILI»
ВВЕДЕНИЕ 5
ГЛАВА 1 ОСНОВНАЯ ЧАСТЬ 6
1.1 Язык программирования 6
1.2 Среда разработки 7
1.3 Методы реализации пользовательского
интерфейса Windows Forms 8
1.4 Система управления базами данных MS Access 9
1.5 Требования к пользовательским интерфейсам ………… 10
1.6 Обзор существующих программных продуктов 16
ГЛАВА 2 СПЕЦИАЛЬНАЯ ЧАСТЬ 16
2.1 Актуальность и цель работы 16
2.2 Описание области применения и исходных данных приложения 17
2.3 Разработка базы данных приложения 18
2.4 Проектирование структуры приложения 23
2.6 Графический интерфейс программы 24
2.7 Описание классов и методов приложения 32
2.8Описание SQL-запросов к базе данных 36
ГЛАВА 3 ЭКОНОМИЧЕСКАЯ ЧАСТЬ 43
ГЛАВА 4 ТЕХНИКА БЕЗОПАСНОСТИ 49
ЗАКЛЮЧЕНИЕ 64
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 65
ПРИЛОЖЕНИЕ А - Программный код приложения 66
2.1 Актуальность и цель работы
На сегодняшний день любая организация нуждается в своевременном доступе к информации. Ценность информации в современном мире очень высока. Базы данных обеспечивают надежное хранение информации, и своевременный доступ к ней. Практически любая современная организация нуждается в базе данных, удовлетворяющей те или иные потребности по хранению, управлению и администрированию данных. Использование баз данных становится неотъемлемой составляющей деловой деятельности современного человека и функционирования организаций. В нашем случае сотруднику проката автомобилей нужно быстро ознакомить клиента с тем, какие автомобили имеются в наличии и тарифами на них.
Актуальность данной работы состоит в существенном упрощение хранения и поиска информации, а также в значительной степени сократит время, затраченное на обработку запросов от клиентов и вероятность возникновения ошибок, которые могут встречаться в самых разных операциях.
Объектом исследования является служба проката автомобилей.
Предметом исследования является деятельность менеджера по прокату автомобилей.
Целью данной дипломной работы является закрепление профессиональных навыков по работе с MS Acces и и разработке графического интерфейса на языке с#.
Изучение организационной структуры проката автомобилей. Создание и ведение локальной базы данных, в том числе просмотр и дополнение базы данных. Создание и ведение справочников сотрудников, клиентов. Создание необходимых запросов.
При автоматизации рабочего места сотруднику больше не придется делать вручную большинство задач, которые до этого отнимали у него много времени. Всю основную работу будет выполнять разработанная система. Сотруднику необходимо будет только ввести информацию о клиентах, выполнить выбор автомобиля для определенного клиента.
Цель работы – разработка приложения, позволяющего вести базу данных клиентов службы аренды авто, арендовать автомобили, формировать списки автомобилей арендованных и доступных для аренды, списки клиентов арендовавших авто и просрочивших аренду. Рассчитывать стоимость аренды в соответствии с выбранным автомобилем.
Актуальность:
-Удобство работы сотрудников сервиса по аренде автомобилей;
-Уменьшаются затраты времени на заполнение документов;
-Удобный способ хранения всех необходимых данных и быстрый доступ к ним;
-Упрощение аренды авто для пользователей использующих сервис не первый раз.
2.2 Описание области применения и исходных данных приложения
Данное приложение предназначено для использования сотрудниками сервиса по аренде автомобилей в целях автоматизации аренды автомобилей, уменьшении затрат времени и удобства клиентов и мониторинга арендованных автомобилей, клиентов у которых в аренде находятся авто.
Процесс работы организации, занимающейся прокатом автомобилей следующий. Покупается автомобиль, марка, модель, цвет и мощность двигателя выбираются по простому критерию - каталог представляемый клиенту автомобилей должен быть всеобъемлющ. Потом они заносятся в базу и дальше в работу вступают - клиенты. Под контролем менеджеров происходит выбор автомобиля, определяются сроки аренды. Если автомобиль подходит к очередному ТО, либо если автомобилю требуется ремонт, то мастер ремонтного цеха снимает автомобиль из списка доступных для заказа, руководит обслуживанием транспортного средства, затем автомобиль восстанавливается в статус доступного к заказу.
Исходными данными для приложения являются:
-Автомобили доступные в аренду;
Приложение должно уметь работать с таблицами базы данных с информацией об автомобилях, клиентах, аренде. В программе должна присутствовать возможность регистрировать новых клиентов, формировать списки автомобилей арендованных и доступных для аренды, списки клиентов арендовавших авто и просрочивших аренду, рассчитывать стоимость аренды в соответствии с выбранным автомобилем.
Должна быть реализована функция добавления клиента, аренды, расчета стоимости аренды, формирование списка просроченной аренда, формирование списка арендаторов, автомобилей доступных для аренды и не доступных. Поиск автомобилей и клиентов.
2.3 Разработка базы данных приложения
Разработка базы данных состоит из концептуального, логического и физического проектирования.
Концептуальное проектирование - это процедура конструирования информационной модели, не зависящей от каких-либо физических условий реализации.
В ходе изучения предметной области выделены следующие сущности, представляющие информационное значение для задачи:
-Автомобили – информация обо всех автомобилях доступных в сервисе;
-Клиенты – информация о клиентах арендующих авто;
Концептуальное представление базы данных приведено на рисунке 2.1.
Рисунок 2.1 – Концептуальная модель базы данных
Логическое проектирование - это процесс конструирования общей информационной модели предприятия на основе отдельных моделей данных пользователей, которая является независимой от особенностей реально используемой СУБД и других физических условий [5, c.78].
Первым этапом логического проектирования
- Преобразование локальной концептуальной модели данных в локальную логическую модель. (Удаление связей, сложных связей, рекурсивных связей, связей с атрибутами, удаление множественных атрибутов.)
- Определение набора отношений исходя из структуры локальной логической модели данных.
-Проверка модели с помощью правил нормализации.
- Проверка модели в отношении транзакций пользователей.
- Создание диаграммы сущность-связь.
- Определение требований поддержки целостности данных. (Обязательные данные, ограничения для доменов атрибутов, целостность сущностей (PK не может быть NULL), требования данного предприятия (бизнес-правила)).
- Обсуждение разработанных локальных логических моделей данных с конечными пользователями.
Второй этап проектирования:
- Слияние локальных моделей в единую глобальную модель данных (анализ имен сущностей и связей ,PK).
- Проверка глобальной логической модели данных (нормализация и транзакции).
- Проверка возможностей расширения модели в будущем.
- Создание окончательного варианта диаграммы сущность-связь
- Обсуждение глобальной модели данных с пользователем.
Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - «клиент», «автомобиль», «аренда». Примеры взаимосвязей между понятиями - «клиент может быть в одном экземпляре», «клиент может арендовать несколько машин».
Логическое представление базы данных приведено на рисунке 2.2.
Рисунок 2.2 – Логическая модель базы данных
Физическое проектирование базы данных - процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах; на этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты.
Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего, необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных. [2]
Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных.
В случае реляционной модели данных под этим подразумевается следующее:
- Создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;
- Определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;
-Разработка средств защиты создаваемой системы.
Приступая к физическому проектированию, прежде всего, необходимо проанализировать и хорошо усвоить информацию об отношениях, собранную на этапе построения логической модели базы данных. Эта информация может содержаться в словаре данных и в определениях отношений, записанных на языке DBDL. Определение каждого выделенного в глобальной логической модели данных отношения включает следующие элементы: - имя отношения;
- Список простых атрибутов, заключенный в круглые скобки.
- Определение первичного ключа и (если таковые существуют) альтернативных (АК) и внешних (FK) ключей.
- Список производных атрибутов и описание способов их вычисления.
-Определение требований ссылочной целостности для любых внешних ключей.
Для каждого атрибута в словаре данных должна присутствовать следующая информация: - определение его домена, включающее указание типа данных, размерность внутреннего представления атрибута и любые требуемые ограничения на допустимые значения;
-Принимаемое по умолчанию значение атрибута (необязательно).
-Допустимость значения NULL для данного атрибута.
Физическое представление таблиц базы данных приведено на рисунках 2.3, 2.4, 2.5.
Рисунок 2.3 – Физическое представление таблицы «AVTOMOBILI»
