Автоматизация процесса управления использованием автотранспорта АО 'ХК Сибирский Цемент'

Вид работы:

Дипломная (ВКР)
Предмет:

Информационное обеспечение, программирование
Язык:

Русский
,
Формат файла:
MS Word

58,29 Кб
Опубликовано:

2017-07-09

Все дипломные работы по информационному обеспечению

Скачать дипломную работу Читать текст online Заказать дипломную
*Помощь в написании! Посмотреть все дипломные работы

Вы можете узнать стоимость помощи в написании студенческой работы.

Автоматизация процесса управления использованием автотранспорта АО 'ХК Сибирский Цемент'

Аннотация

Автор дипломной работы: Ястребова Марина Владимировна

Тема работы: «Автоматизация процесса управления использованием автотранспорта АО «ХК Сибирский Цемент».

Специальность: Информационные системы и технологии

Город: г. Кемерово

Описание: Данная работа описывает разработку информационной системы (ИС) по учету использования автотранспортных средств предприятия. Система функционирует на базе СУБД SQL Server. Ограничений по количеству пользователей нет.

Данная система выполняет следующие функции:

- внесение данных в базу данных;

- хранение;

- изменение;

- удаление

- расчет степени изношенности транспортных средств;

- экспорт в Xml;

- импорт из Xml.

Примерное время разработки составило 2 месяца.

Содержание

Аннотация

Содержание

Введение

. Разработка технического задания

1.1 Исходное задание на проектирование

.2 Анализ организационно-технологической структуры предприятия

1.2.1 Краткая характеристика предприятия

.2.2 Вид и профиль деятельности

.2.3 Цели функционирования предприятия

.2.4 Организационная структура предприятия

.2.5 Состав бизнес процессов

.2.6 Исследование функций структуры и деятельности базового подразделения

1.3 Формулировка требований к системе

1.3.1 Выявление бизнес процессов базового подразделения

.3.2 Объекты бизнес процессов

.3.3 Выявление автоматизируемых элементов БП

1.4 Формирование требований

1.4.1 Состав требований

.4.2 Определение состава сценариев, реализующих требования

.4.3 Разработка содержания сценариев

.4.4 Определение требований к пользовательскому интерфейсу

1.5 Формулировка требований к системе

.6 Требование к программному обеспечению

2. Анализ и проектирование

2.1 Классы граничных объектов

.2.Определение методов объектов

3. Разработка системы централизованного хранения и обработки данных

3.1 Формирование требований к БД

.2 Формирование отношений в БД

.3 Выявление связей множеств сущностей и их характеристик

.4 Даталогическое проектирование

.5 Разработка сценариев работы с данными

.6 Разработка механизмов реализации серверной компоненты

4. Специальная часть. Использование технологии Xamarin.Forms для организации заполнения путевых листов

4.1 Выбор технологии

.2 Область применения в разрабатываемой информационной системе

5. Технологии разработки и программная реализация

5.1 Выбор технологии

5.1.1 Выбор операционной системы

.1.2 Выбор взаимодействия пользователя с операционной системой

.1.3 Выбор языка и среды программирования

5.2 Определение физической архитектуры приложения

5.2.1 Определение состава компонент

.2.2 Разработка компонент

.2.3 Уточнение состава экранных форм. Определение конкретных типов управляющих элементов для форм

.2.4 Определение технологии доступа к компоненте данных

5.3 Тестирование

6. Аппаратная и административная интеграция ИС

6.1 Разработка схемы развертывания

6.1.1 Формулировка требований к физическим устройствам и сетевому оборудованию, состав рабочих мест

6.2 Выбор состава аппаратных средств

6.2.1 Расчет потребности персонала

6.3 Разработка среды интеграции

6.3.1 Выбор сетевой архитектуры и технологии

.3.1.1 Выбор архитектуры

.3.1.2 Выбор технологии и аппаратных средств. Расчет сети

7. Общие вопросы администрирования

7.1 Определение стратегии администрирования на уровне руководства и целей предприятия

.2 Определение объектов администрирования

.3 Политика администрирования на уровне предприятия

.4 Политика администрирования на уровне разрабатываемой системы

8. Вопросы информационной безопасности

8.1 Анализ угроз

.2 Информационная безопасность на уровне предприятия

8.2.1 Контроль доступа в помещение организации

.2.2 Обеспечение безопасности с помощью аппаратных средств

.2.3 Определение политики управления доступом пользователей

.2.4 Антивирусная защита информации

.2.5 Безопасность электронной почты

8.3 Информационная безопасность на уровне разрабатываемой ИС

9. Экономическое обоснование разработки системы

9.1 Расчет затрат на проектирование

.2 Расчет эксплуатационных затрат

.3 Экономическая эффективность

.4 Срок окупаемости разработанной системы

.5 Технико-экономические показатели проекта

Заключение

Список литературы

Приложение

Введение

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

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

Процесс «Организация продажи цемента и цемент содержащего сырья» является одним из процессов, необходимых для достижения поставленной цели. Он включает в себя несколько подпроцессов, одним из которых является «Учет поставки груза». Без автоматизации данный подпроцесс требует больших временных затрат, обеспечение необходимой точности расчетов и минимизации ошибок.

Цель выпускной работы - сокращение временных затрат, связанных с формированием путевых листов сотрудниками предприятия и расчетами степени изношенности транспортных средств.

Задачи:

· Разработка технического задания

· Решение вопросов, связанных с анализом и проектированием информационной системы

· Разработка системы централизованного хранения и обработки данных

· Разработка интерфейса и программная реализация.

· Решение вопросов, связанных с интеграцией в информационную систему предприятия

· Решение вопросов администрирования.

· Решение вопросов информационной безопасности.

· Расчет экономической эффективности.

1. Разработка технического задания

.1 Исходное задание на проектирование

Необходимо разработать систему учета использования транспортных средств предприятия АО «ХК Сибирский Цемент».

Техническое задание в полном варианте представлено в приложении 1.

.2 Анализ организационно-технологической структуры предприятия

.2.1 Краткая характеристика предприятия

«Сибирский цемент» является одним из ведущих производителей цемента и цементного сырья. Представляет собой холдинг, включающий в себя цементные заводы России, сервисные предприятия, занимающие реализацией сырья и обслуживанием компаний, входящих в Холдинг. Управление холдингом производит руководящая компания - Холдинговая компания «СибЦемент», располагающаяся в г.Кемерово.

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

Компания была основана в 2002 году. В период с 2002 по 2005 год происходила консолидация активов крупнейших цементных заводов региона.

«Сибирского цемента» имеет прочное положение на рынке. Поставки выпускаемой продукции «Сибирского цемента» производятся не только по Сибири, Центральному и Южному федеральным округам, а также в Чеченскую и Удмуртскую республики, Ямало-Ненецкий Автономный Округ, Монголию, Казахстан и другие направления. Перевозка цемента осуществляется автомобильным и железнодорожным транспортом. «Сибирский цемент» располагает собственной компанией, занимающейся вопросами логистики и грузоперевозок.

.2.2 Вид и профиль деятельности

Открытое акционерное общество «Сибирский цемент» занимается производством и реализацией цемента и цементного сырья, а также строительных материалов на его основе по всей России.

.2.3 Цели функционирования предприятия

Для отображения требуемых значений технологических, технических, производственно-экономических или других показателей бизнес процессов, которые должны быть достигнуты в результате их выполнения, используются модели. Для разработки модели «Цели функционирования предприятия» используется диаграмма классов (class diagram), которая представлена на рис.1.

Рисунок 1. Цели функционирования предприятия

.2.4 Организационная структура предприятия

Управление предприятием производится на базе определенной организационной структуры. Структура предприятия и его подразделений осуществляется самим предприятием. При разработке организационной структуры необходимо обеспечить эффективное распределение функций по подразделениям.

Для разработки модели «Организационная структура» используется пользовательская диаграмма, которая представлена на рис. 2.

Рисунок 2. Организационная структура предприятия

Руководством деятельности Холдинга занимается совет директоров, который избирает президента компании ХК «СибЦемент». ХК состоит из департаментов, каждый из которых отвечает за определенную деятельность:

· Департамент экономики и финансов занимается распределением денежных средств по подразделениям предприятия. Главой департамента является вице-президент по экономике и финансам;

· Департамент развития инвестиционных проектов занимается разработкой инвестиций. Главой департамента инвестиций является вице-президент компании по инвестиционному развитию;

· Департамент информационных технологий занимается организацией работы с информацией, которая движется между подразделениями;

· Департамент маркетинга и управления качеством занимается обеспечением управления качеством предприятия;

· Департамент персонала и организации управления занимается работой с персоналом предприятия;

· Департамент правового обеспечения занимается организацией правовых отношений между сотрудниками предприятия и руководством;

· Департамент по связям с общественностью занимается организацией различных опросов общества и сбором отзывов по работе предприятия с клиентами;

· Стратегический комитет занимается разработкой стратегии предприятия.

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

· Автотракторный цех, который занимается организацией поставки груза клиенту и выполнение различных заказов:

o Директор цеха производит контроль деятельности цеха;

o Диспетчер АТЦ занимается формированием путевых листов и распределением заказов на выполнение;

o Механик АТЦ производит наблюдение за ТС цеха, за из пригодным к работе состоянием;

o Водитель производит выполнение заказов, их непосредственную поставку до клиентов.

· Горный цех занимается производством цемента;

· Бухгалтерия занимается распределением денежных средств и их управлением на предприятии;

· Здравпункт занимается контролем, поддержанием работоспособного состояния работников завода;

· ИТ отдел занимается организацией управления информацией на предприятии;

· Отдел кадров занимается работой с сотрудниками предприятия.

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

· Торговый Дом занимается организацией снабжения предприятий необходимыми ресурсами и оборудованием;

· ЗапСибЦемент занимается организацией продажи цемента и цемент содержащего сырья;

· СибЦемСервис занимается сервисом оборудования и зданий предприятия;

· КузбассТрансЦемент занимается содержанием парка жд состава, используемого для транспортировки груза по городам России.

Кроме того, в подчинение управляющей компании находятся предприятия по производству цемент содержащей продукции:

· Комбинат «Волна» выпускает хризотил цементные кровельные и плоские листы и трубы;

· Сибирский бетон занимается производством товарного бетона и растворов.

.2.5 Состав бизнес процессов

Деятельность и состав бизнес процессов представлены на рис. 3.-5.

Рисунок 3. Контекстная диаграмма деятельности предприятия

Рисунок 4. Состав бизнес процессов предприятия

Рисунок 5. Декомпозиция процесса "Организация продажи цемента и цементного сырья"

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

1.2.6 Исследование функций структуры и деятельности базового подразделения

Автотракторный цех - это структура в организации, которая занимается учетом поставки заказа клиенту и учетом транспортных средств предприятия.

Основным направлением деятельности АТЦ является:

· Ритмичное, бесперебойное обеспечение потребности ОАО автотранспортом, тракторной техникой, грузоподъемными автомобильными кранами.

· Осуществление перевозок людей и грузов транспортными средствами цеха в соответствии с заявками, поданными подразделениями ОАО.

· Осуществление коммерческой деятельности по перевозкам и ремонту автомобильной техники.

Функции работников автотракторного цеха:

. Начальник цеха:

· Осуществление руководства производственно-хозяйственной деятельностью цеха.

· Внедрение передового отечественного и зарубежного опыта

· конструирования и технологии производства аналогичной продукции.

· Координация работы мастеров и цеховых служб.

· Учет, представление установленной отчетности.

· Подбор кадров рабочих и служащих, их расстановка и целесообразное использование.

· Повышение квалификации рабочих и служащих цеха.

· Контроль соблюдения работниками правил и норм охраны труда и техники безопасности.

2. Диспетчер АТЦ:

· Формирование ПЛ в соответствие с поступившими заявками;

· Организация координации деятельности водителей ТС.

3. Водитель:

· Организация безопасной доставки груза заказчику.

. Механик АТЦ:

· Организация бесперебойной работы ТС;

· Технический осмотр ТС;

· Проведение внепланового ремонта ТС.

Всего в цехе работает 11 человек, в их числе: 2 механика, 2 диспетчера, начальник цеха, 5 водителей.

В организации цели, задачи, функции, права и обязанности сотрудников прописаны в должностных инструкциях.

Декомпозиция процесса «Учет поставки груза» представлена на рис. 6.

Рисунок 6. Декомпозиция процесса "Учет поставки груза"

.3 Формулировка требований к системе

.3.1 Выявление бизнес процессов базового подразделения

Для описания был выбран бизнес процесс «Учет поставки груза». Этот процесс был выбран для автоматизации. Декомпозиция процесса «Учет поставки груза» представлена на рис.7.

Рисунок 7. Диаграмма деятельности процесса "Учет поставки груза"

Работы, выполняемые диспетчером АТЦ:

· Определение ТС на выполнение заказа;

· Определение водителя на выполнение заказа;

· Формирование путевого листа на выполнение заказа;

· Заполнение путевого листа начальными данными по транспортному средству;

· Отправка данных по заказам и транспортному средству горному цеху завода;

· Расчет степени износа транспортного средства.

Работы, выполняемые сотрудниками горного цеха:

· Погрузка груза в транспортное средство.

Работы, выполняемые водителем ТС:

· Доставка груза клиенту;

· Отметка времени в путевом листе о выполненном заказе;

· Проверка все ли заказы выполнены;

· Возврат ТС на склад;

· Заполнение данных по поездке в путевой лист.

Описание объектов:

· Список водителей - является входным для Назначения водителя на выполнение заказов;

· Список грузов является входным для формирования путевого листа, отправки данных транспортному цеху информации по грузам, которые необходимо выполнить и погрузки груза в ТС;

· Список транспортных средств является входным для назначения тс на выполнение заказов;

· Выбранное ТС - является выходным из назначения тс на выполнение заказов и входным для заполнения путевого листа, отправки данных по ТС и грузам горному цеху и погрузки груза в ТС;

· Выбранный водитель является выходным из назначения водителя на выполнение заказа и входным в заполнение путевого листа;

· Путевой лист - является выходным из формирования путевого листа и входным в заполнение путевого листа;

· Путевой лист (с начальными данными по ТС, водителю и заказам) является выходным из заполнения путевого листа и входным в отметку времени доставки груза в путевом листе;

· Путевой лист с начальными данными и данными по выполненным заказам является выходным из отметка времени доставки груза в путевом листе и входным в проверку, все ли заказы выполнены, заполнение данных по выполненной поездке в путевой лист;

· ТС является выходным из доставки груза клиенту и входным в возврат транспортного средства на склад;

· Выполненный заказ является выходным из доставки груза клиенту;

· Заполненный путевой лист является выходным из заполнение данных по выполненной поездке в путевой лист и входным в расчет степени износа ТС;

· Результаты изношенности ТС является выходным из расчета износа ТС.

.3.2 Объекты бизнес процессов

Объектами бизнес процессов являются информационные либо материальные объекты, которые связаны с бизнес процессами. Объекты процесса представлены на рисунке 8.

Рисунок 8. Объекты бизнес процессов

Выявленные классы объектов:

. Водитель - представляет водителей предприятия и данные о них:

· ФИО - фамилия, имя и отчество водителя. Тип char.

· Дата рождения - тип char.

· Паспортные данные - серия и номер паспорта водителя. Тип char.

· Категория вождения - определяется тип транспортных средств, которыми может управлять водитель. Тип char.

2. Заказ - представляет заказы, которые необходимо выполнить водителю на соответствующем транспортном средстве.

· Тип заказа - определяет транспортное средство, которое необходимо использовать для выполнения заказа. Тип char.

· Содержание заказа - содержит описание заказа, его суть. Тип char.

· Дата доставки - определяет день месяц и год доставки. Тип char.

· Адрес доставки - определяет место доставки. Тип char.

3. Транспортное средство - определяет транспортные средства предприятия.

· Государственные номер - определяет госномер транспортного средства. Тип char.

· Марка транспортного средства - определяет модель транспортного средства. Тип char.

· Тип транспортного средства - определяет его предназначение. Тип char.

· Степень изношенности транспортного средства - определяет изношенность транспортного средства. Тип double.

.3.3 Выявление автоматизируемых элементов БП

В процессе работы были выявлены следующие элементы бизнес процессов, требующие автоматизации. Состав автоматизируемых элементов бизнес процессов представлен на рисунке 9.

Определение ТС на выполнение заказа. Автоматизация этого процесса позволит быстро определить свободный транспорт предприятия и назначить его на заказ.

Рисунок 9. Диаграмма состава автоматизируемых бизнес процессов

Определение заказов, которые необходимо выполнить. Автоматизация данного процесса позволит быстро определить заказы, которые необходимо выполнить.

Назначение водителя на выполнение заказа. Автоматизация данного процесса позволит обеспечить более быстрый и точный подбор кадров для выполнения заказов.

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

Заполнение путевого листа начальными данными соответствует функции «Заполнение путевого листа». Автоматизация данного процесса позволит быстро заполнить путевой лист данными по водителю, ТС и заказам.

Заполнение путевого листа по результатам выполненной поездки соответствует функции «Заполнение данных по выполненной поездке в путевой лист». Автоматизация данного процесса позволит быстро заполнить путевой лист данными по транспортному средству, показатели которого в ходе процесса изменяются.

Заполнение времени поставки заказа соответствует функции «Отметка времени доставки груза в путевом листе». Автоматизация данного процесса позволит вести учет времени выполнение каждого заказа.

При автоматизации этого бизнес процесса решаются следующие задачи:

•Уменьшение затрат рабочего времени специалиста;

•Ускорение процесса поставки заказа;

•Обеспечение оперативного доступа сотрудника ХК СибЦемент а также водителей о свободных ТС, получение различных отчетностей по проведенным заказам за определенный срок и т.п.

.4 Формирование требований

.4.1 Состав требований

Соответствие функциональных требований автоматизируемым бизнес решениям, а также выявленные подсистемы отобразим в виде матрицы трассировки. Матрица трассировки представлена на рисунке 10.

Выявлены следующие требования:

· Обеспечение возможности регистрации ТС включает в себя ввод данных по новому транспортному средству;

· Обеспечение возможности поиска ТС в зависимости от типа груза включает в себя вывод транспортных средств, которые занимаются выполнением заказов определенного типа;

· Обеспечение возможности регистрации водителя включает в себя ввод данных по новому водителю;

· Обеспечение возможности поиска водителя в зависимости от типа ТС включает в себя вывод водителей, которые имеют категорию вождения выбранного ТС;

· Обеспечение возможности формирования путевого листа в зависимости от типа ТС включает в себя формирование путевого листа с определенными атрибутами;

Рисунок 10. Состав требований

· Обеспечение возможности авто заполнения путевого листа при выборе заказов, ТС и водителя начальными данными включает в себя заполнение путевого листа данными по последней поездке транспортного средства;

· Обеспечение возможности заполнения путевого листа конечными данными по поездки включает в себя ввод данных по ТС по окончании выполнения заказов;

· Обеспечение возможности расчета степени износа ТС включает в себя расчет по результатам заполненного путевого листа степени износа используемого транспортного средства;

· Обеспечение возможности отметки времени по результатам выполнение каждого заказа включает в себя ввод времени, когда заказ был выполнен;

· Обеспечение возможности регистрации заказа включает в себя ввод данных по новому заказу;

· Обеспечение возможности поиска заказов, которые необходимо выполнить, в зависимости от даты включает в себя выбор даты и вывод заказов, выполнение которых назначено на выбранную дату.

.4.2 Определение состава сценариев, реализующих требования

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

Рисунок 11. Диаграмма вариантов использования

Водитель выполняет следующие функции:

· Заполнение путевого листа, включает в себя заполнение данных по ходу выполнения заказов, а именно время выполнения заказа, а также данные по ТС после выполнения всех заказов;

Диспетчер АТЦ выполняет следующие функции:

· Занимается вводом данных по новым транспортным средствам, заказам и водителям в систему;

· Производит формирование путевого листа, которое включает в себя поиск и назначение водителя на заказ, определение списка заказов, которые необходимо выполнить, поиск и назначение транспортного средства на выполнение заказа;

· Заполняет начальные данные путевого листа, а именно данные по водителю, ТС и заказам;

· По результатам выполненных заказов производит расчет степени изношенности транспортного средства.

.4.3 Разработка содержания сценариев

Содержимое сценариев представлено в виде декомпозиции соответствующих им «вариантов использования».

. Работа с заказами

Диаграмма деятельности сценария «Работа с заказами» приведена на рисунке 12.

В результате работы процесса выявлены следующие объекты:

Граничные объекты:

· Форма программы - содержит форму «Работа с заказами». Позволяет создавать, изменять, удалять заказы.

Сущности:

· Список заказов - содержит заказы с данными о них.

· Выбранный заказ - содержит данные о заказе (наименование, тип, дата формирования заказа, дата доставки, адрес доставки).

Рисунок 12. Диаграмма деятельности сценария "Работа с заказами"

Подсценарии «Добавить заказ», «Изменить заказ», «Удалить заказ» представлены соответственно на рисунках 13, 14, 15.

Рисунок 13. Диаграмма деятельности для сценария "Добавить заказ"

Рисунок 14. Диаграмма деятельности для сценария "Изменить заказ"

Рисунок 15. Диаграмма деятельности для сценария "Удалить заказ"

· Документ Xml с данными о заказах - содержит данные о заказах с структурированном виде (наименование, тип, дата формирования заказа, дата доставки, адрес доставки).

Все сценарии выполняются Диспетчером АТЦ:

· Открывается Форма для работы с заказами, на нее загружаются данные по всем заказам предприятия;

· Выбирается действие:

o Изменение заказа;

§ Выбирается заказ для изменения информации о нем; открывается доступность полей для ввода информации по заказам.

o Создание заказа:

§ Открывается доступность полей для ввода информации по заказу, диспетчер вводит данные по заказам в соответствующие поля;

§ Диспетчер выбирает документ, с которого необходимо произвести загрузку данных в таблицу.

o Удаление заказа;

§ Выбирается заказ для удаления, подтверждается удаление заказа.

· Сохраняются всевозможные изменения в системе.

· Подтверждается закрытие формы.

. Работа с ТС

Диаграмма деятельности сценария «Работа с ТС» приведена на рис. 16.

Рисунок 16. Диаграмма деятельности для процесса "Работа с ТС"

Подсценарии «Добавить ТС», «Изменить ТС», «Удалить ТС» представлены соответственно на рисунках 17, 18, 19.

Рисунок 17. Диаграмма деятельности для сценария "Добавить ТС"

Рисунок 18. Диаграмма деятельности сценария "Изменение данных по ТС"

В результате работы процесса выявлены следующие объекты:

Граничные объекты:

· Форма программы - содержит форму «Работа с ТС». Позволяет создавать, изменять, удалять транспортные средства.

Рисунок 19. Диаграмма деятельности сценария "Удаление ТС"

Сущности:

· Список ТС - содержит ТС с данными о них.

· Выбранное ТС - содержит данные о ТС (Госномер, марка, тип ТС, Тип Шин, Количество бензина, Количество пройденных км).

Все сценарии выполняются Диспетчером АТЦ:

· Открывается Форма для работы с ТС, на нее загружаются данные по всем ТС предприятия;

· Выбирается действие:

o Изменение ТС:

§ Выбирается ТС для изменения информации о нем; открывается доступность полей для ввода информации по ТС.

o Создание ТС:

§ Открывается доступность полей для ввода информации по ТС, диспетчер вводит данные по ТС в соответствующие поля;

o Удаление ТС:

§ Выбирается ТС для удаление, подтверждается удаление ТС.

· Сохраняются всевозможные изменения в системе.

· Подтверждается закрытие формы.

. Работа с водителями

Диаграмма деятельности сценария «Работа с водителями» приведена на рисунке 20.

Рисунок 20. Диаграмма деятельности сценария "Работа с водителями"

Сценарии «Добавление ТС», «Изменение ТС» и «Удаление ТС» представлены на рисунках соответственно 21, 22, 23.

Рисунок 21. Диаграмма деятельности сценария "Добавление водителя"

Рисунок 22. Диаграмма деятельности для сценария "Изменение данных водителя"

Рисунок 23. Диаграмма деятельности сценария "Удаление водителя"

В результате работы процесса выявлены следующие объекты:

Граничные объекты:

· Форма программы - содержит форму «Работа с водителями». Позволяет добавлять новых и удалять водителей, а также изменять данные по выбранному водителю.

Сущности:

· Список Водителей - содержит водителей с данными о них.

· Выбранный водитель - содержит данные о водителе (ФИО, дата рождения, номер телефона, паспортный данные, категория вождения).

Все сценарии выполняются Диспетчером АТЦ:

· Открывается Форма для работы с водителями;

· Диспетчер в зависимости от того, что он хочет сделать, производит разную работу:

o Изменение данных по водителю;

o Добавление нового водителя;

§ Открывается доступность полей для ввода информации по водителю, диспетчер вводит данные по водителю в соответствующие поля;

o Удаление водителя;

§ Выбирается водителя для удаление, подтверждается удаление водителя.

· Сохраняются изменения в системе.

· Подтверждается закрытие формы.

4. Формирование путевого листа

Диаграмма деятельности сценария «Формирование путевого листа» приведена на рисунке 24.

В результате работы процесса выявлены следующие объекты:

Граничные объекты:

· Форма программы - содержит форму «Формирование путевого листа». Позволяет создавать путевые листы, которые используются водителями при выполнении заказов.

Рисунок 24. Диаграмма деятельности "Формирование путевого листа"

Сущности:

· Список ТС - содержит ТС с данными о них.

· Список водителей - содержит водителей с данными о них.

· Выбранный водитель - содержит данные о водителе (ФИО, дата рождения, номер телефона, категория вождения ТС).

· Список заказов - содержит заказы и данные о них.

· Выбранные заказы- содержит список заказов, которые необходимо выполнить по данному путевому листу и данные о них (Тип заказа, вес, Дата формирования заказа, номер договора, Дата поставки).

· Сформированный путевой лист - содержит путевой лист и данные по нему (список заказов, водителя, назначенного на заказ, транспортное средство, дата формирования путевого листа).

Все сценарии выполняются Диспетчером АТЦ:

· Открывается Форма для формирования путевых листов;

· Диспетчер выбирает список заказов на выполнение, исходя из этого списка выбираются ТС и водитель;

· Диспетчер вводит дополнительные данные о путевому листу, характерные для каждого путевого листа, такие как дата;

· Диспетчер нажимает кнопку формирования путевого листа;

· Сохраняется путевой лист в системе.

· Подтверждается закрытие формы.

.4.4 Определение требований к пользовательскому интерфейсу

Требования к пользовательскому интерфейсу включают:

· тип используемых управляющих элементов;

· состав экранных форм;

· состав управляющих элементов на экранных формах.

Состав экранных форм определяется на основе граничных объектов, выявленных в сценариях выполнения функций системы. Каждый граничный объект может соответствовать или форме, или закладке на форме. Для представления функций пользователям, был реализован пользовательский интерфейс. Были созданы формы: «Авторизация», «Выбор действия», «Работа с транспортными средствами», «Работа с заказами», «Работа с водителями», «Формирование путевого листа», «Работа с путевыми листами», «Заполнение путевого листа».

Рисунок 25. Пользовательский интерфейс системы

Требования к интерфейсу:

· Возможность добавления, изменения, удаления ТС;

· Возможность добавления, изменения, удаления водителей;

· Возможность добавления, изменения, удаления заказов;

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

· Возможность назначения водителя, добавления заказов и назначения транспортного средства на выполнение заказов;

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

· Возможность автоматического расчета степени износа транспортного средства.

1.5 Формулировка требований к системе

Работа АТЦ, а, следовательно, и выполнение выбранного для автоматизации БП, заключается в следующем: составление путевых листов, ведение множества журналов по учету ТС и их эксплуатации, назначение водителя и ТС на заказ и соответственно доставка груза до заказчика, расчет степени изношенности ТС по результатам выполнения заказа. Ведение множества журналов, а также, составление путевых листов вручную занимает очень много времени. Расчет результатов степени износа ТС производится вручную диспетчером АТЦ, что может привести к допущению им множества ошибок. При этом управляющая компания может получить доступ к работе АТЦ только по приезду и проведению различного рода проверок, в ходе которых изучается множество журналов, которые ведет АТЦ.

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

Автоматизация бизнес процессов приносит следующие преимущества:

· сокращение времени на формирование путевых листов, а также выполнение заказа;

· уменьшение трудозатрат;

· минимизация вероятности возникновения ошибок, связанных с анализом данных в процессе исполнения задач;

· разграничение функций пользователей системы;

· удобство просмотра деятельности цеха.

Анализ необходимых преобразований ресурсов:

1. Материального обеспечения:

Преобразование материального обеспечения требуется для установки сервера с БД и подключения ПК и планшетов для функционирования системы.

2. Организационного обеспечения:

Система довольно проста в использовании. Необходимо обучение персонала, которое займет некоторое время.

. Временное обеспечение:

Временные затраты на поиск информации и формирование путевых листов и т.д. значительно сокращаются. Большая часть бумажного документооборота заменяется электронным, вследствие чего также происходит сокращение временных затрат.

. Финансовое обеспечение:

Преобразование финансового обеспечения не требуется.

Использование автоматизированной системы влечет привлечения дополнительных ресурсов, таких как внедрение сервера с БД. При внедрении системы требуется дополнительное время на перенос данных с бумажных носителей в базу данных.

Функциональные требования к системе:

Система должна обеспечивать:

· Функцию хранения информации о ТС, водителях, заказах и сформированных ПЛ;

· Возможность внесения новых водителей, заказов и ПЛ, модификацию данных по ним и их удаление.

· Функцию поиска заказов, выполненных определенным ТС, поиска ТС, водителем которых был определенный человек.

· Функцию расчета результатов степени изношенности ТС.

Нефункциональные требования к системе:

Система должна обеспечивать:

· целостность информации;

· безопасность (аутентификация пользователей средствами ОС и разделение прав доступа к информации в БД);

· быстродействие системы;

· запас объёма на хранение информации в БД.

Требования к надёжности:

Уровень надежности должен достигаться согласованным применением организационных, организационно- технических мероприятий и программно-аппаратных средств.

Надежность должна обеспечиваться за счет:

• Применение технических средств, системного и базового программного обеспечения

• Соблюдение правил эксплуатации и технического обслуживания.

• Предварительного обучения пользователей.

Требования к безопасности

• Защита системы должна обеспечиваться комплексом программно- технологических средств и поддерживающих их организационных мер;

• Защита системы должна обеспечиваться на всех технологических этапах обработки информации и во всех режимах функционирования, в том числе при проведении ремонтных работ;

• Программно- технические средства не должны существенно ухудшить основные функциональные характеристики системы (надежность, быстродействие, возможность изменения конфигурации).

.6 Требование к программному обеспечению

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

Программное обеспечение должно обладать свойствами:

• Надежности;

• Модифицируемости;

• Масштабируемости;

• Удобства эксплуатации.

2. Анализ и проектирование

.1 Классы граничных объектов

Диаграмма классов представлена на рисунке 26.

Рисунок 26. Диаграмма классов анализа

В ходе анализа были выявлены следующие классы:

. Классы граничных объектов:

Класс «Форма Авторизация» - определен на основе объекта «Форма программы» для авторизации пользователя и разграничения его прав. Методы:

· Вход в систему - определяется соответствие данных, введенных в поля формы Логин и Пароль, в зависимости от правильности введенных данных и типа пользователя открывает разные формы.

Класс «Форма Выбор действия» определен на основе объекта «Форма программы» для выбора дальнейших действий диспетчера АТЦ. Методы:

· Открытие Формы Формирование путевого листа позволяется открыть форму «Форма Формирование путевого листа».

· Открытие Формы «Форма Работа с Водителями» позволяет открыть форму «Форма работы с водителями».

· Открытие Формы «Форма Работа с заказами» позволяет открыть форму «Форма работы с заказами».

· Открытие формы «Форма работы с ТС» позволяется открыть форму для работы с транспортными средствами

Класс «Форма Работа с водителями» позволяется смотреть данные по имеющимся водителям предприятия, организовывать работу с ними. Методы

· Добавление - реализован на основе сценария «Работа с Водителями». В результате метода в систему добавляется новый водитель.

· Изменение данных водителя - реализован на основе сценария «Работа с водителями». В ходе метода изменяются данные по уже существующему водителю.

· Удаление данных водителя - реализуется на основе сценария «Работа с родителями». В результате метода водитель из системы и его данные удаляются.

Класс «Форма: Работа с транспортными средствами» определен на основе объекта «Форма программы», позволяет осуществлять просмотр данным по имеющемуся транспорту предприятия, а также, производить модификацию данных. Методы:

· Добавление - определен на основе сценария «Работа с транспортными средствами». В результате вызова метода в систему добавляются данные по новому транспортному средству.

· Изменение - определен на основе сценария «Работа с транспортными средствами». В результате вызова метода изменяются данные в системе по уже внесенному транспортному средству.

· Удаление - определен на основе сценария «Работа с транспортными средствами». В результате вызова метода удаляются данные по транспортному средству.

Класс «Форма Работа с заказами» позволяется смотреть данные по имеющимся заказам предприятия, организовывать работу с ними. Методы

· Добавление - реализован на основе сценария «Работа с заказами». В результате метода в систему добавляется новый заказ.

· Изменение данных заказа- реализован на основе сценария «Работа с заказами». В ходе метода изменяются данные по уже существующему заказу.

· Удаление данных заказа - реализуется на основе сценария «Работа с заказами». В результате метода заказ из системы и его данные удаляются.

Класс «Форма Работа с ПЛ» определен на основе объекта «Форма программы», позволяет осуществлять просмотр сформированных путевых листов и удаления путевых листов. Методы:

· Удаление, результатом вызова метода является удаление данных по путевому листу.

· Открытие формы Формирование путевого листа, в результате которого происходит запуск формы.

Класс «Форма Формирование путевого листа» определен на основе объекта «Форма программы», позволяет осуществлять добавление новых путевых листов. Методы:

· Поиск заказов определенной даты - позволяет формировать путевые листы с заказами одного дня.

· Поиск ТС - позволяет осуществлять поиск транспортного средства для выполнения заказов в зависимости от типа заказа.

· Поиск водителя - позволяет осуществлять поиск водителя определенной категории в зависимости от выбранного транспортного средства.

· Формирование путевого листа позволяет добавить в систему новый путевой лист и отправить его на выполнение.

Класс «Форма заполнение путевого листа» определен на основе объекта «Форма программы». Позволяет вносить данные по ходу и результатам выполнения заказов. Методы:

· Добавление дополнительных особенностей - позволяет добавить заполненные данные к начальным данным по путевому листу и заказам.

· Расчет степени износа транспортного средства - позволяет рассчитать степень износа транспортного средства и определить срок до конца момента эксплуатации и необходимости проведения ремонтов.

Классы сущностей:

Класс «Пользователь» отображает возможных пользователей системы. Атрибуты:

· Логин - тип char, представляет логин пользователя.

· Пароль - тип char, представляет пароль пользователя.

Класс «Транспортное средство» отображает имеющиеся транспортные средства на предприятие. Атрибуты:

· ID - идентификатор транспортного средства, тип int.

· ГосНомер - государственный номер транспортного средства, тип char.

· Тип ТС задает предназначение транспортного средства. Тип задается элементом перечисления ТипТС.

· Количество бензина показывает уровень топливного бака транспортного средства. Тип double.

· Пройденный путь показывает количество км, которое

проехал транспорт. Тип double.

· Степень изношенности транспортного средства показывает уровень изношенности шин и транспортного средства. Тип double.

Методы:

· Создать ТС, тип возврата void - создается ТС.

· Изменить ТС, тип возврата void - изменяется ТС.

· Удалить ТС, тип возврата void - удаляется ТС.

Класс «Заказ» отображает имеющиеся заказы на предприятии. Атрибуты:

· ID - идентификатор заказа, тип int.

· Тип заказа задает тип транспортного средства, которое необходимо использовать для доставки заказа клиенту. Тип задается элементом перечисления ТипЗаказа.

· Содержание заказа описывает сам заказ. Тип char.

· Дата доставки определяет день, месяц и год доставки заказа. Тип char.

· Адрес доставки определяет место доставки заказа. Тип char.

Методы:

· Создать, заказ тип возврата void - создается заказ.

· Изменить заказ, тип возврата void - изменяется заказ.

· Удалить заказ, тип возврата void - удаляется заказ.

Класс «Водитель» представляет водителей предприятия. Атрибуты:

· ID - идентификационный номер. Тип int.

· ФИО - фамилия, имя и отчество водителя. Тип char.

· Дата рождения, тип char.

· Номер телефона, тип char.

· Паспортные данные - серия и номер паспорта водителя. Тип char.

· Категория вождения определяет список транспортных средств, которыми может управлять водитель. Задается элементами перечисления КатегорияВождения.

Методы:

· Создать водителя, тип возврата boolean - создается водитель.

· Изменить водителя, тип возврата boolean - изменяется водитель.

· Удалить водителя, тип возврата boolean - удаляется водитель.

Класс «Путевой лист» определяет заказы, которые необходимо выполнить на определенном транспорте определенному водителю, а также изменения по транспортному средству, которые происходили за время выполнения заказов и данные по заказам. Атрибуты:

· ID - идентификационный номер, тип int.

· Заказы - определяет список заказов, которые необходимо выполнить по ПЛ. Тип Заказ.

· ТС - определяет ТС на выполнение заказов. Тип Транспортное средство.

· Водитель - определяет водителя, который будет выполнять заказы. Тип Водитель.

· Дополнительные особенности определяют сервис для транспортного средства. Тип Дополнительные особенности.

· Дата формирования - тип char.

· Количество потраченного бензина, Тип double.

· Пройденный путь - количество км, потраченных на выполнение заказов.

· Время возврата ТС на склад - тип char.

Методы:

· Добавление дополнительной особенности;

· Добавление путевого листа - формирует путевой лист с начальными данными.

Методы были выявлены на основе формирования сценариев, рассмотренных в пункте 2.2.

2.2 Определение методов объектов

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

Диаграмма последовательности сценария «Работа с водителями» приведена на рисунке 27.

Рисунок 27. Диаграмма последовательности сценария "Работа с водителями"

Выявленные методы:

· Открытие приложения() реализует открытие формы авторизация;

· Авторизация() вызывает метод Открытие формы();

· Открытие формы() реализует открытие формы в зависимости от места вызова;

· Запрос на открытие формы работа с водителями() вызывает метод Открытие формы();

· Загрузка данных на форму() реализует вывод информации о водителях из БД в таблицу на форме;

· Выбор водителя для изменения/удаления данных() вызывает метод Заполнение полей данными по водителю();

· Заполнение полей данными по водителю() реализует заполнение полей формы данными по выбранному водителю;

· Ввод новых данных по водителю() включает в себя заполнение полей на форме;

· Запрос на изменение данных() вызывает метод Изменение данных по водителю();

· Изменение данных по водителю() включается в себя изменение данных по выбранному водителю;

· Сохранение изменений в системе() реализует сохранение введённых диспетчером АТЦ данных в БД;

· Запрос на добавление нового водителя() вызывает метод Добавление нового водителя();

· Добавление нового водителя() реализует создание экземпляра класса водитель и добавление его в список;

· Запрос на удаление водителя вызывает метод Удаление водителя():

· Удаление водителя включает в себя удаление экземпляра класса водителя с выбранными параметрами;

· Закрытие формы() реализует закрытие той формы, на которой метод вызван;

· Закрытие приложения() реализует выход из системы.

Все методы сценария «Работа с водителями» выполняются Диспетчером АТЦ.

Диаграмма последовательности сценария «Работа с ТС» приведена на рисунке 28.

Рисунок 28. Диаграмма последовательности сценария "Работа с ТС"

Выявленные методы:

· Запрос на изменение данных() вызывает метод Изменение данных по ТС();

· Изменение() включается в себя изменение данных по выбранному ТС;

· Сохранение() реализует сохранение введённых диспетчером АТЦ данных в БД;

· Запрос на добавление нового ТС() вызывает метод Добавление();

· Добавление() реализует создание экземпляра класса ТС и добавление его в список;

· Запрос на удаление ТС вызывает метод Удаление():

· Удаление ТС включает в себя удаление экземпляра класса ТС с выбранными параметрами;

· Закрытие формы() реализует закрытие той формы, на которой метод вызван;

· Закрытие приложения() реализует выход из системы.

Все методы сценария «Работа с ТС» выполняются Диспетчером АТЦ.

Диаграмма последовательности сценария «Работа с заказами» приведена на рисунке 29.

· Открытие приложения() реализует открытие формы авторизация;

· Авторизация() вызывает метод Открытие формы();

· Открытие формы() реализует открытие формы в зависимости от места вызова;

· Запрос на открытие формы работа с ТС() вызывает метод Открытие формы();

· Загрузка данных() реализует вывод информации о ТС из БД в таблицу на форме;

· Выбор ТС для изменения/удаления данных() вызывает метод Загрузка данных в поля формы();

· Загрузка данных в поля формы() реализует заполнение полей формы данными по выбранному водителю;

· Ввод новых данных по ТС() включает в себя заполнение полей на форме;

Рисунок 29. Диаграмма последовательности сценария «Работа с заказами»

Выявленные методы:

· Открытие приложения() реализует открытие формы авторизация;

· Авторизация() вызывает метод Открытие формы();

· Открытие формы() реализует открытие формы в зависимости от места вызова;

· Запрос на открытие формы работа с заказами() вызывает метод Открытие формы();

· Загрузка данных() реализует вывод информации о заказах из БД в таблицу на форме;

· Выбор заказа для изменения/удаления данных() вызывает метод Загрузка данных в поля формы();

· Загрузка данных в поля формы() реализует заполнение полей формы данными по выбранному заказу;

· Ввод новых данных по заказу() включает в себя заполнение полей на форме;

· Запрос на изменение данных() вызывает метод Изменение данных по заказау();

· Изменение() включается в себя изменение данных по выбранному Заказу;

· Сохранение() реализует сохранение введённых диспетчером АТЦ данных в БД;

· Запрос на добавление нового заказа () вызывает метод Добавление();

· Добавление() реализует создание экземпляра класса заказ и добавление его в список;

· Запрос на удаление заказа вызывает метод Удаление():

· Удаление заказа включает в себя удаление экземпляра класса заказ с выбранными параметрами;

· Закрытие формы() реализует закрытие той формы, на которой метод вызван;

· Закрытие приложения() реализует выход из системы.

Все методы сценария «Работа с заказами» выполняются Диспетчером АТЦ.

Диаграмма последовательности сценария «Формирование путевого листа» приведена на рисунке 30.

Рисунок 30. Диаграмма последовательности для сценария "Формирование путевого листа"

Выявленные методы:

· Открытие приложения() реализует открытие формы авторизация;

· Авторизация() вызывает метод Открытие формы();

· Открытие формы() реализует открытие формы в зависимости от места вызова;

· Запрос на открытие формы работа с путевыми листами() вызывает метод Открытие формы();

· Загрузка данных() реализует вывод информации о путевых из БД в таблицу на форме;

· Выбор даты выполнения заказов() вызывает метод Поиск заказов определенной даты();

· Выбор заказов() вызывает метод Поиск транспортных средств в зависимости от типа заказа();

· Выбор ТС() вызывает метод Поиск водителя определенной категории() в зависимости от типа ТС;

· Выбор водителя() реализует назначение определенного водителя на выполнение заказов;

· Запрос на формирование путевого листа() вызывает метод Формирование ПЛ();

· Сохранение() реализует сохранение введённых диспетчером АТЦ данных в БД;

· Закрытие формы() реализует закрытие той формы, на которой метод вызван;

· Закрытие приложения() реализует выход из системы.

Все методы сценария «Формирование путевого листа» выполняются Диспетчером АТЦ.

3. Разработка системы централизованного хранения и обработки данных

.1 Формирование требований к БД

На основании исходного задания СУБД должна быть построена по технологии клиент-сервер. База данных должна хранить информацию о пользователях системы, водителях, транспортных средствах, заказах, путевых листах, иметь возможность добавлять, редактировать, удалять эту информацию. База данных должна быть универсальной, т.е. оставаться работоспособной на любой машине и подстраиваться под видоизменение пользовательского интерфейса, быть способной к реорганизации и расширения при изменении предметной области.

.2 Формирование отношений в БД

На основании классов проектирования выявлены отношения, которые необходимы для хранения данных: Пользователи, Водители, Транспортные средства, Заказы, Путевые листы. Их атрибуты и описания в таблице 1

Таблица 1. Выявленные отношения, их атрибуты и описание

Отношение	Атрибуты	Описание
Drivers(водители) выявлено на основе класса Водитель	FIO(Фамилия, имя, отчество, тип string), BirthDay(дата рождения, тип datetime), Passport (данные паспорта: серия и номер, тип string), Phone (Номер телефона, тип string), Kategory(категория вождения, тип string)	Содержит информацию о водителях предприятия
Zaks (Заказы) выявлено на основе класса Заказ	TypeOfZak(тип заказа, тип string), Soderzh(описание заказа, тип string), DateDost(дата доставки заказа, тип datetime), AdressDos(адрес доставки, тип string)	Содержит информацию о заказах предприятия
Transports (Транспортные средства) выявлено на основе класса Транспортное средство	TypeOfTran(тип транспортного средства, тип string), GosNum(государственный номер транспортного средства, тип string), TypeOfShin(тип шин, тип string), Put(пройденный путь, тип double), Benz(потраченное количество бензина , тип double), Isnos(степень изношенности транспортного средства, тип double)	Содержит информацию по транспортным средствам предприятия
PutLists (Путевые листы) выявлено на основе класса Путевой лист	Zakasy (список заказов на выполнение, тип List <Zaks>), Trans(транспортное средство, тип Transports), Voditel (водитель, тип Drivers), DataForm(дата формирования путевого листа, тип datetime), ProidPut(пройденный путь, тип double), TimeVosvr(время возврата ТС на склад, тип datetime), bens(количество бензина в баке, тип double)	Содержит информацию о путевых листах предприятия

.3 Выявление связей множеств сущностей и их характеристик

В процессе проектирования были выявлены следующие связи отношений:

«PutLists» и «Zaks» имеют связь один ко многим, так как идентификатор каждого id в отношении «PutLists» может иметь несколько значений атрибута в отношении «Zaks».

Рисунок 31. Отношение "PutLists-Zaks"

«Transports» и «PutLists» имеют связь один ко многим, так как один транспорт может работать по многим путевым листам.

«Drivers» и «PutLists» имеют связь один ко многим, так как один водитель может работать по многим путевым листам.

«PutLists» и «DopOs» имеют связь один ко многим, так как один путевой лист может содержать множество особенностей сервиса.

Рисунок 32. Отношение "PutLists-Transports"

Рисунок 33. Отношение "PutLists - Drivers"

Рисунок 34. Отношение "DopOs - PutLists"

Рисунок 35 Результирующая ER-диаграмма, отображающая сущности и их святи

.4 Даталогическое проектирование

) Сущность «Водители» представлена таблицей Drivers.

Рисунок 36. Таблица "Drivers"

- числовой тип int, является ключевым атрибутом. Введен для идентификации водителя, а также для связи с путевыми листами.- символьный тип nvarchar(max), содержит фамилию, имя и отчество водителя.- тип datetime, содержит дату рождения водителя.- символьный тип nvarchar(max), содержит паспортные данные водителя.- символьный тип nvarchar(max), содержит номер телефона водителя.- символьный тип nvarchar(max), содержит категории вождения водителя.

) Сущность «Транспортные средства» представлена таблицей Transports.

Рисунок 37. Таблица "Transports"

- числовой тип int, является ключевым атрибутом. Введен для идентификации транспортного средства, а также для связи с путевыми листами.- символьный тип nvarchar(max), содержит государственный номер транспортного средства.- символьный тип nvarchar(max), содержит тип транспортного средства.- символьный тип nvarchar(max), содержит тип используемых шин на транспортном средстве.- числовой тип float, содержит количество пройденных км транспортным средством.- числовой тип float, содержит количество потраченного бензина в транспортном средстве, в литрах.- числовой тип float, содержит степень износа транспортного средства.

) Сущность «Заказы» представлена таблицей Zaks.

Рисунок 38. Таблица "Zaks"

- числовой тип int, является ключевым атрибутом. Введен для идентификации заказа.- символьный тип nvarchar(max), содержит формулировку заказа.- символьный тип nvarchar(max), содержит тип заказа.- символьный тип nvarchar(max), содержит адрес доставки груза.- числовой тип float, содержит вес груза.- тип datetime, содержит дату формирования заказа.- тип datetime, содержит дату доставки груза.

) Сущность «Дополнительные особенности путевого листа» представлена таблицей DopOs.

Рисунок 39. Таблица "DopOs"

Id - числовой тип int, является ключевым атрибутом. Введен для идентификации сервиса.- символьный тип nvarchar(max), содержит тип используемого сервиса.- символьный тип nvarchar(max), содержит значение используемого сервиса.

) Сущность «Путевые листы» представлена таблицей PutLists.

Рисунок 40. Таблица "PutLists"

- числовой тип int, является ключевым атрибутом. Введен для идентификации путевого листа, а также для связи с сервисом, заказами.- тип datetime, содержит дату формирования путевого листа.- числовой тип float, содержит количество пройденных км транспортным средством.- числовой тип float, содержит количество потраченного бензина в транспортном средстве, в литрах.

.5 Разработка сценариев работы с данными

Добавление данных:

Добавление ТС. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.17). При добавлении нового ТС в таблицу Transport, необходимо вводить его ГосНомер- Gosnum, Тип транспорта - Type, Тип шин - TypeSh, Объем топливного бака - EmkostBak, показатель одометра - Put, уровень бензина в топливном баке - BenValue. Код ТС - Id, генерировать автоматически (к последнему идентификатору прибавляется единица). При подтверждении ввода данных, в таблице Transport создается новая запись. Обработку необходимо реализовать через хранимую процедуру.

Добавление водителя. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.21). При добавлении нового водителя в таблицу Driver, необходимо вводить его ФИО- FIO, Дата рождения - Birthday, Паспортные данные - Passport, Номер телефона - Phone, категория вождения - Kateg. Код водителя - Id, генерируется автоматически (к последнему идентификатору прибавляется единица). При подтверждении ввода данных, в таблице Driver создается новая запись. Обработку необходимо реализовать через хранимую процедуру.

Добавление заказа. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.13.). При добавлении нового заказа в таблицу Zakaz, выбирается документ xml для выгрузки данных. В документе хранятся по заказам, а именно его Наименование- Name, Дата формирвоания - date, Тип заказа - Type, параметры груза(вес, количество людей) - Param, Адрес доставки - Adress. Код заказа - Id, генерируется автоматически (к последнему идентификатору прибавляется единица). При подтверждении ввода данных, в таблице Zakas создается новая запись. Обработку необходимо реализовать через хранимую процедуру.

Формирование путевого листа. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.24.). При добавлении нового путевого листа в таблицу PutList, выбирается водитель, заказы и ТС. Вводится дата формирования путевого листа. Код путевого листа - Id, генерируется автоматически (к последнему идентификатору прибавляется единица). При подтверждении формирования путевого листа, в таблице PutList создается новая запись, содержащая идентификатор, дату формирования путевого листа, идентификатор транспортного средства и идентификатор водителя. Обработку необходимо реализовать через хранимую процедуру.

Добавление сервиса. При добавлении сервиса необходимо указать его наименование - Name, значение - Znach. Код сервиса - Id, генерируется автоматически (к последнему идентификатору прибавляется единица). При подтверждении добавления сервиса в таблице DopOs появляется запись с данными по сервису и путевому листу, при заполнении которого был добавлен сервис. Обработку необходимо реализовать с помощью хранимых процедур.

Изменение данных:

Изменение данных ТС. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.18). При изменении данных выбирается ТС из таблицы на форме, ТС вводится его ГосНомер- Gosnum, Тип транспорта - Type, Тип шин - TypeSh, Объем топливного бака - EmkostBak, показатель одометра - Put, уровень бензина в топливном баке - BenValue. Код ТС - Id, генерируемый автоматически, не изменяется. При подтверждении изменения данных, в таблице Transport изменяются данные по ТС. Обработку необходимо реализовать через хранимую процедуру.

Изменение данных водителя. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.22). При изменении данных необходимо выбрать водителя, ввести его ФИО- FIO, Дату рождения - Birthday, Паспортные данные - Passport, Номер телефона - Phone, категория вождения - Kateg. Код водителя - Id, генерируемый автоматически, не изменяется. При подтверждении изменения данных, в таблице Driver изменяются данные по водителя с выбранным ID. Обработку необходимо реализовать через хранимую процедуру.

Изменение данных по заказу. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.14). При изменении данных необходимо выбрать заказ, ввести его Наименование- Name, Дату формирования - date, Тип заказа - Type, параметры груза(вес, количество людей) - Param, Адрес доставки - Adress. Код заказа - Id, генерируемый автоматически, не должен изменяться. При подтверждении изменения данных, в таблице Zakas изменяется запись по заказу с выбранным Id. Обработку необходимо реализовать через хранимую процедуру.

Изменение времени выполнения заказа. При выполнении данного сценария необходимо выбрать заказ и ввести время выполнение. При подтверждение ввода в записи о заказе появляется запись о времени выполнения. Обработку следует реализовать через хранимую процедуру.

Удалениие данных:

Удаление ТС. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.19). При удалении данных выбирается ТС из таблицы на форме. При подтверждении удаления данных, из таблицы Transport удаляется запись с данными по выбранному ТС. Обработку необходимо реализовать через хранимую процедуру.

Удаление водителя. Сценарий соответствует рассмотренному в процессе проектирования одноимённому сценарию (рис.23). При удалении данных выбирается водитель из таблицы на форме. При подтверждении удаления данных, из таблицы Driver удаляется запись с данными по выбранному водителю. Обработку необходимо реализовать через хранимую процедуру.

При удалении данных по ТС необходимо реализовать удаление данных в путевом листе по ТС. Сценарий следует реализовать через триггер.

При удалении данных по водителю необходимо удалять данный в ПЛ по этому водителю. Сценарий следует реализовать через триггер.

При удалении ПЛ необходимо производить удаление в записях о ПЛ в данных о заказах. Сценарий следует реализовать через триггер.

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

Выбор данных:

Выбор данных по ТС. Сценарий необходим для вывода данных в соответствующий элемент формы. Сценарий необходимо реализовать через хранимую процедуру.

Выбор данных по заказам. Сценарий необходим для вывода данных в соответствующий элемент формы. Сценарий необходимо реализовать через хранимую процедуру.

Выбор данных по водителям. Сценарий необходим для вывода данных в соответствующий элемент формы. Сценарий необходимо реализовать через хранимую процедуру.

Сценарий поиска данных о ТС по типу заказа. Сценарий необходим для вывода данных в соответствующий элемент формы. При добавлении заказа в путевой лист формируется список ТС, соответствующих типу заказа. Сценарий реализуется через хранимую процедуру.

Сценарий поиска данных о водителях по типу заказа. Сценарий необходим для вывода данных в соответствующий элемент формы. При добавлении заказа в путевой лист формируется список водителей, соответствующих типу заказа. Сценарий реализуется через хранимую процедуру.

Сценарий поиска данных о заказах одной даты доставки. Сценарий необходим для вывода данных в соответствующий элемент формы. Для поиска данных необходимо выбирать дату. При подтверждении поиска информация по заказам выводится в соответствующий элемент формы. Сценарий следует реализовать через хранимую процедуру

Сценарий поиска данных о ПЛ по ФИО водителя. Сценарий необходим для вывода данных в соответствующий элемент формы. Для поиска данных необходимо выбирать водителя. При подтверждении поиска информация по ПЛ выводится в соответствующий элемент формы. Сценарий следует реализовать через хранимую процедуру

.6 Разработка механизмов реализации серверной компоненты

. Добавление данных