№ ванны
|
Число гидропаков
|
1
|
2
|
2
|
1
|
3
|
1
|
4
|
2
|
Каждый из гидропаков соединен с насосом, который перекачивает в ванну
смесь воды и краскошлама, и затем краскошлам флоккулируется в гидропаке. В
случае неисправности насоса гидропака дозирующие насосы флокулянта и коагулянта
и насосы кабин считаются неисправными и останавливаются.
Последним из рассматриваемых объектов будет краско-подготовительное
отделение (код оборудования 0610107440). Оборудование, находящееся в
краско-подготовительном отделении:
1. Циркуляционные емкости (общее число - 48);
2. Теплообменник охлаждения;
. Теплообменник подогрева;
Краско-подготовительное отделение используется для приведения прозрачного
и базового лака к условиям, необходимым для проведения покрасочных работ.
Циркуляционные емкости используются для приведения лака к необходимому
состоянию и последующей передачи в окрасочные камеры. Теплообменники охлаждения
и подогрева используются соответственно для приведения температуры лака к
заданной.
Рисунок 7 - Определение неисправностей в краско-подготовительном
отделении
Таким образом, основными параметрами, которые необходимы для последующей
обработки являются:
1. Питание контроллера электрошкафа (норма или ошибка);
2. Пожарная сигнализация (включена или выключена);
. Сбой насоса горячей воды;
. Сбой насоса охлажденной воды;
. Фактическая температура в емкости.
1. Информацию о произошедших ошибках можно получить только на пульте
управления конкретного оборудования. Следовательно, для каждого типа
оборудования должен быть предусмотрен свой оператор.
2. Информация о неисправностях нигде не сохраняется, поэтому
возникают сложности с ее статистической обработкой, выявлении наиболее часто
возникающих ошибок и проведении работ по их устранению и предотвращению.
Одним из способов решения выше указанных проблем является внедрение в
существующую технологию автоматизированной информационной системы. Основными
задачами, решаемыми новой системой будут:
1. Сбор информации о параметрах и неисправностях на оборудовании в цехе
окраски 44-1.
2. Хранение информации о неисправностях в базе данных.
. Проведение статистической обработки данных с целью выявления
наиболее часто возникающих неисправностей.
Предъявляемыми требованиями к проектируемой технологии будут:
. АИС должна обладать WEB-интерфейсом, доступным и понятным для пользователя.
. АИС должна реализовывать защиту от ошибочных действий
пользователя.
. АИС должна реализовывать репликацию БД.
. АИС должна быть кроссплатформенна с целью дальнейшего
использования в других предприятиях, подобных заказчику.
. АИС должна иметь систему разграничения прав доступа.
. АИС должна иметь функционал, в полной мере заменяющий текущую систему
обработки данных, а также предоставлять дополнительные возможности, описанные
выше.
Мною было принято решение разработки собственной АИС в рамках цеха
окраски 44-1, удовлетворяющей требованиям рассматриваемого подразделения. Выбор
и обоснование архитектуры информационной системы, на основе определенных
критериев оценки будет рассмотрен в следующем параграфе.
1.3 Обоснование архитектуры информационной системы
Для проектирования АИС необходимо определить архитектуру, которая будет
использоваться при ее построении. Критериями, которые будут определять выбор,
будут являться:
1. Стоимость - должна быть как можно меньше, чтобы повысить
экономическую эффективность проекта в целом;
2. Отказоустойчивость - система должна продолжать работу при отказе
некоторых ее компонентов;
. Масштабируемость - способность системы справляться с увеличением
рабочей нагрузки (увеличивать свою производительность) при добавлении новых
ресурсов;
. Распространенность - данный критерий очень важен, так как если
технология распространена, ей легче оказывать техническую поддержку,
модернизировать и т.д.;
. Производительность - критерий, определяющий насколько хорошо,
система будет справляться с высокими нагрузками.
На основании проведенного анализа рассматриваемой области мы можем представить,
как будет выглядеть архитектура информационной системы. Архитектура в
укрупненном виде представлена на рисунке 8.
Рисунок 8 - архитектура проектируемой информационной системы (укрупненный
вариант)
Как видно из представленного выше рисунка, архитектура информационной
системы будет состоять из 5 основных компонентов:
1. Оборудование цеха окраски 44-1;
2. Внешняя система, позволяющая получать сведения о параметрах и
неисправностях оборудования;
. Сервер базы данных, на котором будет храниться вся информация о
параметрах на оборудовании, а так же все полученные сведения по произошедшим
неисправностям;
. Сервер приложений, на котором будет производиться статистическая
обработка полученных параметров и неисправностей, определение наиболее опасных
проблем для их устранения.
5. Web-сервер, позволяющий реализовать работу сервера приложений на основе web-интерфейса.
Выбранный нами тип архитектуры является некоторой разновидностью
трехуровневой архитектуры.
Таким образом, в рамках данной главы мы провели анализ предметной
области, определили основные бизнес-процессы, протекающие на производстве,
выявили проблемы, связанные с текущим состоянием системы. На основании
изложенных проблем было принято решение о модернизации системы, и первым шагом
стала разработка архитектуры будущей информационной системы.
неисправность
автоматизированный информационный данные
2. Проектирование ИС
2.1 Обоснование технологии проектирования
В настоящее время используется большое количество подходов, которые
позволяют, создавать модели бизнес-процессов предприятий. Особенно выделяют:
структурный (функциональный), объектно-ориентированный, отдельно выделяется
методология ARIS. Описание каждого подхода и его нотаций описано в источнике
[3].
При проектировании данной системы будет использоваться
объектно-ориентированный подход. Это объясняется тем, что нотация данного
подхода (UML) позволяет достаточно полно и
наглядно описать предметную область и позволяет легко изменять проект (при
изменении одного объекта или процесса не надо изменять все остальные, как,
например, в структурном подходе). Также UML является достаточным для проектирования данной
системы, следовательно, методология ARIS, включающая UML и другие
методологии, будет избыточна.
Существуют следующие средства для проектирования с помощью UML:
¾ Visual Paradigm 6.1 Enterprise [4];
¾ Rational Rose [5];
¾ Borland Together [6];
¾ ArgoUML [7];
¾ Netbeans UML Plugin [8];
¾ Eclipse Omondo Plugin [9];
¾ Enterprise Architect [10].
Для выбора наиболее подходящего будут использоваться следующие критерии:
. Возможность генерации программного кода на языке PHP.
. Возможность производить реверс кода.
. Поддержка ОС Windows.
. Стоимость приобретения.
. Опыт успешного использования (отзывы).
. Простота освоения и использования.
Все критерии кроме стоимостного оценивается следующими балами:
- не удовлетворят требованию
- частично удовлетворяет требованию
- полностью удовлетворяет требованию
Стоимостной критерий является наиболее важным, поэтому его баллы выше:
- высокая стоимость;
- средняя стоимость;
- бесплатно
Таблица
2. Исходные данные для выбора CASE-средства
|
Visual Paradigm 6.1 Enterprise
|
Rational Rose
|
Borland Together
|
ArgoUML
|
Netbeans UML Plugin
|
Eclipse Omondo Plugin
|
Enterprise Architect
|
Возможность генерации программного кода на языке PHP
|
10
|
0
|
10
|
5
|
0
|
10
|
Возможность производить реверс кода
|
10
|
0
|
0
|
10
|
0
|
10
|
10
|
Поддержка ОС Windows
|
10
|
10
|
10
|
10
|
10
|
10
|
10
|
Стоимость приобретения
|
20
|
0
|
10
|
20
|
20
|
10
|
10
|
Опыт успешного использования (отзывы)
|
10
|
10
|
10
|
10
|
0
|
5
|
10
|
Простота освоения и использования.
|
10
|
5
|
10
|
10
|
10
|
5
|
10
|
ИТОГ:
|
70
|
25
|
40
|
70
|
45
|
40
|
60
|
Анализ показал, что наиболее подходящие для проектирования CASE-средства
это Visual Paradigm и Enterprise Architect. При проектировании будет
использоваться Visual Paradigm, так как имеется опыт работы в данной программе.
Для проектирования системы будет использоваться методология RAD. Согласно
этой методологии результатом фазы проектирования должны быть:
¾ общая информационная модель системы;
¾ функциональные модели системы в целом и подсистем,
реализуемых отдельными командами разработчиков;
¾ точно определенные с помощью CASE-средства интерфейсы между
автономно разрабатываемыми подсистемами;
¾ построенные прототипы экранов, отчетов, диалогов.
В итоге должна получиться схема базы данных, удовлетворяющая требованиям
новой технологии и включающая все необходимые таблицы, для реализации заданного
функционала.
Далее в ходе разработки проекта АИС необходимо выполнить следующие шаги:
1. Разработка модели информационной системы
2. Разработка концептуальной модели БД.
. Построение логической модели БД.
. Оптимизация структуры таблиц и связей модели БД.
.2 Разработка модели ИС
В ходе проектирования ИС необходимо построить UML диаграммы, позволяющие описать функционирование и
реализацию этой системы.
Опишем диаграмму вариантов использования (Use case diagram).
Рисунок 10 - Диаграмма вариантов использования
Первым шагом будет построение UML-диаграммы, отражающей последовательности процессов при получении
сведений о параметрах оборудования и неисправностях, возникающих в процессе его
работы.
Из представленного выше рисунка видно как сведения о неисправностях
попадают к конечному пользователю (оператору информационной системы). Оператор
получает сведения, прошедшие статистическую обработку и, следовательно, может
на основе полученных результатов делать выводы и принимать определенные
решения.
Следующим шагом проектирования будет определение принципов работы
оператора с информационной системой.
Рисунок 12 - Диаграмма последовательности работы оператора с информационной
системой
Таким образом, мы видим, что оператор получает возможность работы с
информационной системой, только если успешно прошел аутентификацию. Система
аутентификации позволит нам не только не допустить доступ к информационной
системе посторонних лиц, но и распределить рабочее пространство между
операторами, а, следовательно, лучше осуществлять контроль их работы.
Реализация функциональной части проектируемой АИС будет реализована на
языке Java. Приведем диаграмму классов,
описывающую иерархию классов, реализуемые ими методы, а также поля, содержащие
разного рода информацию, обрабатываемую в системе.
Рисунок 13 - Диаграмма классов для проектируемой АИС сервера приложений
Ключевым классом является класс Plant. Данный класс описывает конкретное оборудование в цехе окраски 44-1.
Соответственно, он имеет собственные параметры, а также принимает объекты
классов Parametr (отвечает за текущее состояние
оборудования) и Error (содержит
ошибки, возникшие на данном оборудовании).
Класс Report позволяет вывести готовый отчет по
оборудованию, объект которого был передан на вход метода в качестве параметра.
Поскольку работа в системе подразумевает постоянную работу с БД, то
необходимым условием является создание пула подключений к БД с целью
оптимальной работы пользователей, отсутствия конфликта при работе с одними
записями. Для этих целей создается отдельный класс DBConnectionPool, который создает отдельное
подключение к БД по требованию, добавляя его в список текущих подключений (это
позволяет в следующий раз пользователю не создавать новое подключение, а
использовать уже созданное).
Помимо базовых классов, реализующих работу пользователя с системой,
существует отдельный пакет с классом, реализующим работу сервлетов проектируемой
АИС. Данные сервлеты реализуют основную аналитическую часть АИС.
Для созданного объекта класса Plant становится возможным определение ошибок и параметров работы
оборудования, используя следующие методы:
1. Метод, определяющий существующие ошибки на оборудовании createError с атрибутами названия, статуса и
значения. Спецификация приведена в Приложении №5.
2. Метод, определяющий текущие параметры оборудования, по данным
приходящим с внешней системы createParametr. Спецификация приведена в Приложении №6.
3. Проектирование базы данных ИС
.1 Инфологическое (концептуальное) проектирование
На основе моделирования предметной области были выявлены основные
сущности проектируемой АИС. Опишем их взаимодействие с помощью нотации Чена на
рисунке 14.
Рисунок 14 - Общая инфологическая модель проектируемой системы
Основной сущностью является «Оборудование». Через данную сущность
взаимодействуют остальные сущности, а именно:
1. Оператор.
2. Внешняя система.
. Параметр (является зависимой сущностью, то есть существует
только вместе с сущностью «Оборудование»).
. Ошибка (является зависимой сущностью, то есть существует только
вместе с сущностью «Оборудование»).
Связь сущностей «Оборудование - Внешняя система» в соответствии с
диаграммой вариантов использования, представленной на рисунке 10, описывает
функцию внешней системы получать информацию о текущем состоянии оборудования.
Связь сущностей «Внешняя система - Параметр» в соответствии с диаграммой
вариантов использования, представленной на рисунке 10, описывает функцию
внешней системы выделять из полученных сведений по оборудованию и впоследствии
сохранять параметры его текущей работы.
Связь сущностей «Внешняя система - Ошибка» в соответствии с диаграммой
вариантов использования, представленной на рисунке 10, описывает функцию
внешней системы выделять из полученных сведений по оборудованию ошибки (если
они есть) и сохранять их в базе данных.
Связь сущностей «Оператор - Оборудование» в соответствии с диаграммой
вариантов использования, представленной на рисунке 10, описывает функцию
запроса сведений по конкретному оборудованию оператором.
Связь сущностей «Оператор - Параметр» в соответствии с диаграммой
вариантов использования, представленной на рисунке 10, описывает функцию получения
оператором сведений по значениям параметров, запрошенного оборудования.
Связь сущностей «Оператор - Ошибка» в соответствии с диаграммой вариантов
использования, представленной на рисунке 10, описывает функцию получения
оператором сведений по имеющимся ошибкам на конкретном оборудовании.
Каждая сущность имеет свой набор атрибутов, описывающих ее.
Расширенная инфологическая модель приведена в Приложении 7.
3.2 Обоснование логической модели БД
На сегодняшний день существует большое число разных видов моделей данных,
обрабатываемых в информационной системе. На сегодняшний день основными моделями
данных являются:
иерархическая модель - состоит из упорядоченного набора экземпляров в
виде дерева без множественного наследования;
сетевая модель - состоит из упорядоченного набора экземпляров в виде
дерева с множественным наследованием;
реляционная модель - состоит из отношений и элементов отношений (кортеж);
объектная модель - состоит из данных, оформленных в виде моделей объектов
произвольного типа.
Оценивание будет выполняться по 3-бальной шкале, где наивысший бал будет
означать удовлетворение вида модели выдвинутому критерию, а наименьший - не
удовлетворение. Основными критериями будут являться:
простота физической реализации;
личный опыт работы с моделью;
«понятность» для пользователя.
Сведем сравнительный анализ моделей данных в таблицу.
Таблица 4 - Критическая оценка моделей данных проектируемой АИС
Критерий оценки
|
Иерархическая
|
Сетевая
|
Реляционная
|
Объектная
|
Простота физической реализации
|
2
|
2
|
3
|
3
|
Личный опыт работы
|
1
|
1
|
3
|
1
|
«Понятность» для пользователя
|
3
|
3
|
2
|
1
|
ИТОГО
|
6
|
6
|
8
|
5
|
В ходе проведенного сравнительного анализа мною была выбрана реляционная
модель представления данных.
возможность генерирования физической модели БД на основе имеющейся
логической модели;
бесплатное распространение программного продукта;
личный опыт работы с программным продуктом.
Наконец, определив тип модели данных, а также CASE-средство, с помощью которого данная модель будет
реализовываться, можно приступить к построению самой модели БД.
3.3 Построение логической модели БД
В пункте 3.1 были определены следующие сущности модели данных
информационной системы:
1. Оборудование;
2. Оператор;
. Внешняя система;
. Параметр;
. Ошибка.
Кроме этого в данном пункте был определен набор основных атрибутов данных
сущностей.
Каждая сущность имеет свой уникальный идентификатор, который позволяет
получить доступ к любой произвольной записи таблицы. Данный идентификатор
является первичным ключом (простой ключ) для соответствующей сущности.
Каждая сущность связанна с остальными, при этом каждая связь имеет свои
свойства: «Оборудование - тип оборудования» - один ко многим, «Тип оборудования
- функция» - один ко многим, «Функция - параметр» - один ко многим,
«Оборудование - параметр» - многое ко многим, «Оператор - оборудование» -
многое ко многим.
Ссылочная целостность и отчет по ключам таблиц представлены в Приложении
8 и 9 соответственно.
На основе данной информации становится возможным произвести построение
логической модели проектируемой АИС с использованием CASE-средства, определенного в пункте 3.2.
Рисунок 15 - Логическая модель информационной системы
Заключение
В данном курсовом проекте был рассмотрен цех окраски 44-1
сборочно-кузовного производства ОАО «АвтоВАЗ».
В ходе анализа предметной области был установлен ряд недостатков
существующей системы обработки данных, на основе которых было принято решение о
проектировании собственной АИС. Далее были определены требования к
проектируемой системе, выбраны CASE-средства,
с помощью которых будет осуществлен процесс ее проектирования и разработки. Для
проектирования АИС была выбрана платформа JEE (JDBC, Servlets, JSP, EJB).
После этого были смоделированы UML-диаграммы, описывающие бизнес процессы, а также диаграмма классов, на
основе которой были определены основные сущности системы, их атрибуты. Для их
визуального отображения была использована нотация Чена.
Наконец, было проведено описание сущностей системы, свойства их связей,
нормализация, а также наличие первичных, вторичных и альтернативных ключей, что
позволило построить логическую модель БД проектируемой информационной системы.
Список использованной литературы
1. Роберт
Дж. Мюллер. Базы данных и UML /
Мюллер Дж. Роберт - М.: ЛОРИ, 2002. - 420 с.
2. Лешек
А. Мацяшек. Разработка ИС с использованием UML / Мацяшек Лешек А. - М.: Вильямс, 2002. - 432 с.
. Хетагуров
Я.А. Проектирование АСОиУ / Я. А. Хетагуров - М.: Высшая школа, 2006. - 224 с.
. Вязовик
Н.А. Программирование на Java:
Учебный курс. / Н.А. Вязовик- М.: Craftway Computers, 2003. -
592с.
. Дейтел
Х.М. Технологии программирования на Java 2, корпоративные системы, сервлеты, JSP, Web-сервисы:
Учебный курс. / Х.М. Дейтел- М.: Бином-пресс, 2003. - 672с.: ил.
. Кузнецов
С.Д. Базы данных. Модели и языки: Учебный курс. / С. Д. Кузнецов- М.:
Бином-пресс, 2008. - 692с.
. Буди
Курняван. Создание web-приложений на языке Java с помощью сервлетов, JSP и EJB:
Руководство для разработчиков масштабируемых приложений J2EE. / Курняван Буди -
М.: ЛОРИ, 2008. - 880с.
Приложения
Приложение №1 (Определение неисправностей в блоке вентиляторов)
Приложение №2 (Предварительный нагрев воздуха)
Приложение №3 (Осушение воздуха)
Приложение №4 (Увлажнение приточного воздуха)
Приложение №5 (Спецификация метода createError())
Приложение №6 (Спецификация метода createParametr())
Приложение №7 (Расширенная инфологическая модель проектируемой системы)