Диплом: Автоматизация и обеспечение информационной безопасности процесса приема техники на ремонтные работы в ОАО Samsung Service

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
68
Рисунок 2.4 Экранная форма ввода данных в справочник Цеха
Рисунок 2.5 Экранная форма ввода данных в справочник Оборудование
2.2.3 Характеристика результатной информации
В качестве выходных данных в разработанной ИС формируются следующие
отчеты:
69
Отчет по количеству поступивших заявок за период за каждый цех
сравнительно с другими цехами;
По простаивающему оборудованию в настоящий момент;
Сравнительный отчет по простою оборудования каждого цеха за
период;
Сравнительный отчет по количеству выполненных заявок за период
за каждый отдел сравнительно с другими отделами ремонтного подразделения;
По оборудованию, которое более всего простаивало за период
(сравнительно по типам)
Отчет по загруженности работников ремонтной службы за
определенный промежуток времени
Примеры отчетов приведены на рисунках ниже.
Рисунок 2.6 Сводный отчет по цехам
Рисунок 2.7 Сводный отчет по отделам
70
Рисунок 2.8 Сводный отчет по сотрудникам
Рисунок 2.9 Сводный отчет по оборудованию
Рисунок 2.10 Сводный отчет по типам оборудования
2.3 Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
71
В системе предусмотрено 4 типа пользователей. На рис. 2.11 представлена
диаграмма прецедентов, которая представляет функции администратора по работе
с системой.
Администратор (диспетчер)
Управление справочниками
системы
Просмотр загруженности
работников ремонтной службы
Отправка заявки исполнителю
Просмотр открытых и закрытых
нарядов за определенный
период
Просмотр комплектующих на
складе
Получение отчетов
Сравнительный отчет по
простою оборудования каждого
цеха за период
Отчет по простаивающему
оборудованию в настоящий
момент
Отчет по количеству
поступивших заявок за период
за каждый цех сравнительно с
другими цехами
Отчет по загруженности
работников ремонтной службы
за определенный промежуток
времени
По оборудованию, которое
более всего простаивало за
период (сравнительно по типам)
Сравнительный отчет по
количеству выполненных
заявок за период за каждый
отдел сравнительно с другими
отделами ремонтного
подразделения
Учет ПВР
Рисунок 2.11 Диаграмма прецедентов администратора
Заказчик
Оформление заявки
Просмотр оформленных заявок
Просмотр времени простоя
оборудования за период
Просмотр текущего времени
простоя оборудования
Выбор оборудования
Ввод предполагаемой причины
поломки
Отчет по простаивающему
оборудованию в настоящий
момент
Отчет по количеству
поступивших заявок за период
По оборудованию, которое
более всего простаивало за
период (сравнительно по типам)
Получение отчетов за свой цех
Рисунок 2.12 Диаграмма прецедентов заказчика
72
Исполнитель (оператор)
просмотр невыполненных
нарядов
просмотр закрытых нарядов
просмотр отремонтированного
оборудования
оформление аварийной заявки
Прием заявки
Мотивированный отказ от
заявки
Формирование накладной на
выдачу комплектующих
Закрытие заявки
Оформление наряда
Получение отчетов за свой
отдел
Сравнительный отчет по
простою оборудования каждого
цеха за период
Отчет по простаивающему
оборудованию в настоящий
момент
Отчет по количеству
поступивших заявок за период
за каждый цех сравнительно с
другими цехами
Отчет по загруженности
работников отдела ремонтной
службы за определенный
промежуток времени
По оборудованию, которое
более всего простаивало за
период (сравнительно по типам)
Рисунок 2.13 Диаграмма прецедентов исполнителя
Руководитель
Сравнительный отчет по
простою оборудования каждого
цеха за период
Отчет по простаивающему
оборудованию в настоящий
момент
Отчет по количеству
поступивших заявок за период
за каждый цех сравнительно с
другими цехами
Отчет по загруженности
работников ремонтной службы
за определенный промежуток
времени
По оборудованию, которое
более всего простаивало за
период (сравнительно по типам)
Сравнительный отчет по
количеству выполненных
заявок за период за каждый
отдел сравнительно с другими
отделами ремонтного
подразделения
Рисунок 2.14 Диаграмма прецедентов руководителя
Сценарий диалога, формирующийся на основе дерева функций, приведен на
рисунке 2.15.
73
Главное меню
Отчет по количеству поступивших заявок за период
за каждый цех сравнительно с другими цехами
Отчет по простаивающему оборудованию в
настоящий момент
Сравнительный отчет по простою оборудования
каждого цеха за период
Оборудование
Работы
Цеха
Добавить
Отправить на
выполнение
Отказаться от
выполнения
Заявки
Справочники
Отчеты
Добавить
Удалить
Редактировать
Редактировать
Пользователи
Сравнительный отчет по количеству выполненных
заявок за период за каждый отдел сравнительно с
другими отделами ремонтного подразделения
Удалить
Формировать
наряд
По оборудованию, которое более всего простаивало
за период (сравнительно по типам)
Отчет по загруженности работников ремонтной
службы за определенный промежуток времени
Рисунок 2.15 Сценарий диалога для пользователя
2.3.2. Характеристика базы данных
Процесс реализации инфологической модели проходит в несколько шагов:
• Выявление сущностей;
• Выявление зависимостей между сущностями;
• Указание первичных и альтернативных ключей;
• Отражение атрибутов сущностей;
Перевод модели к требуемому уровню нормальной формы.
Логический уровень отражения модели – это абстрактный взгляд на данные,
где они представляются так, как будут выглядеть в реальном мире. Логическая
модель данных считается универсальной и никак не связана с отдельной
реализацией СУБД. А физическая модель данных зависит от каждой отдельной
СУБД, фактически являясь визуализацией системного каталога. В физической
модели заключены данные по всем объектам БД. Т.к. стандартов на объекты БД
просто нет (к примеру, нет стандарта на типы данных), физическая модель связана
с конкретной реализацией СУБД. Поэтому одной и той же логической модели
часто ставят в соответствие несколько разных физических моделей. И если в
74
логической модели не имеет значения, какой точно тип данных содержит атрибут,
то в физической модели очень важно указать всю информацию о необходимых
физических объектах.
Схема базы данных приведена на рисунке 2.16
Рисунок 2.16 Физическая модель данных
Характеристика каждой таблицы и описание ее полей представлено ниже.
Таблица 2.4
Характеристика таблицы 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)
Да
75
Таблица 2.5
Характеристика таблицы 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)
Да
Таблица 2.6
Характеристика таблицы request_spares
Поле
Тип
Null
id
int(11)
Нет
id_request
int(11)
Нет
id_spare
int(11)
Нет
date
datetime
Нет
spare_count
double
Нет
Таблица 2.7
Характеристика таблицы subdivision
Поле
Тип
Null
id
int(11)
Нет
name
varchar(255)
Да
Таблица 2.8
Характеристика таблицы user
Поле
Тип
Null
id
int(11)
Нет
surname
varchar(255)
Да
name
varchar(255)
Да
patronymic
varchar(255)
Да
76
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
Да
Таблица 2.9
Характеристика таблицы workshop
Поле
Тип
Null
id
int(11)
Нет
name
varchar(255)
Да
2.3.3. Структурная схема пакета (дерево вызова программных модулей)
Анализ концептуальной модели позволил выделить следующие пакеты:
интерфейсные элементы - классы, реализующие интерфейсные
компоненты;
пользовательский интерфейс - классы, реализующие объекты
интерфейса с пользователем;
интерфейс с БД - классы, реализующие интерфейс с базой данных;
база данных
ИС
Интерфейс с
БД
Пользовательс
кий интерфейс
Интерфейсные
элементы
Рисунок 2.17 Диаграмма пакетов
77
Диаграмма развертывания системы представлена на рисунке.
Сервер приложений
ПК заказчика
Локальная сеть
компании
Клиентская
часть
программы
Серверная
компонента
ПК диспетчера
Панель
управления
системой
Сервер БД
БД
ПК исполнителя
Клиентская
часть
программы
ПК руководителя
Клиентская
часть
программы
Рисунок 2.18 Диаграмма развертывания
Как следует из приведенной диаграммы, для развертывания системы
необходим сервер баз данных, сервер приложений, а также персональные
компьютеры пользователей системы с установленными на них клиентскими
компонентами программы.
Программа является многопользовательским клиент-серверным
приложением, состоящим из следующих элементов:
Сервер приложений;
Сервер базы данных;
Клиент.

Смотрите также:

"Автоматизация обработки заявок ООО "Проектно-Строительная Компания"
"Автоматизация процесса аттестации персонала для ООО "Нэт Бай Нэт Холдинг"
"Анализ интернет-активности конкурентов ( на примере конкурентов "Газпром нефть")
"Бухгалтерский учёт и аудит расчётов с подотчётними лицами в организации на примере ООО "ЛОЦ 10""
«Психологическое сопровождение персонала в организации на примере ООО «Крокус»
Cовершенствование деловой оценки персонала в организации (на примере ООО "Даймонд кейтеринг развитие")
IPO - инструмент финансирования деятельности организации. На примере ПАО «Нефтяная компания «Лукойл»
PR как средство продвижения организации (на примере ПАО "Тамбовский завод "Комсомолец им. Н.С. Артемова")
PR-коммуникации в сфере общественного питания (на примере кафе-кондитерской «Cream Cheese»)
SMM как средство повышения эффективности работы учреждений социокультурной сферы (на примере Малого театра)