Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Пермский национальный исследовательский политехнический университете (ПНИПУ)

Факультет: Электротехнический (ЭТФ)

Направление: 230100.62 - Информатика и вычислительная техника (ИВТ)

Профиль: Автоматизированные системы обработки информации и управления (АСУб)

Кафедра информационных технологий и автоматизированных систем (ИТАС)

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

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

На тему: Проектирование автоматизированной системы учета запчастей и неисправностей в цехе по обслуживанию и ремонту устройств КТСМ ОАО «РЖД»

Студент

Боярских А.С.

Руководитель

Лясин В.Н.

Пермь 2014

Министерство образования и науки Российской Федерации

Пермский национальный исследовательский политехнический университет (ПНИПУ)

Факультет: Электротехнический (ЭТФ)

Направление: 230100.62 - Информатика и вычислительная техника (ИВТ)

Профиль: Автоматизированные системы обработки информации и управления (АСУб)

Кафедра информационных технологий и автоматизированных систем (ИТАС)

Зав. кафедрой: д.э.н., проф.

Файзрахманов Р.А._________________

«____»_____________________2013 г.

ЗАДАНИЕ

на выполнение выпускной работы бакалавра

Ф, И.О. Боярских Антон Сергеевич

Факультет: Электротехнический

Группа: АСУбзу - 10

Начало выполнения работы: 25.11.13

Контрольные сроки просмотра работы кафедрой 11.01.14, 17.01.14, 20.01.14

Защита работы на заседании ГЭК 23.01.14

1.Наименование темы:

Проектирование автоматизированной системы учета запчастей и неисправностей в цехе по обслуживанию и ремонту устройств КТСМ ОАО «РЖД».

2.Исходные данные к работе: задача автоматизации деятельности цеха по обслуживанию и ремонту устройств КТСМ.

3.Содержание пояснительной записки:

а) Основная часть:

Анализ деятельности предприятия ОАО «РЖД» и цеха по обслуживанию и ремонту устройств КТСМ.

Описание существующей системы.

Обоснование необходимости автоматизации учета.

Требования к системе автоматизированного учета.

Требования к аппаратуре и программным средствам.

б) Специальная часть:

Анализ известных подходов к решению проблемы.

Описание функциональной модели деятельности объекта.

Разработка функциональной модели желаемой системы.

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

Экранные формы.

Выходные документы.

Разработка технического задания на информационную систему.

4.Перечень графического материала:

Схема «Как есть» - 2 страницы.

Схема «Как должно быть» - 2 страницы.

Логическая модель базы данных - 1 страница.

Экранные формы - 1 страница.

5.Дополнительные указания:

Функциональные схемы спроектировать в BPwin.

Базу данных спроектировать в PowerDesigner.

Интерфейс спроектировать в MS Visual Studio (C#).

Спроектированная база данных должна быть совместима с SQLite

6.Основная литература:

- Маклаков С.В. BPWin, ERWin. CASE - средства разработки информационных систем. - М.: Диалог - МИФИ , 1999.

- В.П. Гладков, Проектирование баз данных, - Пермь: изд. ПГТУ, 2007.

Руководитель ВКР:___________________________________________ (доцент Лясин В.Н.)

Консультант_________________________________ (ст.электромеханик Ладейщиков В.Н.)

Задание получил: ________________________________________________ (Боярских А.С.)

КАЛЕНДАРНЫЙ ГРАФИК ВЫПОЛНЕНИЯ

ВЫПУСКНОЙ КВАЛИФИКАЦИОННОЙ РАБОТЫ

Наименование этапа	Объем (в%)	Начало	Конец	Примечание
1. Сбор и анализ исходных данных, постановка задачи	10	25.11.2013	29.11.2013
2. Анализ и выбор методов и средств решения задачи	20	1.12.2013	10.12.2013
3. Разработка теоретической части; методики решения	10	15.12.2013	20.12.2013
4. Выбор и разработка средств решения задачи	40	20.12.2013	9.01.2014
5. Разработка графической части	10	9.01.2014	14.01.2014
6. Оформление пояснительной записки	10	14.01.2014	18.01.2014
7. Представление работы на проверку и отзыв руководителя квалификационной работы		20.01.2014	20.01.2014
8. Представление работы заведующему кафедрой		21.01.2014	21.01.2014
9. Предоставление на рецензию		22.01.2014	22.01.2014
10. Защита на заседании ГЭК		23.01.2014	23.01.2014

Руководитель ВКР: __________________________________________ (доцент Лясин В.Н.)

Задание получил: _________ (Боярских А.С.)

«_________» _________________________________ 2013 г.

Реферат

Пояснительная записка: 80 страниц, 14 рисунков, 20 таблиц, 12 источников, 6 приложений.

ЦОРУ КТСМ, ТЕХКАРТОЧКА, ШЧ-3.

Объектом исследования является цех по обслуживанию и ремонту устройств КТСМ ОАО «РЖД» Кунгурская дистанция СЦБ.

Целью данной работы является проектирование автоматизированной системы для выполнения функций цеха по обслуживанию и ремонту устройств КТСМ ОАО «РЖД» Кунгурская дистанция СЦБ.

Функциональные схемы реализованы в программе BPwin 4.0.

База данных спроектирована в программе Power Designer 15.3.

Интерфейс спроектирован в визуальной среде проектирования Visual Studio (C#).

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

Содержание

Введение

1. Общая часть

1.1 Проектирование автоматизированных информационных систем

1.2 Анализ деятельности предприятия ОАО «РЖД» ШЧ-3 и цеха по обслуживанию и ремонту устройств КТСМ

1.3 Описание существующей системы учета

1.4 Обоснование необходимости автоматизации учета

1.5 Требования к системе автоматизированного учета

1.6 Требования к аппаратуре и программным средствам

2. Специальная часть

2.1 Анализ известных подходов к решению проблемы

2.2 Описание функциональной модели деятельности объекта

2.3 Разработка функциональной модели желаемой системы

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

2.5 Экранные формы

2.6 Выходные документы

2.7 Разработка технического задания на информационную систему

Заключение

Список литературы

Приложения

Список сокращений

Введение

Актуальность. В эпоху информационных технологий трудно представить компанию или фирму, в которой нет автоматизированных рабочих мест. Например, взять обычного предпринимателя, в распоряжении которого находится магазин и небольшой склад товаров. Даже у него, с большой вероятностью есть автоматизированное рабочее место. К примеру, рабочее место бухгалтера оснащено системой бухучета - 1С - это и есть АРМ. Что уж тут говорить про большие предприятия, такие, как ОАО «РЖД». На предприятии, с тысячами рабочих мест, не найдет объект для автоматизации только ленивый или бездарный.

В качестве объекта исследования выбрано рабочее место сотрудников цеха по обслуживанию и ремонту устройств КТСМ ШЧ-3. Цех занимается поддержанием работоспособности оборудования (ремонт, обслуживание) отвечающего за безопасность движения поездов (обнаружение нагретых букс коленных пар вагонов). Данное оборудование КТСМ замеряет температуру нагрева букс во время движения поездов. В результате ремонта, персонал цеха расходует определенные запчасти. Потом заказывает их снова. Таким образом в цехе идет большое движение запчастей. Много времени уходит на поиски ответов, на вопросы вроде: «Сколько осталось таких-то запчастей на складе?», «Есть - ли вообще определенная запчасть на складе?», «Когда, что заказывать?» В результате могут возникать экстренные ситуации которые могут привести к задержке поездов, а это миллионные убытки.

Целью данной работы является проектирование автоматизированной системы для выполнения функций учета запчастей и неисправностей цеха по обслуживанию и ремонту устройств КТСМ ОАО «РЖД» Кунгурская дистанция СЦБ. Т.к. в процессе списания запчастей необходимо указывать причину списания и оборудование, на которое производилось списание, дополнительно будет реализована задача автоматизированного учета выполненных работ персоналом цеха по обслуживанию и ремонту устройств КТСМ.

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

- дать общую характеристику объекта автоматизации. Изучить организационную и функциональную структуру предприятия и цеха по обслуживанию устройств КТСМ;

- изучить алгоритм функционирования ЦОРУ КТСМ. Разработать функциональную модель существующей системы;

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

- разработать желаемую функциональную модель системы;

- разработать инфологическую модель данных;

- разработать техническое задание;

разработать интерфейс будущей системы с программной реализацией (без реализации функциональной части).

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

Данная работа послужить готовым проектом для разработки автоматизированной системы и внедрения её на рабочем месте персонала цеха по обслуживанию устройств КТСМ и всей структуры ОАО «РЖД».

1. Общая часть

1.1 Проектирование автоматизированных информационных систем

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

Проектирование включает следующие стадии:

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

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

3. Стадия ввода в эксплуатацию, включающая опытную эксплуатацию и приемо-сдаточные испытания системы. Эти стадии позволяют выявить недостатки и уточнить технические решения.

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

В процессе работы необходимо исследовать работу цеха по обслуживанию и ремонту устройств КТСМ, являющимся одним из структурных подразделений ШЧ-3 ОАО «РЖД». Изучить информацию, поступающую в цех, методы ее обработки, проанализировать полученные данные. Проанализировать требуемые отчеты и сведения. Разработать систему учета запчастей, позволяющую быстро и эффективно осуществлять, как их списание, так и занесение в систему. Разработать базу данных, где будет храниться вся исходная информация, на основании которой можно будет формировать отчетные формы, пользоваться справочной информацией и анализировать деятельность цеха в целом. Реализовать пользовательский интерфейс для удобства ввода информации, использования справочников, просмотра отчетов.

1.2 Анализ деятельности предприятия ОАО «РЖД» ШЧ-3 и цеха по обслуживанию и ремонту устройств КТСМ

Общая характеристика предприятия

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

Структурная схема предприятия

Управление дистанцией сигнализации и связи осуществляет аппарат управления. Численность работников аппарата определяется с учётом штатных нормативов в зависимости от группы дистанции, контингента оперативно-производственного штата и местных условий. К руководителям дистанции относятся начальник дистанции (ШЧ), главный инженер (ШЧГ) и заместители начальника дистанции. Функции управления - это часть управленческой деятельности, включающая в себя совокупность решений, действий или процессов, объединенных общностью осуществляемых задач по управлению производством. Функции управления зависят от специфики конкретной дистанции: её размеров и конфигурации, технической оснащённости, территориальной разобщённости подразделений, характера производственных процессов и т.п.

Описание деятельности цеха по обслуживанию и ремонту устройств КТСМ

Рабочий персонал цеха состоит из 11 специалистов: старший электромеханик и 10 электромехаников . Главная задача рабочего персонала: не допускать неисправностей оборудования, вовремя выполнять график работ по обслуживанию устройств КТСМ.

Рабочий режим цеха: с 8:00 до 17:00. Суббота, воскресение: выходные дни (кроме дежурства). Так же существует суточное дежурство на дому согласно графика дежурств.

Цех состоит из кабинета и склада общая площадь которых занимает 25 квадратных метров. Так же 13 помещений (модулей) вагонного типа (в которых установлен КТСМ) каждый площадью 15 квадратных метров. Модули расположены на протяжении Шаля - Пермь 2 через каждые 35 километров. В кабинете цеха располагается оборудование и приборы, предназначенные для эффективной работы цеха: вольтметр, мегомметр, омметр, 2 компьютера, паяльная станция и другое. Так же на каждой установке есть набор инструментов, некоторые запчасти и прибор измерения напряжения. На складе хранятся все необходимые, ранее заказанные запасные части для оборудования. Все запчасти рассортированы по типу.

Деятельность цеха заключается в следующем. Комплекс КТСМ-02 является системой автоматического контроля технического состояния (диагностики) подвижного состава, состоящей из подсистем обнаружения неисправностей буксовых узлов, колесных пар, тормозного и автосцепного оборудования, волочащихся деталей, нарушения габарита и др. Каждая единица оборудования состоит из взаимосвязанных механических и электронных комплектующих (частей). Не редко эти составляющие могут выходить из строя и вызывать разного рода неисправности, сбои в работе. Для ремонта, т.е. устранения неисправности могут потребоваться новые детали, взамен вышедшим из строя. Задача работников цеха по обслуживанию и ремонту устройств КТСМ, в первую очередь, по мере возможности -- предотвратить возникновение неисправности! В противном случае - найти и устранить неисправность. После произведенной работы, необходимо сделать соответствующие отметки о выполненной работе в техкарточке и списать запчасти с учета, если для устранения неполадки были израсходованы новые.

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

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

1.3 Описание существующей системы учета

Как таковой автоматизированной системы в цехе по обслуживанию и ремонту устройств КТСМ не существует. Вся автоматизация рабочего места на данный момент сводится к ручному вводу данных в электронную таблицу, записям в журнале и уменьшения количества запасных частей на складе, посредством вычета введенного количества израсходованных деталей рядом с наименованием детали. Основное программное обеспечение используемое на рабочем месте при текущей системе учета Microsoft Office 2003, в частности это Word (текстовый редактор) и Exel (редактор электронных таблиц). Рабочий персонал цеха по обслуживанию и ремонту устройств КТСМ в процессе работы расходует запчасти и списывает их с учета (файл электронных таблиц), отмечает неисправности оборудования в техкарточках (текстовые файлы со списками неисправностей). Старший электромеханик, просматривает текущие записи о произведенных работах за неделю (через меню пуск -- последние документы смотрит последние открытые техкарточки), анализирует соотношение количества оставшихся запчастей к количеству израсходованных за период времени и на основании выводов делает заявку на необходимое количество запчастей.

Когда старший электромеханик находится в отпуске или на больничном он назначает заместителя (электромеханика). Соответственно, обязанности по заявкам запчастей перекладываются на его плечи. Но, т. к. электромеханик постоянно занят своей работой и всего лишь совмещает обязанности старшего электромеханика, он не может отследить полное движение запчастей и вполне может упустить важную деталь из учета. Выходя на работу, старший электромеханик анализирует все техкарточки на соответствие неисправностей, повлекших за собой замену запчастей и заявок за эти запчасти. Если запчасть списана, а заявки нет, он заказывает ее.

1.4 Обоснование необходимости автоматизации учета

Существующая -- почти ручная система учета очень не эффективна по ряду многих причин. Некоторые из них.

- Фиксация неисправности и списание запчасти происходит в два длительных этапа. Первый -- добавление записи о неисправности в текстовый файл -- техкарточку. Второй -- списание запчасти в файле электронных таблиц «Учет». Данная процедура также занимает много времени. Не эффективна. Постоянно приходится открывать разные файлы. Искать по длинному списку запчастей в файле электронных таблиц «Учет».

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

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

- Нет реализации выборки данных о закончившихся, заканчивающихся запчастях в учете, без учета визуальной.

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

1.5 Требования к системе автоматизированного учета

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

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

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

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

3. Гибкость - это означает, что система должна быть реализована, так, чтобы в дальнейшем она могла приспосабливаться к возможным изменениям, благодаря стандартизации элементов системы.

4. Мобильность - система должна быть легко переносимой с одного компьютера на другой.

1.6 Требования к аппаратуре и программным средствам

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

1. Тактовая частота процессора не менее 1800 МГц.

2. Оперативной памяти не менее 1024 Мб.

3. 40 Гб и выше свободного места на жестком диске.

4. Разрешение экрана не менее 1024х768 точек.

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

1. Операционная система семейства Microsoft Windows XP / Windows Vista / Windows 7 / Windows 8.

2. Пакет программ Microsoft Office 2003 / Office 2007 / Office 2010.

2. Специальная часть

2.1 Анализ известных подходов к решению проблемы

Программное обеспечение современного рынка

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

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

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

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

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

Еще одна из хороших программ, на мой взгляд, оказалась «Программа складского учета движения товаров КЛАД-Перл». Она предназначена для учета движения товаров на предприятиях малого и среднего бизнеса. В зависимости от настроек и типа базы данных, программа может использоваться для складского учета на предприятиях следующих типов:

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

- магазины, торговые точки;

- строительные организации;

- салоны сотовой связи;

- склады и организации складского типа;

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

Программа складского учета «КЛАД-Перл» позволяет:

- автоматизировать ведение электронных документов для всех основных операций с товаром (приход, переброска, списание, инвентаризация;

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

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

- вести не только коллективную материальную ответственность в салонах красоты, но и индивидуальную;

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

- формировать разнообразные отчеты за произвольный период в любой выбранной из справочника валюте;

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

Складская программа «КЛАД-Перл» обеспечивает полный контроль товарооборота, начиная с поступления товара на склад и заканчивая списанием (или продажей) товара как целиком, так и частями в виде ингредиентов. Программа складского учета «КЛАД-Перл» позволяет автоматизировать учет движения товаров между подразделениями предприятия, поставщиками и покупателями; наладить контроль над финансами предприятия; упростить бухгалтерский учет; производить анализ прибыльности продаж и многое другое.

Таблица 2.1 Анализ соответствующих требований к возможностям программ современного рынка

	«1С» Склад	КЛАД - Перл	Собственное решение
Эффективность	+	+	+
Гибкость	+	-	+
Мобильность	-	-	+
Устойчивость	+	+	+
Простота использования	-	+	+
Стоимость	-	-	+

Средства для разработки автоматизированной системы

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

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

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

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

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

В настоящее время на практике количество CASE-средств, поддерживающих объектно-ориентированный подход, невелико по сравнению с поддерживающими структурный подход. В том числе, диаграммы, отражающие специфику объектно-ориентированного подхода (диаграммы классов, объектов и т.д.), гораздо менее наглядны и плохо понимаемы непрофессионалами. Примерами объектно-ориентированных CASE-средств являются: Rational Rose фирмы Rational Software и Paradigm Plus фирмы Computer Associates, предназначенные для автоматизации этапов анализа и проектирования ПО.

Основное различие между традиционными структурными методологиями проектирования и более новыми объектно-ориентированными методологиями находится в их первичном фокусировании: Структурные методы проектирования фокусируются на функциях системы: "что она делает". Объектно-ориентированные методы фокусируются на данных (объектах) системы: "что делается с...". Объектная ориентация может предоставить инструментальные средства, обеспечивающие более высокое качество программного обеспечения.

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

Современные CASE-средства, поддерживающие структурный подход, охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО. На сегодняшний день российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами: Vantage Team Builder (Westmount I-CASE), PowerDesigner, Silverrun, BPwin, S-Designor, CASE.Аналитик.

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

PowerDesigner дает возможность управления изменениями на этапе проектирования, предлагает технику управления метаданными и содержит уникальную технологию анализа взаимосвязей моделей (технология impact analysis). Одновременно с поддержкой ведущих техник моделирования и управления метаданными, PowerDesigner также позволяет работать с моделями любых типов в единой интегрированной среде, а репозиторий метаданных PowerDesigner помогает наладить слаженное взаимодействие между всеми заинтересованными лицами компании, что обеспечивает более быстрый отклик на изменения в существующей бизнес - среде. [6]

PowerDesigner поддерживает следующие технологии моделирования.

Моделирование данных: концептуальная, логическая и физическая модели данных, и расширение для проектирования хранилищ данных, основанное на IE (Information Engineering) методологии или нотации IDEF 1/x.

Моделирование приложений: все диаграммы UML и управление реализацией персистентных объектов за счет расширенной возможности описания OR-отображений (Object/Relational mapping). Техники моделирования с использованием XML и связь таких моделей с UML и моделями данных.

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

Моделирование Архитектуры предприятия: моделирование архитектуры предприятия, - от бизнес целей до реализации, с использованием уникальной технологии соединения и синхронизации (Link and Synch). Это позволяет избавиться от лишней информации и обеспечивает прозрачность описания, что увеличивает конкурентоспособность бизнеса, повысив скорость реагирования на изменения в экономике, технологиях и законодательстве.

Модели PowerDesigner полностью интегрированы: используя уникальную технологию соединения и синхронизации (Link and Synch), PowerDesigner интегрирует метаданные между всеми типами моделей.

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

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

Открытая поддержка всех основных платформ: Более 60 СУБД, ведущие платформы для разработки приложений, такие как Java J2EE, Microsoft.NET, Web Services и PowerBuilder, а также языки исполнения процессов, такие как ebXML и BPEL4WS.

Преимущества PowerDesigner [11].

Продуктивность - повышение эффективности за счет совместной работы бизнеса и IT.

Открытость - открытая поддержка различных гетерогенных сред разработки.

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

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

Наличие инструментов анализа - повышает гибкость и эффективность бизнеса за счет наличия технологии Link & Sync, обеспечивающей полноценный анализ влияния изменений.

В качестве СУБД выбран SQLite. Выбор данной библиотеки обоснован рядом причин[12].

Пожелание заказчика.

Бесплатное распространение библиотеки.

Отсутствие необходимости покупки дополнительных программных средств.

Переносимость базы данных.

SQLite -- легковесная встраиваемая реляционная база данных. Исходный код библиотеки передан в общественное достояние. В 2005 году проект получил награду Google-O'Reilly Open Source Awards.

Слово «встраиваемый» означает, что SQLite не использует парадигму клиент-сервер, то есть движок SQLite не является отдельно работающим процессом, с которым взаимодействует программа, а предоставляет библиотеку, с которой программа компонуется и движок становится составной частью программы. Таким образом, в качестве протокола обмена используются вызовы функций (API) библиотеки SQLite. Такой подход уменьшает накладные расходы, время отклика и упрощает программу. SQLite хранит всю базу данных (включая определения, таблицы, индексы и данные) в единственном стандартном файле на том компьютере, на котором исполняется программа. Простота реализации достигается за счёт того, что перед началом исполнения транзакции записи весь файл, хранящий базу данных, блокируется.

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

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

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

Сама библиотека SQLite написана на C; существует большое количество привязок к другим языкам программирования, в том числе Delphi, C++, Java, C#, Perl, PHP, Tcl (средства для работы с Tcl включены в комплект поставки SQLite), Ruby, Haskell, Scheme, Smalltalk, Lua и Parser, а также ко многим другим. Полный список существующих средств размещён на странице проекта

Для проектирования интерфейса выбрана среда MS Visual Studio (C#).

Microsoft Visual Studio -- линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms. Среда выбрана в качестве инструмента проектирования интерфейсной части программы по ряду причин [10].

Большая библиотека графических элементов управления.

Возможность установки дополнительных библиотек.

Совместимость с операционной системой семейства Windows.

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

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

На основе проведенного анализа средств разработки ИС выбраны:

CASE-средства: BPwin 4.0 и Sybase Power Designer 15.3.

СУБД SQLite.

Среда разработки интерфейса MS Visual Studio (C#).

2.2 Описание функциональной модели деятельности объекта

Во время обследования объекта автоматизации было проведено собеседование с сотрудниками ЦОРУ КТСМ. В результате чего было выявлено, что основными функциями системы учета запчастей и неисправностей являются.

Хранение «правдивой» информации о всех движениях запчастей: приход, списание - от этого зависит своевременный заказ запчастей и как следствие, своевременный ремонт оборудования минующий его простои. Для ЦОРУ КТСМ своевременное занесение информации о списании запчастей является важной составляющей эффективной работы цеха.

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

На основании данного обследования построена функциональная модель «AS IS» (как есть).

На диаграмме А-0 IDEF0 показана общая модель ведения учета запчастей и неисправностей ЦОРУ КТСМ (рис. 2.1).



Рисунок 2.1 - Общая модель ведения учета запчастей и неисправностей ЦОРУ КТСМ.

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

Сбор данных о неисправности оборудования КТСМ;

Учет запчастей ЦОРУ КТСМ.

Рисунок 2.2 - Декомпозированная модель ведения учета запчастей и неисправностей ЦОРУ КТСМ.

Входная информация.

Заявки на устранение неисправностей оборудования КТСМ - заявки на ремонт оборудования могут поступать в ЦОРУ КТСМ от сотрудников цеха, в частности от электромехаников.

Каталог запчастей ЦОРУ КТСМ - список запчастей имеющихся на складе, которые могут быть использованы в процессе устранения неисправности.

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

Журнал выполненных работ - ведется сотрудниками ЦОРУ КТСМ в ручную, для регистрации неисправностей и списанных запчастей.

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

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

Управление.

ПТЭ и инструкции ЦОРУ КТСМ - при выполнении своей работы сотрудники руководствуются правилами техники безопасности эксплуатации электроустановок потребителей, и инструкциями цеха по обслуживанию электронных систем.

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

Бюджет на покупку запчастей - при заказе запчастей старший электромеханик не может выйти за рамки бюджета.

Должностные инструкции старшего электромеханика - должностная инструкция старшего электромеханика оговаривает его права и обязанности.

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

Механизмы.

Старший электромеханик - начальник ЦОРУ КТСМ, занимается контролем функционирования данного подразделения.

Электромеханики - сотрудники предприятия.

Информация на выходе.

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

Заявки на приобретение запчастей - на каждую запчасть старший электромеханик составляется заявку (приложение Д).

Акт на списание запчастей - ежемесячно старший электромеханик составляет акт на израсходованные за месяц запчасти (Приложение Е).

Каталог запчастей ЦОРУ КТСМ с изменениями - на выходе, после выполнения работ, журнал выходит с внесенными изменениями.

Техкарточки на оборудование КТСМ с изменениями - на выходе, после выполнения работ, техкарточка выходит с внесенными изменениями в журнале.

2.3 Разработка функциональной модели желаемой системы

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

На выходе появится дополнительная информация - Статистика неисправностей. До внедрения системы собираемая информация о неисправностях хоть и хранилась в упорядоченном виде, но не представлялось возможности быстрого и точного анализа этой самой информации. После внедрения автоматизированной подсистемы, сбор и анализ, будут протекать в автоматизированном режиме. Это будет новый вид информации, который позволит повысить производительность оборудования за счет выявления и устранения «слабых» мест оборудования КТСМ.

В схеме появился новый механизм - проектируемая система. Если раньше, вся работа выполнялась в ручную, то теперь этот механизм берет на себя большую часть работы.

Во - первых, он помогает уйти от повторного выполнения одних и тех же действий.

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

Рисунок 2.3 - Общая модель ведения учета запчастей и не исправностей ЦОРУ КТСМ после внедрения.



Рисунок 2.4 - Декомпозированная модель ведения учета запчастей и неисправностей ЦОРУ КТСМ после внедрения

Входная информация.

Заявки на устранение неисправностей оборудования КТСМ.

Каталог запчастей.

Накладные на запчасти.

Журнал выполненных работ.

Отклоненные заявки.

Техкарточки на оборудование КТСМ.

Управление.

ПТЭ и инструкции ЦОРУ КТСМ.

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

Бюджет на покупку запчастей.

Должн. инстр. Старшего электромеханика.

Должн. инстр. Электромеханика.

Механизмы.

Старший электромеханик.

Электромеханик.

Проектируемая подсистема.

Информация на выходе.

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

Заявки на приобретение запчастей.

Акт на списание запчастей.

Каталог запчастей ЦОРУ КТСМ с изменениями.

Техкарточки на оборудование КТСМ с изменениями.

Статистика неисправностей

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

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

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

Концептуальная модель переносится затем в модель данных, совместимую с выбранной СУБД. Возможно, что отраженные в концептуальной модели взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения концептуальной модели. Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью.

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

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

Логическая структура БД (схема приведена в приложении Б) отражает информационно-логическую модель.

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

Физическая структура БД (схема приведена в приложении В) является адекватным отображением полученной информационно-логической модели, не требующей преобразований. Каждый объект модели данных отображается соответствующей реляционной таблицей.

Проектирование таблиц базы данных

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

Таблица - Должности

Сущность должности (таблица 2.2) предназначена для описания должностей сотрудников ЦОРУ КТСМ.

Таблица 2.2 - Сущность Roles

№п/п	Имя атрибута	Тип атрибута	Описание
1	role_id	Integer (pk)	Код должности
2	department_id	Integer (fk)	Код подразделения
3	role_name	Varchar (100)	Имя должности
4	date_from	Date	Дата введения должности
5	date_to	Date	Дата закрытия должности

Таблица -- Связь сотрудника и должности

Сущность Personal_link_roles (таблица 2.3) предназначена для хранения истории должностей каждого сотрудника.

Таблица 2.3 - Сущность Personal_link_roles

№ п/п	Имя атрибута	Тип атрибута	Описание
1	pr_link_id	Integer (pk)	Код связи сотрудника и должности
2	role_id	Integer (fk1)	Код должности
3	personal_id	Integer (fk2)	Код сотрудника
4	date_from	date	Дата назначения на должность
5	date_to	date	Дата снятия с должности

Таблица - Сотрудники

Сущность сотрудники (таблица 2.4) предназначена для описания сотрудников ЦОРУ КТСМ.

Таблица 2.4 - Сущность Personals

№п/п	Имя атрибута	Тип атрибута	Описание
1	personal_id	Integer (pk)	Код сотрудника
2	fio	Varchar (100)	ФИО сотрудника ЦОРУ КТСМ
3	person_number	Integer	Табельный номер
4	date_job_in	Date	Дата приема на работу
5	date_job_out	Date	Дата увольнения

Таблица -- Связь неисправности и шагов

Сущность связь неисправности и шагов (таблица 2.5) предназначена для хранения истории каждой неисправности.

Таблица 2.5 - Сущность Brokens_link_steps

№п/п	Имя атрибута	Тип атрибута	Описание
1	bs_link_id	Integer (pk)	Код связи неисправности и шагов
2	broken_step_id	Integer (fk1)	Код шага неисправности
3	broke_id	Integer (fk2)	Код неисправности
4	date_from	Date	Дата начала статуса неисправности
5	date_to	Date	Дата окончания статуса неисправности

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

Сущность связь сотрудника и неисправностей (таблица 2.6) предназначена для хранения хода устранения неисправности сотрудниками. Например, одну и туже неисправность могут устранять несколько сотрудников поочередно. Данная сущность позволит отследить всех сотрудников принимающих участие в устранении неиспрваности.

Таблица 2.6 - Сущность Personal_link_brokens

№п/п	Имя атрибута	Тип атрибута	Описание
1	pb_link_id	Integer (pk)	Код связи сотрудника и неисправности
2	personal_id	Integer (fk1)	Код сотрудника
3	broke_id	Integer (fk2)	Код неисправности
4	date_from	Date	Дата начала устранения неисправности сотрудником
5	date_to	Date	Дата окончания (передачи) устранения неисправности

Таблица -- Неисправности

Сущность неисправности (таблица 2.7) предназначена для хранения неисправностей происходящих на оборудовании ЦОРУ КТСМ.

Таблица 2.7 - Сущность Brokens

п/п	Имя атрибута	Тип атрибута	Описание
1	broke_id	Integer (pk)	Код неисправности
2	equip_id	Integer (fk)	Код оборудования
3	descript_brok	varchar(500)	Описание неисправности
4	date_start	Date	Дата появления неисправности
5	date_stop	Date	Дата устранения неисправности
6	rank	integer	Сложность неисправности

Таблица -- Оборудование

Сущность оборудование (таблица 2.8) предназначена для хранения оборудования ЦОРУ КТСМ.

Таблица 2.8 - Сущность Equipment

№п/п	Имя атрибута	Тип атрибута	Описание
1	equip_id	Integer (pk)	Код оборудования
2	equip_group_id	Integer (fk)	Код группы оборудования
3	equip_name	varchar(100)	Название оборудования
4	start_year	Date	Дата ввода оборудования в эксплуатацию
5	serial_number	varchar(100)	Заводской серийный номер оборудования
6	end_year	Date	Дата снятия оборудования с эксплуатации
7	descript_eq	varchar(500)	Описание оборудования
8	power	integer	Потребляемая мощность оборудования, измеряется в кВт
9	firm_manufact	varchar(100)	Фирма -- изготовитель оборудования

Таблица -- Списанные запчасти

Сущность списанные запчасти (таблица 2.9) предназначена для хранения истории списанных запчастей.

Таблица 2.9 - Сущность Broke_link_spares

№п/п	Имя атрибута	Тип атрибута	Описание
1	bs_link_id	Integer (pk)	Код списанной запчасти
2	broke_id	Integer (fk1)	Код неисправности
3	spare_id	Integer (fk2)	Код запчасти
4	count	Integer	Количество списанных запчастей (должно быть не менее 1)
5	date_out	Date	Дата списания запчасти
6	note	varchar(100)	Примечание

Таблица -- Подразделения

Сущность подразделения (таблица 2.10) предназначена для хранения списка подразделений занимающихся обслуживанием ЦОРУ КТСМ.