Проектирование АИС планирования и учета поставок деталей для сборки автомобилей на платформе В0 в ОАО «Автоваз»

Филиал федерального государственного бюджетного образовательного учреждения высшего профессионального образования

«САМАРСКИЙ ГОСУДАРСТВЕННЫЙ АЭРОКОСМИЧЕСКИЙ УНИВЕРСИТЕТ имени академика С.П. КОРОЛЕВА (национальный исследовательский университет)»

в городе Тольятти Самарской области

Кафедра радиоэлектроники и системотехники

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

«Проектирование АСОИУ»

Проектирование АИС планирования и учета поставок деталей для сборки автомобилей на платформе В0 в ОАО «Автоваз»

Тольятти 2011 г.

РЕФЕРАТ Курсовая работа.

Пояснительная записка 30 с., 12 рис., 3 табл., 11 источников

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

Объектом исследования является автоматизированная информационная система для ОАО «АВТОВАЗ». Предметом исследования является процесс планирования и учета поставок деталей. Целью работы является проектирование АИС планирования и учета поставок деталей внутри ОАО «АВТОВАЗ» из изготавливающих детали цехов на платформу В0.

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

В процессе работы будет спроектировано web-приложение, разработаны схемы и модели БД, а также их спецификации.

Введение

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

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

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

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

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

Для достижения поставленной цели необходимо решить следующие задачи:

1. Описать предметную область и объект автоматизации.

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

3. Провести обзор аналогов.

4. Спроектировать модель предлагаемого состояния информационной системы заказчика «как должно быть».

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

6. Составить логическую модель БД.

Провести оценку проделанной работы и выявить дальнейшие пути улучшения АИС.

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

1. ОАО «АВТОВАЗ».

2. Дочерние предприятия ОАО «АВТОВАЗ».

Пояснительная записка состоит из введения, трех глав, заключения.

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

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

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

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

1 Описание и моделирование предметной области

1.1 Описание объекта автоматизации

ОАО «АВТОВАЗ» — российская автомобилестроительная компания, крупнейший производитель легковых автомобилей в России. Ежегодно «АВТОВАЗ» выпускает около 900 тыс. автомобилей, что говорит о его стабильности.

В феврале 2008 года корпорация Renault приобрела блокирующий пакет акций ОАО «АВТОВАЗ» (25%). Сотрудничество с Renault выгодно для обеих сторон, поэтому необходимо обеспечить высокое качество работы платформ, производящих автомобили партнера.

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

Рисунок 1 — административно-штатное устройство предприятия ОАО «Автоваз»

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

Каждое производство делится на цеха и подразделения, которые выполняют свои определенные задачи. В данном курсовом проекте будет спроектирована АИС для сборочно-кузовного производства (СКП). СКП включает в себя три линии конвейера, на двух из которых собираются автомобили семейств «Самара» и «Приора», а третья, называемая В0, была модернизирована и на ней планируется сборка автомобилей Renault.

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

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

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

1. Заказ и отгрузка деталей;

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

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

4. Составление графиков выполняемых заказов;

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

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

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

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

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

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

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

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

1.2 Формализация существующих бизнес-процессов

На сегодняшний день у «АВТОВАЗ"а существует следующая модель обработки и хранения данных.

Рисунок 2 -действующая система обработки данных ОАО «АВТОВАЗ» (для автомобилей семейства «Калина»)

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

— электронный документ с оформленным заказом;

— бумажный документ с оформленным заказом.

В ходе всего бизнес-процесса выполняется работа с данными о деталях. Это работа заключается как в сборе, актуализации, так и в последующем анализе и, при необходимости, сохранении ее в центральном репозитории. Большинство операций, на которых и строится существующая модель «как есть», выполняется вручную (например, при составлении заказа на производства или оформлении накладной на склад). Кроме того, при таком подходе проходит большой интервал времени между поступлением заказа и отгрузкой деталей, что вносит факт снижения актуальности результата, а также потерей времени работников на «излишние» действия, не связанные на прямую с их профессиональной обязанностью. Наконец, у «АВТОВАЗ"а реализуется накопление всей информации о деталях в виде документов или отчетов. Это вносит неудобства не только при сортировке данных, но и при поиске необходимого документа.

Проанализировав существующую модель обработки данных можно обрисовать ключевые проблемы текущей информационной системы «АВТОВАЗ"а:

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

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

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

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

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

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

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

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

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

1. АИС должна поддерживать одновременную работу с собой до 30 человек;

2. АИС должна реализовывать защиту от ошибочных действий пользователя;

3. АИС должна реализовывать репликацию БД;

4. АИС должна быть кроссплатформенна с целью дальнейшего использования в других предприятиях, подобных «АВТОВАЗу»;

5. АИС должна иметь систему разграничения прав доступа;

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

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

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

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

1.3 Обоснование технологии проектирования

В структурном анализе и проектировании используются различные модели, описывающие:

· Функциональную структуру системы;

· Последовательность выполняемых действий;

· Передачу информации между функциональными процессами;

· Отношения между данными.

К четвертой группе относится унифицированный язык моделирования UML (Unified Modeling Language), который представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы.

UML обладает механизмами расширения, предназначенными для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и ERM. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком. К его механизмам расширения относятся:

стереотипы;

тегированные (именованные) значения;

ограничения.

При проектировании данной системы будет использоваться объектно ориентированный подход. Это объясняется тем, что нотация данного подхода (UML) позволяет достаточно полно и наглядно описать предметную область и позволяет легко изменять проект (при изменении одного объекта или процесса не надо изменять все остальные, как, например, в структурном подходе).

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

ѕ общая информационная модель системы (для её построения будет использоваться диаграмма вариантов использования, поскольку система имеет несколько вариантов использования);

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

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

ѕ построенные прототипы экранов, отчетов, диалогов.

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

Существуют следующие средства для проектирования с помощью UML:

· Visual Paradigm 6.1 Enterprise;

· Rational Rose;

· Borland Together;

· ArgoUML;

· Netbeans UML Plugin;

· Eclipse Omondo Plugin;

· Enterprise Architect

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

· Возможность генерации программного кода на языке PHP.

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

· Поддержка ОС Windows.

· Стоимость приобретения.

· Опыт успешного использования (отзывы).

· Простота освоения и использования.

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

0 — не удовлетворят требованию

5 — частично удовлетворяет требованию

10 — полностью удовлетворяет требованию Стоимостной критерий является наиболее важным, поэтому его баллы выше:

0 — высокая стоимость;

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

20 — бесплатно Таблица 1. Исходные данные для выбора CASE-средства

Анализ показал, что наиболее подходящие для проектирования CASE средства это Visual Paradigm и Enterprise Architect. При проектировании будет использоваться Visual Paradigm, так как имеется опыт работы в данной программе.

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

2 Проектирование ИС

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

2.1 Сравнительный анализ, выбор и разработка архитектуры

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

1. Архитектура с файл — сервером.

2. Архитектура с терминал — сервером.

3. Клиент — серверная архитектура.

4. Многозвенная клиент — серверная архитектура.

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

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

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

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

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

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

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

информационная система учет поставка

Таблица 2 — Сравнение архитектур

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

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

Рисунок 3 — Схема архитектуры клиент-сервер проектируемой АИС Компоненты проектируемой системы:

1. Web-сервер + PHP модуль.

2. SQL-сервер.

3. Браузер клиента.

2.2 Проектирование ИС

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

Ниже приведем диаграмму вариантов использования системы (use case diagram) (Рисунок 5).

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

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

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

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

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

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

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

— добавление деталей со склада в акт отгрузки в соответствии с требованиями заказа (в случае наличия деталей);

— перенаправление заказа на производства для изготовления необходимых деталей (в случае отсутствия деталей на складе).

После внесения каких-либо изменений в БД мастер также имеет возможность просмотреть нужную таблицу посредством специальной web-страницы.

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

Рисунок 8 — диаграмма последовательности работы мастера на производстве для оформления акта отгрузки Приведем диаграмму классов (Рисунок 10), описывающую иерархию классов, реализуемые ими методы, а также поля, содержащие разного рода информацию, обрабатываемую в системе.

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

— добавление деталей в акт отгрузки деталей (реализуется классом AktOtgruz) — спецификация к реализуемым методам класса приведена в Приложении A;

— учет поступивших заказов (реализуется классом Graphic) .

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

— на основе имеющихся данных по деталям на складе и по заказанным деталям выполняется проверка наличия деталей на складе (реализуется вызовом метода searchSkladDetali () класса Operator (спецификация к реализуемому методу приведена в Приложении В));

— на основе имеющихся данных по количеству заказанных деталей и сроков выполнения заказа выполняется расчет графиков изготовления и отгрузки деталей для данного заказа (реализуется вызовом метода getGraph () класса Graphic).

Приведем диаграмму развертывания проектируемой АИС на рисунке ниже.

Рисунок 9 — диаграмма развертывания проектируемой АИС Рисунок 10 — диаграмма классов проектируемой АИС

3 Проектирование БД ИС

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

1. Системный анализ предметной области.

2. Инфологическое проектирование (концептуальная модель).

3. Даталогическое проектирование (логическая модель).

4. Физическое проектирование.

Анализ предметной области был произведён в разделе 1. Физическое проектирование произведено не будет, так как проектируемая система не привязана к определённой СУБД.

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

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

Сущности:

1. Оператор.

2. Заказ.

3. Назначение

4. Детали.

5. Категория.

6. Атрибут.

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

8. Склад.

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

Рисунок 11 — Концептуальная модель Отношение оператор-заказ описывает функцию составления заказа оператором.

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

Отношение детали-категория определяет к какой категории принадлежит деталь. Отношение детали-свойство определяет конкретное свойство каждой детали (например, материал), а отношение свойство-зачение задает значение этого свойства для детали (например, металл).

Отношение деталь-склад определяет, сколько каких деталей хранится на конкретном складе.

3.2 Обоснование логической модели БД

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

1. Реляционная модель. Состоит из отношений и элементов отношений.

2. Многомерная модель. Состоит из измерений. Измерение — это множество однотипных данных, образующих одну из граней гиперкуба.

3. Темпоральная модель. Состоит из трех компонент: структура данных DS, операции OP и ограничения целостности C.

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

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

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

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

Для построения данной модели будет использоваться ERwin Data Modeler. Данное CASE-средство удовлетворяет следующим требованиям:

— возможность генерирования физической модели БД на основе имеющейся логической модели;

— бесплатное распространение программного продукта;

— личный опыт работы с программным продуктом.

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

3.3 Построение логической модели БД

В пункте 3.1 были определены следующие основные сущности модели данных проектируемой АИС:

1. Оператор.

2. Заказ.

3. Назначение

4. Детали.

5. Категория.

6. Атрибут.

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

8. Склад.

Кроме этого в данном пункте был определен набор основных атрибутов данных сущностей.

Каждая сущность имеет свой уникальный идентификатор, который позволяет получить доступ к любой произвольной записи таблицы. Данный идентификатор является первичным ключом (простой ключ) для соответствующей сущности. Некоторые сущности могут иметь альтернативные ключи, которые тоже однозначно определяют запись. Например, таблица «Оператор» имеет альтернативный ключ «Логин», этот ключ полностью идентифицирует запись. Отчёт по альтернативным ключам представлен в приложении С.

Для модели определены инверсные ключи. Инверсный ключ — это атрибут или группа атрибутов, которые используются для доступа к сущности (так, как если бы они были первичными ключами), однако не обязательно находят только один экземпляр. В таблице «Заказ» определён инверсный ключ «ИД_Оператор». Это объясняется тем, что запросы по заказу будут осуществляться по составившему его оператору, например, отобразить все заказы конкретного мастера. Отчёт по инверсным ключам представлен в приложении 3.

В системе должна реализовываться ссылочная целостность. Для примера рассмотрим реализацию ссылочной целостности для связи

«Т_Оператор Т_Заказ»

где Т_Оператор — родительская таблица, Т_Заказ — дочерняя таблица (имеет внешний ключ таблицы Т_Оператор). Ссылочная целостность для этой связи описана в таблице ниже.

Таблица 3 — Описание ссылочной целостности для связи «Т_Оператор Т_Заказ»

Отчёт по ссылочной целостности всех связей представлен в приложении D.

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

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

На основе данной информации становится возможным произвести построение логической модели проектируемой АИС с использованием CASE-средства, определенного в пункте 3.2.

Рисунок 12 — Логическая модель данных

Заключение

В данной работе была проанализирована деятельность производственно-диспетчерского отдела (ПДО) СКП ОАО «АВТОВАЗ». В качестве процесса автоматизации взята поставка деталей в соответствующее производство. Смоделированы существующие процессы в ПДО и выделены недостатки такие как:

· оформление заказа производится вручную,

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

Для проектирования системы был выбран объектный подход. Проектирование производилось на CASE-средстве Visual Paradigm.

Система реализуется в трёхзвенной архитектуре «клиент-сервер» и включает в себя компоненты: Web-сервер + PHP модуль, SQL-сервер, браузер клиента. Для проектирования был выбран RAD-подход. При проектировании системы определены внешние сущности и разработана диаграмма вариантов использования всей системы в целом. Из этой диаграммы разобраны два варианта использования «Формирование заказа на производство» и «Формирование графиков изготовления и отгрузки деталей». Для каждого из них построены диаграммы последовательности, определены модули, выполняющие определённые функции и описаны спецификации этих функций. Они представлены в приложениях. Также спроектирована диаграмма классов для реализации функционала системы.

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

Список используемой литературы

1. Хетагуров Я. А., Проектирование АСОИУ / Я. А. Хетагуров — М.: Высш. шк., 2006. — 223с.

2. Ларман К., Применение UML и шаблонов проектирования / К. Ларман — М.: Вильямс, 2002. — 624с.

3. Рябышева И. В. Сравнительный анализ подходов к проектированию ИС [Электронный ресурс]. — Режим доступа: http://www.ict.nsc.ru/ws/YM2004/8666/index.htm.

4. Visual Paradigm 6.1 Enterprise [Электронный ресурс]: [Официальный сайт Visual Paradigm]. — Режим доступа: www. visual-paradigm.com/product/sde/vs/editions/community.jsp.

5. Rational Rose [Электронный ресурс]: [Официальный сайт IBM]. — Режим доступа: www-01.ibm.com/software/awdtools/developer/rose.

6. Borland Together [Электронный ресурс]. — Режим доступа: www.interface.ru/fset.asp?Url=/borland/bt.htm

7. ArgoUML [Электронный ресурс]: [Официальный сайт ArgoUML]. — Режим доступа: argouml.tigris.org.

8. Netbeans UML Plugin [Электронный ресурс]: [Официальный сайт Netbeans]. — Режим доступа: netbeans.org/features/uml.

9. Eclipse Omondo Plugin [Электронный ресурс]: [Официальный сайт Visual Paradigm]. — Режим доступа: www. visual-paradigm.com/solution/eclipseuml.

10. Enterprise Architect [Электронный ресурс]. — Режим доступа: www.sparxsystems.com.

11. Обзор нотаций, используемых при построении диаграмм «сущность-связь» [Электронный ресурс]. — Режим доступа: http://pda.mstu.edu.ru/study/materials/zelenkov/ch₂_4.html.

Приложение A

П1 — спецификация метода searchSkladDetali () класса Operator

Приложение В

П2 — спецификация метода DetAkt класса AktOtgruz

Приложение С

Отчёт по ключам

Приложение D

Отчёт по ссылочной целостности