Курсовые работы / ПРИС К_8
.pdf
Декомпозиция процесса «Формирование технологической карты» представлена на рисунке 2.6.
Рисунок 2.6 – Декомпозиция процесса «Формирование технологической карты»
Декомпозиция процесса «Запуск в производство» представлена на рисунке 2.7.
Рисунок 2.7 – Декомпозиция процесса «Запуск в производство»
22
Декомпозиция процесса «Проверка изделия в ОТК» представлена на рисунке 2.8.
Рисунок 2.8 – Декомпозиция процесса «Проверка изделия в ОТК»
2.4 Анализ модели данных
На основе технического задания была разработана логическая и физическая модели данных по стандарту IDEF1X. Данные модели представлены на рисунках 2.9 и 2.10 соответственно.
Рисунок 2.9 – Логическая модель данных по стандарту IDEF1X
23
Рисунок 2.10 – Физическая модель данных по стандарту IDEF1X
Отношение находится в третьей нормальной форме (3НФ), если оно находится во второй нормальной форме, и каждый не ключевой атрибут зависит только от первичного ключа и не зависят друг от друга.
Данные могут группироваться разными способами в таблицы
(отношения). В качестве исходной (отправной)точки при проектировании БД может использоваться одно какое-то универсальное отношение, в которое включаются все нужные атрибуты. Оно может содержать все данные, которые предполагается размещать в БД.
Алгоритм нормализации (к ЗНФ):
1.Получить исходное множество функциональных зависимостей для атрибутов рассматриваемой БД.
2.Получить минимальное покрытие множества функциональных зависимостей.
3.Определить первичный ключ отношения.
4.Если первичный ключ исходного отношения не вошел полностью ни в одну проекцию, то создать отдельное отношение из атрибутов ключа.
24
Выводы по второму разделу
В результате выполнения второго раздела курсового проекта были определены требования к разрабатываемому приложению, а также разработаны модели в различных нотация. Исходя из анализа данных макетов нотаций
IDEF0, DFD и IDEF1X можно сделать вывод, что разрабатываемое web-
приложение автоматизирует работу отдела технического контроля, упростит документооборот между отделами. Хорошо отлаженная система учётного документооборота отражает реально происходящую на предприятии текущую производственную деятельность и даёт управленцам возможность воздействовать на нее. Поэтому автоматизация документооборота позволяет повысить эффективность управления.
Вweb-приложении будет содержать пять справочников, а также в данном приложении вход будет осуществлять по логину и паролю.
Врезультате проектирования web-приложения был получен проект приложения, содержащий достаточно информации для её реализации.
25
3 РАЗРАБОТКА И ТЕСТИРОВАНИЕ ИС
3.1 Описание структуры базы данных
Для начала необходимо изучить структуру приложения. Общее представление содержимого:
Файл/Папка: app/
Назначение: Содержит контроллеры, модели, вьюхи, хелперы,
рассыльщики и ресурсы приложения.
Файл/Папка: bin/
Назначение: Содержит Rails скрипты которые стартуют ваше приложение, также директория может содержать другие скрипты которые вы используются для настройки, деплоя или запуска.
Файл/Папка: config/
Назначение: Конфигурации маршрутов, базы данных приложения, и т.д.
Файл/Папка: db/
Назначение: Содержит текущую схему базы данных, а также миграции базы данных.
Файл/Папка: lib/
Назначение: Внешние модули для приложения.
Файл/Папка: log/
Назначение: Файлы логов приложения.
Файл/Папка: public/
Назначение: Единственная папка, которая доступна извне как есть.
Содержит статичные файлы и скомпилированные ресурсы.
Файл/Папка: Rakefile
Назначение: Этот файл содержит набор команд, которые могут быть запущены в командной строке. Определения команд производятся во всех компонентах Rails. Вместо изменения Rakefile, вы можете добавить свои собственные задачи, добавив файлы в директорию lib/tasks вашего приложения.
26
Файл/Папка: README.rdoc
Назначение: Это вводный мануал для приложения. Его следует отредактировать, чтобы рассказать остальным, что ваше приложение делает,
как его настроить, и т.п.
Файл/Папка: test/
Назначение: Юнит-тесты, фикстуры и прочий аппарат тестирования. Это раскрывается в руководстве Тестирование приложений на Rails
Файл/Папка: tmp/
Назначение: Временные файлы (такие как файлы кэша и pid)
Файл/Папка: vendor/
Назначение: Место для кода внешних разработчиков. В типичном приложении на Rails, включает внешние гемы.
Файл/Папка: Gemfile, Gemfile.lock
Назначение: Эти файлы позволяют указать, какие зависимости от гемов нужны для приложения на Rails. Эти файлы используются гемом Bundler.
Для разрабатываемой ИС требуется создать 5 справочников и 3 отчета.
Справочники:
-газоанализаторы;
-сотрудники; -заказчики;
-заказы;
-разрабатываемые газоанализаторы.
Отчеты:
-отчет о заказах газоанализаторов
-отчет о занятости сотрудников
-поиск заказа по дате оформления
Следует рассмотреть подробнее каждый из справочников.
Втаблице 3.1 представлено описание справочника «Газоанализаторы».
Вданном справочнике содержится информация о названии газоанализатора и его фото. Также есть функции просмотра, удаления и
27
редактирования записи.
Таблица 3.1 – Таблица «Газоанализаторы»
Название таблицы |
Название поля |
Тип поля |
Примечание |
gazoanalizator |
Id |
integer |
Генерируется самостоятельно |
|
h_name |
string |
|
|
photo |
string |
|
|
status |
boolean |
|
|
s_delete |
boolean |
|
|
null |
timestamp |
Генерируется самостоятельно |
Втаблице 3.2 представлено описание справочника «Сотрудники».
Вданном справочнике содержится информация о фамилии, имени,
отчестве сотрудника, его фото, должность, дата рождения. Также есть функции просмотра, удаления и редактирования записи.
Таблица 3.2 – Таблица «Сотрудники»
Название |
Название поля |
Тип поля |
Примечание |
sotr |
Id |
Integer |
Генерируется самостоятельно |
|
s_fam |
string |
|
|
s_name |
string |
|
|
s_otch |
string |
|
|
s_date |
date |
|
|
dlzh |
string |
|
|
photo |
string |
|
|
status |
boolean |
|
|
s_delete |
boolean |
|
|
null |
timestamp |
Генерируется самостоятельно |
Втаблице 3.3 представлено описание справочника «Заказчики».
Вданном справочнике содержится информация о фамилии, имени,
отчестве заказчика, указан его адрес и контактный телефон Также есть функции просмотра, удаления и редактирования записи.
Таблица 3.3 – Таблица «Заказчики»
Название |
Название поля |
Тип поля |
Примечание |
zakazchiks |
Id |
Integer |
Генерирует самостоятельно |
|
s_fam |
string |
|
|
s_name |
string |
|
|
s_otch |
string |
|
|
s_date |
date |
|
|
adres |
string |
|
|
tel |
string |
|
|
status |
boolean |
|
|
s_delete |
boolean |
|
|
null |
timestamp |
Генерируется самостоятельно |
28
Втаблице 3.4 представлено описание справочника «Заказы».
Вданном справочнике содержится информация ФИО заказчика, названии заказанного газоанализатора, дата заказа, указан сотрудник, возможность подтверждения гарантийного срока либо указание цены за услугу (при отсутствии гарантии). Также есть функции просмотра, удаления и редактирования записи.
Таблица 3.4 – Таблица «Заказы»
Название |
Название поля |
Тип поля |
Примечание |
zakazs |
Id |
integer |
Генерируется самостоятельно |
|
|
|
|
|
zakazchik |
belongs_to |
Берется из таблицы заказчики |
|
gazoanalizator |
belongs_to |
Берется из таблицы газоанализаторы |
|
s_date |
date |
|
|
sotr |
belongs_to |
Берется из таблицы сотрудники |
|
garant |
boolean |
|
|
cena |
integer |
|
|
status |
boolean |
|
|
s_delete |
boolean |
|
|
null |
timestamp |
Генерируется самостоятельно |
Втаблице 3.5 представлено описание справочника «Разрабатываемые газоанализаторы».
Вданном справочнике содержится информация о названии газоанализатора и указании сотрудника, который занимается данным видом газоанализатора. Также есть функции просмотра, удаления и редактирования записи.
Таблица 3.5 – Таблица «Разрабатываемые газоанализаторы»
Название |
Название поля |
Тип поля |
Примечание |
pazgazoanalizator |
Id |
integer |
Генерируется самостоятельно |
|
|
|
|
|
gazoanalizator |
belongs_to |
Берется из таблицы газоанализаторы |
|
sotr |
belongs_to |
Берется из таблицы сотрудники |
|
status |
boolean |
|
|
s_delete |
boolean |
|
|
null |
timestamp |
Генерируется самостоятельно |
29
3.2 Дерево программных модулей
При разработке модуля, решающей задачи автоматизации документооборота, важным этапом является описание иерархии функций управления и обработки данных разрабатываемого программного продукта.
Дерево функций представляет собой иерархическую структуру.
Все действия (функции) программного продукта можно разделить на подмножества основных функций.
Основные функции управления и обработки данных - свойственны как информационным системам любой специализации, так и именно в данном модуле. Они отражают особенности процесса обработки информации,
получения результатов, ведения информационной базы проекта. Эти функции организованы в том порядке и в том составе, которые продиктованы условиями обработки и управления данными в конкретной предметной области.).
Нарисунке 3.1 представлено дерево программных модулей.
авторизация
справочники |
|
|
газоанализаторы |
|
Добавление, редактирование, удаление и просмотр информации |
|
||
сотрудники |
|
Добавление, редактирование, удаление и просмотр информации |
|
||
заказчики |
|
Добавление, редактирование, удаление и просмотр информации |
|
||
заказы |
|
Добавление, редактирование, удаление и просмотр информации |
|
||
Разработанные газоанализаторы |
|
Добавление, редактирование, удаление и просмотр информации |
|
отчеты |
|
|
Отчет о заказах газоанализаторов |
|
Обработка запроса и вывод в Excel |
|
||
Отчет о занятости сотрудников |
|
Обработка запроса и вывод в Excel |
|
||
Поиск заказа по дате оформления |
|
Обработка запроса и вывод в Excel |
|
||
пользователи |
|
|
Рисунок 3.1 – Дерево программных модулей
30
3.3 Схемы взаимосвязей модулей и массивов данных
Схема взаимосвязи программных модулей должна содержать структуру программы, составные части (модули) и отражать связь между ними.
На основе алгоритма определяется укрупненная схема функционирования алгоритма по перестройке входной информации в выходную.
В соответствии с описанием алгоритма необходимо разработать блок схему, которая предназначена для отображения процесса решения задачи на ЭВМ с применением совокупности программных модулей, указанием взаимосвязи между ними и используемыми на входе и выходе алгоритма не только для перечня и характеристики блоков, но возможности локализации в блоках определённых модулей обработки информации. На рисунке 3.2
изображена схема взаимосвязи модулей и массивов данных.
пользователи авторицация газоанализаторы сотрудники заказчики заказы Разработанные газоанализаторы Отчет о заказах газоанализаторов Отчет о занятости сотрудников Поиск заказа по дате оформления
База данных
Рисунок 3.2 – Схема взаимосвязи модулей и массивов данных
Информационной базой данного модуля являются таблицы: «Газоанализаторы», «Сотрудники», «Заказчики», «Заказы», «Разработанные газоанализаторы».
Структура этих таблиц была представлена ранее (в пункте 3.1)
31