Сетевая технология планирования и учета поставок деталей для сборки автомобилей на платформе В0 в ОАО "Автоваз"

 

Сетевая технология планирования и учета поставок деталей для сборки автомобилей на платформе В0 в ОАО "Автоваз"

автоматизация заказ локальный сеть

Реферат

АВТОМАТИЗАЦИЯ, CASE ТЕХНОЛОГИИ, ОФОРМЛЕНИЕ ЗАКАЗОВ, АРХИТЕКТУРА «КЛИЕНТ-СЕРВЕР», WEB-СЕРВЕР, СЕРВЕР ПРИЛОЖЕНИЙ, SQL-СЕРВЕР, ЗАПРОСЫ.

Объектом исследования является автоматизация процесса поставки деталей на ОАО «АВТОВАЗ».

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

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

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

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

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

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

Введение

В настоящее время активно развивается сотрудничество ОАО «Автоваз» с компанией «Renault», вследствие чего на «Автовазе» начинается сборка новых автомобилей на новых платформах. На данный момент большая часть деталей для новых моделей автомобилей поставляется из-за границы, однако некоторые детали производятся и на самом «Автовазе». Разрабатываемая система направлена на облегчение таких процессов как заказ деталей, производимых на «Автовазе», планирование графика изготовления и отгрузки деталей, учета получения готовых деталей после отгрузки.

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

Новизна курсового проекта состоит в том, что в настоящее время на «Автовазе» на платформе В0, где производят новые модели автомобилей, не реализована подобная система.

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

Областью применения данного проекта являются:

1.ОАО «Автоваз».

2.Дочерние предприятия ОАО «Автоваз».

Анализ поставленной задачи и постановка задачи на проектирование

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

Анализ существующей технологии обработки информации

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

Процесс поставки деталей можно разделить на следующие задачи:

1.Ведение нормативной базы;

2.Планирование производства (формирование плана производства, программы производства);

.Учет перемещения деталей по технологическому маршруту;

.Учет отклонений от технологического маршрута (брак, инвентаризация и т.д.);

.Контроль выполнения программы производства (формирование отчетов);

.Учет состояния складов.

Схема поставки деталей представлена на рисунке 1.

Рис.

Из рисунка 1 видно, что заготовки деталей от удаленных внешних поставщиков сначала поступают на склады Дирекции по логистике, после чего направляются в цеха изготовления деталей. Заготовки же от местных внешних поставщиков и изготовляемые непосредственно на самом АВТОВАЗе, сразу поступают в цеха изготовления деталей.

Ниже представлен рисунок 2, на котором раскрывается комплекс цехов изготовления деталей:

Рисунок 2 - Комплекс цехов изготовления деталей.

Рассмотрим подробнее задачи процесса поставки деталей.

Ведение нормативной базы.

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

Сопровождение СПС выполняется частично в информационной системе.

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

1.Планирование производства.

Рисунок 3 - Планирование производства

1)Формирование плана товарного выпуска (автомобили, запасные части, кооперация);

2)Формирование СПС (нормативной базы);

)Формирование программы производства (разузлованный согласно СПС план товарного выпуска по производствам, цехам, складам, контрагентам АВТОВАЗа).

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

Контроль выполнения программы производства выполняется непрерывно.

Здесь формирование плана, СПС и программы производства осуществляется вручную сотрудниками АВТОВАЗа и после этого вводится в ИС. Это занимает много времени и повышает возможность возникновения ошибочных расчетов в планах.

2.Учет перемещения деталей по технологическому маршруту.

Схема перемещения деталей по технологическому маршруту показана на рисунке 4.

Рисунок 4 - Схема информационных потоков в информационной системе

Цифрами на рисунке 4 обозначены:

1)Регистрация отгрузки комплектующих со складов ДпЛ. Выполняется на складах ДпЛ, печатается сопроводительный документ - Отгрузочная ведомость.

2)Регистрация приемки комплектующих от внешних поставщиков. Выполняется на складах прямой поставки деталей. Печатается бирка на тарное место.

3)Регистрация отгрузки деталей из производств МтП, ПрП. Выполняется на складах готовых деталей в МтП, ПрП, печатается сопроводительный документ - Накладная передачи деталей.

4)Регистрация отгрузки готовых узлов по направлениям (в СКП, в з/ч, кооперация, МСП) Выполняется на складах готовых деталей,запасных частей, печатается сопроводительный документ - Накладная передачи деталей.

3.Учет отклонений от технологического маршрута (брак).

Рисунок 5 - Учет деталей в изоляторе брака

На рисунке 5:

1. Информирование ДпК о факте брака. В на основе ИС Управление качеством, формируется Акт бракования продукции или Акт возврата продукции. Чаще всего, данная операция производится вручную, или полуавтоматически.
2. Подпись акта бракования представителями ДпК, цеха, поставщика детали (поставщика - в случае обнаружения брака по вине поставщика).
3. Регистрация приема бракованных деталей на склад-изолятор брака. Выполняется на складе-изоляторе брака на основе документов: Акт бракования продукции или Акт возврата продукции (по данным ИС Управления качеством).
4. Регистрация отгрузки брака поставщику (в случае обнаружения брака по вине поставщика). Выполняется на складе-изоляторе брака.
5. Регистрация отгрузки брака в ООО ПППО (в случае обнаружения окончательного брака по вине цеха). Выполняется на складе-изоляторе брака.

В ИС ведется учет состояния склада-изолятора брака в режиме реального времени.

. Контроль выполнения программы производства (формирование отчетов)

Ответственными подразделениями в МСП, отвечающим за контроль выполнения программы производства по комплексу изготовления деталей, является ПДБ Шасси и ПО МСП.

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

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

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

Наиболее важными табуляграммами и видеограммами в ИС являются Баланс движения деталей (БДД) и Контроль хода отправки (КХО).

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

Учет состояния складов.

Типовые конфигурации автоматизированных рабочих мест (АРМ):

АРМ склада комплектующих (склады комплектующих, склады прямой поставки - входная номенклатура):

ПК (для складов прямой поставки);

принтер Zebra для печати бирки на тарное место.

АРМ склада готовых деталей (склады готовых деталей, кооперации, запасных частей, изолятор брака - выходная номенклатура):

ПК + принтер Zebra для печати бирки на тарное место;

матричный принтер для печати Накладной передачи деталей.

АРМ плановика ПДБ (АРМ плановика ПДБ, выполняющего функции контроля хода производства и выполнения программы производства):

ПК + лазерный принтер для печати видеограмм по контролю хода производства и выполнению программы производства.

Каждое АРМ требует только одной точки подключения в сеть (ПК). Прочее оборудование (принтеры) подключается непосредственно к ПК. АРМ на складе может быть оснащен весовым комплексом (ЭТВС), интегрированный в ИС и также не требует отдельной точки подключения. На каждом складе присутствует не менее 2 АРМ (в зависимости от объема номенклатуры). Рассмотрим основные недостатки существующей информационной системы:

1.В случае если процесс оформления заказа или составления отчета выполняется вручную, насколько правильно он оформлен зависит от грамотности составителя. Это приводит к следующим проблемам:

·возможны ошибки при составлении заказов из-за человеческого фактора;

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

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

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

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

Разработка новой технологии обработки информации

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

Рассмотрим способы решения выявленных проблем в пункте 1.1. Таким образом, создаваемая технология должна отвечать следующим требованиям:

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

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

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

В ходе проектирования технологии необходимо построить UML диаграммы, позволяющие описать функционирование и реализацию эту систему. Ниже приведем диаграмму вариантов использования системы (use case diagram) (Рисунок 3).

Рисунок 2 - диаграмма вариантов использования проектируемой сетевой технологии.

Проектируемая сетевая технология должна обеспечивать одновременную работу до 30 человек. К ним относятся:

оператор производства Renault, который составляет заказы и принимает детали;

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

кладовщик, который отгружает детали со склада в соответствии с накладной;

рабочие, изготавливающие детали в соответствии с графиком.

Ниже приведем диаграмму последовательности (sequence diagram) для оператора Renault и АИС, поскольку именно они реализуют накопление информации о деталях в БД, которая и будет использоваться для дальнейшего статистического анализа, а также построения отчетов об изготовлении и доставке деталей.

Рисунок 3 - диаграмма последовательности работы оператора Renault

Каждому оператору предоставляется своя область работы с ИС, которая определяется формой заказа, предметной областью. Поэтому необходимо использовать систему аутенфикации, с целью недопустимости редактирования «чужой» информации оператором. После составления заказа происходит автоматическое сохранение в БД, после чего пользователю приходит сообщение об успешном сохранении с вопросом, желает ли он распечатать заказ. Если пользователь отвечает утвердительно, ему приходит веб-страница с заполненным заказом.

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

Для того чтобы начать разработку сетевой технологии необходимо выбрать ее архитектуру. Существуют следующие виды архитектур:

1. Архитектура с файл - сервером.
2. Архитектура с терминал - сервером.
3. Клиент - серверная архитектура.
4. Многозвенная клиент - серверная архитектура.

Приведем основные требования предъявляемые к архитектуре создаваемой технологии:

1.Минимальные затраты на внедрение и сопровождение.

2.Низкие требования к аппаратуре как клиентской части так и сервера.

.Максимально низкая нагрузка на сеть.

.Простота построения приложений данной архитектуры.

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

Сравним рассмотренные виды архитектур на соответствие предъявляемым требованиям (см. таблицу 1), и выберем подходящую.

Таблица 1 - Сравнение архитектур

ТребованиеВид архитектурыФайл-серверКлиент-серверМногозвенная клиент-сервернаяТерминал-серверМинимальные затратыДаДаНетНетНизкие требования к аппаратуреДаДаНетНетМинимальный трафикНетДаДаДаЛегкость построения приложенийДаДаДаДаПростота внедренияДаДаНетДаВсего Да:4 из 55 из 52 из 53 из 5

Сравнив рассмотренные виды архитектур видно, что в наибольшей степени всем предъявляемым требованиям удовлетворяет архитектура клиент-сервер. Поэтому выбор будет сделан в пользу архитектуры клиент-сервер. Данная архитектура представлена на рисунке 4.

При такой архитектуре персональные компьютеры объединены в локальную сеть, в которой имеется сервер баз данных, содержащий общие базы данных. Функции СУБД разделены на две части: пользовательские программы, такие как приложения для формирования интерактивных запросов и генераторы отчетов, выполняются на клиентском компьютере, а ядро базы данных, которое хранит данные и управляет ими, работает на сервере. В этой архитектуре SQL стал стандартным языком, обеспечивающим взаимодействие между пользовательскими программами и ядром базы данных.

Рис.

В архитектуре клиент - сервер запрос передается по сети на сервер баз данных в виде SQL-запроса. Ядро базы данных на сервере обрабатывает запрос и просматривает базу данных, которая также расположена на сервере. После вычисления результата ядро базы данных посылает его обратно по сети клиентскому приложению, которое отображает его на экране персонального компьютера.

Достоинства:

1.Легкость построения и внедрения приложений данной архитектуры.

2.Минимальный сетевой трафик.

.Обеспечивает широкий спектр разграничений прав доступа к БД.

Недостатки:

1.Сложность администрирования СУБД.

2.Жесткая привязанность приложений к конкретному SQL серверу, замена которого требует изменения кода программы в клиентских приложений.

.Общая производительность и надежность БД полностью зависит от конкретных технологий и особенностей применяемых в SQL сервере.

Выбор технологии и программного обеспечения для реализации новой сетевой технологии

В данной главе будет описано все необходимое ПО, используемое для создания результирующей сетевой технологии.

Выбор сервера базы данных

Для успешного решения поставленной задачи необходимо рассмотреть наиболее популярные SQL сервера и выбрать наиболее подходящий сервер.

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

Базы данных в данной системе могут быть реализованы в следующих программах: Informix, Oracle, MySQL, MS SQL Server. Для выбора наиболее подходящей программы необходимо ввести критерии выбора. Для ввода критериев выбора нужно учесть следующие факторы:

1. затраты на приобретение;
2. время освоения;
3. максимальное число пользователей одновременно обращающихся к базе;
4. платформу;
5. способ доступа;
6. требования к сложности SQL запросов;
7. скорость работы БД и СУБД;
8. сложность обслуживания БД.

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

На основе перечисленных факторов сформируем требования к СУБД, которые и будут являться критериями для выбора наиболее подходящей СУБД.

Таблица 2 - Требования к СУБД для создаваемой системы

№ПараметрТребование1Затраты на приобретениеНаименьшие2Максимальное число пользователей одновременно обращающихся к базе1003ПлатформаWindows4Размер базы данныхдо нескольких Гб5Тип программыбольшой web-сервер6Требования к сложности SQL запросов (Мощность языка SQL)Не сложные, стандартные7Сложность настройки, установки, администрированияминимальная8Стоимость программистов и администраторов (Сложность обслуживания БД)минимальная

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

Таблица 3 - Сравнение SQL - серверов

ПараметрInformixOracleMySQLMS SQL ServerНаименьшие затраты на приобретение0010Возможность 100 пользователей одновременно обращающихся к базе1111Платформа Windows1111Размер базы данных до 1 Гб1111Тип программы - большой web-сервер1111Требования к сложности SQL запросов (Мощность языка SQL) Не сложные, стандартные1111Минимальная сложность настройки, установки, администрирования0011Минимальная стоимость программистов и администраторов (Сложность обслуживания БД)0011ИТОГ:5587

На основе данного анализа, очевидно, что система MySQL является достаточной для создания нужной БД, но при этом она бесплатная. Следовательно, для реализации проекта будет взята СУБД MySQL.

Выбор языка написания серверных сценариев сетевой технологии

Языки программирования для создания web-приложений делятся на языки, используемые на стороне клиента, и языки, используемые на стороне сервера.

Код программ, работающих на стороне клиента (посетителя сайта) выполняется на компьютере посетителя сайта, в браузере, запущенном на компьютере пользователя (Internet Explorer, Opera, Netscape, Firefox и др.). Этот код пишется на языках JavaScript и VBScript.

Программа, используемая на стороне сервера, вставляет сгенерированные ею конструкции HTML и не передается клиенту, т.е. посетитель, просмотрев код страницы, никогда не увидит кода, генерирующего фрагменты HTML. Эти программы пишутся на таких языках программирования:

PHP;;.

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

Быстрота выполнения кода.

Этот критерий является очень важным. Оценивается по трехбалльной шкале:

- медленное выполнение кода;

- средняя скорость выполнения кода;

- быстрое выполнение кода.

Поддержка СУБД MySQL (выбрана в предыдущем пункте).

Шкала оценки:

- не поддерживает СУБД MySQL;

- поддерживает СУБД MySQL.

Выполнение приложения в любом браузере.

Шкала оценки:

- выполняется только в браузере MS Internet Explorer;

- поддерживает мало браузеров;

- выполняется в основных браузерах.

Стоимость.

- высокая стоимость среды программирования;

- средняя стоимость;

- свободное распространение.

Простота изучения (написания кода).

- сложен для понимания.

- относительно прост для изучения.

Сформируем таблицу сравнения и выберем наиболее подходящий язык программирования web-приложения.

Таблица 4 - Сравнение языков программирования web-приложений

№КритерийPHPPerlJava1.Быстрота выполнения кода3212.Поддержка SQL-сервера MySQL1113.Выполнение приложения в любом браузере3334.Стоимость4405.Простота изучения211Итог:13116

Из таблицы видно, что язык программирования PHP лучше других удовлетворяет поставленным критериям. Следовательно, для написания движка web-страницы будет использоваться язык программирования PHP.

Выбор web-сервера

Для организации сайтов в глобальной сети используются около двух десятков серверов. Основные из них Apache и MS IIS (Microsoft Information Server).

Web-сервер Apache работает под Windows и Unix-подобными операционными системами (Linux, FreeBSD, Solaris и т.д.). Web-сервер Apache является бесплатным продуктом с открытым исходным кодом.

Web-сервер MS IIS работает только под Windows, является коммерческим продуктом.

Таким образом, для разрабатываемой системы будет использоваться web-сервер Apache, так как он не уступает web-серверу MS IIS, но при этом является свободно распространяемым.

Итак, в данной главе определено, что технология имеет многозвенную архитектуру «клиент-сервер», состоящую из приложения, web-сервера, сервера приложений и SQL-сервера.

Выбрано программное обеспечение, реализующее данную архитектуру:

• SQL-сервер - MySQL.
• Web-сервер Apache.

Язык написания серверных сценариев - PHP.

Постановка задачи

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

1.В случае если процесс оформления заказа выполняется вручную, насколько правильно он оформлен зависит от грамотности составителя. Это приводит к следующим проблемам:

·возможны ошибки при составлении заказов из-за человеческого фактора;

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

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

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

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

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

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

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

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

Архитектурой для разрабатываемой сетевой технологии стала архитектура клиент-сервер. Ключевыми лицами в работе с разрабатываемой технологией были выделены:

1.Заказчик.

2.Исполнитель.

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

1.Технология создания веб-приложения PHP;

2.SQL-сервер - MySQL;

3.Web-сервер Apache.

Таким образом, были определены основные требования к разрабатываемой сетевой технологии.

Разработка сетевой технологии

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

Разработка логической модели данных

Разработка баз данных включает в себя этапы:

1. Системный анализ предметной области.
2. Инфологическое проектирование (концептуальная модель).
3. Даталогическое проектирование (логическая модель).
4. Физическое проектирование.

Анализ предметной области был произведён в пункте 1, остальные этапы будут рассмотрены ниже.

Для проектирования необходимо выбрать средства проектирования.

Выбор средств проектирования

Для проектирования необходимо выбрать CASE-средства. Оценка CASE-средств будет производиться по следующим критериям:

• возможность ввода и редактирования информации, описывающей элементы данных системы и их отношения;
• удобство пользовательского интерфейса. Удобство расположения и представления часто используемых элементов экрана, способов ввода данных и др.;
• простота освоения. Трудовые и временные затраты на освоение средств;
• совместимость обновлений (совместимость новых версий с существующими, включая, например, совместимость по входным или выходным данным);
• совместимость с версиями ОС (возможность работы в среде различных версий одной и той же ОС, простота модификации CASE-средства для работы с новыми версиями ОС);
• переносимость данных между различными версиями CASE-средства;
• затраты на CASE-средство. Включают стоимость приобретения, установки, начального сопровождения и обучения. С учётом цены для всех необходимых конфигураций (включая единственную копию, несколько копий, локальную лицензию, лицензию для предприятия, сетевую лицензию).

Каждый критерий может иметь оценку 0-5.

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

Оценка «5» означает, что данный критерий выполняется полностью.

То CASE-средство, которое будет иметь наибольший балл, будет принято. Балл этого программного обеспечения не должен быть меньше 30.

Оценка отражена в таблице 7.

В выборе и оценке участвуют следующие программные средства:

• Vantage Team Builder (Westmount I-CASE),
• Designer/2000;
• Silverrun;
• Erwin;
• S-Designor;
• CASE-Аналитик.

Таблица 5 - Оценка CASE-средств

CASE-средства Критерии оценкиWestmount I-CASEDesigner/2000SilverrunERwin+BPwinS-DesignorCASE.Аналитиквозможность ввода и редактирования информации, описывающей элементы данных системы и их отношения555555удобство пользовательского интерфейса433544простота освоения434554совместимость обновлений555554совместимость с версиями ОС555545переносимость данных между различными версиями CASE-средства545545затраты на CASE-средство430440ИТОГ:322827343126

Из приведённой таблицы видно, что наиболее удобным средством для проектирования является Computer Associates Erwin, так как он имеет наибольший балл.

Инфологическое проектирование

Инфологическое проектирование предполагает построение семантической модели предметной области, то есть информационной модели высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД <#"justify">Оператор.

Заказ.

Назначение

Детали.

Категория.

Атрибут.

Значение атрибута.

Склад.

Рисунок 7 - Концептуальная модель

Таблица

Наименование атрибутаТип поляОператорфамилияпростоеимяпростоеотчествопростоеОформлениеОператорпростоеЗаказпростоеДетальпростоеКоличество деталейпростоеЗаказ№простоеДата составленияпростоеДата исполненияпростоеДетали№простоеНаименованиепростое№ сериипростоеДата изготовленияпростоеДобавление детали в заказСкладпростоеДетальпростоеЗаказпростоеОтправление заказаЗаказпростоеНазначениепростоеНазначение№простоеНазвание производствапростоеСвойствоНазвание свойствапростоеОпределение свойстваДетальпростоеСвойствопростоеЗначение свойстваЗначениепростоеОпределение значенияСвойствопростоеЗначениепростоеСклад№простоеМесторасположениепростоеХранение на складеСкладпростоеДетальпростоеКоличество на складепростоеКатегорияНазвание категориипростоеОпределение категорииДетальпростоеКатегорияпростое

В итоге будут получены следующие отношения.

Отношение оператор-заказ будет опеределено связью один-ко-многим, т.к. один и тот же оператор может оформлять много заказов, но один заказ может оформить только один оператор.

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

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

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

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

Даталогическое проектирование подразумевает под собой набор схем отношений <#"justify">На основе полученной логической модели, отраженной на рисунке 8, можно перейти к физической модели разрабатываемой технологии. В ERwin 4.1 физическая модель является графическим представлением реально реализованной базы данных. Физическая база данных будет состоять из таблиц, столбцов и связей. Физическая модель зависит от платформы, выбранной для реализации, и требований к использованию данных.

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

Таблица 7 - Определение соответствий типов данных логической и физической моделей технологии

Тип данных логической моделиТип данных физической моделиstringvarchar (20)numberintegerdatedate

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

Разработка основных алгоритмов обработки информации

Данная система должна предусматривать два варианта использования:

1. Взаимодействие с оператором на производстве при приеме заказа.
2. Взаимодействие с оператором (мастером) на производстве при составлении и получении графиков изготовления и отгрузки деталей.

При взаимодействии с оператором система должна реализовывать следующие функции (основные):

• поиск нужных деталей на складе;
• добавление деталей в акт отгрузки деталей;
• оформление акта отгрузки деталей.

Поиск нужной детали происходит по ключевому слову, введённому в поле поиска. Ключевое слово ищется по всем группам деталей. Это позволяет искать детали по идентификатору и наименованию деталей. Алгоритм поиска представлен на рисунке 9.

Рисунок 9 - Сценарий обработки информации при поиске детали на складе

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

Рисунок 10 - Сценарий обработки информации при добавлении детали в акт передачи деталей

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

Рисунок 11 - Сценарий обработки информации при оформлении акта передачи деталей

При взаимодействии приложения с мастером система должна реализовывать следующие функции:

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

С точки зрения АИС формирование графиков изготовления и отгрузки деталей выглядит следующим образом:

Рисунок 13 - формирование графиков изготовления и отгрузки деталей (АИС)

АИС имеет возможность постоянной актуализации графиков изготовления и поставки деталей. Актуализация ведется по двум направлениям:

при получении заказа АИС оценивает загруженность своего участка производства на данный момент и количество уже выполняемых заказов. Исходя из этого она рассчитывает графики изготовления деталей;

ориентируясь на требования заказа АИС составляет графики отгрузки деталей.

С точки зрения системы процесс изменения количества товара на складе происходит следующим образом:

Рисунок 15 - Сценарий обработки информации при изменении количества деталей на складе

Данный процесс происходит после подтверждения мастером команды добавления количества деталей.

Процесс добавления новой детали представляет собой заполнение всех атрибутов детали.

Процесс изменения информации о детали представляет собой изменение атрибута детали.

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

Рисунок 16 - Сценарий формирования списка заготовок на производство

При формировании заказа на производство должно быть предусмотрено добавление количества заготовок для производства. Это количество определяет мастер на основе статистики заказов. Также необходима функция печати данного заказа. В системе организована структура пользователей с различными правами. По умолчанию существует две записи: клиент и администратор. Администратор имеет неограниченные права, которые невозможно ограничить. Он может создавать других пользователей и определять права для этих пользователей. Например, создать мастеров, отвечающих за различные функции системы: добавление и изменение деталей, работа с заказами, работа со складом и т.д. Данная функция рассчитана на разграничение прав ответственных мастеров при значительном расширении сферы использования системы. При создании (изменении) пользователя выполняется следующий алгоритм:

Рисунок 17 - Сценарий сохранения пользователя

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

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

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

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

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

Рисунок 18 - схема взаимодействия форм и интерфейсов системы

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

• Интерфейс для ввода новых данных;
• Интерфейс для актуализации БД;
• Интерфейс для получения отчета по запрашиваемым параметрам.

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

Рисунок 19 - страница главного навигационного меню системы

Стартовая страница предполагает выбор одной из четырех основных операций системы:

1. режим ввода новых деталей - предоставляет доступ к существующим записям БД, а также позволяет реализовывать ввод новой информации;
2. составление заказа/акта передачи деталей - предоставляет доступ к странице составления необходимого документа;
3. формирование графика - предоставляет доступ к странице ввода сведений для формирования графика;
4. просмотр графика - предоставляет доступ к странице составленных графиков для ознакомления.

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

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

Рисунок 20 - форма ввода новых данных в систему

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

Рисунок 21 - форма ввода деталей на склад

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

Рисунок 22 - форма составления акта отгрузки

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

Интерфейс составления заказа практически аналогичен акту отгрузки деталей:

Рисунок 23 - форма составления заказа

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

Рисунок 24 - интерфейс формирования графика

При нажатии кнопки «Сформировать график», происходит обработка полученного заказа системой и составление графика на время до даты исполнения заказа для конкретного подразделения определенного производства. Полученный график можно посмотреть прямо на странице формирования графика (рис. 25) или нажав кнопку «Просмотр графика» в главном меню программы, после чего откроется новое окно с графиком (рис. 26). Это сделано для того чтобы пользователи, у которых нет доступа к функции формирования графика, тем не менее тоже могли его посмотреть, ничего не изменяя.

Рисунок 25 - интерфейс составления графика

Рисунок 26 - интерфейс просмотра графика

Отображение структуры разработанной сетевой технологии

Как описано выше описываемая технология реализуется на многозвенной архитектуре «клиент-сервер». При выборе программного обеспечения определены программы для реализации компонентов архитектуры:

• SQL-сервер - MySQL.
• Web-сервер Apache.

Операторы работают с системой через локальную сеть с помощью браузера.

Структура разрабатываемой технологии выглядит следующим образом:

Рисунок 27 - Структура технологии автоматизированного оформления заказов на поставку деталей

На рисунке отображена диаграмма развёртывания для структуры технологии автоматизированного оформления заказов через глобальную сеть.

Оценка эффективности разработанной сетевой технологии публикации тестов

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

1. Скорость работы системы.
2. Защита от ошибочных действий пользователя.
3. Лёгкость понимания при работе с системой.

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

Миним_общее_время = Тотобр + Тотв + Твоспр

где Миним_общее_время - минимально возможное время,

Тотобр - время отображения веб-страницы,

Тотв - время получения ответа от системы,

Твоспр - время восприятия информации пользователем.

Доступ к функциям системы предоставляется пользователю сразу после прохождения удачной авторизации, на которую тратиться не более 10 секунд. Время отображения веб-страницы занимает не более 1 секунды. Время получения ответа системы занимает не более секунды. За счет удачного использования таблиц на веб-странице информация является читабельной и наглядной, поэтому для восприятия информации требуется не более 20 секунд.

Миним_общее_время = 1 + 1 + 20 =22 сек

Итого, для получения ответа с сервера пользователю потребуется не более 22 секунд.

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

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

Заключение

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

На этапе анализа бала рассмотрена базовая технология поставки деталей и выявлены её недостатки, такие как:

1.процесс оформления заказа или составления отчета выполняется вручную, насколько правильно он оформлен зависит от грамотности составителя. Это приводит к следующим проблемам:

·ошибки при составлении заказов из-за человеческого фактора;

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

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

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

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

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

Для технологии была определена многозвенная архитектура «клиент-сервер». Для её реализации было выбрано следующее программное обеспечение:

• SQL-сервер - MySQL.
• Web-сервер Apache.

Язык написания серверных сценариев - PHP.

Также были определены основные требования к приложению и поставлена задача на разработку.

На этапе проектирования было произведено инфологическое, даталогическое и физическое проектирование

На этапе разработки были описаны основные алгоритмы обработки информации, разработан интерфейс пользователя.

Оценка эффективности производилась по параметрам системы, таким как:

1. Скорость работы системы.
2. Защита от ошибочных действий пользователя.
3. Лёгкость понимания при работе с системой.

Система удовлетворяет поставленным требованиям.

Литература

.Квентин Зервас Web 2.0: создание приложений на PHP- М.: «Вильямс», 2009. - С. 544.

.Киммел Пол, UML. Основы визуального анализа и проектирования - Изд. АСТ - 272 с.

.Коннолли Т., Бегг К., Базы данных. Проектирование, реализация и сопровождение. Теория и практика - 3-е изд. - М.: Вильямс, 2003. - 1436 с.

.Крэг Ларман, Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ и проектирование - 3-е издание - М.: Вильямс, 2006. - 736 с.

.Пейтон К., PHP5 & MySQL 5 в примерах и на проектах - Изд. Бином, 2009. - 368 с.

.Шибанов С. В., Основы разработки баз данных в клиент-серверных приложениях - Изд. ПГУ, 2010. - 580 с.

Сетевая технология планирования и учета поставок деталей для сборки автомобилей на платформе В0 в ОА

Больше работ по теме:

Сетевая база данных "Трудовая биржа"
Диплом
Проектирование баз данных
Диплом
Разработка базы данных "МВД"
Диплом
Разработка информационной подсистемы тестирования встроенного программного обеспечения PLC-модемов для ЗАО "КИЭП "Энергомера"
Диплом
База данных "Гостиница"
Диплом