42
9. Запчасти
Код_запчасти
Наименование
Количество
10. Изменение_запроса
Код_запроса
Дата
Код_статуса
11. Тип_пользователя
Код_типа_пользователя
Наименование_типа_пользователя
12. Статус_запроса
Код_статуса
Наименование_статуса
13. Оборудование
Код_оборудования
Код_цеха
Код_типа_оборудования
Наименование
Инв._номер
Серийный_номер
Дата_учета
Примечание
Время_простоя
Отметка_об_остановке
На рисунке 14 представлена физическая модель данных.
Er-диаграмма базы данных в среде проектирования показана на
рисунке 15.
43
Рисунок 14 – Физическая модель данных
Рисунок 15 – Er-диаграмма базы данных в среде проектирования
44
Характеристика каждой таблицы и описание ее полей представлены в
таблицах 12 – 26.
Таблица 12 – Характеристика таблицы equipment
Поле
Тип
Null
id
int(11)
Нет
id_workshop
int(11)
Да
id_equipment_type
int(11)
Да
name
varchar(255)
Да
inventory_number
varchar(255)
Да
serial_number
varchar(255)
Да
start_date
datetime
Да
info
mediumtext
Да
downtime
float
Да
stand
bit(1)
Да
Таблица 13 – Характеристика таблицы equipment_maintenance_schedule
Поле
Тип
Null
id_equipment
int(11)
Нет
date_1
datetime
Нет
date_2
datetime
Нет
info
varchar(255)
Да
Таблица 14 – Характеристика таблицы equipment_type
Поле
Тип
Null
id
int(11)
Нет
name
varchar(255)
Да
Таблица 15 – Характеристика таблицы request
Поле
Тип
Null
id
int(11)
Нет
id_state
int(11)
Да
id_sender
int(11)
Да
id_equipment
int(11)
Да
request_date
datetime
Да
repair_date_1
datetime
Да
repair_date_2
datetime
Да
user_reason
varchar(255)
Да
true_reason
varchar(255)
Да
info
mediumtext
Да
id_subdivision
int(11)
Да
description
mediumtext
Да
culprit
varchar(255)
Да
performed_work
mediumtext
Да
production_culture
varchar(255)
Да
id_production_master
int(11)
Да
id_mender
int(11)
Да
id_dispatcher
int(11)
Да
kind_of_repair_work
varchar(255)
Да
45
Таблица 16 – Характеристика таблицы request_destinations
Поле
Тип
Null
id_request
int(11)
Нет
id_subdivision
int(11)
Нет
date
datetime
Нет
Таблица 17 – Характеристика таблицы request_spares
Поле
Тип
Null
id
int(11)
Нет
id_request
int(11)
Нет
id_spare
int(11)
Нет
date
datetime
Нет
spare_count
double
Нет
Таблица 18 – Характеристика таблицы request_states
Поле
Тип
Null
id_request
int(11)
Нет
id_state
int(11)
Нет
date
datetime
Нет
Таблица 19 – Характеристика таблицы request_users
Поле
Тип
Null
id_request
int(11)
Нет
id_user
int(11)
Нет
date_1
datetime
Да
date_2
datetime
Да
info
varchar(255)
Да
Таблица 20 – Характеристика таблицы settings
Поле
Тип
Null
id
int(11)
Нет
organization_name
varchar(255)
Да
Таблица 21 – Характеристика таблицы spare
Поле
Тип
Null
id
int(11)
Нет
name
varchar(255)
Да
spare_count
double
Да
Таблица 22 – Характеристика таблицы state
Поле
Тип
Null
id
int(11)
Нет
name
varchar(255)
Да
Таблица 23 – Характеристика таблицы subdivision
Поле
Тип
Null
id
int(11)
Нет
name
varchar(255)
Да
46
Таблица 24 – Характеристика таблицы user
Поле
Тип
Null
id
int(11)
Нет
surname
varchar(255)
Да
name
varchar(255)
Да
patronymic
varchar(255)
Да
login
varchar(255)
Да
password
varchar(255)
Да
id_user_type
int(11)
Да
phone
varchar(255)
Да
email
varchar(255)
Да
id_subdivision
int(11)
Да
id_workshop
int(11)
Да
block
bit(1)
Да
report_date_1
datetime
Да
report_date_2
datetime
Да
Таблица 25 – Характеристика таблицы user_type
Поле
Тип
Null
id
int(11)
Нет
name
varchar(255)
Да
Таблица 26 – Характеристика таблицы workshop
Поле
Тип
Null
id
int(11)
Нет
name
varchar(255)
Да
2.4. Разработка алгоритмов системы
При разработке некоторой системы, ее функциональные возможности,
то есть поведение, которым она должна обладать с точки зрения заказчика,
документируются с помощью модели прецедентов. Модель прецедентов
показывает, какие функции должна быть способна выполнять система, а
также в какой среде она должна работать. Модель прецедентов
разрабатывается на ранних этапах проектирования и дает возможность
заказчику четко сформулировать свои требования, а разработчику – понять,
что нужно заказчику [4,26].
Основными элементами модели прецедентов являются актеры и
прецеденты.
Актеры – могут только вводить информацию в систему, только
получать информацию из системы или делать и то, и другое. В роли актера
47
может выступать также и другая система, если она будет взаимодействовать
с разрабатываемой системой, и не будет являться ее неотъемлемой частью.
Прецеденты – предназначены для моделирования диалога между
системой и ее субъектами. Они представляют собой возможности, которые
система может обеспечить конкретному субъекту [39].
Работа системы осуществляется следующим образом:
1. Заказчик (представитель цеха) заходит в систему и формирует
заявку, выбирая из списка сломанное оборудование, вводя предполагаемую
причину поломки, при этом дата и время заявки устанавливается
автоматически.
2. Заявка попадает к диспетчеру, который направляет ее технику.
Диспетчер, при необходимости, может добавить свое примечание.
3. Техник рассматривает заявку и может либо принять ее на
исполнение, либо вернуть диспетчеру с указанием причины. В случае
возврата диспетчер назначает заявку другому сотруднику.
4. Если заявка принимается на исполнение, техник может выписать
накладную на получение какого-либо оборудования со склада, выбирая его
из списка.
5. Если необходимого оборудования в системе нет, исполнитель
может сформировать аварийную заявку в отдел снабжения, для поставки
требуемого оборудования на склад и распечатать ее. Если при следующей
синхронизации оказывается, что это оборудование уже поступило на склад, в
списке заявок в работе должно появится уведомление о том, что
оборудование поступило на склад и можно приступать к ремонтным работам.
6. По окончании ремонта техник закрывает заявку и наряд, выбирая из
списка выполненные работы, а также используя список оборудования,
которое было выдано для проведения данного ремонта. Оборудование также
можно добавлять в наряд при его закрытии. Дата и время закрытия
устанавливается автоматически.
48
7. Закрытая техником заявка отображается у заказчика в списке
выполненных работ. Заказчик должен закрыть ее окончательно или
отправить на доработку, добавив примечание.
В диаграмме прецедентов 3 актера. На рисунках 16 и 17 представлены
диаграммы прецедентов, которые представляют функции администратора по
работе с системой и функции заказчика соответственно.
Управление справочниками
системы
Просмотр загруженности
техников
Формирование и отправка
заявки исполнителю
Просмотр открытых/закрытых
нарядов за определенный
период
Просмотр комплектующих
на складе
Получение отчетов
Сравнительный отчет по
простою оборудования
Отчет по простаивающему
оборудованию
Отчет по количеству
поступивших заявок за период
Отчет по загруженности
техников за определенный
промежуток времени
Сравнительный отчет по
количеству выполненных
заявок за период
Администратор
(диспетчер)
Рисунок 16 – Диаграмма прецедентов администратора
Оформление заявки
Просмотр оформленных заявок
Просмотр времени простоя
оборудования за период
Просмотр текущего времени
простоя оборудования
Выбор оборудования
Ввод предполагаемой причины
поломки
Отчет по простаивающему
оборудованию в настоящий
момент
Отчет по количеству
поступивших заявок за период
Сравнительный отчет по
простаивающему оборудованию
Получение отчетов за свой цех
Заказчик
Рисунок 17 – Диаграмма прецедентов заказчика
49
Диаграмма прецедентов, отражающая функции техника, представлена
на рисунке 18.
Просмотр невыполненных нарядовПросмотр закрытых нарядов
Просмотр отремонтированного
оборудования
Формирование аварийной заявки
Прием заявки
Причина отказа от выполнения
заявки
Формирование накладной на
выдачу комплектующих
Закрытие заявки
Формирование наряда
Получение отчетов
Сравнительный отчет по простою
оборудования
Отчет по простаива ющему
оборудованию в настоящий
момент
Отчет по количеству поступивших
заявок за период
Отчет по загруженности техника за
определенный промежуток
времени
По оборудованию, которое более
всего простаивало за период
(сравнительно по типам)
Техник
Рисунок 18 – Диаграмма прецедентов техника
Перед началом работы с БД, необходимо выполнить аутентификацию
пользователя, система запрашивает его логин и пароль. В случае если
пользователь не прошел регистрацию либо была допущена ошибка в пароле
и/или логине, то ему не предоставляется доступ к работе в ИС. Если проверка
пользовательского логина и пароля прошла успешно откроется главное окно
программы. На рисунке 19 показана диаграмма очередности действий при
выполнении аутентификации.
Прецедент «Учет заявки» активизируется пользователем ИС
выступающим в качестве заказчика. Данным прецедентом описывается
процедура ввода новых данных в БД. В установленную форму на основании
документов вводятся данные, а также вся справочная информация, которая
необходима при работе с системой. На рисунке 20 показана диаграмма
очередности действий подобного прецедента.
50
Кнопка
Данные
аутентификации
Окно авторизации
Основное окно
Ввод логина и пароля
Нажатие на кнопку
Запрос данных
Данные аутентификации
Проверка полученных
данных
Вывод сообщения о неверно
введенных данных
Открытие главного окна, если проверка успешна
Оператор
Рисунок 19 – Диаграмма очередности «Аутентификация пользователя»
Форма ввода заявки
Поле ввода причины
Форма выбора
оборудования
Ввод предполагаемой
причины
Нажатие на кнопку
Таблица
Заявки
Кнопка Сохранить
Сохранение данных
Сообщение
об успешном сохранении заявки
Заказчик
Рисунок 20 – Диаграмма последовательности «Учет заявок»
51
Диаграмма последовательности «Распределение заявок» показывает
порядок распределения и направления заявок технику для исполнения.
Диаграмма последовательности на рисунке 21 показывает очередность
действий при распределении заявок.
Форма списка заявок
Выбор техникаФорма заявки
Выбор заявки
Выбор техника
Нажатие на кнопку
Таблица Заявки
Кнопка Сохранить
Сообщение
об успешной обработке заявок
Список заявок
Заявка
Список техников
Диспетчер
Рисунок 21 – Диаграмма распределения заявок
Диаграмма последовательности «Обработка заявки техником»
показывает порядок обработки заявок при получении техником. Исполнитель
может либо отказаться от заявки, либо принять ее на исполнение. Диаграмма
последовательности при отказе от заявки приведена на рисунке 22.
Диаграмма последовательности при приеме заявки в работу приведена
на рисунке 23.